Re: Bits from the release team and request for discussion

[Anthony Towns-5]

On Fri, Jul 31, 2009 at 05:39:23AM +1000, Anthony Towns wrote:
> On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
> > About freeze timing we think that DebConf should definitely not fall
> > into a freeze

> > We noticed that releases in the first quarter of the year
> > worked out quite well in the past like both Etch and Lenny. Taking these
> > into consideration we think it would be best to freeze in December.

> > We'll be consulting all key teams within Debian to see how their plans
> > and schedules can fit into a new timeline. Before the end of August we
> > hope to have finished this process of consultation and be able to
> > present the new plan to you.

> Why not have a developer poll as to what month(s) would most suit
> people for the freeze, rather than limiting it to "key teams"?

So, with August almost half-way over, I guess the release team's not
going to be doing much more to seek input from non-key teams/developers.

I still think it'd be interesting and useful to get broader input,
though. Something like a choice amongst the following questions by GR
might work:

  1. The Debian project recommends that the release team target
     December 2009 for squeeze's freeze, and work hard to avoid allowing
     the freeze to slip by more than a few weeks. The project notes this
     is approximately 10 months after lenny's release, and approximately
     18 months after lenny's freeze. The project acknowledges this may
     assist in synchronising Debian 6.0 and Ubuntu 10.04 LTS, may assist
     in setting up regular freezes every second December, and is intended
     to allow Debian 6.0 to be released prior to DebConf 2010.

  2. The Debian project recommends that the release team target
     January-February 2010 for squeeze's freeze, following a December
     "release summit" with maintainers/upstreams for major packages to
     allow some new upstream releases that occur early in the freeze to be
     included. The project acknowledges this may assist in synchronising
     Debian 6.0 and Ubuntu 10.04 LTS, and may assist in setting up
     regular freezes every second year. The project notes this may or
     may not allow Debian 6.0 to be released prior to DebConf 2010.

  3. The Debian project recommends that the release team target
     March/April 2010 for squeeze's freeze. The project acknowledges
     this will likely mean the freeze will be active during DebConf 10.

  4. The Debian project recommends that the release team target
     May-July 2010 for squeeze's freeze. The project notes that this
     is approximately two years after lenny's freeze, and acknowledges
     this will mean the freeze will be active during DebConf 10.

  5. The Debian project recommends that the release team target
     October-December 2010 for squeeze's freeze. The project notes that
     this will be after DebConf 10 has finished, and between 20-22 months
     after lenny's release. The project acknowledges that depending on
     the length of the freeze, this may mean squeeze will be released
     more than two years after lenny.

Any thoughts? We could have such a vote over and done in about two weeks,
with the DPL's consent, and it'd seem a lot more inclusive and less
cabal-tastic than how things seem to be working atm...

Cheers,
aj

[Giacomo A. Catenazzi]

Anthony Towns wrote:

> On Fri, Jul 31, 2009 at 05:39:23AM +1000, Anthony Towns wrote:
>> On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
>>> About freeze timing we think that DebConf should definitely not fall
>>> into a freeze
>
>>> We noticed that releases in the first quarter of the year
>>> worked out quite well in the past like both Etch and Lenny. Taking these
>>> into consideration we think it would be best to freeze in December.
>
>>> We'll be consulting all key teams within Debian to see how their plans
>>> and schedules can fit into a new timeline. Before the end of August we
>>> hope to have finished this process of consultation and be able to
>>> present the new plan to you.
>
>> Why not have a developer poll as to what month(s) would most suit
>> people for the freeze, rather than limiting it to "key teams"?
>
> So, with August almost half-way over, I guess the release team's not
> going to be doing much more to seek input from non-key teams/developers.
>
> I still think it'd be interesting and useful to get broader input,
> though. Something like a choice amongst the following questions by GR
> might work:
>
>   1. The Debian project recommends that the release team target
>      December 2009 for squeeze's freeze, and work hard to avoid allowing
>      the freeze to slip by more than a few weeks. The project notes this
>      is approximately 10 months after lenny's release, and approximately
>      18 months after lenny's freeze. The project acknowledges this may
>      assist in synchronising Debian 6.0 and Ubuntu 10.04 LTS, may assist
>      in setting up regular freezes every second December, and is intended
>      to allow Debian 6.0 to be released prior to DebConf 2010.

(...)
>
> Any thoughts? We could have such a vote over and done in about two weeks,
> with the DPL's consent, and it'd seem a lot more inclusive and less
> cabal-tastic than how things seem to be working atm...

Later Luk wrote that now December 2009 seems an unrealistic target, but he
would talk to other teams to discuss the freeze date/period before announcing
again.

IMHO we should wait a formal decision of RMs before a GR.

Personally I don't think we should do a GR to recommend a freeze or release date.
We already used the DPL election to push a release, when it was *long* due, but
I don't think we should push a freeze.

ciao
        cate


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthew Johnson-12]

On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote:
> Personally I don't think we should do a GR to recommend a freeze or release date.
> We already used the DPL election to push a release, when it was *long* due, but
> I don't think we should push a freeze.

Zack has been patching devotee to allow more informal (and not at all
binding) polls to be run with the same infrastructure. I think this
could be a suitable candidate to run using that. It allows us to have a
poll which can only be voted in by DDs and not easily stuffed, but
without having to go through the pain of a formal resolution.

Matt
--
Matthew Johnson

[Manoj Srivastava]

On Tue, Aug 11 2009, Matthew Johnson wrote:

> On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote:
>> Personally I don't think we should do a GR to recommend a freeze or release date.
>> We already used the DPL election to push a release, when it was *long* due, but
>> I don't think we should push a freeze.
>
> Zack has been patching devotee to allow more informal (and not at all
> binding) polls to be run with the same infrastructure. I think this
> could be a suitable candidate to run using that. It allows us to have a
> poll which can only be voted in by DDs and not easily stuffed, but
> without having to go through the pain of a formal resolution.

        Hmm? Why haven't these patches been sent upstream, then?  I have
 been also working at devotee-ng, which will have a plug-in
 architecture, to allow votes to add in dfferent pre-processing stacks
 (mime/gpg-decrypt, vs plain ballot vs DB lookup), to bypass checks
 (gpg, ldap), or add new ones, and to change the vote tallying
 algorithm, and add in new response/publish modules.

        Forking devotee at this point seems to serve little purpose,
 given that upstream is not hostile.

        manoj

--
If you wish to live wisely, ignore sayings -- including this one.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Neil McGovern]

On Tue, Aug 11, 2009 at 10:14:10AM -0500, Manoj Srivastava wrote:
>         Forking devotee at this point seems to serve little purpose,
>  given that upstream is not hostile.
>

Given that the secretary team haven't heared of these patches (AFAIK),
the mention of 'forking' is a bit of a over-reaction.

Neil
--
<weasel> dpkg: shut up
<dpkg> No, I won't, and you can't make me. :P
<weasel> hah.  _I_ can

[Gunnar Wolf]

Anthony Towns dijo [Tue, Aug 11, 2009 at 01:07:33PM +1000]:
> So, with August almost half-way over, I guess the release team's not
> going to be doing much more to seek input from non-key teams/developers.
>
> I still think it'd be interesting and useful to get broader input,
> though. Something like a choice amongst the following questions by GR
> might work:
> (…)

I basically oppose such a GR, as it is is merely speculative (who
knows _now_ or at the GR voting time when we will be close to
achieving our release goals?), and because it is a ruling on a
technical subject (at least according to some metrics). But if the
vote were to be held at all, I would add:

  6. The Debian project recognizes the responsible team to take any
     decisions regarding the freeze date and reach to be the Release
     Team, and accepts their best judgement in this regard.

BTW, reiterating so much on when Ubuntu is, when DebConf is and all
that... Is just too reiterative, if you allow me to reiterate ;-)

Greetings,

--
Gunnar Wolf • gwolf@... • ([phone] / 1451-2244

[Manoj Srivastava]

On Tue, Aug 11 2009, Gunnar Wolf wrote:

> Anthony Towns dijo [Tue, Aug 11, 2009 at 01:07:33PM +1000]:
>> So, with August almost half-way over, I guess the release team's not
>> going to be doing much more to seek input from non-key teams/developers.
>>
>> I still think it'd be interesting and useful to get broader input,
>> though. Something like a choice amongst the following questions by GR
>> might work:
>> (…)
>
> I basically oppose such a GR, as it is is merely speculative (who
> knows _now_ or at the GR voting time when we will be close to
> achieving our release goals?), and because it is a ruling on a
> technical subject (at least according to some metrics). But if the
> vote were to be held at all, I would add:
>
>   6. The Debian project recognizes the responsible team to take any
>      decisions regarding the freeze date and reach to be the Release
>      Team, and accepts their best judgement in this regard.

        Perhaps you should look at this less confrontationally. The vote
 is a non-binding recommendation, it is an information gathering vote
 where people provide feedback to the release team; by voting for the
 option that best suits their development plans.

        Based on the outcome, the release team can come to an *informed*
 decision. By objecting to the vote, you might be making the tasks of
 the release team harder, by denying them information from the project
 at large.

        manoj
--
if (instr(buf,sys_errlist[errno])) /* you don't see this */ Larry Wall
in eval.c from the perl source code
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stephen Gran]

This one time, at band camp, Anthony Towns said:
> Any thoughts? We could have such a vote over and done in about two weeks,
> with the DPL's consent, and it'd seem a lot more inclusive and less
> cabal-tastic than how things seem to be working atm...

Is there some reason we need something as heavyweight as a GR?  This
looks like a doodle poll that accidentally got ideas of grandeur and
thought it was helping Debian.
--
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@... |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[Josselin Mouette]

Le mardi 11 août 2009 à 15:08 -0500, Manoj Srivastava a écrit :
>         Perhaps you should look at this less confrontationally. The vote
>  is a non-binding recommendation, it is an information gathering vote
>  where people provide feedback to the release team; by voting for the
>  option that best suits their development plans.
>
>         Based on the outcome, the release team can come to an *informed*
>  decision. By objecting to the vote, you might be making the tasks of
>  the release team harder, by denying them information from the project
>  at large.

I do not trust a majority of people – regardless of the people – to make
an appropriate managerial decision. We have people in charge, who take a
lot of time to remain informed of the status of various subsystems in
Debian so that they can make informed decisions. If we replace them by a
majority’s vote, you can expect the decisions to be wrong.

--
 .''`.      Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling

[Marc Singer]

2009/8/11 Josselin Mouette <joss@...>

[deletia]

I do not trust a majority of people – regardless of the people – to make
an appropriate managerial decision. We have people in charge, who take a
lot of time to remain informed of the status of various subsystems in
Debian so that they can make informed decisions. If we replace them by a
majority’s vote, you can expect the decisions to be wrong.

It is also challenging to get a large group of people well enough informed to make a decision worthy of the effort.
 

Cheers

[Manoj Srivastava]

On Tue, Aug 11 2009, Josselin Mouette wrote:

> Le mardi 11 août 2009 à 15:08 -0500, Manoj Srivastava a écrit :
>>         Perhaps you should look at this less confrontationally. The vote
>>  is a non-binding recommendation, it is an information gathering vote
>>  where people provide feedback to the release team; by voting for the
>>  option that best suits their development plans.
>>
>>         Based on the outcome, the release team can come to an *informed*
>>  decision. By objecting to the vote, you might be making the tasks of
>>  the release team harder, by denying them information from the project
>>  at large.
>
> I do not trust a majority of people – regardless of the people – to make
> an appropriate managerial decision. We have people in charge, who take a
> lot of time to remain informed of the status of various subsystems in
> Debian so that they can make informed decisions. If we replace them by a
> majority’s vote, you can expect the decisions to be wrong.

        You are not reading.

        The whole vote is to come up with a recommendation for the
 decision makers, and the raw vote counts can give them an idea of the
 impact or desirability of each option. There is no decision by the
 unwashed masses bit going on here. This is just a medium of informing
 the decision makers of teams that they might not have time to keep up
 with -- and  individual developers, whole release plans en masse  ought
 to have some bearing on the release, and thus are relevant information
 to the RM's


        Had the vote draft been couched as overriding a delegate
 decision, you might have ahd a point to your rant.

        manoj

--
The only thing that experience teaches us is that experience teaches us
nothing. Andre Maurois (Emile Herzog)
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Neil McGovern]

On Tue, Aug 11, 2009 at 07:56:33PM -0500, Manoj Srivastava wrote:
>         The whole vote is to come up with a recommendation for the
>  decision makers

And should the decision makers not follow that recommendation, the
flamewars will truely begin.

The format and phrasing of this is:
"The Debian project recommends [something]".
I would feel very uncomfortable going against the project directly
recommending I follow a particular course of action. This indicates to
me that this is more of an instruction, rather than a recommendation,
despite the wording.

Neil
--
<moray> hm, maybe wearing a black t-shirt while dusting my bedroom for the
        first time in years wasn't such a good idea


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bernhard R. Link-2]

* Marc Singer <elf@...> [090812 03:12]:

> 2009/8/11 Josselin Mouette <joss@...>
>
> > [deletia]
> >
> > I do not trust a majority of people ? regardless of the people ? to make
> > an appropriate managerial decision. We have people in charge, who take a
> > lot of time to remain informed of the status of various subsystems in
> > Debian so that they can make informed decisions. If we replace them by a
> > majority?s vote, you can expect the decisions to be wrong.
> >
>
> It is also challenging to get a large group of people well enough informed
> to make a decision worthy of the effort.

While it is challenging to inform a large group of people, that is in my
eyes rather a reason to make it a vote: If you do not inform people well
enough so that they would vote for the best solution, they will not
recognize the best solution as that, so they will be unhappy with those
doing the decisions and be frustrated, leaving or working against the
solution.

So if you cannot get the people affected by the decision to back up the
decision (and if it is only in a way of "X I trust, X said Y") then not
doing a vote is the wrong way to go: Better risk a suboptimal decision
and people supporting that to having decided an optimal solution that
cannot work due to lack of support or even no longer having people doing
the better solutions in charge as noone likes their decisions.

Hochachtungsvoll,
        Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Marc Singer]

On Wed, Aug 12, 2009 at 1:10 AM, Bernhard R. Link <brlink@...> wrote:

* Marc Singer <elf@...> [090812 03:12]:

> 2009/8/11 Josselin Mouette <joss@...>
>
> > [deletia]
> >
> > I do not trust a majority of people ? regardless of the people ? to make
> > an appropriate managerial decision. We have people in charge, who take a
> > lot of time to remain informed of the status of various subsystems in
> > Debian so that they can make informed decisions. If we replace them by a
> > majority?s vote, you can expect the decisions to be wrong.
> >
>
> It is also challenging to get a large group of people well enough informed
> to make a decision worthy of the effort.

While it is challenging to inform a large group of people, that is in my
eyes rather a reason to make it a vote: If you do not inform people well
enough so that they would vote for the best solution, they will not
recognize the best solution as that, so they will be unhappy with those
doing the decisions and be frustrated, leaving or working against the
solution.

So if you cannot get the people affected by the decision to back up the
decision (and if it is only in a way of "X I trust, X said Y") then not
doing a vote is the wrong way to go: Better risk a suboptimal decision
and people supporting that to having decided an optimal solution that
cannot work due to lack of support or even no longer having people doing
the better solutions in charge as noone likes their decisions.

The claim that "...noone [sic] likes their decisions" is hardly defensible.

Whether or not there is a GR, the point is that it is difficult to assess the benefit
of a recommendation made by the membership as it has everything to do with
the question asked and the depth of their knowledge of the issue.  Perhaps
the fundamental issue is whether or not the membership is willing to trust the
decisions of the release managers.

Cheers

[Raphaël Hertzog]

On Tue, 11 Aug 2009, Matthew Johnson wrote:

> On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote:
> > Personally I don't think we should do a GR to recommend a freeze or release date.
> > We already used the DPL election to push a release, when it was *long* due, but
> > I don't think we should push a freeze.
>
> Zack has been patching devotee to allow more informal (and not at all
> binding) polls to be run with the same infrastructure. I think this
> could be a suitable candidate to run using that. It allows us to have a
> poll which can only be voted in by DDs and not easily stuffed, but
> without having to go through the pain of a formal resolution.

I would like to see such a poll as well.

Cheers,
--
Raphaël Hertzog


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Gunnar Wolf]

Manoj Srivastava dijo [Tue, Aug 11, 2009 at 03:08:52PM -0500]:

> > I basically oppose such a GR, as it is is merely speculative (who
> > knows _now_ or at the GR voting time when we will be close to
> > achieving our release goals?), and because it is a ruling on a
> > technical subject (at least according to some metrics). But if the
> > vote were to be held at all, I would add:
> >
> >   6. The Debian project recognizes the responsible team to take any
> >      decisions regarding the freeze date and reach to be the Release
> >      Team, and accepts their best judgement in this regard.
>
>         Perhaps you should look at this less confrontationally. The vote
>  is a non-binding recommendation, it is an information gathering vote
>  where people provide feedback to the release team; by voting for the
>  option that best suits their development plans.
>
>         Based on the outcome, the release team can come to an *informed*
>  decision. By objecting to the vote, you might be making the tasks of
>  the release team harder, by denying them information from the project
>  at large.

It is not confrontational, as it has been pointed out by others
here. You might rephrase what I meant to say as:

    6. This particular developer knows there is more to a release than
       his personal (or particular group's) points of view, and
       acknowledges any decision put forward by the release team, as
       long as they listen to the project real concerns, will be
       better informed and, thus, better than any random date that
       might be pushed forward

--
Gunnar Wolf • gwolf@... • ([phone] / 1451-2244

[Manoj Srivastava]

On Wed, Aug 12 2009, Gunnar Wolf wrote:

> Manoj Srivastava dijo [Tue, Aug 11, 2009 at 03:08:52PM -0500]:
>> > I basically oppose such a GR, as it is is merely speculative (who
>> > knows _now_ or at the GR voting time when we will be close to
>> > achieving our release goals?), and because it is a ruling on a
>> > technical subject (at least according to some metrics). But if the
>> > vote were to be held at all, I would add:
>> >
>> >   6. The Debian project recognizes the responsible team to take any
>> >      decisions regarding the freeze date and reach to be the Release
>> >      Team, and accepts their best judgement in this regard.
>>
>>         Perhaps you should look at this less confrontationally. The vote
>>  is a non-binding recommendation, it is an information gathering vote
>>  where people provide feedback to the release team; by voting for the
>>  option that best suits their development plans.
>>
>>         Based on the outcome, the release team can come to an *informed*
>>  decision. By objecting to the vote, you might be making the tasks of
>>  the release team harder, by denying them information from the project
>>  at large.
>
> It is not confrontational, as it has been pointed out by others
> here. You might rephrase what I meant to say as:
>
>     6. This particular developer knows there is more to a release than
>        his personal (or particular group's) points of view, and
>        acknowledges any decision put forward by the release team, as
>        long as they listen to the project real concerns, will be
>        better informed and, thus, better than any random date that
>        might be pushed forward

        Why is this vote not being considered a part of the  release
 managers listening to the developers? Throw away the results of the
 vote. The release managers can just look at the raw data, to see how
 many people are saying that for their packages, the optimal release
 date is foo. Then, factor in other variables, and look at large
 packages differently, look at the major packages to sync with upstream
 and other distributions, and decide.

        This whole thing of we must not even take a straw poll to see
 what developers might say, because giving the developers a voice will
 somehow undercut the release team seems somewhat strange to me.

        I would be against binding resolutions, but I am in favour of
 non-binding straw polls.

        manoj
--
Kill Ugly Processor Architectures Karl Lehenbauer
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Banck]

On Tue, Aug 11, 2009 at 01:07:33PM +1000, Anthony Towns wrote:
> Any thoughts? We could have such a vote over and done in about two
> weeks, with the DPL's consent, and it'd seem a lot more inclusive and
> less cabal-tastic than how things seem to be working atm...

I think it is a bad idea, given that the release team seems to be
listening to the project and revising their freeze schedule ideas.


Michael


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve McIntyre]

On Tue, Aug 11, 2009 at 01:07:33PM +1000, Anthony Towns wrote:
>
>Any thoughts? We could have such a vote over and done in about two weeks,
>with the DPL's consent, and it'd seem a lot more inclusive and less
>cabal-tastic than how things seem to be working atm...

Personally, I think the last thing we need is a GR on this front right
now. There's still discussion going on and plenty of scope for
interested people to make their feelings known. We don't need the
overhead of a GR at all that I can see.

--
Steve McIntyre, Cambridge, UK.                                steve@...
< sladen> I actually stayed in a hotel and arrived to find a post-it
          note stuck to the mini-bar saying "Paul: This fridge and
          fittings are the correct way around and do not need altering"


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Marc 'HE' Brockschmidt-3]

Manoj Srivastava <srivasta@...> writes:

> On Tue, Aug 11 2009, Gunnar Wolf wrote:
>> I basically oppose such a GR, as it is is merely speculative (who
>> knows _now_ or at the GR voting time when we will be close to
>> achieving our release goals?), and because it is a ruling on a
>> technical subject (at least according to some metrics). But if the
>> vote were to be held at all, I would add:
>>
>>   6. The Debian project recognizes the responsible team to take any
>>      decisions regarding the freeze date and reach to be the Release
>>      Team, and accepts their best judgement in this regard.
>
>         Perhaps you should look at this less confrontationally. The vote
>  is a non-binding recommendation, it is an information gathering vote
>  where people provide feedback to the release team; by voting for the
>  option that best suits their development plans.

While I can't really disagree with this, I don't think a GR will
actually provide all the needed information.

In a GR, quite a few people will prefer one option over the other for
reasons that have nothing to do with the feasibility or quality of a
freeze at a given point [1].

I believe answers to a short questionnaire (what will be released when?
should it be in squeeze) would help a lot more, and thus I'm currently
working with the rest of the release team to send such mails.

At this point, I would like to once again apologize for the less than
optimal handling of communication between the release team and the rest
of the project in the past month. [2] The last weeks were shaped by
discussions that would have been unneeded if we had explained proposals
in a better way (and marked them more clearly as proposals) and avoided
some (now obvious) mistakes.

Marc

Footnotes:
[1]  As example, people who know that they have a few thousand machines
     running lenny will probably prefer a later date, so that they don't
     need to do mass dist-upgrades after just 30 months.
[2]  Please note that this statement is not a coordinated release team
     statement, but an expression of my personal feelings.