Present Buildpacks to the TOC about toc

[caniszczyk]

@bgrant0607 and @monadic are happy to sponsor this in the sandbox

@sclevine can you put forth a project proposal and issue a PR against the TOC repo?

[duglin]

@sclevine can you elaborate on where, or what, this "project" is? The url to github you provided is just to a README. All of the links in there go to other sites. Are you proposing a project that has code - and if so, where is it? or are you suggesting we pick-up the CF code base? Or is this project a specification? the CF spec? the heroku spec?

[caniszczyk]

RFC @cncf/toc

If I don't hear anything against scheduling from the TOC by end of next week, how does Aug 21st work at 8am PT?

[sclevine]

@duglin We intend to contribute a specification for a new buildpack interface that adopts cloud native principles and standards, a corresponding reference implementation, and a set of tools. We don't currently plan to contribute existing buildpacks.

Apologies for the lack of clarity -- this is an early-stage project intended for the sandbox, and we plan to publish more before presenting to the TOC.

[duglin]

Great, thanks for the clarification.

…

Sent from my iPad

On Jun 9, 2018, at 12:01 AM, Stephen Levine ***@***.***> wrote: @duglin We intend to contribute a specification for a new buildpack interface that adopts cloud native principles and standards, a corresponding reference implementation, and a set of tools. We don't currently plan to contribute existing buildpacks. Apologies for the lack of clarity -- this is an early-stage project intended for the sandbox, and we plan to publish more before presenting to the TOC. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[garethr]

What's a good place for folks to contribute to this effort?

[dankohn]

@sclevine Could you please speak to why Heroku and Cloud Foundry are not planning to contribute the existing buildpacks?

[caniszczyk]

@sclevine you can present to the TOC on August 21st if that works at 8am PT

[chipchilders]

@dankohn I'll let @sclevine and the Heroku folks reply as well, but generally think about buildpacks as artifacts that are designed to be varied across users and use cases. An imperfect analogy would be Dockerfiles. There's discussion in the works around a buildpack registry to help with discoverability across the ecosystem of buildpack authors.

What matters is the standardization of the API and reference implementations of that API that can support using any buildpack that conforms to the standard.

[dankohn]

I agree that you can treat buildpacks as opaque and just standardize the interfaces for them. However, I know from experience that there are thousands of hours of engineering invested in, say, the internals of the Ruby or Node.js buildpacks. I would think that CF and Heroku might want to collaborate to share that engineering rather than maintain their own buildpacks. But perhaps that collaboration could come later.

…

-- Dan Kohn <[email protected]> Executive Director, Cloud Native Computing Foundation https://www.cncf.io [phone] https://www.dankohn.com

On Tue, Jun 12, 2018 at 12:53 PM, Chip Childers ***@***.***> wrote: @dankohn <https://github.com/dankohn> I'll let @sclevine <https://github.com/sclevine> and the Heroku folks reply as well, but generally think about buildpacks as artifacts that are designed to be varied across users and use cases. An imperfect analogy would be Dockerfiles. There's discussion in the works around a buildpack registry to help with discoverability across the ecosystem of buildpack authors. What matters is the standardization of the API and reference implementations of that API that can support using any buildpack that conforms to the standard. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC8MBlF_gIISGktkONciJG_zjMAv0Ociks5t7_HygaJpZM4Ug-FV> .

[sclevine]

@caniszczyk August 21 at 8am PT works for everyone, thanks!

@dankohn The new specification pushes a chunk of common buildpack functionality into the lifecycle (the program that runs in the build container and implements the spec) so that authoring a simple buildpack is relatively easy. It also has built-in support for inline buildpacks, so that developers can still take advantage of the buildpack model (ex. automatic OS-level patches) without overhead when they need more flexibility than existing buildpacks provide.

We plan to create a registry for buildpacks with a degree of curation, but we don't have immediate plans to include existing buildpacks in the project itself. We may re-evaluate this once the Cloud Foundry and Heroku buildpacks adopt the new specification. We want buildpacks to be a comprehensive solution for building app images, but we also believe that having more than one implementation of a Ruby buildpack or Node.js buildpack that implements the new specification initially will help us drive out an interface that is generic and interoperable.

We've still actively collaborating on the new specification, but we've made it viewable here for those interested in reviewing it before we open the doc up for public comment. I've also started work on a reference implementation here.

[caniszczyk]

scheduled to present Aug 21st at 8am PT

[sclevine]

Thanks @bgrant0607 and @monadic! Don't hesitate to reach out to us if you have any questions about the project. We really appreciate your interest! 😄

@caniszczyk Will do ASAP.

[sclevine]

@caniszczyk proposed here: #150