[Freeciv-Dev] Development Strategies [Was Documentation, Usability and Development]

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

To elaborate on Jason's suggestions.

There are several useful development models that might be applied here.

In one case every patch that passes a cursory sanity test is checked in
to a new branch off its specified base and assigned a development path
identity that allows work to proceed along this branch.

This does several things. First, it is a record of every submission so 
it can be recovered. Second, it allows the submitter(s) to work at 
cleaning this up in a real dev environment. It also makes it relatively
easy to merge mainline changes into this branch at any point. This lets
big patches be worked on for a long time, while smaller ones can move
ahead through the process. 

The responsibility for maintaining currency in the long running patches 
is up to those developers, thus they can work on the feature for awhile, 
do a resync at a milestone, then go back to feature cleanup and then do 
the final resync and test cycle. Clearly the more often they resync, the 
easier the resyncs are and the more likely that others may rollin their 
patch to see what is happening (rolling in and out a patch after a resync 
from the base branch should be a painless operation).

Note: if you merge mainline into this branch, then if mainline has not 
changed and you merge this branch back into mainline, mainline will be
exactly equivalent to the branch, and this will correspond to updating
mainline with the patch.

So, at the point that the patch is considered ready for inclusion into
the mainline, you merge mainline into the patch branch. You checkout,
build and run your final sanity tests. If everything is okay, then you
merge the patch branch back into mainline and you are guaranteed of a
stable mainline (as stable as your testing on the branch cares to be)
with the patch applied.

Clearly the mainline branch is accessible only to the Freeciv core
maintainers and they have the collective responsibility and authority
on the final decision of what goes in there.

But, you can give access to anyone, or a selected set of patch branch
developers to do as they will on the patch branches. 

Now in a second case, you run a development and mainline branch. The 
above model is applied except substitute development branch for mainline
in the above scenario. You might consider opening up access to the 
development branch to "reviewers" or maintainers-in-training so there
is more manpower to handle things there.

The development branch is considered "experimental", i.e. although it is
relatively stable, a lot of things can be introduced there and perhaps
even deployed to freeciv servers to get feedback on whether these are
really good ideas. Patches move into the development branch once they
are stable and accepted.

At various points the maintainers decide amongst themselves, or with 
input from the server experience and/or the dev-list what features
should be in the "stable" product. The mainline would be branched and
sets of patches or a snapshot of the development tree merged into
the branch. This would then be cleaned up and thoroughly tested. At 
the point that it was considered ready for beta, any interim changes
(i.e. bugfixes) applied to the mailine would be merged into this devtree,
run through a QA cycle, and then merged back into the mainline. The
branch would continue as the beta release, and eventually the 
maintenance tree for the release. Any further updates would be
periodically merged back into the mainline to keep it current though
eventually, the mainline would move on to the next release.

Here is a crude pictorial flow of the process.

 mainline    devbranch
  |
  + - - - - - - > +    patch01
  |               + - - > + submitted
  |               |       + updated
  |               + - - > + synced
  |               + < - - + applied        patch02
  |               + - - - - - - - - - - - - - + submitted
  |               +    patch03                + updated
  |               + - - > + submitted         |
  |               | - - - | - - - - - - - - > + synced
  |   bugfix      |       + updated           |
  | < - +         + - - > + synced            + updated
  |               |       + updated           |
  |               + - - > + synced            + updated
  |               + < - - + applied           |
  |               |                           |
  |               + - - - - - - - - - - - - > + synced
  |   beta1       + < - - - - - - - - - - - - + applied
  + - > +         |
  |     + - - - > + synced
  |     + < - - - + applied
  |     |  bugfix |                        patch04
  |     + < - +   + - - - - - - - - - - - - > + submitted
  |     |         |    patch05                |
  + < - + applied + - - > +                   |
  |     o release |       |                   |
  |     + <bugfix |       + updated           |
  |     o pt-rel  + - - > + synced            + updated
  |               +       + rejected          |
  |               |                           |
  |               + - - - - - - - - - - - - > + synced
  |   beta2       + < - - - - - - - - - - - - + applied
  + - > +         |
  |     + - - - > + synced
  |     + < - - - + applied
  |     + <bugfix |
  + < - + applied |
  |     o release |
  |               |

As a final twist, if you allow a few long running "patches" or really
alternate development branches, it might not be unreasonable for the
FreeCivAC, or TeamFreeciv type people to put their stuff on an alternate
development branch. The advantage for Freeciv, is that responsible groups
of people could manage their own devpaths, but the whole collection of
source would be maintained in a unified way that allowed a lot of cross
fertilization and poaching of ideas between groups. It would not be
unreasonable for example, for the official Freeciv maintainers to produce
a release that took components from multiple development paths. 

It is also the case that contributors would be able to try out and help
with fixes to any of these devpaths with minimal fuss because of a lot
of the shared tools, techniques and general increase in interaction. They
might see a lot of help be provided to move the alternate Freecivs to a 
more current release level as part of the release or post-release activity.

At 04:56 PM 01/11/29 -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>
>
>> 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).
>
>jason

Cheers,
RossW
=====