Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose to manage project status #314

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Propose to manage project status #314

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6523ced
Propose to manage project status
loewenstein-sap Dec 17, 2024
752df1c
Update text/0000-buildpack-status.md
loewenstein-sap Dec 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions text/0000-buildpack-status.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# Introduce a maintenance status for buildpacks

## Summary

Given the limited capacity of the maintainer teams, we should start to introduce a disctinction between the different levels of maintenance individual buildpacks provide.
loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved
The proposed levels are:
- **Active Maintenance**: The buildpack is actively maintained and updated by the maintainers. Feature requests and bug reports are actively worked on. The maintainers have capacity for coordinated cross project work.
- **Security Maintenance**: The buildpack is maintained and updated by the maintainers, but the focus is on critical bugs and project hygene like dependency updates. The maintainers might have limited capacity for cross project work.
- **Out of maintenance**: The buildpack is not actively maintained by the maintainers. The maintainers might still accept PRs and bug reports, but the response time is not guaranteed. The maintainers have no capacity for cross project work.
Comment on lines +7 to +9
Copy link
Contributor

@dmikusa dmikusa Dec 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather see the levels as some opaque term, so people don't read into the title and assume things. For example, Level 1, Level 2, Level 3 or Gold, Silver, Bronze. I know it's a little less friendly, cause you might need to look up what the levels mean but I think that will actually prevent people from making possibly incorrect assumptions about them.

I'd also prefer to have four levels, where 1-3 are similar to what you outlined and 4 is when a project has gone dormant. That way we can differentiate between a project that's been archived cause maybe it's no longer useful or relevant as opposed to projects that have gone dormant and could be useful but just don't have anyone to maintain them.

My thoughts on the individual levels:

Top tier - a.) two or more maintainers (possibly with a grace period to allow for transitions), b.) maintainers actively participating in RFC process c.) maintainers actively participating in cross-project work d.) maintainers are actively engaged with the community (slack, discussions) e.) there is an established release schedule and it's being followed

Second tier - a.) one or more maintainers, b.) maintainers are less involved (not meeting one of b.), c.) or d.) from top-level, c.) there's no established release schedule or release schedule is not being followed (i.e sporadic releases)

Third tier - a.) zero or one maintainer, b.) maintainer may be unresponsive or new and not yet involved (not meeting multiple of b.), c.) or d.) from top-level, c.) project is a new project and being bootstrapped, no 1.0 release yet. d.) no defined release schedule / no consistent releases

Fourth tier - a.) zero maintainers, b.) cannot guarantee state of the buildpack in terms of compatibility or security, c.) project does not recommend this buildpack be used in its present state.

IMO, first and second tiers are normal. The main difference is just the involvement of the maintainers.

The third tier is a transition tier, a buildpack may go there if it's been abandoned, like if the maintainers have left and we're hoping to get new maintainership. New buildpacks also start here and it's a place to grow. So it's kind of an incubator. Users can use these but it's a use at your own risk kind of situation.

I think there should be time limits for buildpacks that are in the third tier. There are maybe 12 months to find someone to become the maintainer or get a new buildpack going and get things up to tier 2 quality or the buildpack gets moved to tier four. No one is going to want to have a buildpack go to tier 4 status, but I think we need something objective as a trigger and time would be one way to accomplish that.

The fourth tier is just a placeholder for what happens when we can no longer maintain a buildpack. It goes here until there is sufficient interest and involvement to resurrect it. This is different from buildpacks that we've deprecated and removed, which means those are not coming back.


## Motivation

A couple of maintainers have recently left the project, without others having stepped up to take over their responsibilities. Some of the maintainer teams are down to a single maintainer. This is not good for the project overall and in particular not for the outside perception. At the same time, we should acknowledge that some of the buildpacks might be as finished as software can get and don't need active maintenance anymore. This proposal aims to make the current state of the buildpacks more transparent to the users and to the maintainers themselves. In particular, the remaining maintainers might want to avoid being blocked on important cross project work by buildpacks that are not actively maintained anymore.

## Detailed Explanation

We should define the different levels of maintenance and the expectations that come with them.
I would suggest that the core builder proposed with https://github.com/paketo-buildpacks/rfcs/pull/313 would only accept buildpacks that are actively maintained. That way we can make sure that cross project topics like multi-arch or Ubuntu LTS updates can be addressed in a timely manner. Users can still use the other buildpacks, by specifying them explicitly.

Those buildpacks that get marked **Out of maintenance** should probably either be archived or moved to the paketo-community organization. We should also make sure that the users are aware of the status of the buildpacks. This could be done by adding a badge to the README of the buildpacks.

## Rationale and Alternatives

We could continue as we are, but that will lead to cross project efforts to potentially take indefinitely.

## Implementation

We should document the different levels of maintenance.
We should check with maintainers of the buildpacks if they agree with the proposed level of maintenance.

## Prior Art

None.

## Unresolved Questions and Bikeshedding

- What levels of maintenance should we have? I came up with two different levels of maintenance and one to express that the buildpack is not maintained anymore. I am happy to introduce finer grained levels of maintenance if that is desired.
Copy link
Contributor

@dmikusa dmikusa Dec 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have to be careful with terms like maintenance and support, as to some readers that will (incorrectly) imply a contract. That the project has actual guarantees on things, when in fact everything we do is "best effort". This is part of what I'd mentioned above about readers assuming things, and I think using an opaque term for the different levels will help prevent any miscommunication here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe using the term "activity level" which reflects what's in the wording interms of how actively the buildpacks may be updated but does not imply any promised maintenance so maybe something like:

  • Active
  • Security updates only
  • incubating, bootstrapping
  • Inactive

- What about the buildpacks that are not maintained anymore? Should we archive them or move them to the paketo-community organization?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- What about the buildpacks that are not maintained anymore? Should we archive them or move them to the paketo-community organization?
- What about the buildpacks that are not maintained anymore? Should we archive them or move them to the paketo-community organization?
- What about paketo-community? Do we really need that if we have this tier system?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be more in favor of getting rid of paketo-community and just moving any useful/maintained buildpacks into the corresponding tier in paketo-buildpacks. There's a bunch of overhead with paketo-community in terms of managing it, keeping GH teams in sync, keep secrets in sync, etc... and I don't feel like it has really achieved it's purpose, which is to attract folks to contribute community managed buildpacks.