incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Apache CMS Workflow and a Key Question
Date Thu, 14 Jul 2011 22:19:42 GMT

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.


Mime
View raw message