Re: 2.20 schedule

["Elijah Newren" <newren gmail com>]

On 3/8/07, Vincent Untz <vuntz gnome org> wrote:
> > the proposal i'm in favour for is the second one. the definitely best
> > one is the last one, but i just don't know how much we want to care
> > about novell? (yes, i've asked them for info on how much time it approx.
> > takes them to patch and include gnome 2.20 into their release.)
>
> It's not Novell, but OpenSUSE ;-)
> Looks like Mandriva would like sooner two.
> IMHO, since people are relying on us and are expecting a schedule before
> mid-September (we've always done this in the past, I believe), I'd tend

2.8 was released Sept 15 (http://www.gnome.org/start/2.7/).  Also, I
objected to doing 2.15 before mid-September last year, for what it's
worth (http://mail.gnome.org/archives/release-team/2006-March/msg00169.html).

Just my $0.02.  I'd like to include the distributors, but I really
don't like having the spacing of other freezes messed up.  Releasing
earlier also screws up our release schedule with the timing near
Christmas...  I'd say API/ABI freeze before GUADEC (and request people
to quit pushing GUADEC further back every year) if we really want to
release earlier, but I personally dislike it.

> I'll send a mail with more details later (maybe this week-end), but the
> basic idea is that we're using a lot of maintainers' time in stable
> release, and they're applying all sort of patches. Some are critical,
> but some are clearly not.

Weird; we did the .3 release because distributors (e.g. Federico)
complained that stable releases were dropped and critical patches were
only applied to the unstable branch.  If we don't do the .3 releases,
maintainers have no incentive to apply anything to that branch.  Now
you're pointing out that we also have the opposite problem with some
modules.  Fun.  :)

> Also, it sounds weird to have a hard code freeze for 2.20.0, but then no
> freeze for later releases. So, something like keeping a slushy code
> freeze after 2.20.0. The idea is that we tell maintainers that they can
> freely commit, but we'd like them to mail us after the commit so we know
> about it (or something like this). Also, we'd tell them that only highly
> visible bugs should be fixed in stable releases (ideally, only crashers).

Sounds reasonable to me; I think it'd be a good way to make treatment
of the stable branch a bit more uniform and reliable.

Elijah