[Scummvm-devel] CVS frozen for 0.5.0!

Max Horn max at quendi.de
Fri Jul 11 12:22:07 CEST 2003


[I replied to this earlier but apparently by accident sent it only to 
Ender]

Am Donnerstag, 10.07.03 um 06:02 Uhr schrieb J.Brown (Ender):

> We just froze for 0.5.0, so please use your judgement in applying CVS
> commits. If in doubt, please check with myself or Fingolfin.
>
> An updated test list will be posted later tonight, I have a few things 
> I
> want to change. This is a fairly 'soft' freeze for the first few days, 
> to
> allow any commits for V1 support... I still want to get this fixed up a
> little more for 0.5.0, and Beneath a Steel Sky is excluded from the
> freeze.
>
> The planned release schedule is as follows:
>
>  Jul 10 - 14: Soft freeze, initial testing of 'frozen' games (Simon, 
> DOTT,
> S&M, etc)
>  Jul 14 - 24: Hard freeze, strict commit rules
>  Jul 24 - 28: Final tests, ensure all ports recognise all games
>  Jul 28 - 31: Ports compiled/uploaded, CVS tagged and unfrozen
>
Hm... any reason we are reverting to the old inflexible scheme, instead 
of using the modern one which worked so well last time (e.g. unlike 
previous times, it was trivial to get out a bug fix release even two 
weeks after the original release).

In particular: Why do we hard freeze for ten days, then test for 4 more 
days? Why wait 10 days before testing ?!? That makes no sense to me... 
Maybe you meant: we hard freeze for fourteen days and test during that 
time. That still doesn't make much sense to me, though, since we need 
to fix bugs that crop up during the test period. I'd propose the 
alternate approach

1) Jul 10 - 14: Final development efforts take place (that's what you 
call a "soft freeze", I guess)
2) Jul 14, 12:00 UTC (or any other time): We branch. Major work can 
resume on trunk, branch is frozen and only gets bug fixes
3) Same day: We release a "beta" tarball and binaries, and let people 
test, for example for 10 days (doing that since SF.net CVS is lagging 
to much behind). It's also trivial to have tarballs for the 0.5.0 
branch be made, in parallel to the regular daily snapshots
4) Jul 14-Jul 24: Only bug fixes are applied to the branch
5) Jul 24: If things are sufficiently stable, hard freeze the branch, 
and maybe test it for a few more days (and maybe provide "RC1" 
source/binares). This should be handled flexible: if there are still 
major issues open, we can easily delay this point -> this works easily, 
since people can still work on the trunk in any way they want, unlike 
in the other scheme, which essentially forces developers to "hold 
still" for 2 weeks).
6) Day X: Release. The release happens within 24 hours. Ports which are 
later are late and can be added later. After all, porters have 2-3 
weeks lead time, so they know the day of the release. There is no real 
excuse to miss it, and no reason to wait for specific binaries either, 
IMHO. If a porters knows he won't be able to provide binaries in that 
time frame, fine, we can also adjust the time frame - but that 
information should be available in advance. Plus, I don't see any 
problems in having a given binary a few days later than others (nobody 
complained about that for 0.4.0 / 0.4.1)

To emphasize this again: I believe it is very important that we do not 
prevent developers for two weeks or longer from making bigger changes. 
E.g. I have the next two weeks time. If I am not allowed to make any 
changes, fine by me, I have many other things I can spend my time on. 
However, that doesn't mean I'll make those changes after the two weeks, 
because then I will probably not have time anymore. I guess it's the 
same for other developers: we can't just allocate our time for ScummVM 
in arbitrary ways. If we have time to work on it, but can't, that time 
is lost forever for ScummVM.


Cheers,

Max





More information about the Scummvm-devel mailing list