Re: Debian decides to adopt time-based release freezes
Frans Pop
> 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
> 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-proj...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sune Vuorela
> --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.
>
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.
Sandro Tosi
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-----
Sandro Tosi
Hash: SHA1
On Wed, Jul 29, 2009 at 06:45, Sune Vuorela<nos...@vuorela.dk> 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-----
Goswin von Brederlow
> 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
Kartik Mistry
> 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
Martin Wuertele
> > 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
Sandro Tosi
> 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
Goswin von Brederlow
> On Wed, Jul 29, 2009 at 08:59, Goswin von Brederlow<goswi...@web.de> 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
Marc Haber
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
Sandro Tosi
> Sandro Tosi <mo...@debian.org> writes:
>
>> On Wed, Jul 29, 2009 at 08:59, Goswin von Brederlow<goswi...@web.de> 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
Sandro Tosi
> * Sandro Tosi <mo...@debian.org> [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
Holger Levsen
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 Moeller
> 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
Alexander Reichle-Schmehl
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
Matthew Johnson
> of course, if we have to take formal steps for everything, we'll do a
> >> > 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
Alexander Reichle-Schmehl
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
Luk Claes
> 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
Luk Claes
> On 2009-07-29, Frans Pop <ele...@planet.nl> 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=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.
Who would you like to propose a release cycle to the project if not the
Release Team?
To be clear the Release Team cannot just decide what the release cycle
will be, though we proposed a plan in the team's keynote at DebConf and
the plan was welcomed by the audience. There were some important
considerations though.
> 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 do not plan to do a yearly release, we plan to have a release about
every 2 years while having a one time exception for next release by
freezing this December.
> 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.
I guess you are talking about freezing this December and not in general?
Lets discuss the issues regarding KDE and see if we can come to a solution.
> ...and we still have the same kernel and X in testing as in stable.
Both of which are being worked on currently.
> 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]
The main reason is that the Release Team hopes to now have the momentum
to make a time based freeze work. If we would delay, it will very
probably mean that many developers 'forget' about what the time based
freeze is about.
> 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.
s/releases/release/
> By freezing after around 9 months of unstable we annoy the developers
> who wants to get stuff done before a release.
The developers have had the opportunity and still have the opportunity
to get stuff done before the release. It's true that developers should
probably consider to already be careful about what to upload, but there
is still opportunity to do changes till the freeze.
> And what happened to "when it is ready" ?
That has not changed at all. That's the reason we do not want to do a
time based release, we will only release when we are 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.
It's indeed the package maintainers that can make sure that the freeze
will take a long time. Though if they consider the points you made
earlier in this mail I'm confident that they will try to keep the freeze
short.
> I'm considering how we can get this decision undone. Anyone up for
> helping with that?
Very constructive... what plan do you have in mind that will be shared
by the Release Team and the project as a whole?
> [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.
Are you confident that KDE will be better at releasing in time and with
a higher quality than they are used to? Otherwise it looks to me like we
would need many more months before we can freeze KDE.
Cheers
Luk
Steve Langasek
> >> 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/
slan...@ubuntu.com vor...@debian.org
[1] It was announced at the release team keynote at DebConf, but obviously
not everyone will have had a chance to see that yet
Raphael Hertzog
> bullshit! we are trading quality for what?
Please don't be so aggressive and leave some time to RM to respond to your
comments before posting more mails....
> Or there's something else behind the curtains that it's not being said
> (consciously), like ubuntu LTS?
Yes, it was said in the RM keynote at debconf.
Note that the announce is meant mainly for the users/press, not for
developers.
But the idea of a press release came from the press team and not
necessarily from the RM. It would have been nice to have a simultaneous
announce for DD on d-d-a with more developer-oriented content.
> > 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
We are not only targetting big corporations. Either we do a full release
or we extend lenny to 3 years with lenny and a half. The release team
decided for the former.
It will be difficult but I think it's worth trying. As Colin commented in
the RM keynote, a one year release requires some discipline onto us, it's
not necessarily a bad idea to force ourselves into this.
> Not to mention how many angry replies are coming, I feel the community
> of debian developers is not accepting this decision silently.
I have almost never seen a decision that was not commented... that does
not mean that it won't last. The RM are entitled to take the decision and
while I was also surprised by it, I don't intend to work against it.
And there are many other people here at debconf that feel the same. You'll
see it in the video of the RM keynote.
Cheers,
--
Raphaï¿œl Hertzog
Mario Fux
> On 2009-07-29, Frans Pop <ele...@planet.nl> wrote:
Good morning
[snip]
> 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.
As a KDE and Debian user I'm mainly concerned about this. Why do I have to
miss every major release in January when Debian is freezed one month before?
KDE is a somehow quite big upstream. Why no better coordination?
Thx for your work
Mario
Ben Finney
> 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.
Ditto. Conferences are a great way to get a bunch of people together and
kick ideas around, but they are *not* the Annual General Meeting of the
project.
Issues this sweeping should only be decided via clear, open discussion
using the established communication channels wfor the project. A
conference that only a fraction of Debian members can attend is not such
a channel.
--
\ “Nature abhors a moron.” —Henry L. Mencken |
`\ |
_o__) |
Ben Finney
Marc Haber
> 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.
So that's the new secret cabal taking our decisions?
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
Julien Cristau
> Who would you like to propose a release cycle to the project if not
> the Release Team?
>
Nobody proposed anything, you announced a decision to debian-announce.
Without, as far as I can tell, any prior discussion with the developers
(as had happened before lenny, see
<87mz1di...@pindar.marcbrockschmidt.de> for an example). Why was
that not deemed necessary/appropriate this time around?
Cheers,
Julien
Marc Haber
> Who would you like to propose a release cycle to the project if not the
> Release Team?
>
> To be clear the Release Team cannot just decide what the release cycle
> will be, though we proposed a plan in the team's keynote at DebConf and
> the plan was welcomed by the audience. There were some important
> considerations though.
Nobody would have objected to a proposal. This was a press release,
which has already been picked up by the major news sites. You didn't
propose anything, you announced a 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
Marc Haber
> GR. I hoped that in this project we can discuss ideas instead of
> fight.
I think the way this decision was announced showed clearly that is was
not intended to have a discussion about this topic.
Grüße
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
Sune Vuorela
> Who would you like to propose a release cycle to the project if not the
> Release Team?
What I have seen so far, both from the press announcement and from the
video, it is not a proposal. it is a decision.
>
> To be clear the Release Team cannot just decide what the release cycle
> will be, though we proposed a plan in the team's keynote at DebConf and
> the plan was welcomed by the audience. There were some important
And some people just don't feel good about "taking the word" in such
audiences. So you only get feedback by a specific "kind" of people.
>> 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.
>
> I guess you are talking about freezing this December and not in general?
No. KDE releases january and july.
>> By freezing after around 9 months of unstable we annoy the developers
>> who wants to get stuff done before a release.
>
> The developers have had the opportunity and still have the opportunity
> to get stuff done before the release. It's true that developers should
> probably consider to already be careful about what to upload, but there
> is still opportunity to do changes till the freeze.
"Already be careful" yeah - that's exactly what I mean. We don't have
enough time to get stuff done.
>> 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.
>
> It's indeed the package maintainers that can make sure that the freeze
> will take a long time. Though if they consider the points you made
> earlier in this mail I'm confident that they will try to keep the freeze
> short.
As repeated. This is not the way to get the package maintainers to help
the release team.
>> I'm considering how we can get this decision undone. Anyone up for
>> helping with that?
>
> Very constructive... what plan do you have in mind that will be shared
> by the Release Team and the project as a whole?
I'm fine with the current "aim for 18 months, release after 21 months"
schedule that we have been doing with etch and lenny.
>
>> [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.
>
> Are you confident that KDE will be better at releasing in time and with
> a higher quality than they are used to?
I'm pretty confident that ubuntu will release with the newest kde -
unless they are planning to change what they have been doing ever since
they started on kde.
kde 4.1 released exactly on time. kde 4.2 released exactly on time.
kde4.3 is unfortunately going to slip 1 week.
And the kde developers have gotten much better in not letting as many
regressions in in third digit releases than in the 3.5 series.
> Otherwise it looks to me like we
> would need many more months before we can freeze KDE.
You can just freeze kde now if you want to.
/Sune
MJ Ray
> I do sincerely hope that there will be a GR to overrule this decision.
Hoping doesn't make it happen. I'm upset by the horribly botched
process, but I'm not willing to reverse this decision for that alone.
I doubt I'm unusual in that, so anyone looking for a GR proposer
probably should look at themselves.
I don't think there's a GR power to recall a delegate (even if we're
sure which individual delegates decided this) and it's a long time
until the next DPL election which could include delegate changes in
its platform, so what else can you do? Lobby the DPL? Amend the
constitution to make such a GR power? Complain on -project?
Regards,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Tshepang Lekhonkhobe
>> 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]
>
> The main reason is that the Release Team hopes to now have the momentum to
> make a time based freeze work. If we would delay, it will very probably mean
> that many developers 'forget' about what the time based freeze is about.
How about using this opportunity to help fulfill the Shuttleworth
dream of freezing both Ubuntu LTS and Debian at the same time? He self
mentioned he's willing to reach a 'compromise' if Debian or another
major distro is willing to co-operate, that is if it's willing to
freeze the same upstream versions of key components (Linux, X, GNU
toolkit, ...).
--
my place on the web:
floss-and-misc.blogspot.com
Luk Claes
> -----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.
No, the Release Team proposed a plan. The project is free to accept or
refuse the plan. Of course refusing the plan will have its consequences
within the Release Team as well as within the project.
>> 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.
The main advantage of a time based freeze would be that developers have
a clear idea about when the cutoff is for new features and when the
period of stabilising to a release starts. This should give developers a
better chance to plan and more responsibility in how they want to
support their packages.
>> 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.
The main reason is that we now have the momentum to try a time based
freeze and that delaying the freeze would cause developers to 'forget'
about what a time based freeze is about.
>> 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.
Hmm, you put it very negative while the intention is not at all how you
put it:
We will only release when we are ready to make sure we do not have to
trade quality.
We will freeze on a upfront specified date to give developers a chance
to better plan what should be included in the release.
> and predictability is the only advantage of this proposal? if so, then
> simply let's drop it: pro and cons are damn wrong.
No, see above.
>> 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.
True, this time we want to make sure we have the momentum to do a time
based freeze and maybe get some developers to think about shorter time
plans.
>> inconveniences caused for users. Having predictable freezes should also
>> reduce overall freeze time.
>
> should we remember here that lenny freeze took +6 months?
Note that how long the freeze takes is the responsibility of all
developers as the most important measure (RC bugs) can be influenced by
everyone.
>> 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?
Not at all. The Release Team proposed a plan and it was welcomed during
the team's keynote at DebConf. But your and others input is very much
appreciated.
The announcement was made to be sure that press coverage would not
differ from the actual message and confuse people. It seems it has not
reached that goal completely, though the intentions were good.
> 2. it doesn't seem all the attendants agreed with it, given what
> happened yesterday evening on #debian-release.
I don't know 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
Not at all.
> - - there is a constant drift away from debian by our users, this
> would be the killing shot
Why? We do try to take into account considerations to improve the usability.
> - - 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?
You could propose the skip one release if needed.
Cheers
Luk
Otavio Salvador
> 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.
It is quite strange, in my POV, that it wasn't discussed with main
teams (kernel, X, KDE, GNOME, d-i, ...) inside of Debian.
We all know that even Debconf has a lot of people most of those
projects hadn't people attending to the KeyNote and then this is not
the proper place to _propose_ a plan. This is suppose to have been
sent to debian-devel-announce, discussed and then after all announced.
AFAIK the main point of communication for Debian Developers are
debian-devel-announce and debian-announce. I was surprise that a
KeyNote is not a formal way of making proposals and GET resolutions
done.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Joerg Jaspert
>> 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".
I agree. For myself it would mean i can stop nearly any project for the
archive we have running currently, as all of them have the risk of
breaking something and needing time to fix it up. No source v3, no
debtags, no splitted Descriptions, all can go away thanks to this.
IMO it would have been much wiser to chose next December for the first
freeze, that would leave everyone enough time for their projects and not
cut them all away with the short remaining time.
> 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.
Here I disagree, even if I hate the way this is announced.
The Debian project did empower the Release Team to manage our
releases. We did not tell them "Manage the release by exactly following
whatever we did in the past". So they are entirely free to chose the way
a release is done.
What I agree with is that the whole announcement of this went out in the
uttermost stupid way that was possible to achieve. This is not to blame
the press team, its their job to send out such stuff when someone in
Debian approaches them and gives them useful content. The blame for this
is entirely on the Release Team which should have learned from prior
mistakes (like mine, hello DD levels).
A much better way of handling this would have been to have the
discussion during their DebConf session and then going to
debian-...@l.d.o and presenting it there. "Here, this is what we
intend to do, please comment, it will be released to the public soon".
(And fuck the press thats too dumb and takes "news" out of random
project lists).
> 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.
I agree.
> 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.
Well. If the announcement happens a year before (or more), then there is
nothing much needed. Freezes are to be expected and a timeline longer
than this would be ok.
> And what happened to "when it is ready" ?
Its the freeze, not the release. I doubt that this is thrown out, but it
is attached to the release, not freeze.
> I'm considering how we can get this decision undone. Anyone up for
> helping with that?
I object, but feel free to if you really must.
As I already said the Release Team *does* have the power to take such
decisions. If you go on with a GR you effectively take away this
power. Not that good an idea IMO.
Also, as we empowered them to do releases and finding the best way to do
them is one of their tasks - lets try this. If it doesn't work out,
heck, we can always change our minds.
I disagree with the "we announced it, we can't change our mind". Thats
wrong. We can tell people "Hey, we tested it, it doesn't work for us, we
are now going this other road".
Though I really suggest the release team to go and think about dropping
the freeze this December, but making it next one. *PLEASE* keep the
system open for development a bit longer. Thanks.
On 11826 March 1977, Luk Claes wrote:
> Who would you like to propose a release cycle to the project if not the
> Release Team?
This wasn't a proposal, this was a full fledged announcement and
decision. A proposal looks *much* different than a post to -announce.
> To be clear the Release Team cannot just decide what the release cycle
> will be, though we proposed a plan in the team's keynote at DebConf and
> the plan was welcomed by the audience. There were some important
> considerations though.
So, having like 20 (or a hundred) people within one talk room made this
the announce? Uh.
>> 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 do not plan to do a yearly release, we plan to have a release about
> every 2 years while having a one time exception for next release by
> freezing this December.
Please reconsider this and move the freeze a year later. A freeze this
december *does* block about aall interesting things that we would want
to happen in squeeze. Squeeze wouldnt be more than a lenny+0.8 release
then. And thats really nothing *I* would love to attach my name too.
>> I'm considering how we can get this decision undone. Anyone up for
>> helping with that?
> Very constructive... what plan do you have in mind that will be shared
> by the Release Team and the project as a whole?
Sorry, but this style of announce unfortunately asked for such replies.
>> The text was coordinated within the entire press team, our release
>> masters, the head of the technical commitee and the DPL.
> So that's the new secret cabal taking our decisions?
The release team, and the other people mentioned are hardly a secret
cabal. Don't be ridiculous.
On 11826 March 1977, Sandro Tosi wrote:
> 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.
It would be so nice if people could simply behave and keep civil
discussion tone.
On 11826 March 1977, Marc Haber wrote:
> I do sincerely hope that there will be a GR to overrule this decision.
I do sincerely hope noone is that stupid yet.
--
bye, Joerg
00:00:11 <LupusE> goebelmeier: http://ftp-master.debian.org/new.html <-
warum steht hier 'mplayer'? ist das eine whishlist?
Marc Haber
> Sandro Tosi wrote:
>> 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, the Release Team proposed a plan. The project is free to accept or
> refuse the plan. Of course refusing the plan will have its consequences
> within the Release Team as well as within the project.
My legal teacher once said (in German): "If you have a cow, it doesn't
matter whether or how often you write 'horse' on it, it will stay a
cow." The Release Team didn't propose a plan. It announced a
decision to the press.
> The main advantage of a time based freeze would be that developers have
> a clear idea about when the cutoff is for new features and when the
> period of stabilising to a release starts. This should give developers a
> better chance to plan and more responsibility in how they want to
> support their packages.
As a developer, I felt myself well-informed by the release time about
freeze and release time plans in the past. No need to change anything here.
> The announcement was made to be sure that press coverage would not
> differ from the actual message and confuse people.
The actual message was "this is how we're going to do things in the
future and no discussion about this is wanted".
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
Sune Vuorela
>> I'm considering how we can get this decision undone. Anyone up for
>> helping with that?
>
> I object, but feel free to if you really must.
> As I already said the Release Team *does* have the power to take such
> decisions. If you go on with a GR you effectively take away this
> power. Not that good an idea IMO.
I'm hoping that we can convince the release team to change their mind.
By reading Luk's replies in this thread and looking at the way this was
communicated, I'm not that confident that it will succeed.
Do we as developers have other ways to say "This is really bad, please
don't" other than doing a GR.
I do not want to disarm the release team in general, but I do want to
communicate that I find this (decision, process, timing) very bad for
debian, for me and for my motivation to do debian work.
If I end up having to choose wether to disarm the current release team
in general or not being able to properly communicate what I_think is
inappropriate, I guess I need to figure out what to do.
I really hope that release team will change its mind.
> Please reconsider this and move the freeze a year later. A freeze this
> december *does* block about aall interesting things that we would want
> to happen in squeeze. Squeeze wouldnt be more than a lenny+0.8 release
> then. And thats really nothing *I* would love to attach my name too.
Ack.
/Sune
Bernd Zeimetz
> Please reconsider this and move the freeze a year later. A freeze this
> december *does* block about aall interesting things that we would want
> to happen in squeeze. Squeeze wouldnt be more than a lenny+0.8 release
> then. And thats really nothing *I* would love to attach my name too.
>
Ack.
Not talking with the large packaging and infrastructure teams before making such
a decision and just deciding a fixed date is a complete failure of the release
team. Its the minimum we should be able to expect from them. Fixed and regular
freeze dates are nice to have, but not without finding a proper way and date to
begin. And making Ubuntu happy is *not* more important than the wishes of our
infrastructure teams or the KDE and Gnome teams.
If you really want to force a freeze in December, don't expect any help from me.
Probably a good time to find a new distribution then... or to start a GR. Not
sure what is better for my nerves.
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bernd Zeimetz
> On Wed, Jul 29, 2009 at 11:40, Luk Claes<l...@debian.org> wrote:
>>> 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]
>> The main reason is that the Release Team hopes to now have the momentum to
>> make a time based freeze work. If we would delay, it will very probably mean
>> that many developers 'forget' about what the time based freeze is about.
>
> How about using this opportunity to help fulfill the Shuttleworth
> dream of freezing both Ubuntu LTS and Debian at the same time? He self
> mentioned he's willing to reach a 'compromise' if Debian or another
> major distro is willing to co-operate, that is if it's willing to
> freeze the same upstream versions of key components (Linux, X, GNU
> toolkit, ...).
The only reason for this dream is to make sure that Debian fixes the Ubuntu bugs
for free.
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Daniel Baumann
> The project is free to accept or
> refuse the plan. Of course refusing the plan will have its consequences
> within the Release Team as well as within the project.
and by announcing this "plan" that *bold* to the whole world, you also
made perfectly sure that it is as unconvenient as possible for the
project to overrule an already announced RM decission, publicity-wise.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel....@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
Mark Brown
> Frans Pop wrote:
>> 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.
Was the possibility of doing the announcement without a specific freeze
date considered?
Bernd Zeimetz
> On Wed, Jul 29, 2009 at 06:45, Sune Vuorela<nos...@vuorela.dk> wrote:
>> I'm considering how we can get this decision undone. Anyone up for
>> helping with that?
>
me too. Obviously we need to force the release team to talk with the important
teams in Debian. If i'd have to come up with a GR it would probably sound like
"While we appreciate the plan of fixed freeze cycles, the plan to start them in
December 2009 is not acceptable for the project. We ask the release team to talk
with all important teams (kernel, d-i, kde, gnome, ftp-master, dsa,....) to find
an appropriate date."
Of course its not easy to find a date which makes all teams completely happy,
but the release team should try to do so at least.
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Armin Berres
> Sune Vuorela wrote:
> I guess you are talking about freezing this December and not in general?
>
> Lets discuss the issues regarding KDE and see if we can come to a solution.
Good. So let me propose something.
> Are you confident that KDE will be better at releasing in time and
> with a higher quality than they are used to? Otherwise it looks to
> me like we would need many more months before we can freeze KDE.
Yes, we are quite sure, that KDE will release in time. KDE 4.3 released
slipped a week, but all the RCs have already been very stable.
You want to try something with the next release? So let me propose the
following: We ship the exactly same Upstream KDE as Ubuntu -- talking
about version numbers here. This really allows us to use the momentum
between Debian and Ubuntu on the Desktop front. Everything else is just
useless.
In the end this means: In January we put 4.4 (or maybe even the RCs, as
they are normally stable) into unstable, and later we also put the 4.4.1
and 4.4.2 (maybe also 4.4.3) into unstable. I am very sure we will not
not introduce RC bugs which will not be fixed within very less days, but
we will fix a lot of minor bugs with the uploads. Your job is just to
unblock the fun then :)
In the freeze times, the changes happening to the KDE packages are very
marginal. We do win nothing by freezing that long (and yes, I do not
believe the freeze is over after 3 months).
So, do you think we can manage to ship Squeeze with the best KDE ever,
to make Squeeze the best Debian ever, and at the same time align with
Ubuntu which will release before us?
Greetings,
Armin
member of the Debian Qt KDE team
Nico Golde
* Sune Vuorela <nos...@vuorela.dk> [2009-07-29 12:07]:
> On 2009-07-29, Luk Claes <l...@debian.org> wrote:
> > Who would you like to propose a release cycle to the project if not the
> > Release Team?
>
> What I have seen so far, both from the press announcement and from the
> video, it is not a proposal. it is a decision.
Why is that such a big problem for you? I mean without
stating my opinion about the content of this decision itself
I think as it's the release teams job to make such decisions
and for myself just trust them that this is the best
decision for the project. Everyone is free to join the
release team and take part in such discussions if you really
want that. I am not sure either whether that is a good
decision or not but I feel not competent enough in the area
of release team work to 100% judge that so I just trust in
their work and their experience. That's what teams are for,
reducing workload.
The only thing that really bugs me a bit that the security
team hasn't been contacted about this beforehand as well and
as we need to support the releases this sucks a bit. But
well, let's see what happens and LART them later in case of
problems.
Cheers
Nico
--
Nico Golde - http://www.ngolde.de - ni...@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.
Otavio Salvador
On Wed, Jul 29, 2009 at 8:45 AM, Nico Golde<ni...@ngolde.de> wrote:
> The only thing that really bugs me a bit that the security
> team hasn't been contacted about this beforehand as well and
> as we need to support the releases this sucks a bit. But
> well, let's see what happens and LART them later in case of
> problems.
Specially because RM team expect us, as developers, to support
upgrades from 5.0 to 7.0; this means that Security Team will need to
support Debian 5.0, Debian 6.0 and Debian 7.0 at SAME time.
I'd like to hear from RM team how they expect it to be done since they
ought to have though about that when _planning_ this schedule.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Alexander Reichle-Schmehl
Marc Haber 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.
> So that's the new secret cabal taking our decisions?
Yes, of course. Tomorrow we planed to decide to grant us a bonus on our
payment, since we think we are doing a good job.
No, seriously: Steffen suggested the one who pressed the button for the
announcement to apologise. I answered, that the ones, who pressed the
button, where simply doing their job with the OK from several "instances
above". If you don't like that, don't shoot the messenger, because they
might get sick of being shooten at at every occasion; thanks.
Best regards,
Alexander
Thijs Kinkhorst
> If you don't like that, don't shoot the messenger, because they
> might get sick of being shooten at at every occasion; thanks.
I think an important critic in this thread is the way the message was
brought: DD's like myself are learning of this decision from a press
release. Affected teams haven't been asked or even informed beforehand.
This is definitely something that the 'messenger' should have considered
before deciding to take this route to announce the plan, don't you think?
Thijs
Stephen Frost
> I'm hoping that we can convince the release team to change their mind.
I doubt you can, and I hope you don't. It could have been announced
better, but in general I think it's a good thing for Debian. Please get
over how it was announced.
Thanks,
Stephen
Stephen Frost
> > 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.
Having a fixed freeze start helps people plan, of course. Having a
release date goal helps make it happen.
Just to toss out another example, PostgreSQL has been trying to get to a
time-based release system for a while. It's getting pretty close now,
but these things take time and there will be challenges ahead. Overall,
I think this is a good thing for Debian.
Thanks,
Stephen
Joerg Jaspert
>> 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, the Release Team proposed a plan. The project is free to accept or
> refuse the plan. Of course refusing the plan will have its consequences
> within the Release Team as well as within the project.
So you basically try to suppress all discussion by issuing an "eat this
or get another release team"?
>> and what are the real advantages of this? I saw none in this announce.
> The main advantage of a time based freeze would be that developers have
> a clear idea about when the cutoff is for new features and when the
> period of stabilising to a release starts. This should give developers a
> better chance to plan and more responsibility in how they want to
> support their packages.
I don't think anyone is arguing against the time based freeze way of
doing things.
The arguments go against the way you announced this *and* the extremely
short timeframe you leave the project to develop its distribution, thus
limiting squeeze to be just a lenny point release, compared to what we
had in prior releases.
>> 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.
> The main reason is that we now have the momentum to try a time based
> freeze and that delaying the freeze would cause developers to 'forget'
> about what a time based freeze is about.
Sorry, you are happily destroying the momentum for a lot of people in
core and large teams.
>> should we remember here that lenny freeze took +6 months?
> Note that how long the freeze takes is the responsibility of all
> developers as the most important measure (RC bugs) can be influenced by
> everyone.
And thats why the Release Team should gather the developers behind them,
not in front against them. :)
> Not at all. The Release Team proposed a plan and it was welcomed during
> the team's keynote at DebConf. But your and others input is very much
> appreciated.
It was welcomed by how many people? A dozen? Uh.
> The announcement was made to be sure that press coverage would not
> differ from the actual message and confuse people. It seems it has not
> reached that goal completely, though the intentions were good.
s/completly/at all/.
Really, the press is *unimportant* compared to communication *within*
the project. We are not a company which income depending on them. If the
press is dumb enough to take a story out of a non-announce list, then
fine, idiots everywhere. But that shouldn't have stopped you from
talking to *the* *project* first, instead of to press monkeys (our
press@ not meant with that).
--
bye, Joerg
Some NM:
Debian is mostly about free keysigning^Wspeech.
Steve Langasek
> > count me in.
> me too. Obviously we need to force the release team to talk with the
> important teams in Debian. If i'd have to come up with a GR it would
> probably sound like "While we appreciate the plan of fixed freeze cycles,
> the plan to start them in December 2009 is not acceptable for the project.
> We ask the release team to talk with all important teams (kernel, d-i,
> kde, gnome, ftp-master, dsa,....) to find an appropriate date."
Would *you* intend to talk to all of these teams, before starting a GR
declaring that the proposed timeline is not acceptable to them?
--
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/
slan...@ubuntu.com vor...@debian.org
Alexander Reichle-Schmehl
Thijs Kinkhorst schrieb:
>> If you don't like that, don't shoot the messenger, because they
>> might get sick of being shooten at at every occasion; thanks.
> I think an important critic in this thread is the way the message was
> brought: DD's like myself are learning of this decision from a press
> release. Affected teams haven't been asked or even informed beforehand.
>
> This is definitely something that the 'messenger' should have considered
> before deciding to take this route to announce the plan, don't you think?
Please try to put yourself in our (the press teams) place:
* In the release teams keynote a major change is announced
* It is clear, that the topic will be picked up by journalists
* It is also clear, that the topic will sooner or later be seen on
planet.debian.org or some mailing list
As press team we can either wait for journalists to pick it up from
random blog posts and mails or we can try to draft an official
announcement, get it OKed by as much involved people as possible. If
possible we will decide on the later option to prevent confusion or
articles written based on biased blogs or mails, otherwise we would do a
very bad job to Debian by just waiting.
If you don't like what was announced, feel free to discuss it the
release team. But don't blame us for doing our job.
Best regards,
Alexander
Bernd Zeimetz
> On Wed, Jul 29, 2009 at 01:36:16PM +0200, Bernd Zeimetz wrote:
>>> count me in.
>
>> me too. Obviously we need to force the release team to talk with the
>> important teams in Debian. If i'd have to come up with a GR it would
>> probably sound like "While we appreciate the plan of fixed freeze cycles,
>> the plan to start them in December 2009 is not acceptable for the project.
>> We ask the release team to talk with all important teams (kernel, d-i,
>> kde, gnome, ftp-master, dsa,....) to find an appropriate date."
>
> Would *you* intend to talk to all of these teams, before starting a GR
> declaring that the proposed timeline is not acceptable to them?
Where did I say that the timeline is not acceptable for the teams?I said the
timeline is not acceptable at all. And you should talk to the teams to find a
proper date.
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Anthony Towns
> 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.
> d-project, d-devel or d-vote.
Sure makes the dicussion harder and more confrontational, if nothing else.
Are we trying to make people long for the days of [0]?
[0] http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
> Some explanation of how and by who this
> decision was reached would be appreciated.
For one, it'd be fascinating to know why it's a two year cycle starting
about one year from the last release instead of about two. I'm presuming
the answer is "It'd be awkward for Ubuntu to sync with, given their
last LTS release was early 2008 and they've kind-of promised two year
cycles". I'm not seeing why a freeze anywhere in March-July in even
years wouldn't suffice for both issues though.
For two, it means squeeze is getting a ten month development phase
(mid Feb to sometime in Dec), of which five-and-a-half months have
already gone. So, hey, downhill run with only, uh, 1100-odd RC bugs to
fix. We've never had that many RC bugs to fix before, but we had about
600 nine-months before lenny released, and I guess about 400 when lenny
froze this time last year.
For three, what happened to getting the firmware issue resolved early in
squeeze's cycle [1]? It's evidently no longer early in squeeze's cycle,
so maybe I just somehow missed the decision on that...
[1] http://lists.debian.org/debian-vote/2009/05/msg00000.html
As far as making decisions at debconf (or irc) rather than via the
lists goes, I read an article about PowerPoint use in the military
[2] that strikes me as kinda parallel: having time to look over these
proposals calmly first rather than having to immediately react seems
generally helpful.
[2] http://www.afji.com/2009/07/4061641
And, umm, presuming Debian manages a five month freeze (ie, 1.5
months less than lenny's), and it releases in April, as presumably
does Ubuntu 10.04 LTS (leisuresuit lorikeet?), why bother running
Debian stable? Ubuntu comes with paid, full-time security support;
it'll have pretty much everything Debian does, and probably a bit more;
its popularity will probably provide better hardware support including
preinstalled systems in some cases... And hey, for machines still running
etch, it'll probably be just as easy to upgrade to Ubuntu as it would
be to skip lenny and go to squeeze.
Someone remind me why it'll be worth caring about stable?
Cheers,
aj
Giacomo Catenazzi
> The main reason is that the Release Team hopes to now have the momentum
> to make a time based freeze work. If we would delay, it will very
> probably mean that many developers 'forget' about what the time based
> freeze is about.
Is it so important this momentum? Is it grave, for DD, to forget about
release cycles? We have debian new that will remember us our duties.
Anyway, in next weeks could you (RM in general) give some more precise
plan about next releases? and what DD should do/not do in next few
months?
We changed this week the default shell, we changed this week the init.d
mechanism, it was proposed to pass shortly to upstart.
There was announced plan to dpkg-source version 3. I see a lot changes,
but few time. How do we must handle it? What plan has RM to maintain
Debian quality? Did you skip some changes?
ciao
cate
PS: dpkg-source version v3 was announced very early: good. But I find
lack of announcement of other important changes, could the RM announce
earlier huge plans.
PS: is it only an impression or there is a plan to block
Debian specific changes (src v3), destructive for ubuntu and go to
Ubuntu essential programs (insserv/upstrart) in so short time?
We must care as priority our quality. The quality of derivatives
should come only as later priority.
Steve Langasek
> >> If you don't like that, don't shoot the messenger, because they
> >> might get sick of being shooten at at every occasion; thanks.
> > I think an important critic in this thread is the way the message was
> > brought: DD's like myself are learning of this decision from a press
> > release. Affected teams haven't been asked or even informed beforehand.
> > This is definitely something that the 'messenger' should have considered
> > before deciding to take this route to announce the plan, don't you think?
> Please try to put yourself in our (the press teams) place:
> * In the release teams keynote a major change is announced
> * It is clear, that the topic will be picked up by journalists
I wonder why this is clear, exactly - I didn't notice journalists in the
room during the talk, and I doubt they're watching the DebConf video feed in
realtime. Don't you think there was time here to have a developer
announcement + discussion first, without worrying about the press covering
it before we'd even posted to d-d-a?
One of the reasons I heard mentioned here at DebConf for putting out a press
release was to give our *users* as much warning as possible that the release
cycle would be different, so that they could plan accordingly. I think this
was a good reason for doing a press release soon; I don't think it was
urgent to have it happen immediately, and I think having it happen this way
has had an unfortunate effect on the developer discussion process.
(Which is still an important and necessary process, even if some people
currently feel the release team is shoving this decision down their throats
- if there are problems with the proposed plan, we can only fix those and
make the next Debian release as great as possible by discussing them
respectfully and working together to solve them.)
--
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/
slan...@ubuntu.com vor...@debian.org
Ana Guerrero
> On Wed, Jul 29, 2009 at 12:29 PM, Goswin von Brederlow<goswi...@web.de> 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)?
>
There was NOT (public) discussion in debconf about this, it was just presented
in the keynote as taken decision.
Ana
Stefano Zacchiroli
> Do we as developers have other ways to say "This is really bad, please
> don't" other than doing a GR.
Well, if you *really* want to do that, I've a technical device to
offer. In the past days, by coincidence, I've worked to setup a
devotee instance on master.d.o, run by myself, with the purpose of
taking polls as we usually vote for GR.
That way, we can ask developers opinion, being sure only DDs vote,
still avoiding taking decisions which might reveal themselves too
constraining in the near future, as Joerg observed.
The reason I stressed "really" above is twofold:
1) while everything seems to be working fine, there are still some
rough edges (e.g. the vote graphs do not work properly yet). If you
intend to go this way, remember that you've been warned :-)
2) I agree that taking the "time-based release" is a decision which
the Release Team has the right to take by the authority which the
project has given them.
So it should be either this decision, or a GR to overrule.
Practically, if you want me to set it up, I can do that fairly
quickly, but I would love having someone to test it with me. Once it
is ready, I guess it can be announced here (and on -vote).
Let me know if you, or anybody else, like the idea.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Ana Guerrero
>
> The Release Team proposed a plan in the keynote at DebConf. There
> were some important considerations, but in general the audience
> welcomed the plan.
>
I am sorry Luk, but keeping in silent does not mean agreing with what has been
said. I think large part of the audience just was very surprised and wanted
to think deeper about the idea before raise properly argued concerns.
Ana Guerrero
> Sune Vuorela wrote:
>
> >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.
>
>
> Lets discuss the issues regarding KDE and see if we can come to a solution.
>
With my KDE hat on, I am sure we can disscuss about this and maybe get a
solution, but it would have been nicer if you have discuss this issues with
any team *before* making any plans.
Alexander Reichle-Schmehl
Steve Langasek schrieb:
>> Please try to put yourself in our (the press teams) place:
>> * In the release teams keynote a major change is announced
>> * It is clear, that the topic will be picked up by journalists
> I wonder why this is clear, exactly - I didn't notice journalists in
> the room during the talk, and I doubt they're watching the DebConf
> video feed in realtime.
That was meant in a more general way: It seemed to me clear, that such
a change would be picked up by the journalists as soon as they get to
know. I think you agree on that?
So taking into consideration the third point it was just a matter of
time before it would hit the press. And therefore we had the choice to
wait and let journalists pick random stuff (and the risk, that they
don't understood it completely (which journalists don't stop from still
writing)) or do what we did: Send out an announcement for them to base
their articles on (and hope, that we are easy enough for them).
> Don't you think there was time here to have a developer announcement
> + discussion first, without worrying about the press covering it
> before we'd even posted to d-d-a?
That's not important; independently of whether there was time for mail
to d-d-a or not, it's not the press teams job to keep Developers
informed. The press teams job is "external" communication.
So if you want to blame us, then blame us for the being out of sync
regarding "internal" and "external" communication.
Best regards,
Alexander
Aurelien Jarno
> The Debian project has decided to adopt a new policy of time-based
> development freezes for future releases, on a two-year cycle.
I am fine with that, at least I think we should give a chance to this
method. They are some concerns about bad synchronisation with some
upstream projects, but I am sure we can find some arrangements.
> Freezes
> 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.
I have a lot more problems with that. If this short release cycle had
been announced a few weeks after the release of Lenny, it would have
been fine. With such a late announce, a lot of developers and teams have
already made their schedule and plans based on a roughly 2 year release
for Squeeze, and it is really frustrating to have cut them down.
I am also really concerned by the state of the release team. Sid is
opened again for 5 months, and the freeze will happen in 5 months, so we
are just in the middle. If we look a bit what happens on the release
team since the release of Lenny, it has simply been absent. A lot of
mails on debian-release about hints or binNMU are ignored, mails about
transitions are answered very late. The recent MySQL transition is just
an example. Last but not least, the transitions are not really managed
and take a lot of time (for example QEMU is blocked out of testing for 2
months due to the bluez transition).
That's why I would like to ask a single question to the release team:
What are your plans to ensure the development process of Squeeze
is not slowed down by migration and transitions issues? Or said
otherwise how the release team is going to ensure fast reaction
to the requests on the mailing list and short transitions (more
one week than two months)?
The three new release assistants seems to be a first answer to that, but
I really doubt it is enough.
Cheers,
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aure...@aurel32.net http://www.aurel32.net
Peter Samuelson
[Luk Claes]
> Who would you like to propose a release cycle to the project if not
> the Release Team?
So this is a proposal?
The Vancouver proposal should have taught us a lesson: when you
announce a big change, if you truly intend for it to be a proposal to
be discussed, you have to state this clearly, or people will get upset
at what they see as a fait accompli.
>> 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?
> The main reason is that the Release Team hopes to now have the
> momentum to make a time based freeze work. If we would delay, it will
> very probably mean that many developers 'forget' about what the time
> based freeze is about.
This rationale doesn't seem very plausible, for two reasons.
First, what need is there for "momentum"? Announce "the freeze will be
in Dec 2010" and, if you think we will forget about it, periodically
remind us via those bits-of-the-RMs style mails.
Second, what is new about time-based freezing? Wasn't that what we did
for lenny? The release team had a graduated freeze schedule in place
well in advance, and tried hard to stick to it. What is different next
time?
There've been a lot of rumors that the 10 months until squeeze freeze
has more to do with trying to benefit Ubuntu LTS, than anything about
"momentum". This unfortunately sounds a lot more plausible to me. If
it is correct, I'd rather you just said so up front.
(For the record, it still wouldn't make me _happy_. Cui bono? I
believe freezing four months before an Ubuntu LTS release would not
benefit Debian at all. Freezing _after_ an LTS release, or at least
after an LTS freeze, would help Debian quite a lot more.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Anthony Towns
> 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
> no need for an apology.
It's remarkable how often people who should be apologising don't think
there's cause for an apology. Personally, I would suggest that the
"press team" made the mistake here of making an announcement on behalf
of the project of something pretty major that hadn't actually already
been discussed on any developer lists. I'm very surprised that neither
Bdale nor Steve made that point...
On Wed, Jul 29, 2009 at 04:30:07PM +0200, Alexander Reichle-Schmehl wrote:
> That was meant in a more general way: It seemed to me clear, that such
> a change would be picked up by the journalists as soon as they get to
> know. I think you agree on that?
Yeah. Journalists do things like that. It's one of the costs of working
in public.
> That's not important; independently of whether there was time for mail
> to d-d-a or not, it's not the press teams job to keep Developers
> informed. The press teams job is "external" communication.
Yes, and announcing this as a finished decision before it's even been
discussed amongst the developers is very misleading.
Cheers,
aj, watching master get shutdown as he types
Manoj Srivastava
> On Wed, Jul 29, 2009 at 01:36:16PM +0200, Bernd Zeimetz wrote:
>> > count me in.
>
>> me too. Obviously we need to force the release team to talk with the
>> important teams in Debian. If i'd have to come up with a GR it would
>> probably sound like "While we appreciate the plan of fixed freeze cycles,
>> the plan to start them in December 2009 is not acceptable for the project.
>> We ask the release team to talk with all important teams (kernel, d-i,
>> kde, gnome, ftp-master, dsa,....) to find an appropriate date."
>
> Would *you* intend to talk to all of these teams, before starting a GR
> declaring that the proposed timeline is not acceptable to them?
Feh. Do as I say, not as I do.
manoj
--
Alcohol, hashish, prussic acid, strychnine are weak dilutions. The
surest poison is time. -- Emerson, "Society and Solitude"
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> Who would you like to propose a release cycle to the project if not
> the Release Team?
A proposal would have been absolutely appropriate, with
discussions by various teams as to the best time to freeze.
> To be clear the Release Team cannot just decide what the release cycle
> will be, though we proposed a plan in the team's keynote at DebConf
> and the plan was welcomed by the audience. There were some important
> considerations though.
The audience for the talk was what fraction of the developer set?
> We do not plan to do a yearly release, we plan to have a release about
> every 2 years while having a one time exception for next release by
> freezing this December.
Why? There are development plans underway by folks (and yes, I
am one of them) where packages will be polished for release about a
year from now -- and the short release cycle throws a monkey wrench
into the works.
Why was this not discussed before hand? Are we so beholden to
canonical that we must slave our releases to their LTS? I thought they
borrowed our code, not the other way around.
> The main reason is that the Release Team hopes to now have the
> momentum to make a time based freeze work. If we would delay, it will
> very probably mean that many developers 'forget' about what the time
> based freeze is about.
If you want to get the developers behind your release schedule,
keeping us in the loop is a better idea. As such, it seems to me you
think that treating developers like mushrooms will have no impact on
your precious release schedule. I think you might find that the
release team can't make releases on its own.
> The developers have had the opportunity and still have the opportunity
> to get stuff done before the release. It's true that developers should
> probably consider to already be careful about what to upload, but
> there is still opportunity to do changes till the freeze.
I see no reason for developers kept out in the cod to do so;
really. While the release team might be constitutionally delegated to
decide when to release on a whim, the developers are also
constitutionally protected from having to do something they do not want
to.
manoj
--
Sigmund Freud is alleged to have said that in the last analysis the
entire field of psychology may reduce to biological electrochemistry.
Manoj Srivastava
> Hi,
> * Sune Vuorela <nos...@vuorela.dk> [2009-07-29 12:07]:
>> On 2009-07-29, Luk Claes <l...@debian.org> wrote:
>> > Who would you like to propose a release cycle to the project if not the
>> > Release Team?
>>
>> What I have seen so far, both from the press announcement and from the
>> video, it is not a proposal. it is a decision.
> [...]
> Why is that such a big problem for you? I mean without
> stating my opinion about the content of this decision itself
> I think as it's the release teams job to make such decisions
> and for myself just trust them that this is the best
> decision for the project. Everyone is free to join the
And if I feel that is not the best decision for the users of my
package?
manoj
--
Try not to have a good time ... This is supposed to be
educational. Charles Schulz
Manoj Srivastava
> 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.
I think that just expands the set of people who owe an apology.
manoj
--
sillema sillema nika su
Manoj Srivastava
> The Debian project did empower the Release Team to manage our
> releases. We did not tell them "Manage the release by exactly following
> whatever we did in the past". So they are entirely free to chose the way
> a release is done.
�2.1. General rules
1. Nothing in this constitution imposes an obligation on anyone to do
work for the Project.
So the developers are then within their rights to ignore the
short first freeze, and work to release whenever the packages are
really ready.
manoj
--
"I don't believe in psychology. I believe in good moves." Bobby Fischer
Manoj Srivastava
Well, yes and no. I think a freeze every two years is a good
idea. I just do not think that we should freeze in 5 months or so.
manoj
--
God is real, unless declared integer.
Manoj Srivastava
> (Which is still an important and necessary process, even if some people
> currently feel the release team is shoving this decision down their throats
> - if there are problems with the proposed plan, we can only fix those and
> make the next Debian release as great as possible by discussing them
> respectfully and working together to solve them.)
Really? I doubt that the effort to get the next release of
debian to a state where we can ock down a out of the box install or
virtual machine with selinux strict policy is going to get any
consideration at all.
All the short first release cyce seems to do is to ensure that
canonical's LTS will always be a more compelling product than a Debian
release, being slightly newer and improved. Does not sound like a win
for Debian (just makes us even more irrelevant).
manoj
--
It is the quality rather than the quantity that matters. Lucius Annaeus
Seneca (4 B.C. - A.D. 65)
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Jonathan Wiltshire
> On Wed, Jul 29, 2009 at 10:49:40AM +0000, Sune Vuorela wrote:
> > Do we as developers have other ways to say "This is really bad, please
> > don't" other than doing a GR.
>
> Well, if you *really* want to do that, I've a technical device to
> offer. In the past days, by coincidence, I've worked to setup a
> devotee instance on master.d.o, run by myself, with the purpose of
> taking polls as we usually vote for GR.
In a broader sense, the ability for proposers of ideas to take a straw
poll in this manner could be valuable for getting an idea of what the
general developer community thinks. In my experience of some lists, it
seems that developers aren't willing to get drawn into a long discussion
but might welcome an opportunity to say 'yes', 'work on it more' or 'no'
and then get back to work.
However, there are many contributors who aren't eligible to vote on GRs
because they are not full DD yet, including me, yet the 'proposal' we're
discussing affects us deeply too. Might you find a way to include us (maybe
the DM keyring is a good start)?
--
Jonathan Wiltshire
1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Michael Banck
> On Wed, Jul 29, 2009 at 11:40:30AM +0200, Luk Claes wrote:
> > Sune Vuorela wrote:
> >
> > >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.
> >
> > I guess you are talking about freezing this December and not in general?
> >
> > Lets discuss the issues regarding KDE and see if we can come to a solution.
> >
>
> With my KDE hat on, I am sure we can disscuss about this and maybe get a
> solution, but it would have been nicer if you have discuss this issues with
> any team *before* making any plans.
Well, you have to draw the line somewhere - we skipped KDE4 with lenny
and will apparently skip GNOME3 with squeeze. I understand that some
teams are unhappy not having been contacted before (maybe the security
team being the most important, IMHO), but I don't think there is a
historical precedence (or even clear desire) of the release team
contacting lots of teams beforehand on release timeline decisions.
Michael
Stefano Zacchiroli
> Ditto. Conferences are a great way to get a bunch of people together
> and kick ideas around, but they are *not* the Annual General Meeting
> of the project.
>
> Issues this sweeping should only be decided via clear, open
> discussion using the established communication channels wfor the
> project. A conference that only a fraction of Debian members can
> attend is not such a channel.
Please, everybody, stop this kind of "you evil DebConf attendees have
decided for us all" arguments. The "time-based freeze" has been
announced/proposed during a talk at DebConf; it was fresh news for the
attendees as it was fresh news for everybody else receiving it via
-announce a few hours later.
Martin Wuertele
> Please, everybody, stop this kind of "you evil DebConf attendees have
> decided for us all" arguments. The "time-based freeze" has been
> announced/proposed during a talk at DebConf; it was fresh news for the
> attendees as it was fresh news for everybody else receiving it via
> -announce a few hours later.
And that makes it any better?
Yours Martin
Francesco P. Lovergine
>
> Well, yes and no. I think a freeze every two years is a good
> idea. I just do not think that we should freeze in 5 months or so.
>
+1
--
Francesco P. Lovergine
Steve Langasek
> >> me too. Obviously we need to force the release team to talk with the
> >> important teams in Debian. If i'd have to come up with a GR it would
> >> probably sound like "While we appreciate the plan of fixed freeze cycles,
> >> the plan to start them in December 2009 is not acceptable for the project.
> >> We ask the release team to talk with all important teams (kernel, d-i,
> >> kde, gnome, ftp-master, dsa,....) to find an appropriate date."
> > Would *you* intend to talk to all of these teams, before starting a GR
> > declaring that the proposed timeline is not acceptable to them?
> Feh. Do as I say, not as I do.
Thanks for your helpful contribution to this discussion.
--
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/
slan...@ubuntu.com vor...@debian.org
Bernhard R. Link
> Please, everybody, stop this kind of "you evil DebConf attendees have
> decided for us all" arguments. The "time-based freeze" has been
> announced/proposed during a talk at DebConf; it was fresh news for the
> attendees as it was fresh news for everybody else receiving it via
> -announce a few hours later.
Well, it was not totally fresh news. After all there was already
http://derstandard.at/1246541995003/Interview-Shuttleworth-about-GNOME-30---Whats-good-whats-missing-what-needs-work
(which was linked from slashdot and other sides).
Not sure if this makes the situation much better. But it was not
actually totally surprising.
Hochachtungsvoll,
Bernhard R. Link
Marc Haber
> * Stefano Zacchiroli <za...@debian.org> [090729 18:22]:
> > Please, everybody, stop this kind of "you evil DebConf attendees have
> > decided for us all" arguments. The "time-based freeze" has been
> > announced/proposed during a talk at DebConf; it was fresh news for the
> > attendees as it was fresh news for everybody else receiving it via
> > -announce a few hours later.
>
> Well, it was not totally fresh news. After all there was already
> http://derstandard.at/1246541995003/Interview-Shuttleworth-about-GNOME-30---Whats-good-whats-missing-what-needs-work
> (which was linked from slashdot and other sides).
Call me paranoid, but this looks to me like Ubuntu's cash source knew
more about our release team's innards than Debian itself. This is
wildly disturbing.
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
Stefano Zacchiroli
> > Please, everybody, stop this kind of "you evil DebConf attendees have
> > decided for us all" arguments. The "time-based freeze" has been
> > announced/proposed during a talk at DebConf; it was fresh news for the
> > attendees as it was fresh news for everybody else receiving it via
> > -announce a few hours later.
> And that makes it any better?
Please read what I wrote and refrain from stretching it. What I
reported does not make it neither better, nor worse; it just states
that the merits of the issues have nothing to do with DebConf9.
Ben Pfaff
> Frans Pop <ele...@planet.nl> 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.
Not every Debian developer attends Debconf. Did the explanations
or discussions there ever get passed along to the developers who
did not attend? I do not remember seeing any.
--
Ben Pfaff
http://benpfaff.org
Ana Guerrero
> team being the most important, IMHO), but I don't think there is a
> historical precedence (or even clear desire) of the release team
> contacting lots of teams beforehand on release timeline decisions.
>
For the record, mail"KDE plans for the lenny cycle":
http://lists.debian.org/debian-release/2007/04/msg00155.html
If you go to:
http://lists.debian.org/debian-release/2007/04/threads.html
you will see a lot of teams being asked.
I was expecting for something similar when making the plans for the squeeze
cycle.
Ana
Fathi Boudra
> Well, you have to draw the line somewhere - we skipped KDE4 with lenny
> and will apparently skip GNOME3 with squeeze.
This way, we still continue to lose desktop users and the same apply
to stable/server users (Debian stable vs Ubuntu LTS).
Otavio Salvador
> * Stefano Zacchiroli <za...@debian.org> [090729 18:22]:
>> Please, everybody, stop this kind of "you evil DebConf attendees have
>> decided for us all" arguments. The "time-based freeze" has been
>> announced/proposed during a talk at DebConf; it was fresh news for the
>> attendees as it was fresh news for everybody else receiving it via
>> -announce a few hours later.
>
> Well, it was not totally fresh news. After all there was already
> http://derstandard.at/1246541995003/Interview-Shuttleworth-about-GNOME-30---Whats-good-whats-missing-what-needs-work
> (which was linked from slashdot and other sides).
It is quite nice to notice that _our_ /dear/ Release Team was in touch
with Ubuntu (nothing wrong with that) but forgot to get in touch with
us ;-)
There's nothing wrong and discuss plans with other projects and share
ideas; what is completely wrong is to not discuss it with us specially
because WE ARE THE ONES THAT ARE GOING TO MAKE IT (NOT) HAPPEN.
> Not sure if this makes the situation much better. But it was not
> actually totally surprising.
Sure it helps; it makes clear the importance we have for RM people.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Gustavo Franco
behalf of debian installer team.
I'm sure d-i team is very important to RM team. Communication is far
from being a strong quality of this project, with that in mind could
you please try to dissociate a little from the whole thing and raise
points against a time-based release freeze from d-i team point of
view?
I really want to know, but from your previous message all I see is
"screw you RM team, you talked to Ubuntu folks and didn't talk to our
direct peers so we will make that fail". I'm sorry if it wasn't the
statement you wanted to share.
regards,
-- Gustavo "stratus" Franco
Teemu Likonen
> I believe freezing four months before an Ubuntu LTS release would not
> benefit Debian at all. Freezing _after_ an LTS release, or at least
> after an LTS freeze, would help Debian quite a lot more.
I believe the same. Mark Shuttleworth said something along the lines of
"there's no pressure to agree on everything but a common meta-cycle is
useful base for discussion" [1]. I kind of agree but the thing is that
it's a huge gain for Ubuntu's stability even if Debian and Ubuntu
developers don't agree on _anything_. Ubuntu still gets a frozen and
fairly stable system to build their LTS release from. Ubuntu will
probably release newer versions of major packages anyway so they are
(partly) focusing on different bugs. They won't focus on Debian's RC
bugs. So what are the real benefits for Debian?
---------------
1. http://derstandard.at/fs/1246541995003/Interview-Shuttleworth-about-GNOME-30---Whats-good-whats-missing-what-needs-work
Charles Plessy
>
> 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).
Dear release team,
I would like to add my voice to the concerns about freezing in five monthes and
supporting two releases at the same time.
I first read the press release with interest, because I really appreciated in
the Lenny development cycle to have a serie of step-by-step soft deadlines for
the freeze process. But then I noticed that:
- The time you allow us for Squeeze development is already half passed.
- You uniterally decided to increase our work load by requiring us
to support upgrade from Lenny in 2012.
Moreover, I read from the rumor that the above decision is motivated by some
strategic considerations about synergies with Ubuntu, that are not mentionned
in the press release, nor confirmed by you. I will not feel like staying in
Debian if it becomes a place of taboos where we are expected to read between
the lines and understand the true meaning of what "larger organisations" mean
in our communications. Let me make clear that there no irony intended: I just
never read about plans to synchronise our efforts with Ubuntu LTS, and there is
simply too much of political correctness in your press release to make it
informational for people who do not have access to the gossips.
In addition, it is clear from the messages posted to that thread that some key
teams were not consulted for the acceleration of the release schedule of
Squeeze. I am starting to wonder if you are making our project in danger.
I urge you to provide us some strong arguments about the benefits of:
- Unexpectedly shortenning the release cycle,
- Supporting upgrading from Lenny in 2012.
It has been proposed in the past to make minor stable releases, and
Etch-and-a-half looked like a first step in that direction. Freezing in
December looks like another step, especially with the support of upgrades
accross two releases. I am sure that there is something interesting to build in
that direction, but there is much ambiguity in your decision, as the 2010
release is expected to be more formal than a ‘and-a-half’ release. Yesterday,
Steffen posted some thoughts about new ways to release by tagging, and before
him it was already proposed to freeze only the core of Debian, to make
backports officials, to have a “constantly usable testing”, etc. I would be
very intersted to read your comments on this. Are we going that way, or are we
in contrary committing ourselves to make ’monster releases’ every second year.
(And let other distros innovate on the subject).
Please CC me in case of reply, I am not subscribed to -project.
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Otavio Salvador
On Wed, Jul 29, 2009 at 4:55 PM, Gustavo Franco<str...@debian.org> wrote:
> Otavio, let me make it clear for all readers that you're talking on
> behalf of debian installer team.
>
> I'm sure d-i team is very important to RM team. Communication is far
> from being a strong quality of this project, with that in mind could
> you please try to dissociate a little from the whole thing and raise
> points against a time-based release freeze from d-i team point of
> view?
I think that time-based freezes are good to allow people to plan for
it and be sure that everything are is shape when it comes.
>From d-i POV I think a time-based freeze is going to help us to be
able to plan ahead, and push other teams for the same. The current
timeline can be a hard one for us depending on what the other teams
are planning to do during the time up to the freeze.
To make easier for people to understand why d-i sometimes takes longer
to release then expected here goes a view about what d-i depends on to
a release to happen. We need to coordinate with:
- d-i team (of course)
- RM team (due migrations, blocks, and like)
- kernel team (to get bugs fixed and coordinate uploads to fit the schedule)
- debian-cd team (media and package set planning due space restrictions)
- GNOME team (due their meta-packages and space restrictions and
libraries that we use in d-i)
- KDE team (due meta-packages and space restrictions)
- ftpmasters (to process packages and migrate installer)
So it is quite difficult to know right now if we'll be able to make it
in time; we depends on a lot of people and coordination to make it
happen.
Our current plan is to release Alpha 1 as soon as possible and then
get a better view of our current stability status. We will then focus
in stabilizing all the installer due the short time for the freeze.
Gustavo Franco
Thanks for the heads up. In other words, it seems you're fine with the
overall idea but is skeptical about the timing, right?
I also think the bottom line of your argument is that due the amount
of coordination we need we may miss some pieces of the puzzle. Well,
it's clear RM team will keep unblocking packages that contains RC bugs
during freeze. I expect to see more RC bugs related to features that
were partially uploaded (package Y version A is in, but Z version B
isn't) and there's definitely a window for improvements on this camp.
Unfortunately, we have no metrics on how many packages were unblocked
due that to compare.
regards,
-- Gustavo "stratus" Franco
Otavio Salvador
On Wed, Jul 29, 2009 at 9:53 PM, Gustavo Franco<str...@debian.org> wrote:
> Hi Otavio,
>
> Thanks for the heads up. In other words, it seems you're fine with the
> overall idea but is skeptical about the timing, right?
I hope that this big mess will turns to be a way to people to realise
that coordination is a critical thing in all parts of Debian.
I also believe that December freeze is quite difficult for all parts
involved. Another team that will have bigger problems is the security
team but it is not yet clear how they will manage to support an extra
release.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Carsten Hey
again in December 2011*? Mark Shuttleworth seems (at least seemed) to
be fine with delaying Ubuntu LTS by half a year to get Ubuntu and Debian
in sync [1]:
| The LTS will be either 10.04 or 10.10 - based on the conversation that
| is going on right now between Debian and Ubuntu.
Besides having more time to make Squeeze a great Debian release, one
could also revisit the need to support "skip-upgrades" if the freeze
would be postponed.
In his blog Lucas highlights the similarity between the next Ubuntu LTS
and the next Debian release, but he also points out the need to
differentiate us from Ubuntu. This sounds contrary. He also asks how
we are relevant but does not give an answer [2]:
| after the releases (both Ubuntu’s and Debian’s), users will get to
| choose between two very similar distributions. We need to think about
| how Debian will differenciate itself from Ubuntu: what should we
| emphasize? How are we relevant?
I hope he does not want to imply that we should let Ubuntu release for
us anytime in the future. Some pros and cons of such a step have
already been discussed in our wiki years ago [3].
Carsten
* Or freeze again in December 2012 if one and a half year is not enough
time between two Ubuntu LTS releases.
[1] http://derstandard.at/fs/1246541995003/Interview-Shuttleworth-about-GNOME-30---Whats-good-whats-missing-what-needs-work
[2] http://www.lucas-nussbaum.net/blog/?p=375
[3] http://wiki.debian.org/LetUbuntuReleaseForUs
Marc Haber
> On Wed, Jul 29, 2009 at 4:55 PM, Gustavo Franco<str...@debian.org> wrote:
> > Otavio, let me make it clear for all readers that you're talking on
> > behalf of debian installer team.
> >
> > I'm sure d-i team is very important to RM team. Communication is far
> > from being a strong quality of this project, with that in mind could
> > you please try to dissociate a little from the whole thing and raise
> > points against a time-based release freeze from d-i team point of
> > view?
>
> I think that time-based freezes are good to allow people to plan for
> it and be sure that everything are is shape when it comes.
Is it really so? Has the release team not always informed people in
time about what they were planning?
Greetings
Marc, who still thinks that the new current freeze plan will mean that
Ubuntu LTS will always be the "better" OS.
--
-----------------------------------------------------------------------------
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
Marc Haber
> I also believe that December freeze is quite difficult for all parts
> involved. Another team that will have bigger problems is the security
> team but it is not yet clear how they will manage to support an extra
> release.
Actually, the security team will probably have a hard time during the
"one-shot" "we allow skipping squeeze" phase, but afterwards they will
probably profit from being just a little behind Ubuntu. The rest of
Debian won't.
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
Marc Haber
On Thu, Jul 30, 2009 at 08:45:41AM +0200, Carsten Hey wrote:
> Why not freeze in June 2010 instead of December 2009 and then freeze
> again in December 2011*? Mark Shuttleworth seems (at least seemed) to
> be fine with delaying Ubuntu LTS by half a year to get Ubuntu and Debian
> in sync [1]:
>
> | The LTS will be either 10.04 or 10.10 - based on the conversation that
> | is going on right now between Debian and Ubuntu.
I don't think that we shouldn't time our releases according to what
Mark Shuttleworth says. We are not Ubuntu's slave even if they try
hard to make it look like that.
In fact, I would prefer if Ubuntu had to change _their_ scheduled to
accomodate us, if they want to have the advantage of being in sync
with us. It's _their_ advantage after all, not ours.
Our 18-to-24-month release cycle was a nice vehicle to stay
asynchronous with Ubuntu, which _I_ consider a desireable feature to
prevent Debian from perishing. We are not only major supplier to
Ubuntu, we have our end customers ourselves. I'd prefer that it stayed
that way.
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
Frans Pop
> I don't think that we shouldn't time our releases according to what
> Mark Shuttleworth says. We are not Ubuntu's slave even if they try
> hard to make it look like that.
>
> asynchronous with Ubuntu, which _I_ consider a desireable feature to
> prevent Debian from perishing. We are not only major supplier to
> Ubuntu, we have our end customers ourselves. I'd prefer that it stayed
> that way.
+1
Martin Wuertele
> I don't think that we shouldn't time our releases according to what
> Mark Shuttleworth says. We are not Ubuntu's slave even if they try
> hard to make it look like that.
>
> In fact, I would prefer if Ubuntu had to change _their_ scheduled to
> accomodate us, if they want to have the advantage of being in sync
> with us. It's _their_ advantage after all, not ours.
>
> Our 18-to-24-month release cycle was a nice vehicle to stay
> asynchronous with Ubuntu, which _I_ consider a desireable feature to
> prevent Debian from perishing. We are not only major supplier to
> Ubuntu, we have our end customers ourselves. I'd prefer that it stayed
> that way.
Couldn't have it phrased better.
+1
Yours Martin
Sandro Tosi
> On Thu, Jul 30, 2009 at 08:45:41AM +0200, Carsten Hey wrote:
>> Why not freeze in June 2010 instead of December 2009 and then freeze
>> again in December 2011*? Mark Shuttleworth seems (at least seemed) to
>> be fine with delaying Ubuntu LTS by half a year to get Ubuntu and Debian
>> in sync [1]:
>>
>> | The LTS will be either 10.04 or 10.10 - based on the conversation that
>> | is going on right now between Debian and Ubuntu.
>
> I don't think that we shouldn't time our releases according to what
> Mark Shuttleworth says. We are not Ubuntu's slave even if they try
> hard to make it look like that.
>
> In fact, I would prefer if Ubuntu had to change _their_ scheduled to
> accomodate us, if they want to have the advantage of being in sync
> with us. It's _their_ advantage after all, not ours.
>
> Our 18-to-24-month release cycle was a nice vehicle to stay
> asynchronous with Ubuntu, which _I_ consider a desireable feature to
> prevent Debian from perishing. We are not only major supplier to
> Ubuntu, we have our end customers ourselves. I'd prefer that it stayed
> that way.
Absolutely +1
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Gustavo Franco
Haber<mh+debia...@zugschlus.de> wrote:
> Hi,
>
> On Thu, Jul 30, 2009 at 08:45:41AM +0200, Carsten Hey wrote:
>> Why not freeze in June 2010 instead of December 2009 and then freeze
>> again in December 2011*? Mark Shuttleworth seems (at least seemed) to
>> be fine with delaying Ubuntu LTS by half a year to get Ubuntu and Debian
>> in sync [1]:
>>
>> | The LTS will be either 10.04 or 10.10 - based on the conversation that
>> | is going on right now between Debian and Ubuntu.
>
> I don't think that we shouldn't time our releases according to what
> Mark Shuttleworth says. We are not Ubuntu's slave even if they try
> hard to make it look like that.
>
> In fact, I would prefer if Ubuntu had to change _their_ scheduled to
> accomodate us, if they want to have the advantage of being in sync
> with us. It's _their_ advantage after all, not ours.
>
> Our 18-to-24-month release cycle was a nice vehicle to stay
> asynchronous with Ubuntu, which _I_ consider a desireable feature to
> prevent Debian from perishing. We are not only major supplier to
> Ubuntu, we have our end customers ourselves. I'd prefer that it stayed
> that way.
I don't get why do you consider 18-to-24-month release cycles a
desirable feature to prevent Debian from perishing. Is this just to
stay out of sync with another deb-based distro?
We are definitely not only major supplier to any other deb-based
distro, and you act our end customers are really happy with not even
knowing the date when we will freeze to our next release. Could you
please also point out why that's bad to a set of our end customers?
regards,
-- Gustavo "stratus" Franco
Marc Haber
> On Thu, Jul 30, 2009 at 12:16 AM, Marc
> Haber<mh+debia...@zugschlus.de> wrote:
> > On Thu, Jul 30, 2009 at 08:45:41AM +0200, Carsten Hey wrote:
> >> Why not freeze in June 2010 instead of December 2009 and then freeze
> >> again in December 2011*? Mark Shuttleworth seems (at least seemed) to
> >> be fine with delaying Ubuntu LTS by half a year to get Ubuntu and Debian
> >> in sync [1]:
> >>
> >> | The LTS will be either 10.04 or 10.10 - based on the conversation that
> >> | is going on right now between Debian and Ubuntu.
> >
> > I don't think that we shouldn't time our releases according to what
> > Mark Shuttleworth says. We are not Ubuntu's slave even if they try
> > hard to make it look like that.
> >
> > In fact, I would prefer if Ubuntu had to change _their_ scheduled to
> > accomodate us, if they want to have the advantage of being in sync
> > with us. It's _their_ advantage after all, not ours.
> >
> > Our 18-to-24-month release cycle was a nice vehicle to stay
> > asynchronous with Ubuntu, which _I_ consider a desireable feature to
> > prevent Debian from perishing. We are not only major supplier to
> > Ubuntu, we have our end customers ourselves. I'd prefer that it stayed
> > that way.
>
> I don't get why do you consider 18-to-24-month release cycles a
> desirable feature to prevent Debian from perishing. Is this just to
> stay out of sync with another deb-based distro?
If we work _this_ hard to allow Ubuntu to get their LTS releases in
sync with out stable releases in a way that allows Ubuntu to get a
later KDE _and_ a later GNOME[1], things are running in the wrong
direction. Why continue releasing stable in the first place then? We
could freeze in December, thus missing both KDE and GNOME, and
unfreeze when Ubuntu has detached itself before their release. Nobody
would even think about using Debian stable when there is Ubuntu LTS
with more recent software _and_ commercial support by its vendor
available.
That way, Debian would deteriorate into what OpenSUSE is for SLES and
what Fedora is for RHEL - the technical playground for the unpaid
developers who iron out the kinks from what will be the basis of the
commercial release. I don't think that this is desireable.
> We are definitely not only major supplier to any other deb-based
> distro,
Yes, currently. With the new release schedule, we will be.
> and you act our end customers are really happy with not even knowing
> the date when we will freeze to our next release.
I do not think that we were too late with announcing our freezes in
the past. What we did in the past was just fine, and I was very
satisfied with the way etch and lenny were released. No need to change
the system which we _FINALLY_ got running. At least we do not need to
change if there is no advantage for us, only for our competitors.
Greetings
Marc
[1] Assuming that KDE continues releasing Januar and July and GNOME
continues releasing March and September
--
-----------------------------------------------------------------------------
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
Raphael Hertzog
> In fact, I would prefer if Ubuntu had to change _their_ scheduled to
> accomodate us, if they want to have the advantage of being in sync
> with us. It's _their_ advantage after all, not ours.
I don't mind who changes the date for the other but I really don't agree
that doing it is only for Ubuntu's advantage. Nobody in Debian would have
taken such a decision, we are Debian developers and have no interest in
helping only Ubuntu.
What we're speaking of is synergy between both distributions. You know the
it's the principle behind “the combination of both is worth more that the
sum of individual parts”.
> We are not only major supplier to Ubuntu, we have our end customers
> ourselves. I'd prefer that it stayed that way.
The synchronization with Ubuntu is not going to remove our identity.
We'll keep our user base and the possible improvements in both
distributions will help us do better in the competition with other
operating systems (proprietary or not).
Cheers,
--
Raphaël Hertzog
Tshepang Lekhonkhobe
> On Thu, 30 Jul 2009, Marc Haber wrote:
>> In fact, I would prefer if Ubuntu had to change _their_ scheduled to
>> accomodate us, if they want to have the advantage of being in sync
>> with us. It's _their_ advantage after all, not ours.
>
> I don't mind who changes the date for the other but I really don't agree
> that doing it is only for Ubuntu's advantage. Nobody in Debian would have
> taken such a decision, we are Debian developers and have no interest in
> helping only Ubuntu.
>
> What we're speaking of is synergy between both distributions. You know the
> it's the principle behind “the combination of both is worth more that the
> sum of individual parts”.
>
>> We are not only major supplier to Ubuntu, we have our end customers
>> ourselves. I'd prefer that it stayed that way.
>
> The synchronization with Ubuntu is not going to remove our identity.
> We'll keep our user base and the possible improvements in both
> distributions will help us do better in the competition with other
> operating systems (proprietary or not).
>
> Cheers,
Me wholly agrees.
Adding to that, the mighty Ian Murdock once stated that if Ubuntu
wins, then Debian wins, that Ubuntu is like a variety of Debian.
Ubuntu has got their market which Debian failed to capture anyways
(desktop), so if they keep honouring publicly stating and recognizing
Debian as their upstream, so much the better, why not. And Ubuntu will
keep growing whether Debian co-operates or not by the way, cuz their
leadership is damn solid.
There's some (many) of us who feel that the great Debian culture is
irreplaceable, and therefore won't use Ubuntu as their primary OS. So
why worry about losing relevance.
--
my place on the web:
floss-and-misc.blogspot.com