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 22:15:56 GMT

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

>> Regards, Dave
> Thanks for the additional thoughts/information.

Thanks. I only had time because my travel plans are delayed today.


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

View raw message