[gentoo-dev] Re: Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, media-gfx/skencil... and others

[Duncan]

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