Re: On cadence and collaboration
On Wed, Aug 5, 2009 at 4:44 PM, Mark Shuttleworth<mark@ubuntu.com> wrote:
> The proposal as I understood it was that in December, the key component
> maintainers / release managers from all interested distributions would
> discuss, on a public mailing list, their plans for the base versions of
> those components in their 2010 releases.
Well, this is not the proposal as it was announced, and this is
definitely not what we understand as "freeze" in Debian. In Debian,
"freezing" in December means that no new versions enter testing after
the freeze begins.
I think the proposal as you word it would be fine, since this would
probably mean freezing later on. Maybe March or so. This would make
much more sense, from my point of view. But this is NOT what was
announced and communicated to us.
> The rough guide I heard was that, if we looked at the list in December, we'd
> probably be able to agree on things like the default versions of Python,
> Perl, X and GCC, but that it might be harder on kernel, GNOME and KDE.
> That's OK by me - whatever consensus *does* emerge from the process is a win
> that we otherwise would not have. Some teams may not be ready for the
> discussion, some might be. That's OK too.
I don't think it makes sense to rush our release as much as it's being
proposed only to finish with different versions of big components. I
understand that GCC and X are important, but I don't think all the
hard work makes sense unless we can also sync the desktops.
> The difference in our language is about the meaning of "freeze" in December.
> I think December is not about actually freezing, it's about reviewing and
> planning and looking for opportunities. Certainly, I think the Debian team
> will want to freeze some things very early (December!), but some maintainer
> teams may well be willing to commit to using something that will freeze a
> little later, especially if they can collaborate well with Ubuntu on those
> packages.
That's not how it has worked in the past. We've had some scaled
freeze, freezing the toolchain first and the rest of the packages
afterwards, but it's never been "some maintainer teams" who decided
what was frozen and what wasn't, it's always been the Release Team.
And the Release Team has said that they'd rather not do the scaled
freeze this time, they'd rather just do one freeze, and get it over
fast.
I think that there is a significant difference on how Debian and
Ubuntu work towards a release which means that speaking about a
"December freeze" has very different consequences on each
distribution. So, maybe we need to change the terms, so that we are
both speaking about the same thing.
> It's true that Decembers a fractured month, and it would arguably be better
> to do heavy lifting in another month. I imagine the main work will really be
> Feb-March, once the decisions are final and widely communicated.
Again, this was not what was announced, it's not what we were
expecting after the "We freeze in December" plan.
I personally wouldn't object to a general "let's decide what we want
in our distro" discussion in December, as long as the freeze is done
after those components have been included. That means that if we want
March's GNOME, we would have to freeze in April.
If we (as in Debian) freeze in December, then there's absolutely
nothing to discuss. We already know what we are going to ship.
Finally, the whole idea of the time based freezes was to know when we
were going to freeze, so that maintainers could work towards that. If
the freeze date is decided in the December discussions, then we are
back to the current (or past) model, of freezing at some unknown
point.
--
Besos,
Marga
Reply to: