incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <...@robweir.com>
Subject Re: SVN and bringing the total end-to-end OOo project under Configuration Management
Date Mon, 29 Aug 2011 13:59:05 GMT
On Mon, Aug 29, 2011 at 7:15 AM, Terry Ellison <terrye@apache.org> wrote:
> 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.
>

Could we do something like this:

1) Check in the source for whatever base phpBB we're customizing.  So
the "official" phpBB release becomes the trunk.

2) Our customizations occur in a branch

3) We try, over time, to push relevant patches upstream to phpBB, to
reduce future merge work.

4) We have a script to push our customized phpBB branch into
production (or INFRA has a script to pull it)

5) When we get new patches, revisions, etc., from phpBB we check that
into trunk and then do a merge on our branch

In other words, we keep the unaltered phpBB in SVN, and do our
customization work in a branch.

Backups of content, I think, are unrelated.

Another thing to consider is asking, longer term, who is going to
maintain phpBB @ Apache?  Are we the only project that will use it?
Or do we think that others will adopt it as well?  If not at a project
level, maybe Apache would find it interesting at a foundation-level
for interactions with the public?  If we can encourage broader use at
Apache, and get a couple more people able and willing to support it at
the INFRA level, then it would make more sense of the base code to be
at the INFRA level.

-Rob


> Regards
> Terry
>

Mime
View raw message