T&S for Release Assistents
[Cced the victi^Wpotential assistents this time - next time get it from
the list :]
Hi guys,
Your first assignment, should you choose to accept it, is to solve the
following bugs:
Robert Edmonds
423823 retchmail: FTBFS: error: there are no arguments to 'cur' that
depend on a template parameter, so a declaration of 'cur' must be available
368226 Quagga does intentionally not upgrade automatically
405186 docbook2x: FTBFS: reference to nonexistent nodes
Julien Cristau
423966 wvdial: FTBFS: error: there are no arguments to 'cur' that depend
on a template parameter, so a declaration of 'cur' must be available
393361 Source package contains non-free IETF RFC/I-D's
403611 xemacs21-basesupport: xsl mode interprets delete key inconsistently
Pierre Habouzit
393403 Source package contains non-free IETF RFC/I-D's
294520 qtparted: Incorrect handling of extended partitions
356055 loadlin: loadlin.exe cannot be built from source
Neil McGovern
393425 Source package contains non-free IETF RFC/I-D's
395252 requires too much security maintainance work due to embedded
ffmpeg copy
402482 busybox gunzip / zcat fail to decompress validly gzipped files
"Solve" can mean many things. The best solution is a fixed package being
uploaded to the archive that satisfies the submitter, the maintainer,
and everyone else. Alternatively, it might be that it's a non-bug or
has already been fixed, and you can satisfy everyone that that's the
case. Another option is that the bug might be unfixable, and the package
may need to be removed from testing or unstable or both. In some cases
the bug may be specific to woody or sarge. In some cases the submitter
might not be contactable to verify the problem's solved.
By this time in two weeks, you should aim for each of the bugs under
your name to have moved forward as far as possible, ideally closed. If
it's not clear what the problem is, find out. If it's not clear what
would fix it, work it out. If the fix isn't entirely clear, spell it
out. If it's fixed upstream, point that out. Prepare a patch if there
isn't already one. Do an NMU if appropriate. You get the idea.
You might want to consider spending a few minutes looking at each bug
now, and, if necessary, ask for any more information that's needed from
the submitter, so that you have the information when you've got some
more time to spend on it later.
Once you've done as much as you're able for the two weeks, make sure the
bug report includes all the up to date information, then reply to this
mail (to debian-release@lists.debian.org) with a brief summary of what's
happened and what the next step (if any) is. If you think the package
requires removal from testing (or the bug can be fixed by other means
from the release team), feel free to forward the proposed fix as soon as
possible to the release team.
If the above is just too easy, for extra credit you can take on some of
the other older bugs from the RC bug list. If you do, include those in
your mail next week. If you're not able to fix a bug, ask for help or
do as much as you can, then leave it; don't get in over your head, or,
worse, upload an NMU that's broken or doesn't completely fix the
problem.
Of course, you are allowed to use all resources available for bug
fixing; this excludes the help of the current release team members for
obvious reasons. :)
So, have fun,
Your Release Managers
Reply to: