Re: Debian decides to adopt time-based release freezes

[Frans Pop-3]

On Wednesday 29 July 2009, Meike Reichle wrote:
> The Debian project has decided to adopt a new policy of time-based
> development freezes for future releases, on a two-year cycle.

Disappointing to see such an announcement without any prior discussion on
d-project, d-devel or d-vote. Some explanation of how and by who this
decision was reached would be appreciated.

So from now on we release "when it's time" instead of "when it's ready"?
RC bugs are no longer relevant?

Cheers,
FJP

[Ben Pfaff]

Frans Pop <elendil@...> writes:

> On Wednesday 29 July 2009, Meike Reichle wrote:
>> The Debian project has decided to adopt a new policy of time-based
>> development freezes for future releases, on a two-year cycle.
>
> Disappointing to see such an announcement without any prior discussion on
> d-project, d-devel or d-vote. Some explanation of how and by who this
> decision was reached would be appreciated.

The URL in the announcement is 404.  Possibly a prank.
--
Ben Pfaff
http://benpfaff.org


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

[Sune Vuorela-2]

On 2009-07-29, Frans Pop <elendil@...> wrote:

> --nextPart2108813.qE7SciSrbv
> Content-Type: text/plain;
>   charset="iso-8859-15"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
>
> On Wednesday 29 July 2009, Meike Reichle wrote:
>> The Debian project has decided to adopt a new policy of time-based
>> development freezes for future releases, on a two-year cycle.
>
> Disappointing to see such an announcement without any prior discussion on=20

I'm disappointed by the decision, the timing and the process.
I'm especially dissapointed about the "we freeze after less than a year
of open unstable".

The process:

This is not something that should be done only by the release team
without a broad discussion amongst the developers, unless the relaese
team wants to do it them selves without cooperation from the package
maintainers.

The timing:

If we are going to do a yearly release, we need to announce it to the
developers more than 5 months before freeze. Too many people have too
many plans.
We also need to coordinate such things with the larger packaging teams
to see wether it fits their schedules and their upstream schedules. For
example from a KDE point of view, it is around teh worst time.

...and we still have the same kernel and X in testing as in stable.

The decision:

Why doing a 12 months release "to get into the new schedule" instead of
just adopting a 24 months schedule based on the lenny release? [1]

By freezing after around 9 months after thawing, we will again annoy the
many sid users we have, and by doing releases after 12 months after a
release, we will start annoy the "corporate" users.

By freezing after around 9 months of unstable we annoy the developers
who wants to get stuff done before a release.

And what happened to "when it is ready" ?

If a freeze is expected to be short, the release team needs help from
the package maintainers. This is not the way to get the package
maintainers to help them.


I'm considering how we can get this decision undone.  Anyone up for
helping with that?

/Sune


[1] Some people says it is to get to work better with ubuntu in security
things and other such "stable support" - and having the same package
versions will make it easier to share patches.  Unfortunately, in some
cases this will not fit. For example, Qt4.6 and KDE4.4 is expected to be
released in january, which would be right after the debian freeze. I
would be very surprised to see a ubuntu releaese in april with kde4.3
and qt4.5. And here, we now already have two browser engines that we
can't work properly together and share patches with ubuntu, because too
much has (probably) happened.
And for much other software, there is probably similar examples.


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

[Sandro Tosi-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Debian decides to adopt time-based release freezes

No, the project DID NOT decide it, the release team did, and the
project has to accept it; there's a lot of difference.

> The Debian project has decided to adopt a new policy of time-based
> development freezes for future releases, on a two-year cycle. Freezes

and what are the real advantages of this? I saw none in this announce.

> will from now on happen in the December of every odd year, which means
> that releases will from now on happen sometime in the first half of every
> even year.  To that effect the next freeze will happen in December 2009,
> with a release expected in spring 2010. The project chose December as a
> suitable freeze date since spring releases proved successful for the
> releases of Debian GNU/Linux 4.0 (codenamed "Etch") and Debian GNU/Linux
> 5.0 ("Lenny").

if time-based is REALLY needed, why then not "freeze on even Dec and
release on Spring on odd years"? this will allow the current release
cycle to have enough time to achieve something, while letting
time-based proposers happy.

> Time-based freezes will allow the Debian Project to blend the
> predictability of time based releases with its well established policy of
> feature based releases. The new freeze policy will provide better
> predictability of releases for users of the Debian distribution, and also

bullshit! we are trading quality for what? We release when it's ready,
not when the clock ticks. it's completely a non-sense, and it's
generating only bad feelings in developers and users.

and predictability is the only advantage of this proposal? if so, then
simply let's drop it: pro and cons are damn wrong.

> allow Debian developers to do better long-term planning.  A two-year
> release cycle will give more time for disruptive changes, reducing

Not this time.

> inconveniences caused for users. Having predictable freezes should also
> reduce overall freeze time.

should we remember here that lenny freeze took +6 months?

> Since Debian's last release happened on Feb. 14th 2009, there will only
> be approximately a one year period until its next release, Debian
> GNU/Linux 6.0 (codenamed "Squeeze").  This will be a one-time exception
> to the two-year policy in order to get into the new time schedule. To

why on earth we need this exception? *we* are deciding (let's pretend
this) what will be our time schedule, so we can decide to have "freeze
on Dec even years, rel on Spring odd years" policy and we can save
squeeze as long as the next development cycles.

Or there's something else behind the curtains that it's not being said
(consciously), like ubuntu LTS?

> accommodate the needs of larger organisations and other users with a long
> upgrade process, the Debian project commits to provide the possibility to
> skip the upcoming release and do a skip-upgrade straight from Debian
> GNU/Linux 5.0 ("Lenny") to Debian GNU/Linux 7.0 (not yet codenamed).

so, what's the point in preparing squeeze? let's just skip it then

> Although the next freeze is only a short time away, the Debian project
> hopes to achieve several prominent goals with it. The most important are

Who is hoping this? we have still a colossal amount of work to do, and
we are just said "hey, we'll freeze in 5 months: get it done, fir RC
bugs and let's kick out squeeze). that's not encouraging.

Rel team needs commitment from developers to release, and this is not
the way to get it.

> multi-arch support, which will improve the installation of 32 bit
> packages on 64 bit machines, and an optimised boot process for better
> boot performance and reliability.
>
> The new freeze policy was proposed and agreed during the Debian Project's
> yearly conference, DebConf, which is currently taking place in Caceres,
> Spain. The idea was well received among the attending project members.

1. what about the developers that couldn't come to DC? don't we
deserve to be asked for our opinion? are we of a lower class? is this
a decision only made by a team and then you want to us to pretend the
whole project decided it?

2. it doesn't seem all the attendants agreed with it, given what
happened yesterday evening on #debian-release.

To conclude:

- - we are giving up our quality-based release for a time-based one
for no particular reason
- - there is a constant drift away from debian by our users, this
would be the killing shot
- - we didn't know this decision was being discussed
- - we received no alert with enough time to work on make squeeze
happen (and then we talk about time-based release, bah)
- - this is a change in our most important aspect of our work: the
release. How can I go now to my boss and propose to switch to debian
once this is happening?

Not to mention how many angry replies are coming, I feel the community
of debian developers is not accepting this decision silently.

- --
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.6)

iEYEARECAAYFAkpv3/wACgkQAukwV0RN2VA0hwCfXCMIt/1oskEz1melH91QNzXb
S9MAn2P1kxY16R2o6Ay53OUfyZEYh1si
=CgR9
-----END PGP SIGNATURE-----


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

[Sandro Tosi-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jul 29, 2009 at 06:45, Sune Vuorela<nospam@...> wrote:
> I'm considering how we can get this decision undone.  Anyone up for
> helping with that?

count me in.

- --
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.6)

iEYEARECAAYFAkpv4DQACgkQAukwV0RN2VC4vACfaIwapx8f72tcWukZIAtRwVr1
OREAmwenWiSAPkb90ZSZ7bNCOoDQY63r
=BNSt
-----END PGP SIGNATURE-----


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

[Goswin von Brederlow-2]

Frans Pop <elendil@...> writes:

> On Wednesday 29 July 2009, Meike Reichle wrote:
>> The Debian project has decided to adopt a new policy of time-based
>> development freezes for future releases, on a two-year cycle.
>
> Disappointing to see such an announcement without any prior discussion on
> d-project, d-devel or d-vote. Some explanation of how and by who this
> decision was reached would be appreciated.

It was discussed at debconf. Lots of explanation given there seems to
have been left out of the announcement.

> So from now on we release "when it's time" instead of "when it's ready"?
> RC bugs are no longer relevant?
>
> Cheers,
> FJP

No, we freeze on time, we release when ready. Big difference.

MfG
        Goswin


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

[Sandro Tosi-4]

On Wed, Jul 29, 2009 at 08:59, Goswin von Brederlow<goswin-v-b@...> wrote:
> No, we freeze on time, we release when ready. Big difference.

and this means a shorter freeze period (as stated in the original
announce) because?

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

[Marc Haber-5]

Hi,

On Wed, Jul 29, 2009 at 03:08:02AM +0200, Meike Reichle wrote:
> The Debian project has decided to adopt a new policy of time-based
> development freezes for future releases, on a two-year cycle.

I find it deeply disturbing that DDs not attending Debconf learn about
this decision via debian-announce. I would have expected at the very
least to announce, if not discuss, on a developer list before.

Do we really need to go Ubuntu on this matter (both in the objective
and in the way of decision making)?

I do sincerely hope that there will be a GR to overrule this decision.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


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

[Kartik Mistry]

On Wed, Jul 29, 2009 at 12:29 PM, Goswin von Brederlow<goswin-v-b@...> wrote:
> It was discussed at debconf. Lots of explanation given there seems to
> have been left out of the announcement.

BOF? Talk? Where I can find explanation(s)?

--
 Cheers,
 Kartik Mistry | 0xD1028C8D | IRC: kart_
 Debian GNU/Linux Developer
 Blogs: {ftbfs, kartikm}.wordpress.com


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

[Martin Wuertele]

* Sandro Tosi <morph@...> [2009-07-29 07:39]:

> > Debian decides to adopt time-based release freezes
>
> No, the project DID NOT decide it, the release team did, and the
> project has to accept it; there's a lot of difference.

No see 4.1.3 of the constitution "Make or override any decision
authorised by the powers of the Project Leader or a Delegate."

> > Time-based freezes will allow the Debian Project to blend the
> > predictability of time based releases with its well established policy of
> > feature based releases. The new freeze policy will provide better
> > predictability of releases for users of the Debian distribution, and also
>
> bullshit! we are trading quality for what? We release when it's ready,
> not when the clock ticks. it's completely a non-sense, and it's
> generating only bad feelings in developers and users.

freeze != release, I'm not happy with the way the decision was
communicated. I beg you to mind your wording tough.

> 1. what about the developers that couldn't come to DC? don't we
> deserve to be asked for our opinion? are we of a lower class? is this
> a decision only made by a team and then you want to us to pretend the
> whole project decided it?

It is a delegate decision according to 2.5 of the constitution.

yours
Martin


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

[Goswin von Brederlow-2]

Sandro Tosi <morph@...> writes:

> On Wed, Jul 29, 2009 at 08:59, Goswin von Brederlow<goswin-v-b@...> wrote:
>> No, we freeze on time, we release when ready. Big difference.
>
> and this means a shorter freeze period (as stated in the original
> announce) because?

>From what I understand because the long freeze period we had last time
is making problems all around for users (of unstable/testing) and
developers as well as the release itself.

MfG
        Goswin


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

[Sandro Tosi-4]

On Wed, Jul 29, 2009 at 09:36, Goswin von Brederlow<goswin-v-b@...> wrote:

> Sandro Tosi <morph@...> writes:
>
>> On Wed, Jul 29, 2009 at 08:59, Goswin von Brederlow<goswin-v-b@...> wrote:
>>> No, we freeze on time, we release when ready. Big difference.
>>
>> and this means a shorter freeze period (as stated in the original
>> announce) because?
>
> From what I understand because the long freeze period we had last time
> is making problems all around for users (of unstable/testing) and
> developers as well as the release itself.

This is a fact (lenny release was too long) but doesn't address how a
fixed freeze start would generate a shorter freeze period.

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

[Sandro Tosi-4]

On Wed, Jul 29, 2009 at 09:14, Martin Wuertele<maxx@...> wrote:
> * Sandro Tosi <morph@...> [2009-07-29 07:39]:
>
>> > Debian decides to adopt time-based release freezes
>>
>> No, the project DID NOT decide it, the release team did, and the
>> project has to accept it; there's a lot of difference.
>
> No see 4.1.3 of the constitution "Make or override any decision
> authorised by the powers of the Project Leader or a Delegate."

of course, if we have to take formal steps for everything, we'll do a
GR. I hoped that in this project we can discuss ideas instead of
fight.

>> > Time-based freezes will allow the Debian Project to blend the
>> > predictability of time based releases with its well established policy of
>> > feature based releases. The new freeze policy will provide better
>> > predictability of releases for users of the Debian distribution, and also
>>
>> bullshit! we are trading quality for what? We release when it's ready,
>> not when the clock ticks. it's completely a non-sense, and it's
>> generating only bad feelings in developers and users.
>
> freeze != release, I'm not happy with the way the decision was
> communicated. I beg you to mind your wording tough.

I know it was unpolite, but it's the only way I can express my
feelings right now.

>> 1. what about the developers that couldn't come to DC? don't we
>> deserve to be asked for our opinion? are we of a lower class? is this
>> a decision only made by a team and then you want to us to pretend the
>> whole project decided it?
>
> It is a delegate decision according to 2.5 of the constitution.

so let's call it this way: not "Debian decided" but "a delegate
decided on behalf of the project", I think this clarifies what
happened.

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

[Holger Levsen-2]

Hi,

On Mittwoch, 29. Juli 2009, Frans Pop wrote:
> > The Debian project has decided to adopt a new policy of time-based
> > development freezes for future releases, on a two-year cycle.
> Disappointing to see such an announcement without any prior discussion on
> d-project, d-devel or d-vote.

I was and am also surprised. I do like the change but I'm not sure I like the
way the Debian project has decided this...

> So from now on we release "when it's time" instead of "when it's ready"?

I think you got this wrong: AIUI: we freeze, when it's time (and December can
become January or February... too) and release when it's ready. Sounds good
to me.


regards,
        Holger

[Steffen Möller]

Holger Levsen wrote:

> On Mittwoch, 29. Juli 2009, Frans Pop wrote:
>>> The Debian project has decided to adopt a new policy of time-based
>>> development freezes for future releases, on a two-year cycle.
>> Disappointing to see such an announcement without any prior discussion on
>> d-project, d-devel or d-vote.
>
> I was and am also surprised. I do like the change but I'm not sure I like the
> way the Debian project has decided this...

Same here. The release team, or the individual that pressed the button for the
announcement, I suggest to apologize for disturbing our community.

I don't think that there should be any formal rules on what kind of announcements can be
made with or without prior public discussion. Those would weaken us. We should trust our
delegates and allow them to react quickly and appropriately when required. The release
team has certainly discussed it all a lot and it may have felt like a public discussion to
them, but it was not. It is all a matter of taste IMHO, and here I sense some less
self-reflective maybe problematic judgement.

Steffen


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

[Alexander Reichle-Schmehl-2]

Hi!

Ben Pfaff schrieb:

> The URL in the announcement is 404.  Possibly a prank.

Sorry, no prank just a delay since we missed the website rebuild and
where to lazy to wait four hours for the announcement to be send out
after the next website build.


Best regards,
  Alexander


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

[Luk Claes]

Frans Pop wrote:
> On Wednesday 29 July 2009, Meike Reichle wrote:
>> The Debian project has decided to adopt a new policy of time-based
>> development freezes for future releases, on a two-year cycle.
>
> Disappointing to see such an announcement without any prior discussion on
> d-project, d-devel or d-vote. Some explanation of how and by who this
> decision was reached would be appreciated.

The Release Team proposed a plan in the keynote at DebConf. There were
some important considerations, but in general the audience welcomed the
plan.

The announcement was made to avoid confusion and unclear press coverage.

> So from now on we release "when it's time" instead of "when it's ready"?
> RC bugs are no longer relevant?

No, we freeze in time, we release when ready. RC bugs are still one of
the measures to see when we are ready.

Thanks for your feedback.

Cheers

Luk


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

[Alexander Reichle-Schmehl-2]

Hi!

Steffen Moeller schrieb:

> Same here. The release team, or the individual that pressed the button for the
> announcement, I suggest to apologize for disturbing our community.

The text was coordinated within the entire press team, our release
masters, the head of the technical commitee and the DPL.  IMHO there's
no need for an apology.


Best regards,
  Alexander


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

[Matthew Johnson-12]

On Wed Jul 29 09:59, Sandro Tosi wrote:

> of course, if we have to take formal steps for everything, we'll do a
> >> > predictability of time based releases with its well established policy of
> >> > feature based releases. The new freeze policy will provide better
> >> > predictability of releases for users of the Debian distribution, and also
> >>
> >> bullshit! we are trading quality for what? We release when it's ready,
> >> not when the clock ticks. it's completely a non-sense, and it's
> >> generating only bad feelings in developers and users.
> >
> > freeze != release, I'm not happy with the way the decision was
> > communicated. I beg you to mind your wording tough.
>
> I know it was unpolite, but it's the only way I can express my
> feelings right now.

The tone aside, I think it is important to note the difference between
freezing on time and releasing on time. The freeze date  is a cut-off
for new upstream releases, feature development etc. Having a well-known
in advance date by which people need to complete their feature
development, particularly one which we know is hard and not (as we've
had recently) liable to slip will give developers the ability to plan
better. I know that in the last release I was holding off from uploading
things which I could have done because I thought we were about to freeze
and wanted to allow things to move to testing, but we didn't freeze, at
least partly because other developers hadn't planned well enough to time
their uploads with the announced freeze date.

The release, however, will be when it's ready. We have said nothing
about how long the freeze will be. I'm hopeful that the scheduled
freezes will allow us to reduce the freeze time.


--
Matthew Johnson

[Steve Langasek]

On Wed, Jul 29, 2009 at 09:59:46AM +0200, Sandro Tosi wrote:
> >> 1. what about the developers that couldn't come to DC? don't we
> >> deserve to be asked for our opinion? are we of a lower class? is this
> >> a decision only made by a team and then you want to us to pretend the
> >> whole project decided it?

> > It is a delegate decision according to 2.5 of the constitution.

> so let's call it this way: not "Debian decided" but "a delegate
> decided on behalf of the project", I think this clarifies what
> happened.

I'm surprised that this was announced on debian-announce before it had first
been announced on d-d-a[1], since that does carry a higher risk that a
decision that has been announced to the general public may be reverted due
to lack of support.  Nevertheless, the distinction between "Debian decided"
and "a delegate decided on behalf of the project" is not one that is
relevant on debian-announce.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...

[1] It was announced at the release team keynote at DebConf, but obviously
not everyone will have had a chance to see that yet


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