So all 3 of the people subscribed to this list have probably heard this
already, but I re-iterate here for those who don't spend their lives
staring at IRC backlogs.
The current QA team is definately short on overall goals. We have a lot
of people that are passionate about QA, and they all do their own thing
to contribute. However I think we can do better.
So step one is listing QA violations. Sure Repoman complains about
most, if not all of them and Mr Bones likes to squish the usurpers that
break dependencies in the tree. However I think some of them just pop
out at people and they have no clue how to fix them, or the fix isn't
easy, or they just don't know how to fix it so they ignore it.
Just as was discussed about making people work on Enterprise Gentoo, we
can't make poeple do QA who don't necessary care about it. And thats
not to say QA isn't important, or whatnot. I think a lot of people view
it as a PITA, and so they ignore any problems.
Step 2 is improving our QA tool. Sven has written Autorepoman. I have
half the code, and partly this mail is to ask Sven to release the other
half. Sven, I'd personally like to work on it, I know you have very
little time, and it may not be the dream tool you meant it to be. If
necessarily I may make an attempt to write my own tool, if you are wary
about releasing the code, although I'd prefer not to throw away code
you've already written.
The current repoman sucks, is not extensible and worse, is within
portage itself, bound to their release cycle, which in the past has been
pretty slow ( although it should be speeding up ). For now I volunteer
maintainership of the tool, primarily because in the 2.1 branch there
are a lot of changes and whomever maintains it will probably have to
have close ties with the portage team. The main problem with taking
repoman out of portage and into QA maintainership is that when devs use
~arch versions of portage, Repoman tends to get castrated by the API
Step 3: Posting QA violations publically. By Publically, I mean to the
world. We would need a box to run the tool on and generate a webpage,
much like autorepoman does now ( although hopefully a bit prettier ).
Someone also suggested an internal ( lets it be dev-only or qa-only )
pig tree, that also lists who last touched each file that had a QA
violation. This is a toss up but may prove useful ( or foolhardy ) to keep.
Step 4: Having a tool to track QA violations, per-dev, per-herd,
per-project. I was thinking a record similar to like a GLSA, where we
simply record who/what/where/when/why/how and store it somewhere. Then
we can run reports on what projects sucked, what projects were good,
what devs suck, what devs were good, herds..etc...
Step 5: Helping devs help themselves. Most of the things in Repoman's
complaint list are automagically fixable. Repoman complains that the
ebuild is in cvs but the digest isn't, add the digest to cvs
automagically...or ebuild is missing HOMEPAGE, add HOMEPAGE="none", or
whatnot. Automation, This goes hand in hand with super sekrit goal #6
Step 6: QA must be Unobtrusive. We were joking in IRC that the title
should be "QA we take the fun out of developing." And while funny,
thats a bad attitude to have towards the situation. To that end we need
to be unobtrusive to developers to gain their support of QA. We need to
make good QA easy for devs to accomplish so they aren't hounded by
errors every time they commit and say fuck it QA sucks. I think a lot
of that has to do with tools that do the work for them, and while some
may argue that this will allow bad habits ( Oh I didn't know X was a QA
violation because repoman magically fixed it for me every time ), I
think partly #1 will mitigate that issue.
Lastly of course, we need to come up with a system of punishment to go
along with #4, in case a dev/project/herd is having issues keeping up
with QA. This is the most difficult issue IMHO, mostly because there
arne't a lot of avenues to go down, and DevRel seems quite stagnant
recently, although that mail on -dev from fmccor looks promising :)
Specifically we probably need some kind of group to review QA records
and enforce said punishments themselves, or through devrel as a liason
Lots of stuff, I know solar had some ideas relating to arch teams, I've
cc'd a few people because I am not sure if they are subscribed ( sorry
if I ended up sending duplicate mails to you three ).
-Alec Warner (antarus)
email@example.com mailing list