[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Implementing my proposal for the organisation of QA


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).

- 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
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

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

  * maintain the WNPP bugs and the orphaned packages

<--  snip  -->

I'm happy if you send me feedback.


[1] http://qa.debian.org/debcheck.php

Reply to: