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
team.
* 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
equiv.
Regards
Terry
- SVN and bringing the total end-to-end OOo project under... Terry Ellison
-
