[Nix-dev] Keeping nixpkgs up to date

[Michael Raskin]

>Actually I think people are much more inclined to sit down and spend a
>few minutes sometimes updating a package or two from their group rather
>than putting their own name down specifically on a package and then
>having the sole burden of updating it themselves. I also think it makes
>people feel ‘I'm in a group of people doing similar so I can always seek
>help from them’ as opposed to ‘I'm on my own to figure it out when this
>breaks’.
>
>In general it means that technically one is ‘in charge’ of more packages
>per-person but it's much easier to try to recruit under the ‘come and
>help out sometimes with these packages’ angle as opposed to ‘go and
>become maintainer of those packages and they will be your responsibility’.
>
>Even if that's not the case, this doesn't remove the existing system,
>people are free to only put down their name on individual packages. I'm
>simply aiming at more organisation. We really have a lot of packages
>that need some entity to maintain them and it's easier to track a
>handful of entities for activity than thousands of individual packages.

Let me tell you what went on when the «maintainers» field was added.

It turned out that noone claimed maintenance of the packages at first.

Then it was specifically spelled out that maintenance is not expected to
mean exclusivity in changing the package or specific actions to perform,
but the maintainer is expected to do own best at answering the questions
about the package when someone tries to improve/update it but cannot…

I am not sure, though, who of use remembers this discussion.

I would say that ZHF has some progress specifically because it is about
reasonable efforts to improve signal-to-noise.

If we want packages to get updated, we need to merge pull requests 
faster and not let pull requests linger in limbo. That would make 
sending PRs for updates look like a good idea (so less burden on 
maintainers to monitor updates). For complex questions, we should Cc:
the maintainers of the packages in question (or of the most similar
packages with maintainers) — but the idea is that more people should 
read pull requests. Once in a couple of weeks I find time to reduce the
amount of pending PRs by a page. Five more people among committers to do
the same and we'll have no pending PRs without good reason for 
a detailed discussion, I hope…

Those who don;t yet have commit rights could still read the PRs, comment
whether they see anything to improve, and try to test some of the PRs:
knowing that a PR works fine for a few people makes it simpler to decide
to merge…