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