Today I finally went around writing a script that could help me with sending QA last rites, without using Evolution; this way, I was able to send out quite a few last rites before I went to have my vacations. It actually took me a bit of tinkering because my first try was using bash and sendmail to prepare the messages, and in particular to sign them. Since encoding my name properly is quite hard, I gave up and I now use mutt to send the stuff; unfortunately i was unable to find how to sign the messages with mutt and gpgme; if somebody can help me with that, it’s very welcome.
With the script at hand I then went on checking some of my older bugs to send some of them out; some bugs weren’t really correct before (caused by the older tinderbox attempts, which used --buildpkg) and I fixed them up, others were fixed with time, others were still valid. All the packages that failed to build for whatever reason the past October (or at least, most of those) have been last-rited, masked and ready for removal. There are other packages that have been masked and prepared for removal, for failures to build, QA concerns and other stuff.
Now, since these are last rites for QA reasons, they get a 60-days grace period (I usually just did two months, but since I’m now running it through the script, it’s easier to use a real 60-days time). If the package maintainers, other developers, or users, have interested in keeping these packages alive, they should have enough time to do so. Keeping them broken as they are now, though, is not an option, and just fixing them to build, and keep them rotting forever, is not an option either.
Now, while Samuli and Victor are going through to fix all the possible glibc 2.10 and gcc 4.4 failure for the tree, I’m trying to find the problems that are not related to those, and decide on a number of reasons whether to remove the packages or not. These include, but don’t limit to, build failures not stopping the ebuild, broken dependencies, old ebuild not touched for years (sometimes fixes are made but no major change is present, some of those have to go as well), and a sum of minor QA issues.
Since minor issues are, as the name imply, not big enough to call for a removal of a package, I don’t stop at one or two of those, but when I get a package that fails to build, for whatever reason, and then I find that it doesn’t respect flags, CC, and fails with --as-needed as well, then the package is as good as broken to me, and it’s deemed to go.
At the same time, spending eight months or so being broken, in ~arch, is enough for the package to be deemed broken, even if it works fine in stable. Why this? Because it’ll be keeping other packages from going stable, or it’ll break when they go, so it’s not something ignorable.
The date for the start of the final cleanup is October 8th 2009, that day, about 20 packages will be removed (probably even more); while this is just a minimal part of the tree, that keeps growing and growing with time (I also have quite a few packages to add myself), it is part of the standard maintenance that we have to do to make sure that the tree is healthy.
The added advantage is that the packages that are masked will not be rebuilt repeatedly by the tinderbox in the future, which reduces the amount of work and thus the time needed for a full rebuild (it’s already pretty long as it is running all the testsuites: some take hours to complete, some even freeze in the middle and require manual handling (which is why I won’t be leaving the tinderbox running while I’m in London). And on a related note, glib’s testsuite completely freezes Gentoo/FreeBSD to a stop. Scary!
Good to hear, Diego. The Gentoo tree is just like a real tree – it needs to have the dead branches and rot dealt with so it stays healthy, grows and blossoms. Personally I’d make it 30 days before something is canned – but I understand the need for notification and the chance for people to step up and take over. As the man who killed XMMS, anything you do is fine with me 🙂
Great idea overall.But why not put the packages with objective breakages into an overlay (“gentoo-unmaintained” perhaps) and do it faster, like in 30 days? If its a case of a broken ebuild in ~arch, the broken package could get hard-masked on the overlay, other ebuilds could stay as they are. All that you’d do on that overlay is move packages back into the tree if the problem is fixed, delete the package after a prolonged while, or mask more ebuilds if problems crop up in a formerly stable ebuild before the deletion or fix.Might be the better solution for users than removing packages that still potentially work for them, its more transparent to users, support and random people who run arch that something is amiss, developers won’t have to wait two months at worst…
I was going to request that last rites packages be listed on gentoo.org, I remember they were at one time. Also was going to request that dead packages be moved to an overlay, perhaps called graveyard. Seems Radtoo beat me to it.