[Nix-dev] Maintainership

[Michael Raskin]

>Michael Raskin <7c6f434c at mail.ru> writes:
>> Somehow, whenever updates of packages I care about were broken, it was 
>> a simple mistake that was easy to fix separately… I think this scenario 
>> is overly pessimistic.
>
>Well, depends on your point of view. If you only care about a few
>packages for your personal use, it's one thing, when you deploy an

I care about a few hundreds packages that I want to have installed,
and a few tens of them are something I use constantly.

>installation with twenty users it's entirely different. You run into the
>need to fix packages that you don't personally use or aren't very
>familiar with, and even if you figure out a fix, it is unlikely to be
>entirely correct.
>
>Being able to consult someone who understands both nix(os) *and* the
>package in question in a timely fashion would make fixing such problems
>much easier, and even somewhat less likely to be required.

Improving quality of individual packages = reducing count of packages
in the short run. So it's better to have a dump for non-Hydra-worthy 
packages…

>> In general, one can expect that the amount of time maintainers spend on
>> their packages will not change too much whatever policy change you
>> propose. There are some packages that I want to have installed but don't
>> care about versions, so the question is not whether I will maintain them
>> well but whether I will keep them in configurations/ or nixpkgs/.
>
>Well, I expect that if the tools make it easy to see whom to contact
>about a particular package, maintainers will see more engagement from
>their users. That alone can work to make them more active, and can give

Or just burn out… Hopefully only w.r.t. NixPkgs and only temporarily.

>them valuable feedback/new knowledge about how the package is/can be
>used. It also makes it less likely they break use-cases in the future if
>they are familiar with them.