[RFC 0180] Remove broken and unmaintained leaf packages

[Mic92]

Rendered

[dotlambda]

There should be a rule to notify e.g. everyone who touched the package expression in the past before removal.

[Frontear]

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?

[Mic92]

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.

[AndersonTorres]

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?

There are some of those packages that are very critical. Ideally they should be kept by a team.

[Mic92]

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?

There are some of those packages that are very critical. Ideally they should be kept by a team.

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.

[AndersonTorres]

I could see the security team for example maintaining microcode package.

Or the nixos-hardware team (when they become a NixOS team :D )

[Aleksanaa]

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:

1. Throws a warning to end users but still builds on hydra
2. Make a mark similar to insecure. If the user needs to use it, it needs to be manually allowed and it will not be built on hydra.
3. Completely remove related expressions.

Each of these stages can last three to six months, giving everyone plenty of time to react and plenty of reason to remove it.

[Frontear]

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

[8573]

Each of these stages can last three to six months, giving everyone plenty of time to react

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?

[AndersonTorres]

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.

[Mic92]

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:

1. Throws a warning to end users but still builds on hydra

2. Make a mark similar to insecure. If the user needs to use it, it needs to be manually allowed and it will not be built on hydra.

3. Completely remove related expressions.

Each of these stages can last three to six months, giving everyone plenty of time to react and plenty of reason to remove it.

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.

[Bot-wxt1221]

Some old packages that no longer update should be considered. Maybe we should add a tag to point out it shouldn't be deleted.

[nixos-discourse]

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

[nixos-discourse]

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

[kevincox]

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.

See more info on the Nix RFC process here

[nixos-discourse]

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

[Mic92]

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.

See more info on the Nix RFC process here

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.

[kevincox]

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.

[AndersonTorres]

I would like to see the Problem Infrastructure implemented before taking action, since it will provide the framework for doing this programatically.

[emilazy]

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.

[Mic92]

I would like to see the Problem Infrastructure implemented before taking action, since it will provide the framework for doing this programatically.

This is already happening: NixOS/nixpkgs#338267
I don't think we should block starting discussion on this PR for this reason, since this RFC is just about policies and not about implementation. Also we already have warnings/errors for "no maintainers" and "broken", so I don't see what this problem infrastructure should add new.

[Mic92]

I would like to nominate @emilazy for as a shepherd for this PR.

[emilazy]

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.

[Mic92]

I also would like to nominate @preisi

[preisi]

I'm accepting the nomination (and the chance to contribute to NixOS :))

[Mic92]

And finally I would like to nominate @jopejoe1

[jopejoe1]

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.

[Mic92]

I haven’t served as an RFC shepherd before, so I’m not too familiar with the exact process

Don't worry, I was on the steering committee for a few years and several RFCs, so I know the process.

[emilazy]

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.

[Mic92]

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.

[AndersonTorres]

I don't think we should block starting discussion on this PR for this reason, since this RFC is just about policies and not about implementation.

Makes sense.
I was thinking about implementation and avoiding reinvent the wheel.