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

Re: On cadence and collaboration

Hi, Julien:

On Wednesday 05 August 2009 20:42:03 Julien BLACHE wrote:
> Manoj Srivastava <srivasta@debian.org> wrote:
> Hi,
> >> From the very start of the Debian Project, Debian has been different
> >> from everything else: different package management tools, different
> >> philosophy, different organization, you name it.
> >
> >         But most of these will not be lost if we have a time based
> I think we'll lose part of the "we release when it's ready" philosophy
> (that our RMs seem to despise so much). Because part of this is to
> freeze when it's ready.

Not at all if done properly.  Freeze on a date simply means that what it's 
ready on that date is included, what it's not ready won't be included, simply 
as that.  When you couple that with a freeze date well known in advance, you 
allow interested people to plan properly.

In other words: freeze on december the first doesn't mean that if, say, Gnome 
will publish it's new shiny 1.2 version by december the 15, the last beta 
should have to be included, but that the december version will ship version 
1.1 (or whatever is the previous known to work stable).  It's up to the 
upstreamer to decide if next time they will publish by november the 15th 
instead of december the 15th so their latest greatest gets to be shipped.  
The fact that they'll know well in advance when the freeze is to be expected 
is what will allow them space enough to make a savvy decision while now, with 
the "freeze when ready" is a matter of luck and a point of friction 
(pleeease, wait for another two weeks for our new and shinny).

> A time-based freeze could mean for some teams that they'll have to
> stop work basically for months to a year. It already takes too much
> time to recover after a release, this won't help.

Why?  I really don't see your point unless you mean for the packager under 
current conditions where no real branches are allowed on Debian (but the 
everbody's bag that it is 'experimental' that has demonstrated not to be a 
solution at all).  This needs to be changed and I expect the time-based 
freeze to be the tick that will finally push this change.

I envision a system where a new upload will create kind of a branch and 
trigger a dependency cascade where all dependent (depend, suggest and 
recomend) packages are alerted so their maintainers can test for obvious 
problems and ack the upgrade or release a new change on the branch that again 
triggers the dependency cascade for its dependants.  Once everybody acks or 
upgrades the whole branch gets commited into what currently is "testing" (the 
ack mech will in turn help for the MIA case: an unanswering maintainer 
would -under proper conditions, automatically meant for the package to be 
orphaned or even retired; a maintanier whose last package goes that way would 
be automatically marked for MIA process).

This way, you could freeze testing almost any day without problems (and Ubuntu 
could easily go on their own if in the end that's better for their interests, 
since the health of testing would be much better any day going almost without 
the "upgrading storms" current process almost guarantee on testing from time 
to time).

If that's what you meant, I think you don't have an argument against 
time-based freezes but against the "first time-based freeze on Dec-2009" but 
to push it to a latter date in order to have time for the tools to be 
developed (hey, Mr. Canonical, there you have a very interesting case where 
your hands and moneys would certainly be more than welcome).

> In this day and age, you have to look at features in addition to the
> version number, because the latter isn't necessarily very telling of
> the real changes from one release to another. Major features are
> delivered in minor releases nowadays...

I already said that to be simply malpractice and beyond a distribution's 
ability to correct (while I'm with Shuttleworth in that concurrent freezes 
would help to "show the proper path" to upstreamers).

Reply to: