Yea? When are you filing a patch that corrects it?
complaining does nothing. we all know what would be
better and move toward it
and your forgetting the by-law: you don't fix what
you think is better by breaking software that works
unless you can really prevent all breakage
after all. what you think is better, compared to
software filed by, ie, ATT experts long ago?
Your probably wrong an not studied enough has to
be my first assumption.
Neil Williams wrote:
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).
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5191965c.4080...@cox.net
