incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Ellison <>
Subject SVN and bringing the total end-to-end OOo project under Configuration Management
Date Mon, 29 Aug 2011 11:15:56 GMT
I have tracked the various svn discussions on the DL so far.  This note 
is to initiate a discussion on the specific topic of how we should 
organise the top-level-directory (TLD) structure within svn.  As I have 
mentioned elsewhere, family circumstances have underlined that any of 
use could suddenly leave this project either as a conscious decision or 
due circumstances quite outside our control, and this really underlines 
the issue that all of our work should at some level be brought under 
proper configuration management (CM) and revision control.

IMHO, the current TLD split branches, site, tags, trunk is missing an 
aspect.  The branches and trunk are the main roots for the OOo code-base 
its self, but the OOo also spans a wide range of services which should 
also be under proper CM.  At the moment "site/trunk" superficially has 
the organisation of the "OOo website" but we don't have just one single 
homogeneous website; we have a range website services which we are 
migrating over to Apache and surely the work on *all* of these need to 
be brought under CM.

Let me discuss one example.  We run 10 national language (NL) forums 
based on the "off-the-shelf" FLOSS package phpBB.  However:

     * We also support 16 different language variants, each with its own 
language pack.  (For example we have EN and EN-US so which reflects the 
different spelling practice either side of the "pond".)  And multiple 
languages are supported on each forum (for example I always use English 
(plus occasional google-translate), even when working on the Japanese forum.

     * An out-of the-box phpBB installation is one code-base per (NL) 
forum, which simply doesn't scale across 10 NL instances, so in our 
configuration all 10 instances share the same code-base.

     * We have a number of forum customisations which have been 
requested / negotiated by our community groups.

     * phpBB is regularly upgraded by its maintainers (~ every 6 
months), on each upgrade all of the above needs to be regressed across 
the new version of the package.

So my issue on the "forums" service is what should we keep under CM and 
where.  So for example:

     *  The underlying platform, that is the VM which hosts the service, 
is maintained under CM within /infra/infrastructure/trunk/machines/vms/ 
and  /infra/infrastructure/trunk/docs/machines.  However, these only 
relate to the "root stuff" done by and maintained by the infrastructure 

     *  There is the application, which is maintained by one (or 
hopefully more than) one application maintainer(s).  The application 
maintainers do this work within their normal interactive log-in and 
don't use root privileges.  Here we *don't* need to keep under CM the 
base phpBB + 16 NL packs, because in this case the phpBB developers 
already do this.  However, I have a standard scripted process for 
unpacking this tarballs into correct destination directories, applying 
patches, and any customisation add-ons, and version upgrades, etc.  It 
is this meta-application stuff -- these unpack and build scripts, and 
the OOo site-specific custom add-ons, and build documentation which 
needs to be under CM within the /incubator/ooo tree.

     *  There is the application content, which is huge and changes on a 
minute-by-minute basis, but which is not within CM (in the svn sense), 
but must be backed up properly through a documented backup / 
disaster-recovery policy.

     *  And lastly we have one-off task related items, for example in 
the case of the forums I am developing a process and scripts which 
specifically relate to the migration of the content and cut-over of the 
service from Oracle to Apache.

I have exactly the same hierarchy for the ooo-wiki and I would expect 
the same to be happening for Kay's and Raphael's work also.  So getting 
down to hard-tacks,

     *  Where do we home the *ooo-forums* node in this tree (or any of 
the other service sub-systems)?

     *  Within the *ooo-forums* node, should we have a standard 
next-level sub-structure and if so, then what?

     *  What do we do about existing nodes which do not follow this 
standard.  For example /incubator/ooo/site/trunk/tools seems to really 
be a small subset of the kenai migration scripts so (if we accept my 
argument) should really be in /incubator/ooo/site/trunk/kenai/tools or 


View raw message