On Wed, 8 May 2013 16:51:14 +0100 Ian Jackson <ijack...@chiark.greenend.org.uk> wrote:
> So I would like to suggest that we should have a thread where we: I suspect a wiki page will be needed at some point... > * Try to identify the main ways in which bugs can be "hard" (which > might be technical, political, or a mixture) These are the issues which discouraged me from working on particular RC bugs during this release and the one before it. * Hard to reproduce - uncommon packages, specialised setups, specific hardware or hardware configurations, intermittent issues. * Un- / under maintained packages not yet orphaned. IMHO we should be much more aggressive with such packages - strict time limits for all RC-buggy leaf packages, regardless of the uncertainties of popcon, leading to at least automatic removal from testing. Warning bugs against reverse dependencies of non-leaf packages warning of problems. (We have this now in the PTS for WNPP issues, an extension to "RC bugs in dependencies" could also be really useful.) * Disagreements between submitter & maintainer / fixer * Architecture-specific bugs for less common ports - maybe be more aggressive here also on which architectures are deemed fit for release on the basis of the occurrence and likely delays caused by such bugs. * Non-standard packaging or build system or packages using methods known to make NMU's difficult. * Languages other than C, C++, perl, shell or python, reducing the possible number of people who can get a full overview of the package. * Lapsed release goals (like building sanely twice in a row, not just in a clean chroot but during a typical NMU process too, so that test changes can be easily and quickly reverted and the package rebuilt.) Particularly important for packages which take a long time to build or have esoteric / uncommon build-dependencies. * Poor quality documentation within the package, especially for build-system idiosyncrasies and internal API/ABI requirements. Simple things like a comment in each source code file saying what the code in that file is meant to achieve. foo.c - wraps the bar interface in the foo class etc. Other steps to take as preventative measures: * More QA runs through the archive prior to freeze to catch things like embedded libraries or binaries without sources or licence irregularities, FTBFS and piuparts errors. The actual decision of the freeze date could be made to be reliant on a % clean report from such runs. * Make it a *MUST* that all transitions, no matter how small, are checked with the release team starting from as soon as the freeze is announced (not just after it starts) such that uploads which start a transition could be pushed into DELAYED or REJECTed automatically. (Not easy to implement this one, I know.) > * Try to think of workflows which might overcome these problems debian/rules must be a makefile, only specific packages can be allowed to not use debhelper, toolchain packages to be frozen earlier than the rest of the archive... I think the Debian PPA approach could also ease the process substantially - we could, for example, require that all uploads during a freeze which do not fix RC bugs must go into a Debian PPA. This reduces the need for t-p-u builds and should help the slow isolation of desired changes from packaging fluff. > * In particular, try to think of workflows and/or support tools > which might be able to connect the people with the skills and/or > authority to solve the problem, with the bug - and help motivate > those people to do the work needed to unblock the bug. That sounds like a requirement for tags and a search interface allied with rc-alert or similar. BSP's could also make use of such tags, possibly via an interface akin to the reverse of dd-list. Maybe the debtags information could be used to feed data into UDD relating to the likely experience of the maintainers based on the implemented-in and works-with tags of the packages which they maintain? Then a BSP can just feed the names into the search and get a list of likely bug numbers. The data would also help identify tags which have poor coverage and high proportions of bugs. > * Consider other ways in which our RC-bug-fixing efforts can be > improved, especially during the latter part of the freeze. > > I have deliberately avoided suggesting any answers to these questions > myself in this article. But I may do so later. > > Also we should try to treat this discussion as a kind of > semi-brainstorm: if someone makes what seems like a poor suggestion, > try to improve on it or post a better one yourself, rather than merely > criticising theirs. That will help keep the discussion open and avoid > it getting hung up on specific disagreements (which is of course a > think that mailing list conversations have a tendency to to). -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgp678phNWTJP.pgp
Description: PGP signature
