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 RE: [DISCUSS] RE: SVN and bringing the total end-to-end OOo project under Configuration Management
Date Tue, 30 Aug 2011 00:39:03 GMT
I agree that some aspects should be integrated into the Apache project and that they should
be housed at apache.org.  

Some of these are easy.  Bug reporting, access to project source code (not previous releases
obviously), some other things, submission of patches and subscription to ooo-dev, obviously.
 One of the easiest ways to find these is to look at a native-language subsite and see which
pages link to English-language pages. All the cases I have found are ones that could now link
to pages on apache.org once the corresponding resource is available or migrated.  The German-language
pages at 
<http://incubator.apache.org/openofficeorg/de/> that were uploaded are instructive.
 Would you really expect to keep all of that there?  And if not, what happens to the parts
that are not kept?  I would think we want this loosely-coupled and not drawn into apache.org.
 

Some other things, such as wikis and forums can still be operated via the openoffice.org domain,
although we need to figure out some things about registrations and identification.  The migrations
that will be coming up in a few weeks can serve that, although there will be disruption. 
But I think we can do the least necessary to be back in operation.  Preservation of existing
registrations would be nice.  (These are not tied to <name>@openoffice.org, at least
the wiki isn't; I suspect the forums aren't either.)

There are some web and wiki pages that are in a gray area and we can decide what to do about
those (e.g., it is a wiki page that explains how to download the latest source code and the
big DEV300.hg package.  That might get caught in the sweep of English-language pages linked
from the NLC sections, but if not it needs to be captured somehow.  I also don't know how
long one would leave hg.services.openoffice.org up, though one might preserve it until we
have a podling release.  It doesn't provide ALv2-licensed source of course, so there is a
window to deal with there.

I'm not going to dig further other than saying we might end up in something like the same
place.  I want to leave as much possible out in the hands of the community as possible and
bring the least that makes sense to the podling.  And I would do all of it, no matter where
we eventually end up, by first preserving as much operation of the openoffice.org domain and
site as possible and then migrating in manageable chunks, both toward the Apache development
side and toward functioning of the rest, however under new management.

 - Dennis

-----Original Message-----
From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
Sent: Monday, August 29, 2011 16:55
To: ooo-dev@incubator.apache.org
Subject: Re: [DISCUSS] RE: SVN and bringing the total end-to-end OOo project under Configuration
Management

On Mon, Aug 29, 2011 at 5:57 PM, Dennis E. Hamilton
<dennis.hamilton@acm.org> wrote:
> 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'm not talking about converting existing contributions to ALv2.
Obviously we cannot do that.  I'm talking about future contributions.

We'll have a community wiki, yes of course.  We have one now.  We've
had it since we first started.  We'll have a user list, certainly.
But core project functions, such as development,  translation,
documentation, user support, etc., should be integrated into the
project, the Apache project.  These are core project responsibilities.
 Every other Apache project does this.  I have not heard a cogent
argument why this should not be true of us.

The thing to let sink in is that this is an Apache project, with an
Apache project community, with an Apache license.   We only delay the
inevitable if we continue talking like there will be an independent
entity, using Apache servers and trademarks, but electing licenses
other than ALv2 and using a decision making process and meritocracy
independent of the Apache project and the Apache Way.

We need to start talking about how we integrate and welcome the
community into the project, not just integrate websites.  We need to
start explaining the benefits of signing the iCLA and the benefits of
the Apache Way.  If we fail to do this, then we fail as a PPMC, and
ultimately as a project.

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

I'm arguing the logic of my position.  You were doing the same, but
now you've veered off to arguing mass opinion.

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

That is not what I was proposing.

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

OOo also independently raised funds, organized events, gave permission
for trademark use, registered domain names, applied for Google Summer
of Code, collected money from conference sponsors, hosted commercial
extensions on their websites, put Oracle product advertisements in
their install programs, etc.  We're not going to continue all of these
things.  We cannot continue all of these things.  We're an Apache
project.  We need to start thinking like one.

There is absolutely no obligation to continue something OOo did merely
because OOo did it.

Apache is not the Internet Archive. We have no duty to curate and
preserve things just because they existed at OOo.  As you know,
LibreOffice did not just copy everything as-is from OOo.  Why should
we not have similar freedom of action?

Apache is not SourceForge.  Unlike OOo it does not work for us to
create nearly 200 independent "projects" beneath our podling that
maintain their own websites, their own wikis, their own code
repositories and their own releases.  If there is a project that we
neglect to migrate, because we don't appreciate its value, then there
is nothing that prevents volunteers who worked on that project from
applying to become their own incubation project, or from setting up
their own independent project.

The default action is that nothing happens unless sufficient
volunteers step forward to migrate a service and then integrate it
into the Apache project.  This means integrating it not only at the
Infrastructure level, but also as a component of an Apache project,
under the Apache Way and with the reality that a project exists as an
entity within a larger non-profit corporation, etc.  That is the
default.


> The only alternative I can imagine is if some other party steps up to operate openoffice.org
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.

>

There are certainly some who are hoping for this.  But the hard part
of having a successful alternative service is not the trademark or the
OpenOffice.org domain.  The hard part is providing the technical
infrastructure, expertise and volunteers.

Look at http://www.oooforum.org  They get tons of traffic though they
are independent of the OOo and get no advantage from the URL or any
official relationship to the project.

Look also at LibreOffice for a similar case.  They've made significant
progress, without any use of OOo trademarks, logos or domain names.

Look also at ODFAuthors for another example.

If someone wanted to host an OOo wiki, or community website, or
documentation site, or extensions site, or whatever, they can JFDI.
Lack of the openoffice.org domain name did not prevented the above
projects from setting up successful websites.  Why should it prevent
someone today?

In any case, if someone really thinks they need to use the trademark,
logo or domain name then there is always the ability to submit a
proposal to the PPMC.  They could also make their own incubation
proposal to Apache.  Since Apache, not this project, owns the
trademark, logo and domain name, Apache could then mediate access to
these assets among the Apache projects that request them.  That is
also an option we might have at graduation, to move in to multiple new
projects.

> 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 [mailto:robweir@apache.org]
> Sent: Monday, August 29, 2011 14:33
> To: ooo-dev@incubator.apache.org
> Subject: Re: [DISCUSS] RE: SVN and bringing the total end-to-end OOo project under Configuration
Management
>
> On Mon, Aug 29, 2011 at 5:09 PM, Dennis E. Hamilton
> <dennis.hamilton@acm.org> 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 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.
>>
>
> "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
>>
>> 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.]
>>
>
> 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.
>
>> 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.
>>
>
> 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 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