[Nix-dev] Maintainership
Petr Rockai
me at mornfall.net
Wed Jan 29 16:22:48 CET 2014
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
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.
> 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
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.
Of course, having nix-env or somesuch list maintainers, and making it
possible to file issues with individual packages (as opposed to just
making a generic issue in github) would help with those things as well.
Petr
--
id' Ash = Ash; id' Dust = Dust; id' _ = undefined
More information about the nix-dev
mailing list