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

[Reinier Post <rp@xxxxxxxxxx>]

On Sat, Dec 01, 2001 at 02:02:58AM -0500, Ross W. Wetmore wrote:
> 
> 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. 

There is a related plan I've had that  - as usual -  I haven't had
time to implement.  Namely, a simple system for automated compilation
of Freeciv+patches on civserver.freeciv.org.  It would be implemented
with a Makefile.

At the moment, we have a Makefile that fetches the CVS tree, applies
any patches from a given directory, configures, compiles, and starts
the resulting civserver.  We take the set of pending patches in the
bug tracking system, and instead of applying all of them, allow users
to select a subset, using a web interface.  The subset can be encoded
as a Makefile target that stands for the code tree patched with exactly
those patches.  By using a special user and invoking ulimit and nice as
appropriate, you can have a complete Freeciv patch testing environment,
specified with a trivial web form and a Makefile.  It's only two files,
so we could put distribute this, allowing people can set it up on their
own machines; that way we can playtest patches on various platforms.
The system would also indicate the port on which the resulting civserver
is started, and a URL as which the resulting civclient can be fetched
(which is not as useful), or if the compilation failed, the error
messages.  (Interactive debugging is too much to ask.)

A more sophisticated approach would use a database table to record which
combinations of CVS versions and patches have been tried and whether or
not they successfully compile, and include this info in the web form.

How this is related to the insertion of these patches into the CVS tree,
I don't know, but it would be reasonable to allow patches into the tree
only if they have been submitted to the bugtracking system and compile
cleanly on a representative set of platforms - with this system, anyone
can test this, and playtest the result, at any time!

[...]

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

The system above could be of help here.

-- 
Reinier