|
Hi Marga Margarita Manterola wrote: If Debian commits to a December freeze, would that mean that Ubuntu commits to releasing 10.04 with KDE 4.3 (already released) and GNOME 2.28 (to be released in a few months), instead of KDE 4.4 (to be released in January) and GNOME 2.30 (to be released in March)? This has been one of the main concerns of the December freeze, apart from the fact that we wouldn't meet our release goals, that you are suggesting how to solve. Ubuntu has shown in the past a tendency to ship with the latest versions of software. In the case of GNOME, the freeze in Ubuntu usually happens before GNOME is even released, and yet the latest GNOME goes into the release. So, how would that work in this case? 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. It wouldn't be realistic to hope that every distro joins a consensus on every component - there are good reasons why some might want to use a more bleeding edge piece and others may want a more conservative piece. For example, architecture support in Debian might require a different GCC or kernel than the one that everyone else goes with, and that's fine. 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. My expectation is that Debian will want to have more flexibility in how long the release is baked than Ubuntu would normally give itself. My hope is that we can agree on a GNOME and KDE version, and that Debian will thus benefit from all the work Ubuntu does on that and then have a few extra months (as many as deemed necessary) to bake it to Debian's satisfaction. 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.It is my opinion that freezing after GNOME releases (and gets into testing) would be better for Debian. This means either April or October, depending on which GNOME release we want to ship. If we think, for real, that December is the best month of the year to freeze (I definitely don't), then we would need to somehow convince both GNOME and KDE (and then other upstreams as well) to release in October/November. It's not that much of a change for GNOME, but I don't see this happening this year for KDE. Maybe next year, if this is planned well in advance. 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. In December, by this proposal, we would just have a series of threads on a list like the distributions@lists.freedesktop.org list, where we try to establish what consensus we can across the major components. It would be planning and discussion, not actually starting the freeze itself except for those components which the maintainers and release managers felt it necessary.But why December? December is a very nasty month to do important things, people go on holidays, stay away from their computers for one, two or more weeks. If anything, I think December is the worst month to plan for a freeze. Mark |