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