Since I’ve been working on my tinderbox, I have found lots of packages that are unmaintained both for what concerns ebuilds, and upstream. This actually reminded me a lot of my first months within the multimedia teams (sound and video), during which I have found so many bad implementations that I was, for a while, renamed “the package undertaker” — I think Jeremy (Darkside) has now this title though, thanks to treecleaning.
Up to now I really left it to the actual maintainer (or treecleaners) to remove the broken package from the tree; but since it seems like many developers don’t seem even to care about removing the broken packages when they stop maintaining them, I’ve finally decided to take the matter in my hands, and started looking at the packages to last rite.
This mainly involves old ebuilds, untouched but for batch fixes for the past years, failing with the stable glibc, and with huge QA violations in the ebuild. So that the packages won’t be removed just for fun, I’m giving them 60 days to be fixed and salvaged instead of the standard 30. This hopefully will be enough to save the important useful stuff and get rid of the stuff that is only dragging down the Gentoo quality average.
While I’m absolutely in favour of keeping everything in a single, huge tree (I dislike overlays and I have already said that many times) there is one way we can reduce the amount of problematic software in the tree: removing the stuff that is desperate and that will never be up on par with the rest of the packages, and refusing to add software if it doesn’t look like its QA issues can be solved (even if that means not having software that users might demand in the tree until somebody goes around to fix the issues).
So this goes out as a warning: if you care about a package that is going to be removed for QA reasons, you’re very welcome to step in to fix the problems with it, we’ll be glad to keep it in the tree (unless, of course, it depends on a whole chain of software that should disappear, like for instance aRTs, ESounD and GTK+ 1.2).
Obviously there is always the option of bribing some dev enough that he can care about the package enough 🙂
Well this is too complicated in case of KDE 3. I’m performing cleanups in kde3 misc apps and i see many apps frozen by upstream for too long. Even kde 3 itself is dead for too long. But it is still popular and widely-used, so it isn’t too easy to remove kde3 apps from tree, nor is maintaining them. That’s why we have decided to keep it until kde 4.4 hits tree and then move kde-3 in an overlay, for two reasons:-packages will still be available-we have the right not to care about it any more as i strongly believe it is waste of time. I’d like your opinion on this as an ex-kde member
Could you please list any packages you want to kill off here? I use a few oddball packages that may be targets and I’d like to know so I can at least try to fix them. 🙂
Theo I understand your problem pretty well.. I sincerely would have liked to stay on KDE 3 myself till KDE 4.4 too, but I already started noticing the bitrot going on .. thus why I moved to GNOME mainly. I think it would be a nice thing to start removing at least those packages that are not essential and can be easily replaced, like KNetLoad (and I say that being its ex-upstream!). But I agree with it not being easy.James, the packages will have 60 days grace periods, so you should find them before they get slated for removal… on the other hand, if you wish to find which ones I might be going to look at, just check for my bugs where treecleaner@g.o is CCed, I’ll start from those probably.