|
|
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:
|
|
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=E8ne Trojette, and Raphael Hertzog presented
their ideas to improve the quality of orphaned packages that still have
users.
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
konqueror.
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
distribution.
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
programs.
* 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.
Cheers,
Andi
Debian QA Group
[1] http://wiki.debian.org/qa.debian.org
[2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tagproposed-orphan,prop=
osed-r
emoval;usersdebian-qa@lists.debian.org;nam0Proposals;pri0tag:propo=
sed-remova
l,proposed-orphan;ttl0Proposed%20to%20be%20removed,Proposed%20to%20be%20=
orphan
ed;nam1Status;pri1severity:serious,normal;ttl1No%20answer%20yet,ac=
knowledged
;nam2Progress;pri2pending:pending,done;ttl2In%20progress,Solved
[3] http://www.damog.net/index.php?optioncom_content&taskview&id177
[4] http://lists.debian.org/debian-devel-announce/2005/09/msg00016.html
|
