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

Bits from the Darmstadt QA team meeting

Hi all, 

We had a very productive QA Team Meeting in Darmstadt from the 9th to
the 11th of September[1].  The participants had a lot of fruitful
discussions during the weekend.  Besides minor bits that "just
happened", the following major issues progressed significantly:
 * Mass package removal
   Frank Lichtenheld and Marc Brockschmidt decided to wade through the
   lists of very old and unused packages to identify those that can be
   removed from the archive. The criteria are simple: No maintainer upload
   in the last two years and only few users (according to popcon).  Other
   things, like rc-bugginess, the availability of alternatives, and the
   status of upstream development are also taken into account.

   Though 30 bugs were filed in Darmstadt, the bug filing continues.  The
   new usertags feature of the BTS is used to track the bugs[2].

   Besides tracking old unused packages, David Moreno Garza started
   closing[3] old ITPs and RFP.

 * Collaborative maintenance by external contributors
   Alexis Sukrieh, Mohammed Adnène Trojette, and Raphael Hertzog presented
   their ideas to improve the quality of orphaned packages that still have

   The basic idea is to set up a common source control repository where
   non-developers can commit new versions and packaging improvements.
   Official developers can get an overview of changed packages, review the
   changes and upload them to the archive.

   Discussing this during and after the talk the participants/we came to
   the conclusion that this system is probably not ideal for the needs of
   orphaned packages, but could greatly improve the sponsoring process for
   prospective developers.

 * QA and Security (open discussion)
   The recent security advisories showed some fundamental problems with
   the security support for mozilla. If only a few patches are applied,
   the package often becomes unstable. If we agree to use the newer
   upstream version, we can't bump the version number, as this would
   require a rebuild of plugins and extensions, which are also used by

   This problem will become even more complex in etch, when the joint
   efforts of the Gnome and KDE teams (in form of freedesktop.org specs)
   will lead to more inter-dependencies between large core parts of our

   The problems of security support show that we need to work out a way to
   make packages more independent of each other, even if we want them to
   use each other's functions. The solutions that were proposed include
   more use of plugin systems, which make components optional, splitting
   out functions in libraries and symbol-versioning for core libraries.

   As most maintainers have no experience with handling security bugs in
   their packages, we will create "debian-security-mentors", where
   experienced QA people will help to sort out the bug fixing and
   coordination with upstream and the security team. It is not decided yet
   whether this will be a mailing list, an IRC channel, etc., though.

Besides these subjects, there were several talks on QA-related subjects:

 * Internals of the Package Tracking System
   Raphael Hertzog gave a short introduction on the internals of Debian's
   Package Tracking System. He explained how the single parts work
   together and where one could begin to add new parts. He also pointed us
   to the existing Todo list.

   The discussion following his presentation lead to some nice ideas for
   further improvements. One of these, adding information from
   volatile.debian.net and secure-testing.debian.net to the package
   overview, is currently being implemented.

 * New Maintainers - New help or new problems?
   Marc Brockschmidt provided an analysis of the current New Maintainer
   process from a Quality Assurance point of view and presented some
   possible improvements.

   He explained that the current process has two main problems, one being
   the enormous waste of time invested into writing answers to a
   pre-defined set of questions, the other being the fact that these
   questions only filter for people that are good at answering questions.

   The proposed improvements were all based on the idea of a more
   individual, task-based process. About two thirds of the P&P questions
   could be replaced by standard QA tasks like NMUing, bug triage and WNPP
   clean-ups.  Likewise, a big chunk of the T&S questions could be
   replaced by NMUs and package mainenance.

 * Lintian
   Frank Lichtenheld talked about lintian's history, its structure and the
   idea behind its architecture. He showed how lintian unpacks packages,
   collects general data and then runs tests.

   He also presented plans for future lintian development. The old model
   of E and W types of tests will be replaced by a more fine-grained
   system using two characters, one to specify the impact of a problem,
   one saying how probable it is that the test has false positives. Frank
   also explained that the current laboratory implementation has many
   problems and will be replaced in the future.

   The interaction with other package checkers that are usually used
   before an upload (like linda, debdiff and piuparts) should be improved
   in the future, for example by providing a common interface to all these

 * Autotools-related build failures
   Sam Hocevar presented a short introduction into the insanity the
   autotools are. He explained how the single tools work together, which
   files are generated and what they're used for.
   The most common problems, as well as some solutions were discussed. Sam
   pointed out why some of them (like bootstrapping the complete autotool
   stuff in the build process) lead to additional problems and presented
   alternative solutions, like shipping a freshly bootstrapped set of
   files in the .diff.gz.

   The role of the upstream maintainer was also emphasized, as they can
   save all packagers a lot of work if they distribute their software
   bootstrapped with correctly used, recent versions of the autotools.

 * Managing breakage in the Debian-Installer
   Frans Pop gave an interesting talk about breakage in the development
   version of debian-installer and how the developers deal with this. 

   He gave an overview of what causes breakage in d-i and why it is almost
   impossible to avoid it in a lot of cases, mainly because most causes
   are external to the team. Users are kept informed about the status of
   the daily builds of the installer through a special wiki page.

   The main strategy is to detect breakage early. The installer is built
   daily for all architectures and a log summary page is used to check for
   breakage there. Also, Joey Hess has set up a network of machines for
   different architectures running automated installations; the results
   from these can also be viewed from a summary page.  Another valuable
   source of information are the installation reports sent in by users.

Slides and videos to all talks are availible in the debian-meetings archive.
See [4] for more information. 

Last not least we agreed on adding three more people to the QA unix group,
Christoph Berg, Marc 'HE' Brockschmidt and Martin Zobel-Helas.

Debian QA Group

[1] http://wiki.debian.org/qa.debian.org

[2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=proposed-orphan,proposed-r

[3] http://www.damog.net/index.php?option=com_content&task=view&id=177

[4] http://lists.debian.org/debian-devel-announce/2005/09/msg00016.html

Attachment: signature.asc
Description: Digital signature

Reply to: