Re: What your ballot should look like if you're in favor of releasing sarge
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 [cjwatson@flatline.org.uk]
Reply to: