The biggest issue with GDrive is that our folks in China can’t easily view them ;)  

My question/feedback comes from the other recent thread about buildpack sizing and efficiency. I did not see a bullet point in the list below for this (unless it was covered by different wording/terminology).  I would love to see a way where buildpacks can become smaller not bigger whilst still supporting the vast array of languages+versions. 

Thank you for including them in this email and thank you for keeping us all in the loop, much appreciated!

  ~Wayne

CTO ; Stark & Wayne, LLC

On May 4, 2015, at 13:50 , Mike Dalessio <mdalessio@pivotal.io> wrote:

Hi all,

We held the first Buildpacks PMC meeting today; I'd like to share the agenda and notes.

For reference, all agendas notes for the Buildpacks PMC will be kept in a public Google Drive folder at this URL:


I realize GDrive isn't the most convenient medium for some in the CF community; I'd love to hear how we can better support transparency for everyone.

Please feel free to respond with comments and questions!

Cheers,
-m

----

Attendees:
  • Chip Childers, Cloud Foundry Foundation
  • Mike Dalessio, Pivotal (PMC lead)
  • Christopher Ferriss, IBM
  • Michael Fraenkel, IBM
  • Mark Kropf, Pivotal


Recent Inception Report and Stated Goals

The Buildpacks core development team held a project inception on 2015-04-20, to gain a shared understanding of upcoming goals and tracks of work.

Goals
    • Expand supported ecosystem to include more languages & frameworks
    • Cloud Foundry ownership of Buildpacks
    • Leverage new primitives in Diego (“app lifecycle”)
    • Enable 3rd party extensions to the Developer experience
    • Enable application developer extensions to the Developer experience
    • Set patterns for creating new buildpacks and for extending the Developer experience
    • Generate clearer diagnostics during staging
    • Enable Operator ease of updating common dependencies
    • Keep the `bin/detect` experience: buildpacks should Just Work™
    • Exert more ownership over the rootfs
    • Binary buildpack support

Risks
    • java-buildpack is diverging quickly from the core buildpacks
    • Lack of deep experience in some ecosystems
    • Wide variety in implementations across buildpacks
    • rootfs: with great power comes great responsibility (e.g., security response)
    • tight coupling between buildpacks and rootfs
    • versioning between buildpacks and rootfs

Current Backlog and Priorities


Notable near-term goals:

  • staticfile-buildpack support in `cf-release`
  • binary buildpack (a.k.a. “null buildpack”) support in `cf-release`
  • ability to generate and test CF rootfs-specific binaries; and tooling for CF operators to do the same


Proposal: Buildpack Incubation Process

Discussion today for PMC input; a draft document will be circulated for comment to cf-dev@ mailing list after the meeting, in a separate thread.


_______________________________________________
cf-dev mailing list
cf-dev@lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev