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

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx> wrote:
> On Wed, 28 Nov 2001, Kevin Brown wrote:
> 
> > 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
> 
> Ah... but were those changes stable enough to be added to the stable
> branch in the first place? Its a very, very bad idea to keep adding 
> features to a product without any quality control. I have no fancy for
> feature creep either.

I agree.  This is why it's important to do a feature freeze and
concentrate on fixing bugs in the development tree for a while before
releasing it (i.e., using it as the new "stable" branch).

> > branches of the same code than to maintain a stable branch and a
> > development branch.
> 
> I wonder about this. I guess it depends on the patch. If its a narrowly
> focused patch it isn't that hard to maintain.

Well, bugfix-only patches tend to be narrow that way, and those are
the only kinds of patches that'll be allowed in the stable tree,
right?  So the additional effort to maintain a stable tree shouldn't
be terribly great.

> > 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
> 
> This just makes a mess of things IMHO. That ball of mess you call
> "development branch" with N generations of patches... after a couple of
> months do you still remember which patch changed which part? Can you
> easily pull things apart?

Huh?  How does this differ from what we're doing now??  I'm not
arguing that the quality control of the development branch should be
significantly lower (if any) than what we currently have now!

And remember: all of this is being done using CVS, so looking up what
fixed what is relatively simple.  Backing out changes may be more
difficult since newer stuff may depend on those changes, but the
important thing is that NONE OF THAT IS DIFFERENT THAN WHAT WE HAVE
NOW.

If you really want to maintain the development branch the same way CVS
is being maintained right now, I have no problem with that.  It might
make sense to change some of the policies for code inclusion once a
stable/development model is in place but those changes would have to
be discussed, evaluated, and agreed upon first.  But how the
development branch is managed is *independent* of whether or not a
stable branch is created.  Right now the main CVS tree *is* the
development branch, like it or not.


> > 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
> 
> Agreed, we should release more often. But IMHO having 2 branches wouldn't
> help that. It would make matters even worse because it would further
> dilute resources.

Not significantly.  Remember: *ONLY* bugfixes go into the stable tree!
Most of the patches that are submitted are for enhancements, not bug
fixes, so the only additional effort involved would be the application
of the bugfixes to two trees instead of one, and some of the bugfixes
might not even be relevant to the development tree, depending on what
code has changed there.

Want to know why we should do it this way?  Simple: because right now
bugfixes don't make it into a release designed for public consumption
until the next major release.  That's just like how Microsoft does it!
It might be acceptable if your aim is to make people pay the most
money over time for your software, but it's completely inappropriate
for an open-source/free-software project like Freeciv.

Split the tree into stable and development branches and you can
release to the general public against only the stable branch, and
bugfixes can then be cleanly applied and released without having to
*also* release a bunch of untested new stuff to that same population
in the same release.  This is a *major* win compared with what we have
now.  For one thing it means that you don't *have* to get your major
release exactly right the first time (which requires an exceptionally
long bugfix cycle prior to release in order to catch all of the bugs).
Having a stable branch gives you the opportunity to catch bugs after
the fact without having a significant impact on your development.

You can (and should) still release a tarball of your development tree
often, so that people who are interested in being on the bleeding edge
can play with your code and give you feedback.  In short, the *only*
thing that should change is the addition of a stable branch against
which only bugfixes are accepted.


So what are the advantages of the current model over this?  The *only*
one I can see is that it takes a little less manpower than the
stable/development model does, and only a little at that.  Nothing
truly significant, in other words.

> > 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
> 
> Ah yes. Linux...
> Your role model "Linux" takes way too long between releases. 

This depends on how you define a "release".  In terms of how often
they release a tarball for general public consumption, they release
far more often than Freeciv does.  When a bug is found a new minor
version that addresses it is typically released within a few days.
That sometimes works against them, of course, but except for
immediately following a major release, when have you *ever* seen that
happen for Freeciv?  In terms of how often they release a "stable"
major version, they release less often than Freeciv does.  But in
proportion to the amount of code involved, they release more often
than Freeciv does, even for "stable" major versions.


> The Linux method is far from perfect. Besides taking too long, and
> being focused on one single person (single point of failure), they
> add features often without considering the consequences. Case in
> point: the bugged as hell 2.4 VM.  Had they actually been more picky
> on such a critical piece of code as this, these problems could have
> never happened at all.

But none of this is a criticism of the basic two-branch method, only
of how the Linux maintainers end up doing things in practice.

Remember: the linux kernel is *5 times* the size of Freeciv, and they
have A LOT more guys submitting patches to it (but funneling them
through what, two or three guys at most?  Just like Freeciv, right?),
and they aren't using CVS (as you mention).  You shouldn't be
surprised that they release less often than Freeciv does, given all
that.

> Your role model doesn't even use CVS, or in fact any version control
> system... Nothing is perfect.

No, nothing is perfect, but we shouldn't discard a method if it isn't
perfect, as long as it's better than what we have right now.  The
stable/development model has major advantages and no significant
drawbacks compared with what we're doing now.  So why aren't we using
it?



-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

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