So as I wrote this afternoon, I spent the whole day today between ebuilds and bugzilla. To do what? Well, to scratch a few itches with bugs that were being overlooked for too long.
First, I fixed most of the bugs caused by the new autotools wrappers, leaving open only some that needed some careful checking, and two that were stable requests before killing the old versions. Then I looked for the packages using libtoolize (they should not!), and filed, one by one, bugs for all of them in bugzilla, minus the ones I could fix/cleanup myself, making sure that ~arch at least appeared working.
This accounted for most of the autotools misbehaviours in Portage, and fixed in the mean time an unixODBC bug that was waiting, too. It’s fun to be asked to look after a but you already fixed a few hours before 🙂
But as there are a lot of non addressed issues, still, I looked at another one, the totally broken and QA-violating debug.eclass that causes a lot of debug useflags in packages that shouldn’t have it. The bug is still in the 58K range, which means it’s quite old considering that today I reached quota 160K. The bug basically states that debug.eclass has to be removed because either ineffective or (if you’re lucky) messing with the wrong stuff: debug useflag should enable debug codepaths not debug code generation (-ggdb and no stripping), for those you follow the backtraces guide .
So I’ve replaced debug.eclass with a dummy one that will just whine while the users do an emerge -avuD world, and then opened a bug for all and every ebuild or eclass still inheriting debug.eclass (thanks to compnerd who fixed the main user, gnome2.eclass), fixing the ones missing a maintainer, or maintained by someone I know I can step on the toes of. Soon the problem should be fixed.
So today is a “step over someone else’s toes day”, I think I never committed so much stuff against packages that are not mine, as I’m usually playing it safe with territorial devs, but this hopefully fixed a lot of stuff that wouldn’t have been fixed otherwise.
This leads me to a few considerations over the QA that we had in Gentoo up to now, and I’m not just referring to the current QA project but also to the past. All the developers who ever had the title of “QA lead” had lost themselves writing policies, documentation that is never finished, specifications, and playing with automated QA scans that supposedly found a lot of broken stuff, but mostly focused on dependency errors (which yes, are bad, but are not the only type of QA problems we have, and they are probably reduced quite a bit now). The outcome is that we had no QA up to now that actually fixed something. Yes they filed a bit of bugs, ciaranm found some trouble here and there, but the autotools debacle, that could have been handled in a couple of days if a couple more devs were working on it beside me and Mike (vapier), took three months to come to a decent conclusion, and actually might take a lot more, as I haven’t covered all the packages yet.
This is why I don’t think that a policy-based QA is going to help us. First of all, spb still hasn’t written any EAPI=0 documentation, that was promised to the council the first reunion, now at least three months ago; okay he might have had a lot of stuff to do with his school, the work and whatever, but if you don’t have time, just pass the task on someone else, seems crystal clear to me. The devmanual have been updated only partially, and still contains inconsistencies.. I given up trying to write content for it because my British English is simply fantasy, and thus I have to skip on it. The issue with dependencies on system packages didn’t get any answer to the bug, where a (valid to me) concern was brought on: if you don’t state any system dependency for non-system packages, you get the wrong order for re-emerging packages, how do you solve it? The libexec versus lib/misc debate, also, simply disappeared. Kugelang promised me to consider it the Monday after the last council meeting, but it’s still there; he asked me a few details on Christmas Eve (at 23:30, you don’t expect me to be around, do you?), but we’re still without any solution to that, and everybody do whatever he/she thinks to be correct.
I’m not QA and I don’t want to be called that way, after watching the precedent devs failing in their objectives. I’m a simple developer who wants the stuff fixed, and wants it as soon as the maintainers can provide it, but is not ready to wait indefinitely. If I don’t see debug.eclass gone from every ebuild in a week, I’ll change all the remaining ones myself. if I see some bug caused by the new QA warning of autotools.eclass called without WITH_AUTO{MAKE,CONF} variables set lingering for more than 10 days, I’ll fix it myself. I don’t care if someone wants his packages for himself, if you leave it broken, someone will fix it: me.
You’ll see more noise from me on this front in the future, you’ll see probably more bugs (especially after Robin will finally give us a working bugzilla! YAI FOR ROBIN, HIP HIP, HURRA!), and you’ll see me committing to other people’s packages way more often, because if I find something broken, I’ll just fix it next time, won’t wait for the eternity if the bug is trivial, or is an ebuild misusing my own eclasses (autotools.eclass).
Ryan, I think I’ll mail gentoo-dev tomorrow to remind them of the autofailure guide (again, something I wrote in a day’s worth of spare time, obviously I will never write an entire manual this way, but it does not take that much time to get a summary on how to do something that a lot of devs have no clue about – like rebuilding autotools).
And Jokey, don’t be upset if I replaced your script with a oneliner 🙂 I’m getting used to them so much first of all for autoepatch, but also because I think the best way to find the problems is to look for them with an human eye. Although yes, I wrote a Ruby script to find the use.mask entries that are redundant, and that’s how I fixed all of old PHPs binary flags not to be repeated over every damn profile out there, but it’s not like I didn’t check them myself and didn’t ask Luca which ones were safe to mask and unmask!