[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian decides to adopt time-based release freezes

On 2009-07-29, Luk Claes <luk@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.

> 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.


Reply to: