-
-
Notifications
You must be signed in to change notification settings - Fork 158
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.
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
[RFC 0180] Remove broken and unmaintained leaf packages #180
base: master
Are you sure you want to change the base?
Conversation
3fd8a73
to
2e5572a
Compare
0082dff
to
215d264
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a rule to notify e.g. everyone who touched the package expression in the past before removal.
There are some packages with no maintainer yet don't exactly "become outdated" (an example is the intel-microcode package). How are we going to handle those? |
I am sure that someone wants to become a maintainer of a package like this, once we actually become serious about removing it, because their hardware won't function without it. However we leave the decision what to do in this case up to the person merging the pull request i.e. waiting for a reasonable amount of time depending on the importance package. |
There are some of those packages that are very critical. Ideally they should be kept by a team. |
849ea46
to
086cb9a
Compare
I think having this RFC in place, will make actually possible to find instances like this and hopefully improve the maintenance of these packages. I could see the security team for example maintaining microcode package. |
Or the nixos-hardware team (when they become a NixOS team :D ) |
I hope the problem infrastructure or something like it can be implemented first, so we can add warnings to end users like "foo is deprecated and is subject to removal because ...", and guide them to give feedback. If they give reasonable reasons, we will cancel or postpone the removal. We can divide the deprecation of a package into three stages:
Each of these stages can last three to six months, giving everyone plenty of time to react and plenty of reason to remove it. |
Additionally going back to maintainerless packages, I think itd be best to do a broad sweep and find which packages are still orphans and find them a team, especially for critical packages like the microcode package. Once this is done anything left behind would be non essential stuff, which can follow the removal procedure |
Wouldn't anything shorter than six months per stage not be enough time for users of stable channels to notice before the removal process may move on to the next stage? |
About orphaning, we also need to deal with the silent retirement. There are a truckload of maintainers that did not maintain their codes from a long span of time. I suggested to do a soft deletion of silent retired maintainers at NixOS/nixpkgs#310759. Regardless the above: We have the infamous Zero Hydra Failures event. We can do something similar around the months 3 and 9 in order to mark and sweep unmaintained packages. |
I don't see really enough benefit in step 2, it just creates more work for us. Removing packages should not be more work than adding packages. |
Some old packages that no longer update should be considered. Maybe we should add a tag to point out it shouldn't be deleted. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfcsc-meeting-2024-08-05/50170/1 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfcsc-meeting-2024-08-19/50831/1 |
RFCSC: This RFC has not acquired enough shepherds. This typically shows lack of interest from the community. In order to progress a full shepherd team is required. Consider trying to raise interest by posting in Discourse, talking in Matrix or reaching out to people that you know. If not enough shepherds can be found in the next month we will close this RFC until we can find enough interested participants. The PR can be reopened at any time if more shepherd nominations are made. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfcsc-meeting-2024-09-02/51514/1 |
When I was on the RFC steering committee, we used to find shepherds based on the people involved in the discussion. Is this no longer the case and I should nominate people? There are enough people that participated in the discussion but the since the topic is not super controversial and the RFC is kept intentionally short, there is not a lot discussion needed. |
Please nominate anyone you think is suitable. The whole community is welcome to nominate shepherds (including themselves). Sometimes members of the RFC Steering Committee will make nominations but IIUC it isn't the role of the steering committee as an entity to do so. The ability to nominate is available to everyone and not centralized in the committee. |
Co-authored-by: Thiago Kenji Okada <[email protected]>
I would like to see the Problem Infrastructure implemented before taking action, since it will provide the framework for doing this programatically. |
Are you going to drive the work of getting the problems infrastructure into Nixpkgs? Per #180 (comment) it’s currently stalled out, and I don’t think we should block this improvement on the status quo on an unspecified person appearing to fix that. |
This is already happening: NixOS/nixpkgs#338267 |
I would like to nominate @emilazy for as a shepherd for this PR. |
I walked into that one :) I haven’t served as an RFC shepherd before, so I’m not too familiar with the exact process, and my availability at specific hours is erratic, so I am worried that I would likely miss scheduled meetings. Other than that I’d be happy to do what I can to get this merged. |
I also would like to nominate @preisi |
I'm accepting the nomination (and the chance to contribute to NixOS :)) |
And finally I would like to nominate @jopejoe1 |
I haven't served as an RFC Shepherd yet either, but I hope that with accepting this nomination, I can help with getting this merged and implemented. |
Don't worry, I was on the steering committee for a few years and several RFCs, so I know the process. |
If doing the shepherd meetings over Matrix text chat works for everyone else I can probably squeeze in the time and would be happy to try to shepherd this. |
Invite sent. |
Makes sense. |
Rendered