date:20110802

On Tue, 2011-08-02 at 22:18 -0400, Rob Weir wrote:
> On Tue, Aug 2, 2011 at 9:17 PM, Jean Hollis Weber  wrote:
> >
> > The user guides are dual-licensed under CC-BY and GPL, and the past
> > contributors have obviously agreed to those licenses. They have not
> > agreed to the Apache license, and most of them cannot be found to ask if
> > they agree. We can't just relicense the books under the Apache license.
> >
> > What you have said tells me that those books cannot be attachments on a
> > Apache-OOo wiki page. Is that correct? If so, then we can host them
> > elsewhere and link to them from the wiki.
> >
> 
> You asked previously about CC-BY.  I said that was on the list of
> compatible licenses.  You never asked about GPL nor did I make a
> comment on GPL.

Your note about CC-BY reached me after I sent this note to the list. At
the time I wrote the above, I did not have that information. Sorry to
add to the noise confusion!

> 
> In any case, do you really mean GPL? Or do you mean GNU Free
> Documentation License (GFDL)?

Yes, I meant GPL. Here is the copyright statement from a typical user
guide chapter:

"This document is Copyright © 2005–2011 by its contributors as listed
below. You may distribute it and/or modify it under the terms of either
the GNU General Public License (http://www.gnu.org/licenses/gpl.html),
version 3 or later, or the Creative Commons Attribution License
(http://creativecommons.org/licenses/by/3.0/), version 3.0 or later."

Derivative works (which would include any Apache-OOo materials based on
these books) could therefore be licensed under either GPL or CC-BY, so
the GPL license statement could be dropped if that's an issue.

> As I mentioned before, the list of compatible licenses are listed here:
> 
> http://www.apache.org/legal/resolved.html#category-a
> 
> CC-BY is fine. Specifically version 2.5:
> http://creativecommons.org/licenses/by/2.5/
> 
> Note that CC-BY 3.0 is not listed.  But this may just be because no
> project as requested it to be reviewed and approved.
> 
> What version are you licensing under?

CC-BY 3.0 or later.

--Jean

I can't unsubscribe.

2011-08-02 Thread dba03

Hi,
I send a short reply to this address: 
ooo-dev-uc.1312335345.hjgokelidmnkpjaodegk-dba03=163@incubator.apache.org  
to confirm unsubscribe from ooo-dev@incubator.apache.org. But it failed:
SMTP error, DOT: 552 spam score (5.4) exceeded threshold 
(DATE_IN_PAST_96_XX,HTML_MESSAGE,SPF_PASS,TRACKER_ID ).(SMTP error, DOT: 552 
spam score (5.4) exceeded threshold 
(DATE_IN_PAST_96_XX,HTML_MESSAGE,SPF_PASS,TRACKER_ID )).

So I tried another method: send a message to   
 and put the entire address listed above  
into the "Subject:" line.
It failed again:
:  ezmlm-request: fatal: the local part 
of the command string does not match this list (#5.1.1)

Re: User guide licensing (was: Refactoring the brand)

On Tue, Aug 2, 2011 at 9:17 PM, Jean Hollis Weber  wrote:
> On Tue, 2011-08-02 at 20:43 -0400, Rob Weir wrote:
>> On Tue, Aug 2, 2011 at 8:32 PM, Jean Hollis Weber  
>> wrote:
>> > On Tue, 2011-08-02 at 10:52 -0400, Rob Weir wrote:
>> >> On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton
>> >>  wrote:
>> >> > -1
>> >> >
>> >> > I don't understand why there is continued pressing that things not in a 
>> >> > release have to be treated as if it requires the same treatment as the 
>> >> > content of a release.  I thought we had worked a high-level sketch of 
>> >> > the user documentation case with Jean Hollis Weber some time ago on 
>> >> > this list.
>> >> >
>> >>
>> >> That was something else entirely, ODFAuthors.org, a site that is
>> >> external to Apache.  We're not discussing that right now.  What we're
>> >> discussing is the content at wiki.services.openoffice.org, which we
>> >> are planning to be part of the Apache OpenOffice project. Two
>> >> different things.
>> >
>> > *I* was talking about the docs produced by ODFAuthors, in my note quoted
>> > below, and I asked a question that was not answered; the answer was
>> > about the material directly edited on the wiki, not about the material I
>> > asked about.
>> >
>>
>> From licensing perspective it is the same, whether it is content in
>> wikitext or content in attachments to a wiki page.  The thing that
>> would be different would be links to content on external sites.
>>
>> If that is not answering your question, maybe you should restate, with
>> a link to a specific example.
>
> The user guides are dual-licensed under CC-BY and GPL, and the past
> contributors have obviously agreed to those licenses. They have not
> agreed to the Apache license, and most of them cannot be found to ask if
> they agree. We can't just relicense the books under the Apache license.
>
> What you have said tells me that those books cannot be attachments on a
> Apache-OOo wiki page. Is that correct? If so, then we can host them
> elsewhere and link to them from the wiki.
>

You asked previously about CC-BY.  I said that was on the list of
compatible licenses.  You never asked about GPL nor did I make a
comment on GPL.

In any case, do you really mean GPL? Or do you mean GNU Free
Documentation License (GFDL)?

As I mentioned before, the list of compatible licenses are listed here:

http://www.apache.org/legal/resolved.html#category-a

CC-BY is fine. Specifically version 2.5:
http://creativecommons.org/licenses/by/2.5/

Note that CC-BY 3.0 is not listed.  But this may just be because no
project as requested it to be reviewed and approved.

What version are you licensing under?

Nothing is mentioned about GFDL.  It is not in the permitted or forbidden lists.

> Does this also mean that the guides cannot be part of the official
> documentation set? That's okay with me (not sure what other contributors
> think), but it seems less than ideal for the project.
>

See above.  CC-BY 2.5 is acceptable.

> Examples of the existing user guides can be downloaded from this page
> and pages linked to it:
> http://wiki.services.openoffice.org/wiki/Documentation/OOo3_User_Guides/OOo3.3_User_Guide_Chapters
>
> --Jean
>
>> >> >
>> >> > -Original Message-
>> >> > From: Rob Weir [mailto:apa...@robweir.com]
>> >> > Sent: Tuesday, August 02, 2011 05:04
>> >> > To: ooo-dev@incubator.apache.org
>> >> > Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
>> >> > re:OpenOffice.org branding)
>> >> >
>> >> > On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber 
>> >> >  wrote:
>> >> >> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>> >> >>> I'd look at it like this:  The documentation that is needed for our
>> >> >>> users to be successful with our product, from end users, to admins, to
>> >> >>> application developers, that documentation is product documentation.
>> >> >>> If having it deleted or defaced, without us noticing it, would cause
>> >> >>> our users some harm, then it is product documentation.  If the right
>> >> >>> to copy, modify and redistribute the documentation is essentially to
>> >> >>> successful creating and hosting a new port or translation, or even a
>> >> >>> commercial derivative or an open source fork, of the project, then it
>> >> >>> is product documentation.
>> >> >>
>> >> >> Leaving aside for the moment all the other user-doc type items on the
>> >> >> wiki, and looking specifically at the existing current set of user
>> >> >> guides (which are in ODT/PDF format, but made available for download
>> >> >> from the existing OOo wiki), I'm unclear how they will fit into this.
>> >> >> They are not currently under the Apache license, and we would never be
>> >> >> able to track down all the contributors to get them to agree to the
>> >> >> license and/or sign the iCLA. So are we talking only about future
>> >> >> updates to these docs? And if so, do you mean that every future
>> >> >> contributor to these guides during their production must s

Re: User guide licensing (was: Refactoring the brand)

2011-08-02 Thread Pedro Giffuni


Hmm ..
If Oracle owns them we can include them in the grant and update te 
license.


Cheers,

pedro.

On Wed, 03 Aug 2011 11:17:28 +1000, Jean Hollis Weber 
 wrote:

On Tue, 2011-08-02 at 20:43 -0400, Rob Weir wrote:
On Tue, Aug 2, 2011 at 8:32 PM, Jean Hollis Weber 
 wrote:

> On Tue, 2011-08-02 at 10:52 -0400, Rob Weir wrote:
>> On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton
>>  wrote:
>> > -1
>> >
>> > I don't understand why there is continued pressing that things 
not in a release have to be treated as if it requires the same 
treatment as the content of a release.  I thought we had worked a 
high-level sketch of the user documentation case with Jean Hollis 
Weber some time ago on this list.

>> >
>>
>> That was something else entirely, ODFAuthors.org, a site that is
>> external to Apache.  We're not discussing that right now.  What 
we're
>> discussing is the content at wiki.services.openoffice.org, which 
we

>> are planning to be part of the Apache OpenOffice project. Two
>> different things.
>
> *I* was talking about the docs produced by ODFAuthors, in my note 
quoted
> below, and I asked a question that was not answered; the answer 
was
> about the material directly edited on the wiki, not about the 
material I

> asked about.
>

From licensing perspective it is the same, whether it is content in
wikitext or content in attachments to a wiki page.  The thing that
would be different would be links to content on external sites.

If that is not answering your question, maybe you should restate, 
with

a link to a specific example.


The user guides are dual-licensed under CC-BY and GPL, and the past
contributors have obviously agreed to those licenses. They have not
agreed to the Apache license, and most of them cannot be found to ask 
if
they agree. We can't just relicense the books under the Apache 
license.


What you have said tells me that those books cannot be attachments on 
a

Apache-OOo wiki page. Is that correct? If so, then we can host them
elsewhere and link to them from the wiki.

Does this also mean that the guides cannot be part of the official
documentation set? That's okay with me (not sure what other 
contributors

think), but it seems less than ideal for the project.

Examples of the existing user guides can be downloaded from this page
and pages linked to it:

http://wiki.services.openoffice.org/wiki/Documentation/OOo3_User_Guides/OOo3.3_User_Guide_Chapters

--Jean


>> >
>> > -Original Message-
>> > From: Rob Weir [mailto:apa...@robweir.com]
>> > Sent: Tuesday, August 02, 2011 05:04
>> > To: ooo-dev@incubator.apache.org
>> > Subject: Re: Refactoring the brand: Apache ooo + 
OpenOffice.org? (was re:OpenOffice.org branding)

>> >
>> > On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber 
 wrote:

>> >> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>> >>> I'd look at it like this:  The documentation that is needed 
for our
>> >>> users to be successful with our product, from end users, to 
admins, to
>> >>> application developers, that documentation is product 
documentation.
>> >>> If having it deleted or defaced, without us noticing it, 
would cause
>> >>> our users some harm, then it is product documentation.  If 
the right
>> >>> to copy, modify and redistribute the documentation is 
essentially to
>> >>> successful creating and hosting a new port or translation, or 
even a
>> >>> commercial derivative or an open source fork, of the project, 
then it

>> >>> is product documentation.
>> >>
>> >> Leaving aside for the moment all the other user-doc type items 
on the
>> >> wiki, and looking specifically at the existing current set of 
user
>> >> guides (which are in ODT/PDF format, but made available for 
download
>> >> from the existing OOo wiki), I'm unclear how they will fit 
into this.
>> >> They are not currently under the Apache license, and we would 
never be
>> >> able to track down all the contributors to get them to agree 
to the
>> >> license and/or sign the iCLA. So are we talking only about 
future
>> >> updates to these docs? And if so, do you mean that every 
future
>> >> contributor to these guides during their production must sign 
the iCLA?
>> >> Or just that only someone with suitable access rights 
(committer?) can

>> >> put them on the wiki (in ODT/PDF format)? Or something else?
>> >>
>> >
>> > I'd like us to treat documentation like we do code.  Not 
necessarily
>> > the same tools, but the same care for provenance, 
accountability and

>> > quality, namely:
>> >
>> > 1) We welcome "patches" and "contributions" from anyone, but 
these
>> > must be first reviewed and approved by a project committer 
before they
>> > become part of the documentation set.  Any such contributions 
must be

>> > made under Apache 2.0 license.
>> >
>> > 2) Only project committers have direct write access to the
>> > documentation.  This requires that they first sign the iCLA.
>> >
>> > 3) All contributions, whether from the public or from 
committers and

>> > tr

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 9:24 PM, TerryE  wrote:
> On 02/08/11 23:28, Rob Weir wrote:
>>
>> With the wiki, if we really want to allow anyone to have write access
>> to it, then we really need to be committed to fight the weeds, which
>> in the case of wikis would be spam, low quality content, edit wars,
>> etc.  If we can re-establish the community participation level the way
>> it was a year ago, then great.  It would have a chance of success.
>> But right now I see almost no activity on the wiki.  35,000 user
>> accounts, but no users.  If this doesn't change, the weeds will surely
>> win.
>
> [terrye@doc logs]$ ls -hl
>
> total 112635922
>
> -rw-r--r--   1 webservd webservd    2.1G Jan 12  2011 access.20110106.log
>
> -rw-r--r--   1 webservd webservd    2.2G Jan 19  2011 access.20110113.log
>
> -rw-r--r--   1 webservd webservd    2.2G Jan 26  2011 access.20110120.log
>
> -rw-r--r--   1 webservd webservd    2.2G Feb  2  2011 access.20110127.log
>
> -rw-r--r--   1 webservd webservd    2.2G Feb  9 23:59 access.20110203.log
>
> -rw-r--r--   1 webservd webservd    2.1G Feb 16 23:59 access.20110210.log
>
> -rw-r--r--   1 webservd webservd    2.1G Feb 23 23:59 access.20110217.log
>
> -rw-r--r--   1 webservd webservd    2.1G Mar  2 23:59 access.20110224.log
>
> -rw-r--r--   1 webservd webservd    2.1G Mar  9 23:59 access.20110303.log
>
> -rw-r--r--   1 webservd webservd    2.0G Mar 16 23:59 access.20110310.log
>
> -rw-r--r--   1 webservd webservd    2.0G Mar 23 23:59 access.20110317.log
>
> -rw-r--r--   1 webservd webservd    2.0G Mar 30 23:59 access.20110324.log
>
> -rw-r--r--   1 webservd webservd    1.9G Apr  6 23:59 access.20110331.log
>
> -rw-r--r--   1 webservd webservd    1.9G Apr 13 23:59 access.20110407.log
>
> -rw-r--r--   1 webservd webservd    1.8G Apr 20 23:59 access.20110414.log
>
> -rw-r--r--   1 webservd webservd    1.6G Apr 27 23:59 access.20110421.log
>
> -rw-r--r--   1 webservd webservd    1.8G May  4 23:59 access.20110428.log
>
> -rw-r--r--   1 webservd webservd    1.8G May 11 23:59 access.20110505.log
>
> -rw-r--r--   1 webservd webservd    1.7G May 18 23:59 access.20110512.log
>
> -rw-r--r--   1 webservd webservd    1.6G May 25 23:59 access.20110519.log
>
> -rw-r--r--   1 webservd webservd    1.6G Jun  1 23:59 access.20110526.log
>
> -rw-r--r--   1 webservd webservd    1.5G Jun  8 23:59 access.20110602.log
>
> -rw-r--r--   1 webservd webservd    1.5G Jun 15 23:59 access.20110609.log
>
> -rw-r--r--   1 webservd webservd    1.6G Jun 22 23:59 access.20110616.log
>
> -rw-r--r--   1 webservd webservd    1.4G Jun 29 23:59 access.20110623.log
>
> -rw-r--r--   1 webservd webservd    1.3G Jul  6 23:59 access.20110630.log
>
> -rw-r--r--   1 webservd webservd    1.4G Jul 13 23:59 access.20110707.log
>
> -rw-r--r--   1 webservd webservd    1.3G Jul 20 23:59 access.20110714.log
>
> -rw-r--r--   1 webservd webservd    1.4G Jul 27 23:59 access.20110721.log
>
> -rw-r--r--   1 webservd webservd    1.1G Aug  3 03:14 access.20110728.log
>
> We've discussed the update access reasons and issues previously.   As you
> can see from the Apache logs, the read volumes are still pretty high though
> they have fallen off by almost a factor of two since the Apache
> announcement.  Sorry, but I can't give you proper transaction volumes.
>  Clayton had  o:rw access, not me.
>

No need to apologize.  Read volumes are pretty much irrelevant when
discussing a policy for editing.  Or are you suggesting that this is
related to caching policy?  If so, that is a reasonable point.  With
only 5 people editing, with a very low rate of changes, and many
people reading, caching should be very effective, at least on the most
frequently-read pages.

> Terry
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, 2011-08-02 at 15:39 +0100, Terry Ellison wrote:
> Rob,
> 
> I think that you've missed my point.  The guy didn't THREATEN to leave.  
> He HAS left.  I doubt we will get him back.  My strong reaction was 
> because of that entirely avoidable loss of 5+ man-years of project 
> expertise that we will be pressed to recover for the sake on an 
> ill-considered shout-down. 

Terry, you may have private info from Clayton that I don't have, but my
understanding from conversations with him is that he never had any
intention of remaining with the Apache OOo project beyond helping a bit
with the handover process. In fact, I'm fairly sure he said this in a
note to this list some weeks ago, but I haven't the energy to try to
track it down in the archives.

--Jean

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


Rob,



Is there any easy way to get a list of active users for the wiki,
year-to-date for 2011, maybe sorted by number of edits?  That would be
great to know, a list of people we can reach out to and invite to
participate again in the new project and new wiki, if they are not
already here.


Possible? -- Yes.  Can we resource it now? -- No not now, AFAIK.  Sorry.

//Terry

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


On 02/08/11 23:28, Rob Weir wrote:


With the wiki, if we really want to allow anyone to have write access
to it, then we really need to be committed to fight the weeds, which
in the case of wikis would be spam, low quality content, edit wars,
etc.  If we can re-establish the community participation level the way
it was a year ago, then great.  It would have a chance of success.
But right now I see almost no activity on the wiki.  35,000 user
accounts, but no users.  If this doesn't change, the weeds will surely
win.

[terrye@doc logs]$ ls -hl

total 112635922

-rw-r--r--   1 webservd webservd2.1G Jan 12  2011 access.20110106.log

-rw-r--r--   1 webservd webservd2.2G Jan 19  2011 access.20110113.log

-rw-r--r--   1 webservd webservd2.2G Jan 26  2011 access.20110120.log

-rw-r--r--   1 webservd webservd2.2G Feb  2  2011 access.20110127.log

-rw-r--r--   1 webservd webservd2.2G Feb  9 23:59 access.20110203.log

-rw-r--r--   1 webservd webservd2.1G Feb 16 23:59 access.20110210.log

-rw-r--r--   1 webservd webservd2.1G Feb 23 23:59 access.20110217.log

-rw-r--r--   1 webservd webservd2.1G Mar  2 23:59 access.20110224.log

-rw-r--r--   1 webservd webservd2.1G Mar  9 23:59 access.20110303.log

-rw-r--r--   1 webservd webservd2.0G Mar 16 23:59 access.20110310.log

-rw-r--r--   1 webservd webservd2.0G Mar 23 23:59 access.20110317.log

-rw-r--r--   1 webservd webservd2.0G Mar 30 23:59 access.20110324.log

-rw-r--r--   1 webservd webservd1.9G Apr  6 23:59 access.20110331.log

-rw-r--r--   1 webservd webservd1.9G Apr 13 23:59 access.20110407.log

-rw-r--r--   1 webservd webservd1.8G Apr 20 23:59 access.20110414.log

-rw-r--r--   1 webservd webservd1.6G Apr 27 23:59 access.20110421.log

-rw-r--r--   1 webservd webservd1.8G May  4 23:59 access.20110428.log

-rw-r--r--   1 webservd webservd1.8G May 11 23:59 access.20110505.log

-rw-r--r--   1 webservd webservd1.7G May 18 23:59 access.20110512.log

-rw-r--r--   1 webservd webservd1.6G May 25 23:59 access.20110519.log

-rw-r--r--   1 webservd webservd1.6G Jun  1 23:59 access.20110526.log

-rw-r--r--   1 webservd webservd1.5G Jun  8 23:59 access.20110602.log

-rw-r--r--   1 webservd webservd1.5G Jun 15 23:59 access.20110609.log

-rw-r--r--   1 webservd webservd1.6G Jun 22 23:59 access.20110616.log

-rw-r--r--   1 webservd webservd1.4G Jun 29 23:59 access.20110623.log

-rw-r--r--   1 webservd webservd1.3G Jul  6 23:59 access.20110630.log

-rw-r--r--   1 webservd webservd1.4G Jul 13 23:59 access.20110707.log

-rw-r--r--   1 webservd webservd1.3G Jul 20 23:59 access.20110714.log

-rw-r--r--   1 webservd webservd1.4G Jul 27 23:59 access.20110721.log

-rw-r--r--   1 webservd webservd1.1G Aug  3 03:14 access.20110728.log

We've discussed the update access reasons and issues previously.   As 
you can see from the Apache logs, the read volumes are still pretty high 
though they have fallen off by almost a factor of two since the Apache 
announcement.  Sorry, but I can't give you proper transaction volumes.  
Clayton had  o:rw access, not me.


Terry

User guide licensing (was: Refactoring the brand)

On Tue, 2011-08-02 at 20:43 -0400, Rob Weir wrote:
> On Tue, Aug 2, 2011 at 8:32 PM, Jean Hollis Weber  wrote:
> > On Tue, 2011-08-02 at 10:52 -0400, Rob Weir wrote:
> >> On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton
> >>  wrote:
> >> > -1
> >> >
> >> > I don't understand why there is continued pressing that things not in a 
> >> > release have to be treated as if it requires the same treatment as the 
> >> > content of a release.  I thought we had worked a high-level sketch of 
> >> > the user documentation case with Jean Hollis Weber some time ago on this 
> >> > list.
> >> >
> >>
> >> That was something else entirely, ODFAuthors.org, a site that is
> >> external to Apache.  We're not discussing that right now.  What we're
> >> discussing is the content at wiki.services.openoffice.org, which we
> >> are planning to be part of the Apache OpenOffice project. Two
> >> different things.
> >
> > *I* was talking about the docs produced by ODFAuthors, in my note quoted
> > below, and I asked a question that was not answered; the answer was
> > about the material directly edited on the wiki, not about the material I
> > asked about.
> >
> 
> From licensing perspective it is the same, whether it is content in
> wikitext or content in attachments to a wiki page.  The thing that
> would be different would be links to content on external sites.
> 
> If that is not answering your question, maybe you should restate, with
> a link to a specific example.

The user guides are dual-licensed under CC-BY and GPL, and the past
contributors have obviously agreed to those licenses. They have not
agreed to the Apache license, and most of them cannot be found to ask if
they agree. We can't just relicense the books under the Apache license.

What you have said tells me that those books cannot be attachments on a
Apache-OOo wiki page. Is that correct? If so, then we can host them
elsewhere and link to them from the wiki.

Does this also mean that the guides cannot be part of the official
documentation set? That's okay with me (not sure what other contributors
think), but it seems less than ideal for the project.

Examples of the existing user guides can be downloaded from this page
and pages linked to it:
http://wiki.services.openoffice.org/wiki/Documentation/OOo3_User_Guides/OOo3.3_User_Guide_Chapters

--Jean

> >> >
> >> > -Original Message-
> >> > From: Rob Weir [mailto:apa...@robweir.com]
> >> > Sent: Tuesday, August 02, 2011 05:04
> >> > To: ooo-dev@incubator.apache.org
> >> > Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
> >> > re:OpenOffice.org branding)
> >> >
> >> > On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  
> >> > wrote:
> >> >> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
> >> >>> I'd look at it like this:  The documentation that is needed for our
> >> >>> users to be successful with our product, from end users, to admins, to
> >> >>> application developers, that documentation is product documentation.
> >> >>> If having it deleted or defaced, without us noticing it, would cause
> >> >>> our users some harm, then it is product documentation.  If the right
> >> >>> to copy, modify and redistribute the documentation is essentially to
> >> >>> successful creating and hosting a new port or translation, or even a
> >> >>> commercial derivative or an open source fork, of the project, then it
> >> >>> is product documentation.
> >> >>
> >> >> Leaving aside for the moment all the other user-doc type items on the
> >> >> wiki, and looking specifically at the existing current set of user
> >> >> guides (which are in ODT/PDF format, but made available for download
> >> >> from the existing OOo wiki), I'm unclear how they will fit into this.
> >> >> They are not currently under the Apache license, and we would never be
> >> >> able to track down all the contributors to get them to agree to the
> >> >> license and/or sign the iCLA. So are we talking only about future
> >> >> updates to these docs? And if so, do you mean that every future
> >> >> contributor to these guides during their production must sign the iCLA?
> >> >> Or just that only someone with suitable access rights (committer?) can
> >> >> put them on the wiki (in ODT/PDF format)? Or something else?
> >> >>
> >> >
> >> > I'd like us to treat documentation like we do code.  Not necessarily
> >> > the same tools, but the same care for provenance, accountability and
> >> > quality, namely:
> >> >
> >> > 1) We welcome "patches" and "contributions" from anyone, but these
> >> > must be first reviewed and approved by a project committer before they
> >> > become part of the documentation set.  Any such contributions must be
> >> > made under Apache 2.0 license.
> >> >
> >> > 2) Only project committers have direct write access to the
> >> > documentation.  This requires that they first sign the iCLA.
> >> >
> >> > 3) All contributions, whether from the public or from committers and
> >> > tracked/logged, so we can accuratel

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 8:53 PM, Jean Hollis Weber  wrote:
> On Tue, 2011-08-02 at 19:12 -0400, Rob Weir wrote:
>
>> The essential question to ask is, what rights do users of the doc
>> have?  If we want downstream consumers to be able to copy, modify and
>> redistribute the documentation then we need it under Apache 2.0, which
>> is what would happen if the author signed the iCLA.
>
> The user guides are under CC-BY license. Your hypothetical case could
> reuse them just as they could reuse material under the Apache license.
>

All content contributed directly to the project is done in Apache 2.0.
 But there is some allowance for using 3rd party components that have
a compatible license.  A list of compatible licenses currently
recognized are listed here:

http://www.apache.org/legal/resolved.html#category-a

As you can see, CC-BY 2.5 is included in that list.  So I think we're good.

-Rob


> Yes, I realise you're talking about wiki material in the rest of this
> note.
>
> --Jean
>
>>
>> Project releases, naturally, are all under Apache 2.0 and must
>> guarantee these rights.  This is true for any doc that is bundled with
>> them.
>>
>> As you know, we don't currently bundle the wiki doc with the releases.
>>  But should we reserve the right to do this?  Let me give you a very
>> plausible use case for that:
>>
>> Imagine a school or government department, or a company, that wants to
>> deploy OpenOffice in their organization, but also wants to host their
>> own copy of the wiki documentation, inside their firewall, perhaps
>> with some customized material.  This could range from adding
>> additional links to internal template servers, to removing irrelevant
>> information, to adding documentation regarding internal-only plugins.
>> It could be complete, or only for some small number of pages.
>>
>> Is something like that a reasonable use?  Something that we should
>> "reserve the right" to support?  I think so.  If we ever wanted to
>> support something like this, then we would need the wiki (or at least
>> the core doc parts of the wiki) be under a common permissive license.
>
>
>
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, 2011-08-02 at 19:12 -0400, Rob Weir wrote:

> The essential question to ask is, what rights do users of the doc
> have?  If we want downstream consumers to be able to copy, modify and
> redistribute the documentation then we need it under Apache 2.0, which
> is what would happen if the author signed the iCLA.

The user guides are under CC-BY license. Your hypothetical case could
reuse them just as they could reuse material under the Apache license. 

Yes, I realise you're talking about wiki material in the rest of this
note.

--Jean

> 
> Project releases, naturally, are all under Apache 2.0 and must
> guarantee these rights.  This is true for any doc that is bundled with
> them.
> 
> As you know, we don't currently bundle the wiki doc with the releases.
>  But should we reserve the right to do this?  Let me give you a very
> plausible use case for that:
> 
> Imagine a school or government department, or a company, that wants to
> deploy OpenOffice in their organization, but also wants to host their
> own copy of the wiki documentation, inside their firewall, perhaps
> with some customized material.  This could range from adding
> additional links to internal template servers, to removing irrelevant
> information, to adding documentation regarding internal-only plugins.
> It could be complete, or only for some small number of pages.
> 
> Is something like that a reasonable use?  Something that we should
> "reserve the right" to support?  I think so.  If we ever wanted to
> support something like this, then we would need the wiki (or at least
> the core doc parts of the wiki) be under a common permissive license.

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, 2011-08-02 at 18:36 -0400, Rob Weir wrote:

> Also, Jean, I'm glad you are following this thread.  I'd love to hear
> what you think the relationship between the kind of doc on the wiki
> versus what you are doing on ODFAuthors.  How do they relate in terms
> of topics, content types, etc.?  Is there significant overlap?  Is
> there any way to rationalize this?

In the past we put a "wikified" version of the user guides on the wiki,
along with the .ODT and .PDF versions, but after 3.2 we stopped doing
that as it was too much work for the small number of people involved.
The reasons for the wiki version were (a) to offer the user guides in
another format, for those who prefer reading online; and (b) to
encourage updates from people who might find that faster and easier to
do than submitting changes through the ODFAuthors group. As far as I
know, very few pages were edited on the wiki, although some valuable
comments were left on a few discussion pages, primarily in the more
advanced or technical parts of the Calc Guide. In several instances,
again mainly with the Calc Guide, there were useful links to other wiki
pages with content that we did not attempt to add to the .odt/.pdf
versions: mainly the lists of functions that were searchable in various
ways on the wiki.

Other than that, there is almost no overlap except for some how-tos that
I or others extracted from the user guides or wrote as stand-alones and
then incorporated into a user guide (perhaps 10 wiki pages at most). 

BTW, I do not recommend wikifying future releases of the user guides
because of the work involved. Making the .odt/.pdf versions downloadable
from the wiki is easy and AFAIK works well for all concerned.

--Jean

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 8:32 PM, Jean Hollis Weber  wrote:
> On Tue, 2011-08-02 at 10:52 -0400, Rob Weir wrote:
>> On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton
>>  wrote:
>> > -1
>> >
>> > I don't understand why there is continued pressing that things not in a 
>> > release have to be treated as if it requires the same treatment as the 
>> > content of a release.  I thought we had worked a high-level sketch of the 
>> > user documentation case with Jean Hollis Weber some time ago on this list.
>> >
>>
>> That was something else entirely, ODFAuthors.org, a site that is
>> external to Apache.  We're not discussing that right now.  What we're
>> discussing is the content at wiki.services.openoffice.org, which we
>> are planning to be part of the Apache OpenOffice project. Two
>> different things.
>
> *I* was talking about the docs produced by ODFAuthors, in my note quoted
> below, and I asked a question that was not answered; the answer was
> about the material directly edited on the wiki, not about the material I
> asked about.
>

>From licensing perspective it is the same, whether it is content in
wikitext or content in attachments to a wiki page.  The thing that
would be different would be links to content on external sites.

If that is not answering your question, maybe you should restate, with
a link to a specific example.

-Rob

> --Jean
>
>> >
>> > -Original Message-
>> > From: Rob Weir [mailto:apa...@robweir.com]
>> > Sent: Tuesday, August 02, 2011 05:04
>> > To: ooo-dev@incubator.apache.org
>> > Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
>> > re:OpenOffice.org branding)
>> >
>> > On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  
>> > wrote:
>> >> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>> >>> I'd look at it like this:  The documentation that is needed for our
>> >>> users to be successful with our product, from end users, to admins, to
>> >>> application developers, that documentation is product documentation.
>> >>> If having it deleted or defaced, without us noticing it, would cause
>> >>> our users some harm, then it is product documentation.  If the right
>> >>> to copy, modify and redistribute the documentation is essentially to
>> >>> successful creating and hosting a new port or translation, or even a
>> >>> commercial derivative or an open source fork, of the project, then it
>> >>> is product documentation.
>> >>
>> >> Leaving aside for the moment all the other user-doc type items on the
>> >> wiki, and looking specifically at the existing current set of user
>> >> guides (which are in ODT/PDF format, but made available for download
>> >> from the existing OOo wiki), I'm unclear how they will fit into this.
>> >> They are not currently under the Apache license, and we would never be
>> >> able to track down all the contributors to get them to agree to the
>> >> license and/or sign the iCLA. So are we talking only about future
>> >> updates to these docs? And if so, do you mean that every future
>> >> contributor to these guides during their production must sign the iCLA?
>> >> Or just that only someone with suitable access rights (committer?) can
>> >> put them on the wiki (in ODT/PDF format)? Or something else?
>> >>
>> >
>> > I'd like us to treat documentation like we do code.  Not necessarily
>> > the same tools, but the same care for provenance, accountability and
>> > quality, namely:
>> >
>> > 1) We welcome "patches" and "contributions" from anyone, but these
>> > must be first reviewed and approved by a project committer before they
>> > become part of the documentation set.  Any such contributions must be
>> > made under Apache 2.0 license.
>> >
>> > 2) Only project committers have direct write access to the
>> > documentation.  This requires that they first sign the iCLA.
>> >
>> > 3) All contributions, whether from the public or from committers and
>> > tracked/logged, so we can accurately determine who made a given
>> > change.  So no anonymous or pseudonymous patches.  A user id that we
>> > can trace to a real email address is fine.
>> >
>> > With code this works by non-committer contributors sending patches
>> > (diffs) to the mailing list, where they are merged in and reviewed by
>> > a committer, and then checked into the repository.  With
>> > documentation, using a wiki , we would need a different mechanism for
>> > achieving this.  Luckily there are MediaWiki extensions to enable
>> > this.
>> >
>> > I'd like to preserve the immediate nature of editing on the wiki.
>> > That is its strength.  But we need to find away to also get this under
>> > project oversight as well.  I think we can do both, without too much
>> > annoyance to contributors.
>> >
>> >> --Jean
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>
>
>
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, 2011-08-02 at 10:52 -0400, Rob Weir wrote:
> On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton
>  wrote:
> > -1
> >
> > I don't understand why there is continued pressing that things not in a 
> > release have to be treated as if it requires the same treatment as the 
> > content of a release.  I thought we had worked a high-level sketch of the 
> > user documentation case with Jean Hollis Weber some time ago on this list.
> >
> 
> That was something else entirely, ODFAuthors.org, a site that is
> external to Apache.  We're not discussing that right now.  What we're
> discussing is the content at wiki.services.openoffice.org, which we
> are planning to be part of the Apache OpenOffice project. Two
> different things.

*I* was talking about the docs produced by ODFAuthors, in my note quoted
below, and I asked a question that was not answered; the answer was
about the material directly edited on the wiki, not about the material I
asked about. 

--Jean

> >
> > -Original Message-
> > From: Rob Weir [mailto:apa...@robweir.com]
> > Sent: Tuesday, August 02, 2011 05:04
> > To: ooo-dev@incubator.apache.org
> > Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
> > re:OpenOffice.org branding)
> >
> > On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  
> > wrote:
> >> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
> >>> I'd look at it like this:  The documentation that is needed for our
> >>> users to be successful with our product, from end users, to admins, to
> >>> application developers, that documentation is product documentation.
> >>> If having it deleted or defaced, without us noticing it, would cause
> >>> our users some harm, then it is product documentation.  If the right
> >>> to copy, modify and redistribute the documentation is essentially to
> >>> successful creating and hosting a new port or translation, or even a
> >>> commercial derivative or an open source fork, of the project, then it
> >>> is product documentation.
> >>
> >> Leaving aside for the moment all the other user-doc type items on the
> >> wiki, and looking specifically at the existing current set of user
> >> guides (which are in ODT/PDF format, but made available for download
> >> from the existing OOo wiki), I'm unclear how they will fit into this.
> >> They are not currently under the Apache license, and we would never be
> >> able to track down all the contributors to get them to agree to the
> >> license and/or sign the iCLA. So are we talking only about future
> >> updates to these docs? And if so, do you mean that every future
> >> contributor to these guides during their production must sign the iCLA?
> >> Or just that only someone with suitable access rights (committer?) can
> >> put them on the wiki (in ODT/PDF format)? Or something else?
> >>
> >
> > I'd like us to treat documentation like we do code.  Not necessarily
> > the same tools, but the same care for provenance, accountability and
> > quality, namely:
> >
> > 1) We welcome "patches" and "contributions" from anyone, but these
> > must be first reviewed and approved by a project committer before they
> > become part of the documentation set.  Any such contributions must be
> > made under Apache 2.0 license.
> >
> > 2) Only project committers have direct write access to the
> > documentation.  This requires that they first sign the iCLA.
> >
> > 3) All contributions, whether from the public or from committers and
> > tracked/logged, so we can accurately determine who made a given
> > change.  So no anonymous or pseudonymous patches.  A user id that we
> > can trace to a real email address is fine.
> >
> > With code this works by non-committer contributors sending patches
> > (diffs) to the mailing list, where they are merged in and reviewed by
> > a committer, and then checked into the repository.  With
> > documentation, using a wiki , we would need a different mechanism for
> > achieving this.  Luckily there are MediaWiki extensions to enable
> > this.
> >
> > I'd like to preserve the immediate nature of editing on the wiki.
> > That is its strength.  But we need to find away to also get this under
> > project oversight as well.  I think we can do both, without too much
> > annoyance to contributors.
> >
> >> --Jean
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, 2011-08-02 at 08:03 -0400, Rob Weir wrote:
> On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  
> wrote:
> > On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
> >> I'd look at it like this:  The documentation that is needed for our
> >> users to be successful with our product, from end users, to admins, to
> >> application developers, that documentation is product documentation.
> >> If having it deleted or defaced, without us noticing it, would cause
> >> our users some harm, then it is product documentation.  If the right
> >> to copy, modify and redistribute the documentation is essentially to
> >> successful creating and hosting a new port or translation, or even a
> >> commercial derivative or an open source fork, of the project, then it
> >> is product documentation.
> >
> > Leaving aside for the moment all the other user-doc type items on the
> > wiki, and looking specifically at the existing current set of user
> > guides (which are in ODT/PDF format, but made available for download
> > from the existing OOo wiki), I'm unclear how they will fit into this.
> > They are not currently under the Apache license, and we would never be
> > able to track down all the contributors to get them to agree to the
> > license and/or sign the iCLA. So are we talking only about future
> > updates to these docs? And if so, do you mean that every future
> > contributor to these guides during their production must sign the iCLA?
> > Or just that only someone with suitable access rights (committer?) can
> > put them on the wiki (in ODT/PDF format)? Or something else?
> >
> 
> I'd like us to treat documentation like we do code.  Not necessarily
> the same tools, but the same care for provenance, accountability and
> quality, namely:
> 
> 1) We welcome "patches" and "contributions" from anyone, but these
> must be first reviewed and approved by a project committer before they
> become part of the documentation set.  Any such contributions must be
> made under Apache 2.0 license.
> 
> 2) Only project committers have direct write access to the
> documentation.  This requires that they first sign the iCLA.
> 
> 3) All contributions, whether from the public or from committers and
> tracked/logged, so we can accurately determine who made a given
> change.  So no anonymous or pseudonymous patches.  A user id that we
> can trace to a real email address is fine.
> 
> With code this works by non-committer contributors sending patches
> (diffs) to the mailing list, where they are merged in and reviewed by
> a committer, and then checked into the repository.  With
> documentation, using a wiki , we would need a different mechanism for
> achieving this.  Luckily there are MediaWiki extensions to enable
> this.
> 
> I'd like to preserve the immediate nature of editing on the wiki.
> That is its strength.  But we need to find away to also get this under
> project oversight as well.  I think we can do both, without too much
> annoyance to contributors.

As far as I can tell, you are talking about direct edits to the wiki.
That is not what I asked about. 

--Jean

RE: How to handle the downloads?

2011-08-02 Thread Gavin McDonald



> -Original Message-
> From: Marcus (OOo) [mailto:marcus.m...@wtnet.de]
> Sent: Wednesday, 3 August 2011 9:40 AM
> To: ooo-dev@incubator.apache.org
> Subject: Re: How to handle the downloads?
> 
> Am 08/02/2011 11:03 PM, schrieb Gavin McDonald:
> >
> >
> >> -Original Message-
> >> From: Marcus (OOo) [mailto:marcus.m...@wtnet.de]
> >> Sent: Wednesday, 3 August 2011 12:55 AM
> >> To: ooo-dev@incubator.apache.org
> >> Subject: Re: How to handle the downloads?
> >>
> >> Thanks for you note. Then we should implement adownload method
> >> withthe fllowing order:
> >>
> >> 1. User clicks on the One-Click-Download URL and get the software
> >> (like today on "download.openoffice.org").
> >>
> >> 2. If not, he can use alternative download links (like today on
> >> "download.openoffice.org/pther.html").
> >>
> >> 3. If a special mirror has to be used, the list of all available
> >> mirrors
> > will help
> >> (like today on "http://distribution.openoffice.org/mirrors/#mirrors";).
> >>
> >> Latest with step 3 all users should be able to download something.
> >
> > Yep, all possible here at the ASF right now.
> >
> > See www.apache.org/mirrors for our equiv of step 3.
> 
> I've already understood that you don't want the OOo mirrors but that we
> should use the Apache ones. ;-)

Hi Marcus,

don't count me as 100% on that yet, I want to know more about the OOo
mirrors too.

I just didn't want to be maintaining 150+ projects on one mirror system and
1 project
on another mirror system. maintaining one mirror system is easier, so If
that is possible
and our mirroring system can cope, and we can maybe coax a few more mirrors
our way
all the better. Some of our existing mirrors may decide that bandwidth is
too much and
leave, so we need replacements.

If it makes sense to try and merge these somehow, I want to pursue that
avenue.

We may need both for some time, we can not put non ASF releases on our
mirroring system
anyway so what we are trying to resolve is from our first ASF release
onwards.

Gav...


> 
> Marcus
> 
> 
> 
> >> Am 08/02/2011 04:38 PM, schrieb Donald Whytock:
> >>> A consideration...I for one have a need to be able to select my
> >>> mirror.  My office's firewall blocks certain domains and websites,
> >>> especially those recognized as "hosting" or "file-sharing" sites.
> >>> It does not, however, block .edu sites, so when I download an Apache
> >>> product I select a university mirror.
> >>>
> >>> Other users may have similar constraints.  If OOo's download process
> >>> is going to tie into Apache mirroring, please don't completely
> >>> eliminate the capacity to select the mirror.
> >>>
> >>> Don

Re: How to handle the downloads?

Am 08/02/2011 11:03 PM, schrieb Gavin McDonald:

-Original Message-
From: Marcus (OOo) [mailto:marcus.m...@wtnet.de]
Sent: Wednesday, 3 August 2011 12:55 AM
To: ooo-dev@incubator.apache.org
Subject: Re: How to handle the downloads?

Thanks for you note. Then we should implement adownload method withthe
fllowing order:

1. User clicks on the One-Click-Download URL and get the software (like
today on "download.openoffice.org").

2. If not, he can use alternative download links (like today on
"download.openoffice.org/pther.html").

3. If a special mirror has to be used, the list of all available mirrors

will help

(like today on "http://distribution.openoffice.org/mirrors/#mirrors";).

Latest with step 3 all users should be able to download something.

Yep, all possible here at the ASF right now.

See www.apache.org/mirrors for our equiv of step 3.

I've already understood that you don't want the OOo mirrors but that we 
should use the Apache ones. ;-)

Marcus

Am 08/02/2011 04:38 PM, schrieb Donald Whytock:

A consideration...I for one have a need to be able to select my
mirror.  My office's firewall blocks certain domains and websites,
especially those recognized as "hosting" or "file-sharing" sites.  It
does not, however, block .edu sites, so when I download an Apache
product I select a university mirror.

Other users may have similar constraints.  If OOo's download process
is going to tie into Apache mirroring, please don't completely
eliminate the capacity to select the mirror.

Don

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


Rob Weir wrote:

On Tue, Aug 2, 2011 at 5:16 PM, Andy Brown  wrote:

Rob Weir wrote:


I poked around and found this page:

http://wiki.services.openoffice.org/wiki/Special:Statistics


Good find.


This lists some additional roles (with counts)

Administrators (26)
Bureaucrats (4)
Editors (20)
Reviewers (5)

Those are in addition to 35,020 User accounts.

Curiously, it reports only 5 of the 35,020 users as having been active
in the past 7 days.


Personally I am surprised there have been any edits since the announcement
of transferring to Apache, let a lone in the last week. Shows that someone
is still interested.  I would like to find out what as edited.


How we authorize people for these roles and what qualifications are
required for these roles is an important question.

There are a similar set of questions we should ask about the support
forums, what the roles are and how PPMC oversight maps to them.


I would think that the PPMC and Committers would be the logical choice.  The
administration is still our responsibility.  Currently we have members that
are listed in admin roles for the wiki and for the forums.



A reasonable set of guidelines might be:

0) The permission to set user permissions should be reserved for PPMC-delegates

1) Any permission that allows actions that cannot be logged or cannot
easily be undone should be reserved for PPMC-delegates

2) Any permission that allows one user rights over another user
(banning, suspending, locking pages, etc.) should be reserved for
PPMC-delegates

3) Other permissions can be shared more broadly.

The normal case would be to have PPMC delegates be committers.  If not
now, then they would be obvious candidates for to become committers.


Seems good to me.  I might suggest #2 that at least two members be 
required to ban a user, prevents personal issues.


Andy

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Wolf Halton

This certainly states the Apache position clearly, Eike.
Since I already have a CLA in file (it only hurt for a moment) it would be
silly for me to argue the case for undocumented contribution any more. The
most sensible route, IMO, is to offer a wiki with 3 contributor levels.
1. Registered users who checkbox a creative-commons eula, or Apache license
agreement. This gives us the ability to run the wiki, and to edit or delete
user content as required. I imagine these users will only be able to comment
on articles, and I expect most of them to abstain.
2. People with CLAs on file, who ike to write how-tos and pages. These
people will be allowed to edit eachother's contributions.
3. Committers who vet and edit the writings of the #2 committers (and
eachother) for possible inclusion in the official documentation.
Persons who perceive this as an honour will write in the wiki. Persons what
consider this structure to be an enormous pita will probably still write in
wikipedia, where the contributors are mostly of type #2.

Wolf

On Aug 2, 2011 6:47 PM, "Eike Rathke"  wrote:
> Hi Rob,
>
> On Tuesday, 2011-08-02 13:18:37 -0400, Rob Weir wrote:
>
>> > And we should look around at some of the TLP project wikis that allow
public contributions.
>>
>> Pass along some links if you find some good examples.
>
> I think these explain well what needs to be considered for project
> documentation wikis and that it is allowed to use conventional wikis:
>
>
https://cwiki.apache.org/confluence/display/CWIKI/Index#Index-Ifweusethewikitomaintainprojectdocumentation%2Carethereanyspecialconsiderations%3F
>
>
https://cwiki.apache.org/confluence/display/CWIKI/Index#Index-Butwhatifwewouldlikethecommunityatlargetohelpmaintainthespace%3F
>
> | the touch point is whether you want to reserve the right to bundle the
> | documentation with a release and/or check a copy into an ASF repository
>
>
> Eike
>
> --
> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 6:46 PM, Eike Rathke  wrote:
> Hi Rob,
>
> On Tuesday, 2011-08-02 13:18:37 -0400, Rob Weir wrote:
>
>> > And we should look around at some of the TLP project wikis that allow 
>> > public contributions.
>>
>> Pass along some links if you find some good examples.
>
> I think these explain well what needs to be considered for project
> documentation wikis and that it is allowed to use conventional wikis:
>
> https://cwiki.apache.org/confluence/display/CWIKI/Index#Index-Ifweusethewikitomaintainprojectdocumentation%2Carethereanyspecialconsiderations%3F
>
> https://cwiki.apache.org/confluence/display/CWIKI/Index#Index-Butwhatifwewouldlikethecommunityatlargetohelpmaintainthespace%3F
>
> | the touch point is whether you want to reserve the right to bundle the
> | documentation with a release and/or check a copy into an ASF repository
>

The essential question to ask is, what rights do users of the doc
have?  If we want downstream consumers to be able to copy, modify and
redistribute the documentation then we need it under Apache 2.0, which
is what would happen if the author signed the iCLA.

Project releases, naturally, are all under Apache 2.0 and must
guarantee these rights.  This is true for any doc that is bundled with
them.

As you know, we don't currently bundle the wiki doc with the releases.
 But should we reserve the right to do this?  Let me give you a very
plausible use case for that:

Imagine a school or government department, or a company, that wants to
deploy OpenOffice in their organization, but also wants to host their
own copy of the wiki documentation, inside their firewall, perhaps
with some customized material.  This could range from adding
additional links to internal template servers, to removing irrelevant
information, to adding documentation regarding internal-only plugins.
It could be complete, or only for some small number of pages.

Is something like that a reasonable use?  Something that we should
"reserve the right" to support?  I think so.  If we ever wanted to
support something like this, then we would need the wiki (or at least
the core doc parts of the wiki) be under a common permissive license.

-Rob

>
>  Eike
>
> --
>  PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

Hi Rob,

On Tuesday, 2011-08-02 10:52:33 -0400, Rob Weir wrote:

> > I don't understand why there is continued pressing that things not in a 
> > release have to be treated as if it requires the same treatment as the 
> > content of a release.  I thought we had worked a high-level sketch of the 
> > user documentation case with Jean Hollis Weber some time ago on this list.
> >
> 
> That was something else entirely, ODFAuthors.org, a site that is
> external to Apache.  We're not discussing that right now.  What we're
> discussing is the content at wiki.services.openoffice.org, which we
> are planning to be part of the Apache OpenOffice project. Two
> different things.

Actually the OOo 3.2 user guide by the ODFAuthors group was contributed
to the wiki as well under a CC-BY license, see for example
http://wiki.services.openoffice.org/wiki/Documentation/OOo3_User_Guides/Getting_Started

Later guides for OOo 3.3 and 3.x are available as .odt and .pdf checked
in to the wiki, not as wiki pages, see
http://wiki.services.openoffice.org/wiki/Documentation

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpxZCoDeR9dv.pgp
Description: PGP signature

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Wolf Halton

If you go back to the founding of the support forums, you will find there is
what amounts to a charter for the support organization. The bureaucrats and
a few other roles stemmed from that. We were attempting to create an
organization that was more than simply a support website. Being one of the
people whose involvement tapered off, I have some empathy for others who got
busy with other things.

All sites I know of have a certain amount of ebb and flow among the
registered members, but even among the registered members, I suspect there
was a large number who visited to research a question without stopping to
log in. I known I do that.

Wolf
Tirelessly evading conventionality for 49 years, so you don’t have to. :-)

On Aug 2, 2011 6:11 PM, "Manfred A. Reiter"  wrote:
> 2011/8/2 Rob Weir 
>
>> On Tue, Aug 2, 2011 at 3:26 PM, Andy Brown 
>> wrote:
>>
>> [...]
>
>>
>> I poked around and found this page:
>>
>> http://wiki.services.openoffice.org/wiki/Special:Statistics
>>
>> This lists some additional roles (with counts)
>>
>> Administrators (26)
>> Bureaucrats (4)
>> Editors (20)
>> Reviewers (5)
>>
>> Those are in addition to 35,020 User accounts.
>>
>> Curiously, it reports only 5 of the 35,020 users as having been active
>> in the past 7 days.
>>
>
>
> did you poked around 1 year ago as well?
> do you have an explanation, why these numbers are slowing down?
>
> with the statistic above you don't increase the credibility ...
>
> or
>
>
http://www.statistik.baden-wuerttemberg.de/Veroeffentl/Monatshefte/essay.asp?xYear=2004&xMonth=11&eNr=11
>
> cheers
>
> M.
>
>
> M.

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

Hi Rob,

On Tuesday, 2011-08-02 13:18:37 -0400, Rob Weir wrote:

> > And we should look around at some of the TLP project wikis that allow 
> > public contributions.
> 
> Pass along some links if you find some good examples.

I think these explain well what needs to be considered for project
documentation wikis and that it is allowed to use conventional wikis:

https://cwiki.apache.org/confluence/display/CWIKI/Index#Index-Ifweusethewikitomaintainprojectdocumentation%2Carethereanyspecialconsiderations%3F

https://cwiki.apache.org/confluence/display/CWIKI/Index#Index-Butwhatifwewouldlikethecommunityatlargetohelpmaintainthespace%3F

| the touch point is whether you want to reserve the right to bundle the
| documentation with a release and/or check a copy into an ASF repository


  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpzjWkbNkWEw.pgp
Description: PGP signature

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 6:24 PM, Jean Weber  wrote:
>
>
> On 03/08/2011, at 7:16, Andy Brown  wrote:
>
>> Rob Weir wrote:
>>>
>>> Curiously, it reports only 5 of the 35,020 users as having been active
>>> in the past 7 days.
>>
>> Personally I am surprised there have been any edits since the announcement 
>> of transferring to Apache, let a lone in the last week. Shows that someone 
>> is still interested.  I would like to find out what as edited.
>
> I may have updated some pages related to the workings of the Docs group and 
> ODFAuthors, but not any docs themselves.
>

Is there any easy way to get a list of active users for the wiki,
year-to-date for 2011, maybe sorted by number of edits?  That would be
great to know, a list of people we can reach out to and invite to
participate again in the new project and new wiki, if they are not
already here.

Also, Jean, I'm glad you are following this thread.  I'd love to hear
what you think the relationship between the kind of doc on the wiki
versus what you are doing on ODFAuthors.  How do they relate in terms
of topics, content types, etc.?  Is there significant overlap?  Is
there any way to rationalize this?

> Jean
>
>>
>

Re: OOO340 to svn

Hi IngridvdM,

On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:

> >The Hg archive should simply replicate the current structure at OOo,
> >also for ease of adding in pending CWSs as branches, so a separate l10n
> >repository.
> >
> Another good argument to separate l10n from trunk was given in an
> earlier thread: This way it is easier for developers to get only
> what they will need usually and spare the extra time and space.
> 
> I think this is a good argument and I wonder whether we shouldn't be
> prepared to identify more such stuff - for example the binfilter.

The problem with binfilter is that it depends on modules not in
binfilter, changing them incompatibly may entail changes necessary to
binfilter, those changes should be in one changeset, which I think is
not possible when not in trunk, insights anyone?

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgp8N84tQJjUk.pgp
Description: PGP signature

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 6:10 PM, Manfred A. Reiter  wrote:
> 2011/8/2 Rob Weir 
>
>> On Tue, Aug 2, 2011 at 3:26 PM, Andy Brown 
>> wrote:
>>
>> [...]
>
>>
>> I poked around and found this page:
>>
>> http://wiki.services.openoffice.org/wiki/Special:Statistics
>>
>> This lists some additional roles (with counts)
>>
>> Administrators (26)
>> Bureaucrats (4)
>> Editors (20)
>> Reviewers (5)
>>
>> Those are in addition to 35,020 User accounts.
>>
>> Curiously, it reports only 5 of the 35,020 users as having been active
>> in the past 7 days.
>>
>
>
> did you poked around 1 year ago as well?
> do you have an explanation, why these numbers are slowing down?
>
> with the statistic above you don't increase the credibility ...
>
> or
>
> http://www.statistik.baden-wuerttemberg.de/Veroeffentl/Monatshefte/essay.asp?xYear=2004&xMonth=11&eNr=11
>

One of the biggest mistakes I made when I moved into my house was to
design in my back yard a huge garden.  It took a weeks of labor to get
it started.  But I never had time to maintain it.  I created a garden
far too large for my small "community" (my wife and I) to handle.  We
fought back the weeds, but the weeds won in the end.  I would have
been better off with house plants, in pots.  More sheltered.  But also
easier to take care of.

With the wiki, if we really want to allow anyone to have write access
to it, then we really need to be committed to fight the weeds, which
in the case of wikis would be spam, low quality content, edit wars,
etc.  If we can re-establish the community participation level the way
it was a year ago, then great.  It would have a chance of success.
But right now I see almost no activity on the wiki.  35,000 user
accounts, but no users.  If this doesn't change, the weeds will surely
win.

> cheers
>
> M.
>
>
> M.
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Jean Weber

On 03/08/2011, at 7:16, Andy Brown  wrote:

> Rob Weir wrote:
>> 
>> Curiously, it reports only 5 of the 35,020 users as having been active
>> in the past 7 days.
> 
> Personally I am surprised there have been any edits since the announcement of 
> transferring to Apache, let a lone in the last week. Shows that someone is 
> still interested.  I would like to find out what as edited.

I may have updated some pages related to the workings of the Docs group and 
ODFAuthors, but not any docs themselves.

Jean

>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


Eike Rathke wrote:

Hi Andy,

On Tuesday, 2011-08-02 14:16:23 -0700, Andy Brown wrote:


Personally I am surprised there have been any edits since the
announcement of transferring to Apache, let a lone in the last week.
Shows that someone is still interested.  I would like to find out
what as edited.


http://wiki.services.openoffice.org/wiki/Special:RecentChanges

One of the 5 was me editing my user page..

   Eike



Thanks that is what I was looking for.  That is something I never got a 
round to. :(


Andy

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread eric b


Hi Rob,



I poked around and found this page:

http://wiki.services.openoffice.org/wiki/Special:Statistics

This lists some additional roles (with counts)

Administrators (26)
Bureaucrats (4)
Editors (20)
Reviewers (5)

Those are in addition to 35,020 User accounts.

Curiously, it reports only 5 of the 35,020 users as having been active
in the past 7 days.




I'd say People observe what happens, since the announce, but probably  
before ...


To tell you more, I myself was - between 2006 and 2009 - very active  
on the OpenOffice.org wiki, initialy thought for developers purpose.


It was a very alive and uggly big bazaar, with a lot of ideas, tries  
and experiences. The Mac OS X native port was the best moment of the  
OpenOffice.org Community life (before people use the word, thinking  
to ''usefull idiots'' instead, to be honest ... ). There was nothing  
forced : we tried to organize, as well as possible, but concentrating  
on the content, not on the look. As an example, have a look at my  
users page, per see the activity it was : http:// 
wiki.services.openoffice.org/wiki/User:Ericb


But a day, some people decided to control the OpenOffice.org wiki  
(not only the wiki in fact). After that, people like me were upset,  
and simply definitily stopped to use it.


It would be great to not redo the same mistakes ...


Regards,
Eric Bachard

--
qɔᴉɹə
Education Project:
http://wiki.services.openoffice.org/wiki/Education_Project
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 5:16 PM, Andy Brown  wrote:
> Rob Weir wrote:
>>
>> I poked around and found this page:
>>
>> http://wiki.services.openoffice.org/wiki/Special:Statistics
>
> Good find.
>
>> This lists some additional roles (with counts)
>>
>> Administrators (26)
>> Bureaucrats (4)
>> Editors (20)
>> Reviewers (5)
>>
>> Those are in addition to 35,020 User accounts.
>>
>> Curiously, it reports only 5 of the 35,020 users as having been active
>> in the past 7 days.
>
> Personally I am surprised there have been any edits since the announcement
> of transferring to Apache, let a lone in the last week. Shows that someone
> is still interested.  I would like to find out what as edited.
>
>> How we authorize people for these roles and what qualifications are
>> required for these roles is an important question.
>>
>> There are a similar set of questions we should ask about the support
>> forums, what the roles are and how PPMC oversight maps to them.
>
> I would think that the PPMC and Committers would be the logical choice.  The
> administration is still our responsibility.  Currently we have members that
> are listed in admin roles for the wiki and for the forums.
>

A reasonable set of guidelines might be:

0) The permission to set user permissions should be reserved for PPMC-delegates

1) Any permission that allows actions that cannot be logged or cannot
easily be undone should be reserved for PPMC-delegates

2) Any permission that allows one user rights over another user
(banning, suspending, locking pages, etc.) should be reserved for
PPMC-delegates

3) Other permissions can be shared more broadly.

The normal case would be to have PPMC delegates be committers.  If not
now, then they would be obvious candidates for to become committers.

> Andy
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Manfred A. Reiter

2011/8/2 Rob Weir 

> On Tue, Aug 2, 2011 at 3:26 PM, Andy Brown 
> wrote:
>
> [...]

>
> I poked around and found this page:
>
> http://wiki.services.openoffice.org/wiki/Special:Statistics
>
> This lists some additional roles (with counts)
>
> Administrators (26)
> Bureaucrats (4)
> Editors (20)
> Reviewers (5)
>
> Those are in addition to 35,020 User accounts.
>
> Curiously, it reports only 5 of the 35,020 users as having been active
> in the past 7 days.
>


did you poked around 1 year ago as well?
do you have an explanation, why these numbers are slowing down?

with the statistic above you don't increase the credibility ...

or

http://www.statistik.baden-wuerttemberg.de/Veroeffentl/Monatshefte/essay.asp?xYear=2004&xMonth=11&eNr=11

cheers

M.


M.

Re: Converting the repo using mercurial's convert extension

2011-08-02 Thread Daniel Shahaf

Andrew Rist wrote on Tue, Aug 02, 2011 at 10:27:40 -0700:
> On 8/2/2011 7:25 AM, Christian Lohmaier wrote:
> >The script to do the mapping is attached
> unfortunately attachments don't make it through the listserver.

IIRC, the list only blocks some kinds of attachments.

And that can be disabled by a request to infra --- we did that in
dev@subversion.  See INFRA-3724

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

Hi Andy,

On Tuesday, 2011-08-02 14:16:23 -0700, Andy Brown wrote:

> Personally I am surprised there have been any edits since the
> announcement of transferring to Apache, let a lone in the last week.
> Shows that someone is still interested.  I would like to find out
> what as edited.

http://wiki.services.openoffice.org/wiki/Special:RecentChanges

One of the 5 was me editing my user page..

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpQCP7fO2XGN.pgp
Description: PGP signature

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

Hi Rob,

On Tuesday, 2011-08-02 16:38:02 -0400, Rob Weir wrote:

> I poked around and found this page:
> http://wiki.services.openoffice.org/wiki/Special:Statistics
> 
> This lists some additional roles (with counts)
> 
> Administrators (26)
> Bureaucrats (4)
> Editors (20)
> Reviewers (5)
> 
> Those are in addition to 35,020 User accounts.
> 
> Curiously, it reports only 5 of the 35,020 users as having been active
> in the past 7 days.

I think that doesn't come as a surprise, most probabbly OOo is perceived
as a dead horse now. To get a sense for activity in the wiki, on mailing
lists, ... one should take a look at the period before Easter this year.

> How we authorize people for these roles and what qualifications are
> required for these roles is an important question.

To me it's unclear what the role of a Bureaucrat is or where it differs
from an Administrator. It's a subset of Administrators.

I'd say we could ask Clayton as he was Bureaucrat, editor, reviewer and
Administrator, but ...

Certainly SysOp/Administrator/Bureaucrat would be tied to Apache
committers.

Entry points for some overview:
http://wiki.services.openoffice.org/wiki/Special:ValidationStatistics
http://wiki.services.openoffice.org/wiki/OpenOffice.org_Wiki:Administrators

Reviewers appear to be members of the documentation team, as are editors
but not only and that group is larger I don't know everyone.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

pgpBqtrtagMyd.pgp
Description: PGP signature

Re: How to handle the downloads?


On Aug 2, 2011, at 2:05 PM, Rob Weir wrote:

> A use case to consider, for future possibilities.   What would be
> required to do this well, not from a web page, but inside the
> OpenOffice application?  So patches, extensions, templates, even
> upgrades initiated from within the app itself, without launching a
> browser?
> 
> Is that doable?  If the geo location is done via IP address, and there
> is a REST API for finding the closest mirrors, and that returns data
> in XML or JSON, that it should be universally consumable.

I don't see any technical trouble. Once we establish the way we interact with 
the download mirrors than simple requests can be made using an HTTPClient or 
FTPClient library.

Maybe Apache HttpClient - http://hc.apache.org/

Regards,
Dave

> 
> -Rob
> 
> 
> On Tue, Aug 2, 2011 at 4:45 PM, Dave Fisher  wrote:
>> Kay,
>> 
>> On Aug 2, 2011, at 11:43 AM, Kay Schenk wrote:
>> 
>>> 
>>> 
>>> On 08/02/2011 09:05 AM, Dave Fisher wrote:
 
 On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote:
 
> Am 08/02/2011 04:53 PM, schrieb Dave Fisher:
>> 
>> On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote:
>> 
>>> Am 08/02/2011 02:15 PM, schrieb Rob Weir:
 On Tue, Aug 2, 2011 at 4:03 AM, Marcus
 (OOo)wrote:
> Am 08/02/2011 03:00 AM, schrieb Dave Fisher:
>> 
>> On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:
>> 
>>> Am 08/02/2011 01:00 AM, schrieb Ross Gardler:
 
 On 1 August 2011 23:42, Marcus
 (OOo)   wrote:
> 
> Am 08/02/2011 12:15 AM, schrieb Ross Gardler:
 
 ...
 
>> The ASF does not care what your download page
>> looks like as long as you use the CGI scripts to
>> ensure that an appropriate mirror site is used.
> 
> Hm, let's see how independent the download thing
> really will be. ;-)
 
 Why don't you mock-up 9in the CMS) what you want the
 download page to look like, without linking it in
 from elsewhere. Once that is done then we can look at
 making the download.cgi work the way you want it.
>>> 
>>> Good idea. Will do so.
>> 
>> I have a script for downloading the download web source
>> from the kenai svn.
>> 
>> If I download the complete AOOo svn tree particularly
>> ooo/trunk/tools/dev/fetch-all-web.sh
>> 
>> You can run that script like so:
>> 
>> $ ../trunk/tools/dev/fetch-all-web.sh
>> ../trunk/tools/dev/web-list.txt .
>> 
>> You then get this (along with all the sub-projects in the
>> web-list.txt)
>> 
>> download dave$ ls -1 2.4.3 all_beta.html all_rc.html
>> cachedimages common contribute.html download.js
>> download2.js download_bouncer.js download_mirrorbrain.js
>> exceptions.css globalvars.js index.html languages.js
>> md5sums next notes.html other.html print_tables.js
>> robots.txt sdk sdk.html source stable.html test
>> 
>> So it's there and it is a matter of wrapping it
>> properly.
> 
> I don't know what you mean with "wrapping". It's working
> and with adjustment of CSS (header, footer, graphics, etc.)
> and underlaying mirror structure it should run also for
> Apache.
>> 
>> Should we start by committing the download site as a
>> subsite of our incubator project?
> 
> The websites inside the incubator project should be
> developer-oriented. But the download is nearly 100%
> user-related, so I would like to see this content to be
> continued on "www.openoffice.org" and not directly in a
> Apache domain.
> 
 
 I think the point is this:  Even as we preserve the content
 of the OpenOffice.org website, we're not going to be
 re-hosting the Mercurial repositories on OO.o.  Everything
 that was formerly in Mercurial will need to migrate somewhere
 else, either SVN at Apache or to Hg at Apache-Extras.   The
 future OO.o website, hosted by Apache will have its source
 files checked into SVN at Apache.  We'd have a mechanism to
 publish these files, on modification, to the right directory
 for the web server.
 
 We'll need a directory structure in SVN that reflects the
 fact that we'll be storing source files for two websites
 there.  This is not hard.
>>> 
>>> Right. In the SVN repo we have to make the separation of the 2
>>> domains visible.'
>> 
>> Yes that is very true, but there is a problem. We only have the
>> one incubator site in the Apache CMS and we need to do some
>> experimental conversions. Let's mi

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


Rob Weir wrote:


I poked around and found this page:

http://wiki.services.openoffice.org/wiki/Special:Statistics


Good find.


This lists some additional roles (with counts)

Administrators (26)
Bureaucrats (4)
Editors (20)
Reviewers (5)

Those are in addition to 35,020 User accounts.

Curiously, it reports only 5 of the 35,020 users as having been active
in the past 7 days.


Personally I am surprised there have been any edits since the 
announcement of transferring to Apache, let a lone in the last week. 
Shows that someone is still interested.  I would like to find out what 
as edited.



How we authorize people for these roles and what qualifications are
required for these roles is an important question.

There are a similar set of questions we should ask about the support
forums, what the roles are and how PPMC oversight maps to them.


I would think that the PPMC and Committers would be the logical choice. 
 The administration is still our responsibility.  Currently we have 
members that are listed in admin roles for the wiki and for the forums.


Andy

Re: How to handle the downloads?

A use case to consider, for future possibilities.   What would be
required to do this well, not from a web page, but inside the
OpenOffice application?  So patches, extensions, templates, even
upgrades initiated from within the app itself, without launching a
browser?

Is that doable?  If the geo location is done via IP address, and there
is a REST API for finding the closest mirrors, and that returns data
in XML or JSON, that it should be universally consumable.

-Rob


On Tue, Aug 2, 2011 at 4:45 PM, Dave Fisher  wrote:
> Kay,
>
> On Aug 2, 2011, at 11:43 AM, Kay Schenk wrote:
>
>>
>>
>> On 08/02/2011 09:05 AM, Dave Fisher wrote:
>>>
>>> On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote:
>>>
 Am 08/02/2011 04:53 PM, schrieb Dave Fisher:
>
> On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote:
>
>> Am 08/02/2011 02:15 PM, schrieb Rob Weir:
>>> On Tue, Aug 2, 2011 at 4:03 AM, Marcus
>>> (OOo)    wrote:
 Am 08/02/2011 03:00 AM, schrieb Dave Fisher:
>
> On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:
>
>> Am 08/02/2011 01:00 AM, schrieb Ross Gardler:
>>>
>>> On 1 August 2011 23:42, Marcus
>>> (OOo)       wrote:

 Am 08/02/2011 12:15 AM, schrieb Ross Gardler:
>>>
>>> ...
>>>
> The ASF does not care what your download page
> looks like as long as you use the CGI scripts to
> ensure that an appropriate mirror site is used.

 Hm, let's see how independent the download thing
 really will be. ;-)
>>>
>>> Why don't you mock-up 9in the CMS) what you want the
>>> download page to look like, without linking it in
>>> from elsewhere. Once that is done then we can look at
>>> making the download.cgi work the way you want it.
>>
>> Good idea. Will do so.
>
> I have a script for downloading the download web source
> from the kenai svn.
>
> If I download the complete AOOo svn tree particularly
> ooo/trunk/tools/dev/fetch-all-web.sh
>
> You can run that script like so:
>
> $ ../trunk/tools/dev/fetch-all-web.sh
> ../trunk/tools/dev/web-list.txt .
>
> You then get this (along with all the sub-projects in the
> web-list.txt)
>
> download dave$ ls -1 2.4.3 all_beta.html all_rc.html
> cachedimages common contribute.html download.js
> download2.js download_bouncer.js download_mirrorbrain.js
> exceptions.css globalvars.js index.html languages.js
> md5sums next notes.html other.html print_tables.js
> robots.txt sdk sdk.html source stable.html test
>
> So it's there and it is a matter of wrapping it
> properly.

 I don't know what you mean with "wrapping". It's working
 and with adjustment of CSS (header, footer, graphics, etc.)
 and underlaying mirror structure it should run also for
 Apache.
>
> Should we start by committing the download site as a
> subsite of our incubator project?

 The websites inside the incubator project should be
 developer-oriented. But the download is nearly 100%
 user-related, so I would like to see this content to be
 continued on "www.openoffice.org" and not directly in a
 Apache domain.

>>>
>>> I think the point is this:  Even as we preserve the content
>>> of the OpenOffice.org website, we're not going to be
>>> re-hosting the Mercurial repositories on OO.o.  Everything
>>> that was formerly in Mercurial will need to migrate somewhere
>>> else, either SVN at Apache or to Hg at Apache-Extras.   The
>>> future OO.o website, hosted by Apache will have its source
>>> files checked into SVN at Apache.  We'd have a mechanism to
>>> publish these files, on modification, to the right directory
>>> for the web server.
>>>
>>> We'll need a directory structure in SVN that reflects the
>>> fact that we'll be storing source files for two websites
>>> there.  This is not hard.
>>
>> Right. In the SVN repo we have to make the separation of the 2
>> domains visible.'
>
> Yes that is very true, but there is a problem. We only have the
> one incubator site in the Apache CMS and we need to do some
> experimental conversions. Let's mix in with our Incubator site
> two initial projects - www and download - as subdirectories so we
> can get started with headers and footers and modifying the CMS
> build to handle the OOo site pages from Kenai.

 OK, no problem to migratethe webpages into the incubator project.
 Tehn we can "play" a bit with the content to see how it behaves.

> We can then get started with branding as well.
>
> Later we can

RE: How to handle the downloads?

2011-08-02 Thread Gavin McDonald



> -Original Message-
> From: Marcus (OOo) [mailto:marcus.m...@wtnet.de]
> Sent: Wednesday, 3 August 2011 12:55 AM
> To: ooo-dev@incubator.apache.org
> Subject: Re: How to handle the downloads?
> 
> Thanks for you note. Then we should implement adownload method withthe
> fllowing order:
> 
> 1. User clicks on the One-Click-Download URL and get the software (like
> today on "download.openoffice.org").
> 
> 2. If not, he can use alternative download links (like today on
> "download.openoffice.org/pther.html").
> 
> 3. If a special mirror has to be used, the list of all available mirrors
will help
> (like today on "http://distribution.openoffice.org/mirrors/#mirrors";).
> 
> Latest with step 3 all users should be able to download something.

Yep, all possible here at the ASF right now.

See www.apache.org/mirrors for our equiv of step 3.

Gav...

> 
> Marcus
> 
> 
> 
> Am 08/02/2011 04:38 PM, schrieb Donald Whytock:
> > A consideration...I for one have a need to be able to select my
> > mirror.  My office's firewall blocks certain domains and websites,
> > especially those recognized as "hosting" or "file-sharing" sites.  It
> > does not, however, block .edu sites, so when I download an Apache
> > product I select a university mirror.
> >
> > Other users may have similar constraints.  If OOo's download process
> > is going to tie into Apache mirroring, please don't completely
> > eliminate the capacity to select the mirror.
> >
> > Don

Re: How to handle the downloads?

Kay,

On Aug 2, 2011, at 11:43 AM, Kay Schenk wrote:

> 
> 
> On 08/02/2011 09:05 AM, Dave Fisher wrote:
>> 
>> On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote:
>> 
>>> Am 08/02/2011 04:53 PM, schrieb Dave Fisher:
 
 On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote:
 
> Am 08/02/2011 02:15 PM, schrieb Rob Weir:
>> On Tue, Aug 2, 2011 at 4:03 AM, Marcus
>> (OOo)wrote:
>>> Am 08/02/2011 03:00 AM, schrieb Dave Fisher:
 
 On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:
 
> Am 08/02/2011 01:00 AM, schrieb Ross Gardler:
>> 
>> On 1 August 2011 23:42, Marcus
>> (OOo)   wrote:
>>> 
>>> Am 08/02/2011 12:15 AM, schrieb Ross Gardler:
>> 
>> ...
>> 
 The ASF does not care what your download page
 looks like as long as you use the CGI scripts to
 ensure that an appropriate mirror site is used.
>>> 
>>> Hm, let's see how independent the download thing
>>> really will be. ;-)
>> 
>> Why don't you mock-up 9in the CMS) what you want the
>> download page to look like, without linking it in
>> from elsewhere. Once that is done then we can look at
>> making the download.cgi work the way you want it.
> 
> Good idea. Will do so.
 
 I have a script for downloading the download web source
 from the kenai svn.
 
 If I download the complete AOOo svn tree particularly
 ooo/trunk/tools/dev/fetch-all-web.sh
 
 You can run that script like so:
 
 $ ../trunk/tools/dev/fetch-all-web.sh
 ../trunk/tools/dev/web-list.txt .
 
 You then get this (along with all the sub-projects in the
 web-list.txt)
 
 download dave$ ls -1 2.4.3 all_beta.html all_rc.html
 cachedimages common contribute.html download.js
 download2.js download_bouncer.js download_mirrorbrain.js
 exceptions.css globalvars.js index.html languages.js
 md5sums next notes.html other.html print_tables.js
 robots.txt sdk sdk.html source stable.html test
 
 So it's there and it is a matter of wrapping it
 properly.
>>> 
>>> I don't know what you mean with "wrapping". It's working
>>> and with adjustment of CSS (header, footer, graphics, etc.)
>>> and underlaying mirror structure it should run also for
>>> Apache.
 
 Should we start by committing the download site as a
 subsite of our incubator project?
>>> 
>>> The websites inside the incubator project should be
>>> developer-oriented. But the download is nearly 100%
>>> user-related, so I would like to see this content to be
>>> continued on "www.openoffice.org" and not directly in a
>>> Apache domain.
>>> 
>> 
>> I think the point is this:  Even as we preserve the content
>> of the OpenOffice.org website, we're not going to be
>> re-hosting the Mercurial repositories on OO.o.  Everything
>> that was formerly in Mercurial will need to migrate somewhere
>> else, either SVN at Apache or to Hg at Apache-Extras.   The
>> future OO.o website, hosted by Apache will have its source
>> files checked into SVN at Apache.  We'd have a mechanism to
>> publish these files, on modification, to the right directory
>> for the web server.
>> 
>> We'll need a directory structure in SVN that reflects the
>> fact that we'll be storing source files for two websites
>> there.  This is not hard.
> 
> Right. In the SVN repo we have to make the separation of the 2
> domains visible.'
 
 Yes that is very true, but there is a problem. We only have the
 one incubator site in the Apache CMS and we need to do some
 experimental conversions. Let's mix in with our Incubator site
 two initial projects - www and download - as subdirectories so we
 can get started with headers and footers and modifying the CMS
 build to handle the OOo site pages from Kenai.
>>> 
>>> OK, no problem to migratethe webpages into the incubator project.
>>> Tehn we can "play" a bit with the content to see how it behaves.
>>> 
 We can then get started with branding as well.
 
 Later we can change the svn structure to the one that allows
 publishing of multiple sites in Apache. We'll need to discuss the
 publishing of the openoffice domains using the Apache CMS with
 Infrastructure.
>>> 
>>> +1
>> 
>> I have committed the download project to the AOOo svn. No headers and
>> footers yet, but it is now available for "play"
>> 
>> http://incubator.apache.org/openofficeorg/download/index.html
> 
> good start!

http://incubator.apache.org/openofficeorg/www/index.html

Will be there soon. I think I committed more at once than I should. There is a 
lot of deadwood there that should be

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 3:26 PM, Andy Brown  wrote:
> Rob Weir wrote:
>>
>> Another aspect I'd love to see addressed in the proposal:
>>
>> What other roles exist in the wiki?
>>
>> I know about:
>>
>> - Users (which we say may be anyone, provided they identify themselves
>> and agree to the license)
>>
>> - Admins, which as we know need to be committers
>>
>> But any other roles?  Moderators?  Any form of super users?  How are
>> these appointed/approved?  How does the PPMC exercise oversight?
>>
>> -Rob
>>
>
> I will add something on this as well.  Thanks for the info.
>

I poked around and found this page:

http://wiki.services.openoffice.org/wiki/Special:Statistics

This lists some additional roles (with counts)

Administrators (26)
Bureaucrats (4)
Editors (20)
Reviewers (5)

Those are in addition to 35,020 User accounts.

Curiously, it reports only 5 of the 35,020 users as having been active
in the past 7 days.

How we authorize people for these roles and what qualifications are
required for these roles is an important question.

There are a similar set of questions we should ask about the support
forums, what the roles are and how PPMC oversight maps to them.

-Rob

> Andy
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


Rob Weir wrote:

Another aspect I'd love to see addressed in the proposal:

What other roles exist in the wiki?

I know about:

- Users (which we say may be anyone, provided they identify themselves
and agree to the license)

- Admins, which as we know need to be committers

But any other roles?  Moderators?  Any form of super users?  How are
these appointed/approved?  How does the PPMC exercise oversight?

-Rob



I will add something on this as well.  Thanks for the info.

Andy

Re: Converting the repo using mercurial's convert extension

2011-08-02 Thread Christian Lohmaier

On Tue, Aug 2, 2011 at 9:12 PM, Christian Lohmaier  wrote:
> [...]
>> can you list the steps you are following in more detail (even a dump of your
>> term history) and upload the scripts to svn?
>
> I won't upload to svn, as I'm not a committer (and have no intentions
> to sign the iCLA)
>
> But I pasted it here
> http://pastie.org/2310454

Oh, I forgot: While I won't upload it to svn myself, I don't claim any
copyright on this bit of info, so feel free to take it as
Apace-Licensed, LGPL, MPL in whatever present or future versions, as
Public Domain - you get the idea.

ciao
Christian

Re: Converting the repo using mercurial's convert extension

2011-08-02 Thread Christian Lohmaier

Hi Andrew, *,

On Tue, Aug 2, 2011 at 7:27 PM, Andrew Rist  wrote:
> On 8/2/2011 7:25 AM, Christian Lohmaier wrote:
> On Thu, Jul 28, 2011 at 8:42 PM, Jens-Heiner Rechtien 
> wrote:
> On 07/28/2011 04:32 PM, Pedro F. Giffuni wrote:
> --- On Thu, 7/28/11, Christian Lohmaier wrote:
>
> The script to do the mapping is attached [...]
>
> unfortunately attachments don't make it through the listserver.

Sorry, It at lets patches and attached signatures pass, so I was just
hoping a text-attachment would make it as well...

> can you list the steps you are following in more detail (even a dump of your
> term history) and upload the scripts to svn?

I won't upload to svn, as I'm not a committer (and have no intentions
to sign the iCLA)

But I pasted it here
http://pastie.org/2310454

> I'll try to set up a conversion and dumps closer to the source to see how we
> can speed up this process.
> Andrew

So next step here is to create a svn dump, pass it through
svndumpfilter to only keep trunk and populate a new repo with that,
then attempt the hg conversion.
If that fails because svn is "ahead" of mercurial, do the same but
only dump up to the last matched version. That way you still will have
the time-benefit but not all svn's history.

ciao
Christian

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

Another aspect I'd love to see addressed in the proposal:

What other roles exist in the wiki?

I know about:

- Users (which we say may be anyone, provided they identify themselves
and agree to the license)

- Admins, which as we know need to be committers

But any other roles?  Moderators?  Any form of super users?  How are
these appointed/approved?  How does the PPMC exercise oversight?

-Rob

On Tue, Aug 2, 2011 at 2:27 PM, Andy Brown  wrote:
> Dave Fisher wrote:
>>
>> On Aug 2, 2011, at 10:48 AM, Andy Brown wrote:
>>
>>> I work on this and see what I can come up with.  I am no expert on this
>>> so it will be a very rough draft, but something that I fell we will need to
>>> do.  We are much different that the "normal" Apache project so hopefully be
>>> granted some working room.  I will start a new thread as this one is getting
>>> to deep to manage.
>>
>> Please put the word [PROPOSAL] in the subject.
>>
>> I think it should be in the context of openoffice.org site issues as
>> opposed to apache.org issues, I think that may be the best dividing line for
>> the boundary for this "working room".
>
> Thanks for the idea, I will go that way.
>
>>> I am only trying to help all of us to keep a great product where it
>>> belongs.
>>
>> By trying you succeed.
>
> Thanks.
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)




2) We need a credible security mechanism for the wiki.  Today, for
example, it is not required for a user to give their real name (the
field is optional).  And the password can be as little as 1 character.
  (Yup, I just created an account with password="x").  With 15,000
zombie accounts, lack of real names and the ability for users to
create trivially crackable accounts, it would be hard to really
identify a change to a particular person.


Yes on password strength, no on real names.  The key issue here is that 
at some point during either the registration or posting process, the 
account holder / poster actively acknowledges that the contributed 
content falls under whatever licence that is required.  Without formal 
identity verification, there is no material difference between a Monica 
and a claimed name.

Re: How to handle the downloads?

2011-08-02 Thread Kay Schenk




On 08/02/2011 09:05 AM, Dave Fisher wrote:


On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote:


Am 08/02/2011 04:53 PM, schrieb Dave Fisher:


On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote:


Am 08/02/2011 02:15 PM, schrieb Rob Weir:

On Tue, Aug 2, 2011 at 4:03 AM, Marcus
(OOo)wrote:

Am 08/02/2011 03:00 AM, schrieb Dave Fisher:


On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:


Am 08/02/2011 01:00 AM, schrieb Ross Gardler:


On 1 August 2011 23:42, Marcus
(OOo)   wrote:


Am 08/02/2011 12:15 AM, schrieb Ross Gardler:


...


The ASF does not care what your download page
looks like as long as you use the CGI scripts to
ensure that an appropriate mirror site is used.


Hm, let's see how independent the download thing
really will be. ;-)


Why don't you mock-up 9in the CMS) what you want the
download page to look like, without linking it in
from elsewhere. Once that is done then we can look at
making the download.cgi work the way you want it.


Good idea. Will do so.


I have a script for downloading the download web source
from the kenai svn.

If I download the complete AOOo svn tree particularly
ooo/trunk/tools/dev/fetch-all-web.sh

You can run that script like so:

$ ../trunk/tools/dev/fetch-all-web.sh
../trunk/tools/dev/web-list.txt .

You then get this (along with all the sub-projects in the
web-list.txt)

download dave$ ls -1 2.4.3 all_beta.html all_rc.html
cachedimages common contribute.html download.js
download2.js download_bouncer.js download_mirrorbrain.js
exceptions.css globalvars.js index.html languages.js
md5sums next notes.html other.html print_tables.js
robots.txt sdk sdk.html source stable.html test

So it's there and it is a matter of wrapping it
properly.


I don't know what you mean with "wrapping". It's working
and with adjustment of CSS (header, footer, graphics, etc.)
and underlaying mirror structure it should run also for
Apache.


Should we start by committing the download site as a
subsite of our incubator project?


The websites inside the incubator project should be
developer-oriented. But the download is nearly 100%
user-related, so I would like to see this content to be
continued on "www.openoffice.org" and not directly in a
Apache domain.



I think the point is this:  Even as we preserve the content
of the OpenOffice.org website, we're not going to be
re-hosting the Mercurial repositories on OO.o.  Everything
that was formerly in Mercurial will need to migrate somewhere
else, either SVN at Apache or to Hg at Apache-Extras.   The
future OO.o website, hosted by Apache will have its source
files checked into SVN at Apache.  We'd have a mechanism to
publish these files, on modification, to the right directory
for the web server.

We'll need a directory structure in SVN that reflects the
fact that we'll be storing source files for two websites
there.  This is not hard.


Right. In the SVN repo we have to make the separation of the 2
domains visible.'


Yes that is very true, but there is a problem. We only have the
one incubator site in the Apache CMS and we need to do some
experimental conversions. Let's mix in with our Incubator site
two initial projects - www and download - as subdirectories so we
can get started with headers and footers and modifying the CMS
build to handle the OOo site pages from Kenai.


OK, no problem to migratethe webpages into the incubator project.
Tehn we can "play" a bit with the content to see how it behaves.


We can then get started with branding as well.

Later we can change the svn structure to the one that allows
publishing of multiple sites in Apache. We'll need to discuss the
publishing of the openoffice domains using the Apache CMS with
Infrastructure.


+1


I have committed the download project to the AOOo svn. No headers and
footers yet, but it is now available for "play"

http://incubator.apache.org/openofficeorg/download/index.html


good start!



To get headers and footers a template is needed and the view.pm will
need adjustment.

See
http://incubator.apache.org/openofficeorg/website-local.html#directory_layout

 Regards, Dave



Marcus




At least this separation will be established from my point
of view.

Marcus




We still need someone to work with infra@ to ensure
the mirror network can cope with the load, but I'm
sure that will be handled in good time.


Marcus




--

MzK

"If you can keep your head when all others around you
 are losing theirs - maybe you don't fully understand
 the situation!"
-- Unknown

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


Dave Fisher wrote:


On Aug 2, 2011, at 10:48 AM, Andy Brown wrote:


I work on this and see what I can come up with.  I am no expert on this so it will be a 
very rough draft, but something that I fell we will need to do.  We are much different 
that the "normal" Apache project so hopefully be granted some working room.  I 
will start a new thread as this one is getting to deep to manage.


Please put the word [PROPOSAL] in the subject.

I think it should be in the context of openoffice.org site issues as opposed to 
apache.org issues, I think that may be the best dividing line for the boundary for this 
"working room".


Thanks for the idea, I will go that way.


I am only trying to help all of us to keep a great product where it belongs.


By trying you succeed.


Thanks.

Re: OOO340 to svn

2011-08-02 Thread IngridvdM


Am 01.08.2011 23:31, schrieb Eike Rathke:


The Hg archive should simply replicate the current structure at OOo,
also for ease of adding in pending CWSs as branches, so a separate l10n
repository.

Another good argument to separate l10n from trunk was given in an 
earlier thread: This way it is easier for developers to get only what 
they will need usually and spare the extra time and space.


I think this is a good argument and I wonder whether we shouldn't be 
prepared to identify more such stuff - for example the binfilter.


So what I would like to consider is whether we should go with a 
structure like:


ooo/trunk/...
ooo/extras/l10n/...
(ooo/extras/binfilter/... as possibility to add later)

instead of:

ooo/trunk/...
ooo/l10n/...

The name extras is of course open to discuss also.

Opinions?
Ingrid


For SVN I think l10n as sibling to trunk would be best.

   Eike

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


On Aug 2, 2011, at 10:48 AM, Andy Brown wrote:

> Rob Weir wrote:
>> On Tue, Aug 2, 2011 at 12:10 PM, Andy Brown  wrote:
>>> 
>>> If you talking the wiki, instead of requiring an ICLA as a person has to
>>> create an account, why not make it part of that process that "All submitted
>>> contributions are under AL2 license".  Would that not be sufficient?
>>> 
>> 
>> The IPMC guidance, via the Podling Guide that they have published [1] is:
>> 
>> "Podlings may use a wiki to create documentation (including the
>> website) providing that follow the guidelines. In particular, care
>> must be taken to ensure that access to the wiki used to create
>> documentation is restricted to only those with filed CLAs. The PPMC
>> MUST review all changes and ensure that trust is not abused."
>> 
>> I personally like your idea of having a click-through-license grant on
>> the wiki itself, either as part of account creation or on the edit
>> page itself.  But if we did that, I'd suggest some related issues to
>> address:
>> 
>> 1) We shouldn't just ignore IPMC guidance.  There may be some
>> allowance for variation in procedures, but that should not be assumed.
>>  If we want to do something differently, then we need to write up that
>> proposal, get consensus here among PPMC members, and then take it to
>> the IPMC and probably Apache Legal Affairs (to review whatever
>> language we use).  I'd gladly support that.
> 
> I work on this and see what I can come up with.  I am no expert on this so it 
> will be a very rough draft, but something that I fell we will need to do.  We 
> are much different that the "normal" Apache project so hopefully be granted 
> some working room.  I will start a new thread as this one is getting to deep 
> to manage.

Please put the word [PROPOSAL] in the subject.

I think it should be in the context of openoffice.org site issues as opposed to 
apache.org issues, I think that may be the best dividing line for the boundary 
for this "working room".

> 
>> 2) We need a credible security mechanism for the wiki.  Today, for
>> example, it is not required for a user to give their real name (the
>> field is optional).  And the password can be as little as 1 character.
>>  (Yup, I just created an account with password="x").  With 15,000
>> zombie accounts, lack of real names and the ability for users to
>> create trivially crackable accounts, it would be hard to really
>> identify a change to a particular person.
> 
> I do not believe I have seen anyone state that there were not problems with 
> the current setup and improvements could not be made.  This is one area that 
> we really need to look at and fix.
> 
>> [1] http://incubator.apache.org/guides/sites.html
>> 
 2) How do we ensure that the documentation is under PPMC oversight and
 remains high quality?
>>> 
>>> I received a daily report of all changes to the wiki, there is also the
>>> option for "as done" report.  It would only take a few minutes to do a quick
>>> review of those changes, an revert them if needed.
>>> 
>> 
>> OK.  Maybe that report could be directed to the ooo-commits list as well?
> 
> I am sure that is a possibility but if all that use the committers that use 
> the wiki get the reports then we should have that covered without adding to 
> the ooo-commit list.
> 
 I'm open to discussions of various technical and procedural means to
 achieve these goals.  But I am adamant in achieving them one way or
 another.
>>> 
>>> Would the above listed work?
>>> 
>> 
>> I think that takes us in the right direction.  Thanks.
> 
> I am only trying to help all of us to keep a great product where it belongs.

By trying you succeed.

Regards,
Dave


> 
> Andy

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


Rob Weir wrote:

On Tue, Aug 2, 2011 at 12:10 PM, Andy Brown  wrote:


If you talking the wiki, instead of requiring an ICLA as a person has to
create an account, why not make it part of that process that "All submitted
contributions are under AL2 license".  Would that not be sufficient?



The IPMC guidance, via the Podling Guide that they have published [1] is:

"Podlings may use a wiki to create documentation (including the
website) providing that follow the guidelines. In particular, care
must be taken to ensure that access to the wiki used to create
documentation is restricted to only those with filed CLAs. The PPMC
MUST review all changes and ensure that trust is not abused."

I personally like your idea of having a click-through-license grant on
the wiki itself, either as part of account creation or on the edit
page itself.  But if we did that, I'd suggest some related issues to
address:

1) We shouldn't just ignore IPMC guidance.  There may be some
allowance for variation in procedures, but that should not be assumed.
  If we want to do something differently, then we need to write up that
proposal, get consensus here among PPMC members, and then take it to
the IPMC and probably Apache Legal Affairs (to review whatever
language we use).  I'd gladly support that.


I work on this and see what I can come up with.  I am no expert on this 
so it will be a very rough draft, but something that I fell we will need 
to do.  We are much different that the "normal" Apache project so 
hopefully be granted some working room.  I will start a new thread as 
this one is getting to deep to manage.



2) We need a credible security mechanism for the wiki.  Today, for
example, it is not required for a user to give their real name (the
field is optional).  And the password can be as little as 1 character.
  (Yup, I just created an account with password="x").  With 15,000
zombie accounts, lack of real names and the ability for users to
create trivially crackable accounts, it would be hard to really
identify a change to a particular person.


I do not believe I have seen anyone state that there were not problems 
with the current setup and improvements could not be made.  This is one 
area that we really need to look at and fix.



[1] http://incubator.apache.org/guides/sites.html


2) How do we ensure that the documentation is under PPMC oversight and
remains high quality?


I received a daily report of all changes to the wiki, there is also the
option for "as done" report.  It would only take a few minutes to do a quick
review of those changes, an revert them if needed.



OK.  Maybe that report could be directed to the ooo-commits list as well?


I am sure that is a possibility but if all that use the committers that 
use the wiki get the reports then we should have that covered without 
adding to the ooo-commit list.



I'm open to discussions of various technical and procedural means to
achieve these goals.  But I am adamant in achieving them one way or
another.


Would the above listed work?



I think that takes us in the right direction.  Thanks.


I am only trying to help all of us to keep a great product where it belongs.

Andy

Re: Converting the repo using mercurial's convert extension

2011-08-02 Thread Andrew Rist





On 8/2/2011 7:25 AM, Christian Lohmaier wrote:

Hi Heiner, *,

On Thu, Jul 28, 2011 at 8:42 PM, Jens-Heiner Rechtien  wrote:

On 07/28/2011 04:32 PM, Pedro F. Giffuni wrote:

--- On Thu, 7/28/11, Christian Lohmaier wrote:
...

[1] Note that with the map, it would also be possible to
reuse the old OOo-Subversion repo for the linear commits,
after all the hg repo was a conversion from the svn server.
This would save quite a bit of time.

I like this idea ... if the old SVN server is still available
and we can do a progressive conversion of the rest of the Hg
stuff we will save a lot of metadata that had previously been
lost (plus we save conversion time).

It's still available: http://svn.services.openoffice.org/ooo resp.
svn://svn.services.openoffice.org/ooo

You can use svnsync to create a local copy of the rep. Will take a while :-)

Yes, takes almost two days - would have been easier if there was a dump :-)

Now good thing: mapping the revisions works, and is completed on a
slow machine in 10 minutes.
Bad thing: I couldn't test the import with the plain repo, as hg
convert wants a *full* checkout of the repo, not just trunk, and that
doesn't fit in the 100GB I have available[1], so I'm now creating a
dump to run through svndumpfilter to only preserve trunk and retry
with that shrunk repo. (

The script to do the mapping is attached

unfortunately attachments don't make it through the listserver.
can you list the steps you are following in more detail (even a dump of 
your term history) and upload the scripts to svn?
I'll try to set up a conversion and dumps closer to the source to see 
how we can speed up this process.

Andrew

, it will create the mapping
that can be used as hg-shamap to kickstart the conversing skipping the
first 263205 revision, thus saving way more than 20 days of conversion
time :-)

So while the process won't work with the pristine copy of the pristine
svn copy, it can still be used as basis for the conversion when
filtered to only include trunk, as all the linear revisions are
matched in trunk.

[1] the svn repo contains 984 cws - and when you assume just 1 GB per
cws for simplicity, you would need 1TB of storage to just do the
conversion. and svn needs loads of RAM to perform the checkout - the
1GB of real RAM and 1GB of RAM was all occupied by svn, and after
filling the 100GB a mere 12MB were free, so even with enough storage
capacity, the amount of RAM probably would not have been sufficient
for a full checkout...

ciao
Christian

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 12:54 PM, Dennis E. Hamilton
 wrote:
> I'm not sure we are all talking about the same documentation.  I suppose the 
> OOODEV wiki is the appropriate place to be doing that documentation, whatever 
> it is, that is intended in the guidelines.
>

I'm thinking of these things that are necessary for anyone to make use
of the product. The core documentation.  A look around other Apache
projects would give some idea of what that doc is, at least from a
developer's perspective.  But there is analogous doc requirements for
users, admins and app developers.  Honestly, I think most of what we
call doc is "core doc".

> When we see the equivalent on OpenOffice.org, we should, on a per-case basis, 
> redirect it to OOODEV perhaps.
>

I don't think we want to move content across different wiki
applications.  I'd be happy to delete OOODEV and stick with MediaWiki
for both wikis.  That would give us some consistency in look and feel.
 It would also allow the public wiki to be a sandbox or lab where
anyone could propose and develop new doc sets.  As the doc matured, it
could then me integrated into the official doc and maintained from
there.  If we have a consistent license and markup, we can do things
like that.

> But we do need to get to specific cases and handle them individually.
>

Agreed.  We'll learn by doing as well.

> For a general-public editable wiki, I think sticking with the Creative 
> Commons Attribution license should be just fine where it is already supplied. 
>  More people seem to know what that is, and it is fully permissive without 
> what appears to be such high ceremony as the ALv2.
>

I disagree.  Let me explain why.  The wiki currently holds a lot of
detailed plans and designs for future features.  So it is used for
project planning and technical design.  See, for example:

http://wiki.services.openoffice.org/wiki/Calc/Features/Multi-range_copy_and_paste

There are also pages with more detailed designs, including embedded source code:

http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions#formula.2Finc.2Fformula.2Fcompiler.hrc

So it is very possible that patentable methods and copyrighted source
code could migrate directly from the wiki into project source code.
It is prudent to ensure that those who contribute to these wiki pages
are making the necessary assertions with regards to any IP involved.
This is no different than the agreements you and I made when deciding
to work on standards at OASIS.  Even though it is just "documentation"
that documentation is the blueprint for software, and as such has IP
implications.

Of course, the alternate way is to move these pages and those like it
into a project-wiki which is only writable by those who have returned
the iCLA.

> And we should look around at some of the TLP project wikis that allow public 
> contributions.
>

Pass along some links if you find some good examples.

-Rob

>  - Dennis
>
> -Original Message-
> From: Rob Weir [mailto:apa...@robweir.com]
> Sent: Tuesday, August 02, 2011 09:28
> To: ooo-dev@incubator.apache.org
> Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
> re:OpenOffice.org branding)
>
> On Tue, Aug 2, 2011 at 12:10 PM, Andy Brown  wrote:
>> Rob Weir wrote:
>>
>>> At Apache, every committer has the ability to veto a change.  Not just
>>> me.  Far from it.
>>
>> True.
>>
>>> In any case, in order to move the argument forward, I'd like to
>>> reiterate thecific concerns that I have, to which I've seen no
>>> response other than "we don't want to change".  But no one is
>>> addressing the fundamental questions:
>>>
>>> 1) How do we ensure that the future documentation is under the Apache
>>> 2.0 license so that it can be copied, modified and redistributed
>>> freely by others?
>>
>> If you talking the wiki, instead of requiring an ICLA as a person has to
>> create an account, why not make it part of that process that "All submitted
>> contributions are under AL2 license".  Would that not be sufficient?
>>
>
> The IPMC guidance, via the Podling Guide that they have published [1] is:
>
> "Podlings may use a wiki to create documentation (including the
> website) providing that follow the guidelines. In particular, care
> must be taken to ensure that access to the wiki used to create
> documentation is restricted to only those with filed CLAs. The PPMC
> MUST review all changes and ensure that trust is not abused."
>
> I personally like your idea of having a click-through-license grant on
> the wiki itself, either as part of account creation or on the edit
> page itself.  But if we did that, I'd suggest some related issues to
> address:
>
> 1) We shouldn't just ignore IPMC guidance.  There may be some
> allowance for variation in procedures, but that should not be assumed.
>  If we want to do something differently, then we need to write up that
> proposal, get consensus here among PPMC members, and then take it to
> the IPMC and probably Apache

Re: How to handle the downloads?


Am 08/02/2011 06:05 PM, schrieb Dave Fisher:


On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote:


Am 08/02/2011 04:53 PM, schrieb Dave Fisher:


On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote:


Am 08/02/2011 02:15 PM, schrieb Rob Weir:

On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)wrote:

Am 08/02/2011 03:00 AM, schrieb Dave Fisher:


On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:


Am 08/02/2011 01:00 AM, schrieb Ross Gardler:


On 1 August 2011 23:42, Marcus (OOo)   wrote:


Am 08/02/2011 12:15 AM, schrieb Ross Gardler:


...


The ASF does not care what your download page looks like as long as
you use the CGI scripts to ensure that an appropriate mirror site is
used.


Hm, let's see how independent the download thing really will be. ;-)


Why don't you mock-up 9in the CMS) what you want the download page to
look like, without linking it in from elsewhere. Once that is done
then we can look at making the download.cgi work the way you want it.


Good idea. Will do so.


I have a script for downloading the download web source from the kenai
svn.

If I download the complete AOOo svn tree particularly
ooo/trunk/tools/dev/fetch-all-web.sh

You can run that script like so:

$ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt .

You then get this (along with all the sub-projects in the web-list.txt)

download dave$ ls -1
2.4.3
all_beta.html
all_rc.html
cachedimages
common
contribute.html
download.js
download2.js
download_bouncer.js
download_mirrorbrain.js
exceptions.css
globalvars.js
index.html
languages.js
md5sums
next
notes.html
other.html
print_tables.js
robots.txt
sdk
sdk.html
source
stable.html
test

So it's there and it is a matter of wrapping it properly.


I don't know what you mean with "wrapping". It's working and with adjustment
of CSS (header, footer, graphics, etc.) and underlaying mirror structure it
should run also for Apache.


Should we start by committing the download site as a subsite of our
incubator project?


The websites inside the incubator project should be developer-oriented. But
the download is nearly 100% user-related, so I would like to see this
content to be continued on "www.openoffice.org" and not directly in a Apache
domain.



I think the point is this:  Even as we preserve the content of the
OpenOffice.org website, we're not going to be re-hosting the Mercurial
repositories on OO.o.  Everything that was formerly in Mercurial will
need to migrate somewhere else, either SVN at Apache or to Hg at
Apache-Extras.   The future OO.o website, hosted by Apache will have
its source files checked into SVN at Apache.  We'd have a mechanism to
publish these files, on modification, to the right directory for the
web server.

We'll need a directory structure in SVN that reflects the fact that
we'll be storing source files for two websites there.  This is not
hard.


Right. In the SVN repo we have to make the separation of the 2 domains visible.'


Yes that is very true, but there is a problem. We only have the one incubator 
site in the Apache CMS and we need to do some experimental conversions. Let's 
mix in with our Incubator site two initial projects - www and download - as 
subdirectories so we can get started with headers and footers and modifying the 
CMS build to handle the OOo site pages from Kenai.


OK, no problem to migratethe webpages into the incubator project. Tehn we can 
"play" a bit with the content to see how it behaves.


We can then get started with branding as well.

Later we can change the svn structure to the one that allows publishing of 
multiple sites in Apache. We'll need to discuss the publishing of the 
openoffice domains using the Apache CMS with Infrastructure.


+1


I have committed the download project to the AOOo svn. No headers and footers yet, but it 
is now available for "play"

http://incubator.apache.org/openofficeorg/download/index.html

To get headers and footers a template is needed and the view.pm will need 
adjustment.

See 
http://incubator.apache.org/openofficeorg/website-local.html#directory_layout


The nice CSS styling was was done somehow "bekind" the Kenai framework. 
Not that easy to find all that stuff and to re-implement the basics. But 
let's see...


Thanks for your fast commit. :-)

Marcus




At least this separation will be established from my point of view.

Marcus




We still need someone to work with infra@ to ensure the mirror network
can cope with the load, but I'm sure that will be handled in good
time.


Marcus

RE: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

I'm not sure we are all talking about the same documentation.  I suppose the 
OOODEV wiki is the appropriate place to be doing that documentation, whatever 
it is, that is intended in the guidelines.

When we see the equivalent on OpenOffice.org, we should, on a per-case basis, 
redirect it to OOODEV perhaps.

But we do need to get to specific cases and handle them individually.

For a general-public editable wiki, I think sticking with the Creative Commons 
Attribution license should be just fine where it is already supplied.  More 
people seem to know what that is, and it is fully permissive without what 
appears to be such high ceremony as the ALv2.

And we should look around at some of the TLP project wikis that allow public 
contributions.

 - Dennis

-Original Message-
From: Rob Weir [mailto:apa...@robweir.com] 
Sent: Tuesday, August 02, 2011 09:28
To: ooo-dev@incubator.apache.org
Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 12:10 PM, Andy Brown  wrote:
> Rob Weir wrote:
>
>> At Apache, every committer has the ability to veto a change.  Not just
>> me.  Far from it.
>
> True.
>
>> In any case, in order to move the argument forward, I'd like to
>> reiterate thecific concerns that I have, to which I've seen no
>> response other than "we don't want to change".  But no one is
>> addressing the fundamental questions:
>>
>> 1) How do we ensure that the future documentation is under the Apache
>> 2.0 license so that it can be copied, modified and redistributed
>> freely by others?
>
> If you talking the wiki, instead of requiring an ICLA as a person has to
> create an account, why not make it part of that process that "All submitted
> contributions are under AL2 license".  Would that not be sufficient?
>

The IPMC guidance, via the Podling Guide that they have published [1] is:

"Podlings may use a wiki to create documentation (including the
website) providing that follow the guidelines. In particular, care
must be taken to ensure that access to the wiki used to create
documentation is restricted to only those with filed CLAs. The PPMC
MUST review all changes and ensure that trust is not abused."

I personally like your idea of having a click-through-license grant on
the wiki itself, either as part of account creation or on the edit
page itself.  But if we did that, I'd suggest some related issues to
address:

1) We shouldn't just ignore IPMC guidance.  There may be some
allowance for variation in procedures, but that should not be assumed.
 If we want to do something differently, then we need to write up that
proposal, get consensus here among PPMC members, and then take it to
the IPMC and probably Apache Legal Affairs (to review whatever
language we use).  I'd gladly support that.

2) We need a credible security mechanism for the wiki.  Today, for
example, it is not required for a user to give their real name (the
field is optional).  And the password can be as little as 1 character.
 (Yup, I just created an account with password="x").  With 15,000
zombie accounts, lack of real names and the ability for users to
create trivially crackable accounts, it would be hard to really
identify a change to a particular person.

[1] http://incubator.apache.org/guides/sites.html

>> 2) How do we ensure that the documentation is under PPMC oversight and
>> remains high quality?
>
> I received a daily report of all changes to the wiki, there is also the
> option for "as done" report.  It would only take a few minutes to do a quick
> review of those changes, an revert them if needed.
>

OK.  Maybe that report could be directed to the ooo-commits list as well?

>> I'm open to discussions of various technical and procedural means to
>> achieve these goals.  But I am adamant in achieving them one way or
>> another.
>
> Would the above listed work?
>

I think that takes us in the right direction.  Thanks.

> Andy
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 12:10 PM, Andy Brown  wrote:
> Rob Weir wrote:
>
>> At Apache, every committer has the ability to veto a change.  Not just
>> me.  Far from it.
>
> True.
>
>> In any case, in order to move the argument forward, I'd like to
>> reiterate thecific concerns that I have, to which I've seen no
>> response other than "we don't want to change".  But no one is
>> addressing the fundamental questions:
>>
>> 1) How do we ensure that the future documentation is under the Apache
>> 2.0 license so that it can be copied, modified and redistributed
>> freely by others?
>
> If you talking the wiki, instead of requiring an ICLA as a person has to
> create an account, why not make it part of that process that "All submitted
> contributions are under AL2 license".  Would that not be sufficient?
>

The IPMC guidance, via the Podling Guide that they have published [1] is:

"Podlings may use a wiki to create documentation (including the
website) providing that follow the guidelines. In particular, care
must be taken to ensure that access to the wiki used to create
documentation is restricted to only those with filed CLAs. The PPMC
MUST review all changes and ensure that trust is not abused."

I personally like your idea of having a click-through-license grant on
the wiki itself, either as part of account creation or on the edit
page itself.  But if we did that, I'd suggest some related issues to
address:

1) We shouldn't just ignore IPMC guidance.  There may be some
allowance for variation in procedures, but that should not be assumed.
 If we want to do something differently, then we need to write up that
proposal, get consensus here among PPMC members, and then take it to
the IPMC and probably Apache Legal Affairs (to review whatever
language we use).  I'd gladly support that.

2) We need a credible security mechanism for the wiki.  Today, for
example, it is not required for a user to give their real name (the
field is optional).  And the password can be as little as 1 character.
 (Yup, I just created an account with password="x").  With 15,000
zombie accounts, lack of real names and the ability for users to
create trivially crackable accounts, it would be hard to really
identify a change to a particular person.

[1] http://incubator.apache.org/guides/sites.html

>> 2) How do we ensure that the documentation is under PPMC oversight and
>> remains high quality?
>
> I received a daily report of all changes to the wiki, there is also the
> option for "as done" report.  It would only take a few minutes to do a quick
> review of those changes, an revert them if needed.
>

OK.  Maybe that report could be directed to the ooo-commits list as well?

>> I'm open to discussions of various technical and procedural means to
>> achieve these goals.  But I am adamant in achieving them one way or
>> another.
>
> Would the above listed work?
>

I think that takes us in the right direction.  Thanks.

> Andy
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Terry Ellison


Rob,

Let us take a time-out on this one.  Some of these points are best 
clarified off DL before coming back here; some are noise; and some are 
sufficiently important to be considered properly before being raised as 
threads in their own right rather than buried 20 replies down in a 
thread on "Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
re:OpenOffice.org branding)".


Terry

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


Rob Weir wrote:


At Apache, every committer has the ability to veto a change.  Not just
me.  Far from it.


True.


In any case, in order to move the argument forward, I'd like to
reiterate thecific concerns that I have, to which I've seen no
response other than "we don't want to change".  But no one is
addressing the fundamental questions:

1) How do we ensure that the future documentation is under the Apache
2.0 license so that it can be copied, modified and redistributed
freely by others?


If you talking the wiki, instead of requiring an ICLA as a person has to 
create an account, why not make it part of that process that "All 
submitted contributions are under AL2 license".  Would that not be 
sufficient?



2) How do we ensure that the documentation is under PPMC oversight and
remains high quality?


I received a daily report of all changes to the wiki, there is also the 
option for "as done" report.  It would only take a few minutes to do a 
quick review of those changes, an revert them if needed.



I'm open to discussions of various technical and procedural means to
achieve these goals.  But I am adamant in achieving them one way or
another.


Would the above listed work?

Andy

Re: How to handle the downloads?


On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote:

> Am 08/02/2011 04:53 PM, schrieb Dave Fisher:
>> 
>> On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote:
>> 
>>> Am 08/02/2011 02:15 PM, schrieb Rob Weir:
 On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)   wrote:
> Am 08/02/2011 03:00 AM, schrieb Dave Fisher:
>> 
>> On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:
>> 
>>> Am 08/02/2011 01:00 AM, schrieb Ross Gardler:
 
 On 1 August 2011 23:42, Marcus (OOo)  wrote:
> 
> Am 08/02/2011 12:15 AM, schrieb Ross Gardler:
 
 ...
 
>> The ASF does not care what your download page looks like as long as
>> you use the CGI scripts to ensure that an appropriate mirror site is
>> used.
> 
> Hm, let's see how independent the download thing really will be. ;-)
 
 Why don't you mock-up 9in the CMS) what you want the download page to
 look like, without linking it in from elsewhere. Once that is done
 then we can look at making the download.cgi work the way you want it.
>>> 
>>> Good idea. Will do so.
>> 
>> I have a script for downloading the download web source from the kenai
>> svn.
>> 
>> If I download the complete AOOo svn tree particularly
>> ooo/trunk/tools/dev/fetch-all-web.sh
>> 
>> You can run that script like so:
>> 
>> $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt .
>> 
>> You then get this (along with all the sub-projects in the web-list.txt)
>> 
>> download dave$ ls -1
>> 2.4.3
>> all_beta.html
>> all_rc.html
>> cachedimages
>> common
>> contribute.html
>> download.js
>> download2.js
>> download_bouncer.js
>> download_mirrorbrain.js
>> exceptions.css
>> globalvars.js
>> index.html
>> languages.js
>> md5sums
>> next
>> notes.html
>> other.html
>> print_tables.js
>> robots.txt
>> sdk
>> sdk.html
>> source
>> stable.html
>> test
>> 
>> So it's there and it is a matter of wrapping it properly.
> 
> I don't know what you mean with "wrapping". It's working and with 
> adjustment
> of CSS (header, footer, graphics, etc.) and underlaying mirror structure 
> it
> should run also for Apache.
>> 
>> Should we start by committing the download site as a subsite of our
>> incubator project?
> 
> The websites inside the incubator project should be developer-oriented. 
> But
> the download is nearly 100% user-related, so I would like to see this
> content to be continued on "www.openoffice.org" and not directly in a 
> Apache
> domain.
> 
 
 I think the point is this:  Even as we preserve the content of the
 OpenOffice.org website, we're not going to be re-hosting the Mercurial
 repositories on OO.o.  Everything that was formerly in Mercurial will
 need to migrate somewhere else, either SVN at Apache or to Hg at
 Apache-Extras.   The future OO.o website, hosted by Apache will have
 its source files checked into SVN at Apache.  We'd have a mechanism to
 publish these files, on modification, to the right directory for the
 web server.
 
 We'll need a directory structure in SVN that reflects the fact that
 we'll be storing source files for two websites there.  This is not
 hard.
>>> 
>>> Right. In the SVN repo we have to make the separation of the 2 domains 
>>> visible.'
>> 
>> Yes that is very true, but there is a problem. We only have the one 
>> incubator site in the Apache CMS and we need to do some experimental 
>> conversions. Let's mix in with our Incubator site two initial projects - www 
>> and download - as subdirectories so we can get started with headers and 
>> footers and modifying the CMS build to handle the OOo site pages from Kenai.
> 
> OK, no problem to migratethe webpages into the incubator project. Tehn we can 
> "play" a bit with the content to see how it behaves.
> 
>> We can then get started with branding as well.
>> 
>> Later we can change the svn structure to the one that allows publishing of 
>> multiple sites in Apache. We'll need to discuss the publishing of the 
>> openoffice domains using the Apache CMS with Infrastructure.
> 
> +1

I have committed the download project to the AOOo svn. No headers and footers 
yet, but it is now available for "play"

http://incubator.apache.org/openofficeorg/download/index.html

To get headers and footers a template is needed and the view.pm will need 
adjustment.

See 
http://incubator.apache.org/openofficeorg/website-local.html#directory_layout

Regards,
Dave

> 
> Marcus
> 
> 
> 
> At least this separation will be established from my point of view.
> 
> Marcus
> 
> 
> 
 We still need someone to work with infra@ to ensure the mirror network
 can cope with the load, bu

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Regina Henschel


Hi Rob,

(comments inline)

Rob Weir schrieb:

On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  wrote:

On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:

I'd look at it like this:  The documentation that is needed for our
users to be successful with our product, from end users, to admins, to
application developers, that documentation is product documentation.
If having it deleted or defaced, without us noticing it, would cause
our users some harm, then it is product documentation.  If the right
to copy, modify and redistribute the documentation is essentially to
successful creating and hosting a new port or translation, or even a
commercial derivative or an open source fork, of the project, then it
is product documentation.


Leaving aside for the moment all the other user-doc type items on the
wiki, and looking specifically at the existing current set of user
guides (which are in ODT/PDF format, but made available for download
from the existing OOo wiki), I'm unclear how they will fit into this.
They are not currently under the Apache license, and we would never be
able to track down all the contributors to get them to agree to the
license and/or sign the iCLA. So are we talking only about future
updates to these docs? And if so, do you mean that every future
contributor to these guides during their production must sign the iCLA?
Or just that only someone with suitable access rights (committer?) can
put them on the wiki (in ODT/PDF format)? Or something else?



I'd like us to treat documentation like we do code.  Not necessarily
the same tools, but the same care for provenance, accountability and
quality, namely:

1) We welcome "patches" and "contributions" from anyone, but these
must be first reviewed and approved by a project committer before they
become part of the documentation set.


I don't agree. It is the nature of a wiki, that the content is not 
approved before, but by ongoing editing.


  Any such contributions must be

made under Apache 2.0 license.


In http://www.ooowiki.de/ we have the license information on the start 
page and in the header of each editing mode page. Submitting a change 
automatically agrees to the license. Wouldn't it be possible to do it 
the same with the Apache 2.0 license?




2) Only project committers have direct write access to the
documentation.  This requires that they first sign the iCLA.


That is a very formal action. So most people will not do it. But they 
might write some tips and tutorials.




3) All contributions, whether from the public or from committers and
tracked/logged, so we can accurately determine who made a given
change.  So no anonymous or pseudonymous patches.  A user id that we
can trace to a real email address is fine.


Isn't it possible to set up the wiki in a way, that only registered 
users can write? That is already a hurdle, but I would accept it.




With code this works by non-committer contributors sending patches
(diffs) to the mailing list, where they are merged in and reviewed by
a committer, and then checked into the repository.


That is fine for all things, which belong to the product binaries and to 
the sources, but not for the wiki content.


  With

documentation, using a wiki , we would need a different mechanism for
achieving this.  Luckily there are MediaWiki extensions to enable
this.

I'd like to preserve the immediate nature of editing on the wiki.
That is its strength.  But we need to find away to also get this under
project oversight as well.  I think we can do both, without too much
annoyance to contributors.


We need no such formal mechanism like signing up a iCLA, but groups of 
people who feel responsible for special parts of the wiki. For example, 
compare the pages belonging to 
http://en.wikipedia.org/wiki/Portal:Statistics with the corresponding 
ones in other languages. The better quality of the English ones are not 
due to a formal mechanism of contribution and pre-approving, but because 
the people in the group 
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Statistics care for 
the pages. It is still possible for everyone to edit the content of the 
wiki pages.


Kind regards
Regina

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 11:21 AM, Dennis E. Hamilton
 wrote:
> +1
>
> All wikis that accept public contributions (which is essentially all 
> interesting wikis) must be curated.  Ward Cunningham has provided the 
> definitive exposition about that.
>
> I am sure we can find responsible contributors who will be eager to do that.  
> Maybe some will need administrative access rights and we can require them to 
> be project committers as part of the extension of PPMC oversight and 
> responsibility.
>
> But with regard to contributions of documentation pages, forums, FAQ, etc., 
> the more extended-community involvement that is encouraged by low-friction 
> means, the better.
>

I think that is the key piece, determining what are the essential
documentation pieces (the pieces without which the project cannot
function and the users cannot make use of the releases) versus the
broader universe of supplemental material.

I hope we agree that there is some core part of the documentation set
that the project must provide more direct oversight of, and which we
need to ensure is under a license that permits downstream consumers to
copy, modify and redistribute.

That's all I'm asking for.  That we treat the core documentation as an
essential project asset and use those procedures that we routinely
apply to core project assets.

> In addition, wiki operation is very much in the Apache spirit already - there 
> is no change that can't be reverted (and, in many cases, the reversion 
> consists of moving a copy of an earlier version to be most-recent also, so 
> history is never lost).  I have seen Wikipedia lose history, but I assume 
> that there are ways to avoid that with Wikimedia if we are careful.
>

It is funny when you read Obama's biography one day and read that he
was born in 1712.  It is not funny when you read an OpenOffice wiki
page and a see DOS command that instructs the unwary user to delete
their windows/system directory.

We need to make it clear what is core, trusted documentation versus
other supplemental material that we put a disclaimer on.  Untrusted,
unreviewed doc can do just as much damage as untrusted, unreviewed
code.

> I think this can be worked out as we bring up openoffice.org with hosting on 
> Apache infrastructure.  We do not need a one-size-fits-all autocratic 
> solution.
>

We need two sizes, right:  1) core documentation  and 2) supplemental.
 That was the idea if having two wikis in the first place.

-Rob

>  - Dennis
>
> -Original Message-
> From: Reizinger Zoltán [mailto:zreizin...@hdsnet.hu]
> Sent: Tuesday, August 02, 2011 07:45
> To: ooo-dev@incubator.apache.org
> Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
> re:OpenOffice.org branding)
>
> 2011.08.02. 15:47 keltezéssel, Rob Weir írta:
>> On Tue, Aug 2, 2011 at 9:17 AM, Reizinger Zoltán  
>> wrote:
>>> 2011.08.02. 14:03 keltezéssel, Rob Weir írta:
 On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber
   wrote:
> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>> I'd look at it like this:  The documentation that is needed for our
>> users to be successful with our product, from end users, to admins, to
>> application developers, that documentation is product documentation.
>> If having it deleted or defaced, without us noticing it, would cause
>> our users some harm, then it is product documentation.  If the right
>> to copy, modify and redistribute the documentation is essentially to
>> successful creating and hosting a new port or translation, or even a
>> commercial derivative or an open source fork, of the project, then it
>> is product documentation.
> Leaving aside for the moment all the other user-doc type items on the
> wiki, and looking specifically at the existing current set of user
> guides (which are in ODT/PDF format, but made available for download
> from the existing OOo wiki), I'm unclear how they will fit into this.
> They are not currently under the Apache license, and we would never be
> able to track down all the contributors to get them to agree to the
> license and/or sign the iCLA. So are we talking only about future
> updates to these docs? And if so, do you mean that every future
> contributor to these guides during their production must sign the iCLA?
> Or just that only someone with suitable access rights (committer?) can
> put them on the wiki (in ODT/PDF format)? Or something else?
>
 I'd like us to treat documentation like we do code.  Not necessarily
 the same tools, but the same care for provenance, accountability and
 quality, namely:

 1) We welcome "patches" and "contributions" from anyone, but these
 must be first reviewed and approved by a project committer before they
 become part of the documentation set.  Any such contributions must be
 made under Apache 2.0 license.

 2) Only project committers have direct write acces

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Shane Curcuru


A few comments and suggestions from a mentor.

On 8/1/2011 9:48 PM, Dave Fisher wrote:





There are so many points and counterpoints about new/old and
easy/hard.

I think we need guidance about the migration. We need to state what
we want to do given the strong and understandable push to preserve
the Wiki, forums, and user downloads of the legacy code.


Personally, I'd suggest that a few of the committers who can actually do 
the work here start taking chunks of it, making more concrete 
[PROPOSAL]s, and start working with infra@ and this list on how to do 
those specific tasks.  Break some of the bits off into manageable chunks 
and make progress on them.


A key point with meritocracies is that the people *doing* the work 
(effectively) get to decide.  It feels like a number of threads recently 
are either discussing various details without having more concrete 
proposals, or are being driven by non-committers who are discussing ways 
that the project *won't* work.


This community - in general, everyone on ooo-dev@, but more specifically 
the committers and PPMC - need to focus on specific ways that the 
project *will* work.



WIth the goal of preserving the existing community knowledge base, we
need to know that it is OK for us to consider doing the following
with the openoffice.org domain site on Foundation hardware.

(1) Make sure that we are addressing any concerns about hosting the
user forums on an openoffice.org domain - hosted on an Apache Jail.


Simply hosting it mostly staticly: just figure out the IP issues of 
hosting (what seems to be a significant amount of) content that is not 
under the AL (Apache License).


The whole concept of this large amount of community-driven wiki content 
(i.e. from people not likely to sign iCLAs) really deserves it's own 
separate thread.  In particular, figuring out how the community will 
plan to manage new updates to the community wiki (i.e., either ensuring 
that we have iCLAs or equivalent on all new contributions, or not).


Note: has anyone investigated other Apache wikis and how they manage 
contributions from non-committers?  There are plenty that do that already.




(2) Allow the MediaWiki to exist as much as possible under its
current terms for existing content, and under Apache terms for new
content - hosted on an Apache Jail.


A question for this list and for infra@ (in terms of what the Apache 
infrastructure team is able and willing to physically host).  The best 
approach is to figure out more concretely what the ooo podling wants, 
and then work with infra@ to get it.




(3) Host the old Oracle and Sun releases on download.openoffice.org
through the Apache Mirror system even though they are not AL 2.0.

Are these good questions to ask the Board in our report? Or should we
be looking for guidance on legal-discuss.


Heh, sorry, no, these are not questions to ask the board!  These are 
things for *this* project to figure out - first step 1) what you want to 
do, and then step 2) how you can do it.  Step 2) presumably requires 
talking with legal-discuss@ and infrastructure@ to get specific advice.


If there are significant IP risks with what you're publishing on Apache 
servers today, or if there are unresolvable conflicts within the PPMC, 
then include things like that as "issues for the board".


The board is here to provide the oversight to ensure the Foundation as a 
whole is running smoothly.  The board has appointed a number of specific 
officers or committees who can help with all of these questions - like 
VP, Legal, the Infrastructure team, Branding, and even just the 
Incubator PMC (and your mentors) that can provide guidance on who to ask 
for help on different issues.




We would certainly be very sure that it would very difficult for
misunderstanding that these are NOT Apache releases.

Regards, Dave


Good questions though!

- Shane

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 10:39 AM, Terry Ellison  wrote:
> Rob,
>
> I think that you've missed my point.  The guy didn't THREATEN to leave.  He
> HAS left.  I doubt we will get him back.  My strong reaction was because of
> that entirely avoidable loss of 5+ man-years of project expertise that we
> will be pressed to recover for the sake on an ill-considered shout-down.
>  Was this really wise?
>

No, I do not think it was wise of him to leave.  But, in the end, that
is his choice.  Participating in an open source project, where views
can be aired freely, is not for everyone.  You need the ability to air
opinions and proposals an discuss them respectfully,  But you should
never feel that an idea is unable to be discussed, or that other
members will threaten to leave because someone disagrees with them, or
if they find that their ideas are not loved.  That would only stifle
the free expression of views from other project members.

> Yes, I have only been on the DL for two days, but I have been a major
> contributor to community side of the OOo project for five years.  And in my
> 30+ years in this business, I've seen lots of f***ed up project take-overs
> in my business unit.  I was trying to flag up that this old dog is starting
> to sniff another one, and I would REALLY like to prevent this happening.
>

I assume that the project starts with a random assortment of prior OOo
members, members of related projects, members of other Apache
projects, members of the OASIS ODF standards committees, as well as
some new members "kicking the tires" to see what all the noise is
about.  Some of them will find that this project is not to their
liking.  Some will.  We should try to make this project be inviting to
new members, as well as old members.  But I suspect that incremental
growth will come mainly from new members.

But please tell me, what do you expect I should do when you or anyone
else repeatedly reads your resume to me?  Should I not be allowed to
question proposals?  Should it be considered rude to suggest
alternatives?  Should I feel that it would be in imposition to ask
"why?"  Should I feel that if I don't do exactly what you want,
without question, that you will leave the project?   Really?  Is that
the type of project you would want to work on?  Is that the type of
project that will best attract more contributors?

In terms of project structure and oversight, Apache OpenOffice is a
fresh start.  No one inherits their titles from the legacy project.
No questions are out of bounds.  Nothing is above question.  Yes, of
course, we shouldn't make arbitrary changes, without good reason, just
for the fun of it.  But where something did not work well before, like
achieving a consistent license on the documentation, then we should be
looking at making necessary changes.

And remember, we also have fewer code contributors today, because
there are some developers who are not willing to sign the iCLA or
agree with the Apache 2.0 license.  Should we change that requirement
as well?  I don't think so.  This is an Apache project.  The license
is not negotiable, even though that necessarily means that there will
be some who, for whatever personal reasons and beliefs they honestly
hold, will not be able to participate.

> You seem to be positioning yourself as the project leader and absolute
> arbiter of Apache policy, and YOU have caused a valuable asset to this
> project to walk, yet you seem to be totally unaware of this -- or are and
> don't care.  If we keep this up then this Apache project will drive away
> many if not most of the ex-OOo team who want to contribute.  You'll be left
> with an extremely tidy and well-managed DL but no OpenOffice product.
>

Starting an ad hominen attack does not do credit you or your arguments.

At Apache, every committer has the ability to veto a change.  Not just
me.  Far from it.

In any case, in order to move the argument forward, I'd like to
reiterate the specific concerns that I have, to which I've seen no
response other than "we don't want to change".  But no one is
addressing the fundamental questions:

1) How do we ensure that the future documentation is under the Apache
2.0 license so that it can be copied, modified and redistributed
freely by others?

2) How do we ensure that the documentation is under PPMC oversight and
remains high quality?

I'm open to discussions of various technical and procedural means to
achieve these goals.  But I am adamant in achieving them one way or
another.

> If this is the Apache way, then this will be a sad outcome.  But is this the
> Apache way or just your individual interpretation?  I do wonder what is the
> biggest project that you've run personally, or have you even done this
> before?
>

Did you read the link I sent on decision making at Apache?  Did you
have any questions on it?  If you actually read it, I don't think you
could possibly be asking the above question.

> Regards Terry
>
> On 02/08/11 14:40, Rob Weir wrote:
>>
>> On

RE: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

+1

All wikis that accept public contributions (which is essentially all 
interesting wikis) must be curated.  Ward Cunningham has provided the 
definitive exposition about that.

I am sure we can find responsible contributors who will be eager to do that.  
Maybe some will need administrative access rights and we can require them to be 
project committers as part of the extension of PPMC oversight and 
responsibility.

But with regard to contributions of documentation pages, forums, FAQ, etc., the 
more extended-community involvement that is encouraged by low-friction means, 
the better.  

In addition, wiki operation is very much in the Apache spirit already - there 
is no change that can't be reverted (and, in many cases, the reversion consists 
of moving a copy of an earlier version to be most-recent also, so history is 
never lost).  I have seen Wikipedia lose history, but I assume that there are 
ways to avoid that with Wikimedia if we are careful.

I think this can be worked out as we bring up openoffice.org with hosting on 
Apache infrastructure.  We do not need a one-size-fits-all autocratic solution.

 - Dennis

-Original Message-
From: Reizinger Zoltán [mailto:zreizin...@hdsnet.hu] 
Sent: Tuesday, August 02, 2011 07:45
To: ooo-dev@incubator.apache.org
Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
re:OpenOffice.org branding)

2011.08.02. 15:47 keltezéssel, Rob Weir írta:
> On Tue, Aug 2, 2011 at 9:17 AM, Reizinger Zoltán  wrote:
>> 2011.08.02. 14:03 keltezéssel, Rob Weir írta:
>>> On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber
>>>   wrote:
 On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
> I'd look at it like this:  The documentation that is needed for our
> users to be successful with our product, from end users, to admins, to
> application developers, that documentation is product documentation.
> If having it deleted or defaced, without us noticing it, would cause
> our users some harm, then it is product documentation.  If the right
> to copy, modify and redistribute the documentation is essentially to
> successful creating and hosting a new port or translation, or even a
> commercial derivative or an open source fork, of the project, then it
> is product documentation.
 Leaving aside for the moment all the other user-doc type items on the
 wiki, and looking specifically at the existing current set of user
 guides (which are in ODT/PDF format, but made available for download
 from the existing OOo wiki), I'm unclear how they will fit into this.
 They are not currently under the Apache license, and we would never be
 able to track down all the contributors to get them to agree to the
 license and/or sign the iCLA. So are we talking only about future
 updates to these docs? And if so, do you mean that every future
 contributor to these guides during their production must sign the iCLA?
 Or just that only someone with suitable access rights (committer?) can
 put them on the wiki (in ODT/PDF format)? Or something else?

>>> I'd like us to treat documentation like we do code.  Not necessarily
>>> the same tools, but the same care for provenance, accountability and
>>> quality, namely:
>>>
>>> 1) We welcome "patches" and "contributions" from anyone, but these
>>> must be first reviewed and approved by a project committer before they
>>> become part of the documentation set.  Any such contributions must be
>>> made under Apache 2.0 license.
>>>
>>> 2) Only project committers have direct write access to the
>>> documentation.  This requires that they first sign the iCLA.
>>>
>>> 3) All contributions, whether from the public or from committers and
>>> tracked/logged, so we can accurately determine who made a given
>>> change.  So no anonymous or pseudonymous patches.  A user id that we
>>> can trace to a real email address is fine.
>>>
>>> With code this works by non-committer contributors sending patches
>>> (diffs) to the mailing list, where they are merged in and reviewed by
>>> a committer, and then checked into the repository.  With
>>> documentation, using a wiki , we would need a different mechanism for
>>> achieving this.  Luckily there are MediaWiki extensions to enable
>>> this.
>> Rob,
>> I think you lives outside of this world. You will not find a lot of
>> contributors which needs to work with this idea.
> I'm seeing it working exactly as it does now, with the difference that
> the changes made by non-committers are not immediately visible on the
> page until reviewed and approved by a committer.
>
>> This will stop causal documentation contributors to enhance wiki page.
> So you think that someone will refuse to contribute unless their
> change is made available immediately?  Have you tried this?  Can you
> back up your assertion that no one will contribute?
>
> Take a look at the wiki logs right now:
>
> http://wiki.services.openoffice.org/w/index.php?title=Spe

RE: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

Umm, the proposal page for this incubator project was on a public wiki site and 
was publicly edited.  While there were some mistakes in the course of that, it 
all worked out didn't it?

The project home page is where it is.  That's a straw man (just like the one I 
just gave).  It is not on OpenOffice.org and it won't be, it seems to me.  It 
is in the Apache ooo space.

I propose that we do this on an individual-case basis as we 
migrate/blend/divide/whatever OpenOffice.org-reached content and 
apache.org-reached content.

I propose that we do *not* drop the iCLA hammer on everything to do with 
OpenOffice.org and we should deal with this on concrete terms when we have 
cloned the content of OpenOffice.org ready to reopen under new management but 
with the same welcoming face to the public.

I don't accept that there has been any harm in the handling of provenance on 
OpenOffice.org although it certainly could have been done better.  In fact, 
keeping it the OpenOffice.org site is probably the easiest way to avoid sticky 
permission problems.  Of course, if any contributors want their material taken 
down, we should happily comply.

I wouldn't even add the Apache license to the pages.  The Creative Commons 
attribution license seems perfectly fine there and we should not mess with it.  
The copyright notice I would leave to sharper minds than ours.

 - Dennis

-Original Message-
From: Rob Weir [mailto:apa...@robweir.com] 
Sent: Tuesday, August 02, 2011 07:53
To: ooo-dev@incubator.apache.org
Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton
 wrote:
> -1
>
> I don't understand why there is continued pressing that things not in a 
> release have to be treated as if it requires the same treatment as the 
> content of a release.  I thought we had worked a high-level sketch of the 
> user documentation case with Jean Hollis Weber some time ago on this list.
>

That was something else entirely, ODFAuthors.org, a site that is
external to Apache.  We're not discussing that right now.  What we're
discussing is the content at wiki.services.openoffice.org, which we
are planning to be part of the Apache OpenOffice project. Two
different things.

As for "in release" versus "not in a release", I'll pose a question:
Should we allow anyone to directly edit the project home page, even if
they are not a project committer?  Why not?  It is not "in a release"?

We should be trying to build a an open source release that anyone can
use, modify and redistribute, according to the Apache 2.0 license.
The fact that some pieces are in the source tarball and other pieces
are on the website is irrelevant.  We prevent others from making full
use of our code if we do not allow them to also make full use of
essential documentation.

> There are cross-over cases, such as authoring of what will be embedded help 
> (in many languages) and also the support for on-line help.  But even for 
> on-line help it would be great if it could be community-augmented.
>

I agree,  Everything at Apache is built by the community, including
the source code.  We encourage contributions from all, including
committers, of course, but also patches from users and other
interested parties.  But all such patches are reviewed and approved by
project committers.

> All we're accomplishing here is guaranteeing that the only well-written 
> documents and congenial forums for users will carry the LibreOffice logo.
>
> We already have two separate wikis, one that the community uses and one that 
> requires committers to make the changes.  I notice the second one is not 
> getting much activity.
>

And I'm not seeing a lot of activity at the OpenOffice.org wiki either:

http://wiki.services.openoffice.org/w/index.php?title=Special:RecentChanges&from=20110702130619&days=30&limit=500

What does that prove?

> I think this stance is too heavy-handed in an area where there is no 
> demonstration of harm and a great need for community engagement.  We need to 
> be flexible here, and quickly too.
>

The harm is to the ability of downstream consumers to copy, modify and
redistribute the documentation.  The lax attention paid to this
concern by OpenOffice.org is responsible for the nebulous state of the
IP in the wiki's content today.  That harm has already been done.  I'd
like to prevent that harm from continuing.

>  - Dennis
>
> -Original Message-
> From: Rob Weir [mailto:apa...@robweir.com]
> Sent: Tuesday, August 02, 2011 05:04
> To: ooo-dev@incubator.apache.org
> Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
> re:OpenOffice.org branding)
>
> On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  
> wrote:
>> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>>> I'd look at it like this:  The documentation that is needed for our
>>> users to be successful with our product, from end users, to admins, to
>>> application developers, th

Re: How to handle the downloads?


Am 08/02/2011 04:53 PM, schrieb Dave Fisher:


On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote:


Am 08/02/2011 02:15 PM, schrieb Rob Weir:

On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)   wrote:

Am 08/02/2011 03:00 AM, schrieb Dave Fisher:


On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:


Am 08/02/2011 01:00 AM, schrieb Ross Gardler:


On 1 August 2011 23:42, Marcus (OOo)  wrote:


Am 08/02/2011 12:15 AM, schrieb Ross Gardler:


...


The ASF does not care what your download page looks like as long as
you use the CGI scripts to ensure that an appropriate mirror site is
used.


Hm, let's see how independent the download thing really will be. ;-)


Why don't you mock-up 9in the CMS) what you want the download page to
look like, without linking it in from elsewhere. Once that is done
then we can look at making the download.cgi work the way you want it.


Good idea. Will do so.


I have a script for downloading the download web source from the kenai
svn.

If I download the complete AOOo svn tree particularly
ooo/trunk/tools/dev/fetch-all-web.sh

You can run that script like so:

$ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt .

You then get this (along with all the sub-projects in the web-list.txt)

download dave$ ls -1
2.4.3
all_beta.html
all_rc.html
cachedimages
common
contribute.html
download.js
download2.js
download_bouncer.js
download_mirrorbrain.js
exceptions.css
globalvars.js
index.html
languages.js
md5sums
next
notes.html
other.html
print_tables.js
robots.txt
sdk
sdk.html
source
stable.html
test

So it's there and it is a matter of wrapping it properly.


I don't know what you mean with "wrapping". It's working and with adjustment
of CSS (header, footer, graphics, etc.) and underlaying mirror structure it
should run also for Apache.


Should we start by committing the download site as a subsite of our
incubator project?


The websites inside the incubator project should be developer-oriented. But
the download is nearly 100% user-related, so I would like to see this
content to be continued on "www.openoffice.org" and not directly in a Apache
domain.



I think the point is this:  Even as we preserve the content of the
OpenOffice.org website, we're not going to be re-hosting the Mercurial
repositories on OO.o.  Everything that was formerly in Mercurial will
need to migrate somewhere else, either SVN at Apache or to Hg at
Apache-Extras.   The future OO.o website, hosted by Apache will have
its source files checked into SVN at Apache.  We'd have a mechanism to
publish these files, on modification, to the right directory for the
web server.

We'll need a directory structure in SVN that reflects the fact that
we'll be storing source files for two websites there.  This is not
hard.


Right. In the SVN repo we have to make the separation of the 2 domains visible.'


Yes that is very true, but there is a problem. We only have the one incubator 
site in the Apache CMS and we need to do some experimental conversions. Let's 
mix in with our Incubator site two initial projects - www and download - as 
subdirectories so we can get started with headers and footers and modifying the 
CMS build to handle the OOo site pages from Kenai.


OK, no problem to migratethe webpages into the incubator project. Tehn 
we can "play" a bit with the content to see how it behaves.



We can then get started with branding as well.

Later we can change the svn structure to the one that allows publishing of 
multiple sites in Apache. We'll need to discuss the publishing of the 
openoffice domains using the Apache CMS with Infrastructure.


+1

Marcus




At least this separation will be established from my point of view.

Marcus




We still need someone to work with infra@ to ensure the mirror network
can cope with the load, but I'm sure that will be handled in good
time.


Marcus

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Andre Schnabel

Hi,

 Original-Nachricht 
> Von: Rob Weir 

> > We already have two separate wikis, one that the community uses and one
> that requires committers to make the changes.  I notice the second one is
> not getting much activity.
> >
> 
> And I'm not seeing a lot of activity at the OpenOffice.org wiki either:
> 
> http://wiki.services.openoffice.org/w/index.php?title=Special:RecentChanges&from=20110702130619&days=30&limit=500
> 
> What does that prove?


that OpenOffice.org is a project with (still) a strong name but without
community contributions?

scnr

André

Re: How to handle the downloads?

Thanks for you note. Then we should implement adownload method withthe 
fllowing order:


1. User clicks on the One-Click-Download URL and get the software (like 
today on "download.openoffice.org").


2. If not, he can use alternative download links (like today on 
"download.openoffice.org/pther.html").


3. If a special mirror has to be used, the list of all available mirrors 
will help (like today on 
"http://distribution.openoffice.org/mirrors/#mirrors";).


Latest with step 3 all users should be able to download something.

Marcus



Am 08/02/2011 04:38 PM, schrieb Donald Whytock:

A consideration...I for one have a need to be able to select my
mirror.  My office's firewall blocks certain domains and websites,
especially those recognized as "hosting" or "file-sharing" sites.  It
does not, however, block .edu sites, so when I download an Apache
product I select a university mirror.

Other users may have similar constraints.  If OOo's download process
is going to tie into Apache mirroring, please don't completely
eliminate the capacity to select the mirror.

Don

Re: How to handle the downloads?


On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote:

> Am 08/02/2011 02:15 PM, schrieb Rob Weir:
>> On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)  wrote:
>>> Am 08/02/2011 03:00 AM, schrieb Dave Fisher:
 
 On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:
 
> Am 08/02/2011 01:00 AM, schrieb Ross Gardler:
>> 
>> On 1 August 2011 23:42, Marcus (OOo) wrote:
>>> 
>>> Am 08/02/2011 12:15 AM, schrieb Ross Gardler:
>> 
>> ...
>> 
 The ASF does not care what your download page looks like as long as
 you use the CGI scripts to ensure that an appropriate mirror site is
 used.
>>> 
>>> Hm, let's see how independent the download thing really will be. ;-)
>> 
>> Why don't you mock-up 9in the CMS) what you want the download page to
>> look like, without linking it in from elsewhere. Once that is done
>> then we can look at making the download.cgi work the way you want it.
> 
> Good idea. Will do so.
 
 I have a script for downloading the download web source from the kenai
 svn.
 
 If I download the complete AOOo svn tree particularly
 ooo/trunk/tools/dev/fetch-all-web.sh
 
 You can run that script like so:
 
 $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt .
 
 You then get this (along with all the sub-projects in the web-list.txt)
 
 download dave$ ls -1
 2.4.3
 all_beta.html
 all_rc.html
 cachedimages
 common
 contribute.html
 download.js
 download2.js
 download_bouncer.js
 download_mirrorbrain.js
 exceptions.css
 globalvars.js
 index.html
 languages.js
 md5sums
 next
 notes.html
 other.html
 print_tables.js
 robots.txt
 sdk
 sdk.html
 source
 stable.html
 test
 
 So it's there and it is a matter of wrapping it properly.
>>> 
>>> I don't know what you mean with "wrapping". It's working and with adjustment
>>> of CSS (header, footer, graphics, etc.) and underlaying mirror structure it
>>> should run also for Apache.
 
 Should we start by committing the download site as a subsite of our
 incubator project?
>>> 
>>> The websites inside the incubator project should be developer-oriented. But
>>> the download is nearly 100% user-related, so I would like to see this
>>> content to be continued on "www.openoffice.org" and not directly in a Apache
>>> domain.
>>> 
>> 
>> I think the point is this:  Even as we preserve the content of the
>> OpenOffice.org website, we're not going to be re-hosting the Mercurial
>> repositories on OO.o.  Everything that was formerly in Mercurial will
>> need to migrate somewhere else, either SVN at Apache or to Hg at
>> Apache-Extras.   The future OO.o website, hosted by Apache will have
>> its source files checked into SVN at Apache.  We'd have a mechanism to
>> publish these files, on modification, to the right directory for the
>> web server.
>> 
>> We'll need a directory structure in SVN that reflects the fact that
>> we'll be storing source files for two websites there.  This is not
>> hard.
> 
> Right. In the SVN repo we have to make the separation of the 2 domains 
> visible.'

Yes that is very true, but there is a problem. We only have the one incubator 
site in the Apache CMS and we need to do some experimental conversions. Let's 
mix in with our Incubator site two initial projects - www and download - as 
subdirectories so we can get started with headers and footers and modifying the 
CMS build to handle the OOo site pages from Kenai.

We can then get started with branding as well.

Later we can change the svn structure to the one that allows publishing of 
multiple sites in Apache. We'll need to discuss the publishing of the 
openoffice domains using the Apache CMS with Infrastructure.

Regards,
Dave


> 
> Marcus
> 
> 
> 
>>> At least this separation will be established from my point of view.
>>> 
>>> Marcus
>>> 
>>> 
>>> 
>> We still need someone to work with infra@ to ensure the mirror network
>> can cope with the load, but I'm sure that will be handled in good
>> time.
> 
> Marcus

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton
 wrote:
> -1
>
> I don't understand why there is continued pressing that things not in a 
> release have to be treated as if it requires the same treatment as the 
> content of a release.  I thought we had worked a high-level sketch of the 
> user documentation case with Jean Hollis Weber some time ago on this list.
>

That was something else entirely, ODFAuthors.org, a site that is
external to Apache.  We're not discussing that right now.  What we're
discussing is the content at wiki.services.openoffice.org, which we
are planning to be part of the Apache OpenOffice project. Two
different things.

As for "in release" versus "not in a release", I'll pose a question:
Should we allow anyone to directly edit the project home page, even if
they are not a project committer?  Why not?  It is not "in a release"?

We should be trying to build a an open source release that anyone can
use, modify and redistribute, according to the Apache 2.0 license.
The fact that some pieces are in the source tarball and other pieces
are on the website is irrelevant.  We prevent others from making full
use of our code if we do not allow them to also make full use of
essential documentation.

> There are cross-over cases, such as authoring of what will be embedded help 
> (in many languages) and also the support for on-line help.  But even for 
> on-line help it would be great if it could be community-augmented.
>

I agree,  Everything at Apache is built by the community, including
the source code.  We encourage contributions from all, including
committers, of course, but also patches from users and other
interested parties.  But all such patches are reviewed and approved by
project committers.

> All we're accomplishing here is guaranteeing that the only well-written 
> documents and congenial forums for users will carry the LibreOffice logo.
>
> We already have two separate wikis, one that the community uses and one that 
> requires committers to make the changes.  I notice the second one is not 
> getting much activity.
>

And I'm not seeing a lot of activity at the OpenOffice.org wiki either:

http://wiki.services.openoffice.org/w/index.php?title=Special:RecentChanges&from=20110702130619&days=30&limit=500

What does that prove?

> I think this stance is too heavy-handed in an area where there is no 
> demonstration of harm and a great need for community engagement.  We need to 
> be flexible here, and quickly too.
>

The harm is to the ability of downstream consumers to copy, modify and
redistribute the documentation.  The lax attention paid to this
concern by OpenOffice.org is responsible for the nebulous state of the
IP in the wiki's content today.  That harm has already been done.  I'd
like to prevent that harm from continuing.

>  - Dennis
>
> -Original Message-
> From: Rob Weir [mailto:apa...@robweir.com]
> Sent: Tuesday, August 02, 2011 05:04
> To: ooo-dev@incubator.apache.org
> Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
> re:OpenOffice.org branding)
>
> On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  
> wrote:
>> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>>> I'd look at it like this:  The documentation that is needed for our
>>> users to be successful with our product, from end users, to admins, to
>>> application developers, that documentation is product documentation.
>>> If having it deleted or defaced, without us noticing it, would cause
>>> our users some harm, then it is product documentation.  If the right
>>> to copy, modify and redistribute the documentation is essentially to
>>> successful creating and hosting a new port or translation, or even a
>>> commercial derivative or an open source fork, of the project, then it
>>> is product documentation.
>>
>> Leaving aside for the moment all the other user-doc type items on the
>> wiki, and looking specifically at the existing current set of user
>> guides (which are in ODT/PDF format, but made available for download
>> from the existing OOo wiki), I'm unclear how they will fit into this.
>> They are not currently under the Apache license, and we would never be
>> able to track down all the contributors to get them to agree to the
>> license and/or sign the iCLA. So are we talking only about future
>> updates to these docs? And if so, do you mean that every future
>> contributor to these guides during their production must sign the iCLA?
>> Or just that only someone with suitable access rights (committer?) can
>> put them on the wiki (in ODT/PDF format)? Or something else?
>>
>
> I'd like us to treat documentation like we do code.  Not necessarily
> the same tools, but the same care for provenance, accountability and
> quality, namely:
>
> 1) We welcome "patches" and "contributions" from anyone, but these
> must be first reviewed and approved by a project committer before they
> become part of the documentation set.  Any such contributions must be
> made under Apache 2

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Reizinger Zoltán

2011.08.02. 15:47 keltezéssel, Rob Weir írta:

On Tue, Aug 2, 2011 at 9:17 AM, Reizinger Zoltán wrote:

2011.08.02. 14:03 keltezéssel, Rob Weir írta:

On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber
wrote:

On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:

I'd look at it like this: The documentation that is needed for our
users to be successful with our product, from end users, to admins, to
application developers, that documentation is product documentation.
If having it deleted or defaced, without us noticing it, would cause
our users some harm, then it is product documentation. If the right
to copy, modify and redistribute the documentation is essentially to
successful creating and hosting a new port or translation, or even a
commercial derivative or an open source fork, of the project, then it
is product documentation.

Leaving aside for the moment all the other user-doc type items on the
wiki, and looking specifically at the existing current set of user
guides (which are in ODT/PDF format, but made available for download
from the existing OOo wiki), I'm unclear how they will fit into this.
They are not currently under the Apache license, and we would never be
able to track down all the contributors to get them to agree to the
license and/or sign the iCLA. So are we talking only about future
updates to these docs? And if so, do you mean that every future
contributor to these guides during their production must sign the iCLA?
Or just that only someone with suitable access rights (committer?) can
put them on the wiki (in ODT/PDF format)? Or something else?

I'd like us to treat documentation like we do code. Not necessarily
the same tools, but the same care for provenance, accountability and
quality, namely:

1) We welcome "patches" and "contributions" from anyone, but these
must be first reviewed and approved by a project committer before they
become part of the documentation set. Any such contributions must be
made under Apache 2.0 license.

2) Only project committers have direct write access to the
documentation. This requires that they first sign the iCLA.

3) All contributions, whether from the public or from committers and
tracked/logged, so we can accurately determine who made a given
change. So no anonymous or pseudonymous patches. A user id that we
can trace to a real email address is fine.

With code this works by non-committer contributors sending patches
(diffs) to the mailing list, where they are merged in and reviewed by
a committer, and then checked into the repository. With
documentation, using a wiki , we would need a different mechanism for
achieving this. Luckily there are MediaWiki extensions to enable
this.

Rob,
I think you lives outside of this world. You will not find a lot of
contributors which needs to work with this idea.

I'm seeing it working exactly as it does now, with the difference that
the changes made by non-committers are not immediately visible on the
page until reviewed and approved by a committer.

This will stop causal documentation contributors to enhance wiki page.

So you think that someone will refuse to contribute unless their
change is made available immediately? Have you tried this? Can you
back up your assertion that no one will contribute?

Take a look at the wiki logs right now:

http://wiki.services.openoffice.org/w/index.php?title=Special:RecentChanges&from=20110702130619&days=30&limit=500

What do you see? Many new zombie accounts. People updating their
User pages (not documentation) and a few real documentation changes,
most of which are made by Jean, who is already an Apache OpenOffice
committer.

So although I've seen claims that there are 35,000 user accounts, even
15,000 real accounts, I'm not seeing a huge volume of changes.

Fighting with spammers is a continuous work.
No changes so much because OOo 3.4 was not out on time, and the no new
features happens, it is an side effect of Oracle stopping work on OOo.

See my rare contribution to wiki:
http://wiki.services.openoffice.org/w/index.php?title=Special:Contributions&limit=500&target=R4zoli
Check it, the changes I've made during my contribution, worth for
committer checks, who has not knowledge in Hungarian or OOo Base?

Worth for waiting for approvals?

Your idea to bring all user content under AL 2.0 will not help the users
of OOo, it will hurt them, that is what my experience on tho OOo is saying.

I see no further effort on this topic, your idea may be wrong.
I not want to spend more time on this.
I not see so much support on your side, only you forcing this idea.
Time will tell that it will be useful or not.

Zoltan

When I started working with wiki documentation, first I checked that the
written down text is working in OOo, and if I find something corrected the
text.
I did this when I found some time to work on wiki.
If the causal user meet barriers like every post wait for moderating for
committers they will lost their interest very soon.
What if the wait for

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)


On Aug 2, 2011, at 7:32 AM, Dennis E. Hamilton wrote:

> -1
> 
> I don't understand why there is continued pressing that things not in a 
> release have to be treated as if it requires the same treatment as the 
> content of a release.  I thought we had worked a high-level sketch of the 
> user documentation case with Jean Hollis Weber some time ago on this list.
> 
> There are cross-over cases, such as authoring of what will be embedded help 
> (in many languages) and also the support for on-line help.  But even for 
> on-line help it would be great if it could be community-augmented.
> 
> All we're accomplishing here is guaranteeing that the only well-written 
> documents and congenial forums for users will carry the LibreOffice logo.
> 
> We already have two separate wikis, one that the community uses and one that 
> requires committers to make the changes.  I notice the second one is not 
> getting much activity.
> 
> I think this stance is too heavy-handed in an area where there is no 
> demonstration of harm and a great need for community engagement.  We need to 
> be flexible here, and quickly too.

+1 - Let's listen carefully. We don't have to have all the answers immediately 
and we don't need to drown in slew of emails.

Regards,
Dave

> 
> - Dennis
> 
> -Original Message-
> From: Rob Weir [mailto:apa...@robweir.com] 
> Sent: Tuesday, August 02, 2011 05:04
> To: ooo-dev@incubator.apache.org
> Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
> re:OpenOffice.org branding)
> 
> On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  
> wrote:
>> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>>> I'd look at it like this:  The documentation that is needed for our
>>> users to be successful with our product, from end users, to admins, to
>>> application developers, that documentation is product documentation.
>>> If having it deleted or defaced, without us noticing it, would cause
>>> our users some harm, then it is product documentation.  If the right
>>> to copy, modify and redistribute the documentation is essentially to
>>> successful creating and hosting a new port or translation, or even a
>>> commercial derivative or an open source fork, of the project, then it
>>> is product documentation.
>> 
>> Leaving aside for the moment all the other user-doc type items on the
>> wiki, and looking specifically at the existing current set of user
>> guides (which are in ODT/PDF format, but made available for download
>> from the existing OOo wiki), I'm unclear how they will fit into this.
>> They are not currently under the Apache license, and we would never be
>> able to track down all the contributors to get them to agree to the
>> license and/or sign the iCLA. So are we talking only about future
>> updates to these docs? And if so, do you mean that every future
>> contributor to these guides during their production must sign the iCLA?
>> Or just that only someone with suitable access rights (committer?) can
>> put them on the wiki (in ODT/PDF format)? Or something else?
>> 
> 
> I'd like us to treat documentation like we do code.  Not necessarily
> the same tools, but the same care for provenance, accountability and
> quality, namely:
> 
> 1) We welcome "patches" and "contributions" from anyone, but these
> must be first reviewed and approved by a project committer before they
> become part of the documentation set.  Any such contributions must be
> made under Apache 2.0 license.
> 
> 2) Only project committers have direct write access to the
> documentation.  This requires that they first sign the iCLA.
> 
> 3) All contributions, whether from the public or from committers and
> tracked/logged, so we can accurately determine who made a given
> change.  So no anonymous or pseudonymous patches.  A user id that we
> can trace to a real email address is fine.
> 
> With code this works by non-committer contributors sending patches
> (diffs) to the mailing list, where they are merged in and reviewed by
> a committer, and then checked into the repository.  With
> documentation, using a wiki , we would need a different mechanism for
> achieving this.  Luckily there are MediaWiki extensions to enable
> this.
> 
> I'd like to preserve the immediate nature of editing on the wiki.
> That is its strength.  But we need to find away to also get this under
> project oversight as well.  I think we can do both, without too much
> annoyance to contributors.
> 
>> --Jean
>> 
>> 
>> 
>> 
>> 
>> 
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Terry Ellison


Rob,

I think that you've missed my point.  The guy didn't THREATEN to leave.  
He HAS left.  I doubt we will get him back.  My strong reaction was 
because of that entirely avoidable loss of 5+ man-years of project 
expertise that we will be pressed to recover for the sake on an 
ill-considered shout-down.  Was this really wise?


Yes, I have only been on the DL for two days, but I have been a major 
contributor to community side of the OOo project for five years.  And in 
my 30+ years in this business, I've seen lots of f***ed up project 
take-overs in my business unit.  I was trying to flag up that this old 
dog is starting to sniff another one, and I would REALLY like to prevent 
this happening.


You seem to be positioning yourself as the project leader and absolute 
arbiter of Apache policy, and YOU have caused a valuable asset to this 
project to walk, yet you seem to be totally unaware of this -- or are 
and don't care.  If we keep this up then this Apache project will drive 
away many if not most of the ex-OOo team who want to contribute.  You'll 
be left with an extremely tidy and well-managed DL but no OpenOffice 
product.


If this is the Apache way, then this will be a sad outcome.  But is this 
the Apache way or just your individual interpretation?  I do wonder what 
is the biggest project that you've run personally, or have you even done 
this before?


Regards Terry

On 02/08/11 14:40, Rob Weir wrote:

On Tue, Aug 2, 2011 at 9:00 AM, TerryE  wrote:



Regardless... it doesn't matter to me anymore.  I'm stepping out of
this discussion now, and stepping away from anything to do with OOo
documentation, including the OOo Wiki.

Clayton

This was the outcome of an ill considered discussion.  Clayton, is the one
guy who really understands how the documentation is put together.  He's been
working full time on this for at least 5 years that I know of.  He was
kicked in the teeth by Oracle, albeit for ration if perhaps impersonal
commercial drivers, and now has to consider his future options.  Despite
this and somewhat to my surprise he was willing to re-engage and support OOo
in the future within Apache.  His departure would truly be a loss to the
project and one that I think we all should regret.

In my naiveté I did get the impression that the project would be a flat
consensual collaborative organisation rather than a hierarchical dictat,
albeit with the Apache umbrella.   OK, I fully accept that I don't
understand the "Apache way" yet, but in my days in EDS I had technical
oversight in taking over many account teams and ensuring continuity of
service (most far larger than this project) as well as running large teams
myself.  I have no interest in shovelling this shit in future but I do know
how to get the team to vanish like sand through your fingers.  One sure way
is not to listen to considered and rational experience, to ride roughshod
over peoples input, and to use sarcasm as a tool in sensitive dialogue.
  These people are volunteers contributing pro-bono, not servants.  If this
is going to be the culture of this project, then it is going to wither and
die.


By your strong reaction, Terry, after only being on the list for 2
days, I suspect that you are not yet accustomed to the way we are
debating.  No one is shutting anything down.  We're discussing.  When
there is consensus then we move forward.

Decision making at Apache is described here:

http://www.apache.org/foundation/how-it-works.html#management

It is a good read.  In particular I see nothing about trying to force
decisions by threatening to leave the project.  But maybe I missed
that line ;-)

And remember experience at OOo is not the sole fons et origo of
wisdom.  There are other sources of relevant knowledge and experience.
  We should try to respect all views raised on this list, and not try
to close down arguments by saying, "That's the way we always did it at
OOo" or "I'm more experienced in doing things my way, therefore
everyone else should yield".  Those are not ways to reach consensus.
Similarly, there are parts of Apache that are non-negotiable and areas
where we have some discretion in the project.  The Apache 2.0 license
is an example of something that is non-negotiable.

-Rob

Re: How to handle the downloads?

2011-08-02 Thread Donald Whytock

A consideration...I for one have a need to be able to select my
mirror.  My office's firewall blocks certain domains and websites,
especially those recognized as "hosting" or "file-sharing" sites.  It
does not, however, block .edu sites, so when I download an Apache
product I select a university mirror.

Other users may have similar constraints.  If OOo's download process
is going to tie into Apache mirroring, please don't completely
eliminate the capacity to select the mirror.

Don

RE: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

-1

I don't understand why there is continued pressing that things not in a release 
have to be treated as if it requires the same treatment as the content of a 
release.  I thought we had worked a high-level sketch of the user documentation 
case with Jean Hollis Weber some time ago on this list.

There are cross-over cases, such as authoring of what will be embedded help (in 
many languages) and also the support for on-line help.  But even for on-line 
help it would be great if it could be community-augmented.

All we're accomplishing here is guaranteeing that the only well-written 
documents and congenial forums for users will carry the LibreOffice logo.

We already have two separate wikis, one that the community uses and one that 
requires committers to make the changes.  I notice the second one is not 
getting much activity.

I think this stance is too heavy-handed in an area where there is no 
demonstration of harm and a great need for community engagement.  We need to be 
flexible here, and quickly too.

 - Dennis

-Original Message-
From: Rob Weir [mailto:apa...@robweir.com] 
Sent: Tuesday, August 02, 2011 05:04
To: ooo-dev@incubator.apache.org
Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was 
re:OpenOffice.org branding)

On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  wrote:
> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>> I'd look at it like this:  The documentation that is needed for our
>> users to be successful with our product, from end users, to admins, to
>> application developers, that documentation is product documentation.
>> If having it deleted or defaced, without us noticing it, would cause
>> our users some harm, then it is product documentation.  If the right
>> to copy, modify and redistribute the documentation is essentially to
>> successful creating and hosting a new port or translation, or even a
>> commercial derivative or an open source fork, of the project, then it
>> is product documentation.
>
> Leaving aside for the moment all the other user-doc type items on the
> wiki, and looking specifically at the existing current set of user
> guides (which are in ODT/PDF format, but made available for download
> from the existing OOo wiki), I'm unclear how they will fit into this.
> They are not currently under the Apache license, and we would never be
> able to track down all the contributors to get them to agree to the
> license and/or sign the iCLA. So are we talking only about future
> updates to these docs? And if so, do you mean that every future
> contributor to these guides during their production must sign the iCLA?
> Or just that only someone with suitable access rights (committer?) can
> put them on the wiki (in ODT/PDF format)? Or something else?
>

I'd like us to treat documentation like we do code.  Not necessarily
the same tools, but the same care for provenance, accountability and
quality, namely:

1) We welcome "patches" and "contributions" from anyone, but these
must be first reviewed and approved by a project committer before they
become part of the documentation set.  Any such contributions must be
made under Apache 2.0 license.

2) Only project committers have direct write access to the
documentation.  This requires that they first sign the iCLA.

3) All contributions, whether from the public or from committers and
tracked/logged, so we can accurately determine who made a given
change.  So no anonymous or pseudonymous patches.  A user id that we
can trace to a real email address is fine.

With code this works by non-committer contributors sending patches
(diffs) to the mailing list, where they are merged in and reviewed by
a committer, and then checked into the repository.  With
documentation, using a wiki , we would need a different mechanism for
achieving this.  Luckily there are MediaWiki extensions to enable
this.

I'd like to preserve the immediate nature of editing on the wiki.
That is its strength.  But we need to find away to also get this under
project oversight as well.  I think we can do both, without too much
annoyance to contributors.

> --Jean
>
>
>
>
>
>

Re: How to handle the downloads?


Am 08/02/2011 02:15 PM, schrieb Rob Weir:

On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)  wrote:

Am 08/02/2011 03:00 AM, schrieb Dave Fisher:


On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:


Am 08/02/2011 01:00 AM, schrieb Ross Gardler:


On 1 August 2011 23:42, Marcus (OOo) wrote:


Am 08/02/2011 12:15 AM, schrieb Ross Gardler:


...


The ASF does not care what your download page looks like as long as
you use the CGI scripts to ensure that an appropriate mirror site is
used.


Hm, let's see how independent the download thing really will be. ;-)


Why don't you mock-up 9in the CMS) what you want the download page to
look like, without linking it in from elsewhere. Once that is done
then we can look at making the download.cgi work the way you want it.


Good idea. Will do so.


I have a script for downloading the download web source from the kenai
svn.

If I download the complete AOOo svn tree particularly
ooo/trunk/tools/dev/fetch-all-web.sh

You can run that script like so:

$ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt .

You then get this (along with all the sub-projects in the web-list.txt)

download dave$ ls -1
2.4.3
all_beta.html
all_rc.html
cachedimages
common
contribute.html
download.js
download2.js
download_bouncer.js
download_mirrorbrain.js
exceptions.css
globalvars.js
index.html
languages.js
md5sums
next
notes.html
other.html
print_tables.js
robots.txt
sdk
sdk.html
source
stable.html
test

So it's there and it is a matter of wrapping it properly.


I don't know what you mean with "wrapping". It's working and with adjustment
of CSS (header, footer, graphics, etc.) and underlaying mirror structure it
should run also for Apache.


Should we start by committing the download site as a subsite of our
incubator project?


The websites inside the incubator project should be developer-oriented. But
the download is nearly 100% user-related, so I would like to see this
content to be continued on "www.openoffice.org" and not directly in a Apache
domain.



I think the point is this:  Even as we preserve the content of the
OpenOffice.org website, we're not going to be re-hosting the Mercurial
repositories on OO.o.  Everything that was formerly in Mercurial will
need to migrate somewhere else, either SVN at Apache or to Hg at
Apache-Extras.   The future OO.o website, hosted by Apache will have
its source files checked into SVN at Apache.  We'd have a mechanism to
publish these files, on modification, to the right directory for the
web server.

We'll need a directory structure in SVN that reflects the fact that
we'll be storing source files for two websites there.  This is not
hard.


Right. In the SVN repo we have to make the separation of the 2 domains 
visible.


Marcus




At least this separation will be established from my point of view.

Marcus




We still need someone to work with infra@ to ensure the mirror network
can cope with the load, but I'm sure that will be handled in good
time.


Marcus

Re: Converting the repo using mercurial's convert extension

2011-08-02 Thread Christian Lohmaier

Hi Heiner, *,

On Thu, Jul 28, 2011 at 8:42 PM, Jens-Heiner Rechtien  wrote:
> On 07/28/2011 04:32 PM, Pedro F. Giffuni wrote:
>> --- On Thu, 7/28/11, Christian Lohmaier wrote:
>> ...
>>>
>>> [1] Note that with the map, it would also be possible to
>>> reuse the old OOo-Subversion repo for the linear commits,
>>> after all the hg repo was a conversion from the svn server.
>>> This would save quite a bit of time.
>>
>> I like this idea ... if the old SVN server is still available
>> and we can do a progressive conversion of the rest of the Hg
>> stuff we will save a lot of metadata that had previously been
>> lost (plus we save conversion time).
>
> It's still available: http://svn.services.openoffice.org/ooo resp.
> svn://svn.services.openoffice.org/ooo
>
> You can use svnsync to create a local copy of the rep. Will take a while :-)

Yes, takes almost two days - would have been easier if there was a dump :-)

Now good thing: mapping the revisions works, and is completed on a
slow machine in 10 minutes.
Bad thing: I couldn't test the import with the plain repo, as hg
convert wants a *full* checkout of the repo, not just trunk, and that
doesn't fit in the 100GB I have available[1], so I'm now creating a
dump to run through svndumpfilter to only preserve trunk and retry
with that shrunk repo. (

The script to do the mapping is attached, it will create the mapping
that can be used as hg-shamap to kickstart the conversing skipping the
first 263205 revision, thus saving way more than 20 days of conversion
time :-)

So while the process won't work with the pristine copy of the pristine
svn copy, it can still be used as basis for the conversion when
filtered to only include trunk, as all the linear revisions are
matched in trunk.

[1] the svn repo contains 984 cws - and when you assume just 1 GB per
cws for simplicity, you would need 1TB of storage to just do the
conversion. and svn needs loads of RAM to perform the checkout - the
1GB of real RAM and 1GB of RAM was all occupied by svn, and after
filling the 100GB a mere 12MB were free, so even with enough storage
capacity, the amount of RAM probably would not have been sufficient
for a full checkout...

ciao
Christian

Security Reports page

FYI, I've added a page to the website for "Security Reports", based on
the one used by Tomcat:

http://incubator.apache.org/openofficeorg/security.html

Just the basics right now, including how to report an issue.  Note
that at the end I also give a pointer to the legacy openoffice.org
security bulletins.

-Rob

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 9:35 AM, C  wrote:
> On Tue, Aug 2, 2011 at 14:56, Rob Weir  wrote:
>
> Against my better judgement, one last reply...
>
>> iCLA is not the same as the JCA.  You should read it:
>
> You miss the point entirely Rob.  The issue is not the fine print of
> the iCLA or the JCA (I know what the iCLA says.. I read it)...  it is
> the very fact that requiring it for OOo user documentation raises the
> bar for contribution to the documentation.  If you demand that doc
> contributors sign an iCLA, they simply won't bother... they just go
> away - I've seen this happen over and over, and the people walked..
> not because of the fine print in the JCA... it was because they had to
> sign something, and it was over their head or they can't be bothered
> trying to figure it out.
>

And if these same non-developer, normal user retirees wanted to write
an article for a magazine, on an OpenOffice feature, they would need
to sign a copyright assignment for it to be published by the magazine.
 The point is not the user's background.   Giving license to content
is not a special concern of developers.  It applies to anyone that
creates creative works that they want others to be able to use.

Remember, the mess we're in now, as we're pondering exactly what parts
of the wiki we can actually migrate, was caused by lax attention to
this issue given by the OOo project previously.  That is reducing our
flexibility now.  I'd like to avoid these kinds of problems in the
future.

> Doc contributors are NOT developers.  They are mostly "normal" people
> who have no clue about software development processes.  They are end
> users who enjoy writing a little... editing an FAQ... writing a HowTO.
>  They are often retirees with some spare time on their hands.
>

And their contributions are greatly appreciated.  I don't want to
force them to learn software development process.  But I do what to
ensure that their contributions are made in a way that allows others
to max greatest use of their contributions.  That's why we're an open
source project.

>
>> All documentation in an Apache project is community-developed.
>
> And Apache projects are all very technical.  They are databases, web
> servers, XML framework tools, development toolkits, network
> application frameworks, message brokers, Java development toolsets,
> XML parsers and so on.. none which are Consumer Level products (at
> least that I am aware of or could find).  Documentation for these
> products is written by developers for developers  OOo
> documentation it is user oriented not developer oriented. It is a very
> different animal.
>

Again, that is a red herring.  How the documentation is written and
how it is licensed are two entirely different things.  Ditto for how
content is written and how it is reviewed and approved.  I have no
wish to complicate things for the documentation writer-contributor. We
should make it so they can use familiar tools and techniques.

-Rob

>
> C.
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 9:17 AM, Reizinger Zoltán  wrote:
> 2011.08.02. 14:03 keltezéssel, Rob Weir írta:
>>
>> On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber
>>  wrote:
>>>
>>> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:

 I'd look at it like this:  The documentation that is needed for our
 users to be successful with our product, from end users, to admins, to
 application developers, that documentation is product documentation.
 If having it deleted or defaced, without us noticing it, would cause
 our users some harm, then it is product documentation.  If the right
 to copy, modify and redistribute the documentation is essentially to
 successful creating and hosting a new port or translation, or even a
 commercial derivative or an open source fork, of the project, then it
 is product documentation.
>>>
>>> Leaving aside for the moment all the other user-doc type items on the
>>> wiki, and looking specifically at the existing current set of user
>>> guides (which are in ODT/PDF format, but made available for download
>>> from the existing OOo wiki), I'm unclear how they will fit into this.
>>> They are not currently under the Apache license, and we would never be
>>> able to track down all the contributors to get them to agree to the
>>> license and/or sign the iCLA. So are we talking only about future
>>> updates to these docs? And if so, do you mean that every future
>>> contributor to these guides during their production must sign the iCLA?
>>> Or just that only someone with suitable access rights (committer?) can
>>> put them on the wiki (in ODT/PDF format)? Or something else?
>>>
>> I'd like us to treat documentation like we do code.  Not necessarily
>> the same tools, but the same care for provenance, accountability and
>> quality, namely:
>>
>> 1) We welcome "patches" and "contributions" from anyone, but these
>> must be first reviewed and approved by a project committer before they
>> become part of the documentation set.  Any such contributions must be
>> made under Apache 2.0 license.
>>
>> 2) Only project committers have direct write access to the
>> documentation.  This requires that they first sign the iCLA.
>>
>> 3) All contributions, whether from the public or from committers and
>> tracked/logged, so we can accurately determine who made a given
>> change.  So no anonymous or pseudonymous patches.  A user id that we
>> can trace to a real email address is fine.
>>
>> With code this works by non-committer contributors sending patches
>> (diffs) to the mailing list, where they are merged in and reviewed by
>> a committer, and then checked into the repository.  With
>> documentation, using a wiki , we would need a different mechanism for
>> achieving this.  Luckily there are MediaWiki extensions to enable
>> this.
>
> Rob,
> I think you lives outside of this world. You will not find a lot of
> contributors which needs to work with this idea.

I'm seeing it working exactly as it does now, with the difference that
the changes made by non-committers are not immediately visible on the
page until reviewed and approved by a committer.

> This will stop causal documentation contributors to enhance wiki page.

So you think that someone will refuse to contribute unless their
change is made available immediately?  Have you tried this?  Can you
back up your assertion that no one will contribute?

Take a look at the wiki logs right now:

http://wiki.services.openoffice.org/w/index.php?title=Special:RecentChanges&from=20110702130619&days=30&limit=500

What do you see?  Many new zombie accounts.  People updating their
User pages (not documentation) and a few real documentation changes,
most of which are made by Jean, who is already an Apache OpenOffice
committer.

So although I've seen claims that there are 35,000 user accounts, even
15,000 real accounts, I'm not seeing a huge volume of changes.

> When I started working with wiki documentation, first I checked that the
> written down text is working in OOo, and if I find something corrected the
> text.
> I did this when I found some time to work on wiki.
> If the causal user meet barriers like every post wait for moderating for
> committers they will lost their interest very soon.

What if the wait for review was only a day?

> May be you will have good managed and fully license compliant documentation,
> but fully out of date.

Again, what if aimed to delay the review/approval by no more than 1
day?  Certainly that would not be technically out of date.  Even if
the delay was a week it would not be out of date since releases come
only every couple of months.

> Zoltan
>>
>> I'd like to preserve the immediate nature of editing on the wiki.
>> That is its strength.  But we need to find away to also get this under
>> project oversight as well.  I think we can do both, without too much
>> annoyance to contributors.
>>
>>> --Jean
>>>
>>>
>>>
>>>
>>>
>>>
>
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 9:00 AM, TerryE  wrote:
> 
>>
>> Regardless... it doesn't matter to me anymore.  I'm stepping out of
>> this discussion now, and stepping away from anything to do with OOo
>> documentation, including the OOo Wiki.
>>
>> Clayton
>
> This was the outcome of an ill considered discussion.  Clayton, is the one
> guy who really understands how the documentation is put together.  He's been
> working full time on this for at least 5 years that I know of.  He was
> kicked in the teeth by Oracle, albeit for ration if perhaps impersonal
> commercial drivers, and now has to consider his future options.  Despite
> this and somewhat to my surprise he was willing to re-engage and support OOo
> in the future within Apache.  His departure would truly be a loss to the
> project and one that I think we all should regret.
>
> In my naiveté I did get the impression that the project would be a flat
> consensual collaborative organisation rather than a hierarchical dictat,
> albeit with the Apache umbrella.   OK, I fully accept that I don't
> understand the "Apache way" yet, but in my days in EDS I had technical
> oversight in taking over many account teams and ensuring continuity of
> service (most far larger than this project) as well as running large teams
> myself.  I have no interest in shovelling this shit in future but I do know
> how to get the team to vanish like sand through your fingers.  One sure way
> is not to listen to considered and rational experience, to ride roughshod
> over peoples input, and to use sarcasm as a tool in sensitive dialogue.
>  These people are volunteers contributing pro-bono, not servants.  If this
> is going to be the culture of this project, then it is going to wither and
> die.
>

By your strong reaction, Terry, after only being on the list for 2
days, I suspect that you are not yet accustomed to the way we are
debating.  No one is shutting anything down.  We're discussing.  When
there is consensus then we move forward.

Decision making at Apache is described here:

http://www.apache.org/foundation/how-it-works.html#management

It is a good read.  In particular I see nothing about trying to force
decisions by threatening to leave the project.  But maybe I missed
that line ;-)

And remember experience at OOo is not the sole fons et origo of
wisdom.  There are other sources of relevant knowledge and experience.
 We should try to respect all views raised on this list, and not try
to close down arguments by saying, "That's the way we always did it at
OOo" or "I'm more experienced in doing things my way, therefore
everyone else should yield".  Those are not ways to reach consensus.
Similarly, there are parts of Apache that are non-negotiable and areas
where we have some discretion in the project.  The Apache 2.0 license
is an example of something that is non-negotiable.

-Rob

>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread C

On Tue, Aug 2, 2011 at 14:56, Rob Weir  wrote:

Against my better judgement, one last reply...

> iCLA is not the same as the JCA.  You should read it:

You miss the point entirely Rob.  The issue is not the fine print of
the iCLA or the JCA (I know what the iCLA says.. I read it)...  it is
the very fact that requiring it for OOo user documentation raises the
bar for contribution to the documentation.  If you demand that doc
contributors sign an iCLA, they simply won't bother... they just go
away - I've seen this happen over and over, and the people walked..
not because of the fine print in the JCA... it was because they had to
sign something, and it was over their head or they can't be bothered
trying to figure it out.

Doc contributors are NOT developers.  They are mostly "normal" people
who have no clue about software development processes.  They are end
users who enjoy writing a little... editing an FAQ... writing a HowTO.
 They are often retirees with some spare time on their hands.

> All documentation in an Apache project is community-developed.

And Apache projects are all very technical.  They are databases, web
servers, XML framework tools, development toolkits, network
application frameworks, message brokers, Java development toolsets,
XML parsers and so on.. none which are Consumer Level products (at
least that I am aware of or could find).  Documentation for these
products is written by developers for developers  OOo
documentation it is user oriented not developer oriented. It is a very
different animal.

C.

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread Reizinger Zoltán


2011.08.02. 14:03 keltezéssel, Rob Weir írta:

On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  wrote:

On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:

I'd look at it like this:  The documentation that is needed for our
users to be successful with our product, from end users, to admins, to
application developers, that documentation is product documentation.
If having it deleted or defaced, without us noticing it, would cause
our users some harm, then it is product documentation.  If the right
to copy, modify and redistribute the documentation is essentially to
successful creating and hosting a new port or translation, or even a
commercial derivative or an open source fork, of the project, then it
is product documentation.

Leaving aside for the moment all the other user-doc type items on the
wiki, and looking specifically at the existing current set of user
guides (which are in ODT/PDF format, but made available for download
from the existing OOo wiki), I'm unclear how they will fit into this.
They are not currently under the Apache license, and we would never be
able to track down all the contributors to get them to agree to the
license and/or sign the iCLA. So are we talking only about future
updates to these docs? And if so, do you mean that every future
contributor to these guides during their production must sign the iCLA?
Or just that only someone with suitable access rights (committer?) can
put them on the wiki (in ODT/PDF format)? Or something else?


I'd like us to treat documentation like we do code.  Not necessarily
the same tools, but the same care for provenance, accountability and
quality, namely:

1) We welcome "patches" and "contributions" from anyone, but these
must be first reviewed and approved by a project committer before they
become part of the documentation set.  Any such contributions must be
made under Apache 2.0 license.

2) Only project committers have direct write access to the
documentation.  This requires that they first sign the iCLA.

3) All contributions, whether from the public or from committers and
tracked/logged, so we can accurately determine who made a given
change.  So no anonymous or pseudonymous patches.  A user id that we
can trace to a real email address is fine.

With code this works by non-committer contributors sending patches
(diffs) to the mailing list, where they are merged in and reviewed by
a committer, and then checked into the repository.  With
documentation, using a wiki , we would need a different mechanism for
achieving this.  Luckily there are MediaWiki extensions to enable
this.

Rob,
I think you lives outside of this world. You will not find a lot of 
contributors which needs to work with this idea.

This will stop causal documentation contributors to enhance wiki page.
When I started working with wiki documentation, first I checked that the 
written down text is working in OOo, and if I find something corrected 
the text.

I did this when I found some time to work on wiki.
If the causal user meet barriers like every post wait for moderating for 
committers they will lost their interest very soon.
May be you will have good managed and fully license compliant 
documentation, but fully out of date.

Zoltan

I'd like to preserve the immediate nature of editing on the wiki.
That is its strength.  But we need to find away to also get this under
project oversight as well.  I think we can do both, without too much
annoyance to contributors.


--Jean

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)




Regardless... it doesn't matter to me anymore.  I'm stepping out of
this discussion now, and stepping away from anything to do with OOo
documentation, including the OOo Wiki.

Clayton
This was the outcome of an ill considered discussion.  Clayton, is the 
one guy who really understands how the documentation is put together.  
He's been working full time on this for at least 5 years that I know 
of.  He was kicked in the teeth by Oracle, albeit for ration if perhaps 
impersonal commercial drivers, and now has to consider his future 
options.  Despite this and somewhat to my surprise he was willing to 
re-engage and support OOo in the future within Apache.  His departure 
would truly be a loss to the project and one that I think we all should 
regret.


In my naiveté I did get the impression that the project would be a flat 
consensual collaborative organisation rather than a hierarchical dictat, 
albeit with the Apache umbrella.   OK, I fully accept that I don't 
understand the "Apache way" yet, but in my days in EDS I had technical 
oversight in taking over many account teams and ensuring continuity of 
service (most far larger than this project) as well as running large 
teams myself.  I have no interest in shovelling this shit in future but 
I do know how to get the team to vanish like sand through your fingers.  
One sure way is not to listen to considered and rational experience, to 
ride roughshod over peoples input, and to use sarcasm as a tool in 
sensitive dialogue.  These people are volunteers contributing pro-bono, 
not servants.  If this is going to be the culture of this project, then 
it is going to wither and die.

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Tue, Aug 2, 2011 at 8:20 AM, C  wrote:
> On Tue, Aug 2, 2011 at 14:03, Rob Weir  wrote:
>> I'd like us to treat documentation like we do code.  Not necessarily
>> the same tools, but the same care for provenance, accountability and
>> quality, namely:
>>
>> 1) We welcome "patches" and "contributions" from anyone, but these
>> must be first reviewed and approved by a project committer before they
>> become part of the documentation set.  Any such contributions must be
>> made under Apache 2.0 license.
>>
>> 2) Only project committers have direct write access to the
>> documentation.  This requires that they first sign the iCLA.
>>
>> 3) All contributions, whether from the public or from committers and
>> tracked/logged, so we can accurately determine who made a given
>> change.  So no anonymous or pseudonymous patches.  A user id that we
>> can trace to a real email address is fine.
>>
>> With code this works by non-committer contributors sending patches
>> (diffs) to the mailing list, where they are merged in and reviewed by
>> a committer, and then checked into the repository.  With
>> documentation, using a wiki , we would need a different mechanism for
>> achieving this.  Luckily there are MediaWiki extensions to enable
>> this.
>>
>> I'd like to preserve the immediate nature of editing on the wiki.
>> That is its strength.  But we need to find away to also get this under
>> project oversight as well.  I think we can do both, without too much
>> annoyance to contributors.
>
> This is pretty much JCA regime that was in place under Sun and Oracle.
>  On the User Doc side, it hindered not encouraged doc contributions...
> thus the move to a low entry barrier community Wiki (among other
> things that we tried to implement).  Accepting patches and fixes via a
> bug reporting system is great if you've got the people working the
> bugs and managing the input in a timely manner. otherwise you
> simply have a bottleneck in one or two people.  The same goes for the
> MediaWiki Flagged Revisions (which is installed on the existing OOo
> Wiki by the way, just not in use)... without a team of reviewers, the
> edits are never approved, and community contributions dry up very
> quickly.
>

iCLA is not the same as the JCA.  You should read it:

http://www.apache.org/licenses/icla.txt

The OpenOffice JCA says:

"Contributor hereby assigns to Sun joint ownership in all worldwide
common law and statutory rights associated with the copyrights,
copyright application, copyright registration and moral rights in the
Contribution to the extent allowable under applicable local laws and
copyright conventions."

The Apache iCLA says:

"You hereby grant to the Foundation and to  recipients of software
distributed by the Foundation a perpetual,  worldwide, non-exclusive,
no-charge, royalty-free, irrevocable copyright license to reproduce,
prepare derivative works of,  publicly display, publicly perform,
sublicense, and distribute Your Contributions and such derivative
works."

See the key difference?  With the iCLA recipients get the same rights
as Apache does.  There is no asymmetry like there was with the JCA
where Sun received special rights.

We don't have "a bottleneck in one or two people".  All committers are
able to review and approve patches.  We have (according to Dennis's
latest tally) 54 committers on the project right now.  How many wiki
changes do you think we receive per day?  How much time would it take
to review and approve a single wiki change?  I'd like to see the math
that would suggest a bottleneck.

Of course, not every committer wants to review documentation.  On the
other hand, we're not limited to 54 committers.  If someone is making
a lot of doc changes, and we think they are of high quality, then we
elect them to be committers.  So in an Apache project, you should
never have a review bottleneck.  If you do that would be a sign that
the PPMC is not doing its job of identifying new committers.

> Also you really need to differentiate between Wiki documentation which
> is Community developed... and Application help which is/was treated
> like the source code (and required a JCA to work on).
>

All documentation in an Apache project is community-developed.  All of
it.  100% of it.  Every single line.  Every character, space, em-dash
and en-dash.  There is absolutely nothing in an Apache project, code,
documentation or website that is not developed by the community.  If
you are making a distinction between the committers and the
contributors and some other "community" then you are making a false
distinction.

The question is how does the community work within Apache?

-Rob

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

2011-08-02 Thread C

On Tue, Aug 2, 2011 at 14:03, Rob Weir  wrote:
> I'd like us to treat documentation like we do code.  Not necessarily
> the same tools, but the same care for provenance, accountability and
> quality, namely:
>
> 1) We welcome "patches" and "contributions" from anyone, but these
> must be first reviewed and approved by a project committer before they
> become part of the documentation set.  Any such contributions must be
> made under Apache 2.0 license.
>
> 2) Only project committers have direct write access to the
> documentation.  This requires that they first sign the iCLA.
>
> 3) All contributions, whether from the public or from committers and
> tracked/logged, so we can accurately determine who made a given
> change.  So no anonymous or pseudonymous patches.  A user id that we
> can trace to a real email address is fine.
>
> With code this works by non-committer contributors sending patches
> (diffs) to the mailing list, where they are merged in and reviewed by
> a committer, and then checked into the repository.  With
> documentation, using a wiki , we would need a different mechanism for
> achieving this.  Luckily there are MediaWiki extensions to enable
> this.
>
> I'd like to preserve the immediate nature of editing on the wiki.
> That is its strength.  But we need to find away to also get this under
> project oversight as well.  I think we can do both, without too much
> annoyance to contributors.

This is pretty much JCA regime that was in place under Sun and Oracle.
 On the User Doc side, it hindered not encouraged doc contributions...
thus the move to a low entry barrier community Wiki (among other
things that we tried to implement).  Accepting patches and fixes via a
bug reporting system is great if you've got the people working the
bugs and managing the input in a timely manner. otherwise you
simply have a bottleneck in one or two people.  The same goes for the
MediaWiki Flagged Revisions (which is installed on the existing OOo
Wiki by the way, just not in use)... without a team of reviewers, the
edits are never approved, and community contributions dry up very
quickly.

Also you really need to differentiate between Wiki documentation which
is Community developed... and Application help which is/was treated
like the source code (and required a JCA to work on).

Regardless... it doesn't matter to me anymore.  I'm stepping out of
this discussion now, and stepping away from anything to do with OOo
documentation, including the OOo Wiki.

Clayton

Re: How to handle the downloads?

On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)  wrote:
> Am 08/02/2011 03:00 AM, schrieb Dave Fisher:
>>
>> On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote:
>>
>>> Am 08/02/2011 01:00 AM, schrieb Ross Gardler:

 On 1 August 2011 23:42, Marcus (OOo)   wrote:
>
> Am 08/02/2011 12:15 AM, schrieb Ross Gardler:

 ...

>> The ASF does not care what your download page looks like as long as
>> you use the CGI scripts to ensure that an appropriate mirror site is
>> used.
>
> Hm, let's see how independent the download thing really will be. ;-)

 Why don't you mock-up 9in the CMS) what you want the download page to
 look like, without linking it in from elsewhere. Once that is done
 then we can look at making the download.cgi work the way you want it.
>>>
>>> Good idea. Will do so.
>>
>> I have a script for downloading the download web source from the kenai
>> svn.
>>
>> If I download the complete AOOo svn tree particularly
>> ooo/trunk/tools/dev/fetch-all-web.sh
>>
>> You can run that script like so:
>>
>> $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt .
>>
>> You then get this (along with all the sub-projects in the web-list.txt)
>>
>> download dave$ ls -1
>> 2.4.3
>> all_beta.html
>> all_rc.html
>> cachedimages
>> common
>> contribute.html
>> download.js
>> download2.js
>> download_bouncer.js
>> download_mirrorbrain.js
>> exceptions.css
>> globalvars.js
>> index.html
>> languages.js
>> md5sums
>> next
>> notes.html
>> other.html
>> print_tables.js
>> robots.txt
>> sdk
>> sdk.html
>> source
>> stable.html
>> test
>>
>> So it's there and it is a matter of wrapping it properly.
>
> I don't know what you mean with "wrapping". It's working and with adjustment
> of CSS (header, footer, graphics, etc.) and underlaying mirror structure it
> should run also for Apache.
>>
>> Should we start by committing the download site as a subsite of our
>> incubator project?
>
> The websites inside the incubator project should be developer-oriented. But
> the download is nearly 100% user-related, so I would like to see this
> content to be continued on "www.openoffice.org" and not directly in a Apache
> domain.
>

I think the point is this:  Even as we preserve the content of the
OpenOffice.org website, we're not going to be re-hosting the Mercurial
repositories on OO.o.  Everything that was formerly in Mercurial will
need to migrate somewhere else, either SVN at Apache or to Hg at
Apache-Extras.   The future OO.o website, hosted by Apache will have
its source files checked into SVN at Apache.  We'd have a mechanism to
publish these files, on modification, to the right directory for the
web server.

We'll need a directory structure in SVN that reflects the fact that
we'll be storing source files for two websites there.  This is not
hard.

> At least this separation will be established from my point of view.
>
> Marcus
>
>
>
 We still need someone to work with infra@ to ensure the mirror network
 can cope with the load, but I'm sure that will be handled in good
 time.
>>>
>>> Marcus
>

Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)

On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber  wrote:
> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>> I'd look at it like this:  The documentation that is needed for our
>> users to be successful with our product, from end users, to admins, to
>> application developers, that documentation is product documentation.
>> If having it deleted or defaced, without us noticing it, would cause
>> our users some harm, then it is product documentation.  If the right
>> to copy, modify and redistribute the documentation is essentially to
>> successful creating and hosting a new port or translation, or even a
>> commercial derivative or an open source fork, of the project, then it
>> is product documentation.
>
> Leaving aside for the moment all the other user-doc type items on the
> wiki, and looking specifically at the existing current set of user
> guides (which are in ODT/PDF format, but made available for download
> from the existing OOo wiki), I'm unclear how they will fit into this.
> They are not currently under the Apache license, and we would never be
> able to track down all the contributors to get them to agree to the
> license and/or sign the iCLA. So are we talking only about future
> updates to these docs? And if so, do you mean that every future
> contributor to these guides during their production must sign the iCLA?
> Or just that only someone with suitable access rights (committer?) can
> put them on the wiki (in ODT/PDF format)? Or something else?
>

I'd like us to treat documentation like we do code.  Not necessarily
the same tools, but the same care for provenance, accountability and
quality, namely:

1) We welcome "patches" and "contributions" from anyone, but these
must be first reviewed and approved by a project committer before they
become part of the documentation set.  Any such contributions must be
made under Apache 2.0 license.

2) Only project committers have direct write access to the
documentation.  This requires that they first sign the iCLA.

3) All contributions, whether from the public or from committers and
tracked/logged, so we can accurately determine who made a given
change.  So no anonymous or pseudonymous patches.  A user id that we
can trace to a real email address is fine.

With code this works by non-committer contributors sending patches
(diffs) to the mailing list, where they are merged in and reviewed by
a committer, and then checked into the repository.  With
documentation, using a wiki , we would need a different mechanism for
achieving this.  Luckily there are MediaWiki extensions to enable
this.

I'd like to preserve the immediate nature of editing on the wiki.
That is its strength.  But we need to find away to also get this under
project oversight as well.  I think we can do both, without too much
annoyance to contributors.

> --Jean
>
>
>
>
>
>

Re: [DISCUSS] : Revised Message

On Mon, Aug 1, 2011 at 11:06 PM, Dennis E. Hamilton  wrote:
> I have included the 2011-07-22 recommendations from Stephan Bergmann and the 
> 2011-07-23 recommendation from Ingrid.
>
> These messages will start going out tonight (2011-08-01 utc-0700). They will 
> only appear on the PPMC private list.  I wanted you to know that action is 
> being taken.
>

Thanks, Dennis!

-Rob

>  - Dennis
>
> *** specimen message ***
>
> From: 
> Sent: 
> To: 
> Cc: ooo-priv...@incubator.apache.org
> Subject: : Apache OpenOffice.org Initial Committer 
> Status
>
> Hello ,
>
> You are listed as an Initial Committer on the proposal for the Apache 
> OpenOffice.org incubator project.
>
> The incubator project was accepted by Apache on 2011-06-13.
>
> As an Initial Committer you are invited to be established as a committer on 
> the Apache OpenOffice.org incubator podling. You are also invited to serve on 
> the Podling Project Management Committee after you are established as a 
> committer.
>
> The prerequisite to becoming established as a committer is to register an 
> iCLA agreement with Apache.
>
> Our records indicate that no iCLA has been received from you.
>
> If you choose not to submit an iCLA, please report your decision to 
> .  We will then no longer need to track 
> your status and will not send further reminder mails to you.
>
> Otherwise, if you intend to submit an iCLA, please report your decision to 
> ooo-priv...@incubator.apache.org and indicate how much time you need before 
> the iCLA will be sent to Apache.
>
> For more information and iCLA/CCLA forms, go to 
> .  Complete instructions for submission 
> of an iCLA is at the top of the form (text or PDF).
>
> We welcome your contribution to the Apache OpenOffice.org incubator project.
>
>  - the Apache OpenOffice.org incubator Podling Project Management Committee 
> (PPMC)
>
> *** end of specimen message ***
>
> -Original Message-
> From: Dennis E. Hamilton [mailto:orc...@apache.org]
> Sent: Thursday, July 21, 2011 20:10
> To: OOo-dev Apache Incubator
> Subject: [DISCUSS] : Apache OpenOffice.org Initial 
> Committer Status
>
> There are 20 Initial Committers on the OpenOffice.org incubator proposal who 
> have not yet submitted iCLAs or informed us of their intention not to do so.
>
> Today I used the following format for a message to one of those Initial 
> Committers.
>
> Before 19 more of these are sent out I wanted to check how understandable 
> this is.
>
> I am particularly concerned for how clear this is for those who are not 
> native English speakers.
>
> I welcome your advice.
>
>  - Dennis
>
> *** specimen message ***
>
> From: 
> Sent: 
> To: 
> Cc: ooo-priv...@incubator.apache.org
> Subject: : Apache OpenOffice.org Initial Committer 
> Status
>
> Hello ,
>
> You are listed as an Initial Committer on the proposal for the Apache 
> OpenOffice.org incubator project.
>
> The incubator project was accepted by Apache on 2011-06-13.
>
> As an Initial Committer you are invited to be established as a committer on 
> the Apache OpenOffice.org incubator podling. You are also invited to serve on 
> the Podling Project Management Committee after you are established as a 
> committer.
>
> The prerequisite to becoming established as a committer is to register an 
> iCLA agreement with Apache.
>
> Our records indicate that no iCLA has been received from you.
>
> If you do not choose to submit an iCLA, please report your decision to 
> .  We will then know not wait for it.
>
> If you are submitting an iCLA, please report your decision to 
> ooo-priv...@incubator.apache.org and indicate how much time you need before 
> the iCLA will be sent to Apache.
>
> For more information and iCLA/CCLA forms, go to 
> .  Complete instructions for submission 
> of an iCLA is at the top of the form (text or PDF).
>
> We welcome your contribution to the Apache OpenOffice.org incubator project.
>
>  - the Apache OpenOffice.org incubator Podling Project Management Committee 
> (PPMC)
>
> *** end of specimen message ***
>
>
>
>

Re: How to handle the downloads?