toggle quoted messageShow quoted text
Thanks for asking this question.
The "risk" called out in the inception encompassed a number of things, but
what they really all boil down to is that the java-buildpacks team has its
own roadmap and conventions; and the two teams don't often communicate
about sharing resources, infrastructure, or planning.
I think a reasonable first step is for you and I (and maybe JT and Ben, the
engineering anchors for each team) to have a regular chat on our calendars.
I'd prefer not to get bitten by Conway's Law if we can easily mitigate this
risk. I'll ship you a calendar invite; as well as make sure the
java-buildpack team, as well as voting members of the PMC, are represented
in the next inception or roadmap discussion.
On Mon, May 4, 2015 at 2:43 PM, Ryan Morgan <ryanmorgan(a)gmail.com> wrote:
Thanks for the update Mike. Can we get a bit more detail on
java-buildpack divergence from the other buildpacks?
On Mon, May 4, 2015 at 10:50 AM, Mike Dalessio <mdalessio(a)pivotal.io>
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
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
- 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
- Set patterns for creating new buildpacks and for extending the
- 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.,
- 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