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: