Re: Implementing my proposal for the organisation of QA
On Tue, Jan 08, 2002 at 11:00:15PM +0100, Adrian Bunk wrote:
> - fixing bugs
> - send bug reports for uninstallable packages, [ ... ]
> - problems with testing
> - failed builds
I'm sure nobody thinks doing any of the above is a bad thing, but the
above tasks fall under the general label "accommodation for failure".
While these tasks are all necessary evils which I will do my best to
support, I think task number one needs to be an effort to reduce bugs,
failed builds, etc. in the first place.
The model that I am working with in Debian Jr. is to try to find the best
possible people to work with, including some promising new maintainers,
work directly with them via peer review as they build their packages, and
learn together how to build quality in from the beginning. Education is
going to take us much farther than fixing problems after the fact. As
we work our way backwards towards the beginning of the lifecycle of
a package, orders of magnitude less effort are required to build in quality.
Fixing things up after the fact (as poignantly illustrated by the recent
libqt/libpng incident) not only costs the developers far more effort, but
causes much strife in the developer and unstable/testing user community
(not to mention the untold millions of electrons wasted in the fallout on
the mailing lists).
I put my money behind small groups which focus on building quality into
coherent subsets of packages in Debian. But within the Debian Jr.
working group (and now Debian Med, which follows the same model) there
is still a need to focus on each of the tasks you listed, because all
of our volunteers are at varying levels of comptence, the upstream
packages we have to work with are of varying quality, and we are quite
simply never going to be able to spot and fix every problem before it
happens. In the course of pursuing these tasks, we hope to educate the
maintainers involved so that the quality of their packages will continue
to improve, and we'll have fewer "fixups" required afterwards.
To that end, I will commit our group to assisting in all of these areas,
and specifically, will seek volunteers from Debian Jr. to work through
our list of packages and their dependencies, and focus on each of the
tasks Debian QA has listed. We are already taking some effort to do
this, but there is still quite a lot left to do, and not quite enough
people helping out.
It is clear to me that it is not sufficient for us to merely put together
a Debian Jr. task and then walk away from it. We must not only actively
maintain the task and its meta packages, but we need to go beyond this,
look carefully at the quality of the packages our project depends on,
and chase out as many bugs, failed builds, etc. as possible. In the
process, we will communicate directly with many maintainers currently not
directly involved in Debian Jr. and strengthen teamwork with them. In
this way, I hope Debian Jr. will not only make Debian better for children,
but improve the quality of Debian as a whole.
nSLUG http://www.nslug.ns.ca email@example.com
Debian http://www.debian.org firstname.lastname@example.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]