Re: 2.20 schedule

[Vincent Untz <vuntz gnome org>]

Le jeudi 08 mars 2007, à 02:34, Andre Klapper a écrit :
> Am Dienstag, den 06.03.2007, 14:58 +0100 schrieb Vincent Untz:
> > Does anyone have some time to prepare a schedule for GNOME 2.19/2.20?
> 
> boy, this time it's really non-trivial. before doing this, i've dreamt
> of having the api/abi freeze one week earlier so everybody has enough
> time to fix build breaks. but reality can bite...
> 
> guadec is very late this year. i think everybody agrees that already
> being under api/abi freeze at guadec would be a huge motivation killer
> that definitely has to be avoided.

Nod.

> the other constraint is the opensuse 10.3 release which is planned for
> the end of september (the final date is not fixed yet), and they would
> love to include gnome 2.20 if possible.
> 
> so i've pushed back the api/abi freeze date to be after guadec, by
> compressing the schedule at the end. this results in a pretty tight
> schedule, means: perhaps having one release less (sched1), or having an
> earlier 2.18.3 release (sched1&2) to lower the stress of the
> maintainers.
> 
> i have three schedule proposals at
> http://live.gnome.org/AndreKlapper/Sched1 (2.20 rel: sep 05)

Skipping 2.19.90 is not a good solution, IMHO. I know that it has been
helpful for me as a maintainer :-)

> http://live.gnome.org/AndreKlapper/Sched2 (2.20 rel: sep 12)

One week between feature/module freezes and string freezes is a blocker
to me. There are good chances that many strings might need to be
tweaked, and only one week is a bit short for this.

A solution to this (for this version of the schedule) is to move the
feature/module freeze one week before 2.19.90. One problem with the way
we're doing it right now (ie, freeze and tarballs due on the same date)
is that it encourages maintainers to push for features until the last
minute, and so we can have a "broken" release because the code is not
really tested.

Hrm, even without looking at the freezes, only one week between 2.19.90
and 2.19.91 looks short.

> http://live.gnome.org/AndreKlapper/Sched3 (2.20 rel: sep 19).
> please also see those pages for more info on the changes.

I like this one better. But I'd move 2.18.3 earlier, like in the other
schedules.

> 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
to agree that September 19th might be a bit too late. We can ask on
distributor-list, though.

A fourth proposal would be to have this: schedule 2, but two weeks
between 2.19.90 and 2.19.91 and only one week between 2.19.91 and
2.19.92 (it's the opposite, right now in schedule 2).

This fourth proposal is my preferred one right now :-)

> i also wondered about the sense of having 2.even.3 releases, see [1].
> if we would have a stricter policy on which patches are allowed to get
> into the stable branch, we would probably get more distros back again
> into shipping updated stable releases instead of backporting explicit
> patches. this would also reduce the bugsquad workload and provide a
> clearer bugreport feedback to identify the important issues.
> vincent will pick up this issue in a seperate email (*poke*). ;-)

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.

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).

Vincent

-- 
Les gens heureux ne sont pas pressés.