Re: GNOME 2.23/2.24 - Schedule Proposals

["Lucas Rocha" <lucasr gnome org>]

Hi,

2008/2/9, Vincent Untz <vuntz gnome org>:
> Le samedi 09 février 2008, à 00:06 +0200, Lucas Rocha a écrit :
> > Hi,
> >
> > 2008/2/8, Andre Klapper <ak-47 gmx net>:
> > > Am Dienstag, den 05.02.2008, 16:21 +0200 schrieb Lucas Rocha:
> > > > Here are three proposals for the GNOME 2.23/2.24 release schedule:
> > > >
> > > >   http://live.gnome.org/LucasRocha/TwoPointTwentythree
> > > >
> > > > Which one do you prefer? Comments? Additional proposals?
> > >
> > > i'm late, my 2 cents:
> > >
> > > i want to have api freeze on a monday *without* a release like for 2.21.
> > > having a broken api and only 2 days to fix is worse than having a broken
> > > api and 9 days to fix + many beta testers.
> >
> > In the scope of proposal 3, we could move the API/ABI freeze from week
> > 21 to week 20 or 22. However, I still think we should try to associate
> > all freezes with specific releases (expect for the hard code one) as
> > much as we can. It's easier for maintainers to keep track of the
> > freezes this way. I don't think they keep looking at the calendar very
> > often. Maybe they (we?) should. :-P
> >
> > What do the others think?
>
> Well, I'd disagree here :-)

Concrete proposal? :-P

> If you put a freeze on a release date, you get people changing tons of
> stuff just before a release, which will make a broken release.

On the other hand, having a separate date for the freezes, might
increase (not sure) the amount of freeze break requests just because
maintainers/developers have "missed" the dates (even with the nice
script) which is not very nice too. I understand that API freezes are
specially critical but I wouldn't apply the same rule for the all the
freezes.

All development cycles I've ever participated had a match betwen
freezes and releases and I haven't heard very often about broken or
delayed releases. I remember we had a problem with a GTK+ API change
(tooltips stuff) in the 2.19/2.20 cycle. Does this kind of problem
happen very often?

> It's just a matter of communicating when there's a freeze, and with
> the new scripts (thanks Olav!), it's harder to forget to send the mail.

I still think that we should have the development releases as the
major checkpoints combined with the freezes. From my maintainer
perspective, this works very well. I'm definitely not aware of all the
issues the release team have to deal in a daily basis. So, if you
think a good communication is enough, that's ok for me. :-)

--lucasr