Hi guys,
For the freeze to work well, there are two separate QA tasks that need
to be done: (1) fixing RC bugs before the packages they apply to freeze,
and (2) improving packages' policy compliance and overall consistency.
I suspect it might be an idea for people to choose which of those tasks
they're going to focus on and stick with it for extended periods.
The first team will need to:
* ensure packages port correctly
* ensure they don't crash the system or delete files or whatever
* have any known security problems fixed
* make sure packages are usable
* make sure they comply with all the really important policy guidelines
The second team will hopefully:
* file bugs about integration issues (package doesn't provide
dhelp/doc-base hooks, or doesn't have menu items where it should,
or whatever)
* look for normal and wishlist bugs (both in the BTS and that testers
might notice) and submit patches for them
* check for lintian warnings and provide patches to fix them too
The way the freeze'll be happening is basically such that:
In June, the first team'll clear out all the RC base problems.
In July, the second team'll take over tidying up the base packages,
while the first team'll move on to RC problems in standard
packages, and packages included in tasks.
In August, the second team'll take over the standard packages and the
tasks, and the first team'll fix as many RC issues in
optional and extra packages as they can.
In September, the second team'll tidy up as many optional and extra
packages as they can.
The first team probably has the harder job: fixing obscure issues that
don't show up on non-i386 arches can be tricky and that seems to be
what most of the problems are these days. But both jobs are important
if we're to do a really good release.
Some hints to make the RC bug fixing job a little easier:
* There's no such thing as an unreproducible grave bug. Either it
breaks for everyone, or it doesn't. If the program is usable for
most people, it's not completely unusable.
* Serious bugs should be able to cite the "must" in policy that's
broken. If they can't, it's probably not a serious bug.
* Build dependencies have to be correct if they're present,
but don't have to be present. It's nominally correct to "fix"
these bugs by just removing the "Build-Depends" line from
the source package. It's better not to though. You can build
a chroot to test whether your dependencies are about right
by using debootstrap to make a chroot, then using apt-get to
install build-essential and any named build-dependencies then
seeing what breaks. Usually, anyway. You can use [0] to see what
the autobuilders would use if you don't specify any build-deps.
So anyway, if people can maybe direct some of their QA energies along
those lines, I'm pretty sure it'll be helpful.
Cheers,
aj
[0] http://buildd.debian.org/andrea/i386/source-dependencies-unstable.gz
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpFlc2VlohDL.pgp
Description: PGP signature