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

["Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>]

On Sun, 28 Apr 2002, Ross W. Wetmore wrote:
> But it is still perfectly reasonable to have a SourceForge Testbed,
> a Bohemian AI development group in some loft somewhere, and TeamCiv
> or other groups with their own support and infrastructure. They
> could all submit quality patches for periodic integration builds
> without needing direct access to the freeciv repository.
>
> What is needed is better management of the CVS mainline, with an
> agreement to accept larger more polished patches less frequently,
> i.e. on a periodic basis.

I don't think this is a good idea. Very few patches have multiple authors,
and feedback on patches is essential for quality. This, I think, is an
essential dilemma.

Take my unique and gameloss unit flags patch, for instance. It begun as a
fairly innocent little thing which I thought was ready for cvs. That is,
until Mike wanted to commit it but discovered that dead players weren't
being handled properly. After sending him more than half a dozen new
iterations of the patch, the patch is x10 in size and complexity, and it
is still far from finished. As Raimar keeps pointing out, the same is the
case with a lot of patches.

My point is that one programmer can easily stare himself blind on some
code and forget things that another programmer can easily spot. Two pair
of eyes is more often than not necessary to get a quality patch. And the
faster this feedback is given, the less time is wasted doing the wrong
things and looking at the wrong places. The earlier this is done, the
easier it is to spot errors, correct bad assumptions and improved a bad
design, since massive patches are harder to read and harder to change.
This is the essential lessons of extreme programming.

So I like patches that are clearly defined. I don't like "area" patches
that attempt to fix a whole lot of things, because chances are some of
these things are wrong, and whoever sits down to find out won't notice.
Time required for extensive testing of a patch increases exponentially
with the number of essential changes it contains. Therefore...

> A big question is can the Freeciv maintainers, and/or their chosen
> helpers turn around a half dozen or dozen major patch integrations
> every few months within a week or two of review and week of CVS update
> and final testing?

...the answer to this question is "no". However, I won't be dogmatic about
it. Areas such as AI - where multiple people work on the same things and
the area of code is rather isolated - may be a place where branches and
area patches could work as you describe it.

> Will there be a standard set of test procedures that evolve to insure
> that the result is usable and key elements aren't broken?

This, I think, is much warranted. I've been thinking of how to develop
such a thing. The best way to do it is probably to make a pseudo-server
that loads a constructed savegame and runs a series of tests on it.

Each function should have a few tests, for example

        FC_TEST(is_diplomat_on_tile(17,15), "diplomat was not found");
        FC_TEST(!is_diplomat_on_tile(1,1), "diplomat found where it "\
                                           "should not have been found");

printing on errors,

        FAILURE in test: is_diplomat_on_tile(17,15)
        Message given: diplomat was not found

These tests should go in a separate directory tests/ and be run on "make
check". Once the framework is there, I think each server-side patch should
be required to add at least one test for each of its additional features.

If people agree this is a good idea, I'll put this on my list of things
to do.

Yours,
Per

Ask not what you can do for your country
Ask what your country did to you
 -- KMFDM, Dogma