[Freeciv-Dev] Re: It is feature freeze time

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 09:35 AM 02/04/27 +0200, Raimar Falke wrote:
>On Sat, Apr 27, 2002 at 01:34:55AM +0200, Per I. Mathisen wrote:
>> On Fri, 26 Apr 2002, Ross W. Wetmore wrote:
>> > The sensible thing for the release beta is to spin off a branch
>> > at feature freeze, and only allow bugfixes on that branch. The
>> > regular CVS mainline can continue as the development branch.
>> >
>> > This sort of process management would probably result in a lot
>> > less apologizing and general irritation all round - especially
>> > that resulting from perceptions of the arbitrary favouritism.
>> >
>> > This also means you can continue beta fixing as long as you need
>> > to get the thing stable without pressure from developers or
>> > losing those you have, so there are benefits on both sides.
>> 
>> On Fri, 26 Apr 2002, Jason Short wrote:
>> > I'd like to again suggest the use of CVS branches to minimize the
>> > downtime from a feature freeze.
>> 
>> This has been up before... Actually, I remember suggesting this myself
>> earlier. But I'm not sure about this.
>
>> I want people here to make an effort to debug what we have now so that we
>> can ship it.
>
>I also see this problem. We have to avoid splitting the developers
>base.

I suspect that your developer base is already split along the lines of
things that interest them, and no amount of coercion or freezing of areas
people are actively working on is going to really convince them to work
on your pet projects if the interest isn't there.

>Now that the sound is in I have thought about the time schedule. I
>have drawn one IMHO important conclusion:
>
>  After we released the current version we will set a time (say 3
>  months) and than really freeze the tree at that day. Even when the
>  most impressive feature is just to be applied. Even if is it "ready
>  for inclusion". It will have to wait.

The "train leaves the station" model only works well in a branched 
development environment. The methodology is to pick a stable base,
develop features independently off that base until they are ready 
for integration, then periodically do a baseline integration of all
feature branches that are *ready*. Once the integration is stabilized
everyone syncs their outstanding feature branch to this milestone
and starts a new cycle.

When the baseline has enough completed features you spin off a release
branch, beat it to death and ship. Completed but not yet integrated
features live as addon patches or extensions that anyone should be
able to pickup from freeciv.org on a use at your own risk basis. Bug 
reports against them should be accepted just as if they were in the 
baseline. Download and bugreport stats against outstanding features 
may prove useful in gauging when they are ready.

But most developers spend their time working on individual feature
branches in this model. And maintainers really don't seem capable
of integrating more then simple bugfix patches or completely new and
separate code hierarchies given the past year's experience as example.
Both these elements would have to change.

And things like the regular cosmetic and boolish changes to the baseline 
that only server to derail and add unnecessary branch development cost
would have to be curtailed or follow the same feature model as the rest.

>This may sound drastic but I don't see another way. From Jan till now
>we have only got the sound in (two major goals were still open, one
>has been dropped now). During this time the sound patch was changed in
>a major way (the complete way how the information is transfered from
>the server to the client was revised).

If you pick elements that aren't ready or well thought out as release 
candidates, over ones that are, then you have to live with your mistakes. 

>So I learned that the original way posted in Jan from me was wrong. I
>would like to try the beta time with no extra branches and see what
>will happen. It may also be helpful if Jason can describe (I wasn't

But blocking development or penalizing developers that are moving ahead 
within their feature areas is not a particularly good way to correct the 
original mistakes in poor judgment. Rather it continues to compund them.

>following the development very precisely at these days) what was the
>problem at the previous beta time. Just too many bugs found? No fixes
>were posted? Posted fix weren't committed?

On my part is was mostly that the minimal interest or civility shown by
maintainers to developers not working on their pet projects goes to zero
and their usual comment on anything becomes "go away until after release".

This is maybe the way this project is always managed, but betas tend to 
make its shortcomings far more obvious, and lose a lot of developer
potential and goodwill. It is also hard on the release maintainers who
end up spending a lot of time fighting off the old recurring themes that
such unnecessary tensions and highhandedness produce.

>       Raimar
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "On the eigth day, God started debugging"

Cheers,
RossW
=====