incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject [DISCUSS] RE: SVN and bringing the total end-to-end OOo project under Configuration Management
Date Mon, 29 Aug 2011 21:09:46 GMT
I've been mulling this over and I am wondering about another way to look at the problem, building
on Eike's suggestion too.

This is not a proposal.  It is too high-level and not concrete enough with a viable roadmap.
 We need to see if we can find a consensus in principle and then see what kind of roadmap
would have http://openoffice.org continue in operation.  The goal is as  little disruption
as necessary to achieve rehosting and sustained operation on behalf of the extended community
and also create an effective firewall between the Apache project and non-Apache community
efforts such as the NLC activities.

 - Dennis

BASIC DIRECTION

I think the community material should not be underneath any of the existing svn.apache.org/repos/asf/incubator/ooo
subtrees (not site, not trunk, etc.).

My suggestion is that we use one or more new subtrees.  An easy way would be to have a single
subtree ooo/community with site, wiki, and forums under it.  Or they could be higher-level.

I also think we should consider placing one or more of those on a private SVN tree.  The private
repo would only visible to committers at this level (although it probably means that commit
messages go to ooo-private rather than ooo-commits).  WE ALREADY HAVE A PRIVATE SVN repo that
could be expanded for this.  [I'm not sure this makes sense for backups but there may be other
artifacts that would belong under SVN for the forums and wiki.]

CONSIDERATIONS

The reason for private SVN is to avoid public disclosure of community openoffice.org material
via anything other than the web site, the forums, and the wiki themselves.  It defers having
to deal with current content that is not sanitary with regard to Apache licensing, while continuing
to have that material available to the extended community under the conditions of its original
contribution.  It also assigns custodial responsibility to authorized project committers,
resolving a PPMC duty to the ASF.

Note that this means we should pursue the proposal of Kay Schenk (and, I believe, Jean Hollis
Weber earlier) to *then* migrate the community web content to the community wiki.  One important
benefit is removal of the need for Apache committers to maintain community material.  It is
difficult for the community to submit issues and patches against the private bits, so we want
to make those bits as few as possible.  This is also a way to retain the NLC sites.  If there
is any special custodial relationship needed there, we can work that out without complicating
the Apache development project and sites on the apache.org domain.  In particular, NLC material
and public Apache project materials would never be comingled.

Finally, private or not, the separate tree for the web parts is now amenable for serving up
as a different web site under the openoffice.org domain.  Having the infrastructure and the
repo be separated (better: private) avoids confusion with Apache-licensed content and project
releases as well.  

When the migration is completed, I suspect that the OOOUSER Wiki could be merged over to the
OpenOffice.org wiki (or not, since it seems to provide an important development-side focus).
 http://incubator.apache.org/openofficeorg/ and the eventual http://openofficeorg.apache.org
sites (though I prefer http://ooo.apache.org) would maintain the Apache project development
face and http://openoffice.org would provide the community face, with redirection to developer-focused
apache.org locations (such as for issue tracking, etc.).  



-----Original Message-----
From: Dave Fisher [mailto:dave2wave@comcast.net] 
Sent: Monday, August 29, 2011 09:02
To: ooo-dev@incubator.apache.org
Subject: Re: SVN and bringing the total end-to-end OOo project under Configuration Management


On Aug 29, 2011, at 8:30 AM, Michael Stahl wrote:

> On 29.08.2011 16:40, Terry Ellison wrote:
>> Thanks for comments. Rob.  I was hoping to get your and others thoughts 
>> on this TLD structure issue:  Where do we plug the wiki, the forums, the 
>> other website services into our svn hierarchy (where XXXX=the relevant 
>> service):
>>    * incubator/ooo/site/trunk/XXXX
>> or
>>    * incubator/ooo/site/XXXX/trunk
>> or where?
>> 
>> There's no clear slot in our current TLD structure.  I've put my 
>> responses on the rest below.
> 
> i don't understand at all why "site" contains "trunk", does anybody
> really want to branch it?

In preparation for a release!

Regards,
Dave

> 
>> On 29/08/11 14:59, Rob Weir wrote:
> 
>>> 2) Our customizations occur in a branch
>> Tried this before on projects.  It really doesn't work.  There are 
>> ~2,500 files of which we update about 20-30 with a single patch file.  
>> If we do it the way you suggest, we would have a huge bulk of revisions 
>> every phpBB release.  It's a lot easier to keep the build script and the 
>> patch file under CM and then we only have two files to update every 
>> release.
> 
> perhaps a patch tracking tool like "quilt" would be appropriate?
> 
> http://savannah.nongnu.org/projects/quilt/
> 
> it allows to have not just a single big patch but multiple patches, each
> one containing one "logical change".
> 
> then the patches and quilt metadata can be put into SVN.
> 
> (i have been using a versioned HG Mercurial Queue against the OOo repo,
> which is quite similar in approach...)
> 
> regards,
> michael
> 


Mime
View raw message