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: jdorje@xxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Documentation, Usability and Development
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 30 Nov 2001 11:48:09 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Thu, Nov 29, 2001 at 04:56:04PM -0500, vze2zq63@xxxxxxxxxxx wrote:
> Raimar Falke wrote:
> > On Wed, Nov 28, 2001 at 07:20:17PM -0800, Kevin Brown wrote:
> <snip: FreeCiv's development model>
> >>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?
> As I recall, everyone (or at least everyone who expressed an opinion, 
> which may or may not have included the maintainers) was in favor of a 
> more open development model.  I believe the idea was to recruit a few 
> more maintainers - but this never happened (AFAIK).
> I will again suggest what I suggested then: the current CVS tree can 
> become the "development" tree.  CVS branches can be used judiciously to 
> fork off "stable" trees - for instance, rather than go into a "freeze" 
> before a release, just make a "stable" branch which is frozen (except 
> for bugfixes), and make beta releases from this branch to get feedback. 
>   The branch can stick around after the release, so that further 
> bugfixes can make it in and a new (small) release can easily be made 
> that includes them (of course, this could really screw up the version 
> numbers).
> Essential to this process is that the development branch is opened up 
> more - more maintainers are needed.  Right now the manpower is unequally 
> distributed, so that many more patches are being made than the 
> maintainers can handle (I realize this is because several of the 
> maintainers are currently busy elsewhere, but that really doesn't change 
> the issue).  The current lag time between patch submission and patch 
> acceptance is so long that any decent-length project (like the general 
> topologies change, or the AI rewrite) may take longer than a release 
> cycle, or longer than the author(s) are willing to spend on it.  I think 
> you'll find that if the lag time drops, more patches will be submitted 
> and some of the estranged patch-writers can be brought back into the fold.
> One alternative is to create a separate CVS tree to become the 
> "development" tree.  More maintainers would be granted access to this 
> tree, and patches would be accepted with a much lower lag time.  But I 
> think this would lead to the development tree quickly becoming more 
> stable _and_ feature-rich than the stable tree, which could easily 
> result in a complete fork of the project (unless the development tree 
> completely replaces the stable tree and we start over, which is very 
> unlikely IMO).

In general: I think we should first try more maintainers and if this
doesn't help speak about the development branch later.


 email: rf13@xxxxxxxxxxxxxxxxx
 checking for the vaidity of the Maxwell laws on this machine... ok
 checking if e=mc^2... ok
 checking if we can safely swap on /dev/fd0... yes
    -- kvirc 2.0.0's configure 

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