Re: GNOME 2.23/2.24 - Schedule Proposals



Le samedi 09 février 2008, à 14:21 +0200, Lucas Rocha a écrit :
> 2008/2/9, Vincent Untz <vuntz gnome org>:
> > 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. :-)

Interesting. From my maintainer perspective, I know feature freeze
doesn't work well, for example :-)

I don't think the current way is a big problem either. We've lived with
it for quite some time, so it works :-) Maybe we can try to have the
freeze without release for this cycle to see how it works. And decide
for the cycle after the next one.

Vincent

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]