Re: Release Team Meeting results (the Juelich Edition)
On Sat, Jun 16, 2007 at 01:19:41AM +0200, Andreas Barth wrote:
> * Quality Assurance (QA) checks on the archive were started very late in
> the cycle. They were very useful, but the timing was very unfortunate.
> We want to encourage all interested parties to start their QA checks as
> early as possible and will try to support those by making them a release
> goal. Regular rebuilds, upgrade tests for standard configurations and
> similiar checks improve Debian's quality!
Most QA checks need to be performed at a time testing is quiet to be
feasible and/or useful. Otherwise we get result which are either
unreproducible, already known or transitory, and we miss bugs that will
be introduced later.
As it happens, I have conduced QA checks from Sarge periodically during all
the time of developement of the distribution:
1) Some unsafe rpaths have been introduced very close to the freeze.
2) Conffiles handling depended on dpkg behaviour which changed late
in the cycle, invalidating a lot of proposed fix.
3) Some transitions finished nearly at freeze time (python2.4, gcc-4.1).
4) We needed to improve our QA tools to handle the new issues that came up
(e.g. The X transition)
5) Upgrade test performed too much time before the release are
useless and somewhat harmful: they report problems one will never met
with the final release and miss the one we will really hit.
6) Occasional packages uninstallable in testing (through forcage)
automatically break the tests.
I understand the wish of a short freeze, but QA need to happen on the
packages we ship, not with the package that happened to be in the
archive at the time QA occured. That is why we are Debian after all.
One way to lessen the problem would be not to migrate to testing
packages unless they pass some minimal QA test. But this would make
transitions more painful without significantly reduce the need for
late QA work.
Let say I propose as a release goal that no packages will prompt for
config files changes during upgrade unless the users manually changed
the config files themselves. Would you accept it ? We do have the
capability to report all such issues. Do we have the capability to fix
Imagine a large red swirl here.