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

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

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

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.


> > 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?  :-)



-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

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