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 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 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.

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.

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:

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.

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

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?

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 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.