You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Dave Fisher <da...@comcast.net> on 2011/07/08 22:39:03 UTC
Apache CMS Workflow and a Key Question
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
Looking for the answer and also comments on this workflow.
Best Regards,
Dave
Re: Adding SVN Layout Ideas to Re: Apache CMS Workflow and a Key Question
Posted by 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
Adding SVN Layout Ideas to Re: Apache CMS Workflow and a Key Question
Posted by 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: Apache CMS Workflow and a Key Question
Posted by Dave Fisher <da...@comcast.net>.
On Jul 14, 2011, at 3:09 PM, Marcus (OOo) wrote:
> Am 07/14/2011 09:59 PM, schrieb Dave Fisher:
>> I'm top posting - sorry about that. Let's summarized some facts.
>>
>> - The Apache Way requires a certain process. Commit then Review OR Review the Commit. This is essential project governance.
>>
>> - The approach I outlined is admittedly like what a code developer would do. It is command line and text oriented.
>>
>> - The openoffice.org project at Sun/Oracle has more sub-projects than the Apache Software Foundation has projects.
>>
>> -There was a model for this in Apache - the Apache Jakarta project - and the trend here which looks almost done is to make subprojects into TLP (Apache POI was one) or retire them. Governance became difficult in Jakarta.
>>
>> - To do as you suggest and give certain developers limited access to parts of the website is a good one, but the governance of that would need to match the Apache Way.
>>
>> I think that there are four to-dos.
>>
>> (1) Get the existing svn website repository into the project's svn. I think we should just export it all and then add to the project. The move from cvs to svn in kenai has apparently lost all prior history. Do we care? If exports are fine then we can proceed.
>
> Yes, history is lost. Here is an example on a file that was imported into Kenai's SVN repo:
>
> r1 | kenaiadmin | 2011-02-23 15:51:43 +0100 (Wed, 23 Feb 2011) | 1 line
>
> initial import
>
> So, when we import the Kenai SVN into the Apache SVN then commit history is not important as we will loose data from February until today.
>
> At least, that's my opinion.
>
>> (2) Figure out how the current is converted and processed into pages in the project site. The method I described should be sufficient.
>
> I've no clue as it's happening somewhere inside Kenai.
I was quick and unclear here. I meant the process using the Apache CMS to create am Apache OpenOffice.org version of the Kenai produced OpenOffice.org. It is more about designing our header, footer, and navigation and then putting current content into that skeleton.
http://incubator.apache.org/openofficeorg/website-local.html#directory_layout
>
>> (3) Determine how to put a front-end on this. If the Apache CMS bookmarklet is close enough to the current workflow perhaps we can figure out how make it work for non-commmitters. To make it submit patches to JIRA/bugzilla.
>>
>> (4) Discuss what a sub-project model for Apache OpenOffice.org would be like, but very slowly. We definitely would need to have a high bar and we'll need to get used to working with each other. There will certainly need to be a sufficient number of PPMC members that can govern a sub-project. For the foreign language projects this may require three people on the PPMC fluent enough to know that the ASF is not publishing improper content and willing to oversee that content.
>>
>> Regards,
>> Dave
>
> Marcus
Dave
>
>
>
>> On Jul 14, 2011, at 11:43 AM, Kay Schenk wrote:
>>
>>>
>>>
>>> On 07/13/2011 10:17 PM, Arthur Buijs wrote:
>>>> On 07/14/2011 01:25 AM, Kay Schenk wrote:
>>>>> On 07/08/2011 01:39 PM, Dave Fisher wrote:
>>>>>>
>>>>>> (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.
>>>>>
>>>>> OK, I, personally am still not thrilled about this approach. I think
>>>>> before deciding anything, maybe someone can give us a count of actual
>>>>> "content developers/admins/software developers" on the existing kenai
>>>>> site -- this would be folks with direct "update/committer" rights in the
>>>>> existing environment to see if we can get a breakdown of what there is
>>>>> now at the openoffice.org and some idea of how it's being maintained.
>>>>>
>>>>> I'll be happy to contact the kenai admins and see what I can find out.
>>>>>
>>>>> If there was some way to use an alternate "something" to maintain the
>>>>> "user facing" site, this would be MUCH better. Right now, I'm looking at
>>>>> the "es" project on openoffice.org. There are 13 (out of 347 "es"
>>>>> members) users with development access to this (web) site. These folks
>>>>> have basically been working in this and only this realm. It would be
>>>>> optimal to have some facility where these same folks, should they choose
>>>>> to join say via an Apache wiki account or other mechanism, would be
>>>>> given the SAME access as they have on the new production environment
>>>>> without a lot of complication.
>>>>
>>>> Please explain what you mean by new production environment in the last
>>>> sentence and how much more complicated it would be.
>>>
>>> This applies to the OpenOffice.org website, nothing more.
>>>
>>> Currently, the roles of "content developer"/"software developer" have direct (was cvs, now svn access) to the area for their designated sub-project. Not being familiar with kenai, I don't know details of how this is controlled but I can certainly find out.
>>>
>>> In the "new production environment", i.e. wherever the New OpenoOffic.org "user facing web site" will exist -- initially there was a suggestion to put this as oru current incubator site --
>>>
>>> http://incubator.apache.org/openofficeorg/
>>>
>>> if I'm not mistaken.
>>>
>>> That new area requires an Apache committer status for direct access.
>>>
>>> Dave's process regarding regarding a local test area for contributors on their own box, making changes and then submitting them for actual incorporation (if I'm understanding this correctly) is WAY more complicated than the existing contributors are used to dealing with, or would want to IMO. My point is the current "content developer" community is apparently regarded as trustworthy in their particular realms.
>>>
>>> Could the "user facing" web area be built using something like Apache Cocoon (which frankly I know nothing about) or somehow set-up sub-developer regions on the existing project so folks could get commit rights but only on certain areas and use the GUI tool, which would be optimal.
Re: Apache CMS Workflow and a Key Question
Posted by BRM <bm...@yahoo.com>.
----- Original Message ----
> From: Marcus (OOo) <ma...@wtnet.de>
> Am 07/18/2011 04:31 PM, schrieb BRM:
> > ----- Original Message ----
> >
> >> From: Marcus (OOo)<ma...@wtnet.de>
> >> Am 07/14/2011 09:59 PM, schrieb Dave Fisher:
> >>> (1) Get the existing svn website repository into the project's svn. I
>think
> >> we should just export it all and then add to the project. The move from
>cvs to
> >> svn in kenai has apparently lost all prior history. Do we care? If exports
>are
> >> fine then we can proceed.
> >>
> >> Yes, history is lost. Here is an example on a file that was imported
> >> into Kenai's SVN repo:
> >>
> >> r1 | kenaiadmin | 2011-02-23 15:51:43 +0100 (Wed, 23 Feb 2011) | 1 line
> >>
> >> initial import
> >>
> >> So, when we import the Kenai SVN into the Apache SVN then commit history
> >> is not important as we will loose data from February until today.
> >>
> >> At least, that's my opinion.
> >>
> >
> > FWIW - there is a project cvs2svn that can convert CVS/RCS into SVN dumps
>that
> > can then be loaded with full version history.
> >
> > You can find it here: http://cvs2svn.tigris.org/
> >
> > If the CVS used previously was CVSNT or another variant that had some
> > extensions, then it would be useful to lend them a hand with the support
for
> > that CVS variant (or completing the CVSNT support).
> > Their resources are extremely limited but it is generally doable.
> >
> > So, all is not necessarily lost - but it does depend on whether you want to
> > reload the SVN repo.
>
> I don't know how you thought about CVS but the respective repo is
> already on SVN.
>
I am just noting that if you all cared about the history then there is a way to
get it given the previous repository, responding to what I quoted which
mentioned CVS.
I believe cvs2svn also supports several other repository systems; for example,
they also have a cvs2git tool.
It may be of interest to keep the history, but in a secondary repository for
archival/research purposes - again, supposing it is available.
Or you can do the following:
1. Build the history
2. Rename the existing repository
3. Load the existing history into a new repository
4. Dump the existing repository history
5. Load the existing repository history into the new repository as well.
The 'svnadmin' tool has a great functionality - you can load multiple SVN Dumps
into the same repository, and there are tools to make adjustments in both it and
the cvs2svn tools - e.g. in case the tree names changed.
I would caution though, that the it will take a good amount of time to do step
#2 above - the larger the dump file the longer it takes to load in.
So to recap, all I am saying is that it is possible to recover the history if
the community desired to do so; and that it may even be possible to do so while
keeping the existing changes since the existing SVN repository was setup.
Now, if it's of no interest to the community, then fine. This will just be a
footnote in the mailing list.
As always, $0.02
Ben
Re: Apache CMS Workflow and a Key Question
Posted by BRM <bm...@yahoo.com>.
----- Original Message ----
> From: Marcus (OOo) <ma...@wtnet.de>
> To: ooo-dev@incubator.apache.org
> Sent: Mon, July 18, 2011 12:59:07 PM
> Subject: Re: Apache CMS Workflow and a Key Question
>
> Am 07/18/2011 06:31 PM, schrieb Pedro F. Giffuni:
> >
> >
> > --- On Mon, 7/18/11, Marcus (OOo)<ma...@wtnet.de> wrote:
> >
> > ...
> >>>
> >>> So, all is not necessarily lost - but it does depend
> >>> on whether you want to reload the SVN repo.
> >>
> >> I don't know how you thought about CVS but the respective
> >> repo is already on SVN.
> >>
> >
> > I am confused. Apparently (I am a newcomer) OOo has moved
> > from several VCSs:
> > CVS --> SVN --> Hg --> SVN (Apache)
> >
> > In each conversion one necessarily looses some information.
> > Have we lost significant history during any of those conversions?
> >
> > Perhaps we can take a previous SVN (assumming it exists) and
> > do the conversion progressively from there?
> >
> > Just wondering though.. I am sure the people doing this are
> > taking their time for a reason ;).
>
> Please don't mix things up. I'm talking about the SVN repo that has the
> website stuff and not the core source code of OOo.
>
> Of course we want to keep the repo history of the OOo source code. But
> IMHO it's not necessary to keep itfor the website. Of course we can do
> this, too, if someone means it's important. But it would be the stuff
> from February, 23rd until today. The older stuff is already lost.
>
Okay. Understood. I think we got some confusion into this thread.
Ben
Re: Apache CMS Workflow and a Key Question
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/18/2011 06:31 PM, schrieb Pedro F. Giffuni:
>
>
> --- On Mon, 7/18/11, Marcus (OOo)<ma...@wtnet.de> wrote:
>
> ...
>>>
>>> So, all is not necessarily lost - but it does depend
>>> on whether you want to reload the SVN repo.
>>
>> I don't know how you thought about CVS but the respective
>> repo is already on SVN.
>>
>
> I am confused. Apparently (I am a newcomer) OOo has moved
> from several VCSs:
> CVS --> SVN --> Hg --> SVN (Apache)
>
> In each conversion one necessarily looses some information.
> Have we lost significant history during any of those conversions?
>
> Perhaps we can take a previous SVN (assumming it exists) and
> do the conversion progressively from there?
>
> Just wondering though.. I am sure the people doing this are
> taking their time for a reason ;).
Please don't mix things up. I'm talking about the SVN repo that has the
website stuff and not the core source code of OOo.
Of course we want to keep the repo history of the OOo source code. But
IMHO it's not necessary to keep itfor the website. Of course we can do
this, too, if someone means it's important. But it would be the stuff
from February, 23rd until today. The older stuff is already lost.
Marcus
Re: Apache CMS Workflow and a Key Question
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
--- On Mon, 7/18/11, Marcus (OOo) <ma...@wtnet.de> wrote:
...
> >
> > So, all is not necessarily lost - but it does depend
> > on whether you want to reload the SVN repo.
>
> I don't know how you thought about CVS but the respective
> repo is already on SVN.
>
I am confused. Apparently (I am a newcomer) OOo has moved
from several VCSs:
CVS --> SVN --> Hg --> SVN (Apache)
In each conversion one necessarily looses some information.
Have we lost significant history during any of those conversions?
Perhaps we can take a previous SVN (assumming it exists) and
do the conversion progressively from there?
Just wondering though.. I am sure the people doing this are
taking their time for a reason ;).
cheers,
Pedro.
Re: Apache CMS Workflow and a Key Question
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/18/2011 04:31 PM, schrieb BRM:
> ----- Original Message ----
>
>> From: Marcus (OOo)<ma...@wtnet.de>
>> Am 07/14/2011 09:59 PM, schrieb Dave Fisher:
>>> (1) Get the existing svn website repository into the project's svn. I think
>> we should just export it all and then add to the project. The move from cvs to
>> svn in kenai has apparently lost all prior history. Do we care? If exports are
>> fine then we can proceed.
>>
>> Yes, history is lost. Here is an example on a file that was imported
>> into Kenai's SVN repo:
>>
>> r1 | kenaiadmin | 2011-02-23 15:51:43 +0100 (Wed, 23 Feb 2011) | 1 line
>>
>> initial import
>>
>> So, when we import the Kenai SVN into the Apache SVN then commit history
>> is not important as we will loose data from February until today.
>>
>> At least, that's my opinion.
>>
>
> FWIW - there is a project cvs2svn that can convert CVS/RCS into SVN dumps that
> can then be loaded with full version history.
>
> You can find it here: http://cvs2svn.tigris.org/
>
> If the CVS used previously was CVSNT or another variant that had some
> extensions, then it would be useful to lend them a hand with the support for
> that CVS variant (or completing the CVSNT support).
> Their resources are extremely limited but it is generally doable.
>
> So, all is not necessarily lost - but it does depend on whether you want to
> reload the SVN repo.
I don't know how you thought about CVS but the respective repo is
already on SVN.
Marcus
Re: Apache CMS Workflow and a Key Question
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
--- On Mon, 7/18/11, BRM <bm...@yahoo.com> wrote:
...
> >
> > So, when we import the Kenai SVN into the Apache
> SVN then commit history
> > is not important as we will loose data from
> February until today.
> >
> > At least, that's my opinion.
> >
>
> FWIW - there is a project cvs2svn that can convert CVS/RCS
> into SVN dumps that
> can then be loaded with full version history.
>
> You can find it here: http://cvs2svn.tigris.org/
>
...
>
> So, all is not necessarily lost - but it does depend on
> whether you want to reload the SVN repo.
>
I'd like to see that mainly for personal pleasure: it
would be cool to trace the project to it's roots. Perhaps
it's useful for patent issues too (determining prior art,
or finding the origin of some particular piece
of code?).
cheers,
Pedro.
Re: Apache CMS Workflow and a Key Question
Posted by BRM <bm...@yahoo.com>.
----- Original Message ----
> From: Marcus (OOo) <ma...@wtnet.de>
> Am 07/14/2011 09:59 PM, schrieb Dave Fisher:
> > (1) Get the existing svn website repository into the project's svn. I think
>we should just export it all and then add to the project. The move from cvs to
>svn in kenai has apparently lost all prior history. Do we care? If exports are
>fine then we can proceed.
>
> Yes, history is lost. Here is an example on a file that was imported
> into Kenai's SVN repo:
>
> r1 | kenaiadmin | 2011-02-23 15:51:43 +0100 (Wed, 23 Feb 2011) | 1 line
>
> initial import
>
> So, when we import the Kenai SVN into the Apache SVN then commit history
> is not important as we will loose data from February until today.
>
> At least, that's my opinion.
>
FWIW - there is a project cvs2svn that can convert CVS/RCS into SVN dumps that
can then be loaded with full version history.
You can find it here: http://cvs2svn.tigris.org/
If the CVS used previously was CVSNT or another variant that had some
extensions, then it would be useful to lend them a hand with the support for
that CVS variant (or completing the CVSNT support).
Their resources are extremely limited but it is generally doable.
So, all is not necessarily lost - but it does depend on whether you want to
reload the SVN repo.
$0.02
Ben
Re: Apache CMS Workflow and a Key Question
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/14/2011 09:59 PM, schrieb Dave Fisher:
> I'm top posting - sorry about that. Let's summarized some facts.
>
> - The Apache Way requires a certain process. Commit then Review OR Review the Commit. This is essential project governance.
>
> - The approach I outlined is admittedly like what a code developer would do. It is command line and text oriented.
>
> - The openoffice.org project at Sun/Oracle has more sub-projects than the Apache Software Foundation has projects.
>
> -There was a model for this in Apache - the Apache Jakarta project - and the trend here which looks almost done is to make subprojects into TLP (Apache POI was one) or retire them. Governance became difficult in Jakarta.
>
> - To do as you suggest and give certain developers limited access to parts of the website is a good one, but the governance of that would need to match the Apache Way.
>
> I think that there are four to-dos.
>
> (1) Get the existing svn website repository into the project's svn. I think we should just export it all and then add to the project. The move from cvs to svn in kenai has apparently lost all prior history. Do we care? If exports are fine then we can proceed.
Yes, history is lost. Here is an example on a file that was imported
into Kenai's SVN repo:
r1 | kenaiadmin | 2011-02-23 15:51:43 +0100 (Wed, 23 Feb 2011) | 1 line
initial import
So, when we import the Kenai SVN into the Apache SVN then commit history
is not important as we will loose data from February until today.
At least, that's my opinion.
> (2) Figure out how the current is converted and processed into pages in the project site. The method I described should be sufficient.
I've no clue as it's happening somewhere inside Kenai.
> (3) Determine how to put a front-end on this. If the Apache CMS bookmarklet is close enough to the current workflow perhaps we can figure out how make it work for non-commmitters. To make it submit patches to JIRA/bugzilla.
>
> (4) Discuss what a sub-project model for Apache OpenOffice.org would be like, but very slowly. We definitely would need to have a high bar and we'll need to get used to working with each other. There will certainly need to be a sufficient number of PPMC members that can govern a sub-project. For the foreign language projects this may require three people on the PPMC fluent enough to know that the ASF is not publishing improper content and willing to oversee that content.
>
> Regards,
> Dave
Marcus
> On Jul 14, 2011, at 11:43 AM, Kay Schenk wrote:
>
>>
>>
>> On 07/13/2011 10:17 PM, Arthur Buijs wrote:
>>> On 07/14/2011 01:25 AM, Kay Schenk wrote:
>>>> On 07/08/2011 01:39 PM, Dave Fisher wrote:
>>>>>
>>>>> (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.
>>>>
>>>> OK, I, personally am still not thrilled about this approach. I think
>>>> before deciding anything, maybe someone can give us a count of actual
>>>> "content developers/admins/software developers" on the existing kenai
>>>> site -- this would be folks with direct "update/committer" rights in the
>>>> existing environment to see if we can get a breakdown of what there is
>>>> now at the openoffice.org and some idea of how it's being maintained.
>>>>
>>>> I'll be happy to contact the kenai admins and see what I can find out.
>>>>
>>>> If there was some way to use an alternate "something" to maintain the
>>>> "user facing" site, this would be MUCH better. Right now, I'm looking at
>>>> the "es" project on openoffice.org. There are 13 (out of 347 "es"
>>>> members) users with development access to this (web) site. These folks
>>>> have basically been working in this and only this realm. It would be
>>>> optimal to have some facility where these same folks, should they choose
>>>> to join say via an Apache wiki account or other mechanism, would be
>>>> given the SAME access as they have on the new production environment
>>>> without a lot of complication.
>>>
>>> Please explain what you mean by new production environment in the last
>>> sentence and how much more complicated it would be.
>>
>> This applies to the OpenOffice.org website, nothing more.
>>
>> Currently, the roles of "content developer"/"software developer" have direct (was cvs, now svn access) to the area for their designated sub-project. Not being familiar with kenai, I don't know details of how this is controlled but I can certainly find out.
>>
>> In the "new production environment", i.e. wherever the New OpenoOffic.org "user facing web site" will exist -- initially there was a suggestion to put this as oru current incubator site --
>>
>> http://incubator.apache.org/openofficeorg/
>>
>> if I'm not mistaken.
>>
>> That new area requires an Apache committer status for direct access.
>>
>> Dave's process regarding regarding a local test area for contributors on their own box, making changes and then submitting them for actual incorporation (if I'm understanding this correctly) is WAY more complicated than the existing contributors are used to dealing with, or would want to IMO. My point is the current "content developer" community is apparently regarded as trustworthy in their particular realms.
>>
>> Could the "user facing" web area be built using something like Apache Cocoon (which frankly I know nothing about) or somehow set-up sub-developer regions on the existing project so folks could get commit rights but only on certain areas and use the GUI tool, which would be optimal.
Re: Apache CMS Workflow and a Key Question
Posted by Dave Fisher <da...@comcast.net>.
On Jul 14, 2011, at 2:32 PM, Kay Schenk wrote:
>
>
> On 07/14/2011 12:59 PM, Dave Fisher wrote:
>> I'm top posting - sorry about that. Let's summarized some facts.
>>
>> - The Apache Way requires a certain process. Commit then Review OR
>> Review the Commit. This is essential project governance.
>>
>> - The approach I outlined is admittedly like what a code developer
>> would do. It is command line and text oriented.
>>
>> - The openoffice.org project at Sun/Oracle has more sub-projects than
>> the Apache Software Foundation has projects.
>
> yeah...well... :/
>
>>
>> -There was a model for this in Apache - the Apache Jakarta project -
>> and the trend here which looks almost done is to make subprojects
>> into TLP (Apache POI was one) or retire them. Governance became
>> difficult in Jakarta.
>
> sorry...what's "TLP"
Top Level Project.
>
>>
>> - To do as you suggest and give certain developers limited access to
>> parts of the website is a good one, but the governance of that would
>> need to match the Apache Way.
>>
>> I think that there are four to-dos.
>>
>> (1) Get the existing svn website repository into the project's svn. I
>> think we should just export it all and then add to the project. The
>> move from cvs to svn in kenai has apparently lost all prior history.
>> Do we care? If exports are fine then we can proceed.
>>
>> (2) Figure out how the current is converted and processed into pages
>> in the project site. The method I described should be sufficient.
>
> I'll look at your post again. I know a little bit about current processing, but really, since the move to kenai, not much.
I think I was little short in my description and wish I had time today to explain it better.
The basic idea is to build the appropriate skeleton to drop each page of content into.
In others the master layout.
>
>>
>> (3) Determine how to put a front-end on this. If the Apache CMS
>> bookmarklet is close enough to the current workflow perhaps we can
>> figure out how make it work for non-commmitters. To make it submit
>> patches to JIRA/bugzilla.
>
> Well I spent this am looking at the CMS info that's out there, and without actual access right now, I really couldn't determine much about capabilities.
>
>>
>> (4) Discuss what a sub-project model for Apache OpenOffice.org would
>> be like, but very slowly. We definitely would need to have a high bar
>> and we'll need to get used to working with each other. There will
>> certainly need to be a sufficient number of PPMC members that can
>> govern a sub-project.
>
> I understand
>
> For the foreign language projects this may
>> require three people on the PPMC fluent enough to know that the ASF
>> is not publishing improper content and willing to oversee that
>> content.
>
> hmmm...OK. Personally, I don't have any idea how difficult this would be.
Nor I, It was discussed and deferred in the first week or so of the project.
It will certainly be a topic. I don't think it will be a problem for certain languages, but others...
>
>>
>> Regards, Dave
>
> Thanks for the additional thoughts/information.
Thanks. I only had time because my travel plans are delayed today.
Regards,
Dave
>
>>
>> On Jul 14, 2011, at 11:43 AM, Kay Schenk wrote:
>>
>>>
>>>
>>> On 07/13/2011 10:17 PM, Arthur Buijs wrote:
>>>> On 07/14/2011 01:25 AM, Kay Schenk wrote:
>>>>> On 07/08/2011 01:39 PM, Dave Fisher wrote:
>>>>>>
>>>>>> (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.
>>>>>
>>>>> OK, I, personally am still not thrilled about this approach. I
>>>>> think before deciding anything, maybe someone can give us a
>>>>> count of actual "content developers/admins/software developers"
>>>>> on the existing kenai site -- this would be folks with direct
>>>>> "update/committer" rights in the existing environment to see if
>>>>> we can get a breakdown of what there is now at the
>>>>> openoffice.org and some idea of how it's being maintained.
>>>>>
>>>>> I'll be happy to contact the kenai admins and see what I can
>>>>> find out.
>>>>>
>>>>> If there was some way to use an alternate "something" to
>>>>> maintain the "user facing" site, this would be MUCH better.
>>>>> Right now, I'm looking at the "es" project on openoffice.org.
>>>>> There are 13 (out of 347 "es" members) users with development
>>>>> access to this (web) site. These folks have basically been
>>>>> working in this and only this realm. It would be optimal to
>>>>> have some facility where these same folks, should they choose
>>>>> to join say via an Apache wiki account or other mechanism,
>>>>> would be given the SAME access as they have on the new
>>>>> production environment without a lot of complication.
>>>>
>>>> Please explain what you mean by new production environment in the
>>>> last sentence and how much more complicated it would be.
>>>
>>> This applies to the OpenOffice.org website, nothing more.
>>>
>>> Currently, the roles of "content developer"/"software developer"
>>> have direct (was cvs, now svn access) to the area for their
>>> designated sub-project. Not being familiar with kenai, I don't know
>>> details of how this is controlled but I can certainly find out.
>>>
>>> In the "new production environment", i.e. wherever the New
>>> OpenoOffic.org "user facing web site" will exist -- initially there
>>> was a suggestion to put this as oru current incubator site --
>>>
>>> http://incubator.apache.org/openofficeorg/
>>>
>>> if I'm not mistaken.
>>>
>>> That new area requires an Apache committer status for direct
>>> access.
>>>
>>> Dave's process regarding regarding a local test area for
>>> contributors on their own box, making changes and then submitting
>>> them for actual incorporation (if I'm understanding this correctly)
>>> is WAY more complicated than the existing contributors are used to
>>> dealing with, or would want to IMO. My point is the current
>>> "content developer" community is apparently regarded as trustworthy
>>> in their particular realms.
>>>
>>> Could the "user facing" web area be built using something like
>>> Apache Cocoon (which frankly I know nothing about) or somehow
>>> set-up sub-developer regions on the existing project so folks could
>>> get commit rights but only on certain areas and use the GUI tool,
>>> which would be optimal.
>>>>
>>>
>>> --
>>> ------------------------------------------------------------------------
>>>
>>>
> MzK
>>>
>>> "An old horse for a long hard road, a young pony for a quick
>>> ride". -- Unknown
>>
>
> --
> ------------------------------------------------------------------------
> MzK
>
> "An old horse for a long hard road, a young pony for a quick ride".
> -- Unknown
Re: Apache CMS Workflow and a Key Question
Posted by Kay Schenk <ka...@gmail.com>.
On 07/14/2011 12:59 PM, Dave Fisher wrote:
> I'm top posting - sorry about that. Let's summarized some facts.
>
> - The Apache Way requires a certain process. Commit then Review OR
> Review the Commit. This is essential project governance.
>
> - The approach I outlined is admittedly like what a code developer
> would do. It is command line and text oriented.
>
> - The openoffice.org project at Sun/Oracle has more sub-projects than
> the Apache Software Foundation has projects.
yeah...well... :/
>
> -There was a model for this in Apache - the Apache Jakarta project -
> and the trend here which looks almost done is to make subprojects
> into TLP (Apache POI was one) or retire them. Governance became
> difficult in Jakarta.
sorry...what's "TLP"
>
> - To do as you suggest and give certain developers limited access to
> parts of the website is a good one, but the governance of that would
> need to match the Apache Way.
>
> I think that there are four to-dos.
>
> (1) Get the existing svn website repository into the project's svn. I
> think we should just export it all and then add to the project. The
> move from cvs to svn in kenai has apparently lost all prior history.
> Do we care? If exports are fine then we can proceed.
>
> (2) Figure out how the current is converted and processed into pages
> in the project site. The method I described should be sufficient.
I'll look at your post again. I know a little bit about current
processing, but really, since the move to kenai, not much.
>
> (3) Determine how to put a front-end on this. If the Apache CMS
> bookmarklet is close enough to the current workflow perhaps we can
> figure out how make it work for non-commmitters. To make it submit
> patches to JIRA/bugzilla.
Well I spent this am looking at the CMS info that's out there, and
without actual access right now, I really couldn't determine much about
capabilities.
>
> (4) Discuss what a sub-project model for Apache OpenOffice.org would
> be like, but very slowly. We definitely would need to have a high bar
> and we'll need to get used to working with each other. There will
> certainly need to be a sufficient number of PPMC members that can
> govern a sub-project.
I understand
For the foreign language projects this may
> require three people on the PPMC fluent enough to know that the ASF
> is not publishing improper content and willing to oversee that
> content.
hmmm...OK. Personally, I don't have any idea how difficult this would be.
>
> Regards, Dave
Thanks for the additional thoughts/information.
>
> On Jul 14, 2011, at 11:43 AM, Kay Schenk wrote:
>
>>
>>
>> On 07/13/2011 10:17 PM, Arthur Buijs wrote:
>>> On 07/14/2011 01:25 AM, Kay Schenk wrote:
>>>> On 07/08/2011 01:39 PM, Dave Fisher wrote:
>>>>>
>>>>> (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.
>>>>
>>>> OK, I, personally am still not thrilled about this approach. I
>>>> think before deciding anything, maybe someone can give us a
>>>> count of actual "content developers/admins/software developers"
>>>> on the existing kenai site -- this would be folks with direct
>>>> "update/committer" rights in the existing environment to see if
>>>> we can get a breakdown of what there is now at the
>>>> openoffice.org and some idea of how it's being maintained.
>>>>
>>>> I'll be happy to contact the kenai admins and see what I can
>>>> find out.
>>>>
>>>> If there was some way to use an alternate "something" to
>>>> maintain the "user facing" site, this would be MUCH better.
>>>> Right now, I'm looking at the "es" project on openoffice.org.
>>>> There are 13 (out of 347 "es" members) users with development
>>>> access to this (web) site. These folks have basically been
>>>> working in this and only this realm. It would be optimal to
>>>> have some facility where these same folks, should they choose
>>>> to join say via an Apache wiki account or other mechanism,
>>>> would be given the SAME access as they have on the new
>>>> production environment without a lot of complication.
>>>
>>> Please explain what you mean by new production environment in the
>>> last sentence and how much more complicated it would be.
>>
>> This applies to the OpenOffice.org website, nothing more.
>>
>> Currently, the roles of "content developer"/"software developer"
>> have direct (was cvs, now svn access) to the area for their
>> designated sub-project. Not being familiar with kenai, I don't know
>> details of how this is controlled but I can certainly find out.
>>
>> In the "new production environment", i.e. wherever the New
>> OpenoOffic.org "user facing web site" will exist -- initially there
>> was a suggestion to put this as oru current incubator site --
>>
>> http://incubator.apache.org/openofficeorg/
>>
>> if I'm not mistaken.
>>
>> That new area requires an Apache committer status for direct
>> access.
>>
>> Dave's process regarding regarding a local test area for
>> contributors on their own box, making changes and then submitting
>> them for actual incorporation (if I'm understanding this correctly)
>> is WAY more complicated than the existing contributors are used to
>> dealing with, or would want to IMO. My point is the current
>> "content developer" community is apparently regarded as trustworthy
>> in their particular realms.
>>
>> Could the "user facing" web area be built using something like
>> Apache Cocoon (which frankly I know nothing about) or somehow
>> set-up sub-developer regions on the existing project so folks could
>> get commit rights but only on certain areas and use the GUI tool,
>> which would be optimal.
>>>
>>
>> --
>> ------------------------------------------------------------------------
>>
>>
MzK
>>
>> "An old horse for a long hard road, a young pony for a quick
>> ride". -- Unknown
>
--
------------------------------------------------------------------------
MzK
"An old horse for a long hard road, a young pony for a quick ride".
-- Unknown
Re: Apache CMS Workflow and a Key Question
Posted by Dave Fisher <da...@comcast.net>.
I'm top posting - sorry about that. Let's summarized some facts.
- The Apache Way requires a certain process. Commit then Review OR Review the Commit. This is essential project governance.
- The approach I outlined is admittedly like what a code developer would do. It is command line and text oriented.
- The openoffice.org project at Sun/Oracle has more sub-projects than the Apache Software Foundation has projects.
-There was a model for this in Apache - the Apache Jakarta project - and the trend here which looks almost done is to make subprojects into TLP (Apache POI was one) or retire them. Governance became difficult in Jakarta.
- To do as you suggest and give certain developers limited access to parts of the website is a good one, but the governance of that would need to match the Apache Way.
I think that there are four to-dos.
(1) Get the existing svn website repository into the project's svn. I think we should just export it all and then add to the project. The move from cvs to svn in kenai has apparently lost all prior history. Do we care? If exports are fine then we can proceed.
(2) Figure out how the current is converted and processed into pages in the project site. The method I described should be sufficient.
(3) Determine how to put a front-end on this. If the Apache CMS bookmarklet is close enough to the current workflow perhaps we can figure out how make it work for non-commmitters. To make it submit patches to JIRA/bugzilla.
(4) Discuss what a sub-project model for Apache OpenOffice.org would be like, but very slowly. We definitely would need to have a high bar and we'll need to get used to working with each other. There will certainly need to be a sufficient number of PPMC members that can govern a sub-project. For the foreign language projects this may require three people on the PPMC fluent enough to know that the ASF is not publishing improper content and willing to oversee that content.
Regards,
Dave
On Jul 14, 2011, at 11:43 AM, Kay Schenk wrote:
>
>
> On 07/13/2011 10:17 PM, Arthur Buijs wrote:
>> On 07/14/2011 01:25 AM, Kay Schenk wrote:
>>> On 07/08/2011 01:39 PM, Dave Fisher wrote:
>>>>
>>>> (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.
>>>
>>> OK, I, personally am still not thrilled about this approach. I think
>>> before deciding anything, maybe someone can give us a count of actual
>>> "content developers/admins/software developers" on the existing kenai
>>> site -- this would be folks with direct "update/committer" rights in the
>>> existing environment to see if we can get a breakdown of what there is
>>> now at the openoffice.org and some idea of how it's being maintained.
>>>
>>> I'll be happy to contact the kenai admins and see what I can find out.
>>>
>>> If there was some way to use an alternate "something" to maintain the
>>> "user facing" site, this would be MUCH better. Right now, I'm looking at
>>> the "es" project on openoffice.org. There are 13 (out of 347 "es"
>>> members) users with development access to this (web) site. These folks
>>> have basically been working in this and only this realm. It would be
>>> optimal to have some facility where these same folks, should they choose
>>> to join say via an Apache wiki account or other mechanism, would be
>>> given the SAME access as they have on the new production environment
>>> without a lot of complication.
>>
>> Please explain what you mean by new production environment in the last
>> sentence and how much more complicated it would be.
>
> This applies to the OpenOffice.org website, nothing more.
>
> Currently, the roles of "content developer"/"software developer" have direct (was cvs, now svn access) to the area for their designated sub-project. Not being familiar with kenai, I don't know details of how this is controlled but I can certainly find out.
>
> In the "new production environment", i.e. wherever the New OpenoOffic.org "user facing web site" will exist -- initially there was a suggestion to put this as oru current incubator site --
>
> http://incubator.apache.org/openofficeorg/
>
> if I'm not mistaken.
>
> That new area requires an Apache committer status for direct access.
>
> Dave's process regarding regarding a local test area for contributors on their own box, making changes and then submitting them for actual incorporation (if I'm understanding this correctly) is WAY more complicated than the existing contributors are used to dealing with, or would want to IMO. My point is the current "content developer" community is apparently regarded as trustworthy in their particular realms.
>
> Could the "user facing" web area be built using something like Apache Cocoon (which frankly I know nothing about) or somehow set-up sub-developer regions on the existing project so folks could get commit rights but only on certain areas and use the GUI tool, which would be optimal.
>>
>
> --
> ------------------------------------------------------------------------
> MzK
>
> "An old horse for a long hard road, a young pony for a quick ride".
> -- Unknown
Re: Apache CMS Workflow and a Key Question
Posted by Kay Schenk <ka...@gmail.com>.
On 07/13/2011 10:17 PM, Arthur Buijs wrote:
> On 07/14/2011 01:25 AM, Kay Schenk wrote:
>> On 07/08/2011 01:39 PM, Dave Fisher wrote:
>>>
>>> (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.
>>
>> OK, I, personally am still not thrilled about this approach. I think
>> before deciding anything, maybe someone can give us a count of actual
>> "content developers/admins/software developers" on the existing kenai
>> site -- this would be folks with direct "update/committer" rights in the
>> existing environment to see if we can get a breakdown of what there is
>> now at the openoffice.org and some idea of how it's being maintained.
>>
>> I'll be happy to contact the kenai admins and see what I can find out.
>>
>> If there was some way to use an alternate "something" to maintain the
>> "user facing" site, this would be MUCH better. Right now, I'm looking at
>> the "es" project on openoffice.org. There are 13 (out of 347 "es"
>> members) users with development access to this (web) site. These folks
>> have basically been working in this and only this realm. It would be
>> optimal to have some facility where these same folks, should they choose
>> to join say via an Apache wiki account or other mechanism, would be
>> given the SAME access as they have on the new production environment
>> without a lot of complication.
>
> Please explain what you mean by new production environment in the last
> sentence and how much more complicated it would be.
This applies to the OpenOffice.org website, nothing more.
Currently, the roles of "content developer"/"software developer" have
direct (was cvs, now svn access) to the area for their designated
sub-project. Not being familiar with kenai, I don't know details of how
this is controlled but I can certainly find out.
In the "new production environment", i.e. wherever the New
OpenoOffic.org "user facing web site" will exist -- initially there was
a suggestion to put this as oru current incubator site --
http://incubator.apache.org/openofficeorg/
if I'm not mistaken.
That new area requires an Apache committer status for direct access.
Dave's process regarding regarding a local test area for contributors on
their own box, making changes and then submitting them for actual
incorporation (if I'm understanding this correctly) is WAY more
complicated than the existing contributors are used to dealing with, or
would want to IMO. My point is the current "content developer" community
is apparently regarded as trustworthy in their particular realms.
Could the "user facing" web area be built using something like Apache
Cocoon (which frankly I know nothing about) or somehow set-up
sub-developer regions on the existing project so folks could get commit
rights but only on certain areas and use the GUI tool, which would be
optimal.
>
--
------------------------------------------------------------------------
MzK
"An old horse for a long hard road, a young pony for a quick ride".
-- Unknown
Re: Apache CMS Workflow and a Key Question
Posted by Arthur Buijs <ar...@artietee.nl>.
On 07/14/2011 01:25 AM, Kay Schenk wrote:
> On 07/08/2011 01:39 PM, Dave Fisher wrote:
>>
>> (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.
>
> OK, I, personally am still not thrilled about this approach. I think
> before deciding anything, maybe someone can give us a count of actual
> "content developers/admins/software developers" on the existing kenai
> site -- this would be folks with direct "update/committer" rights in the
> existing environment to see if we can get a breakdown of what there is
> now at the openoffice.org and some idea of how it's being maintained.
>
> I'll be happy to contact the kenai admins and see what I can find out.
>
> If there was some way to use an alternate "something" to maintain the
> "user facing" site, this would be MUCH better. Right now, I'm looking at
> the "es" project on openoffice.org. There are 13 (out of 347 "es"
> members) users with development access to this (web) site. These folks
> have basically been working in this and only this realm. It would be
> optimal to have some facility where these same folks, should they choose
> to join say via an Apache wiki account or other mechanism, would be
> given the SAME access as they have on the new production environment
> without a lot of complication.
Please explain what you mean by new production environment in the last
sentence and how much more complicated it would be.
--
Arthur
Re: Apache CMS Workflow and a Key Question
Posted by Kay Schenk <ka...@gmail.com>.
Hi Dave--
see below
On 07/08/2011 01: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.
AMEN to this!
>
> (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.
OK, I, personally am still not thrilled about this approach. I think
before deciding anything, maybe someone can give us a count of actual
"content developers/admins/software developers" on the existing kenai
site -- this would be folks with direct "update/committer" rights in the
existing environment to see if we can get a breakdown of what there is
now at the openoffice.org and some idea of how it's being maintained.
I'll be happy to contact the kenai admins and see what I can find out.
If there was some way to use an alternate "something" to maintain the
"user facing" site, this would be MUCH better. Right now, I'm looking at
the "es" project on openoffice.org. There are 13 (out of 347 "es"
members) users with development access to this (web) site. These folks
have basically been working in this and only this realm. It would be
optimal to have some facility where these same folks, should they choose
to join say via an Apache wiki account or other mechanism, would be
given the SAME access as they have on the new production environment
without a lot of complication.
I'll look around and respond back to this thread and/or update what I've
already got on the wiki.
>
> 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
>
> Looking for the answer and also comments on this workflow.
>
> Best Regards, Dave
>
>
--
------------------------------------------------------------------------
MzK
"An old horse for a long hard road, a young pony for a quick ride".
-- Unknown