Adding SVN Layout Ideas to Re: Apache CMS Workflow and a Key Question

[Dave Fisher <da...@comcast.net>]

On Jul 8, 2011, at 1:39 PM, Dave Fisher wrote:

> Kay's questions on https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-to-ASF-site-recommendation have helped me focus on how to enable website contributions.
> 
> I really like the Apache CMS. Here is possible a workflow that would allow non-committers to be able to contribute patches to both AOOo content and the site build we implement over the Apache CMS.
> 
> Workflow would be something like this:
> 
> (1) Setup prerequisite software - Python-Markdown, DITA ...
> 
> (2) svn checkout of the AOOo documentation / website repository including scripts.
> 
> (3) Contributor edits documentation files - mdtext, html, javascript, css, dita(?), ....
> 
> (4) Contributor performs test staging builds on their local machine in order to test the results in complete isolation.
> This is a critical requirement. We should want to allow non-committers to easily test ideas without needing a committer to hold their hand with every little design tweak they would like to try.
> 
> (5) When the contributor has updated content ready then they can proceed by according to 
> 	(a) Non-committer - submit an svn diff as a patch.
> 	(b) Committer - perform an svn commit which triggers an actual staging build.
> 
> Here is the question. What is the script that performs the staging? In the Apache CMS it is triggered by a commit, but for local use, the contributor has to run a version of that script. I know that it will somehow invoke one of these:
> 
> ./site/trunk/lib/path.pm
> ./site/trunk/lib/view.pm

I found the docs: http://wiki.apache.org/river/WorkingWithApacheCmsFromTheCommandLine

This helps with both (1) and (4)

> Looking for the answer and also comments on this workflow.

Next step is to layout the svn website directory structure. In the incubator we only have a single site. Our prototype openoffice.org will need to be contained within a directory all publishing through the Apache CMS

Here is a proposed layout:

(1) A full export of all webcontent repositories from Kenai. Done via svn export.

/site/trunk/content/kenai/${OOo-project}

The script in ./trunk/tools/dev/fetch-all-web.sh can be adapted to fill this directory with an svn export. SInce this will be a large import into Apache we will need to co-ordinate with Infrastructure.

We can then write scripts to clean up kenai content into something like the following structure.

(2) The various parts of the future openoffice.org sites.

/site/trunk/content/openofficeorg/ooo/www/
/site/trunk/content/openofficeorg/ooo/why/
...

(3) l10n and the various native language versions of openoffice.org

/site/trunk/content/openofficeorg/l10n/
/site/trunk/content/openofficeorg/${lang}/www/
/site/trunk/content/openofficeorg/${lang}/why/
...

(4) All other projects with remapping if desired to be part of the openoffice.apache.org.

/site/trunk/content/openofficeorg/${group}/${project}

groups and project layout can be determined as we write the scripts to move webcontent from the kenai export.

Note that our incubator website will have everything in /site/trunk/content/openofficeorg/.

When we graduate, or begin to publish openoffice.org we can re-arrange the directories.

Regards,
Dave

Re: Adding SVN Layout Ideas to Re: Apache CMS Workflow and a Key Question

[Greg Stein <gs...@gmail.com>]

On Fri, Jul 8, 2011 at 22:21, Dave Fisher <da...@comcast.net> wrote:
>...
> (1) A full export of all webcontent repositories from Kenai. Done via svn export.
>
> /site/trunk/content/kenai/${OOo-project}
>
> The script in ./trunk/tools/dev/fetch-all-web.sh can be adapted to fill this directory with an svn export. SInce this will be a large import into Apache we will need to co-ordinate with Infrastructure.

I don't have any input on your overall plan, but have svn expertise to
lend here.

If you're doing an "svn export", then that implies you're just
grabbing the tip from the kenai data. You will then have a big
directory of content to "svn import" into the ASF repository. That
does *not* require coordination with Infrastructure. That is a simple
commit, and has no impact on other people using the repository.

If you wanted to retain history, then you would need something more
than "svn export", and you would produce a dumpfile. At that point,
you would need to coordinate with Infrastructure to load the dumpfile.

>...

Cheers,
-g