On Wed, Aug 5, 2009 at 4:44 PM, Mark Shuttleworth<m...@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 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org