openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: Apache CMS Workflow and a Key Question
Date Thu, 14 Jul 2011 21:32:13 GMT

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

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

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


"An old horse for a long hard road, a young pony for a quick ride".
                                   -- Unknown

View raw message