Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: It is feature freeze time
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Cc: <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: It is feature freeze time
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Sat, 27 Apr 2002 00:20:02 -0400

At 01:34 AM 02/04/27 +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. It is embarrasing to ship something with lots of bugs, and
>judging from comments from seasoned players on the irc channel, the
>development branch _is_ buggy.

That is a good reason to isolate it. There may actually be things you
want to take out for release, as insufficiently thought out or too
problemmatic, but by the same token you may not want to abandon them
completely.

Trying to coerce people that have no real stake in the current release
to debug it by stopping activities they are contributing to is also not
necessarily an effective longterm technique.

There is nothing that says you need to maintain all previous mainline
activity rates if people are working on a release, but neither the all 
nor the none extremes are particularly sensible. One should be able to
walk and chew gum at the same time without choking or falling off a cliff.

>Branching off a stable branch may be a good idea. That way we can very
>easily make bugfix releases, if we find that necessary. But I don't think
>we should do so at least not until we've managed to ship our first beta.

Feature freeze *is* a typical milestone for doing this, with code freeze
when all final last minute feature tasks are complete the latest. When
you move to heavy testing and bugfixing you want to be branched to exert
control over what is and is not allowed in.

Also, release branches are very useful for post-release bugfixes. There
is every reason to turn around a quick "dot" release from a maintenance
branch if something critical or a sufficient number of embarassing
problems arise. This is much better than trying to do a second complete
release shortly after. Incremental feature updates to a stable release
branch are also a good way to provide interim exposure to new features.
So it should always be done, and the real discussion should only be about 
when.

Those that have heavy contributions in this release should be the ones
most active in testing and bugfixing during the stability phase. Have
several key contributors swap areas after their own initial pass and do
in depth probes of both the critical codepaths and various exercising
scenarios. This sort of "white box" testing by people with a real 
concern and in depth knowledge will be far better than random and
probably (similar) superficial pokes by people less interested.

You can also ask for people to help on particular areas, as opposed to
throwing something out and waiting to see who responds. The latter
tends to get all or none responses and a dimishing level of TLC by
those that do respond. This presumes you do know what the keys areas
and weaknesses are, and have some sort of testplan to go over them.

I also suspect that putting out a beta will attract a different set of
users and testers than typically fight with CVS. These are also the
people you want to hear complaints from once there is something good
enough to stand up to reasonable abuse. They *will* abuse it.

>Until then let's do some collective bughunting. Perhaps we should ape
>after the gnomes, and stage our very own irc bugfest... or whatever.
>
>But that's just what I think right now, and I may change my mind, and you
>may change my mind, and Raimar, Mike and Tony probably have wildly
>different opinions.

Opinions shared are good ... if there are wild differences then it means
people haven't necessarily found the optimal perspective yet, but knowing
that is the first stage to getting there.

>Yours sleepily,
>Per
>
>Ask not what you can do for your country
>Ask what your country did to you
> -- KMFDM, Dogma

Cheers,
RossW
=====




[Prev in Thread] Current Thread [Next in Thread]