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!