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".
Firstly, I want to say that I don't think this was anyone's fault. So I don't want to lay any blame. I think we should consider, though, how we can try to do better next time. For me the key problem is this: we are lacking a useful workflow for fixing RC bugs (well, many of them, anyway). "Easy" RC bugs tend to get fixed early in the freeze or even beforehand. But as the freeze continues, what are left are "hard" bugs. I don't think we necessarily have a lack of effort. I know that many people were _trying_ to improve the situation with RC bugs. But it's difficult. One ends up picking bugs more or less at random and then reading them. One will then naturally discover that the bug is difficult somehow - after all, if were easy it would probably have been fixed already. Unless one is already surrounded by enthusiastic and authoritative experts with a lot of spare time and (where needed) the right authority, one can end up blocked and discouraged. So I would like to suggest that we should have a thread where we: * Try to identify the main ways in which bugs can be "hard" (which might be technical, political, or a mixture) * Try to think of workflows which might overcome these problems * 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. * 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). Thanks, Ian. -- 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/20874.29810.191974.559...@chiark.greenend.org.uk