On Wed, May 08, 2013 at 04:51:14PM +0100, Ian Jackson wrote:
> It is good to have it released now, but I think we are all (mostly?)
> agreed that wheezy took longer to release than we would have liked.
> In particular, the RC bug count didn't drop "quickly enough".
Thanks for bringing this up!
I would like to take this opportunity to post an experience report and
give some conclusions I'd make from that.
During the wheezy cycle I participated in the 2011 Hildesheim BSP. In my
experience BSPs are among the best places to get difficult issues sorted
out. Political issues tend to play less of a role there and it
participants tend to motivate each other not to give up on technical
challenges. I would like to thank all the BSP organizers for their
valuable contributions to the project.
During said BSP I settled on fixing #88010 (yes five digits, policy
violation, {lenny,squeeze}-ignore). It clearly meets the criterion of
"hard" and fixing it took more than a year. Here are a few observations
on the process:
* The largest amount of time used for fixing went into communication.
Sometimes I would wait for multiple months to receive an essential
answer from involved parties. This had a multitude of reasons and I
would like to avoid a blame game here, but this ultimately resulted
in missing the freeze and later resulted in last-minute changes.
* There were a great many people who helped me with technical aspects,
that were sufficiently isolated and did not require a broad view on
the issue. This applies especially to the changes in packaging, the
involved perl code, the usage of dpkg triggers and the transition
tool set.
* Even though I had a variety of people review the changes introduced,
the first attempts resulted in a variety of new failure modes.
Remark: The PPA thingy might be part of the solution here. As it
would make testing transitions easier.
> * Try to think of workflows which might overcome these problems
Given the experience above and the experience with other RC bugs, I
would like to suggest to form semi-spontaneous teams around some RC
bugs. The rationale here being is that some "hard" RC bugs tend to be
quite complex and complexity made me give up on other issues. We already
have the notion of "owner" in the BTS, but its usage appears to be
limited (and I didn't use it either for RC bugs so far). By forming a
team around a particular issue, we can contain the complexity and
motivate each other. This is not to say that such a team is to do the
full fix, but to give a direction and coordinate the involved parties.
The team would be tasked with avoiding stalls in the progress, pinging
and possibly timing out involved parties. Possibly writing regular
progress summaries would also be helpful to evaluate the performance of
the team. Such summaries would also make switching the owner later
easier. This model should also work with single person teams, but I'd
fear that a single person could more easily run into political
acceptance issues.
This is just a rough sketch so far, and I cannot tell whether it
actually works. Rereading the above paragraph, it sounds a bit like
"mini release goal".
Helmut
--
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/20130509090056.ga28...@alf.mars
