My thoughts about QA and documentation

So, this was discussed today in #gentoo-dev quickly, and I think it make sense to report it here, so at least I can make sure to clear up my own mind writing my thoughts on this matter, always discussed and rarely realised: Quality Assurance.

Let’s start to say that Quality Assurance is a subjective concept. Everybody has a different view of the QA problems, and of the QA process itself. There is who prefers passive QA and who prefers active QA. Different kind of QA process can be used on different kind of projects, and every project should have its own set of QA rules.

There’s no panacea for QA, one cannot simply decide a set of rule and they will be the ones for every project of the world. Things have to be tailored correctly.

What I think of QA in Gentoo is pretty complex. I think we really need a QA team, but how to establish it it’s difficult. There’s no written policy, and in a lot of cases what passes as policy “because it was always done this way” is just a subjective way used by the more vocal part of our developers, that often is the also the older part of our developers, that not always is right.

So, I disagree with trying to enforce QA from day one after establishing rules. We have an example of the past were some developer involved in QA (I try not to say names) asked me personally to convert the || ( .. ) dependency for KDE ebuilds into a range-based dependency … (no comment on this please).

What I think should be done would be to start creating some policies, so that no feature is lost for both developers and users, and that complexity doesn’t make writing ebuild more difficult than it is (not too much at least), and make sure that we accept them for the most part. When there’s disagreement between a developer and QA team, and the developer has reasons (even debatable from the QA team), no one should force the decision until this can be decided. It’s not useful to apply a change that might break stuff for users, and we should think that the maintainer of an ebuild knows it better than anyone in the QA team, as that’s what a maintainer is supposed to do (or we wouldn’t need them, don’t you think that?).

The other big problem is deciding who should make these rules and who should apply them. If it’s the same people it’s likely to be abused on the long term. Tell “the people who wants to join the QA project” doesn’t help, as they might not know our technical limitations either (see above), plus I’ve seen people from all the three package managers that work with ebuilds not understanding how =foo-bar/baz-1.3* worked…

At the end, just screaming “we need more QA” won’t help. Also because QA project should make sure that their rules don’t end up hindering work on any of our current projects, by forcing people on standard tracks that aren’t followed by things like Gentoo/Alt, Hardened or Embedded projects.

On documentation instead, I want to dedicate a single paragraph, that tries to summarise what I said some days ago about the devwiki (that seems to still exist, although I actually forgot about it after last year). I don’t see the usefulness in a private wiki (without public reading) to store documentation. I can understand using it to add reserved information like ports and configuration settings for infra’s servers, but documentation for other projects? Infra is basically the only project that shouldn’t interface with the users, and that has information that shouldn’t be read by them, but for any other project, documentation should be public. You cannot expect users to help, to know the documentation, if they can’t reach them. At the same time, I think just a fraction of our developers have access to the devwiki, and even who has it (like me) might simply forget its existence when they don’t use it for some many months. You cannot look up documentation you don’t know it’s there.

Now to complete my view over the “hot” topics of this Gentoo, I’d like to point to this blog from Clint Adams appeared on Planet Debian and the entry he points to, to let people think about the interminable discussions on our mailing lists.

And now, if the coughs don’t kill me, I’d return to my xine hacking …

My thoughts on stable markings

Sounds like today I have to do another post talking about facts currently in discussion, although I usually try to avoid this kind of posts, focusing more on technicalities, or discussions about Freedom, or in general talking of things being done rather than being discussed.

So, there’s a lot of fuzz about stable markings lately, especially since after x86 arch team was created also x86 stable markings take their time, while before they were done when the developers felt that way.

This of course slowed down the x86 stable tree, but at the same time now we have a stable tree that is almost really “stable”. Unfortunately, although it started more quickly, now the stable marking rate is slowing down, not only for x86 but also for amd64.

The reasons? Too many people not caring for the stable tree and deciding to use ~arch directly, developers who don’t have stable chroots, and so it’s a domino effect: the less the stable tree is used, the less the stable markings can be done.

Myself, I actually started having a stable chroot at the time, but then I had to drop it, for the simple reason that I didn’t have enough time to keep it updated as my whole system.

So, although I don’t pretend to know an answer to this, I have a suggestion: ATs, when you become devs (because most of you will become), don’t drop the stable systems, don’t drop stable chroots, but rather help stable marking stuff. For AMD64 in particular I see a really bad trend :“( the stable markings are almost getting an halt lately… while last year it was the first arch marking stable.

Myself, I’ve decided that if I’m able to upgrade the CPU of this box (to an Athlon 64 x2 4600+, that has the not-so-high price of €245, plus €89 for a 1GB ram stick), or rather if I’m able to get another job to pay for that, as I’m going to upgrade the CPU for sure if I get enough money, I’ll be maintaining an amd64 stable chroot once again, so that at least the software I maintain usually I’ll be able to test and mark stable when everyone else can’t.

Anyway, I hope this is the last post I do following a discussion in gentoo-dev, as it’s also boring for me, as well as for who don’t read gentoo-dev :P