openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
Subject Re: Apache CMS Workflow and a Key Question
Date Thu, 14 Jul 2011 22:09:49 GMT
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 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 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 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 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 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 "user facing
web site" will exist -- initially there was a suggestion to put this  as oru current incubator
site --
>> 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.

View raw message