On Mon, Aug 29, 2011 at 7:15 AM, Terry Ellison <[email protected]> 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 >
