Re: [Nix-dev] Maintainership
Excerpts from Alex Berg's message of Wed Jan 29 03:57:56 +0100 2014: Rather than removing unmaintained packages, can we make them available as a separate, opt-in channel? Then they will bitrot even faster - because you have to test much more. It would be possible, I've been using kind of overlays for a long time (for haskell and ruby packages packaged my automatic style) But also see below, git history will be available always .. @Jan Malakhovski For what it worth, I think unmaintained packages should not be removed just for the sake of it, especially when/if their nix-expressions are nontrivial. Don't forget that history will always be accessible by using git search. But I agree that its easy to miss that. Its non trivial to estimate how much complicated packages (let's say openoffice/libreoffice for instance) also change while packages are broken. In the open office / libre office case open office was broken too, but the fix was not to fix open office but to switch to libre office. There are so many reasons that it does make sense to remove packages after some time (maybe 6-12 month) which is why its important to declarate since when they were broken. At least that's what I think. The more interesting question is whether we should try to keep all tarballs mirrored, so that you at least have a chance to install the old versions which worked once .. - Again nice users statistics would help determining which source archives to keep. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Thomas Bereknyei tombe...@gmail.com writes: That almost sounds like an unstable channel. Unstable and unmaintained are two very different things. Rather than removing unmaintained packages, can we make them available as a separate, opt-in channel? I'd say that is an option, but if the unmaintained pile contains important software and basically everybody needs to enable it, we are not much better off -- we'll still get a lot of breakage every time we update the system and even up-to-date systems will likely sport many vulnerabilities. Not everyone is happy to rely on security by obscurity of NixOS, and if it becomes more widespread it could become an easy attack target. I imagine that non-NixOS installations of nixpkgs have a different set of trade-offs though. -- 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
Re: [Nix-dev] Maintainership
Jan Malakhovski o...@oxij.org writes: * First, this remove unmaintained policy discourages adding new packages to the public nixpkgs by users that are unable to maintain stuff. In the example above, I would better store the package in my own branch than risk it being unexpectedly removed. This would probably imply duplication of work in case somebody else will want to have it at some later point. I wouldn't search all the nixpkgs' forks for a possibility that somebody already has an expression for this package. It is a trade-off. Broken packages can be more overhead than duplication of work. If you make a package that works for you, push it to nixpkgs and abandon it, the next person will find it broken for his purpose, fix it and in the process break it for you. You will both spend time debugging the package. If one of the two users was a maintainer, the other could come to him and they can figure out something that works for both. If there is no maintainer and you update once in a while, you can end up ping-ponging fixes and counterfixes. I would rather drop this remove unmaintained altogether, at least for current requirements for being a maintainer (especially about the timely fashion). Marking unmaintained (or even better: unmaintained and potentially exploitable (which I would define as: it's a daemon or some other package uses it)) packages broken and notifying contributors about this fact looks okay. Even things that are marked as broken involve cognitive overhead when working on nixpkgs. They clutter up the source, often use outdated idioms, they hold up or complicate changes in support code. It's like a closet, it's hard to get at the things you actually use when it's full of junk. As for exploitable, that's an extremely conservative approach you suggest. I'm wondering if a remote code execution vulnerability in your browser or e-mail client is of no concern to you. :-) Or a PDF reader? Flash plugin? There have been countless security breaches due to bugs in non-daemon, leaf packages. 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
Re: [Nix-dev] Maintainership
It is a trade-off. Broken packages can be more overhead than duplication of work. If you make a package that works for you, push it to nixpkgs and abandon it, the next person will find it broken for his purpose, fix it and in the process break it for you. You will both spend time debugging the package. If one of the two users was a maintainer, the other could come to him and they can figure out something that works for both. If there is no maintainer and you update once in a while, you can end up ping-ponging fixes and counterfixes. 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. 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/. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
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
Re: [Nix-dev] Maintainership
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
Re: [Nix-dev] Maintainership
On 01/29/2014 11:28 PM, Jan Malakhovski wrote: That's clever. And not too much pain. I could handle that in case my package got removed. I recommend using git log -G regexp to search the whole history if you fail to find something. Currently it's just a matter of several seconds on our repo and reasonable HW. With this I see little need for keeping those stubs (for real use one should also preserve name). Whatever the way, we need to somehow indicate quality of the packages. There's lots of stuff that don't build for many months, or with security holes... Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Hi, I agree with basically everything said, and I think breaking packages with no maintainers (after the next stable branch-off, 14.0x?) would be really good to make it obvious what is broken and is a candidate for removal. It would also give people a chance to adopt a package they use before it is removed. Shea Levy s...@shealevy.com writes: * If a change elsewhere breaks a maintained package in a non-obvious way, the maintainers should make a reasonable effort to fix the breakage in a timely fashion I'd say that maintainers of things (packages) with reverse dependencies should also try to help out their dependees when they do bumps likely to break downstream packages. At least by scheduling such bumps at times when they are going to be available for consulting, if nothing else. 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
Re: [Nix-dev] Maintainership
On 01/28/2014 04:36 PM, Shea Levy wrote: Thoughts? Brokenness should be per-platform, as it's been introduced recently (meta.broken meaning that no platform is known to work). Thus, for maintained packages there should be platforms set, so we have at least build status and users have binaries for some default config (this finds much of errors introduced by dependencies). Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Shea Levy s...@shealevy.com writes: * If a package is unmaintained, it can be removed with minimal notice. This will require some time under the new idea of maintainership before it can be fairly put into place, but Eelco had the suggestion that no maintainers could be treated equivalently to meta.broken = true. In Debian, I would imagine they can make use of the popularity contest or whatever it is to see if people are even using this. Is it worth that we consider having the ability to gather metrics like that? Removing things from our package database should be more conscious than is this supported and should really be considering do people need this?. * Maintainers should respond to emails, issues, and pull requests about their package in a timely fashion (even if just with WONTFIX) * Maintainers should at a minimum keep track of security updates for their packages * If a change elsewhere breaks a maintained package in a non-obvious way, the maintainers should make a reasonable effort to fix the breakage in a timely fashion * Ideally maintainers would test their maintained packages on the release branch(es) and master with regular frequency (most ideally by using them as a user) * In most cases, maintainers should keep track of all new releases and update when available. In the case where a particular maintainer only wants to care about a specific version and that version is currently the latest, it would be appreciated if they could let the community know when a newer version is available so that someone else can step up * We should devise a way of denoting maintainers for NixOS modules and adopt similar policies there. Absent that, it would be nice if maintainers for a package also took care of the modules for that package where applicable Thoughts? If we did decide this was a good idea, we should set aside some time period by which people should unmaintain packages they don't want this responsibility for and adopt packages they do. These all sound reasonable - and I think I manage to do most of these myself. Most of the packages I'm a maintainer for are packages I actively use and am interested in the development of, so I am OK with having to keep things up to date. So yes, I agree with all of these points. - ocharles ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Excerpts from Shea Levy's message of Tue Jan 28 16:36:39 +0100 2014: Thoughts? I'd try such: 1) replace broken = true by broken_since=date; (Even maintained packages can be broken - and if they don't get fixed within 3-6 month they can be unmaintained this way. 2) send reminder to use the script to upload app usages (maybe quartely by mailinglist) 3) one month after the reminder was sent packages which are still broken and were broken for more than a month. Think about whether unused (but non broken) packages should be removed, too. Thus I'd send the maintainers a list of packages they maintain once a year, too. Then they can think about which ones to drop eventually. Its hard to define high quality - eg do we expect maintainers to review code, too? ... Maybe it does make sense to think about having different maintainance modes such as: - important - people depend on it - issues will be fixed fast and updates will be made, too? - not important, will be fixed if there is time. The real solution is to start a repository about source versions so that maintainers can upload references to their source tarballs with changelog - also introducing flags such as [this new version fixes a security issue] - then maintainers (also from other distros) could be notified automatically rather than thinking that maintainers will poll homepages regularly .. (which I don't do for most packages I created once).. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Hi, On 28/01/14 18:08, Oliver Charles wrote: * If a package is unmaintained, it can be removed with minimal notice. This will require some time under the new idea of maintainership before it can be fairly put into place, but Eelco had the suggestion that no maintainers could be treated equivalently to meta.broken = true. In Debian, I would imagine they can make use of the popularity contest or whatever it is to see if people are even using this. Is it worth that we consider having the ability to gather metrics like that? It should be possible (if somewhat tricky) to gather this information from the logs of cache.nixos.org (at least for those packages that are actually in the cache). -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
On 01/28/2014 06:12 PM, Stewart Mackenzie wrote: Might we adopt the C4 approach used in zeromq? It was created by Pietor Hintjens. We're using it os the Mozart Oz project and numenta/nupic to great success. Please consider it. Kind regards Stewart I don't understand much, and I think it was meant for the list, not myself. smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Excerpts from Eelco Dolstra's message of Tue Jan 28 18:21:57 +0100 2014: It should be possible (if somewhat tricky) to gather this information from the logs of cache.nixos.org (at least for those packages that are actually in the cache). You'll get cache hits for trying packages - but we need hits for usages. But you're right that that could be a starting point, too. I just think that its very important to understand what gets used, too. About debian and dropping: Right, If something does not work it should be dropped. I just think its nice to have some guaranteed time to fix as well as some hints that packages are broken. Whether a package gets removed 3 month earlier/later doesn't matter as long as it gets masked and then removed. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
On 01/28/2014 04:36 PM, Shea Levy wrote: Thoughts? If we did decide this was a good idea, we should set aside some time period by which people should unmaintain packages they don't want this responsibility for and adopt packages they do. I like your ideas and think that they will help to create a more reliable list of packages. I for one stumbled upon some broken but maintained packages when trying to install them (often without time to fix them or motivation to create an issue). I find this somehow more frustrating as if the package is not there at all or marked as broken. Pascal signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
On Tue, 28 Jan 2014 10:36:39 -0500 Shea Levy s...@shealevy.com wrote: Thoughts? If we did decide this was a good idea, we should set aside some time period by which people should unmaintain packages they don't want this responsibility for and adopt packages they do. For what it worth, I think unmaintained packages should not be removed just for the sake of it, especially when/if their nix-expressions are nontrivial. Suppose currently I'm the only user (or even maybe ex-user) of a package, the package is some obscure userspace util and so there aren't any security concerns involved, it works (or even maybe worked) for me, but I don't have any time whatsoever to maintain it. * First, this remove unmaintained policy discourages adding new packages to the public nixpkgs by users that are unable to maintain stuff. In the example above, I would better store the package in my own branch than risk it being unexpectedly removed. This would probably imply duplication of work in case somebody else will want to have it at some later point. I wouldn't search all the nixpkgs' forks for a possibility that somebody already has an expression for this package. * Second, I believe making a broken package work is usually easier than writing the nix-expression from scratch. Searching repository history for old removed versions of nix-expressions would be painful. I would rather drop this remove unmaintained altogether, at least for current requirements for being a maintainer (especially about the timely fashion). Marking unmaintained (or even better: unmaintained and potentially exploitable (which I would define as: it's a daemon or some other package uses it)) packages broken and notifying contributors about this fact looks okay. Cheers, Jan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Rather than removing unmaintained packages, can we make them available as a separate, opt-in channel? On Jan 28, 2014 6:43 PM, Jan Malakhovski o...@oxij.org wrote: On Tue, 28 Jan 2014 10:36:39 -0500 Shea Levy s...@shealevy.com wrote: Thoughts? If we did decide this was a good idea, we should set aside some time period by which people should unmaintain packages they don't want this responsibility for and adopt packages they do. For what it worth, I think unmaintained packages should not be removed just for the sake of it, especially when/if their nix-expressions are nontrivial. Suppose currently I'm the only user (or even maybe ex-user) of a package, the package is some obscure userspace util and so there aren't any security concerns involved, it works (or even maybe worked) for me, but I don't have any time whatsoever to maintain it. * First, this remove unmaintained policy discourages adding new packages to the public nixpkgs by users that are unable to maintain stuff. In the example above, I would better store the package in my own branch than risk it being unexpectedly removed. This would probably imply duplication of work in case somebody else will want to have it at some later point. I wouldn't search all the nixpkgs' forks for a possibility that somebody already has an expression for this package. * Second, I believe making a broken package work is usually easier than writing the nix-expression from scratch. Searching repository history for old removed versions of nix-expressions would be painful. I would rather drop this remove unmaintained altogether, at least for current requirements for being a maintainer (especially about the timely fashion). Marking unmaintained (or even better: unmaintained and potentially exploitable (which I would define as: it's a daemon or some other package uses it)) packages broken and notifying contributors about this fact looks okay. Cheers, Jan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
That almost sounds like an unstable channel. On Tue, Jan 28, 2014 at 9:57 PM, Alex Berg chex...@gmail.com wrote: Rather than removing unmaintained packages, can we make them available as a separate, opt-in channel? On Jan 28, 2014 6:43 PM, Jan Malakhovski o...@oxij.org wrote: On Tue, 28 Jan 2014 10:36:39 -0500 Shea Levy s...@shealevy.com wrote: Thoughts? If we did decide this was a good idea, we should set aside some time period by which people should unmaintain packages they don't want this responsibility for and adopt packages they do. For what it worth, I think unmaintained packages should not be removed just for the sake of it, especially when/if their nix-expressions are nontrivial. Suppose currently I'm the only user (or even maybe ex-user) of a package, the package is some obscure userspace util and so there aren't any security concerns involved, it works (or even maybe worked) for me, but I don't have any time whatsoever to maintain it. * First, this remove unmaintained policy discourages adding new packages to the public nixpkgs by users that are unable to maintain stuff. In the example above, I would better store the package in my own branch than risk it being unexpectedly removed. This would probably imply duplication of work in case somebody else will want to have it at some later point. I wouldn't search all the nixpkgs' forks for a possibility that somebody already has an expression for this package. * Second, I believe making a broken package work is usually easier than writing the nix-expression from scratch. Searching repository history for old removed versions of nix-expressions would be painful. I would rather drop this remove unmaintained altogether, at least for current requirements for being a maintainer (especially about the timely fashion). Marking unmaintained (or even better: unmaintained and potentially exploitable (which I would define as: it's a daemon or some other package uses it)) packages broken and notifying contributors about this fact looks okay. Cheers, Jan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
