The biggest issue with GDrive is that our folks in China can’t easily view them ;)
toggle quoted messageShow quoted text
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 E. Seguin <wayneeseguin(a)starkandwayne.com <mailto:wayneeseguin(a)starkandwayne.com>>
CTO ; Stark & Wayne, LLC
On May 4, 2015, at 13:50 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:
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!
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.
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
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
See https://www.pivotaltracker.com/n/projects/1042066 <https://www.pivotaltracker.com/n/projects/1042066>
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