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

QA and the freeze...

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.


[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

Reply to: