While Donnie thinks about improving Gentoo management, I already said that I’m going to keep myself to the technical side of the fence, working on improving Gentoo’s technical quality, which I find somehow lacking, and not because of a lack of management. Maybe just for the other way around, there are too many people trying to get the management part working and they fail to see that there is a dire need for technical skills work.
Today I started (not to willingly to be honest) the day with a mail from Alexander E. Patrakov who CCed me on a Debian bug about GCC 4.4 miscompilation; while Ryan is the one who has been working on GCC 4.4, I guessed I could do what Alexander suggested, since I got the tinderbox set up.
To do this I simply set up one more check in my bashrc’s
src_unpack hook, and used the tinderboxing script that Zac provided me with to run ebuild/unpack phase for all the latest versions of all packages. Now, besides the fact that this has the nice side effect of downloading the sources even of the stuff that was missing up to now, I found some things that I really wouldn’t have expected to.
econf (and thus
./configure during unpack phase). Which is bad in so many ways, because it disallows to fiddle with the configure in hook, and in my case wastes time when doing just a search. What worries me, though, is not this mistake, but rather the fact that one of the two ebuilds with it I found up to now went stable a few days ago!
Now, I can understand that arch teams are probably swamped with requests, but it would be nice if such obvious mistakes in ebuild were spotted before the stuff goes stable. For instance, I like the way Ferris always nitpicks on the ebuilds, including the test suites, since it actually allows to spot things that might have escaped the maintainer, who’s likely used to the thing, or has a setup where the thing works already. I don’t care if it stops my stable requests for a few days or even months, but if there is a problem I missed, I like to know that beforehand.
So please, you should refuse stable if something is not right with an ebuild, and even if it’s not a regression, for trivial stuff like that you should refuse it without hesitation.
Of course, sometimes it’s hard to notice such stuff: most ATs only look inside the ebuild if something goes wrong. So, as long as there aren’t any QA warnings from repoman, econf-in-unpack goes unnoticed.Even so, as an AT you sometimes get very nasty reactions if you point out QA warnings (especially so if they were introduced only recently, like No-explicit-RDEPEND). While I can understand that nobody likes shortcomings in their work pointed out, it really makes AT newcomers weary of telling people that repoman is unhappy.On top of that, AT work is complex (and sometimes complicated) as it is, since just about no package maintainer supplies a test plan (there are glorious exceptions, like the emacs guys and a few individuals like Petteri). So doing QA work on top of trying to find out how to test say, sys-cluster/torque, is asking a bit much of the AT teams (especially if they consist of one person or even less).That said, if I see a QA warning from repoman which smacks badly and is in the to-be-stabilized ebuild, I say so on the bug. In severe cases, I don’t stabilize. Also, I have a memory of such stuff and if sys-foo/barbaz consistently comes up with failing dodoc calls, I eventually refuse stabiliziation in the hope the maintainer will get his/her act together.OTOH, I think such things should get caught even before stuff is keyworded. But that’s probably just me.
Indeed the econf call outside of src_compile should really produce a warning, I’ll see for that to be added.Not sure if it’s easily doable in repoman though. As for what concerns ATs testing this, I’m actually more concerned about full developers.Sure you can trust the ATs to test that software works, but you should at least peek a look at the ebuild, it’s not like it’s tremendously long the one I fixed, or that it wasn’t easy to spot it.