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

Reviving Debian QA



Hi,

[ Mailing to Debian Development and Debian QA, please send replies
  *only* to Debian QA <debian-qa@lists.debian.org> ]

as many people out here already know debian-qa has been quite quiet
lately.

What is debian-qa and is it eatable?

  QA stands for Quality Assurance and is intended to keep the quality
  of the distribution as high as it should be.  At the moment there is
  no real Quality Assurance for Debian.  This is mainly due to people
  who had initiated QA found themselves burried in other important
  (Debian-related) stuff.

Do we need Quality Assurance?

  With the growing number of developers working on Debian (>500
  registrated developers at the moment) QA is urgently needed.  It is
  very interesting (and usually not the case) that the quality of
  Debian is still that high.  With companies having more than 500
  concurrent developers ... I don't want to think about this...

  Although we have strict rules (Policy) that defines requirements for
  packages there is still missing a "department" which assures that
  every package is packaged well and integrates in the system nicely.

  To be honest, there are still *lots* of packages not using all the
  suggested tools and integration (menu files, dwww files, doc-base
  files, alternatives, proper suggests/recommends, proper priorities
  etc.)

Now that several new maintainers mentioned QA or QA-like work in their
new-maintainers application I'd like to invite people to work on QA
for Debian.  This doesn't need a fully fledged developer but also
people who can only spend a few hours on Debian.

I would appreciate if some people, both new and regular developers,
would decide to work on QA for Debian GNU.  Please look at the
following - incomplete - list of things which fall into the field of
duty for the QA team:

 . Check old bugs - and work on them

 . Check packages with lots of bugs - and work on them

 . Check if all packages providing user programs (X11 or not) come
   with menu files

   - Such packages have to call update-menus in their postinst and
     prerm scripts

 . Check if all packages that provide documentation register it for
   dwww, doc-base or whatever

 . Check if packages are policy conforming

 . Add documentation where it is needed - there are lots of places
   where documentation is missing.

 . Detect orphaned packages and take care of them

 . Check if packages still work - especially old ones

 . Check if priorities, recommends, suggests and depends are used
   properly

 . Check if packages are linked against proper libraries, maybe check
   if they would work with newer stable ones (especially for Gtk-based
   programs) as well

 . Watch out for new versions of software and notify maintainers if
   needed.

If you find packages which lack support for some of the features
mentioned above the proper action would be to file a wishlist bug
report.  The bug report has to point to accurate documentation or
better include a description of the missing feature and a description
how to solve this.  It would be best if the report would include a
proper patch/menu file/doc file etc.

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.


Reply to: