Michael Raskin <7c6f4...@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 _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev