This is what Vincent Renardias wrote about Debian QA:
========================================================================
-- Debian QA Policy Draft --
Vincent Renardias <[EMAIL PROTECTED]>
Feb. 21th 1997
Aim:
----
Try to improve the overall quality of the Debian GNU/Linux
distribution.
Facts:
------
. Some packages appear to be orphaned or not maintained enough.
. Some outstanding and easy to fix bugs are still pending after
months.
. There's a need to check continuously the distribution's
stability/quality.
. Need to have a spool of maintainers to take care of orphaned
packages.
Foreword:
---------
Sofware QA rules already exist (ISO 9000, etc, ...), but I think
they're not really adapted to Debian, since unpayed volunteers can't
accept the same "pressure" than corporate developpers. Moreover,
developping for Debian must remain fun (and not become a pain
because of a QA group barking at every developper ;). Also, the DQAG
(Debian Quality Assurance Group) should not reduce too much the
development speed of Debian.
For now, we'll use some 'soft' QA rules, just to make sure the
minimum expected amount of quality is reached and critical bugs are
fixed. If everything goes well and the maintainers are happy with
the work the the DQAG, then more restrictive rules will be used.
Since we do not know yet how efficient/inefficient the DQAG work
will be (and how it will be welcomed by the maintainers), I propose
to set it up in 3 steps:
. 1st step will be applied as soon as the DQAG work begins.
. 2nd step will start after 2 or 3 months, when:
- the DQAG will have enough volunteers.
- maintainers will be used to work in collaboration with the DQAG.
. 3rd step will eventually be applied, after discussion/agreement on
how to implement it.
Maintainers:
------------
How much work is expected from the maintainers?
. Fix the 'cosmetic' bugs within 1 month.
. Upgrade a package to the new upstream version within 2 months.
. *Try* to fix the other bugs within 3 months.
. Email the QDAG if they 'give up' on a bug.
DQAG Evolution:
---------------
Re-upload the known orphaned packages with the 'Maintainer' field
set to: "Orphaned Package <debian-qa@lists.debian.org>"
Send an email to all the developpers listed in 'indices/Maintainers'
and ask them if they're still maintaining their packages (Already
proposed as a "developper ping").
Every Debian maintainer/user is encouraged to subscribe to the DQAG
mailing list and become an active DQAG member.
Check distribution completness (wrt. dependencies) after each
dinstall run. (for stable and unstable, with and without contrib &
non-free, and for each architecture)
Check bogus/weird/outdated dependancies:
. packages depending on (say) libc_5.0.9 (need to recompile to
check if it still works with libc.5.4 (and soon libc.6))
. package depending on something that apparently has nothing to do
with it.
Scan the bug tracking system for bugs older than 3 months that are
fixable and provide patches to the debian maintainers (and
eventually also to the upstream maintainers).
Scan c.o.l.a. & sunsite's new entries, and open bugs on concerned
packages asking for upstream upgrade. (Yet another way to see if
maintainers take care of their packages ;)
Regards,
Joey
--
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum
Please always Cc to me when replying to me on the lists.
