[Freeciv-Dev] Re: Documentation, Usability and Development

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Nov 28, 2001 at 07:20:17PM -0800, Kevin Brown wrote:
> Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Wed, Nov 28, 2001 at 12:40:39AM -0500, Justin Moore wrote:
> > > 
> > > > and when you're trying to implement a highly complex rule-based,
> > > > extensible game like free-civ, a good place to start is a complete
> > > > analysis of the problem.
> > > 
> > >    Possibly.  But then we get back to the fact that it's just a game.
> > > Perhaps a slightly modified Brooks' rule works here (if you want a
> > > software engineering approach): Plan to throw two away.  Maybe three.  But
> > > in order for us to make those more drastic changes, we need a development
> > > branch (*nudge nudge*).
> > 
> > I have asked mayself hard if I should implement a new client from
> > scratch. I got the network layer finished and then stopped. I think it
> > is a nice goal. If you use the existing wire protocol you can
> > concentrate on one part (the client for example).
> > 
> > As for the development branch: setup your own like the AC people and
> > Ingo have done.
> 
> But this is completely useless unless the changes eventually make it
> into the stable branch!  

> And the AC people are proof that this doesn't happen right now.

From http://www.freeciv.org/remember.html:
\begin{quote}
  Goals: Rules compatible with Civilization I/II.
\end{quote}

We haven't reached this goals yet. So adding other goal is possible
but have to be discussed.

> It's A LOT more work to maintain multiple feature branches of the
> same code than to maintain a stable branch and a development branch.

I'm not sure about this.

> That's why the development branch needs to be an official branch of
> the main project, and *anything* that isn't strictly a bugfix needs to
> go there first.  There has to be significant motivation on the part of
> everyone involved to move stuff from the development branch into the
> stable branch.  Otherwise most new features will never be seen by the
> general userbase (who tend to use only the stable versions).  That's
> why it makes the most sense to periodically do a feature freeze of the
> development branch, get most of the bugs worked out of it, then switch
> it over to the stable branch, and start a new development branch at
> that point.  

> This is the method that has been proven to work with Linux.  Why
> aren't we using it?

Man power. The kernel has 4 maintainers (for 2.0, 2.2, 2.4 and 2.5)
and a dozen people working full time on it.

> I mean, the only extra work involved is to apply bugfix patches
> against the stable branch.  Otherwise it's business as usual.
> 
> More importantly, why are we still discussing this?  :-)  We had this
> very same discussion a number of months ago, and I'm sure that
> discussion wasn't the first of its kind either!

What was the outcome of the last one?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Are you saying that you actually used the Classpath Java AWT classes in 
  addition to the GTK peers and got them to display something?
  Wow.  That's way better than I did and I wrote the code!"
    -- Aaron M. Renn in the classpath mailing list