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 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"
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 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. 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 others... > >> >> Regards, Dave > > Thanks for the additional thoughts/information. Thanks. I only had time because my travel plans are delayed today. 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 >>>>> 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
