Re: Debian decides to adopt time-based release freezes
Sune Vuorela wrote:
On 2009-07-29, Frans Pop <elendil@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
Reply to: