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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Apr 27, 2002 at 01:59:37PM -0400, Ross W. Wetmore wrote:
> 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.

This may be true.

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

I agree with out. However I suspect that you think about CVS branches
as a branched development environment while I see the local CVS
repositories as the branches.

> When the baseline has enough completed features you spin off a release
> branch, beat it to death and ship.

And this is a third model. So we have
 1) current one: where it is development and at some point the release
 goals where defined. These goals had included also unintegrated
 stuff.
 2) by time: since the CVS is relative stable we can at almost all
 times make a freeze and enter the beta time to remove the remaining
 bugs.
 3) our: every feature gets a rating and if a given sum is accumulated
 we make a release. It turns out that thiss was also proposed by
 Gregory:
   If we follow "release early release often" strategy, I reckon any
   one of the grade 3 improvements deserve a release.  Going down, any
   2 of grade 2 and any 4 of grade 1 deserve a release.


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

Ack.

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

I agree that we can and should improve in this area but it is not this
bad as you describe.

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

Just look at the sound patch: Per the author claimed that it was ready
in Jan. It turns out that the way it communicates wasn't clean. It was
reworked. It resulted in a few preparing patches and then the final
sound patch.

A recent example is the notifier patch: it looks innocent and
painless. However after the inclusion the message option dialogs won't
fit anymore on a 1024x768 screen under xaw. Not to mention 800x600. A
scrollbar or similar has to be added. Currently I think we should
leave it out.

These examples taught me that it is very hard to estimate how ready a
feature is.

> >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
 "This is Linux Country. On a quiet night, you can hear Windows reboot."