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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Nov 29, 2001 at 01:38:16AM -0800, Kevin Brown wrote:
> Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Wed, Nov 28, 2001 at 07:20:17PM -0800, Kevin Brown wrote:
> > > Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > > 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.
> 
> I was actually thinking more along the lines of things like the
> borders patch and the sound patch.
> 
> There may be some architectural considerations that prevent them from
> being incorporated into CVS but no major change will ever satisfy
> everyone's ideas of architectural nirvana.  That's why if a patch
> accomplishes a particular goal, even if not perfectly, it should
> probably be included in the development tree.  Remember that you can
> disable it in the code if that proves necessary, and even remove it if
> it proves to be a real headache.  But you'll make a lot more forward
> progress if your standards for feature inclusion are more liberal than
> conservative.
> 
> I'm not saying that it's a good idea to apply every patch we get.  But
> it's *also* not a good idea to insist on perfection when it comes to
> patches, either.  

> The insistence on no formatting changes in patches is one example.

IMHO a bad one. Formatting isn't a reason to not include a patch.

> If formatting is so important than we should be using
> indent with the appropriate arguments, and put markers in the code to
> indicate places that indent shouldn't touch (indent supports such
> things, after all, so we should use them, yes?).  Most people are
> perfectly willing to adhere to rules such as the one about formatting,
> but the more such rules you insist upon, the more quickly they'll
> decide to work on some other project that isn't so anal.
> 
> Freeciv is an amazingly cool game and everyone here knows it.  If
> there's a manpower problem, hasn't it occurred to you to ask why?
> 
> 
> > > 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.
> 
> I am.  For one thing, everyone who has a branch has to synchronize
> with everyone else's branch.  That's a nontrivial problem when several
> branches are involved.  And the further the branches diverge from each
> other before being merged the more difficult it is to reconcile them
> later on.
> 
> With a single stable branch and a single development branch, these
> issues disappear because the stable branch gets bugfixes only, which
> are also applied to the development branch when applicable.  That's a
> much simpler problem domain to deal with.
> 
> But most importantly, the features that others are working on get
> maximum exposure to the playtesters, so bugs will be worked out of
> them more quickly, which means that issues such as compatibility get
> resolved much earlier and the overall quality of the contributions
> goes up as a result of the bugfixing process.
> 
> > > 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.
> 
> But we're not trying to maintain several versions of the code
> simultaneously!  We don't care about, e.g., Freeciv 1.0.x because we
> don't need to.  Freeciv isn't a critical application like an operating
> system so we don't have to apply the same standards of maintenance and
> support.  That some people here seem to try anyway only impedes
> forward progress.

Ack, we solves this problem nicely on the network layer. However the
savegame code still contains where I/we aren't sure if it is needed
anymore.

> And while Linux may have a dozen people working on it full time, it
> also has 5 times the amount of code and they're not even using CVS.
> Not to mention that the Linux kernel is a hell of a lot more complex
> and sensitive to errors than Freeciv will ever be.
> 
> The only additional manpower involved in maintaining stable and
> development branches is that required to apply bugfixes to both
> branches instead of just one.  Since most patches are for additional
> functionality, this shouldn't be much of an issue.
> 
> And there's one more argument that should make my stance airtight: if
> we split the code into stable and development branches and don't have
> enough manpower to maintain the stable branch, then what will end up
> happening is that the development branch will get all the changes and
> attention...just like now.  In short, we don't *lose* anything by
> trying.  But if someone has enough interest in maintaining the stable
> version, then splitting the code and handing them the stable branch
> may be enough to kickstart the process.  If they fall down on the job
> then nothing at all is lost because development continues on the
> development branch as usual anyway.
> 
> 
> I guess I can understand the urge to go for the gold whenever pursuing
> an endeavor, but in this case I think that's only hampering us.
> There's a time and a place for "good enough" and I think this is one
> of them.  It doesn't have to be perfect, just better than what we have
> now.  Consistent small improvements, to the process and the code, that
> are actually implemented will get you a lot further than the perfect
> big improvement that isn't ever discovered, much less implemented.

If there is a development branch it should be as follows IMHO:
 - there is a stable tree with maintainer(s)
 - there is a development tree with maintainer(s)
 - both trees have a policy what to accept and what not
 - patch submissions can go to both trees but have a higher chance on
 the development tree
 - if the maintainer(s) of the development tree think that a
 feature/patch is stable they submit it to the stable tree

So the development tree acts as a buffer. Also note that this is
similar to this model:
 - there is a central tree with maintainer(s)
 - each developer has a personal tree
 - the developer develops
 - if the developer thinks that a feature/patch is stable they submit
 it to the central tree

So the development tree will add another layer. This will work only if
the development tree gets publicity (e.g. testers). Special civserver
server slots and regular tar.gz help here.

> > > 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?
> 
> I'm not sure.  I had to leave before it was resolved (if indeed it
> ever was) and haven't looked through my mail archives to follow it up.
> 
> But if nothing was resolved and no improvements resulted from the
> discussion then that's a rather sad statement about us as a group,
> don't you think?  :-)

We all have another life ;) And the mail archive acts sometimes better
than my memory.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Python is executable pseudocode. Perl is executable line noise"
    -- Bruce Eckel