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.
