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 openoffice.org 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
capabilities.
(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.
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
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.
--
------------------------------------------------------------------------
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
