incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: [DISCUSS] RE: SVN and bringing the total end-to-end OOo project under Configuration Management
Date Mon, 29 Aug 2011 21:57:52 GMT
Rob, I completely disagree with embracing everything under ALv2 and exclusive Apache Way custodianship.
 I don't consider that a goal.  I don't see how that serves the extended community at all.

I accept that is not your position.

As far as I know, the position you express is not a commonly held view, though whatever view
is commonly held is not all that clear.

Furthermore, I don't believe we have the right to appropriate all things at
that are not explicit in the Oracle SGA.  It seems that is not part of the Apache Way.

So we need to be careful and respectful of what there is and what has gone before in taking
custodianship of the domain name(s).  I think that means endeavoring to perpetuate those sites
in a manner that changes only what we have to change to bridge to the Apache project.  What
is not essential to the Apache project needs to be sustained in its operation for now and
we can work out further arrangements as we go.

The only alternative I can imagine is if some other party steps up to operate
and Apache provides them the use of the domain name under some suitable arrangement.  That
would also be a decent Plan B if we fail to graduate from incubation.

I agree that using a private SVN for the non-developer community stuff is not ideal and would
not be permissible if it was all Apache.  I'm not wedded to that.  What I found valuable is
that it doesn't create any undesirable contamination of what will be clean Apache project
SVN with material that is not so pure.  

Another way to look at it is a web-site/-service version of an Apache Extra, visible to the
world on a non-Apache domain name.  

 - Dennis


-----Original Message-----
From: Rob Weir [] 
Sent: Monday, August 29, 2011 14:33
Subject: Re: [DISCUSS] RE: SVN and bringing the total end-to-end OOo project under Configuration

On Mon, Aug 29, 2011 at 5:09 PM, Dennis E. Hamilton
<> wrote:
> 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 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.

"As little disruption as necessary"  and "sustained operation" are
opposing desires.  I think we should seeking to optimize the project
as an Apache project, not merely transport everything as-is.

Another point is that, regardless of the legacy of the project, Apache
2.0 license is not antithetical to community contributions.  We should
be requiring it everywhere, for all contributions.  If we wanted to be
true to the past, then we'd require copyright assignment to Oracle,
right?  Obviously, moving from that to ALv2 is a big step forward.  So
the goal should be to integrate the community into the Apache project,
not try to create firewalls to prevent effective collaboration.  A
common license is the best way to encourage effective collaboration.

>  - Dennis
> I think the community material should not be underneath any of the existing
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.]

This goes against transparency.  The only things that should be in our
private SVN are confidential things, such as lists of committer email
addresses, etc.

> The reason for private SVN is to avoid public disclosure of community
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.

The only firewall we need are diligent committers.  Remember, there
are many things out there in the wild, wild internet that we must not
cavalierly check into the SVN source tree.   We rely on committers to
be careful everywhere and always.

And we don't want the community wiki,etc., to always be verboten to
project use.  We want, over time, for there to be an increasing amount
of ALv2 material that could be used in other contexts.  I think we do
a disservice if we merely set up a situation where the community can
continue to contribute material that is in a contaminated pool of
variously and ambiguously licensed content.  We owe it to the
community to bring some clarity to this problem.

> 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 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 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 wiki (or not, since it seems to provide an important development-side
focus). and the eventual
sites (though I prefer would maintain the Apache project development
face and would provide the community face, with redirection to developer-focused locations (such as for issue tracking, etc.).
> -----Original Message-----
> From: Dave Fisher []
> Sent: Monday, August 29, 2011 09:02
> To:
> 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?
>> 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

View raw message