Given that this is supposed to be the discussion period, I'd like to share my standpoint regarding one option. Andreas Barth wrote: > | We as Developers at large continue to trust our release team to follow > | all these goals, and therefor encourage them to continue making > | case-by-case-decisions as they consider fit, and if necessary > | authorize these decisions. I am extremely hesitant when it comes to this option. In fact, I think it's going to end up below "Further discussion" on my ballot. The main reason for that is that IMO the main reason that we're having this discussion is that the firmware question was handled rather badly by the current release team (RT). They themselves bear a heavy responsi- bility especially for the way the discussion started (IMO things have now settled down into a fairly reasonable discussion and voting process). We've already had two releases where this was an issue and in both cases it was decided by a GR. Why should the current release team think they could handle it differently? Just compare the way this started (by someone noticing that RC bugs had been tagged lenny-ignore without _any_ prior public discussion) to the way it was handled by the previous release team. For Etch, Steve Langasek *as RM* opened the discussion on debian-vote with this mail: http://lists.debian.org/debian-vote/2006/08/msg00032.html In summary: the previous RT anticipated on the resistance against such waivers, opened a discussion with the project and proposed a resolution to allow the release to go forward. This resulted in a very controlled vote (well, except for ...) and in the end the permission of the project was obtained without any real bloodshed. It's no secret that I've not been happy with the way the current RT has handled a number of things, including for example removals from testing. They seem to think they are mandated a large degree of freedom to beat the archive into shape for the release, no matter the cost and the frustration this may cause developers. IMO this is fundamentally wrong. Important decisions regarding the release, such as waiving structural RC issues, the support of architectures and the removal of packages should be made in discussion with the project at large and *not* by a select team. However careful they are it is impossible that they can correctly weigh all arguments all by themselves, even if only because they are just not aware of all the facts (for which of course they cannot be blamed given the size and diversity of the project). It is especially wrong because the way it is done is largely silent. Only very few people will actually notice the removal of a package or the addition of a tag to a BR when those happen. Most developers will only notice later on, for example when things break. Supporting this option on the ballot would effectively grant the RT broad powers and only increase the kind of problems we've seen in this release cycle. So, although I completely disagree with Robert Milan on his viewpoints regarding firmware, I do thank him for bringing the matter to the attention of the project. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.