[Moose-g3-devel] Collaboration Tools, auto config

[Josef S. <js...@ya...>]

Embedded comments.

> On 8/16/06, Josef Svitak wrote:
> > The Moose architecture needs some major overhaul before it will be ready
> for
> > prime time. This means that anybody doing development on/against it will
> > probably be facing some fairly major refactoring in the future. Hopefully,
> the
> > kind of major source code manipulation which Hugo employed with Genesis
> will
> > not be needed with Moose. Hugo, if you find yourself maintaining your own
> > version control trees, please let someone know so we can find a way to
> > incorporate the needed functionality.
> >

My understanding was that you would compile and run a simulation, then checkout
a different version of the source code, compile and run, ...ad nauseum. That's
the situation I hope is avoidable in G3.

--- Hugo Cornelis wrote:

> Here is the view I take for developing Genesis3 code : It is common
> for a developer to maintain his own code base, at the same time it
> must be possible to synchronize between different code bases, and
> especially to push important changes to the main line of development.
> These are all important aspects of software development that we must
> _encourage_ : put people in control over the things they need.
> 
> What is needed for Genesis3 is distributed version control, such that
> different people can work on different lines of development, e.g. I
> can work on my code, while Upi is working on his code, and other
> developers -- e.g. students or supporters -- are working on their
> copies, without disrupting main line developments.  I am in the phase
> of evaluating Monotone (http://www.venge.net/monotone/), has excellent
> design, good performance, integrated branch-merging, several GUIs and
> an active community.

I don't really see any benefits to using monotone over subversion or even cvs.
The only problem with modern version control systems in general is developers
checking in code which breaks the compile. We could set up subversion so that
approval is required for checkins and I think we may even be able to run a
compile. At a minimum, we could encourage developers to run 'svn update' and
'make' by displaying a message before the commit. See the 'Hook Scripts'
section of http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html
for more information.

> 
> In a more general context, a couple of other things we need are :
> 
> - configure as a unifying deployment interface to other developments,
> e.g. such that Genesis3 can be a subproject of another project or
> vice-versa.
> - again configure, such that we can deal with most of the portability
> issues for C/C++.

This is debatably the most critical piece missing from Moose at the moment. The
Autoconf family of tools is still the best choice for *nixes, including OSX.
For  Windows, I think the jury is out. We may be able to start with autoconf,
but CMake or SCons are more like choices.


> - automated testing, including coverage analysis, we should not rely
> on sourceforge for this.

agreed. sf doesn't have any special tools to aid in this endeavor anyway, other
than the ability to compile on a range of platforms which we probably don't
have access to. 

> - community tools (a wiki, bugtracker, etc.).  Such tools and their
> performance are going to be the major contributors to the success of
> Genesis3.  I know Michael already took a look at some candidates.

I've been trying to stress how important these kind of tools will be. Please
carry the banner for me, Hugo!


js...@ya...
Software Engineer
Linux/OSX C/C++/Java