Implementing my proposal for the organisation of QA
Hi,
over one month ago I suggested the following:
<-- snip -->
Currently QA works the way that people find something to do themselves and
everyone works for himself at the tasks he sees. I propose to change this
to define tasks of QA work with usually 2-3 people responsible for each
area. These people responsible can do the work either themselves or by
organizing that it gets done (e.g. by organizing bug-squashing parties).
advantages:
- it's clear who's responsible for what
- it's more easy to find other people helping (I remember that sometimes
people come that say they are interested in QA work) when you can say
"We are looking for someone to help with xyz."
<-- snip -->
It should be clear that noone should be prevented from helping in an area
he's interested to help, heshould only inform the person responsible
before doing so to avoid confusion or doubled work.
I'd like to get this running, so I'd like you to tell me within one week:
- if you seriously object against it
- to tell your comments about the suggested tasks below
If there are no objections against the procedure will be as follows:
0. make the final list of tasks (we are currently starting this - see
below)
1. look for persons responsible for the tasks
2. announce it on debian-devel-announce
3. if people are needed in some of the tasks, search on debian-devel for
volunteers
The tasks are currently the same as in my first proposal. After a mail
discussion I agreed that the "failed builds" task is something the porters
are responsible for but since too few people going through the build logs
are a serious problem at least on m68k and arm I think it's better to
establish this task. I don't think it's very fruitful to discuss if
everything of this list belongs strictly to QA - the only important thing
is that the work gets done.
<-- snip -->
A first proposal for tasks:
- fixing bugs
* try to fix bugs (especially RC bugs (but not limited to RC bugs!))
e.g. via bug-sqaushing parties
* find MIA maintainers (could be separated out, but my experience is
that you find most MIA maintainers when going through bugs)
- send bug reports for uninstallable packages, unsatisfied
recommends/suggests and priority problems in unstable
* the problems are listed at [1]
- problems with testing
* e.g. find problems why packages don't go into testing
(there are sometimes long dependencies that prevent a package from
getting into testing; it seems that some big library updates are
nearly impossible without manual interaction)
- failed builds
* on some archs there aren't enough people to go through all logs of
failed builds to check whether they are problems in the autobuilder or
to send bug reports
- WNPP
* maintain the WNPP bugs and the orphaned packages
<-- snip -->
I'm happy if you send me feedback.
cu
Adrian
[1] http://qa.debian.org/debcheck.php
Reply to: