date:20110706

On Sat, Jul 2, 2011 at 12:45, Michael Stahl m...@openoffice.org wrote:
...
 Once we have a better picture of what is ready or not cws-list.txt needs
 to be updated.

 i think the goal is to migrate all open CWSes, because perhaps there's still
 something useful in there, and we don't have time to investigate every CWS
 now.

Right. Migrating them all into Subversion for later review is best. We
can always 'rm' the branch if the CWS is determined to be useless.

...
 just tried it out, and it took 80 minutes to produce a 2.6 GB repo with 178
 bookmarks.
 indeed a lot of bookmarks are duplicated, as described above.

 tweaked it a bit, see attachment.

You have commit privs. Apply your fixes right away. We don't need to
review your patch first. Remember: Commit-Then-Review. This will get
things done a lot faster.

The development process that OOo used to use, as I understand it,
looks incredibly heavyweight and slow moving. At Apache, you commit
your changes. If you have a large-ish feature you're unsure about,
then discuss it on the mailing list, and (maybe) go start a branch. In
many cases, it is possibly to develop even large features on trunk
because you can hide it or make it have near-zero impact on the main
trunk code.

Cheers,
-g

Re: fetch-all-cws.sh

2011-07-06 Thread Herbert Duerr



 [...] Speaking of merges in SVN we regularly had the problem that a
 file was renamed in one CWS and changed in another CWS and the result
 was that the change got lost. HG or GIT handle this scenario much
 more gracefully, so there was less risk to do big merges.

 indeed, which led to effectively forbidding moving files in SVN...
 i hope SVN has learned to signal a merge conflict for this nowadays?

I found http://subversion.tigris.org/issues/show_bug.cgi?id=898 and it 
is in status NEW, but the target milestone is 1.8-consider already, so 
there is hope.


 there is another tool, a HG extension called hg-git, which can
 convert HG bookmarks to git branches.
 http://hg-git.github.com/

Great find! I was already brushing up my python and mercurial internals 
skills to extend hg-fast-export's export_commit() for our one big 
hg-repo with one hg-branch and many hg-bookmarks. I'm glad that cup passed.


 so my current plan is this:
 1. convert OOO340 repo to git via hg-fast-export.sh
 2. pull all CWSes into OOO340 repo and create bookmarks
 3. use hg-git to push all of them into the converted git repo

Sounds good!
I'd clarify step one to convert OOO340 repo to a bare git repo via 
hg-fast-export.sh. After all these steps please don't forget git 
pack-refs and git repack (e.g. with -a -d -f --window=200 
--depth=1000) to get a nice and tight repository.


Herbert

Re: fetch-all-cws.sh (was: Building a single Hg repository)

On Tue, Jul 5, 2011 at 16:04, Rob Weir apa...@robweir.com wrote:
 On Tue, Jul 5, 2011 at 3:33 PM, Mathias Bauer mathias_ba...@gmx.net wrote:
 Moin,

 On 05.07.2011 18:14, Mathias Bauer wrote:
...
 Do we really want to have code in the svn repo that will never be used?
 The alternative would be to add cws to svn only after review.

Having code in the repository is fine. It is better to have it there
and not need it, then to need it and not have it there.

As people have stated, these extra CWSs do not add that much more
space. And Apache has more than enough disk space. It is not a
concern.

 Right.  That is why I was thinking that maybe we just create an
 archival copy of the entire repository, including all CWS, and host
 that as a read only Hg or git instance.  Then migrate the trunk to
 SVN,   If there are some CWS that we know are already approved for
 3.4, then include those as well.

Apache only has one repository: Subversion.

The read-only Git instance is simply a mirror of the canonical
Subversion repository.

 That way, if someone does come by, months later, and decide they want
 to complete work CWS, then they can still clone them and work on them.
  But then they would need to copy them into a SVN working copy, and
 merge and commit from there.  Obviously, this does complicate things
 for the future CWS developers.  But they are in the best position to
 stabilize and merge their work.

Haven't we already gone through the whole discussion about CWSs that
may rename files, and that we want to do that rename within Hg before
converting to Subversion?

Let's not mess around with multiple repositories. That is just making
it difficult for us. How is somebody supposed to investigate a CWS
when it lives in a separate repository? That is just making it harder
for ourselves.

-g

Re: fetch-all-cws.sh (was: Building a single Hg repository)

On Wed, Jul 6, 2011 at 07:50, Michael Stahl m...@openoffice.org wrote:
 On 05.07.2011 11:16, Herbert Duerr wrote:
...
 merged. Speaking of merges in SVN we regularly had the problem that a
 file was renamed in one CWS and changed in another CWS and the result
 was that the change got lost. HG or GIT handle this scenario much more
 gracefully, so there was less risk to do big merges.

 indeed, which led to effectively forbidding moving files in SVN...
 i hope SVN has learned to signal a merge conflict for this nowadays?

It sure does. They are called tree conflicts. In this particular
case, you have an incoming edit to a file that doesn't exist. That
will get flagged for conflict resolution.

...
 If the goal is to just merge the outstanding CWSs into trunk I'd suggest
 to stay with hg, merge all good CWSs into trunk and start the apache-ooo
 SVN repository from that trunk.

 If the goal is to preserve the trunk and CWSs of the old-OOo project
 then the idea to provide it as a read-only git repository is great,

We only have one canonical repository at Apache, and that is
Subversion. We should not be planning to create a Git repository...
the read-only Git repositories are just mirrors of portions of the
Subversion repository.

...

Cheers,
-g

Re: fetch-all-cws.sh (was: Building a single Hg repository)

2011-07-06 Thread Thorsten Behrens

Mathias Bauer wrote:
 Do we really want to have code in the svn repo that will never be used?
 The alternative would be to add cws to svn only after review.
 
A somewhat related question would be, until when will the Oracle
offer to extend the source code grant last? Since work done by
Oracle developers would otherwise be effectively unusable for
Apache, even *if* someone then later comes  picks it up?

Cheers,

-- Thorsten, who therefore sees some merit in reviewing them all


pgpMgryRkt0e4.pgp
Description: PGP signature

Re: svn commit: r1142346 - /incubator/ooo/site/trunk/content/openofficeorg/testarea/index.mdtext

I would prefer not to see verson control get littered with test commits.

And if you *insist* on testing with the public version control
repository like this, then at least clean up after yourself and delete
these useless files.

thx
-g

On Sat, Jul 2, 2011 at 19:57,  rbirc...@apache.org wrote:
 Author: rbircher
 Date: Sat Jul  2 23:57:10 2011
 New Revision: 1142346

 URL: http://svn.apache.org/viewvc?rev=1142346view=rev
 Log:
 Simply test the Web CMS

 Added:
    incubator/ooo/site/trunk/content/openofficeorg/testarea/index.mdtext   
 (with props)

 Added: incubator/ooo/site/trunk/content/openofficeorg/testarea/index.mdtext
 URL: 
 http://svn.apache.org/viewvc/incubator/ooo/site/trunk/content/openofficeorg/testarea/index.mdtext?rev=1142346view=auto
 ==
 --- incubator/ooo/site/trunk/content/openofficeorg/testarea/index.mdtext 
 (added)
 +++ incubator/ooo/site/trunk/content/openofficeorg/testarea/index.mdtext Sat 
 Jul  2 23:57:10 2011
 @@ -0,0 +1,43 @@
 +Title:
 +Notice:    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.
 +
 +**This is a Testfile for the CMS**
 +
 +[OpenOffice.org Seite][1]
 +
 +    Das hier ist source Code
 +    Das schon
 +
 +Das glaub nicht mehr
 +
 +  - jaja
 +  - jaja auch
 +  -
 +
 +
 +--
 +
 +
 +--
 +
 +Heading
 +---
 +
 +-
 +
 +  [1]: http://www.openoffice.org
 \ No newline at end of file

 Propchange: 
 incubator/ooo/site/trunk/content/openofficeorg/testarea/index.mdtext
 --
    svn:eol-style = native

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

This is cool. I have one basic question: do you want the latest
content, or do you want full history?

If latest content, then you could use svn export rather than svn
checkout. However, export won't pick up changes from upstream. The
script would need to skip existing directories, rather than update
them.

If you want history, then we'll want to use something like svnsync to
copy history into local repositories. (or svnrdump from the upcoming
1.7 release)

Thoughts?

Cheers,
-g

On Sun, Jul 3, 2011 at 21:07, Dave Fisher dave2w...@comcast.net wrote:
 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=1142528view=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=1142528view=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=1142528view=auto

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

I've drafted the report directly on the wiki.

http://wiki.apache.org/incubator/July2011

Since the Board meeting is the 20th, and they need one-week to review,
we need final sign off by the 13th.

I will be out all next week starting the 12th.  So if we can reach
consensus on this and get a Mentor to sign off by EOD Monday, it would
be great.


-Rob


On Mon, Jul 4, 2011 at 5:45 PM, Ross Gardler rgard...@opendirective.com wrote:
 On 4 July 2011 21:01, Dennis E. Hamilton dennis.hamil...@acm.org wrote:
 +1 on circulation on ooo-dev.

 I'm not sure which wiki you mean and whether that would limit participation 
 or not.

 Sorry, I was referring to the wiki that is used to submit the report
 to the IPMC. It is publicly writable.

 Ross


  - Dennis

 -Original Message-
 From: Ross Gardler [mailto:rgard...@opendirective.com]
 Sent: Monday, July 04, 2011 03:06
 To: ooo-dev@incubator.apache.org
 Subject: Re: Incubator PMC/Board report for July 2011 
 (ooo-dev@incubator.apache.org)

 [ ... ]

 The most common practice that I am aware of is:

 - someone writes a draft and circulates via the dev list for comment
 - after 72 hours or so comments are collated and it's put in the wiki
 - mentors are asked to sign it off

 An alternative which also works well, is to do it directly in the wiki
 and request changes be made directly.

 Ross

 [ ... ]





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

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

2011-07-06 Thread Alexandro Colorado

On Wed, Jul 6, 2011 at 12:45 PM, Rob Weir apa...@robweir.com wrote:

 I've drafted the report directly on the wiki.

 http://wiki.apache.org/incubator/July2011

 Since the Board meeting is the 20th, and they need one-week to review,
 we need final sign off by the 13th.


Judging from the other reports I will try to make it more consice. For
example:
Explaining that is our first report, seems a bit verbose.

Also avoid the QA format and instead draft it as action points. The core
action ponits would be,
- Asset migration
- governance structure
- general project setup

Under migration we can put new website, wiki, etc. OOo code revision.
Under governance structure, we can put we did the initial commiter draft
with some of the numbers Dennise has report.
General project setup we can talk about the OOo site in Apache.

So in essence same information, but different format to make it more
objective and to the point.




 I will be out all next week starting the 12th.  So if we can reach
 consensus on this and get a Mentor to sign off by EOD Monday, it would
 be great.


 -Rob


 On Mon, Jul 4, 2011 at 5:45 PM, Ross Gardler rgard...@opendirective.com
 wrote:
  On 4 July 2011 21:01, Dennis E. Hamilton dennis.hamil...@acm.org
 wrote:
  +1 on circulation on ooo-dev.
 
  I'm not sure which wiki you mean and whether that would limit
 participation or not.
 
  Sorry, I was referring to the wiki that is used to submit the report
  to the IPMC. It is publicly writable.
 
  Ross
 
 
   - Dennis
 
  -Original Message-
  From: Ross Gardler [mailto:rgard...@opendirective.com]
  Sent: Monday, July 04, 2011 03:06
  To: ooo-dev@incubator.apache.org
  Subject: Re: Incubator PMC/Board report for July 2011 (
 ooo-dev@incubator.apache.org)
 
  [ ... ]
 
  The most common practice that I am aware of is:
 
  - someone writes a draft and circulates via the dev list for comment
  - after 72 hours or so comments are collated and it's put in the wiki
  - mentors are asked to sign it off
 
  An alternative which also works well, is to do it directly in the wiki
  and request changes be made directly.
 
  Ross
 
  [ ... ]
 
 
 
 
 
  --
  Ross Gardler (@rgardler)
  Programme Leader (Open Development)
  OpenDirective http://opendirective.com
 




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

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

On Jul 6, 2011, at 10:42 AM, Greg Stein wrote:

This is cool. I have one basic question: do you want the latest
content, or do you want full history?

Well. I think that history was erased with the conversion to Kenai as I am
seeing most everything in the initial revision of when they were imported.
There is a clear revision 1 for most of www.

So, yes history will be important, but there is not a whole lot.

If latest content, then you could use svn export rather than svn
checkout. However, export won't pick up changes from upstream. The
script would need to skip existing directories, rather than update
them.

I followed the pattern with your hg script, so that an aborted checkout could
be restarted at any point and be successful. Some of these projects are huge.

For now we are going to work with these and they may change (Kay Schenk has
commit rights over in OOo/Kenai.)

http://openoffice.org/projects/www/sources/webcontent/show

If you want history, then we'll want to use something like svnsync to
copy history into local repositories. (or svnrdump from the upcoming
1.7 release)

Thoughts?

Not sure. I'd like to know what those close to the OOo content think about this.

I'm not sure if we will do things like this:

(1) Copy the webcontent into the project's svn as data.

(2) Transform it into the format that we want to maintain in the ApacheCMS also
in svn.

(3) Add the proper extensions and views to the Apache CMS and our local lib to
(a) create html web content.
(b) create odf content.
(c) create pdf content

(1) Copy the webcontent into a scratch area and transform it into a directory
structure to be imported into svn.

(2) Add the proper extensions and views to the Apache CMS and our local lib to
(a) create html web content.
(b) create odf content.
(c) create pdf content

I was thinking of (1)/(2) until we get a better handle on the process.

But maybe it would be best to get everything into the archive.

If we do (1)(2)(3) then we'll need to schedule a weekend process with Infra.
Correct? When will svnrdump be available and will it work with OOo/Kenai? What
does that process look like.

Regards,
Dave

Cheers,
-g

On Sun, Jul 3, 2011 at 21:07, Dave Fisher dave2w...@comcast.net wrote:
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=1142528view=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=1142528view=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

Re: svn commit: r1142819 - /incubator/ooo/site/trunk/content/openofficeorg/people.mdtext

2011-07-06 Thread Joe Schaefer

To test you just install the python markdown package and execute the script 
from the command line.

Sent from my iPhone

On Jul 6, 2011, at 2:38 PM, Dave Fisher dave2w...@comcast.net wrote:

Joe,

Submit a patch to infrastructure@ plaese.

I would, but I am uncomfortable submitting untested code. I need some help 
setting up a version of the CMS for testing.

I think that others here may have a similar need.

Thanks.

Anyway if you want to debug what I did here is a diff compared to 
mdx_elementid.py:

--- mdx_elementid.py2011-07-06 10:43:22.0 -0700
+++ mdx_classtag.py2011-07-05 18:34:32.0 -0700
@@ -1,39 +1,39 @@
#! 

'''
-id Extension for Python-Markdown
+classtag Extension for Python-Markdown
==

-This extension adds ids to block elements in Python-Markdown.
+This extension adds class tags to block elements in Python-Markdown.

Simple Usage:

import markdown
text = 
-... list: {#list.1} 
+... list: {.list.1} 
...
-... 1. This is a test {#node1}
-... 2. Other {#node2}
+... 1. This is a test {.node1}
+... 2. Other {#.node2}
... 
... More
... 
- markdown.markdown(text, ['toc','elementid'])
-u'p id=list.1list:/p\\nol\\nli id=node1This is a 
test/li\\nli id=node2Other/li\\n/ol\\npMore/p'
- text2 = uSpain {#el1}
+ markdown.markdown(text, ['toc','classtag'])
+u'p class=list.1list:/p\\nol\\nli class=node1This is a 
test/li\\nli class=node2Other/li\\n/ol\\npMore/p'
+ text2 = uSpain {.el1}
... :Name of a country
...  in the South West of Europe
... 
-... Espa\xf1a {#el2}
+... Espa\xf1a {.el2}
... :Name of Spain
...  in Spanish (contains non-ascii)
... 
... End of definition list...
... 
- markdown.markdown(text2, ['toc','elementid', 'def_list'])
-u'dl\\ndt id=el1Spain/dt\\nddName of a country\\n in the South 
West of Europe/dd\\ndt id=el2Espa\\xf1a/dt\\nddName of Spain\\n in 
Spanish (contains non-ascii)/dd\\n/dl\\npEnd of definition list.../p'
-
+ markdown.markdown(text2, ['toc','classtag', 'def_list'])
+u'dl\\ndt class=el1Spain/dt\\nddName of a country\\n in the 
South West of Europe/dd\\ndt class=el2Espa\\xf1a/dt\\nddName of 
Spain\\n in Spanish (contains non-ascii)/dd\\n/dl\\npEnd of definition 
list.../p'


+Based on mdx_elementid.py
Copyright 2010
* [Santiago Gala](http://memojo.com/~sgala/blog/)

@@ -46,52 +46,52 @@
ID_RE = re.compile(r[ \t]*# optional whitespace
   [#]{0,6}  # end of heading
   [ \t]*# optional whitespace
-   (?:[ \t]*\{[ \t]*\#(?Pid[-._:a-zA-Z0-9]+)[ \t]*\})
+   (?:[ \t]*\{[ \t]*\.(?Pclasstag[-._:a-zA-Z0-9]+)[ 
\t]*\})
   [ \t]*# optional whitespace
   (\n|$)  #  ^^ group('id') = id attribute
,
re.VERBOSE)


-class IdTreeProcessor(markdown.treeprocessors.Treeprocessor):
- Id Treeprocessor - parse text for id specs. 
+class ClasstagTreeProcessor(markdown.treeprocessors.Treeprocessor):
+ Classtag Treeprocessor - parse text for classtag specs. 

-def _parseID(self, element):
-''' recursively parse all {#idname}s at eol into ids '''
+def _parseClasstag(self, element):
+''' recursively parse all {.classtag}s at eol into ids '''
if markdown.isBlockLevel(element.tag) and element.tag not in ['code', 
'pre']:
#print element
if (element.text and element.text.strip()):
m = ID_RE.search(element.text)
if m:
-element.set('id',m.group('id'))
+element.set('classtag',m.group('classtag'))
element.text = element.text[:m.start()]
for e in element:
-self._parseID(e)
+self._parseClasstag(e)
return element


def run(self, root):
'''
-Find and remove all id specs references from the text,
-and add them as the id attribute of the element.
+Find and remove all classtag specs references from the text,
+and add them as the class attribute of the element.

'''
if markdown.isBlockLevel(root.tag) and root.tag not in ['code', 'pre']:
-self._parseID(root)
+self._parseClasstag(root)
return root

-class IdExtension(markdown.Extension):
- Id Extension for Python-Markdown. 
+class ClasstagExtension(markdown.Extension):
+ Classtag Extension for Python-Markdown. 

def extendMarkdown(self, md, md_globals):
- Insert IdTreeProcessor in tree processors. It should be before 
toc. 
-idext = IdTreeProcessor(md)
-idext.config = self.config
-md.treeprocessors.add(elid, idext, _begin)
+ Insert ClasstagTreeProcessor in tree processors. It should be

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

I did some modest streamlining.  I didn't alter the questions.  I did not touch 
the How has the project developed ...  question.

I am not sure which of these topics may be from guidance on providing the 
report.

Alexandro, will you be making the changes along the lines you suggest?

On Friday I can add the latest PPMC summary and anything about the size of 
ooo-dev on the community growth question or whatever other title we give that.

 - Dennis

PS: My name, Dennis, is Irish, not French or Spanish.  Not to be confused 
with Den[n]ise although I was called Denny when I was a child.  My sisters 
still call me that.  (And I shall remind myself that Alexandro is not 
pronounced like Alex when we have an opportunity to meet.)

-Original Message-
From: acolor...@gmail.com [mailto:acolor...@gmail.com] On Behalf Of Alexandro 
Colorado
Sent: Wednesday, July 06, 2011 11:08
To: ooo-dev@incubator.apache.org
Subject: Re: Incubator PMC/Board report for July 2011 
(ooo-dev@incubator.apache.org)

On Wed, Jul 6, 2011 at 12:45 PM, Rob Weir apa...@robweir.com wrote:

 I've drafted the report directly on the wiki.

 http://wiki.apache.org/incubator/July2011

 Since the Board meeting is the 20th, and they need one-week to review,
 we need final sign off by the 13th.


Judging from the other reports I will try to make it more consice. For
example:
Explaining that is our first report, seems a bit verbose.

Also avoid the QA format and instead draft it as action points. The core
action ponits would be,
- Asset migration
- governance structure
- general project setup

Under migration we can put new website, wiki, etc. OOo code revision.
Under governance structure, we can put we did the initial commiter draft
with some of the numbers Dennise has report.
General project setup we can talk about the OOo site in Apache.

So in essence same information, but different format to make it more
objective and to the point.




 I will be out all next week starting the 12th.  So if we can reach
 consensus on this and get a Mentor to sign off by EOD Monday, it would
 be great.


 -Rob


 On Mon, Jul 4, 2011 at 5:45 PM, Ross Gardler rgard...@opendirective.com
 wrote:
  On 4 July 2011 21:01, Dennis E. Hamilton dennis.hamil...@acm.org
 wrote:
  +1 on circulation on ooo-dev.
 
  I'm not sure which wiki you mean and whether that would limit
 participation or not.
 
  Sorry, I was referring to the wiki that is used to submit the report
  to the IPMC. It is publicly writable.
 
  Ross
 
 
   - Dennis
 
  -Original Message-
  From: Ross Gardler [mailto:rgard...@opendirective.com]
  Sent: Monday, July 04, 2011 03:06
  To: ooo-dev@incubator.apache.org
  Subject: Re: Incubator PMC/Board report for July 2011 (
 ooo-dev@incubator.apache.org)
 
  [ ... ]
 
  The most common practice that I am aware of is:
 
  - someone writes a draft and circulates via the dev list for comment
  - after 72 hours or so comments are collated and it's put in the wiki
  - mentors are asked to sign it off
 
  An alternative which also works well, is to do it directly in the wiki
  and request changes be made directly.
 
  Ross
 
  [ ... ]
 
 
 
 
 
  --
  Ross Gardler (@rgardler)
  Programme Leader (Open Development)
  OpenDirective http://opendirective.com
 




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

[DISCUSS] Creation of ooo-security List

[I am reminded that the best way to talk to the PPMC is on ooo-dev and there is 
benefit in so doing.  Here goes.]

PROPOSAL

ooo-security@incubator.a.o be set up as a private list and a selection of not 
more than 10 security-aware PPMC members be subscribed to it.  We need to work 
out what the composition would be.  The list will be automatically forward to 
security@a.o.  I assume that there might be security-aware ooo-podling mentors 
and other ASF Members included in the small PPMC subscription.

DETAILS

General information about the Apache Security Team:
http://www.apache.org/security/

More details on the handling of security and vulnerabilities by committers and 
the role of the [P]PMC:
http://www.apache.org/security/committers.html

Note that creation of a security page on our web site is also part of this.  
That should happen near-immediately also.

BACKGROUND  

I have been nosing around in document-related security areas and that has led 
me to inquire what the arrangements need to be for discussing security issues, 
identified vulnerabilities, proposed mitigations, etc.

I've learned that the Apache approach is for each PMC taking the lead in 
handling security matters related to its releases.  To maintain the security of 
security matters, the practice is to have a private list (for us, ooo-security) 
with not more than ten security-aware subscribers.

Since we may have common-mode issues with respect to the use of our common 
code base and implementation behaviors, it may be necessary to coordinate with 
other teams, including the LibreOffice security team, in our case.  We'll have 
to work that out on an individual-case basis, I suspect.  I don't know if we 
have any PPMC members who are also on that team, and I don't know what the 
structure was for OpenOffice.org and who may have been involved.

 - Dennis

Re: Website Content plus Look and Feel Improvements

2011-07-06 Thread Kay Schenk


On 07/06/2011 11:00 AM, Dave Fisher wrote:

Hi Kay,

On Jul 6, 2011, at 8:34 AM, Kay Schenk wrote:


So, keep the home page as is or find someway to get the CMS
to display it, action statements intact at least.




yes...I hope to investigate the Apache CMS capabilities in this
regard this week.


I'm looking forward to it and I am here to help you with patches and
to talk through ideas.

The CMS does look easily extensible, if you know python, I am
learning.

The current www.apache.org is a good example of how to merge content
from multiple sources on the main page - this includes watching a
twitter feed.


Dave--

Thanks for all this. My days are kind of scattered at the moment, but I 
hope to have at least a summary of what we've discussed here over the 
last few days and some reasonable approaches in the wiki area in about a 
few days. We've covered at lot of ground, by, yes, as you point out, a 
LOT to do. And, unfortunately, since I did know quite a bit about how 
Collabnet was set up, I don't know much about kenai...so more to learn.





Then to my mind the only subs to the OOo domain that I would
think that would be compulsory would be:
support.openoffice.org Why.openoffice.org and
download.openoffice.org

and the NLC subdomains

The rest of the website could happily exist under

OpenOffice.apache.org.


I think we have an outline and lots of work to do.

Regards, Dave


--

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: Brazilian government and Apache OpenOffice.org / TDF's LibreOffice

2011-07-06 Thread Simon Phipps

On Tue, Jul 5, 2011 at 10:56 PM, Jomar Silva homem...@gmail.com wrote:


 I also did a presentation about Apache OpenOffice.org with Simon
 Phipps, inviting all Brazilian community to join us on the project. I
 plan to do a blog post on the next days talking about this
 governmental commitment, inviting other governments and individual
 contribution to work with us all.


Just to expand on Jomar's comment, the presentation we jointly delivered was
attended by a broad spectrum of people from across many FOSS communities,
and I found at the event overall that there were strong emotions still on
display concerning OpenOffice.org and its new homes at Apache and TDF.

During the meeting, I called for developers to start work on the code-base
now, regardless of their eventual expectations of which of the two open
source projects they will join, so that their skills and their familiarity
with the code are developed. Change in the codebase is inevitable, but
skills and familiarity gained today will remain valuable. This uniting
message was well received by the audience.

I've blogged further on the topic at
http://webmink.com/2011/07/06/brazil-signs-up-to-develop-office-suites/


S.

Re: svn commit: r1143546 - /incubator/ooo/site/trunk/content/openofficeorg/people.mdtext

2011-07-06 Thread Joe Schaefer

Dave,

You wiped out someone else's entry (Yong Lin Ma)-
any reason for that?



- Original Message 
 From: thegur...@apache.org thegur...@apache.org
 To: ooo-comm...@incubator.apache.org
 Sent: Wed, July 6, 2011 4:19:15 PM
 Subject: svn commit: r1143546 - 
/incubator/ooo/site/trunk/content/openofficeorg/people.mdtext
 
 Author: thegurkha
 Date: Wed Jul  6 20:19:15 2011
 New Revision:  1143546
 
 URL:  http://svn.apache.org/viewvc?rev=1143546view=rev
 Log:
 CMS commit to  openofficeorg by thegurkha
 
 Modified:
  incubator/ooo/site/trunk/content/openofficeorg/people.mdtext
 
 Modified:  incubator/ooo/site/trunk/content/openofficeorg/people.mdtext
 URL:  
http://svn.apache.org/viewvc/incubator/ooo/site/trunk/content/openofficeorg/people.mdtext?rev=1143546r1=1143545r2=1143546view=diff

 ==
 ---  incubator/ooo/site/trunk/content/openofficeorg/people.mdtext (original)
 +++  incubator/ooo/site/trunk/content/openofficeorg/people.mdtext Wed Jul  6  
20:19:15 2011
 @@ -45,4 +45,5 @@ to look at all contributors to our issue
   | jeanweber | [Jean Hollis Weber](http://taming-openoffice-org.com/) |  
Townsville,nbsp;QLD,nbsp;Australia | Technical  writing/editing/publishing 
of 
end-user documentation |
  | robweir   |  [Rob Weir](http://www.robweir.com/blog)|  
 Westford, 
MA, USA| C/C++, Java, Python, XML, ODF,  Performance tuning |
  | chenjinh  | Jin Hua Chen   | BeiJing, 
China| C/C++, Java, UNO, Impress, programmability |
 -| mayongl   | Yong Lin  Ma   | BeiJing, 
China| C/C++, Java, UNO, MacOS X, ODF |
 +| thegurkha  | Dave McKay  | North East  
Wales, UK | C/C++, Technical Writer, User Forum   |
 +

Re: [DISCUSS] Creation of ooo-security List

On Wed, Jul 6, 2011 at 3:02 PM, Dennis E. Hamilton orc...@apache.org wrote:
 [I am reminded that the best way to talk to the PPMC is on ooo-dev and there 
 is benefit in so doing.  Here goes.]

 PROPOSAL

 ooo-security@incubator.a.o be set up as a private list and a selection of not 
 more than 10 security-aware PPMC members be subscribed to it.  We need to 
 work out what the composition would be.  The list will be automatically 
 forward to security@a.o.  I assume that there might be security-aware 
 ooo-podling mentors and other ASF Members included in the small PPMC 
 subscription.

 DETAILS

 General information about the Apache Security Team:
 http://www.apache.org/security/

 More details on the handling of security and vulnerabilities by committers 
 and the role of the [P]PMC:
 http://www.apache.org/security/committers.html

 Note that creation of a security page on our web site is also part of this.  
 That should happen near-immediately also.


The website already has a Security link on the navigation panel, at
the bottom.  This takes you to the main Apache security page where the
reporter is instructed on how to submit reports.  According to that
page, security reports are routed to the PMC in case we do not have a
dedicated security list.  So I don't see the urgency on creating a new
list or a new web page, especially since we don't even have code in
the repository, let alone a release, and since there already is a
security list and contact address at OOo.  I think that the existing
procedures, in place at Apache, are adequate if someone wanted to
report a problem

The idea of having the discussion in private, on the PMC private list
or on a private security list, is a  good idea, so that any
vulnerability reported would not be immediately exploited by script
kiddies.  Or at least the chances of that would be diminished.  But I
don't think that any of the PPMC members are malicious hackers likely
to abuse any security sensitive information shared on the PPMC list.
Of course, only a subset of the members have security expertise.


 BACKGROUND

 I have been nosing around in document-related security areas and that has led 
 me to inquire what the arrangements need to be for discussing security 
 issues, identified vulnerabilities, proposed mitigations, etc.

 I've learned that the Apache approach is for each PMC taking the lead in 
 handling security matters related to its releases.  To maintain the security 
 of security matters, the practice is to have a private list (for us, 
 ooo-security) with not more than ten security-aware subscribers.

 Since we may have common-mode issues with respect to the use of our common 
 code base and implementation behaviors, it may be necessary to coordinate 
 with other teams, including the LibreOffice security team, in our case.  
 We'll have to work that out on an individual-case basis, I suspect.  I don't 
 know if we have any PPMC members who are also on that team, and I don't know 
 what the structure was for OpenOffice.org and who may have been involved.


I'd object to us officially sharing advance security-related
information with some downstream consumers of OOo while not doing the
same with others.

  - Dennis

Re: DITA for Doc?

I seem to recall an email from the doc people that they wanted to
stick to their current toolset and infrastructure, rather than bring
that to the ASF. My take-away from that message is that the OOo
documentation is written by other/downstream people, rather than as a
deliverable from the ASF.

Cheers,
-g

On Wed, Jul 6, 2011 at 17:10, Rob Weir apa...@robweir.com wrote:
 Would it be worth considering using DITA for the documentation/help?

 I love ODF as much as anyone, but DITA was designed specifically for
 technical documentation, and has built-in facilities for making
 modular topics that then can be reassembled, with a map to
 assemble larger works.  This gives you the ability, for example, to
 have paragraph that only shows up in the Linux version of the doc, but
 not in the Windows version.

 You also get an easy ability, via the DITA Open Toolkit (which is
 Apache 2.0 licensed), to transform the DITA source into a large
 variety of output forms, including:

 HTML
 PDF
 ODT (Open Document Format)
 Eclipse Help
 HTML Help
 Java Help
 Eclipse Content
 Word RTF
 Docbook
 Troff

 The authors focus on the structure and content, and the layout and
 styling is deferred until publication time.  So you have a great deal
 of flexibility for targeting the same content to various uses.

 The other nice thing is that DITA is text (well, XML specifically), so
 we use SVN to manage the content, can do diff's, merges, use the
 editor of our choice, etc.

 I'd like to argue for the advantages of DITA as a source format here.
 I can probably find some volunteers to help enabled this.  The
 Symphony team uses DITA for doc/help, and we've already done the work
 of converting much of the OOo help to DITA.

 -Rob

Re: fetch-all-cws.sh (was: Building a single Hg repository)

2011-07-06 Thread Mathias Bauer

On 06.07.2011 18:58, Greg Stein wrote:

 The development process that OOo used to use, as I understand it,
 looks incredibly heavyweight and slow moving. At Apache, you commit
 your changes. If you have a large-ish feature you're unsure about,
 then discuss it on the mailing list, and (maybe) go start a branch. In
 many cases, it is possibly to develop even large features on trunk
 because you can hide it or make it have near-zero impact on the main
 trunk code.

There's always a trade-off. I agree that for many code changes the
development process of OOo was just too heavy. But OTOH it is a well
known fact that bugs are best found as early as possible. In a large and
complex code base with a lot of parallel work it happens too easy that
ugly bugs slip in and cause a lot of trouble for other developers or
even for users. Fixing them much later, when more code has been added
and the developer already has moved his mind to something else is much
more complicated. So a balance is necessary.

Perhaps looking on other large projects (Firefox, Linux Kernel ...) is a
good idea.

Regards,
Mathias

Re: DITA for Doc?

That was user guides.  I'm talking about help documentation, though
the DITA approach could certainly handle user guides with ease as
well.

And remember, there is more than one doc team to consider here.  And
once of them would like to use DITA.

-Rob

On Wed, Jul 6, 2011 at 5:46 PM, Greg Stein gst...@gmail.com wrote:
 I seem to recall an email from the doc people that they wanted to
 stick to their current toolset and infrastructure, rather than bring
 that to the ASF. My take-away from that message is that the OOo
 documentation is written by other/downstream people, rather than as a
 deliverable from the ASF.

 Cheers,
 -g

 On Wed, Jul 6, 2011 at 17:10, Rob Weir apa...@robweir.com wrote:
 Would it be worth considering using DITA for the documentation/help?

 I love ODF as much as anyone, but DITA was designed specifically for
 technical documentation, and has built-in facilities for making
 modular topics that then can be reassembled, with a map to
 assemble larger works.  This gives you the ability, for example, to
 have paragraph that only shows up in the Linux version of the doc, but
 not in the Windows version.

 You also get an easy ability, via the DITA Open Toolkit (which is
 Apache 2.0 licensed), to transform the DITA source into a large
 variety of output forms, including:

 HTML
 PDF
 ODT (Open Document Format)
 Eclipse Help
 HTML Help
 Java Help
 Eclipse Content
 Word RTF
 Docbook
 Troff

 The authors focus on the structure and content, and the layout and
 styling is deferred until publication time.  So you have a great deal
 of flexibility for targeting the same content to various uses.

 The other nice thing is that DITA is text (well, XML specifically), so
 we use SVN to manage the content, can do diff's, merges, use the
 editor of our choice, etc.

 I'd like to argue for the advantages of DITA as a source format here.
 I can probably find some volunteers to help enabled this.  The
 Symphony team uses DITA for doc/help, and we've already done the work
 of converting much of the OOo help to DITA.

 -Rob

Re: DITA for Doc?

Rob,

I am surprised that you did not suggest using the ODF Toolkit.

Regards,
Dave

On Jul 6, 2011, at 2:10 PM, Rob Weir wrote:

 Would it be worth considering using DITA for the documentation/help?
 
 I love ODF as much as anyone, but DITA was designed specifically for
 technical documentation, and has built-in facilities for making
 modular topics that then can be reassembled, with a map to
 assemble larger works.  This gives you the ability, for example, to
 have paragraph that only shows up in the Linux version of the doc, but
 not in the Windows version.
 
 You also get an easy ability, via the DITA Open Toolkit (which is
 Apache 2.0 licensed), to transform the DITA source into a large
 variety of output forms, including:
 
 HTML
 PDF
 ODT (Open Document Format)
 Eclipse Help
 HTML Help
 Java Help
 Eclipse Content
 Word RTF
 Docbook
 Troff
 
 The authors focus on the structure and content, and the layout and
 styling is deferred until publication time.  So you have a great deal
 of flexibility for targeting the same content to various uses.
 
 The other nice thing is that DITA is text (well, XML specifically), so
 we use SVN to manage the content, can do diff's, merges, use the
 editor of our choice, etc.
 
 I'd like to argue for the advantages of DITA as a source format here.
 I can probably find some volunteers to help enabled this.  The
 Symphony team uses DITA for doc/help, and we've already done the work
 of converting much of the OOo help to DITA.
 
 -Rob

Re: DITA for Doc?

Hi Rob,

On Jul 6, 2011, at 2:10 PM, Rob Weir wrote:

  we've already done the work
 of converting much of the OOo help to DITA.

Is there a software grant coming?

Regards,
Dave

Re: fetch-all-cws.sh (was: Building a single Hg repository)

On Wed, Jul 6, 2011 at 5:59 PM, Mathias Bauer mathias_ba...@gmx.net wrote:
 On 06.07.2011 18:58, Greg Stein wrote:

 The development process that OOo used to use, as I understand it,
 looks incredibly heavyweight and slow moving. At Apache, you commit
 your changes. If you have a large-ish feature you're unsure about,
 then discuss it on the mailing list, and (maybe) go start a branch. In
 many cases, it is possibly to develop even large features on trunk
 because you can hide it or make it have near-zero impact on the main
 trunk code.

 There's always a trade-off. I agree that for many code changes the
 development process of OOo was just too heavy. But OTOH it is a well
 known fact that bugs are best found as early as possible. In a large and
 complex code base with a lot of parallel work it happens too easy that
 ugly bugs slip in and cause a lot of trouble for other developers or
 even for users. Fixing them much later, when more code has been added
 and the developer already has moved his mind to something else is much
 more complicated. So a balance is necessary.


And different approaches might be used in different parts of the
cycle, or on different parts of the project.  For example, we might
declare a Commit-Then-Review policy except after beta, when we turn to
Review-Then-Commit.  Or we might be C-T-R for all documentation files
at all times (since they are trivial to review via diff's) while R-T-C
is always the policy for a specific list of shared modules, where
breakage would have a project-wide impact.

But generally coordination has cost.  If you are a very small group,
you don't need much formal coordination.  But as you get larger you
get to the point where the friction from errors outweighs the cost
of coordination.  But if you get even larger, the cost of coordination
is even greater, and unless you have high discipline coordination is
hard to achieve, outside of authoritative structures like corporations
or armies,  At some scale, nothing but loose coordination will scale.
At the far end you have free markets.

I think we're transitioning from a formally coordinated model led by a
corporation to a model that will have less formal coordination
structures.  This is necessary to grow the project in the absence of
corporate control.  But it will take some time to get used to it.


 Perhaps looking on other large projects (Firefox, Linux Kernel ...) is a
 good idea.

 Regards,
 Mathias

Re: Migration, Bugzilla to JIRA


Just to update on this:
- I have been discussing this with Raphael
- I'm generating current backups of the bz database from OOo
- I'm looking for a place to share an older version of the bz backup - 
it's around 10GB

- I am also looking to provide the bz templates

Andrew



On 7/5/2011 10:37 AM, Dave Fisher wrote:

Mark Thomas is the person on the Apache Infrastructure group who stepped up as 
the contact when I asked infrastructure if they had an opinion in our first few 
days.

Would someone remind us of the contacts on the current OOo bugzilla 
infrastructure. Are these the same contacts to for the MediaWiki?

Mark wanted to know about the overall size and also the underlying database. 
Someone who will carry out these first tests should make contact and start 
planning with Apache Infrastructure.

I know Raphael has been working on the bugzilla issue along with other 
inventory of openoffice domains.

 From what I've read on the list the bugzilla customizations are mostly in 
front in order to guide component selection. Something that others have doubted 
as being useful. To me that it was done means that it was probably perceived as 
useful at one time.

Regards,
Dave

On Jul 5, 2011, at 10:12 AM, Rob Weir wrote:


On Tue, Jul 5, 2011 at 1:01 PM, Raphael Bircherr.birc...@gmx.ch  wrote:

Am 05.07.11 18:27, schrieb Rob Weir:

I'd like to help move this discussion forward.  I'm not perceiving any
*strong* opinions on the Bugzilla versus JIRA question.  But I am
hearing several suggest that JIRA is a better tracker (custom
dashboards in particular were called out).  Bugzilla got some nods for
the ease of migration and the customization done to the OOo version.

Let's wait a little bit longer. The OOo Bugzilla is adapted in same case to
the project. First I'like to have a database dump and the used bugzilla
templates. So we can find out the difference between normal Bugzilla and the
OOo Bugzilla. And If we realy want to mofe to JIRA then we should first
evaluate the possible problem Areas.


Is this something that you are working on?

Right now, I'm only exploring feasibility, what is possible.  If we
find that migration to JIRA is feasible, then I'd propose going ahead
with it.  But now I am exploring.  But I think this is something that
we can do quickly.  It is one of the easier areas to migrate.



For my point of view it's not a good idea to setup now all tools. Else we
will maybe run in the problem, that we can't import the old data.


Our notes crossed, but did you see the my idea of migrating first to a
clean, uncustomized Bugzilla, and then from there to JIRA?


I propose that we make first a test migration and then the live migration.
So we have the possibility to track the problemes.


Yes, of course.


Greetings Raphael

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

Re: fetch-all-cws.sh (was: Building a single Hg repository)

2011-07-06 Thread Simon Phipps


On 6 Jul 2011, at 23:19, Rob Weir wrote:

 I think we're transitioning from a formally coordinated model led by a
 corporation to a model that will have less formal coordination
 structures.  This is necessary to grow the project in the absence of
 corporate control.  But it will take some time to get used to it.

I've always assumed that the extremely careful approach the development team 
was using was more a function of the size, complexity and intra-dependency of 
the code than of corporate control. It is amazing how a small, obvious change 
in one part of OOo can result in a nasty intermittent fault in another part...

S.

Re: DITA for Doc?

On Wed, Jul 6, 2011 at 6:09 PM, Dave Fisher dave2w...@comcast.net wrote:
 Rob,

 I am surprised that you did not suggest using the ODF Toolkit.


The DITA Open Toolkit already supports ODF output.  They did this back
in early 2010 using a XSLT transform.  Although I think doing it with
the ODF Toolkit would be infinitely more elegant, poetic and majestic,
and might even run faster, my belief in that is not so great as to
offer to rewrite it for them.  Maybe someday.

Remember, DITA is not just a word processor format.  It is a
structured, modular vocabulary for technical documentation.  Although
there are dedicated authoring tools, you can author DITA in any XML
editor, or even a text editor.

Now, you could certainly build DITA-like behavior on top of an
OpenOffice, using the RDF XML/RDFa semantic metadata extensibility
features of ODF 1.2, I have not seen any ODF word processor implement
this to the extent that would be needed.  It could also be enabled via
plugins or macros, as has been done with some 3rd party DITA apps for
MS Word.

But then I think you would want to compare a standards-based approach
to technical doc, that is supported by a broad ecosystem of tools,
versus an ad-hoc one used by only us.


 Dave

 On Jul 6, 2011, at 2:10 PM, Rob Weir wrote:

 Would it be worth considering using DITA for the documentation/help?

 I love ODF as much as anyone, but DITA was designed specifically for
 technical documentation, and has built-in facilities for making
 modular topics that then can be reassembled, with a map to
 assemble larger works.  This gives you the ability, for example, to
 have paragraph that only shows up in the Linux version of the doc, but
 not in the Windows version.

 You also get an easy ability, via the DITA Open Toolkit (which is
 Apache 2.0 licensed), to transform the DITA source into a large
 variety of output forms, including:

 HTML
 PDF
 ODT (Open Document Format)
 Eclipse Help
 HTML Help
 Java Help
 Eclipse Content
 Word RTF
 Docbook
 Troff

 The authors focus on the structure and content, and the layout and
 styling is deferred until publication time.  So you have a great deal
 of flexibility for targeting the same content to various uses.

 The other nice thing is that DITA is text (well, XML specifically), so
 we use SVN to manage the content, can do diff's, merges, use the
 editor of our choice, etc.

 I'd like to argue for the advantages of DITA as a source format here.
 I can probably find some volunteers to help enabled this.  The
 Symphony team uses DITA for doc/help, and we've already done the work
 of converting much of the OOo help to DITA.

 -Rob

Re: fetch-all-cws.sh (was: Building a single Hg repository)





On 7/5/2011 8:53 AM, Pedro F. Giffuni wrote:

I agree with Mathias ..

We are not advancing simply because it's not clear who does what.

- Greg made a script to import the Hg stuff ... who will run it?

A number of us are - and props gentlemen, the scripts work great.


- Matthias made a list, is this what Oracle should relicense, or
perhaps we should wait until we merge the resulting SVN branches.
- Who takes the list to Oracle.
As discussed before on the list, I am tracking all of the resources that 
have been identified and will be working this all through on the Oracle 
side.
The list goes beyond just code, to artwork, bz database, translations, 
the forums, wikis, and more.



- Bugzilla or JIRA?

(I personally lean JIRA)

- Who can provide the MediaWiki stuff so we actually translate
  it to confluence?

working on this, also.


We really need people taking the tasks at hand.

cheers,

Pedro.

--- On Tue, 7/5/11, Joe Schaeferjoe_schae...@yahoo.com  wrote:


From: Joe Schaeferjoe_schae...@yahoo.com
Subject: Re: fetch-all-cws.sh (was: Building a single Hg repository)
To: ooo-dev@incubator.apache.org
Date: Tuesday, July 5, 2011, 9:58 AM


- Original Message 

From: Mathias Bauermathias_ba...@gmx.net
To: ooo-dev@incubator.apache.org
Sent: Tue, July 5, 2011 10:55:25 AM
Subject: Re: fetch-all-cws.sh (was: Building a single

Hg repository)

On 01.07.2011 23:18, Greg Stein wrote:


Right. I think we just bring  it all over,

and then sort it out in our

repository.

May I ask who  will be the one that brings it

all over? I don't find

the reference, but  from past reading I

understood that this is nothing

that one of us regular  committers can do.

Why not? It's DVCS after all, so long as we have a
*repeatable* process
for populating an svn dump file, and there's a way to map
that process over
to whatever file list Oracle is willing to provide, seems
like any developer
can initiate this process.

Re: DITA for Doc?

Ah. User guides vs $otherstuff.

For developer documentation, I'd be partial to doxygen. For help
doc... no opinion.

Cheers,
-g

On Wed, Jul 6, 2011 at 18:08, Rob Weir apa...@robweir.com wrote:
 That was user guides.  I'm talking about help documentation, though
 the DITA approach could certainly handle user guides with ease as
 well.

 And remember, there is more than one doc team to consider here.  And
 once of them would like to use DITA.

 -Rob

 On Wed, Jul 6, 2011 at 5:46 PM, Greg Stein gst...@gmail.com wrote:
 I seem to recall an email from the doc people that they wanted to
 stick to their current toolset and infrastructure, rather than bring
 that to the ASF. My take-away from that message is that the OOo
 documentation is written by other/downstream people, rather than as a
 deliverable from the ASF.

 Cheers,
 -g

 On Wed, Jul 6, 2011 at 17:10, Rob Weir apa...@robweir.com wrote:
 Would it be worth considering using DITA for the documentation/help?

 I love ODF as much as anyone, but DITA was designed specifically for
 technical documentation, and has built-in facilities for making
 modular topics that then can be reassembled, with a map to
 assemble larger works.  This gives you the ability, for example, to
 have paragraph that only shows up in the Linux version of the doc, but
 not in the Windows version.

 You also get an easy ability, via the DITA Open Toolkit (which is
 Apache 2.0 licensed), to transform the DITA source into a large
 variety of output forms, including:

 HTML
 PDF
 ODT (Open Document Format)
 Eclipse Help
 HTML Help
 Java Help
 Eclipse Content
 Word RTF
 Docbook
 Troff

 The authors focus on the structure and content, and the layout and
 styling is deferred until publication time.  So you have a great deal
 of flexibility for targeting the same content to various uses.

 The other nice thing is that DITA is text (well, XML specifically), so
 we use SVN to manage the content, can do diff's, merges, use the
 editor of our choice, etc.

 I'd like to argue for the advantages of DITA as a source format here.
 I can probably find some volunteers to help enabled this.  The
 Symphony team uses DITA for doc/help, and we've already done the work
 of converting much of the OOo help to DITA.

 -Rob

Re: OOO and LibreOffice.



To date the LibreOffice crew has taken the effort to merge in changes 
from the OOo code line, for each release.
The most obvious and best way to collaborate in the future is to write 
good code, and make it worth their while to integrate it into LO.
The more compelling the development effort at Apache, the more likely it 
is reused by LO.
This also leads to the situation where they have an interest in pushing 
changes into the AOOo code line, to simplify their future merges.


Andrew

On 7/2/2011 9:16 PM, Graham Lauder wrote:

On Sat, 2011-07-02 at 23:39 -0400, Ted Rolle, Jr. wrote:

Perhaps I'm jaded, but when you have data in two places, you can be sure
of one thing:  they're both wrong.

Conversely, they are both right for their respective supporters and the
reasons that each cite are also right, for each respective audience


I fear that the *Office camps will be in some sort of competition.
Competition means that there is a winner, and a loser.

Not always true, if each iteration serves a unique market.  They can
still be in competition for bragging rights but at the same time only
competing for a common set of the market that is smaller than their main
market, in this case I believe it will be Consumer on one hand (LO) and
Enterprise on the other (OOo), IMO, MSO will be the big loser.


The good thing is that one will survive and become the de-facto
standard.

Prove me wrong!

I'm hoping we will, either way we live in interesting times

Re: [DISCUSS] Creation of ooo-security List

Hi Dennis,

I appreciate your concerns. Have you raised them at secur...@apache.org yet?

If the secur...@apache.org list suggests that the AOOo PPMC request a security 
mailing list now then we should go ahead. We would need the right volunteers to 
handle any concerns.

Perhaps it will turn out that there are some of individuals involved in all of 
AOOo, LibreOffice and Security that can informally handle the multiple hats. 
That might avoid a formal arrangement. But maybe a formal agreement would be 
good.

I think that if we do have a security list that they will need to give 
nonspecific information so that the community can sense that issues are being 
solved. We may very well need to eventually have a security patch schedule that 
is not too frantic. (Firefox 5 or bust, corporations can just have their IE)

Regards,
Dave

On Jul 6, 2011, at 3:35 PM, Dennis E. Hamilton wrote:

 Well, vulnerabilities are vulnerabilities and if there is an exposure in 
 current code or in documents produced in current code, isn't that a concern 
 for us now?  Why would it not be?
 
 Also, I don't presume that everyone is downstream from us (as opposed to the 
 OpenOffice.org that once was).
 
 I think of LibreOffice as a mutual stakeholder because it seems they have a 
 security team too and like it or not, they are cranking out releases very 
 quickly and may be able to provide mitigations, hypothetically, months before 
 we ever get a release of ours out the door.  
 
 Also, some security issues may require a jointly-agreed response so that we 
 attend to interoperability concerns, especially if mitigation involves 
 breaking changes or even introduction of allowed extensions (in the context 
 of the ODF specifications).  Anything that fits into a discretionary area 
 requiring producer-consumer agreement to work needs a community to unfold it.
 
 I don't know about the details of having that work.  I do know if I uncover a 
 problem, I am going to communicate it to every security-conscious entity I 
 can.
 
 To make this conversation concrete: I have security issues I want to raise, 
 which is what had me looking into this in the first place.  I would like to 
 do this in a manner that is in keeping with concerns for dealing with 
 security matters privately to ensure that there is competent review and no 
 danger attached to premature disclosure.  (I suspect not, because the 
 vulnerabilities I am aware of exist in plain sight, but I want the counsel of 
 someone having more security experience than I before saying, Heck, I need 
 something for today's blog post, why not stir things up with this?)
 
 
 - Dennis 
 
 -Original Message-
 From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir
 Sent: Wednesday, July 06, 2011 14:40
 To: ooo-dev@incubator.apache.org
 Subject: Re: [DISCUSS] Creation of ooo-security List
 
 On Wed, Jul 6, 2011 at 3:02 PM, Dennis E. Hamilton orc...@apache.org wrote:
 [I am reminded that the best way to talk to the PPMC is on ooo-dev and there 
 is benefit in so doing.  Here goes.]
 
 PROPOSAL
 
 ooo-security@incubator.a.o be set up as a private list and a selection of 
 not more than 10 security-aware PPMC members be subscribed to it.  We need 
 to work out what the composition would be.  The list will be automatically 
 forward to security@a.o.  I assume that there might be security-aware 
 ooo-podling mentors and other ASF Members included in the small PPMC 
 subscription.
 
 DETAILS
 
 General information about the Apache Security Team:
 http://www.apache.org/security/
 
 More details on the handling of security and vulnerabilities by committers 
 and the role of the [P]PMC:
 http://www.apache.org/security/committers.html
 
 Note that creation of a security page on our web site is also part of this.  
 That should happen near-immediately also.
 
 
 The website already has a Security link on the navigation panel, at
 the bottom.  This takes you to the main Apache security page where the
 reporter is instructed on how to submit reports.  According to that
 page, security reports are routed to the PMC in case we do not have a
 dedicated security list.  So I don't see the urgency on creating a new
 list or a new web page, especially since we don't even have code in
 the repository, let alone a release, and since there already is a
 security list and contact address at OOo.  I think that the existing
 procedures, in place at Apache, are adequate if someone wanted to
 report a problem
 
 The idea of having the discussion in private, on the PMC private list
 or on a private security list, is a  good idea, so that any
 vulnerability reported would not be immediately exploited by script
 kiddies.  Or at least the chances of that would be diminished.  But I
 don't think that any of the PPMC members are malicious hackers likely
 to abuse any security sensitive information shared on the PPMC list.
 Of course, only a subset of the members have security expertise.

Re: [DISCUSS] Creation of ooo-security List

2011-07-06 Thread Daniel Shahaf

Dennis E. Hamilton wrote on Wed, Jul 06, 2011 at 15:35:46 -0700:
 To make this conversation concrete: I have security issues I want to
 raise, which is what had me looking into this in the first place.

Then please report them to security@a.o and/or ooo-private@.

Re: http://OpenOffice.org httpd logs, web analytics, etc.


Rob,
I'm trying to track this down also - it's pretty distributed, and I am 
not sure what is sharable.
I'll do what I can.   (does anyone know who used to collect the stats 
for OOo?)

Andrew

On 6/27/2011 5:33 AM, Rob Weir wrote:

Do we have any detailed access logs or reports for OOo?  I think that
would be useful for prioritizing service migration, decided what to
archive versus what to keep alive, etc.  I've heard a lot of anecdotal
stories, but hard data is good to get the complete picture.

If it would be possible to get, say YTD httpd logs, then I could
generate some reports showing what web site services are post used.
Since the raw data likely has client IP addresses we probably should
treat it as it as sensitive and share only on the PMC's private
repository.

Same information would be useful for capacity planning purposes.

Also, how do Apache projects handle web analytics?  Is there any
tracking code installed by default? Is this permitted?  Do projects
have access to their httpd logs?

-Rob

Re: [DISCUSS] Creation of ooo-security List

2011-07-06 Thread Daniel Shahaf

Dennis E. Hamilton wrote on Wed, Jul 06, 2011 at 12:02:31 -0700:
 I've learned that the Apache approach is for each PMC taking the lead
 in handling security matters related to its releases.  To maintain the
 security of security matters, the practice is to have a private list
 (for us, ooo-security) with not more than ten security-aware
 subscribers.

I've never heard of a magic number cap to the # of subscribers of
a mailing list.

Re: DITA for Doc?

On Wed, Jul 6, 2011 at 6:11 PM, Dave Fisher dave2w...@comcast.net wrote:
 Hi Rob,

 On Jul 6, 2011, at 2:10 PM, Rob Weir wrote:

  we've already done the work
 of converting much of the OOo help to DITA.

 Is there a software grant coming?


It is worth considering.  But I'm not going to face that corporate red
tape merely on speculation that this might be useful.  Let's first
discuss whether the DITA approach seems reasonable.  I think it is
important for content authors to be aware that this would be writing
documentation with tags, similar to HTML.  Good HTML.  But this
structure would give us loads of flexibility for how we structure the
content, combine it is different ways, and publish it.

You can get a flavor of DITA here:

http://www.xmlmind.com/tutorials/DITA/index.html

Tags are off-putting to some people who just want to work in a WYSIWYG
fashion, so I wanted to check.  One possible way of working is to
accept raw content in any reasonable format, ODF, DOC, HTML, yellow
crayon on a napkin, etc., and then have a manual cut  paste process
to get that into DITA initially, and then maintain it that way going
forward.

 Regards,
 Dave

Re: [DISCUSS] Creation of ooo-security List

2011-07-06 Thread Wolf Halton

In some ways, the larger the security group, the quicker the solution rate.
Security patched will need to be checked before they are committed, so the
issue fixed doesn't break 3 other parts of the code.


On Wed, Jul 6, 2011 at 6:54 PM, Daniel Shahaf d...@daniel.shahaf.namewrote:

 Dennis E. Hamilton wrote on Wed, Jul 06, 2011 at 12:02:31 -0700:
  I've learned that the Apache approach is for each PMC taking the lead
  in handling security matters related to its releases.  To maintain the
  security of security matters, the practice is to have a private list
  (for us, ooo-security) with not more than ten security-aware
  subscribers.

 I've never heard of a magic number cap to the # of subscribers of
 a mailing list.




-- 
This Apt Has Super Cow Powers - http://sourcefreedom.com

Re: fetch-all-cws.sh (was: Building a single Hg repository)

Hi Andrew,

Thanks for the update.

On 7/5/2011 8:53 AM, Pedro F. Giffuni wrote:
I agree with Mathias ..

We are not advancing simply because it's not clear who does what.

- Greg made a script to import the Hg stuff ... who will run it?
A number of us are - and props gentlemen, the scripts work great.

- Matthias made a list, is this what Oracle should relicense, or
perhaps we should wait until we merge the resulting SVN branches.
- Who takes the list to Oracle.
As discussed before on the list, I am tracking all of the resources that have
been identified and will be working this all through on the Oracle side.
The list goes beyond just code, to artwork, bz database, translations, the
forums, wikis, and more.

If possible would you provide some more detail in the wiki - probably on one of
these pages - https://cwiki.apache.org/confluence/label/OOOUSERS/site

About artwork, I found these pages the other day:

http://www.openoffice.org/trademark/brandrefresh.html
http://ui.openoffice.org/VisualDesign/OOo3_refresh.html
http://patentpending.co.nz/2010/04/04/openoffice-org-new-setup-file-and-application-icons/

I was wondering when we might get our hands on the original photoshop (or is it
something else?) files for the logos.

- Bugzilla or JIRA?
(I personally lean JIRA)

Since the BZ is behind and has a non-standard schema, maybe the next step is to
understand the actual altered schema vs. both the JIRA and BZ 4.0 schemas. Once
we know that the work to convert can be determined. Mark Thomas had some ideas,
he's the guy on the Apache Infra for BZ/JIRA.

- Who can provide the MediaWiki stuff so we actually translate
it to confluence?
working on this, also.

Do you think that the UWC[1] will be useful? Or, will we need to make up our
own translation?

Regards,
Dave

[1] https://studio.plugins.atlassian.com/wiki/display/UWC/UWC+User+Documentation

We really need people taking the tasks at hand.

cheers,

Pedro.

--- On Tue, 7/5/11, Joe Schaeferjoe_schae...@yahoo.com wrote:

From: Joe Schaeferjoe_schae...@yahoo.com
Subject: Re: fetch-all-cws.sh (was: Building a single Hg repository)
To: ooo-dev@incubator.apache.org
Date: Tuesday, July 5, 2011, 9:58 AM

- Original Message
From: Mathias Bauermathias_ba...@gmx.net
To: ooo-dev@incubator.apache.org
Sent: Tue, July 5, 2011 10:55:25 AM
Subject: Re: fetch-all-cws.sh (was: Building a single
Hg repository)
On 01.07.2011 23:18, Greg Stein wrote:

Right. I think we just bring it all over,
and then sort it out in our
repository.
May I ask who will be the one that brings it
all over? I don't find
the reference, but from past reading I
understood that this is nothing
that one of us regular committers can do.
Why not? It's DVCS after all, so long as we have a
*repeatable* process
for populating an svn dump file, and there's a way to map
that process over
to whatever file list Oracle is willing to provide, seems
like any developer
can initiate this process.

Re: OOO and LibreOffice.

2011-07-06 Thread Jomar Silva



On 2011/6/6 19:52 Andrew Rist andrew.r...@oracle.com wrote: 


To date the LibreOffice crew has taken the effort to merge in changes 
from the OOo code line, for each release.
The most obvious and best way to collaborate in the future is to write 
good code, and make it worth their while to integrate it into LO.
The more compelling the development effort at Apache, the more likely it 
is reused by LO.
This also leads to the situation where they have an interest in pushing 
changes into the AOOo code line, to simplify their future merges.

Andrew

+1

Best,

Jomar

Re: [DISCUSS] Creation of ooo-security List

On Wed, Jul 6, 2011 at 6:35 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Well, vulnerabilities are vulnerabilities and if there is an exposure in 
 current code or in documents produced in current code, isn't that a concern 
 for us now?  Why would it not be?


I'm not saying it is not a concern.  I'm saying if you think it is a
concern, then get on with it and report the concern.

 Also, I don't presume that everyone is downstream from us (as opposed to the 
 OpenOffice.org that once was).

 I think of LibreOffice as a mutual stakeholder because it seems they have a 
 security team too and like it or not, they are cranking out releases very 
 quickly and may be able to provide mitigations, hypothetically, months before 
 we ever get a release of ours out the door.


And IBM and RedOffice and Oracle doesn't have products in use based on
this same code?  And they don't have people who work with security?  I
question your definition of mutual stakeholder, especially since our
list of Committers has members from IBM, RedOffice and Oracle, but
none from LibreOffice.

And how often feature releases are cranked out is irrelevant to how
quickly a vendor can release a security patch if needed.  You are
mixes two different kinds of releases.

 Also, some security issues may require a jointly-agreed response so that we 
 attend to interoperability concerns, especially if mitigation involves 
 breaking changes or even introduction of allowed extensions (in the context 
 of the ODF specifications).  Anything that fits into a discretionary area 
 requiring producer-consumer agreement to work needs a community to unfold it.

 I don't know about the details of having that work.  I do know if I uncover a 
 problem, I am going to communicate it to every security-conscious entity I 
 can.


Hopefully this will include the Apache security list at some point.

 To make this conversation concrete: I have security issues I want to raise, 
 which is what had me looking into this in the first place.  I would like to 
 do this in a manner that is in keeping with concerns for dealing with 
 security matters privately to ensure that there is competent review and no 
 danger attached to premature disclosure.  (I suspect not, because the 
 vulnerabilities I am aware of exist in plain sight, but I want the counsel of 
 someone having more security experience than I before saying, Heck, I need 
 something for today's blog post, why not stir things up with this?)


The Apache process for handling this is documented and it explicitly
covers the case of reports for a project that does not have a
dedicated security list.


  - Dennis

 -Original Message-
 From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir
 Sent: Wednesday, July 06, 2011 14:40
 To: ooo-dev@incubator.apache.org
 Subject: Re: [DISCUSS] Creation of ooo-security List

 On Wed, Jul 6, 2011 at 3:02 PM, Dennis E. Hamilton orc...@apache.org wrote:
 [I am reminded that the best way to talk to the PPMC is on ooo-dev and there 
 is benefit in so doing.  Here goes.]

 PROPOSAL

 ooo-security@incubator.a.o be set up as a private list and a selection of 
 not more than 10 security-aware PPMC members be subscribed to it.  We need 
 to work out what the composition would be.  The list will be automatically 
 forward to security@a.o.  I assume that there might be security-aware 
 ooo-podling mentors and other ASF Members included in the small PPMC 
 subscription.

 DETAILS

 General information about the Apache Security Team:
 http://www.apache.org/security/

 More details on the handling of security and vulnerabilities by committers 
 and the role of the [P]PMC:
 http://www.apache.org/security/committers.html

 Note that creation of a security page on our web site is also part of this.  
 That should happen near-immediately also.


 The website already has a Security link on the navigation panel, at
 the bottom.  This takes you to the main Apache security page where the
 reporter is instructed on how to submit reports.  According to that
 page, security reports are routed to the PMC in case we do not have a
 dedicated security list.  So I don't see the urgency on creating a new
 list or a new web page, especially since we don't even have code in
 the repository, let alone a release, and since there already is a
 security list and contact address at OOo.  I think that the existing
 procedures, in place at Apache, are adequate if someone wanted to
 report a problem

 The idea of having the discussion in private, on the PMC private list
 or on a private security list, is a  good idea, so that any
 vulnerability reported would not be immediately exploited by script
 kiddies.  Or at least the chances of that would be diminished.  But I
 don't think that any of the PPMC members are malicious hackers likely
 to abuse any security sensitive information shared on the PPMC list.
 Of course, only a subset of the members have security expertise.


 BACKGROUND

Re: http://OpenOffice.org httpd logs, web analytics, etc.

Thanks for anything you can find.  The alternative would be to start
collecting logs now, for  a month, and use that.  Or instrument with
Google Analytics or something.  That would give us a good indication
of what pages are most retrieved now.  Not quite as good as knowing
what was most-used back when the site was used for active development,
but would tell us what pages users are going after most.

-Rob

On Wed, Jul 6, 2011 at 6:53 PM, Andrew Rist andrew.r...@oracle.com wrote:
 Rob,
 I'm trying to track this down also - it's pretty distributed, and I am not
 sure what is sharable.
 I'll do what I can.   (does anyone know who used to collect the stats for
 OOo?)
 Andrew

 On 6/27/2011 5:33 AM, Rob Weir wrote:

 Do we have any detailed access logs or reports for OOo?  I think that
 would be useful for prioritizing service migration, decided what to
 archive versus what to keep alive, etc.  I've heard a lot of anecdotal
 stories, but hard data is good to get the complete picture.

 If it would be possible to get, say YTD httpd logs, then I could
 generate some reports showing what web site services are post used.
 Since the raw data likely has client IP addresses we probably should
 treat it as it as sensitive and share only on the PMC's private
 repository.

 Same information would be useful for capacity planning purposes.

 Also, how do Apache projects handle web analytics?  Is there any
 tracking code installed by default? Is this permitted?  Do projects
 have access to their httpd logs?

 -Rob

Re: fetch-all-cws.sh (was: Building a single Hg repository)

On Wed, Jul 6, 2011 at 6:41 PM, Simon Phipps si...@webmink.com wrote:

 On 6 Jul 2011, at 23:19, Rob Weir wrote:

 I think we're transitioning from a formally coordinated model led by a
 corporation to a model that will have less formal coordination
 structures.  This is necessary to grow the project in the absence of
 corporate control.  But it will take some time to get used to it.

 I've always assumed that the extremely careful approach the development team 
 was using was more a function of the size, complexity and intra-dependency of 
 the code than of corporate control. It is amazing how a small, obvious change 
 in one part of OOo can result in a nasty intermittent fault in another part...


I've heard rumors of large C/C++ software applications where this is
not true, but I have yet to see one.

-Rob

Re: DITA for Doc?


On Jul 6, 2011, at 3:55 PM, Rob Weir wrote:

 On Wed, Jul 6, 2011 at 6:11 PM, Dave Fisher dave2w...@comcast.net wrote:
 Hi Rob,
 
 On Jul 6, 2011, at 2:10 PM, Rob Weir wrote:
 
  we've already done the work
 of converting much of the OOo help to DITA.
 
 Is there a software grant coming?
 
 
 It is worth considering.  But I'm not going to face that corporate red
 tape merely on speculation that this might be useful.  Let's first
 discuss whether the DITA approach seems reasonable.  I think it is
 important for content authors to be aware that this would be writing
 documentation with tags, similar to HTML.  Good HTML.  But this
 structure would give us loads of flexibility for how we structure the
 content, combine it is different ways, and publish it.
 
 You can get a flavor of DITA here:
 
 http://www.xmlmind.com/tutorials/DITA/index.html

An example is always helpful. I think that DITA is a reasonable form.

The topicref hierarchy is a critical necessity. It is likely as good as

 Tags are off-putting to some people who just want to work in a WYSIWYG
 fashion, so I wanted to check.

I like tags. Where is a complete reference?

It is difficult to repurpose content if is over-fiddled with in a WYSIWYG 
fashion.

Since we want to repurpose this content in many ways this can make sense.

  One possible way of working is to
 accept raw content in any reasonable format, ODF, DOC, HTML, yellow
 crayon on a napkin, etc., and then have a manual cut  paste process
 to get that into DITA initially, and then maintain it that way going
 forward.

I think that we can strive to go back and forth between DITA and markdown. The 
Apache CMS is easily extensible with XSL. I can see how to structure a 
transformation.

How does DITA handle style sheets? Is it easy to have different layout 
templates for different outputs.

Is there an ODF to DITA translation?

I am currently looking closely at the Apache CMS someone will need to look at 
the requirements. Where's the best release and what's required?

Regards,
Dave


 
 Regards,
 Dave

Re: DITA for Doc?

2011-07-06 Thread florent andré




On 07/07/2011 01:33 AM, Dave Fisher wrote:



...


I am currently looking closely at the Apache CMS someone will need to look at 
the requirements. Where's the best release and what's required?


cms code :
https://svn.apache.org/repos/infra/websites/cms/

cms doc :
http://www.apache.org/dev/cms.html

RE: [DISCUSS] Creation of ooo-security List

I didn't say there were no other mutual stakeholders.  I mentioned one whose 
security list I knew about already.  It does raise interesting questions for 
when concerted action is desirable though.

I am not confusing security fixes with other fixes.  However, slip-streaming 
some easy things is clearly an opportunity at LO at the moment.  I can imagine 
some changes not even being announced as security fixes.  I don't know about 
slip-streaming at IBM, RedOffice, Oracle, Microsoft, etc.

 - Dennis

-Original Message-
From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir
Sent: Wednesday, July 06, 2011 16:10
To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: [DISCUSS] Creation of ooo-security List

On Wed, Jul 6, 2011 at 6:35 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Well, vulnerabilities are vulnerabilities and if there is an exposure in 
 current code or in documents produced in current code, isn't that a concern 
 for us now?  Why would it not be?


I'm not saying it is not a concern.  I'm saying if you think it is a
concern, then get on with it and report the concern.

 Also, I don't presume that everyone is downstream from us (as opposed to the 
 OpenOffice.org that once was).

 I think of LibreOffice as a mutual stakeholder because it seems they have a 
 security team too and like it or not, they are cranking out releases very 
 quickly and may be able to provide mitigations, hypothetically, months before 
 we ever get a release of ours out the door.


And IBM and RedOffice and Oracle doesn't have products in use based on
this same code?  And they don't have people who work with security?  I
question your definition of mutual stakeholder, especially since our
list of Committers has members from IBM, RedOffice and Oracle, but
none from LibreOffice.

And how often feature releases are cranked out is irrelevant to how
quickly a vendor can release a security patch if needed.  You are
mixes two different kinds of releases.

 Also, some security issues may require a jointly-agreed response so that we 
 attend to interoperability concerns, especially if mitigation involves 
 breaking changes or even introduction of allowed extensions (in the context 
 of the ODF specifications).  Anything that fits into a discretionary area 
 requiring producer-consumer agreement to work needs a community to unfold it.

 I don't know about the details of having that work.  I do know if I uncover a 
 problem, I am going to communicate it to every security-conscious entity I 
 can.


Hopefully this will include the Apache security list at some point.

 To make this conversation concrete: I have security issues I want to raise, 
 which is what had me looking into this in the first place.  I would like to 
 do this in a manner that is in keeping with concerns for dealing with 
 security matters privately to ensure that there is competent review and no 
 danger attached to premature disclosure.  (I suspect not, because the 
 vulnerabilities I am aware of exist in plain sight, but I want the counsel of 
 someone having more security experience than I before saying, Heck, I need 
 something for today's blog post, why not stir things up with this?)


The Apache process for handling this is documented and it explicitly
covers the case of reports for a project that does not have a
dedicated security list.


  - Dennis

 -Original Message-
 From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir
 Sent: Wednesday, July 06, 2011 14:40
 To: ooo-dev@incubator.apache.org
 Subject: Re: [DISCUSS] Creation of ooo-security List

 On Wed, Jul 6, 2011 at 3:02 PM, Dennis E. Hamilton orc...@apache.org wrote:
 [I am reminded that the best way to talk to the PPMC is on ooo-dev and there 
 is benefit in so doing.  Here goes.]

 PROPOSAL

 ooo-security@incubator.a.o be set up as a private list and a selection of 
 not more than 10 security-aware PPMC members be subscribed to it.  We need 
 to work out what the composition would be.  The list will be automatically 
 forward to security@a.o.  I assume that there might be security-aware 
 ooo-podling mentors and other ASF Members included in the small PPMC 
 subscription.

 DETAILS

 General information about the Apache Security Team:
 http://www.apache.org/security/

 More details on the handling of security and vulnerabilities by committers 
 and the role of the [P]PMC:
 http://www.apache.org/security/committers.html

 Note that creation of a security page on our web site is also part of this.  
 That should happen near-immediately also.


 The website already has a Security link on the navigation panel, at
 the bottom.  This takes you to the main Apache security page where the
 reporter is instructed on how to submit reports.  According to that
 page, security reports are routed to the PMC in case we do not have a
 dedicated security list.  So I don't see the urgency on creating a new
 list or a new web page,

RE: [DISCUSS] Creation of ooo-security List

I'm assuming the goal is to keep the analysis and discussion of alleged 
vulnerabilities to a relatively small need-to-know group.  

I don't know that 10 is a hard number, I heard it as a suggestion when I asked 
around about how this works at Apache.  Do you know typical sizes for 
security@project lists?

 - Dennis

-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Wednesday, July 06, 2011 15:54
To: OOo-dev Apache Incubator
Subject: Re: [DISCUSS] Creation of ooo-security List

Dennis E. Hamilton wrote on Wed, Jul 06, 2011 at 12:02:31 -0700:
 I've learned that the Apache approach is for each PMC taking the lead
 in handling security matters related to its releases.  To maintain the
 security of security matters, the practice is to have a private list
 (for us, ooo-security) with not more than ten security-aware
 subscribers.

I've never heard of a magic number cap to the # of subscribers of
a mailing list.

Re: [DISCUSS] Creation of ooo-security List

On Wed, Jul 6, 2011 at 18:35, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Well, vulnerabilities are vulnerabilities and if there is an exposure in 
 current code or in documents produced in current code, isn't that a concern 
 for us now?  Why would it not be?

 Also, I don't presume that everyone is downstream from us (as opposed to the 
 OpenOffice.org that once was).

 I think of LibreOffice as a mutual stakeholder because it seems they have a 
 security team too and like it or not, they are cranking out releases very 
 quickly and may be able to provide mitigations, hypothetically, months before 
 we ever get a release of ours out the door.

We can get guidance from the Apache Security Team on this. I suspect
they would concur: work with the development/security teams of people
development forks of OOo. Downstream users would presumably get a
standard pre-notification email.

...
 I don't know about the details of having that work.  I do know if I uncover a 
 problem, I am going to communicate it to every security-conscious entity I 
 can.

The best answer is to ask Security for advice here. There is an
industry-standard approach to this kind of notification.

 To make this conversation concrete: I have security issues I want to raise, 
 which is what had me looking into this in the first place.  I would like to 
 do this in a manner that is in keeping with concerns for dealing with 
 security matters privately to ensure that there is competent review and no 
 danger attached to premature disclosure.  (I suspect not, because the 
 vulnerabilities I am aware of exist in plain sight, but I want the counsel of 
 someone having more security experience than I before saying, Heck, I need 
 something for today's blog post, why not stir things up with this?)

Start with secur...@apache.org, and go from there.

Cheers,
-g

Re: DITA for Doc?