toc icon indicating copy to clipboard operation
toc copied to clipboard
verified publisher icon cncf

[Graduation] Buildpacks Graduation Application

Open jkutner opened this issue 11 months ago • 8 comments

Review Project Moving Level Evaluation

  • [x] I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

Buildpacks Graduation Application

v1.6 This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.

Project name: Buildpacks Project Repo(s): https://github.com/buildpacks, https://github.com/buildpacks-community Project Site: https://buildpacks.io/ Sub-Projects: N/A Communication: https://cloud-native.slack.com/ #buildpacks and various channels with #buildpacks- prefix

Project points of contacts: [email protected], Technical Oversight Committee

Graduation Criteria Summary for Buildpacks

Application Level Assertion

  • [x] This project is currently Incubating, accepted on 2020-11-18, and applying to Graduate.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

Application Process Principles

Suggested

N/A

Required

  • [ ] Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
    • This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.
  • [ ] TAG provides insight/recommendation of the project in the context of the landscape

  • [x] All project metadata and resources are vendor-neutral.

    • The Buildpacks project operates according to well defined vendor-neutral governance guided by our Technical Oversight Committee, and all project communication, messaging, and collaboration is vendor-neutral.

  • [x] Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

  • [x] Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

    • Installation Documentation - https://buildpacks.io/docs/app-journey/
    • Contributing/Community Documentation - https://buildpacks.io/community/#contributing
    • Cloud Native Buildpacks Due Diligence

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

  • [x] Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
    • The Buildpacks project has an established governance process. Formal definition and historical changes are present in our buildpacks/community repository.

Required

  • [x] Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
    • All changes to the charter, governance model, leadership roles, and membership follow the project RFC process.
    • All voting in the CNB project will adhere to a lazy consensus model
    • Complete documentation of nominatation and election processes for TOC, Maintainers, and Contributors can be found in the buildpacks/community repo.
  • [x] Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
    • The Buildpacks project leadership and membership are divided into sub-teams that are responsible for specific components within the project. These include:
      • Technical Oversight Committee (TOC) - responsible for the direction of the project (roadmap), team leadership, and cross-cutting concerns.
      • Implementation Team - responsible for maintaining the components that constitute the Cloud Native Buildpacks reference implementation of the specification.
      • Platform Team - responsible for maintaining pack and any other platforms or platform components, as well as tools and services that support the distribution, discovery, and integration of buildpacks.
      • Learning Team - responsible for maintaining the project’s documentation, website, and resources.
      • Buildpack Authors' Tooling Team - responsible for helping buildpack authors create buildpacks
    • In addition, the buildpacks-community hosts several sub-projects that have independent governance process.

  • [x] Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

  • [x] A number of active maintainers which is appropriate to the size and scope of the project.

    • There are four (4) active Technical Oversight Committee Members from three different companies/organizations.
    • There are eight (8) active Team Leads
    • The leadership of the project are part of three (3) different companies/organizations (Salesforce, VMware/Broadcom, and Bloomberg) as well as independent partcipants.
  • [x] Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
    • Maintainers are in charge of the day to day maintenance of a team's projects.
    • New maintainers must already be contributors, must be nominated by an existing maintainer, and must be elected by a supermajority of CNB Team Leads and the TOC. Likewise, maintainers may resign or be removed by a super-majority of Team Leads and the TOC.
    • Complete documentation for the process can be found in the buildpacks/community repo
  • [x] Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
  • [x] Project maintainers from at least 2 organizations that demonstrates survivability.
    • There are three (3) different organizations with members in Buildpacks leadership positions. See above.
  • [x] Code and Doc ownership in Github and elsewhere matches documented governance roles.
  • [x] Document adoption of the CNCF Code of Conduct
    • https://github.com/buildpacks/.github/blob/main/CODE_OF_CONDUCT.md
  • [x] CNCF Code of Conduct is cross-linked from other governance documents.
    • https://github.com/buildpacks/.github/blob/main/CODE_OF_CONDUCT.md
  • [x] All subprojects, if any, are listed.
    • Sub-projects and components are owned by Teams. All teams and their list of projects are documented in buildpacks/community.
  • [x] If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
    • Sub-projects and components are owned by Teams. All teams and their list of projects are documented in buildpacks/community.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

  • [x] Contributor ladder with multiple roles for contributors.

Required

  • [x] Clearly defined and discoverable process to submit issues or changes.
  • [x] Project must have, and document, at least one public communications channel for users and/or contributors.
  • [x] List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

Engineering Principles

  • [ ] Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This requirement may also be satisfied by completing a General Technical Review.
    • A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.
  • [ ] Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.
    • A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.
  • [x] Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
    • A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.

  • [x] Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

    • [x] Release expectations (scheduled or based on feature implementation)
    • [x] Tagging as stable, unstable, and security related releases
    • [x] Information on branch and tag strategies
    • [x] Branch and platform support and length of support
    • [x] Artifacts included in the release.
    • Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security.

Suggested

  • [x] Achieving OpenSSF Best Practices silver or gold badge.
    • N/A

Required

  • [x] Clearly defined and discoverable process to report security issues.
  • [x] Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
    • Enabled in both our GitHub orgs: buildpacks,buildpacks-community
  • [x] Document assignment of security response roles and how reports are handled.
    • The security team, which consists of project maintainers, will be notified of security reports via email. This process is documented in SECURITY.md
  • [x] Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
    • https://www.bestpractices.dev/en/projects/4748

Ecosystem

Suggested

N/A

Required

  • [x] Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

  • [x] Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

  • [x] TOC verification of adopters.

Refer to the Adoption portion of this document.

  • [x] Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

    • CNCF Projects

      • Knative - Knative documents buildpacks a way to build functions on the cluster.
      • containerd - Buildpacks are used to build OCI images, which can be run by containerd.
      • kubernetes - Buildpacks can be used to build images that can be run on Kubernetes.
      • kpack is a buildpacks platform that runs as an operator on Kubernetes to produce and maintain application images.
      • Podman - Podman can be used as a docker-compatible target for executing buildpacks via pack CLI.

    • Non-CNCF Projects

      • Open Container Initiative - Buildpacks produce images that maintain compatibility with the OCI image spec.
      • Docker - pack CLI will, by default, target the Docker daemon for building images.
      • Project Piper - Project Piper is a set of tools for continuous integration and continuous delivery that uses buildpacks.
      • Tekton - Tekton integration with buildpacks is documented with the buildpacks tasks.

Adoption

Adopter 1 - Google
Adopter 2 - Salesforce
Adopter 3 - VMware by Broadcom

jkutner avatar Feb 17 '25 22:02 jkutner

@kfaseela to triage.

chadbeaudin avatar Jun 10 '25 15:06 chadbeaudin

@jkutner In preparation for Buildpacks to be picked up by a TOC member, please:

  • complete the application checklist, cleanup TODOs(if any) and make sure all the required items answered.
  • Update the status of your Project Presentation to TAG. If https://github.com/cncf/tag-app-delivery/issues/813 was not already completed, I would like to inform you that after TAG restructure the repo has been archived. It's suggested to create issue for "project review" in the cncf/toc repo. You may refer to: https://github.com/cncf/toc/issues/new?template=tech-review.yml
  • review the definition of an adopter
  • verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and submit information for each adopter to the Adopter Interview Questionnaire form

kfaseela avatar Jun 24 '25 11:06 kfaseela

@kfaseela our adopters have submitted the questionnaire. Is there any follow up we need to do?

jkutner avatar Aug 14 '25 14:08 jkutner

@kfaseela our adopters have submitted the questionnaire. Is there any follow up we need to do?

Hello @jkutner : Thanks for the update. Could you please also update the status of your project presentation to TAG as well? (The second point in my above message.)

kfaseela avatar Aug 14 '25 17:08 kfaseela

@kfaseela @jkutner The project can complete the General Technical Review questions while the TAG Reboot continues to progress. A TAG presentation is not required at this time. When a TOC member picks up the project, if there are concerns, they can ask the Project Reviews Subproject to work with the project on a Technical Review as well.

angellk avatar Aug 14 '25 22:08 angellk

Thanks @angellk ! I will start looking at this application and sync up with @jkutner to get started !

kfaseela avatar Dec 02 '25 13:12 kfaseela

✅ Created tech review issue: #1983 - [Tech Review]: Buildpacks

github-actions[bot] avatar Dec 03 '25 13:12 github-actions[bot]