[Scummvm-devel] CVS frozen for 0.5.0!

[J.Brown (Ender)]

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

I would not call this system inflexiable, I put significant thought into
it. If by 'modern' you mean Branching (using a cool CVS feature doesn't
make a freeze phase modern *g*), as I said in an e-mail to devel replying
to a question of yours regarding my initial notice, we will branch if
required. However, this situation is designed to focus resources on
testing and bugfixing during at least the initial freeze period. Also,
I've decided to go with this method to cope with the AnonCVS lag (4 day
soft freeze/test period to cope with 2+ day lag)

> 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

The initial soft freeze of 4 days is when we allow any last minute patches
in, and do initial testing to locate any major problems that may require
changes in the release schedule. So far this period has gone extremely
well with very few initial release critical bugs.

> 1) Jul 10 - 14: Final development efforts take place (that's what you
> call a "soft freeze", I guess)

See Soft Freeze :)

> 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

I hate to use your words against you, but... :)

'"I am not aware of anybody planning major changes". So obviously that
includes myself'

As I again stated in my initial e-mail, if anybody does have a large set
of changes they wish to put in CVS that would require branching, all they
have to do is ask. The only reason I have not branched is that I see no
need at the moment, with the slight possibility of V1 work. But nobody has
made that work yet, so I do not see why local development is a problem,
possibly using the Patch Tracker in te interm to share any major fixes
(and if I do see major fixes, again as stated in my initial e-mail I will
branch).

The fact is, and in fca
> 4) Jul 14-Jul 24: Only bug fixes are applied to the branch

This is, if you read my initial e-mail regarding the freeze, what the Hard
Freeze period is.

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

See above. If any developers do have major development to commit, we can
branch. I have publically stated this before, and you yourself have
pointed out there are no major changes occuring at this time. Hence why I
have chosen now as a good test period. Ignoring the branch, so far your
schedule is almost exactly the same as mine. Although the Jul 24th+ period
in my schedule also includes port tests and binary preperation.

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

The release day does indeed depend on the status. However I am pretty
confident that come the 24th we will not need many future changes, and can
hopefully finalise the source tarball and collect port binaries before the
release period.

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

I agree entirely. If a developer has plans for major changes, as again I
stated at the beginning, all they have to do is request that we branch.
However until there is a need to, not having a branch focuses development
on bugfixes and release-critical bugs.

Anyway, it's too late to change it now, and so far apart from the fact you
want to branch initially as opposed to when/if required, I see minimal
difference to the current plan. We can always tweak these things for 0.6.0
if required.

 - Ender