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: <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: It is feature freeze time
From: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Date: Sat, 27 Apr 2002 21:07:38 +0200 (MEST)

On Sat, Apr 27, 2002 at 01:34:55AM +0200, Per I. Mathisen wrote:
> >> I want people here to make an effort to debug what we have now so that we
> >> can ship it.

At 09:35 AM 02/04/27 +0200, Raimar Falke wrote:
> >I also see this problem. We have to avoid splitting the developers
> >base.

On Sat, 27 Apr 2002, Ross W. Wetmore wrote:
> I suspect that your developer base is already split along the lines of
> things that interest them

I agree.

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

Sounds like total overkill to me. Please give some examples of projects
where this methodology is being used with success. The free software
projects I know that use branches, use this only for large, experimental
code departures.

The only place where I can see that this could be warranted for freeciv is
if we wanted to allow some poeple to rewrite the server-side ai while not
touching the old server-side ai until the new one was ready. I think the
corecleanups is the kind of thing we should _not_ do in a separate branch.
That would mean everyone other than the author would completely lose the
ability to understand what changes have gone in, because the changes
become so many, different and complicatedly interrelated.

Branching off a stable branch and continuing development on the main
trunk, that is a concept I can understand. But giving each developer his
own branch? I've never seen nor tried anything like it.

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

I can see your point.

Yours,
Per

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



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