Debian QA Policy Draft

[Martin Schulze <joey@finlandia.Infodrom.North.DE>]

This is what Vincent Renardias wrote about Debian QA:

========================================================================
                                            -- Debian QA Policy Draft --

                                  Vincent Renardias <vincent@debian.org>
                                                          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.