On Wed, Jun 23, 2004 at 01:14:07PM +0200, Bill Allombert wrote: > On Tue, Jun 22, 2004 at 04:43:29PM +0100, Colin Watson wrote: > > On Tue, Jun 22, 2004 at 05:35:07PM +0200, Bill Allombert wrote: > > > This rely on the premices that at least some options will allow to release > > > sarge sooner. Unfortunately discussions on debian-vote involving the > > > release manager and the ctte had made clear to me that none of the > > > ballot options will have positive effect on the release of sarge, making > > > the exercise rather pointless, the reason being, all the options focus > > > on the previous SC change and side-step the real issue which is the > > > change of the release policy. I see no evidence that any changes of the > > > SC will imply change in the release policy allowing to release sarge > > > sooner. > > > > Can you please refer me to the discussions in question? As far as I can > > tell, both Steve and I (release assistants) have an entirely different > > impression, and between us we proposed some of the options on the > > ballot. > > For example: > <http://lists.debian.org/debian-vote/2004/05/msg00220.html>
In that post, Anthony tells people to think out the consequences for themselves, and says that the TC can reset the release policy if they choose, but doesn't say that that's the only possible resolution. > <http://lists.debian.org/debian-ctte/2004/06/msg00002.html> The main flaw identified here is that the proposals generally don't do enough to delegate explicit discretion to appropriate people, which is a fair criticism. However, several of the proposals certainly do qualify as "grandfather resolutions" as described, and, by explicitly removing the Social Contract's requirement to have DFSG-free documentation and firmware for sarge/some-period-of-time/whatever, go back to allowing discretion on the part of those who would ordinarily be responsible for release issues and DFSG control. > <http://lists.debian.org/debian-vote/2004/05/msg00396.html> I can't say I see a problem here at all; changing the SC means that the argument is for the time being no longer immediately relevant, although it will become relevant again in the future (but that's always going to be the case). The main problem I've encountered is that the GR process was not remotely designed for doing things in a hurry, and when the proponents are feeling under time pressure it positively discourages them from coalescing multiple options into one by means of the frequent resetting of the discussion period. This seems to be suboptimal, although I'm not sure what the ideal fix is. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
