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 14:57:14 GMT
On Mon, Aug 29, 2011 at 10:40 AM, Terry Ellison <Terry@ellisons.org.uk> wrote:
> Thanks for comments. Rob.  I was hoping to get your and others thoughts on
> this TLD structure issue:  Where do we plug the wiki, the forums, the other
> website services into our svn hierarchy (where XXXX=the relevant service):
>   * incubator/ooo/site/trunk/XXXX
> or
>   * incubator/ooo/site/XXXX/trunk
> or where?
>

How about:

 * incubator/ooo/forum/trunk/XXXX
 * incubator/ooo/wiki/trunk/XXXX

In other words, keep "site" for the markdown/Apache CMS website,
keeping that name by convention, but putting other services in their
own TLD.

Obviously we can assemble the production website via a script,
patching it together from several directories.

Do we lose anything from that approach?  Makes it harder to do a
branch across wiki/site/forums, etc., but I don't see where that
capability would ever be needed.

-Rob

> There's no clear slot in our current TLD structure.  I've put my responses
> on the rest below.
>
> On 29/08/11 14:59, Rob Weir wrote:
>>
>> 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
>
> Tried this before on projects.  It really doesn't work.  There are ~2,500
> files of which we update about 20-30 with a single patch file.  If we do it
> the way you suggest, we would have a huge bulk of revisions every phpBB
> release.  It's a lot easier to keep the build script and the patch file
> under CM and then we only have two files to update every release.
>
>> 3) We try, over time, to push relevant patches upstream to phpBB, to
>> reduce future merge work.
>
> Already do this where I can and have retired a couple of patches this way,
> but the phpBB team are only interested introducing truly general and
> desirable changes into phpBB core.  phpBB includes a concept of plug-in
> modules and hooks, but the current architecture doesn't really facilitate
> the sort of mods that we do.  However, the mods architecture is being
> overhauled in the future phpBB v3.2 and this might enable me to move far
> more of the patch content into a proper ooo-site module.  But this is
> futures, not the current phpBB version.
>
>> 4) We have a script to push our customized phpBB branch into
>> production (or INFRA has a script to pull it)
>
> Already do this.
>
>> 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.
>
> I am really not sure if there any advantages at all in doing this and it
> involves a LOT more work.  Given your next point, I think it sensible to
> avoid nugatory work.
>
>> 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
>
> The whole issue of my being a SPoF for the phpBB application is a concern,
> though Drew already has a pretty good understanding and could step in in
> extremis.  Having another (hopefully younger generation) developer tracking
> all this would be a good thing, but perhaps the easiest step-one would be to
> get everything properly baselined in SVN, then look for volunteers.
>
> Regards
> Terry
>
>

Mime
View raw message