William L. Thomson Jr. posted on Sat, 29 Oct 2016 20:48:33 -0400 as excerpted:
> Its a slippery slope Gentoo is going down. The lack of man power causes > many things to go un-maintained. I will not comment on tree-cleaning > being right or wrong. Essentially what is taking place at a high level > is packages over all are being whittled down package by package due to a > lack of man power. > > Eventually it could reach some equilibrium that the amount of packages > is reduced to match the amount of man power to maintain. However it also > runs the risk of another downward spiral side effect. AFAIK, "whittling down" is an illusion, likely due to the fact that tree- clean candidate packages are announced in threads like this, while new packages are simply added without fanfare. At least, in my decidedly informal and less-than-rigorous tracking, pretty consistently whenever I've actually checked the weekly package add/remove list as posted right here to -dev, the count of added packages regularly exceeds the count of removed packages. For anyone who cares enough to check, of course, it should be quite possible to either total up the lists from the weekly add/remove notices for a year, or to simply grab a historical tree from somewhere, even just the first git import tree, and check the number of packages there against the number in a current tree. But it is my decidedly not rigorously tested but generally observed opinion that the number of packages in the tree is actually going up, not down. If that is indeed the case, then what we're seeing is simply the arguably healthy full circulation of packages, both into the tree as new and modern packages gain interest, and out of the tree as old and outdated packages lose interest until there's very few if any that even care about them any more. OTOH, if it's still building and generally working, has no open security bugs, and isn't being removed due to removal of dependencies (which would seem to be what the packages currently under discussion are up against, they /may/ build against a newer dep, but without a maintainer or anyone else actually caring enough to bother testing and the old dep being removed...), general policy /has/ been that it stays in the tree until such time as one of those test factors fails and no one cares enough to fix it. /Then/ it should be treecleaned. And I've been known to post objections to working packages being treecleaned based on exactly that. But with the dep being removed here, and no one (yet) interested enough in them to bother testing with the possible new dep and confirming they work, in this case, yes, I'd say it's time to remove... of course assuming that remains the case for the length of the 30-day notice and masking period, that of course being the very reason /for/ such a public notice and masking, in case someone /does/ care enough about it to volunteer to do that testing and confirm that the proposed substitute dep actually works. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
