RE: Website Content plus Look and Feel Improvements

[Gavin McDonald]

> -Original Message-
> From: C [mailto:smau...@gmail.com]
> Sent: Sunday, 3 July 2011 3:43 PM
> To: ooo-dev@incubator.apache.org
> Subject: Re: Website Content plus Look and Feel Improvements



> C.

I've been told off before for simply using my first name.
(and I have been here 6 years)

Using 'C' in both you rsig and your from address, not good enough for
me I'm afraid, what's you name please?

Gav...

Re: Website Content plus Look and Feel Improvements

[C]

On Sun, Jul 3, 2011 at 09:53, Gavin McDonald  wrote:
>> -Original Message-
>> From: C [mailto:smau...@gmail.com]
>> Sent: Sunday, 3 July 2011 3:43 PM
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Website Content plus Look and Feel Improvements
>
> 
>
>> C.
>
> I've been told off before for simply using my first name.
> (and I have been here 6 years)
>
> Using 'C' in both you rsig and your from address, not good enough for
> me I'm afraid, what's you name please?

Old habits die hard.  I've used "C" on my private email for more years
than I can remember... for many reasons.

My OOo signature is/was:
--
Clayton Cornell   ccorn...@openoffice.org
OpenOffice.org Documentation Project co-lead

Re: Website Content plus Look and Feel Improvements

[Marcus (OOo)]

Am 07/03/2011 07:43 AM, schrieb C:

On Sun, Jul 3, 2011 at 06:29, Graham Lauder  wrote:

On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:

Some projects are huge and others small. I downloaded several:

wave@minotaur:~/ooo-test$ ls -1
development
documentation
download
projects
www

The size is 2.7GB.

It would be good to come up with a scripted way to convert existing webcontent 
to either mdtext, an altered html, or specialized javascript and css. It is 
likely we can adapt the content and use the Apache CMS to wrap a standard 
skeleton.

Regards, Dave




Much of what is on there is legacy material that could be seriously
pruned.  For instance all the old Marketing material that is V2.0 and
earlier could be deleted.

Argument could be made for the marketing material to start from scratch.
Personally I'd like to see a whole new branding and get shot of the old
stuff, make the first Apache release: V4.0 (Historically, significant
global change has meant a whole number change in the version: V2 new
codebase, V3 Apple compatibility. I think this is significant enough:
pre V4 = LGPL license, V4 and later = ALV2)  From a marketing POV it
gives us a handle to hang a campaign on.


The majority of the documentation project content is not really stored
in the stuff that was downloaded in this test.  What you find in the
web-content side is pretty much just pointers to the Wiki plus a few
files here and there that are not in the Wiki.

I would much more prefer that when the time comes to migrate content
of the documentation directory, that I simply tag which files are to
be transferred and the rest are pruned.  I have spent time cleaning up
what's there, but there are still 10 years of legacy things still
laying about, not used anymore stuff that should not be copied
over.


I know that many things are simply outdated and could be deleted easily 
without loosing value. However, when we grab the content from the Oracle 
server, look into the content, and then decide if to take over and 
publish or modify or delete, then we we have much to do and a longer 
time no real content on our websites.


So, I would prefer to take over all content and make it public *) . Then 
we can go through the content and add/modify/delete/whatever part-by-part.


*) After the license problems are solved.

My 2 ct

Marcus

RE: Website Content plus Look and Feel Improvements

[Gavin McDonald]

> -Original Message-
> From: C [mailto:smau...@gmail.com]
> Sent: Sunday, 3 July 2011 6:00 PM
> To: ooo-dev@incubator.apache.org
> Subject: Re: Website Content plus Look and Feel Improvements
> 
> On Sun, Jul 3, 2011 at 09:53, Gavin McDonald 
> wrote:
> >> -Original Message-
> >> From: C [mailto:smau...@gmail.com]
> >> Sent: Sunday, 3 July 2011 3:43 PM
> >> To: ooo-dev@incubator.apache.org
> >> Subject: Re: Website Content plus Look and Feel Improvements
> >
> > 
> >
> >> C.
> >
> > I've been told off before for simply using my first name.
> > (and I have been here 6 years)
> >
> > Using 'C' in both you rsig and your from address, not good enough for
> > me I'm afraid, what's you name please?
> 
> Old habits die hard.  I've used "C" on my private email for more years
than I
> can remember... for many reasons.
> 
> My OOo signature is/was:
> --
> Clayton Cornell   ccorn...@openoffice.org
> OpenOffice.org Documentation Project co-lead

Great, thanks muchly :)

Gav...

Re: Website Content plus Look and Feel Improvements

[C]

On Sun, Jul 3, 2011 at 10:56, Marcus (OOo)  wrote:
> Am 07/03/2011 07:43 AM, schrieb C:
>>
>> On Sun, Jul 3, 2011 at 06:29, Graham Lauder
>>  wrote:
>>>
>>> On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:

 Some projects are huge and others small. I downloaded several:

 wave@minotaur:~/ooo-test$ ls -1
 development
 documentation
 download
 projects
 www

 The size is 2.7GB.

 It would be good to come up with a scripted way to convert existing
 webcontent to either mdtext, an altered html, or specialized javascript and
 css. It is likely we can adapt the content and use the Apache CMS to wrap a
 standard skeleton.

 Regards, Dave

>>>
>>>
>>> Much of what is on there is legacy material that could be seriously
>>> pruned.  For instance all the old Marketing material that is V2.0 and
>>> earlier could be deleted.
>>>
>>> Argument could be made for the marketing material to start from scratch.
>>> Personally I'd like to see a whole new branding and get shot of the old
>>> stuff, make the first Apache release: V4.0 (Historically, significant
>>> global change has meant a whole number change in the version: V2 new
>>> codebase, V3 Apple compatibility. I think this is significant enough:
>>> pre V4 = LGPL license, V4 and later = ALV2)  From a marketing POV it
>>> gives us a handle to hang a campaign on.
>>
>> The majority of the documentation project content is not really stored
>> in the stuff that was downloaded in this test.  What you find in the
>> web-content side is pretty much just pointers to the Wiki plus a few
>> files here and there that are not in the Wiki.
>>
>> I would much more prefer that when the time comes to migrate content
>> of the documentation directory, that I simply tag which files are to
>> be transferred and the rest are pruned.  I have spent time cleaning up
>> what's there, but there are still 10 years of legacy things still
>> laying about, not used anymore stuff that should not be copied
>> over.
>
> I know that many things are simply outdated and could be deleted easily
> without loosing value. However, when we grab the content from the Oracle
> server, look into the content, and then decide if to take over and publish
> or modify or delete, then we we have much to do and a longer time no real
> content on our websites.
>
> So, I would prefer to take over all content and make it public *) . Then we
> can go through the content and add/modify/delete/whatever part-by-part.
>
> *) After the license problems are solved.
>
> My 2 ct
>
> Marcus

I'm only speaking for the Doc Project web content.

As long as the MediaWiki content is still around (and I hope it stays
around), the Doc project web content "move" could probably be stripped
down to just one HTML page and a few ZIP and PDF files that should be
archived somewhere.  All other usable content has been moved to the
OOoWiki.  It would work to move all the old Doc Project debris over,
but it really adds no value.

 I'd rather say "move this file and these other files and the rest can
be ignored" than to see it all moved over once again... or even
better... to not move anything and simply create a new Doc Project
page from scratch.

If everything is simply copied over, it'll be like the Colabnet to
Kenai move... everything is copied and the legacy cruft tags along,
never to be weeded out.

C.
--
Clayton Cornell   ccorn...@openoffice.org
OpenOffice.org Documentation Project co-lead

Re: Website Content plus Look and Feel Improvements

[Marcus (OOo)]

Am 07/03/2011 11:38 AM, schrieb C:

On Sun, Jul 3, 2011 at 10:56, Marcus (OOo)  wrote:

Am 07/03/2011 07:43 AM, schrieb C:


On Sun, Jul 3, 2011 at 06:29, Graham Lauder
  wrote:


On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:


Some projects are huge and others small. I downloaded several:

wave@minotaur:~/ooo-test$ ls -1
development
documentation
download
projects
www

The size is 2.7GB.

It would be good to come up with a scripted way to convert existing
webcontent to either mdtext, an altered html, or specialized javascript and
css. It is likely we can adapt the content and use the Apache CMS to wrap a
standard skeleton.

Regards, Dave




Much of what is on there is legacy material that could be seriously
pruned.  For instance all the old Marketing material that is V2.0 and
earlier could be deleted.

Argument could be made for the marketing material to start from scratch.
Personally I'd like to see a whole new branding and get shot of the old
stuff, make the first Apache release: V4.0 (Historically, significant
global change has meant a whole number change in the version: V2 new
codebase, V3 Apple compatibility. I think this is significant enough:
pre V4 = LGPL license, V4 and later = ALV2)  From a marketing POV it
gives us a handle to hang a campaign on.


The majority of the documentation project content is not really stored
in the stuff that was downloaded in this test.  What you find in the
web-content side is pretty much just pointers to the Wiki plus a few
files here and there that are not in the Wiki.

I would much more prefer that when the time comes to migrate content
of the documentation directory, that I simply tag which files are to
be transferred and the rest are pruned.  I have spent time cleaning up
what's there, but there are still 10 years of legacy things still
laying about, not used anymore stuff that should not be copied
over.


I know that many things are simply outdated and could be deleted easily
without loosing value. However, when we grab the content from the Oracle
server, look into the content, and then decide if to take over and publish
or modify or delete, then we we have much to do and a longer time no real
content on our websites.

So, I would prefer to take over all content and make it public *) . Then we
can go through the content and add/modify/delete/whatever part-by-part.

*) After the license problems are solved.

My 2 ct

Marcus


I'm only speaking for the Doc Project web content.


OK, you know the doc project very well of course. So we can take what is 
still of value and kick the other stuff.



As long as the MediaWiki content is still around (and I hope it stays
around), the Doc project web content "move" could probably be stripped
down to just one HTML page and a few ZIP and PDF files that should be
archived somewhere.  All other usable content has been moved to the
OOoWiki.  It would work to move all the old Doc Project debris over,
but it really adds no value.

  I'd rather say "move this file and these other files and the rest can
be ignored" than to see it all moved over once again... or even
better... to not move anything and simply create a new Doc Project
page from scratch.

If everything is simply copied over, it'll be like the Colabnet to
Kenai move... everything is copied and the legacy cruft tags along,
never to be weeded out.


IMHO better to start with nothing and add page-by-page. I don't think 
that the old stuff will remain with what we are doing here, a restart. ;-)


Marcus

Re: Website Content plus Look and Feel Improvements

[Jean Hollis Weber]

On Sun, 2011-07-03 at 12:05 +0200, Marcus (OOo) wrote:
> Am 07/03/2011 11:38 AM, schrieb C:
> >>>
> >>> The majority of the documentation project content is not really stored
> >>> in the stuff that was downloaded in this test.  What you find in the
> >>> web-content side is pretty much just pointers to the Wiki plus a few
> >>> files here and there that are not in the Wiki.
> >>>
> >>> I would much more prefer that when the time comes to migrate content
> >>> of the documentation directory, that I simply tag which files are to
> >>> be transferred and the rest are pruned.  I have spent time cleaning up
> >>> what's there, but there are still 10 years of legacy things still
> >>> laying about, not used anymore stuff that should not be copied
> >>> over.
> >
> > I'm only speaking for the Doc Project web content.
> 
> OK, you know the doc project very well of course. So we can take what is 
> still of value and kick the other stuff.
> 

+1

> > As long as the MediaWiki content is still around (and I hope it stays
> > around), the Doc project web content "move" could probably be stripped
> > down to just one HTML page and a few ZIP and PDF files that should be
> > archived somewhere.  All other usable content has been moved to the
> > OOoWiki.  It would work to move all the old Doc Project debris over,
> > but it really adds no value.
> >
> >   I'd rather say "move this file and these other files and the rest can
> > be ignored" than to see it all moved over once again... or even
> > better... to not move anything and simply create a new Doc Project
> > page from scratch.
> 
> IMHO better to start with nothing and add page-by-page. I don't think 
> that the old stuff will remain with what we are doing here, a restart. ;-)

+1

Jean
-- 
Jean Hollis Weber
Co-Lead, OpenOffice.org Documentation Project

Re: Website Content plus Look and Feel Improvements

[TJ Frazier]

On 7/3/2011 05:38, C wrote:


I'm only speaking for the Doc Project web content.

As long as the MediaWiki content is still around (and I hope it stays
around), the Doc project web content "move" could probably be stripped
down to just one HTML page and a few ZIP and PDF files that should be
archived somewhere.  All other usable content has been moved to the
OOoWiki.  It would work to move all the old Doc Project debris over,
but it really adds no value.

  I'd rather say "move this file and these other files and the rest can
be ignored" than to see it all moved over once again... or even
better... to not move anything and simply create a new Doc Project
page from scratch.

If everything is simply copied over, it'll be like the Colabnet to
Kenai move... everything is copied and the legacy cruft tags along,
never to be weeded out.

C.
--
Clayton Cornell   ccorn...@openoffice.org
OpenOffice.org Documentation Project co-lead

Normally, I would disagree with cleaning up during a conversion: it is 
the number-one error to avoid. But in this case . . . if we can create a 
new page that says little more than, "See the wiki" . . .


Moving the wiki is going to be a bear. I can only help with the cleanup 
afterward, since that merely requires some OO.o familiarity, and modest 
Confluence skill.

--
/tj/

T. J. Frazier
Melbourne, FL

(TJFrazier on OO.o)

Re: Website Content plus Look and Feel Improvements

[C]

On Sun, Jul 3, 2011 at 12:35, TJ Frazier  wrote:
> Moving the wiki is going to be a bear. I can only help with the cleanup
> afterward, since that merely requires some OO.o familiarity, and modest
> Confluence skill.


The documentation in the current MediaWiki instance has, as many of
you well know, some very deep dependencies on MW and on the various
extensions (custom written and standard).  I have a feeling that there
are quite a few people here who have no idea just how monumental of a
task that would be.  It will not be a "simple" import... it will
require a manual rework of a couple thousand pages of Wiki content
just to pull in the docs...

The short of it is.. I'll help move the MediaWiki to a new server on
the Apache side (if the decision is made to do this), but I'm not
interested in moving the content to Confluence (if this is the final
decision).


C.
--
Clayton Cornell   ccorn...@openoffice.org
OpenOffice.org Documentation Project co-lead

Re: Introduction

[Manfred A. Reiter]

Hi Peter,

nice to meet YOU ;-)

## Manfred - (android) mobil - please excuse typos
Am 03.07.2011 08:56 schrieb "Peter Junge" :
> Hello Raphael,
>
> good having you around here.
>
> Peter
>
> On 24.06.2011 15:42, Raphael Bircher wrote:
>> Hi at all
>>
>> My name is Raphael Bircher and living in Switzerland. The moast of the
>> peoples knows me already. I'm in the OOo Community since the End 2005. I
>> doing QA, Web Stuff, and sametimes I try to do a little bit coding. I've
>> all teached myself, programming experiences and also my bad developer
>> english (without OOo I think I had never learned english). My work for
>> OOo was:
>>
>> - Help by the release QA for the german NLC
>> - Bughunting, IssueTracker cleaning
>> - QA for Mac during and after Aqua porting
>> - Automated Testing
>> - QA the Mac OS X Langpacks
>> - Mentoring new peoples in QA
>> - QA and scripting for the OOo Website
>> - Evaluate problems depended to the Kenai migration.
>> - Dedecting wrong subscribe links during the kenai migration with a
>> script (over 30'000 pages checked)
>> - A portable OpenOffice.org for Mac (never published)
>>
>> Non tecnical stuff
>> - New Member recruting (same of the hardest jobs at OpenOffice.org)
>> - Particip at souveral Events (at the moment no time, see below)
>> - initial and founding Member of OpenOffice.org Switzerland (now saffos
>> swiss assossiacion for free and fair software solutions) I'm no longer
>> member of this assossiacion, but I have contact to it.
>>
>> Work at the moment
>> - Helping by the migration to Apache
>> - 64 bit Version of OOo for Mac
>>
>> And if sameone believe, that my live is filled with OpenOffice.org only,
>> then you are wrong. I have a much bigger passion as OpenOffice.org. It's
>> Sport. I have had many difficult time in my live. I was born with a
>> strong physical handicap called ICP, I had cancer in the year 2005/2006,
>> but nothing of this things blocks me out in sport. My main sport is
>> floorball, this is a hockey sport wich is realy popular in Sweeden
>> Finland Czach Rebublik and Switzerland. I play it for about 20 years
>> now. But sport is for me much more then fun, it's a way of therapy for
>> my handicap and it's a good way to show the people that much mor is
>> possible as you expect. I train 6 times per week and sametimes more.
>> This is the reason why I have not the time to particip at events for
>> OOo. I hope you can respect this. For all who want to see me play, I
>> have a video on YouTube (http://www.youtube.com/watch?v=JBx08dH1Sj0)
>>
>> Back to OOo, what's my reason to particip on it. Because of the sport
>> and also because social assurance issue it's not easy for me to work for
>> money (in this case Switzerland is a complicate and same times paradox
>> Country). But I can't only sit here, and wait for the next training. I
>> have to do samething in the free time, and I like to do same thing that
>> is usfull for all. I think OpenOffice.org is a good thing to du this.
>> The work on the computer is a good alternation to the hard work on the
>> sportfield. Also I want to keep open the door to the world of IT, even I
>> don't know if I would work as professional IT in future. I tend more to
>> going direction motivation & coaching, sport coach or samething like
that.
>>
>> Anyway, the next five years I will make sport, and that's my first
>> priority. In this time I will also particip to OOo. We had a realy hard
>> time at our project, and sametimes it realy hurt wat's going on the last
>> 12 month. Now we see a light and I realy hope that we take the chance.
>>
>> I want to finish my introduction with a little philosophical quote from
>> myself. This quote I said as I was in the hospital with cancer and a
>> survey chance between 30 and 50 %.
>>
>> "Im grössten Tief ist der Anfang deines grössten Hochs, du wächst mit
>> den negativen und nicht mit den positiven Momenten"
>>
>> Translation to english
>> "In the deepest deep is the beginning of your biggest heighlight, you
>> growing up with the bad and not with the good things."
>>
>> Greetings Raphael

Re: [CONF] Confluence Changes in the last 24 hours

[merlin...@new.rr.com]

PLEASE REMOVE ME FROM THIS MAILING LIST!!! 
 
 
 
 
---Original Message---
 
From: conflue...@apache.org
Date: 07/02/11 23:03:15
To: ooo-comm...@incubator.apache.org
Subject: [CONF] Confluence Changes in the last 24 hours
 
This is a daily summary of all recent changes in Confluence.
 
-
Updated Spaces:
-
 
 
Apache Amber (https://cwiki.apache.org/confluence/display/AMBER)
 
Pages
-
OAuth 2.0 Resource Server edited by  seelmann  (03:20 PM)
https://cwiki.apache.org/confluence/display/AMBER/OAuth+2.0+Resource+Server
 
 
 
Apache Camel (https://cwiki.apache.org/confluence/display/CAMEL)
 
Pages
-
Index edited by  christian schneider  (04:51 AM)
https://cwiki.apache.org/confluence/display/CAMEL/Index
 
 
 
Apache CXF (https://cwiki.apache.org/confluence/display/CXF)
 
Pages
-
People edited by  mazzag  (09:34 AM)
https://cwiki.apache.org/confluence/display/CXF/People
 
 
 
Apache Empire DB (https://cwiki.apache.org/confluence/display/empiredb)
 
Pages
-
Release Process edited by  francisdb  (04:15 AM)
https://cwiki.apache.org/confluence/display/empiredb/Release+Process
 
 
 
Apache MINA (https://cwiki.apache.org/confluence/display/MINA)
 
Pages
-
MINA 3.0 design edited by  jvermillard  (02:07 AM)
https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design
 
 
 
Apache OpenOffice.org Community (https://cwiki.apache
org/confluence/display/OOOUSERS)
 
Pages
-
OOo-Sitemap edited by  rbircher  (06:52 PM)
https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap
 
Site-PPMC-Plan edited by  w...@apache.org  (03:19 PM)
https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
 
OpenOffice Domains edited by  w...@apache.org  (02:50 PM)
https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains
 
Transition Planning edited by  w...@apache.org  (02:45 PM)
https://cwiki.apache.org/confluence/display/OOOUSERS/Transition+Planning
 
 
 
Apache Shiro (https://cwiki.apache.org/confluence/display/SHIRO)
 
Pages
-
Session Management edited by  lhazlewood  (10:18 PM)
https://cwiki.apache.org/confluence/display/SHIRO/Session+Management
 
Web edited by  lhazlewood  (04:16 PM)
https://cwiki.apache.org/confluence/display/SHIRO/Web
 
 
 
Travel Assistance (https://cwiki.apache.org/confluence/display/TAC)
 
Pages
-
TreeNavigation edited by  ipv6guru  (08:01 PM)
https://cwiki.apache.org/confluence/display/TAC/TreeNavigation
 
 
 
Apache Tapestry (https://cwiki.apache.org/confluence/display/TAPESTRY)
 
Pages
-
Navigation edited by  kaosko  (09:14 PM)
https://cwiki.apache.org/confluence/display/TAPESTRY/Navigation
 
Search edited by  kaosko  (08:15 PM)
https://cwiki.apache.org/confluence/display/TAPESTRY/Search
 
JavaScript FAQ edited by  hlship  (03:53 PM)
https://cwiki.apache.org/confluence/display/TAPESTRY/JavaScript+FAQ
 
Configuration edited by  hlship  (03:42 PM)
https://cwiki.apache.org/confluence/display/TAPESTRY/Configuration
 
Release Notes 5.3 edited by  hlship  (03:35 PM)
https://cwiki.apache.org/confluence/display/TAPESTRY/Release+Notes+5.3
 
Release Process edited by  bobharner  (07:39 AM)
https://cwiki.apache.org/confluence/display/TAPESTRY/Release+Process
 
Creating The Skeleton Application edited by  bobharner  (07:31 AM)
https://cwiki.apache
org/confluence/display/TAPESTRY/Creating+The+Skeleton+Application
 
Dependencies, Tools and Plugins edited by  bobharner  (07:23 AM)
https://cwiki.apache
org/confluence/display/TAPESTRY/Dependencies%2C+Tools+and+Plugins
 
Documentation edited by  bobharner  (07:21 AM)
https://cwiki.apache.org/confluence/display/TAPESTRY/Documentation
 
 
 
Apache Wicket (https://cwiki.apache.org/confluence/display/WICKET)
 
Pages
-
Spring edited by  xshyamx  (02:05 PM)
https://cwiki.apache.org/confluence/display/WICKET/Spring
 
 
 
-
Users
-
 
khirano
https://cwiki.apache.org/confluence/display/~khirano
 
Change your notification preferences: https://cwiki.apache
org/confluence/users/viewnotifications.action
 

Re: svn commit: r792072 - in /websites/production/openofficeorg: ./ content/openofficeorg/testarea/index.html

[merlin...@new.rr.com]

All of this is way too technical for me.  I've done everything I know how to
get off this mailing list, but to no avail.  Can someone please help me!!!

merlin...@new.rr.com 
 
 
 
 
---Original Message---
 
From: rbirc...@apache.org
Date: 07/02/11 19:02:45
To: ooo-comm...@incubator.apache.org
Subject: svn commit: r792072 - in /websites/production/openofficeorg: ./
content/openofficeorg/testarea/index.html
 
Author: rbircher
Date: Sun Jul  3 00:02:18 2011
New Revision: 792072
 
Log:
Publishing merge to openofficeorg site by rbircher
 
Added:
websites/production/openofficeorg/content/openofficeorg/testarea/index
html
  - copied unchanged from r792071,
websites/staging/openofficeorg/trunk/content/openofficeorg/testarea/index
html
Modified:
websites/production/openofficeorg/   (props changed)
 
Propchange: websites/production/openofficeorg/
-

--- svn:mergeinfo (original)
+++ svn:mergeinfo Sun Jul  3 00:02:18 2011
@@ -1 +1 @@
-/websites/staging/openofficeorg/trunk:791146-792068
+/websites/staging/openofficeorg/trunk:791146-792071
 
 
 

Re: [CONF] Confluence Changes in the last 24 hours

[Christian Grobmeier]

Write a mail to: ooo-commits-unsubscr...@incubator.apache.org



On Sun, Jul 3, 2011 at 6:08 AM, merlin...@new.rr.com
 wrote:
>
> PLEASE REMOVE ME FROM THIS MAILING LIST!!!
>
>
>
>
> ---Original Message---
>
> From: conflue...@apache.org
> Date: 07/02/11 23:03:15
> To: ooo-comm...@incubator.apache.org
> Subject: [CONF] Confluence Changes in the last 24 hours
>
> This is a daily summary of all recent changes in Confluence.
>
> -
> Updated Spaces:
> -
>
>
> Apache Amber (https://cwiki.apache.org/confluence/display/AMBER)
>
> Pages
> -
> OAuth 2.0 Resource Server edited by  seelmann  (03:20 PM)
> https://cwiki.apache.org/confluence/display/AMBER/OAuth+2.0+Resource+Server
>
>
>
> Apache Camel (https://cwiki.apache.org/confluence/display/CAMEL)
>
> Pages
> -
> Index edited by  christian schneider  (04:51 AM)
> https://cwiki.apache.org/confluence/display/CAMEL/Index
>
>
>
> Apache CXF (https://cwiki.apache.org/confluence/display/CXF)
>
> Pages
> -
> People edited by  mazzag  (09:34 AM)
> https://cwiki.apache.org/confluence/display/CXF/People
>
>
>
> Apache Empire DB (https://cwiki.apache.org/confluence/display/empiredb)
>
> Pages
> -
> Release Process edited by  francisdb  (04:15 AM)
> https://cwiki.apache.org/confluence/display/empiredb/Release+Process
>
>
>
> Apache MINA (https://cwiki.apache.org/confluence/display/MINA)
>
> Pages
> -
> MINA 3.0 design edited by  jvermillard  (02:07 AM)
> https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design
>
>
>
> Apache OpenOffice.org Community 
> (https://cwiki.apache.org/confluence/display/OOOUSERS)
>
> Pages
> -
> OOo-Sitemap edited by  rbircher  (06:52 PM)
> https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap
>
> Site-PPMC-Plan edited by  w...@apache.org  (03:19 PM)
> https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
>
> OpenOffice Domains edited by  w...@apache.org  (02:50 PM)
> https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains
>
> Transition Planning edited by  w...@apache.org  (02:45 PM)
> https://cwiki.apache.org/confluence/display/OOOUSERS/Transition+Planning
>
>
>
> Apache Shiro (https://cwiki.apache.org/confluence/display/SHIRO)
>
> Pages
> -
> Session Management edited by  lhazlewood  (10:18 PM)
> https://cwiki.apache.org/confluence/display/SHIRO/Session+Management
>
> Web edited by  lhazlewood  (04:16 PM)
> https://cwiki.apache.org/confluence/display/SHIRO/Web
>
>
>
> Travel Assistance (https://cwiki.apache.org/confluence/display/TAC)
>
> Pages
> -
> TreeNavigation edited by  ipv6guru  (08:01 PM)
> https://cwiki.apache.org/confluence/display/TAC/TreeNavigation
>
>
>
> Apache Tapestry (https://cwiki.apache.org/confluence/display/TAPESTRY)
>
> Pages
> -
> Navigation edited by  kaosko  (09:14 PM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/Navigation
>
> Search edited by  kaosko  (08:15 PM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/Search
>
> JavaScript FAQ edited by  hlship  (03:53 PM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/JavaScript+FAQ
>
> Configuration edited by  hlship  (03:42 PM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/Configuration
>
> Release Notes 5.3 edited by  hlship  (03:35 PM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/Release+Notes+5.3
>
> Release Process edited by  bobharner  (07:39 AM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/Release+Process
>
> Creating The Skeleton Application edited by  bobharner  (07:31 AM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/Creating+The+Skeleton+Application
>
> Dependencies, Tools and Plugins edited by  bobharner  (07:23 AM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/Dependencies%2C+Tools+and+Plugins
>
> Documentation edited by  bobharner  (07:21 AM)
> https://cwiki.apache.org/confluence/display/TAPESTRY/Documentation
>
>
>
> Apache Wicket (https://cwiki.apache.org/confluence/display/WICKET)
>
> Pages
> -
> Spring edited by  xshyamx  (02:05 PM)
> https://cwiki.apache.org/confluence/display/WICKET/Spring
>
>
>
> -
> Users
> ---

Re: svn commit: r792072 - in /websites/production/openofficeorg: ./ content/openofficeorg/testarea/index.html

[Marcus (OOo)]

Just send a mail to "ooo-dev-unsubscr...@incubator.apache.org" and you 
are out of this.


Marcus



Am 07/03/2011 05:59 AM, schrieb merlin...@new.rr.com:

All of this is way too technical for me. I've done everything I know how
to get off this mailing list, but to no avail. Can someone please help me!!!
merlin...@new.rr.com

Re: Another introduction

[Rob Weir]

On Sat, Jul 2, 2011 at 10:44 PM, Graham Lauder  wrote:
> Greetings all,
>
> My name is Graham Lauder AKA Yorick or Yo.  I've been involved with OOo
> for a number of years mainly in the marketing project but also in the
> website project.  I am somewhat responsible (some would say to blame)
> for the look of the present front page, (although I was just responsible
> for the conceptual elements, Maarten, Kay, Ivan and others did the real
> work and improved vastly on my original idea).
>


Welcome aboard, Graham!


> I am MarCon (Marketing Contact) for New Zealand
> http://marketing.openoffice.org/contacts.html and have been since 2004
> or so, (I'm not good with specific dates).
>
> I am a software trainer to Enterprise specialising in OOo and OSS on the
> desktop for Front Office End Users   I would like to be able to say that
> this keeps me fully occupied but unfortunately that would be a
> garnishing of the truth that would stand little scrutiny and so one must
> whore oneself at other less meaningful work in order to do the real work
> when the opportunity arises.
>
> Previous to OOo I was CEO/MD of my own company for 15 years, retiring in
> 2003. (I should add: a retirement which only managed to last 4 years!)
>
> I was ambivalent at the beginning of the the Oracle gift to Apache
> process.  I remained with OOo post the LibreOffice fork because I
> believe that the fork in the initial stages was done more for control
> than anything else and that was born out of frustration in the community
> and a distrust of Oracle's motives with regard to the future of OOo.
> Distrust that would at first, seem to have a reasonable basis given
> later actions and statements.  Then reinforced with the gift in concert
> with IBM. I also didn't think that all the avenues within the existing
> project had been exhausted sufficiently to warrant dividing the
> community.  Having said that I was not involved at the heart of the
> decision making process that led to LO so I may be incorrect in my
> assumptions and it is true that now the LO community feels they are the
> authors of their own destiny, something that they have never felt in the
> past, even under Suns time.
>
> However I am committed to the long term existence of OOo, thus the
> reason I put my hand up early here.
>
> My hope is that the reasons that the LibreOffice fork happened don't
> rear their ugly heads here.  I noted an earlier email exchange with Rob
> Weir where he was denying IBM corporate power in the project.  I would
> point out that this is a meritocracy and the currency in a meritocracy
> is time.  If IBM (or any Corporate) allows employees to contribute on
> company time then that, in a meritocracy, gifts power to the corporate
> employees and therefore to that corporate because they are unlikely to
> step off the corporate line on Company time and certainly are not going
> to do anything that could be construed as against the companies
> interests.
>

I'd compare the situation with OOo under Sun/Oracle, where there the
copyright was assigned to Sun, where there were reserved seats on the
Committee Council for Sun staff, where the project leads on the dev
side were almost all Sun employees.  You will not see things like this
in Apache.  Apache projects are run by a meritocracy, not by a
corporate-dominated hierarchy.  We're not going to have "leads" who
control the destiny of a component by power that has been assigned to
them by a central authority.  Power is not centralized.

Yes, time + merit does give a form of power.  But time comes in many
ways.  By employment, but also by retirement or by avocation.   I know
we have some retired engineers contributing to the project as well.
Should we deny them the ability to do so because they have a luxury of
time that we don't all have?  I don't think so.  There is competition
for an open source developer's time and attention as fierce as any
other competition in the marketplace.   I think we should be grateful
for any contribution of time we receive, big or small.

> So the question is: Will decisions be made at IBM that will translate
> into fait accompli in OOo simply because the IBM members of the
> community have been given the time to contribute to Apache, above and
> beyond those of us who can afford only a number of hours outside of work
> time?
>

To correct a error in your question:  IBM (or any other company) does
not make "decisions" in this project.  Employees of IBM (or any other
company) do not make "decisions" in this project.  However,
individuals of IBM (and other companies) will make contributions to
this project, and these contributions will be reviewed and accepted or
rejected, like any other contributions.

I hope that any contributions by IBM engineers will be judged purely
on their merit and not given special advantages, or disadvantages.  I
would hope that is the same is true in any Apache project, or indeed
for other open source projects like LibreOffice, where a dozen
Nove

Fwd: Reminder: TAC Assistance to ApacheCon NA 2011 closes July 8th

[Dave Fisher]

Danese's FYI was missing a lot of content.

Begin forwarded message:

> From: "Gavin McDonald" 
> Date: July 2, 2011 5:19:57 PM PDT
> To: 
> Subject: Reminder: TAC Assistance to ApacheCon NA 2011 closes July 8th
> Reply-To: 
> 
> Hi All,
> 
> Just a friendly (and final)  reminder that applications for financial help
> to attend ApacheCon NA 2011 in Vancouver close this coming Friday 8th July
> (2200 BST : UTC+1)
> 
> Financial assistance is available for Travel (planes, trains, whatever) ,
> Accommodation (at the conference venue hotel) and Conference entrance fees.
> Dependant on your circumstances will decide how much of that you would be
> given.
> 
> Please visit http://apache.org/travel for more information and a link to the
> application form.
> 
> Remember: We DO help people get to ApacheCon and other Apache events every
> year, we DO want to help people get there who otherwise could not, that is
> why we exist.
> 
> Spread the word, you are welcome to tweet, blog, email, post, phone or smoke
> signal to anyone who you think might benefit from attending ApacheCon this
> year.
> 
> (Any queries please to the tac-apply.at.apache.org address only, do not try
> and post to this committers announce only list)
> 
> Kind Regards,
> 
> The Travel Assistance Committee.
> 

Re: Reminder: TAC Assistance to ApacheCon NA 2011 closes July 8th

[Danese Cooper]

Sorry if my forward was missing content. I did not edit it. Must have been 
iPhone mail client fail.

D

On Jul 3, 2011, at 7:50 AM, Dave Fisher  wrote:

> Danese's FYI was missing a lot of content.
> 
> Begin forwarded message:
> 
>> From: "Gavin McDonald" 
>> Date: July 2, 2011 5:19:57 PM PDT
>> To: 
>> Subject: Reminder: TAC Assistance to ApacheCon NA 2011 closes July 8th
>> Reply-To: 
>> 
>> Hi All,
>> 
>> Just a friendly (and final)  reminder that applications for financial help
>> to attend ApacheCon NA 2011 in Vancouver close this coming Friday 8th July
>> (2200 BST : UTC+1)
>> 
>> Financial assistance is available for Travel (planes, trains, whatever) ,
>> Accommodation (at the conference venue hotel) and Conference entrance fees.
>> Dependant on your circumstances will decide how much of that you would be
>> given.
>> 
>> Please visit http://apache.org/travel for more information and a link to the
>> application form.
>> 
>> Remember: We DO help people get to ApacheCon and other Apache events every
>> year, we DO want to help people get there who otherwise could not, that is
>> why we exist.
>> 
>> Spread the word, you are welcome to tweet, blog, email, post, phone or smoke
>> signal to anyone who you think might benefit from attending ApacheCon this
>> year.
>> 
>> (Any queries please to the tac-apply.at.apache.org address only, do not try
>> and post to this committers announce only list)
>> 
>> Kind Regards,
>> 
>> The Travel Assistance Committee.
>> 
> 

Re: Releasing OOo 3.4 on the old infrastructure

[Andrea Pescetti]

On 19/06/2011 Andrea Pescetti wrote:
> Would it be possible to release OOo 3.4 on the old (Oracle-owned)
> infrastructure, and maybe take advantage of this release to educate
> users and volunteers about the coming new infrastructure at Apache?
> ... I take for granted that the community would support this proposal
> (for one, the Italian community spent weeks to get the OOo 3.4 strings
> 100% translated into Italian, and our QA team is ready to start full
> testing any moment). Would developers and release managers support this
> too?

All reactions on this old mail I sent have been positive, but we still
miss an answer from developers. In my opinion this is an occasion not to
miss for at least the following three reasons, comments welcome.

1) Releasing OpenOffice.org 3.4 must not be seen as the last activity on
   the old infrastructure, but as the first activity of the new Apache
   project. Dozens of tools are used to coordinate an OOo release, and
   for us experienced OOo volunteers it will surely be better to explain
   and revise tools and processes in front of a concrete example rather
   than describing them in abstract to new members.

2) OpenOffice.org 3.4 is mostly ready. I built the latest code from hg
   a couple weeks ago and I've regularly used it so far. The quality is
   good and there is no risk of damaging the OOo reputation. All
   release stoppers are bugs that will have to be fixed anyway, and
   fixing them later will require the same amount of time.

3) The amazing people who joined this project cover all areas needed
   for a successful release. This is the only group that can coordinate
   a successful release (bugfixing, QA, distribution) of OpenOffice.org
   3.4, and use the experience to educate old and new community members
   to the Apache way and, on the other side, to the OOo processes.

We have a huge community that is ready now and that becomes very active
only when a release is in sight (and that would surely be committed to
extra effort, if needed, this time): it would be a risky move, both for
communication and for involvement of volunteers, to have them waiting
for a long time before we can ask them to help us release a new version.

Any reasons not to try?

Regards,
  Andrea.

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 3, 2011, at 3:51 AM, C wrote:

> On Sun, Jul 3, 2011 at 12:35, TJ Frazier  wrote:
>> Moving the wiki is going to be a bear. I can only help with the cleanup
>> afterward, since that merely requires some OO.o familiarity, and modest
>> Confluence skill.
> 
> 
> The documentation in the current MediaWiki instance has, as many of
> you well know, some very deep dependencies on MW and on the various
> extensions (custom written and standard).  I have a feeling that there
> are quite a few people here who have no idea just how monumental of a
> task that would be.  It will not be a "simple" import... it will
> require a manual rework of a couple thousand pages of Wiki content
> just to pull in the docs...

Please provide a few concrete examples of the thousands of pages that will need 
to be reworked. What features of MediaWiki are required and what is the 
purpose. Give me some of the gory details.

> The short of it is.. I'll help move the MediaWiki to a new server on
> the Apache side (if the decision is made to do this), but I'm not
> interested in moving the content to Confluence (if this is the final
> decision).

The bar is much higher to add to Apache Infrastructure. It must be proven to 
Infrastructure that we have enough volunteers that can administer the service. 
Confluence is already present, as is the Apache CMS.

We have individuals with scripting abilities. If the wiki re-work is mechanical 
then we can script it.

Regards,
Dave

> 
> 
> C.
> --
> Clayton Cornell   ccorn...@openoffice.org
> OpenOffice.org Documentation Project co-lead

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 2, 2011, at 3:41 PM, Raphael Bircher wrote:

> Am 02.07.11 23:41, schrieb Kay Schenk:
>> OUCH! see below...
>> 
>> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher  wrote:
>> 
>>> Yesterday I got tired of the look of people.mdtext in the project site. It
>>> was so 1990s. So, I've improved the look via css and adding defined widths.
>>> I guess I am volunteering for the item on
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted
>>> 
>>> Several of us have been surveying the existing openoffice.org website on
>>> several wiki pages mostly linked to from:
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
>>> 
>>> With over 140 "projects" in openoffice.org, it will be important to agree
>>> to a mapping which reduces the granularity by more than an order of
>>> magnitude. The page http://projects.openoffice.org/ is a good and clear
>>> way to start - and pretty much fits the structure on
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
>>> 
>> 
>>>• Product Development
>>>• Extension Development
>>>• Language Support
>>>• Helping Users
>>>• Distribution
>>>• Promotion
>>> 
>>> I think that these groupings will help us easily have a rule about which
>>> projects end up on http://openoffice.apache.org/ or stay on the successor
>>> http://*.openoffice.org/.
>>> 
>>> Projects have "webcontent" and/or "wiki" content. On openoffice.org there
>>> is a generally consistent look. There are exceptions which are marketing
>>> sites like http://why.openoffice.org/. The difference is glaring because
>>> that is the first big button on the main site.
>>> 
>>> Webcontent is available via svn - "svn co
>>> https://svn.openoffice.org/svn/${project}~webcontent ${project}" (Thanks
>>> Marcus Lange)
>>> 
>> 
>>> Some projects are huge and others small. I downloaded several:
>>> 
>> I think "infrastructure" which is the project for all aspects dealing with
>> the development of the old web site itself could be thrown out completely,
>> since, ta da, here we are in a new environment. And, much of that is VERY
>> old. Ditto for much of the "download" area which goes back to the
>> non-mirrors age.
> The problem is, that we have many dead pages on the SVN. At Collabnet we 
> haven't the right to delete pages from the CVS. So many many unused site is 
> still on the SVN but you won't find it over the OOo webpage.
>> It might be useful to take the domains list
>> 
>>  https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains
>> 
>> and see what can be combined into your suggested categories below.  Maybe we
>> could start something like this as a seperate item off the "To Do" list on
>> the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
>> really part of the main website -- web~webcontent.
> I have already done a sitemap for all projects. It's only 4 month old. I do 
> this sitemap for the kenai migration. I will upload the list. It's a line 
> separated textfile.

Would you please commit the list to 
https://svn.apache.org/repos/asf/incubator/ooo/trunk/tools/dev

>> The following page needs more fleshing out:
>> https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap
>> 
>> 
>> 
>>> wave@minotaur:~/ooo-test$ ls -1
>>> development
>>> documentation
>>> download
>>> projects
>>> www
>>> 
>>> The size is 2.7GB.
>>> 
>>> It would be good to come up with a scripted way to convert existing
>>> webcontent to either mdtext, an altered html, or specialized javascript and
>>> css. It is likely we can adapt the content and use the Apache CMS to wrap a
>>> standard skeleton.
>>> 
> Yes we need a script, but I think the Script can only do basic work. The OOo 
> Page is not so easy as it looks. Ther are many special features on the kenai 
> framework, and a load of JavaScript. I agree with Kai that we have to be 
> verry carefull.

On the wiki you mentioned a script for producing downloads from the webcontent 
in svn - that could also go into ooo/trunk/tools/dev

How much of the webcontent in svn is replaced by wiki content? Is the 
webcontent maintained in Kenai, or separately?

Also important and part of being very careful is paying attention to the css 
tags embedded, ids, and classes.

Regards,
Dave

> 
> Greatings Raphael
> 
> -- 
> My private Homepage: http://www.raphaelbircher.ch/

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 2, 2011, at 5:26 PM, Raphael Bircher wrote:

> Am 03.07.11 01:30, schrieb Kay Schenk:
>> On Sat, Jul 2, 2011 at 3:41 PM, Raphael Bircher  wrote:
>> 
>>> Am 02.07.11 23:41, schrieb Kay Schenk:
>>> 
>>>  OUCH! see below...
 On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher
  wrote:
 
  Yesterday I got tired of the look of people.mdtext in the project site.
> It
> was so 1990s. So, I've improved the look via css and adding defined
> widths.
> I guess I am volunteering for the item on
> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Help+Wanted
> 
> Several of us have been surveying the existing openoffice.org website on
> several wiki pages mostly linked to from:
> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Site-PPMC-Plan
> 
> With over 140 "projects" in openoffice.org, it will be important to
> agree
> to a mapping which reduces the granularity by more than an order of
> magnitude. The page 
> http://projects.openoffice.**org/is a 
> good and clear
> way to start - and pretty much fits the structure on
> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
> Project+Planning
> 
> 
 • Product Development
>• Extension Development
>• Language Support
>• Helping Users
>• Distribution
>• Promotion
> 
> I think that these groupings will help us easily have a rule about which
> projects end up on http://openoffice.apache.org/ or stay on the
> successor
> http://*.openoffice.org/.
> 
> Projects have "webcontent" and/or "wiki" content. On openoffice.orgthere
> is a generally consistent look. There are exceptions which are marketing
> sites like http://why.openoffice.org/. The difference is glaring because
> that is the first big button on the main site.
> 
> Webcontent is available via svn - "svn co
> https://svn.openoffice.org/**svn/${project}~webcontent${project}"
>  (Thanks
> Marcus Lange)
> 
> 
  Some projects are huge and others small. I downloaded several:
>  I think "infrastructure" which is the project for all aspects dealing
 with
 the development of the old web site itself could be thrown out completely,
 since, ta da, here we are in a new environment. And, much of that is VERY
 old. Ditto for much of the "download" area which goes back to the
 non-mirrors age.
 
>>> The problem is, that we have many dead pages on the SVN. At Collabnet we
>>> haven't the right to delete pages from the CVS. So many many unused site is
>>> still on the SVN but you won't find it over the OOo webpage.
>>> 
>>>  It might be useful to take the domains list
  https://cwiki.apache.org/**confluence/display/OOOUSERS/**
 OpenOffice+Domains
 
 and see what can be combined into your suggested categories below.  Maybe
 we
 could start something like this as a seperate item off the "To Do" list on
 the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
 really part of the main website -- web~webcontent.
 
>>> I have already done a sitemap for all projects. It's only 4 month old. I do
>>> this sitemap for the kenai migration. I will upload the list. It's a line
>>> separated textfile.
>>> 
>>>  The following page needs more fleshing out:
 https://cwiki.apache.org/**confluence/display/OOOUSERS/**OOo-Sitemap
 
 
 
  wave@minotaur:~/ooo-test$ ls -1
> development
> documentation
> download
> projects
> www
> 
> The size is 2.7GB.
> 
> It would be good to come up with a scripted way to convert existing
> webcontent to either mdtext, an altered html, or specialized javascript
> and
> css. It is likely we can adapt the content and use the Apache CMS to wrap
> a
> standard skeleton.
> 
>  Yes we need a script, but I think the Script can only do basic work. The
>>> OOo Page is not so easy as it looks. Ther are many special features on the
>>> kenai framework, and a load of JavaScript. I agree with Kai that we have to
>>> be verry carefull.
>>> 
>>> Greatings Raphael
>>> 
>>> --
>>> My private Homepage: http://www.raphaelbircher.ch/
>> 
>> OK, a totally different thought/approach.
>> 
>> I think it might be easier in the long run to migrate the entire current OOo
>> site in total (well except for maybe a few areas/projects) and deal with the
>> revamping/reorg on a longer term basis 

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:

> On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:
>> Yesterday I got tired of the look of people.mdtext in the project site. It 
>> was so 1990s. So, I've improved the look via css and adding defined widths. 
>> I guess I am volunteering for the item on 
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted
>> 
>> Several of us have been surveying the existing openoffice.org website on 
>> several wiki pages mostly linked to from:
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
>> 
>> With over 140 "projects" in openoffice.org, it will be important to agree to 
>> a mapping which reduces the granularity by more than an order of magnitude. 
>> The page http://projects.openoffice.org/ is a good and clear way to start - 
>> and pretty much fits the structure on 
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
>> 
>>  • Product Development
>>  • Extension Development
>>  • Language Support
>>  • Helping Users
>>  • Distribution
>>  • Promotion
>> 
>> I think that these groupings will help us easily have a rule about which 
>> projects end up on http://openoffice.apache.org/ or stay on the successor 
>> http://*.openoffice.org/.
>> 
>> Projects have "webcontent" and/or "wiki" content. On openoffice.org there is 
>> a generally consistent look. There are exceptions which are marketing sites 
>> like http://why.openoffice.org/. The difference is glaring because that is 
>> the first big button on the main site.
> 
> The why.openoffice.org page was done as a marketing tool independently
> of the main website and the Website team under the marketing project by
> one of the members of the marketing team and for a specific marketing
> campaign.  Andre's design was so good we left it as is, however there
> had been intention to change it suit the overall look but volunteer time
> availability to do it was lacking.  It still served a purpose as a very
> useful marketing resource so pulling it down just because of a
> non-standard look was never an option.

Understood, thanks for the detail. It is a nice and tight presentation.

>> Webcontent is available via svn - "svn co 
>> https://svn.openoffice.org/svn/${project}~webcontent ${project}" (Thanks 
>> Marcus Lange)
>> 
>> Some projects are huge and others small. I downloaded several:
>> 
>> wave@minotaur:~/ooo-test$ ls -1
>> development
>> documentation
>> download
>> projects
>> www
>> 
>> The size is 2.7GB.
>> 
>> It would be good to come up with a scripted way to convert existing 
>> webcontent to either mdtext, an altered html, or specialized javascript and 
>> css. It is likely we can adapt the content and use the Apache CMS to wrap a 
>> standard skeleton.
>> 
>> Regards, Dave
>> 
> 
> 
> Much of what is on there is legacy material that could be seriously
> pruned.  For instance all the old Marketing material that is V2.0 and
> earlier could be deleted.

What would you do to the main openoffice.org site if you were starting from 
scratch?

Regards,
Dave


> 
> Argument could be made for the marketing material to start from scratch.
> Personally I'd like to see a whole new branding and get shot of the old
> stuff, make the first Apache release: V4.0 (Historically, significant
> global change has meant a whole number change in the version: V2 new
> codebase, V3 Apple compatibility. I think this is significant enough:
> pre V4 = LGPL license, V4 and later = ALV2)  From a marketing POV it
> gives us a handle to hang a campaign on.  
> 
> Cheers
> GL
> 
> -- 
> Graham Lauder,
> OpenOffice.org MarCon (Marketing Contact) NZ
> http://marketing.openoffice.org/contacts.html
> 
> OpenOffice.org Migration and training Consultant.
> 
> 
> 

Re: Releasing OOo 3.4 on the old infrastructure

[Alexandro Colorado]

On Sun, Jul 3, 2011 at 11:27 AM, Andrea Pescetti wrote:

> On 19/06/2011 Andrea Pescetti wrote:
> > Would it be possible to release OOo 3.4 on the old (Oracle-owned)
> > infrastructure, and maybe take advantage of this release to educate
> > users and volunteers about the coming new infrastructure at Apache?
> > ... I take for granted that the community would support this proposal
> > (for one, the Italian community spent weeks to get the OOo 3.4 strings
> > 100% translated into Italian, and our QA team is ready to start full
> > testing any moment). Would developers and release managers support this
> > too?
>
> All reactions on this old mail I sent have been positive, but we still
> miss an answer from developers. In my opinion this is an occasion not to
> miss for at least the following three reasons, comments welcome.
>
> 1) Releasing OpenOffice.org 3.4 must not be seen as the last activity on
>   the old infrastructure, but as the first activity of the new Apache
>   project. Dozens of tools are used to coordinate an OOo release, and
>   for us experienced OOo volunteers it will surely be better to explain
>   and revise tools and processes in front of a concrete example rather
>   than describing them in abstract to new members.
>
> 2) OpenOffice.org 3.4 is mostly ready. I built the latest code from hg
>   a couple weeks ago and I've regularly used it so far. The quality is
>   good and there is no risk of damaging the OOo reputation. All
>   release stoppers are bugs that will have to be fixed anyway, and
>   fixing them later will require the same amount of time.
>
> 3) The amazing people who joined this project cover all areas needed
>   for a successful release. This is the only group that can coordinate
>   a successful release (bugfixing, QA, distribution) of OpenOffice.org
>   3.4, and use the experience to educate old and new community members
>   to the Apache way and, on the other side, to the OOo processes.
>
> We have a huge community that is ready now and that becomes very active
> only when a release is in sight (and that would surely be committed to
> extra effort, if needed, this time): it would be a risky move, both for
> communication and for involvement of volunteers, to have them waiting
> for a long time before we can ask them to help us release a new version.
>
> Any reasons not to try?
>
> Regards,
>   Andrea.
>
>
Well Joost (QA Manager) is not on the list, although I saw Stefan Taxteh
submiting for an apache ID which means he is around. I wonder who would be
needed to speak on this.


-- 
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org

Re: Website Content plus Look and Feel Improvements

[C]

On Sun, Jul 3, 2011 at 18:53, Dave Fisher  wrote:
>> The short of it is.. I'll help move the MediaWiki to a new server on
>> the Apache side (if the decision is made to do this), but I'm not
>> interested in moving the content to Confluence (if this is the final
>> decision).
>
> Please provide a few concrete examples of the thousands of pages that will 
> need to be reworked. What features of MediaWiki are required and what is the 
> purpose. Give me some of the gory details.
>
> The bar is much higher to add to Apache Infrastructure. It must be proven to 
> Infrastructure that we have enough volunteers that can administer the 
> service. Confluence is already present, as is the Apache CMS.
>
> We have individuals with scripting abilities. If the wiki re-work is 
> mechanical then we can script it.
>
> Regards,
> Dave


A few example items... the existing/legacy MediaWiki instance is using
several creative tweaks such as (not an exhaustive list.. just a few):

 - PDF and ODT export.  Confluence can do PDF, but cannot do ODT..
only MS Word DOC format (a significant issue in my view for an OOo
Wiki... a bit sad and embarassing that we'd only be able to export a
proprietary document format, and not the primary doc format that OOo
is known for).  Export to PDF and ODT is something a lot of people use
for the OOo Docs - especially the Basic and Developer's Guides.

 - Dynamic page lists - creates dynamic page set views of doc content.
 This is used for dynamically  indexing the FAQs for example.

 - IDL Tags - custom (but simple) MW extension that creates links to
the IDL library

As for the number of pages... start with the big one.. the Developer's
Guide.  
http://wiki.services.openoffice.org/wiki/Category:Documentation/Developer%27s_Guide
This doc alone is approximately 1000 Wiki pages (something close to
that... I don't know the exact number off the top of my head... it's
around 2000 A4 pages when printed out or converted to PDF/ODT).  Like
the other manuals in the existing/legacy OOo Wiki, it uses a
combination of nested templates and various extensions to manage the
subpages as a book.  It has a detailed TOC and navigation tree, IDL
linking, etc.  This would all need to be stripped and adapted to
convert to Confluence.  Each page would need to land in the right
place in the document hierarchy.  Someone would need to write a
Confluence macro or extension to handle the IDL tagging.  All the
MediaWiki tagging would need to be converted and then someone
would need to wade through the document and double check that it's
still in a logical correct order, and tidy up the little oopses.

Add to the list, the Basic Guide, the Reference Lists, and the
FAQs/HowTos, plus whatever Doc pages have been translated into
Russian, French, Spanish, German etc etc, and you've got a whole lot
of pages that need to be migrated, managed, validated, etc.

I'm not saying it cannot be done... I am familiar with Confluence
Wikis... I have a fair idea what you can do in them.  I also have a
rough idea just how much work will need to be done to get the Wiki
docs migrated to Confluence.

Frank Peters also raised this point a couple of weeks ago... so I'm
not the only one raising a little white flag and saying this part of
the website migration is not going to be as easy as migrating basic MW
content. :-)

One other minor point... licensing shouldn't be a barrier for these
Doc Wiki pages regardless of what is done with them... all of the
Documentation subpages are either CC-By or PDL (or both). If a Doc
Wiki page isn't clearly licensed, then it doesn't belong, or needs to
be corrected.


C.
--
Clayton Cornell       ccorn...@openoffice.org
OpenOffice.org Documentation Project co-lead

Re: Website Content plus Look and Feel Improvements

[Pedro F. Giffuni]

FWIW,

I looked to see if a Wiki converter exists and I found this:

https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter

Probably not everything that's needed but quite a good start?

cheers,

Pedro.

--- On Sun, 7/3/11, Dave Fisher  wrote:

> From: Dave Fisher 
> Subject: Re: Website Content plus Look and Feel Improvements
> To: ooo-dev@incubator.apache.org
> Date: Sunday, July 3, 2011, 11:53 AM
> On Jul 3, 2011, at 3:51 AM, C wrote:
> 
> > On Sun, Jul 3, 2011 at 12:35, TJ Frazier 
> wrote:
> >> Moving the wiki is going to be a bear. I can only
> help with the cleanup
> >> afterward, since that merely requires some OO.o
> familiarity, and modest
> >> Confluence skill.
> > 
> > 
> > The documentation in the current MediaWiki instance
> has, as many of
> > you well know, some very deep dependencies on MW and
> on the various
> > extensions (custom written and standard).  I have
> a feeling that there
> > are quite a few people here who have no idea just how
> monumental of a
> > task that would be.  It will not be a "simple"
> import... it will
> > require a manual rework of a couple thousand pages of
> Wiki content
> > just to pull in the docs...
> 
> Please provide a few concrete examples of the thousands of
> pages that will need to be reworked. What features of
> MediaWiki are required and what is the purpose. Give me some
> of the gory details.
> 
> > The short of it is.. I'll help move the MediaWiki to a
> new server on
> > the Apache side (if the decision is made to do this),
> but I'm not
> > interested in moving the content to Confluence (if
> this is the final
> > decision).
> 
> The bar is much higher to add to Apache Infrastructure. It
> must be proven to Infrastructure that we have enough
> volunteers that can administer the service. Confluence is
> already present, as is the Apache CMS.
> 
> We have individuals with scripting abilities. If the wiki
> re-work is mechanical then we can script it.
> 
> Regards,
> Dave
> 
> > 
> > 
> > C.
> > --
> > Clayton Cornell       ccorn...@openoffice.org
> > OpenOffice.org Documentation Project co-lead
> 
> 
> co

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 3, 2011, at 11:16 AM, C wrote:

> On Sun, Jul 3, 2011 at 18:53, Dave Fisher  wrote:
>>> The short of it is.. I'll help move the MediaWiki to a new server on
>>> the Apache side (if the decision is made to do this), but I'm not
>>> interested in moving the content to Confluence (if this is the final
>>> decision).
>> 
>> Please provide a few concrete examples of the thousands of pages that will 
>> need to be reworked. What features of MediaWiki are required and what is the 
>> purpose. Give me some of the gory details.
>> 
>> The bar is much higher to add to Apache Infrastructure. It must be proven to 
>> Infrastructure that we have enough volunteers that can administer the 
>> service. Confluence is already present, as is the Apache CMS.
>> 
>> We have individuals with scripting abilities. If the wiki re-work is 
>> mechanical then we can script it.
>> 
>> Regards,
>> Dave
> 
> 
> A few example items... the existing/legacy MediaWiki instance is using
> several creative tweaks such as (not an exhaustive list.. just a few):
> 
> - PDF and ODT export.  Confluence can do PDF, but cannot do ODT..
> only MS Word DOC format (a significant issue in my view for an OOo
> Wiki... a bit sad and embarassing that we'd only be able to export a
> proprietary document format, and not the primary doc format that OOo
> is known for).  Export to PDF and ODT is something a lot of people use
> for the OOo Docs - especially the Basic and Developer's Guides.

I understand the need for ODT export. Tell us about the MediaWiki extension 
that is being used, is it part of OOo or is it a third party extension?

BTW - confluence uses an intermediate html format in its conversion to PDF. 
Perhaps that is something that AOOo could provide as an extension to confluence.

Or, maybe as part of an Apache CMS publishing and we can then contribute the 
facility to all of Apache.

> - Dynamic page lists - creates dynamic page set views of doc content.
> This is used for dynamically  indexing the FAQs for example.

A similar effect is possible in both Confluence and Apache CMS.

> - IDL Tags - custom (but simple) MW extension that creates links to
> the IDL library

Do you mean these links:

http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XTopWindowListener.html

We will need to rewrite these anyway. Tell me how these are marked up in 
MediaWiki.

Is the IDL reference generated from the source code? We'll need to get into 
that workflow too.

> As for the number of pages... start with the big one.. the Developer's
> Guide.  
> http://wiki.services.openoffice.org/wiki/Category:Documentation/Developer%27s_Guide
> This doc alone is approximately 1000 Wiki pages (something close to
> that... I don't know the exact number off the top of my head... it's
> around 2000 A4 pages when printed out or converted to PDF/ODT).  Like
> the other manuals in the existing/legacy OOo Wiki, it uses a
> combination of nested templates and various extensions to manage the
> subpages as a book.  It has a detailed TOC and navigation tree, IDL
> linking, etc.  This would all need to be stripped and adapted to
> convert to Confluence.  Each page would need to land in the right
> place in the document hierarchy.  Someone would need to write a
> Confluence macro or extension to handle the IDL tagging.  All the
> MediaWiki tagging would need to be converted and then someone
> would need to wade through the document and double check that it's
> still in a logical correct order, and tidy up the little oopses.

No doubt this is a challenge in Confluence - it likes a flat hierarchy.

If a MoinMoin Wiki is a better fit for conversion from MediaWiki we can 
certainly try it.

I am really for a scripted conversion no matter how we do it. We can test it on 
parts, make sure it fits everyone's needs, I expect this to be iterative and 
repeatable.

> Add to the list, the Basic Guide, the Reference Lists, and the
> FAQs/HowTos, plus whatever Doc pages have been translated into
> Russian, French, Spanish, German etc etc, and you've got a whole lot
> of pages that need to be migrated, managed, validated, etc.
> 
> I'm not saying it cannot be done... I am familiar with Confluence
> Wikis... I have a fair idea what you can do in them.  I also have a
> rough idea just how much work will need to be done to get the Wiki
> docs migrated to Confluence.

Each option does present challenges.

> Frank Peters also raised this point a couple of weeks ago... so I'm
> not the only one raising a little white flag and saying this part of
> the website migration is not going to be as easy as migrating basic MW
> content. :-)
> 
> One other minor point... licensing shouldn't be a barrier for these
> Doc Wiki pages regardless of what is done with them... all of the
> Documentation subpages are either CC-By or PDL (or both). If a Doc
> Wiki page isn't clearly licensed, then it doesn't belong, or needs to
> be corrected.

License due diligence is a key factor. Every page is going to n

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 3, 2011, at 12:01 PM, Pedro F. Giffuni wrote:

> FWIW,
> 
> I looked to see if a Wiki converter exists and I found this:
> 
> https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter
> 
> Probably not everything that's needed but quite a good start?

It sure does look like it is worth a try. It also looks like it may require 
some configuration within Kenai to get the export. If someone wants to get a 
proper export from Kenai's Media Wiki admins (or the proper access to run UWC).

I think we need to start with a single representative project and then work out 
the details for that before we do everything.

It is also worth noting that the UWC is AL2.0 licensed and can be modified.

I'll discuss the UWC with Apache Infrastructure.

Regards,
Dave

> 
> cheers,
> 
> Pedro.
> 
> --- On Sun, 7/3/11, Dave Fisher  wrote:
> 
>> From: Dave Fisher 
>> Subject: Re: Website Content plus Look and Feel Improvements
>> To: ooo-dev@incubator.apache.org
>> Date: Sunday, July 3, 2011, 11:53 AM
>> On Jul 3, 2011, at 3:51 AM, C wrote:
>> 
>>> On Sun, Jul 3, 2011 at 12:35, TJ Frazier 
>> wrote:
 Moving the wiki is going to be a bear. I can only
>> help with the cleanup
 afterward, since that merely requires some OO.o
>> familiarity, and modest
 Confluence skill.
>>> 
>>> 
>>> The documentation in the current MediaWiki instance
>> has, as many of
>>> you well know, some very deep dependencies on MW and
>> on the various
>>> extensions (custom written and standard).  I have
>> a feeling that there
>>> are quite a few people here who have no idea just how
>> monumental of a
>>> task that would be.  It will not be a "simple"
>> import... it will
>>> require a manual rework of a couple thousand pages of
>> Wiki content
>>> just to pull in the docs...
>> 
>> Please provide a few concrete examples of the thousands of
>> pages that will need to be reworked. What features of
>> MediaWiki are required and what is the purpose. Give me some
>> of the gory details.
>> 
>>> The short of it is.. I'll help move the MediaWiki to a
>> new server on
>>> the Apache side (if the decision is made to do this),
>> but I'm not
>>> interested in moving the content to Confluence (if
>> this is the final
>>> decision).
>> 
>> The bar is much higher to add to Apache Infrastructure. It
>> must be proven to Infrastructure that we have enough
>> volunteers that can administer the service. Confluence is
>> already present, as is the Apache CMS.
>> 
>> We have individuals with scripting abilities. If the wiki
>> re-work is mechanical then we can script it.
>> 
>> Regards,
>> Dave
>> 
>>> 
>>> 
>>> C.
>>> --
>>> Clayton Cornell   ccorn...@openoffice.org
>>> OpenOffice.org Documentation Project co-lead
>> 
>> 
>> co

Re: Website Content plus Look and Feel Improvements

[Jean Weber]

On Mon, Jul 4, 2011 at 05:39, Dave Fisher  wrote:
>
> It sure does look like it is worth a try. It also looks like it may require 
> some configuration within Kenai to get the export. If someone wants to get a 
> proper export from Kenai's Media Wiki admins (or the proper access to run 
> UWC).
>

I may be wrong, but I think we're mixing up two things here: the OOo
*website* (under Kenai) and the OOo *wiki* (under Mediawiki). I don't
think they are the same at all, and what needs to be done to bring
them into the Apache system isn't the same.

Clayton's recent posts have been about the *wiki* (after saying that
there is essentially nothing left on the website of importance in the
Documentation area).

>Tell us about the MediaWiki extension that is being used, is it part of OOo or 
>is it a third party extension?

AFAIK, it's a standard extension provided by MediaWiki, though I don't
know more details. Clayton or someone else can be more specific.

--Jean
Jean Hollis Weber
Co-Lead, OpenOffice.org Documentation

Re: Website Content plus Look and Feel Improvements

[Raphael Bircher]

Am 03.07.11 21:39, schrieb Dave Fisher:

On Jul 3, 2011, at 12:01 PM, Pedro F. Giffuni wrote:


FWIW,

I looked to see if a Wiki converter exists and I found this:

https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter

Probably not everything that's needed but quite a good start?

It sure does look like it is worth a try. It also looks like it may require 
some configuration within Kenai to get the export. If someone wants to get a 
proper export from Kenai's Media Wiki admins (or the proper access to run UWC).
To avoid missunderstanding, the Mediawiki from OOo is not located at the 
kenai infrastructure. I'ts on a separate server hosted at Hamburg. All 
webside located under (foobar).services.openoffice.org are external 
services outside the main infrastructure.



--
My private Homepage: http://www.raphaelbircher.ch/

Re: Website Content plus Look and Feel Improvements

[Jean Weber]

On Mon, Jul 4, 2011 at 04:16, C  wrote:
> On Sun, Jul 3, 2011 at 18:53, Dave Fisher  wrote:
>
> A few example items... the existing/legacy MediaWiki instance is using
> several creative tweaks such as (not an exhaustive list.. just a few):
>
>  - PDF and ODT export.  Confluence can do PDF, but cannot do ODT..
> only MS Word DOC format (a significant issue in my view for an OOo Wiki...

Even worse, AFAICT Confluence cannot export more than one wiki page at
a time to MS Word DOC format, which would make compiling a whole book
in that format a lot more difficult.

> Export to PDF and ODT is something a lot of people use
> for the OOo Docs - especially the Basic and Developer's Guides.
> [...]
> As for the number of pages... start with the big one.. the Developer's
> Guide.  This doc alone is approximately 1000 Wiki pages ...  Like
> the other manuals in the existing/legacy OOo Wiki, it uses a
> combination of nested templates and various extensions to manage the
> subpages as a book.
>
> Add to the list, the Basic Guide, the Reference Lists, and the
> FAQs/HowTos, plus whatever Doc pages have been translated into
> Russian, French, Spanish, German etc etc, and you've got a whole lot
> of pages that need to be migrated, managed, validated, etc.

Also all the user guides that are in wiki format contribute a lot of
pages. Some of those can (and probably should) be dropped (anything
for OOo 2.x, for example) but that may not make a significant dent in
the total. We could keep the PDFs and ODTs for the v2.x guides for
historical archives, but dump the wiki pages.

>
> Frank Peters also raised this point a couple of weeks ago... so I'm
> not the only one raising a little white flag and saying this part of
> the website migration is not going to be as easy as migrating basic MW
> content. :-)

--Jean
Jean Hollis Weber
Co-Lead, OpenOffice.org Documentation Project

Re: Website Content plus Look and Feel Improvements

[Kay Schenk]

On 07/03/2011 01:56 AM, Marcus (OOo) wrote:

Am 07/03/2011 07:43 AM, schrieb C:

On Sun, Jul 3, 2011 at 06:29, Graham Lauder
wrote:

On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:

Some projects are huge and others small. I downloaded several:

wave@minotaur:~/ooo-test$ ls -1
development
documentation
download
projects
www

The size is 2.7GB.

It would be good to come up with a scripted way to convert existing
webcontent to either mdtext, an altered html, or specialized
javascript and css. It is likely we can adapt the content and use
the Apache CMS to wrap a standard skeleton.

Regards, Dave




Much of what is on there is legacy material that could be seriously
pruned. For instance all the old Marketing material that is V2.0 and
earlier could be deleted.

Argument could be made for the marketing material to start from scratch.
Personally I'd like to see a whole new branding and get shot of the old
stuff, make the first Apache release: V4.0 (Historically, significant
global change has meant a whole number change in the version: V2 new
codebase, V3 Apple compatibility. I think this is significant enough:
pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
gives us a handle to hang a campaign on.


The majority of the documentation project content is not really stored
in the stuff that was downloaded in this test. What you find in the
web-content side is pretty much just pointers to the Wiki plus a few
files here and there that are not in the Wiki.

I would much more prefer that when the time comes to migrate content
of the documentation directory, that I simply tag which files are to
be transferred and the rest are pruned. I have spent time cleaning up
what's there, but there are still 10 years of legacy things still
laying about, not used anymore stuff that should not be copied
over.


I know that many things are simply outdated and could be deleted easily
without loosing value. However, when we grab the content from the Oracle
server, look into the content, and then decide if to take over and
publish or modify or delete, then we we have much to do and a longer
time no real content on our websites.

So, I would prefer to take over all content and make it public *) . Then
we can go through the content and add/modify/delete/whatever part-by-part.


yes! exactly...investigating ALL this now will take WAY too long.



*) After the license problems are solved.

My 2 ct

Marcus


--

MzK

"He's got that New Orleans thing crawling all over him, that good stuff,
 that 'We Are the Champions', to hell with the rest and
 I'll just start over kind of attitude."
  -- "1 Dead in the Attic", Chris Rose

Re: OOO and LibreOffice.

[Ted Rolle Jr.]

I've been a programmer for many years.  I've seen projects succeed and
projects fail.

Someone has said that managing programmers is akin to herding cats.

Programmers put blood, sweat, tears, and ego into their code (or at least
they should!).
For many programmers, their code is their art.
When this is the case, they - quite naturally - become protective of their
code.
With this philosophy/scenario, there can rarely be smooth roads.

One of the philosophies that I had the unfortunate experience of working
under was 'egoless code'.
Yeah, sure.
Sounded good to the managers.  It rarely worked in reality.


One strategy that kinda/sorta worked was "code walkthroughs".
It was understood beforehand that these were code walkthroughs, *not* "code
walkons".
The programmer invited other programmers to a conference where they could
comment on (not criticize!) the programmer's code.
The invitees did not need to be familiar with the project.
It brought the programmer out of the solitary environment that we get into.
It was, for the most part, a learning opportunity for all involved.
It also increased respect for other's coding ability.


Another suggestion is that the teams pursue a common,
*well-defined*cooperative (read: non-competitive!) objective.

On Sun, Jul 3, 2011 at 2:50 AM, Ross Gardler wrote:

> Hi Ted,
>
> I think the warning in your mail should be heeded. Whilst there are
> opportunities and established practices for collaboration on shared
> code, ensuring the collaboration happens can be difficult. It requires
> a certain level of humility, patience and effort on the part of all
> involved.
>
> Since you are obviously concerned about this do you have any ideas
> that can help us develop the right relationship for collaboration
> between the different parties involved?
>
> Ross
>

Re: Releasing OOo 3.4 on the old infrastructure

[Kay Schenk]

On 07/03/2011 10:35 AM, Alexandro Colorado wrote:

On Sun, Jul 3, 2011 at 11:27 AM, Andrea Pescettiwrote:


On 19/06/2011 Andrea Pescetti wrote:

Would it be possible to release OOo 3.4 on the old (Oracle-owned)
infrastructure, and maybe take advantage of this release to educate
users and volunteers about the coming new infrastructure at Apache?
... I take for granted that the community would support this proposal
(for one, the Italian community spent weeks to get the OOo 3.4 strings
100% translated into Italian, and our QA team is ready to start full
testing any moment). Would developers and release managers support this
too?


All reactions on this old mail I sent have been positive, but we still
miss an answer from developers. In my opinion this is an occasion not to
miss for at least the following three reasons, comments welcome.

1) Releasing OpenOffice.org 3.4 must not be seen as the last activity on
   the old infrastructure, but as the first activity of the new Apache
   project. Dozens of tools are used to coordinate an OOo release, and
   for us experienced OOo volunteers it will surely be better to explain
   and revise tools and processes in front of a concrete example rather
   than describing them in abstract to new members.

2) OpenOffice.org 3.4 is mostly ready. I built the latest code from hg
   a couple weeks ago and I've regularly used it so far. The quality is
   good and there is no risk of damaging the OOo reputation. All
   release stoppers are bugs that will have to be fixed anyway, and
   fixing them later will require the same amount of time.

3) The amazing people who joined this project cover all areas needed
   for a successful release. This is the only group that can coordinate
   a successful release (bugfixing, QA, distribution) of OpenOffice.org
   3.4, and use the experience to educate old and new community members
   to the Apache way and, on the other side, to the OOo processes.

We have a huge community that is ready now and that becomes very active
only when a release is in sight (and that would surely be committed to
extra effort, if needed, this time): it would be a risky move, both for
communication and for involvement of volunteers, to have them waiting
for a long time before we can ask them to help us release a new version.

Any reasons not to try?


Well, I'm not exactly sure what you're referring to at this moment. 
Actually putting new code on Apache? and then, can you detail how you 
think it will get distributed to end users if this was done? Right now, 
the whole "download" process on the old OO.o site is really VERY 
involved. So, this is why I'm asking.


From my perspective as an end user, I would rather stay with what I 
know where I know it (the existing site) and have it work rather than not.




Regards,
   Andrea.



Well Joost (QA Manager) is not on the list, although I saw Stefan Taxteh
submiting for an apache ID which means he is around. I wonder who would be
needed to speak on this.




--

MzK

"He's got that New Orleans thing crawling all over him, that good stuff,
 that 'We Are the Champions', to hell with the rest and
 I'll just start over kind of attitude."
  -- "1 Dead in the Attic", Chris Rose

Re: OOO and LibreOffice.

[Ross Gardler]

On 3 July 2011 23:29, Ted Rolle Jr.  wrote:
> I've been a programmer for many years.  I've seen projects succeed and
> projects fail.
>
> Someone has said that managing programmers is akin to herding cats.
>
> Programmers put blood, sweat, tears, and ego into their code (or at least
> they should!).
> For many programmers, their code is their art.
> When this is the case, they - quite naturally - become protective of their
> code.
> With this philosophy/scenario, there can rarely be smooth roads.
>
> One of the philosophies that I had the unfortunate experience of working
> under was 'egoless code'.
> Yeah, sure.
> Sounded good to the managers.  It rarely worked in reality.

The Apache Way is all about what some might call "ego-less code".
However, this project does face a different issue, not commonly found
in other ASF projects.

How do we work with the community split between OOo and LO. It would
be great if we could get past ego and work together. But before we can
get to that point we need to address the technical differences between
the two code bases. LO is already 8 months or so adrift of OOo (or at
least that is what I am led to believe).

At present the only way I can see to start doing this is to a) drop
the ego on both "sides", this is a different world from the one in
which the fork was seen as necessary. There are still fundamental
licence differences, but I am sure that, for many, the licence is less
important than getting results. b) spending some time understanding
one another (for some that will mean rebuilding relationships) in
order to work towards your second suggestion...

> Another suggestion is that the teams pursue a common, well-defined
> cooperative (read: non-competitive!) objective.

I don't know OOo or LO well enough to know if there is scope for a
"common, well-defined cooperative objective." It would be great if
some people could spend some time considering this. It might well be
that there is little scope for true collaboration. However, during the
proposal phase there were a few people who wanted to explore this.

What happened to the plan for OOo and TDF people to get together?

Ross

>
> On Sun, Jul 3, 2011 at 2:50 AM, Ross Gardler 
> wrote:
>>
>> Hi Ted,
>>
>> I think the warning in your mail should be heeded. Whilst there are
>> opportunities and established practices for collaboration on shared
>> code, ensuring the collaboration happens can be difficult. It requires
>> a certain level of humility, patience and effort on the part of all
>> involved.
>>
>> Since you are obviously concerned about this do you have any ideas
>> that can help us develop the right relationship for collaboration
>> between the different parties involved?
>>
>> Ross
>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 3, 2011, at 2:14 PM, Jean Weber wrote:

> On Mon, Jul 4, 2011 at 04:16, C  wrote:
>> On Sun, Jul 3, 2011 at 18:53, Dave Fisher  wrote:
>> 
>> A few example items... the existing/legacy MediaWiki instance is using
>> several creative tweaks such as (not an exhaustive list.. just a few):
>> 
>>  - PDF and ODT export.  Confluence can do PDF, but cannot do ODT..
>> only MS Word DOC format (a significant issue in my view for an OOo Wiki...
> 
> Even worse, AFAICT Confluence cannot export more than one wiki page at
> a time to MS Word DOC format, which would make compiling a whole book
> in that format a lot more difficult.

It is very cumbersome, but it is possible to export all or part of a space to 
PDF in Confluence - The function is found on the Advanced page.


> 
>> Export to PDF and ODT is something a lot of people use
>> for the OOo Docs - especially the Basic and Developer's Guides.
>> [...]
>> As for the number of pages... start with the big one.. the Developer's
>> Guide.  This doc alone is approximately 1000 Wiki pages ...  Like
>> the other manuals in the existing/legacy OOo Wiki, it uses a
>> combination of nested templates and various extensions to manage the
>> subpages as a book.
>> 
>> Add to the list, the Basic Guide, the Reference Lists, and the
>> FAQs/HowTos, plus whatever Doc pages have been translated into
>> Russian, French, Spanish, German etc etc, and you've got a whole lot
>> of pages that need to be migrated, managed, validated, etc.
> 
> Also all the user guides that are in wiki format contribute a lot of
> pages. Some of those can (and probably should) be dropped (anything
> for OOo 2.x, for example) but that may not make a significant dent in
> the total. We could keep the PDFs and ODTs for the v2.x guides for
> historical archives, but dump the wiki pages.

Good.

Regards,
Dave

> 
>> 
>> Frank Peters also raised this point a couple of weeks ago... so I'm
>> not the only one raising a little white flag and saying this part of
>> the website migration is not going to be as easy as migrating basic MW
>> content. :-)
> 
> --Jean
> Jean Hollis Weber
> Co-Lead, OpenOffice.org Documentation Project

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 3, 2011, at 2:03 PM, Jean Weber wrote:

> On Mon, Jul 4, 2011 at 05:39, Dave Fisher  wrote:
>> 
>> It sure does look like it is worth a try. It also looks like it may require 
>> some configuration within Kenai to get the export. If someone wants to get a 
>> proper export from Kenai's Media Wiki admins (or the proper access to run 
>> UWC).
>> 
> 
> I may be wrong, but I think we're mixing up two things here: the OOo
> *website* (under Kenai) and the OOo *wiki* (under Mediawiki). I don't
> think they are the same at all, and what needs to be done to bring
> them into the Apache system isn't the same.

Thanks, this is very helpful. I am currently thinking that we should fold 
website/Kenai content towards a combination of mdtext, html, javascript and css 
into the current podling website.

> 
> Clayton's recent posts have been about the *wiki* (after saying that
> there is essentially nothing left on the website of importance in the
> Documentation area).

Good point. Let's separate the efforts. It looks like the website is a larger 
effort.

Raphael attached some directory listings for the foreign language sites. These 
look like they are made to parallel the main openoffice.org website.

Back to the website.

(1) An initial test could focus on the current main page in English followed by 
versions in several languages. This will need to script the conversion of 
existing webcontent from Kenai into format for the Apache CMS.

(2) A second focus would be on the Kenai content for one of the product 
development areas. This script may be substantially different.

(3) A third focus would be building the documentation area. If a wiki is 
preferred then we should create a website page that provides good links.

(4) A fourth focus for the website migration is how to best integrate the 
project's choices for Bugzilla or JIRA, user forums, and mailing lists.

>> Tell us about the MediaWiki extension that is being used, is it part of OOo 
>> or is it a third party extension?
> 
> AFAIK, it's a standard extension provided by MediaWiki, though I don't
> know more details. Clayton or someone else can be more specific.

(5) MediaWiki to Apache Wiki can be a separate effort as described in another 
part of this thread.

Regards,
Dave


> 
> --Jean
> Jean Hollis Weber
> Co-Lead, OpenOffice.org Documentation

Re: Website Content plus Look and Feel Improvements

[Dave Fisher]

On Jul 3, 2011, at 2:06 PM, Raphael Bircher wrote:

> Am 03.07.11 21:39, schrieb Dave Fisher:
>> On Jul 3, 2011, at 12:01 PM, Pedro F. Giffuni wrote:
>> 
>>> FWIW,
>>> 
>>> I looked to see if a Wiki converter exists and I found this:
>>> 
>>> https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter
>>> 
>>> Probably not everything that's needed but quite a good start?
>> It sure does look like it is worth a try. It also looks like it may require 
>> some configuration within Kenai to get the export. If someone wants to get a 
>> proper export from Kenai's Media Wiki admins (or the proper access to run 
>> UWC).
> To avoid missunderstanding, the Mediawiki from OOo is not located at the 
> kenai infrastructure. I'ts on a separate server hosted at Hamburg. All 
> webside located under (foobar).services.openoffice.org are external services 
> outside the main infrastructure.

Thanks, I was confused by that. It would be good to see if they will support an 
UWC export for testing.

Regards,
Dave

> 
> 
> -- 
> My private Homepage: http://www.raphaelbircher.ch/

RE: OOO and LibreOffice (and common interests).

[Dennis E. Hamilton]

Probably the first time for Apache/OOo folk and TDF folk to talk together will 
be in conjunction with the Berlin Plugfest, July 14-15.

I can imagine common cause around how discretionary provisions of ODF are 
handled in the implementations and how the implementation-dependent variability 
is handled in an interoperable way.

I also suspect there is a good basis for dealing with document authenticity 
(digital signature and alteration protection) issues and related issues with 
regard to security as well as interoperability considerations around the 
document-encryption approach.

These are areas for which I believe broad-community engagement works at finding 
common solutions.  There are similar prospects around repair of change-tracking 
in an interoperable manner and also on the expressed need for font embedding.

Finally, QA and especially test fixtures might be a fruitful area.  It's not as 
if there is an oversupply of willing contributors in these areas that we can't 
benefit from shared efforts.

 - Dennis

-Original Message-
From: Ross Gardler [mailto:rgard...@opendirective.com] 
Sent: Sunday, July 03, 2011 15:44
To: ster...@gmail.com
Cc: ooo-dev@incubator.apache.org
Subject: Re: OOO and LibreOffice.

On 3 July 2011 23:29, Ted Rolle Jr.  wrote:
> I've been a programmer for many years.  I've seen projects succeed and
> projects fail.

[ ... ]
The Apache Way is all about what some might call "ego-less code".
However, this project does face a different issue, not commonly found
in other ASF projects.

How do we work with the community split between OOo and LO. It would
be great if we could get past ego and work together. But before we can
get to that point we need to address the technical differences between
the two code bases. LO is already 8 months or so adrift of OOo (or at
least that is what I am led to believe).

At present the only way I can see to start doing this is to a) drop
the ego on both "sides", this is a different world from the one in
which the fork was seen as necessary. There are still fundamental
licence differences, but I am sure that, for many, the licence is less
important than getting results. b) spending some time understanding
one another (for some that will mean rebuilding relationships) in
order to work towards your second suggestion...

> Another suggestion is that the teams pursue a common, well-defined
> cooperative (read: non-competitive!) objective.

I don't know OOo or LO well enough to know if there is scope for a
"common, well-defined cooperative objective." It would be great if
some people could spend some time considering this. It might well be
that there is little scope for true collaboration. However, during the
proposal phase there were a few people who wanted to explore this.

What happened to the plan for OOo and TDF people to get together?

Ross

[ ... ]

Re: Releasing OOo 3.4 on the old infrastructure

[Rob Weir]

On Sun, Jun 19, 2011 at 6:23 AM, Andrea Pescetti
 wrote:
> I understand that the necessary code reorganization in the Apache
> project will forbid a public release for months.
>

Aside from the obvious technical tasks of producing code, translation
and documentation, a release at Apache has specific procedural
requirements.  As a Podling project, under incubation, we have
additional requirements.  I'd urge project members to take a quick
read over the following "A Guide to Release Management During
Incubation" for an idea of what is needed:

http://incubator.apache.org/guides/releasemanagement.html


So yes, a release at Apache will take a good deal of time.  But to me
this is work that is best not delayed.  We cannot avoid it.  We need
to deal with these topics, and the earlier we start, the sooner we
will finish.

> On the other hand, OpenOffice.org 3.4 beta has been out for several
> weeks, is regarded by our QA testers as remarkably stable, has a
> dedicated code line and it is not far from release.
>

This is great to know.  This means that we will not need to spend a
lot of time making the code stable.  But we'll have other things to
do, like removing GPL dependencies, etc.  So some I'd expect that
changing of that magnitude will introduce (at least initially) new
bugs.  So it might be reasonable to have a 2nd beta once we have a
clean build.

> Would it be possible to release OOo 3.4 on the old (Oracle-owned)
> infrastructure, and maybe take advantage of this release to educate
> users and volunteers about the coming new infrastructure at Apache?
>

I don't see how this could be possible for this Apache project to do this.

> This shouldn't require an exceptional effort and it would allow to show
> that OpenOffice.org it in good shape and to use the momentum of a new
> release to communicate better the transition to Apache. Otherwise we
> really risk to confuse users and let them feel abandoned, and work on
> the incubator in the next months could be less useful.
>

If user confusion is a concern, maybe we should address that directly?
 For example, it is possible for this project to have a blog, where we
could explain what were are doing and what the plan was.  This
assumes, of course, that we first agree upon a plan.

> It really seems a small effort compared to the major code refactoring
> needed at Apache, and I believe Oracle can state that the bugfixes on
> the OOo 3.4 code line will be granted to Apache too. And the benefits
> for users and communication would be immense.
>

I don't disagree with you that completing OOo 3.4 on the existing
infrastructure would be easier.  I just believe that we should not
avoid the hard work of migration any longer.


> Now, I take for granted that the community would support this proposal
> (for one, the Italian community spent weeks to get the OOo 3.4 strings
> 100% translated into Italian, and our QA team is ready to start full
> testing any moment). Would developers and release managers support this
> too?
>

Again, I don't see how it would be possible for an Apache project to
do this.  Of course, if a group outside of Apache wishes to do
something, with the current infrastructure and current code with
current license, then that is a different question.  But maybe you
should bring this up on the OOo mailing list?

Regards,

-Rob

> Regards,
>  Andrea.
>
>

Re: OOO and LibreOffice.

[Simon Phipps]

On 3 Jul 2011, at 19:43, Ross Gardler wrote:

> But before we can
> get to that point we need to address the technical differences between
> the two code bases. LO is already 8 months or so adrift of OOo (or at
> least that is what I am led to believe).

It's worth observing that the code that new developers will be able to work on 
at Apache is also likely to have significant differences from the last release 
from the Sun/Oracle infrastructure, as well as a completely different workflow. 
I suspect we'll all have no choice but to accept there's a lot of refactoring 
and relearning to do whatever happens.

> What happened to the plan for OOo and TDF people to get together?

We attempted it here at FISL and had a good turnout to the sessions Jomar Silva 
organised (and which I attended too). The result is a commitment (in the form 
of a letter of intent signed by on behalf of the responsible minister) by the 
Brazilian government to invest in both AOOo and LibreOffice. I hope we'll have 
a news posting about it early in the week. 

It's tough, because there's a lot of emotion and history on both "sides", but I 
agree with Jomar that it's possible to devise ways to work together. One 
challenge we'll have with the new developers that Brazil will commit will be 
getting engaged with the codebase. We think a great way for them to do that now 
(rather than at an unknown point in the future) is to use the "Easy Hacks" page 
that LibreOffice has put together to go start work on the code now. 

I suggest we encourage others to do the same.  Doing so is educational and 
co-operative, and TDF are perfectly happy to accept contributions under the 
Apache license.

S.


[1] http://wiki.documentfoundation.org/Development/Easy_Hacks

Re: OOO and LibreOffice.

[Rob Weir]

On Sun, Jul 3, 2011 at 8:40 PM, Simon Phipps  wrote:
>
> On 3 Jul 2011, at 19:43, Ross Gardler wrote:
>
>> But before we can
>> get to that point we need to address the technical differences between
>> the two code bases. LO is already 8 months or so adrift of OOo (or at
>> least that is what I am led to believe).
>
> It's worth observing that the code that new developers will be able to work 
> on at Apache is also likely to have significant differences from the last 
> release from the Sun/Oracle infrastructure, as well as a completely different 
> workflow. I suspect we'll all have no choice but to accept there's a lot of 
> refactoring and relearning to do whatever happens.
>
>> What happened to the plan for OOo and TDF people to get together?
>
> We attempted it here at FISL and had a good turnout to the sessions Jomar 
> Silva organised (and which I attended too). The result is a commitment (in 
> the form of a letter of intent signed by on behalf of the responsible 
> minister) by the Brazilian government to invest in both AOOo and LibreOffice. 
> I hope we'll have a news posting about it early in the week.
>
> It's tough, because there's a lot of emotion and history on both "sides", but 
> I agree with Jomar that it's possible to devise ways to work together. One 
> challenge we'll have with the new developers that Brazil will commit will be 
> getting engaged with the codebase. We think a great way for them to do that 
> now (rather than at an unknown point in the future) is to use the "Easy 
> Hacks" page that LibreOffice has put together to go start work on the code 
> now.
>
> I suggest we encourage others to do the same.  Doing so is educational and 
> co-operative, and TDF are perfectly happy to accept contributions under the 
> Apache license.
>

Simon,

Any chance of TDF requiring Apache 2.0 for new code contributions, in
addition to their current requirement for LGPL/MPL?  My reading of
their rules suggests that a simple majority of their Steering
Committee authorize such a change.  Doing so would open up many more
possibilities for future collaboration and cooperation.  Not doing so
would severely constrain possibilities for cooperation.

-Rob

> S.
>
>
> [1] http://wiki.documentfoundation.org/Development/Easy_Hacks

Re: Releasing OOo 3.4 on the old infrastructure

[Kazunari Hirano]

Hi all,

Don't you fast on Saturday?
:)
We are in Rome.

Thanks,
khirano

Re: svn commit: r1142528 - in /incubator/ooo/trunk/tools/dev: fetch-all-web.sh web-list.txt

[Dave Fisher]

This is a script and text file for fetching and maintaining an svn checkout of 
many OOo project's Kenai webcontent.

I followed the same pattern for the script and text file as Greg did for the 
CWS Mercurial pulls.

dave$ ./fetch-all-web.sh web-list.txt ~/Documents/webtest
 './projects' exists. Updating ...
At revision 3.
 './www' exists. Updating ...
At revision 53.
 './download' exists. Updating ...
At revision 296.
 './development' exists. Updating ...
At revision 15.

Regards,
Dave

On Jul 3, 2011, at 5:48 PM, w...@apache.org wrote:

> Author: wave
> Date: Mon Jul  4 00:48:01 2011
> New Revision: 1142528
> 
> URL: http://svn.apache.org/viewvc?rev=1142528&view=rev
> Log:
> A script for pulling webcontent from Kenai's svn repos plus the start to the 
> web-project list. The script follows the pattern of fetch-all-cws.sh. It is a 
> similar process.
> 
> Added:
>incubator/ooo/trunk/tools/dev/fetch-all-web.sh   (with props)
>incubator/ooo/trunk/tools/dev/web-list.txt   (with props)
> 
> Added: incubator/ooo/trunk/tools/dev/fetch-all-web.sh
> URL: 
> http://svn.apache.org/viewvc/incubator/ooo/trunk/tools/dev/fetch-all-web.sh?rev=1142528&view=auto
> ==
> --- incubator/ooo/trunk/tools/dev/fetch-all-web.sh (added)
> +++ incubator/ooo/trunk/tools/dev/fetch-all-web.sh Mon Jul  4 00:48:01 2011
> @@ -0,0 +1,81 @@
> +#!/bin/sh
> +#
> +# Licensed to the Apache Software Foundation (ASF) under one
> +# or more contributor license agreements.  See the NOTICE file
> +# distributed with this work for additional information
> +# regarding copyright ownership.  The ASF licenses this file
> +# to you under the Apache License, Version 2.0 (the
> +# "License"); you may not use this file except in compliance
> +# with the License.  You may obtain a copy of the License at
> +#
> +#   http://www.apache.org/licenses/LICENSE-2.0
> +#
> +# Unless required by applicable law or agreed to in writing,
> +# software distributed under the License is distributed on an
> +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> +# KIND, either express or implied.  See the License for the
> +# specific language governing permissions and limitations
> +# under the License.
> +#
> +
> +#
> +# Use this script to fetch all a project's webcontent for the projects
> +# listed in the specified file (typically, webcontent-list.txt).
> +#
> +# See https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap
> +# for a note on the checkout from the Kenai svn repository.
> +#
> +# USAGE:
> +#   $ ./fetch-all-web.sh WEB-LIST WORK-DIR
> +#
> +# WEB-LIST is a file containing the list of Projects to fetch
> +#   (see the file tools/dev/webcontent-list.txt)
> +# WORK-DIR each project's webcontent will be created in a
> +#   subdirectory of WORK-DIR
> +#
> +#  Future steps will include scripts to transform the content for
> +#  the Apache CMS or a Confluence Wiki import
> +#
> +
> +if test "$#" != 2; then
> +  echo "USAGE: $0 WEB-LIST WORK-DIR"
> +  exit 1
> +fi
> +
> +REPOS='https://svn.openoffice.org/svn/'
> +REPOS2='~webcontent'
> +
> +# Make the work directory, in case it does not exist
> +if test ! -e "$2"; then
> +  mkdir "$2"
> +fi
> +
> +# Turn the parameters into absolute paths
> +work=`(cd "$2" ; pwd)`
> +
> +webdir=`dirname "$1"`
> +webfile=`basename "$1"`
> +weblist=`(cd "$webdir" ; pwd)`/$webfile
> +
> +
> +for webproject in `grep '^./' $weblist` ; do
> +  cd "$work"
> +
> +  webrepos=${REPOS}${webproject}${REPOS2}
> +
> +  if test -d "$webproject" ; then
> +echo " '$project' exists. Updating ..."
> +cd "$webproject"
> +svn update
> +
> +  elif test -e "$webproject" ; then
> +echo "ERROR: '$webproject' exists and is not a directory."
> +exit 1
> +
> +  # filter out empty CWS: hg incoming returns 1 if there's nothing to pull
> +  else
> +echo " '$webproject' is being created ..."
> +svn co $webrepos $webproject
> +  fi
> +
> +done
> 
> Propchange: incubator/ooo/trunk/tools/dev/fetch-all-web.sh
> --
>svn:eol-style = native
> 
> Propchange: incubator/ooo/trunk/tools/dev/fetch-all-web.sh
> --
>svn:executable = *
> 
> Added: incubator/ooo/trunk/tools/dev/web-list.txt
> URL: 
> http://svn.apache.org/viewvc/incubator/ooo/trunk/tools/dev/web-list.txt?rev=1142528&view=auto
> ==
> --- incubator/ooo/trunk/tools/dev/web-list.txt (added)
> +++ incubator/ooo/trunk/tools/dev/web-list.txt Mon Jul  4 00:48:01 2011
> @@ -0,0 +1,35 @@
> +#
> +# Licensed to the Apache Software Foundation (ASF) under one
> +# or more contributor license agreements.  See the NOTICE file
> +# distributed with this work for additional information
> 

Re: OOO and LibreOffice.

[Simon Phipps]

On Sun, Jul 3, 2011 at 10:03 PM, Rob Weir  wrote:

> On Sun, Jul 3, 2011 at 8:40 PM, Simon Phipps  wrote:
> >
> > On 3 Jul 2011, at 19:43, Ross Gardler wrote:
> >
> >> But before we can
> >> get to that point we need to address the technical differences between
> >> the two code bases. LO is already 8 months or so adrift of OOo (or at
> >> least that is what I am led to believe).
> >
> > It's worth observing that the code that new developers will be able to
> work on at Apache is also likely to have significant differences from the
> last release from the Sun/Oracle infrastructure, as well as a completely
> different workflow. I suspect we'll all have no choice but to accept there's
> a lot of refactoring and relearning to do whatever happens.
> >
> >> What happened to the plan for OOo and TDF people to get together?
> >
> > We attempted it here at FISL and had a good turnout to the sessions Jomar
> Silva organised (and which I attended too). The result is a commitment (in
> the form of a letter of intent signed by on behalf of the responsible
> minister) by the Brazilian government to invest in both AOOo and
> LibreOffice. I hope we'll have a news posting about it early in the week.
> >
> > It's tough, because there's a lot of emotion and history on both "sides",
> but I agree with Jomar that it's possible to devise ways to work together.
> One challenge we'll have with the new developers that Brazil will commit
> will be getting engaged with the codebase. We think a great way for them to
> do that now (rather than at an unknown point in the future) is to use the
> "Easy Hacks" page that LibreOffice has put together to go start work on the
> code now.
> >
> > I suggest we encourage others to do the same.  Doing so is educational
> and co-operative, and TDF are perfectly happy to accept contributions under
> the Apache license.
> >
>
> Simon,
>
> Any chance of TDF requiring Apache 2.0 for new code contributions, in
> addition to their current requirement for LGPL/MPL?  My reading of
> their rules suggests that a simple majority of their Steering
> Committee authorize such a change.  Doing so would open up many more
> possibilities for future collaboration and cooperation.  Not doing so
> would severely constrain possibilities for cooperation.
>

It's certainly worth asking, although I believe their current LGPLv3+MPL
policy is more a suggestion than a requirement so it would ultimately be up
to each contributor. Perhaps you could ask on the steering-discuss list[1]?


S.



[1]  http://listarchives.documentfoundation.org/www/steering-discuss/

Re: OOO and LibreOffice.

[Andy Brown]

Simon Phipps wrote:
> 
> It's certainly worth asking, although I believe their current LGPLv3+MPL
> policy is more a suggestion than a requirement so it would ultimately be up
> to each contributor. Perhaps you could ask on the steering-discuss list[1]?
> 
> 
> S.
> 
> 
> 
> [1]  http://listarchives.documentfoundation.org/www/steering-discuss/
> 

As each developer retains ownership of their code it maybe better to ask
on the developers list [1].  The SC has no control over the devs.

[1] libreoff...@lists.freedesktop.org

Andy

Re: Incubator PMC/Board report for July 2011 (ooo-dev@incubator.apache.org)

[Rob Weir]

Mentors, how is this report typically handled by the PPMC? Can a PPMC
member just draft it and seek lazy consensus to submit?  Or does this
require an explicit PPMC vote?


-Rob

On Fri, Jul 1, 2011 at 10:00 AM,   wrote:
> Dear OpenOffice.org Developers,
>
> This email was sent by an automated system on behalf of the Apache Incubator 
> PMC.
> It is an initial reminder to give you plenty of time to prepare your quarterly
> board report.
>
> The board meeting is scheduled for  Wed, 20 July 2011, 10 am Pacific. The 
> report
> for your podling will form a part of the Incubator PMC report. The Incubator 
> PMC
> requires your report to be submitted one week before the board meeting, to 
> allow
> sufficient time for review.
>
> Please submit your report with sufficient time to allow the incubator PMC, and
> subsequently board members to review and digest. Again, the very latest you
> should submit your report is one week prior to the board meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
> --
>
> Your report should contain the following:
>
>  * Your project name
>  * A brief description of your project, which assumes no knowledge of the 
> project
>   or necessarily of its field
>  * A list of the three most important issues to address in the move towards
>   graduation.
>  * Any issues that the Incubator PMC or ASF Board might wish/need to be aware 
> of
>  * How has the community developed since the last report
>  * How has the project developed since the last report.
>
> This should be appended to the Incubator Wiki page at:
>
>  http://wiki.apache.org/incubator/July2011
>
> Note: This manually populated. You may need to wait a little before this page 
> is
>      created from a template.
>
> Mentors
> ---
> Mentors should review reports for their project(s) and sign them off on the
> Incubator wiki page. Signing off reports shows that you are following the
> project - projects that are not signed may raise alarms for the Incubator PMC.
>
> Incubator PMC
>
>

Uh oh: OpenOffice.org XML Namespaces and Sun Mediatypes

[Dennis E. Hamilton]

It just occurred to me that a place for some sort of common agreement, and 
publication of what they mean, are the OpenOffice.org Namespaces.  I assume 
these "belong" to OpenOffice.org, but governance of namespaces is odd business. 
 These are also something to coordinate with the LibreOffice folk and others 
who use these namespaces for any purpose.  Most of all, they need to be defined.

(This occurred to me reading about macro-recording in LibreOffice Calc, and it 
flashed before my eyes that this is an implementation-dependent feature 
introduced by an (undocument as far as I know) namespace binding:

Here is the bunch that tend to be spit out in the beginning of ODF files used 
within packages as part of fixed boilerplate in the root element:

xmlns:ooo="http://openoffice.org/2004/office"; 

xmlns:oooc="http://openoffice.org/2004/calc";

xmlns:ooow="http://openoffice.org/2004/writer"; 

xmlns:rpt="http://openoffice.org/2005/report"; 

xmlns:tableooo="http://openoffice.org/2009/table";

The URIs all generate 404s.

There are significant uses as in establishment of 





where the attribute values are QNames and they introduce a pot-full of 
unqualified item names that are specific to the QNames, above.

And then there are MIME media types:

application/vnd.sun.xml.ui.configuration

for a subdocument "Configurations2/" in ODF packages produced by 
*OpenOffice.org producers.

There are other application/vnd.sun MIME media types in use as well.

 - Dennis

Re: OOO and LibreOffice.

[André Schnabel]

Hi Rob,


Am 04.07.2011 03:03, schrieb Rob Weir:


Any chance of TDF requiring Apache 2.0 for new code contributions, in
addition to their current requirement for LGPL/MPL?


You asked this already, and afair I did answer on that.

Although formally the SC can decide on this, I (with my hat as SC 
member) would veto any such decision that is not done by the TDF 
members.  It does not matter at all what the SC decides, when current 
developers stop contributing because we enforce apache license.


Although I like the idea of collaboration I would surely not advice our 
(TDF) members to stop working just to be able to collaborate.


regards,

André

Re: Website Content plus Look and Feel Improvements

[Jean Hollis Weber]

On Sun, 2011-07-03 at 16:08 -0700, Dave Fisher wrote:
> On Jul 3, 2011, at 2:14 PM, Jean Weber wrote:
> 
> > On Mon, Jul 4, 2011 at 04:16, C  wrote:
> >> On Sun, Jul 3, 2011 at 18:53, Dave Fisher  wrote:
> >> 
> >> A few example items... the existing/legacy MediaWiki instance is using
> >> several creative tweaks such as (not an exhaustive list.. just a few):
> >> 
> >>  - PDF and ODT export.  Confluence can do PDF, but cannot do ODT..
> >> only MS Word DOC format (a significant issue in my view for an OOo Wiki...
> > 
> > Even worse, AFAICT Confluence cannot export more than one wiki page at
> > a time to MS Word DOC format, which would make compiling a whole book
> > in that format a lot more difficult.
> 
> It is very cumbersome, but it is possible to export all or part of a space to 
> PDF in Confluence - The function is found on the Advanced page.

PDFs exported from a wiki may be convenient for individuals wanting a
copy of info but not concerned about its appearance. They are not of an
acceptable quality for publishing as a book, particularly if they
contain images -- or at least I have never seen one that was acceptable,
by which I mean looking like a reasonably professional publication. 

We (people producing user guides) need to be able to get editable
documents that can be massaged into an acceptable form before exporting
to PDF. Indeed, that is one of the major reasons why we want the user
guides to be maintained in ODT, not wiki form.

> > 
> >> Export to PDF and ODT is something a lot of people use
> >> for the OOo Docs - especially the Basic and Developer's Guides.
> >> [...]
> >> 

Those are the books maintained on the wiki, with input from the
developers. They don't have many images. Getting a reasonable result
from the export is still challenging, but Clayton (and whoever else has
worked on this) has done a heroic job creating templates for export from
MediaWiki. 

--Jean