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

[Justin Moore <justin@xxxxxxxxxxx>]

   First off, I'd like to offer most of this thread as support of my
initial position about missing the forest for the trees.  Three-quarters
of my first post had to do with documentation and usability (hey, lookie
there, it's the subject line!) and only the last quarter had to do with
the development method.  So which argument did everyone focus on?  That's
right, the development method.  Yes, I feel very strongly about the
somewhat-lacking development method.  But I think the usability is
paramount.  So can we *please* have some discussion about my original
technical comments?

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

   Who knows?  How many people ended up testing it?  I'd rather see 95%
correct code go into a tree that 5x as many people will fiddle around
with.  Provided they know it's an alpha/unstable release and are willing
to play around with it and submit bugs, it'll work fine.  Right now we're
waiting until we have code that's 99.9% correct before we subject our
users to it.

   Small patches can only go so far.  Eventually you hit a point where you
need to put something very large into CVS.  You can't repair a car engine
through the tailpipe.

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

   Neither do I.  The unstable branch wouldn't be a free-for-all, just a
sandbox where people with clear ideas can add them.  Ideas like:

- Borders
- Sound
- Increasing the number of nations
- Server overhault
- Iterators
- etc

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

   It depends on how well managed it is.  If the flow of code then becomes

developers -> test patches -> unstable -> stable -> release

instead of

developes -> test patches -> stable -> release

the unstable step gives people more leeway in what they want to do.

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

2000 07/20 - Freeciv 1.11.4
2001 08/10 - Freeciv 1.12.0
(http://www.freeciv.org/timeline.phtml)

> 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.
>
> Your role model doesn't even use CVS, or in fact any version control
> system... Nothing is perfect.

   Thanks for filling in the blanks for me while I wasn't here.  Let's try
this Mad Libs again:

"Justin thinks Freeciv should mirror the ________ process, which turns out
 good code."                              (noun)

Did he mean:
a) Linux,
b) Debian,
c) FreeBSD,
d) all of the above

Linux has been rocky lately.  I was more thinking of FreeBSD or Debian.
Both have multiple branches yet both turn out good code.

> replying to this already beaten to death topic at 6 AM caused that.

   Isn't that what the Freeciv mailing list is all about? :)

   Again, what do people think of the *technical* stuff I mentioned
earlier?  The unifying GUI, etc, etc, etc?

-jdm

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx