openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Apache CMS Workflow and a Key Question
Date Thu, 14 Jul 2011 19:59:02 GMT
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.

(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 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.


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.
> -- 
> ------------------------------------------------------------------------
> MzK
> "An old horse for a long hard road, a young pony for a quick ride".
>                                  -- Unknown

View raw message