Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: Documentation, Usability and Development

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: Justin Moore <justin@xxxxxxxxxxx>, Andrew Sutton <ansutton@xxxxxxx>, Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Documentation, Usability and Development
From: Kevin Brown <kevin@xxxxxxxxxxxxxx>
Date: Wed, 28 Nov 2001 19:20:17 -0800

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

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?  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!

Kevin Brown                                           kevin@xxxxxxxxxxxxxx

    It's really hard to define what "unexpected behavior" means when you're
                       talking about Windows.

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