On Thu, Jan 21, 2016 at 5:41 PM, <waltd...@waltdnes.org> wrote: > I think you misunderstood Roy. He was speaking about "unmaintained > but perfectly functional software". You're talking about "a package > that clearly doesn't build or otherwise simply doesn't work, could not > have worked for past 3 years". Between those 2 extremes will be many > cases of doesn't-work-for-me/works-for-me. Who'll be the final arbiter? >
I don't think we need any kind of formalized policy. The treecleaners can make a decision and there doesn't need to be any appeals. The treecleaners should remove packages that are both unmaintained and broken. They don't have to have bugs open, and simply having a bug open for a long time shouldn't be a reason to treeclean on its own. If a package has a security issue or is just generally crippled then it should be removed. That might sound a bit subjective, but I don't think that is a problem - if the treecleaners want to make a statement of policy they can do so. And if somebody disagrees with the treecleaners then they can go ahead and volunteer to maintain the package. Maintainers aren't actually obligated to fix non-security bugs at all, by the way (though doing so would certainly be nice). But, they'll get to listen to all the grief about problems they cause instead of the treecleaners. Obviously if things get out of hand there are ways to escalate. In any case, I consider the labeling of these unmaintained packages as maintainer-needed as a good thing, even if some get treecleaned as a result. Part of our social contract is not hiding problems. Unmaintained packages should be clearly labeled as such. And I'm all for some suggestions that have been offered to hghlight packages they use which are unmaintained (I'd suggest that instead of messing with eclasses we simply put that feature in portage though). -- Rich
