This Time Self-Hosted
dark mode light mode Search

My little non-QA outcome

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!

Comments 17
  1. Woah, looks like we have a very upsetDiego here.Then again I approve of the attitude:”Someone has to do it, and apparentlythat someone is me, so I may as well get over and done with it.”I guess at the end of it QA, like security,is not so much a policy, than it is process. The policy may be useful but other work has to be done.

  2. First of all, spb still hasn’t written any EAPI=0 documentationIf you’re going to say such things, at least check your facts first. Thanks.

  3. spb, did you complete the documentation and announce it? If you didn’t, you didn’t write any EAPI=0 documentation, but only some draft of it.

  4. I think you’ll find that spb has in fact written rather a lot of the EAPI 0 specification. Whether or not it is a draft, it has still been written, and your personal agenda doesn’t change that.Now, I realise you’re feeling proud of yourself because you just pulled off your first large scale job, but in the grand scheme of things all you did was nuke one very easy to detect inherit — and your replacement doesn’t even solve the problem at hand. Compare that to the amount of work that’s gone into pretty much any other full tree change (think `use` or the utf-8 stuff) and suddenly what you’ve done doesn’t seem very significant. Certainly not cause for the wang waving “ooh spb sucks” exercise that was the above post — he is working on something that *can’t* be done by a trained monkey (or, by your own admission, yourself), and that is thus incompatible with your highly offensive “ooh, I’m in the Council, and I demand you give it to be my yesterday!” attitude.In the mean time, I am waiting for someone to crucify you for a) violating policy by carrying out a tree wide change without appropriate consultation, and b) making a ‘QA change’ that has nothing to do with QA policy. Because, you know, that’s how things work in Gentoo…

  5. Too bad that what people like me and Mike (vapier) do is what ends up in the tree, while you’re still playing with shiny toys.Sure, there are more complex matters, but that does not excuse anyone from fixing the less complex matters that still breaks or pollutes the system.Sure, the inherit was easy to detect, but then why it took two years for someone to take care of it?And don’t try to play the idiot with me, you know perfectly well that this is not my first large-scale intervent on the tree, and I never broke anything by doing my changes.Now, would users be more interested in having the tree that actually get fixed, or in writing shiny toys and documentation that still is not ready?

  6. For you to have actually fixed it, you would have needed to come up with a solution that solves what the original eclass was being used to do. You didn’t fix it, you removed it without providing a replacement. The entire reason that that ugly hack was still in the tree was because no-one had come up with a viable alternative.

  7. No, I gave the alternative: a guide so users knows how to do the proper thing to get a debug build, something that noone else considered (maybe because it wasn’t a shiny tool but something that was useful to users?).Sure it’s not as practical as having a magic method to handle it, but debug.eclass was broken anyway, and this restores the proper handling of debug features.Actually, if I am the one with an agenda (of course I have one: improve the portage tree), you have so many agendas you could be the Halifax organizer.Although you seem to give your best to try to prove me wrong… not sure how much good is that going to do for your agendas, if I actually do something for the users, eh?

  8. As a user *cheer* Diego. You go!Ultimately QA is finding problems and then fixing those problems. Everything else is hand waving. QA is everybody’s commitment to doing the best job possible.A Software developer, for 20 years and counting…

  9. You seem to have the meanings of ‘write’ and ‘release’ confused. Just because you haven’t seen it does not mean that I haven’t written any of it.

  10. Stepped on a few toes, indeed.Eccelente.There is, by the way, not very much wrong with your english. You use strange words sometimes and you occasionally mess up sentence structure but that’s about normal for a non-native speaker.Oh, spb (whoever you are): He hasn’t confused “written” and “released”. If it’s written and not released it’s still not done. The implication is very clear and only a poor understanding of the english language or a bad conscience can excuse you. Which is it?(By the way, that’s a rethorical question, in case you didn’t get it.)Ciaran (in case you read this, this late): I think I’m one of the few users who was sad to see you leave so I won’t flame you… this time. I do think you’re out of line, though.

  11. “First of all, spb still hasn’t written any EAPI=0 documentation”That statement is clearly false. He has written rather a lot of EAPI documentation. Diego just hasn’t bothered to look at it.”The outcome is that we had no QA up to now that actually fixed something.”And you say *I*’m out of line? That statement is dismissing all the work done by dozens of people all of whom have put far more time into things and with far better results than one tiny little poorly implemented eclass removal.

  12. That would consist of? Ignoring a bug for two years? Ignoring treewide breakage by autotools for at least three months?Sure people put far more _time_ into things… but I don’t see any better result, really.If the autotools breakage wasn’t _that_ spread, I’d rather say it’s because autotools.eclass (that you also dismissed as an hack) was able to cover for most cases.

  13. Or maybe QA were busy working on other things. You may not have noticed, what with your head where it is and, but there have been lots of far larger fixes in the past. Just because a couple of your own pet minor peeves didn’t get fixed by someone else does not mean that QA were doing nothing at all; rather, it means they were fixing other people’s pet major peeves.And yes, I dismissed autotools.eclass as a hack when it wasn’t handling WANT_ dependencies properly. The whole “you still need to specify deps manually” thing you did originally was horrible.In the mean time, what you did was:* Hideously break an eclass, in blatant violation of policy, in such a way that end users would get highly screwed over without helping fix the actual problem. This commit was such a screwup that it had to be reverted by a member of the QA team.* Pull in a whole load of people to help fix the worse mess you just created.* Go around saying how clever you are and how everyone else sucks.Most people, when they screw up that badly, have the good sense to apologise and offer their resignation. The last person to screw up an eclass as badly as you did was Chris White, and you know what happened there. You, on the other hand, have the bold-faced audacity to claim that a) you were doing a good thing and that b) no-one else ever does any work.

  14. Now of course if you don’t count that the same ewarn was used to deprecate gcc.eclass by Mike, and that I didn’t break anything (maybe I did for your users, if you wanted to make them break), no Portage users had any problem, but just a minor quantity of ewarns (yes, minor, never more than 20, unless you had an overlay, which means you’re not supported).And the reason why _antarus_ reverted it, is because I left him to, _if he was going to act on it_.Wonder what, you’re the only one thinking that this is not fixing stuff, oh sorry, you and spb. And wonder what else, you’re trying just to try to find me wrong, but you cannot because I’m not on this.

  15. Ciaran: I said you were out of line so I believe that comment is directed at me.I wasn’t referring to the issue at hand. You figure it out; you’re clever enough to do that…

  16. Oh, ciaranm, you are so smart. 😛 How about that you finally fork w/ spb and stop polluting the air here? Just about everyone has had enough of your smart alec bullshit… Oh, and feel tree to take the whitespace QA with you, no-one will miss it.

  17. I reverted the change because I found the number of ewarns to be in bad taste. Ryan Hill actaully reverted it first. And your above statement is false, it was reverted by Ryan and then by myself, neither of which are members of QA.I spoke to Diego about reverting and he, Ryan, myself, Beu, and probably a few others I’m forgetting, fixed the tree such that the ewarn would make sense again (for overlay users, or anyone silly enough to try inheriting from the dead eclass).At the end of the day we got a lot of work done and I’m proud of the outcome, although not so much the discussion that was had prior to the reverting ;)To comment on the QA stuff, there are QA members working on stuff. Not as much as Diego would like, I’m sure, and certainly not as much as I’d like. But in the end the fault would be mine (as I haven’t done much lately to help). I see Mr_Bones still harass’s people, Tove still fixes stuff, Jakub still does tracker bugs, and Kugelfang still fixes random stuff that he finds wrong.I can’t say it’s a team effort (everyone is kind of working on what they enjoy) but that is the core of what Gentoo work is.

Leave a Reply to FlameeyesCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.