Re: Implementing my proposal for the organisation of QA
Le Tue, Jan 08, 2002 at 11:00:15PM +0100, Adrian Bunk écrivait:
> 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).
Nobody can have anything against something like that. However, it's not
sure that it can work. We tried to distribute the work when we created a
QA committe and the task stuff on qa.debian.org. However it never really
worked ... partly because the QA committee was ineffective but also
because contributors don't really work in the way we're trying to
push them.
I believe that's it's not possible to tell people what to do. Having a
single responsible is not enough. People get busy all the time, they
go away, they come back, they have a few hours available from time to
time but they can't plan it in advance. While we do expect from
maintainer to make the necessary efforts to keep the package in shape,
it doesn't work exactly in the same way for the QA stuff since you don't
get as many credit as the maintainer can get, and as such you don't have
any recognized responsibility.
You may try to overcome those difficulties. I'd like you to succeed, but
I think that it's better to try to catch the problem at their roots.
And that's what I'm partly trying to do with the « Package Tracking
System » for which I asked some input here (but I didn't get many
as of today). We have to create the conditions that let much more people
follow and cooperate so that a package can't be forgotten, so that
even difficult bugs have more chance to be dealt by the little
community around the package. We have to let more people feel a bit
responsible of the state of the package.
> - if you seriously object against it
No. But see before for my remarks.
> - send bug reports for uninstallable packages, unsatisfied
> recommends/suggests and priority problems in unstable
> * the problems are listed at [1]
More than sending bug reports should be done. For example, the priority
problem get solved by updating the override file on the mirror. And for
that you'd better provide a patch to the ftpmasters. And then priority
should be updated in the package ...
> - 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)
A warning system would be cool. If your package doesn't go in after the
usual delay, inform the maintainer why it didn't go in.
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: