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