Re: investigation using Google Webmaster tools
Hi Rob; - Original Message - ... We cannot do maintainance for broken links here. Perhaps we should remind users to report broken links on the originating websites. Certainly we can fix this on our end. In fact I just did: http://www.openoffice.org/licenses/lgpl_license.html This isn't rocket science. It is just a minor courtesy to website visitors not to break common links for no good reason. I will give you credit. That page does look like a fine replacement. 63999 broken links to go ;). Pedro.
Issues building Symphony
Hi; I tried configuring Symphony under FreeBSD and I can basically confirm that the instructions in the Wiki are wrong. The Wiki here http://wiki.services.openoffice.org/wiki/How_to_build_Symphony's_source_code mentions --disable-build-mozilla but that option doesn't work, you need --disable-mozilla Under FreeBSD the basic configure procedure is somewhat complicated because cups and other thirdparty software is installed in /usr/local. The version of configure.in in Symphony still has references to the obsolete Pentaho stuff. I did get it to configure with this set of options: ./configure --x-includes=/usr/local/include --x-libraries=/usr/local/lib \ --without-junit \ --disable-odk \ --disable-mozilla \ --enable-category-b \ --with-system-zlib \ --disable-gstreamer \ --with-system-libxml \ --enable-bundled-dictionaries \ --with-gnu-patch=/usr/local/bin/gpatch The next issue is this: build -- version: 275224 Ambiguous paths for module hunspell: /usr/ports/editors/symphony/work/ooo/main/hunspell and /usr/ports/editors/symphony/work/ooo/ext_libraries/hunspell at /usr/ports/editors/openoffice-3-devel/work/ooo/main/solenv/bin/build.pl line 244 __ I guess I can use some brute force to get it to build but I am wondering if that makes sense :(. We will see ... cheers, Pedro.
Re: Python
Hello guys; FWIW, the update to version 2.7.3 doesnt really bring a big difference wrt 2.6.1 but I dont think we will be able to update python further in a long while because there are extensions out there that depend on Python2. Adding Python3 compatibility is not difficult, I think, but an interesting alternative, that people can try now, would be to build/ship AOO with PyPy : http://pypy.org/ Cheers, Pedro.
Re: What to say in AOO 3.4.1 release announcement about the ports? (BSD, Solaris, OS/2)?
Hi Kay; I did some basic update to the FreeBSD porting site sometime ago: http://www.openoffice.org/porting/freebsd/ The site doesn't seem linked from the top-level porting site though. I would prefer to spend my time on the code rather than on the release announcement, however feel free to mention explicitly the FreeBSD port. Just to make it clear: we still have some cleanup to do but the port is fully operational and FreeBSD users are fully aware that it's available on FreeBSD releases. Pedro. From: Kay Schenk kay.sch...@gmail.com To: ooo-dev@incubator.apache.org Sent: Wednesday, August 1, 2012 10:47 AM Subject: Re: What to say in AOO 3.4.1 release announcement about the ports? (BSD, Solaris, OS/2)? On Tue, Jul 31, 2012 at 2:04 PM, drew d...@baseanswers.com wrote: On Tue, 2012-07-31 at 14:36 -0400, Rob Weir wrote: I'm drafting the 3.4.1 release announcement blog post. I have a bullet list where I highlight what is in 3.4.1. I list what platforms are supported, mention the Windows 8 compatibility improvements, and then follow with this bullet item: Community members are also working on BSD, Solaris and OS/2 ports, with plans to release these outside of Apache. Howdy Rob, Is this accurate and worth saying? Yes IIRC and yes IMO. Would it make sense to also include links for each of these ports, where the reader can go for more information? I would think a better return if instead of putting direct links for each, create a fixed address (wiki page?) for 'other ports' (or more appropriate for a title). Hi Drew-- We have a page -- actually a former project at -- http://www.openoffice.org/porting/ that needs a LOT of cleanup. Any volunteers to take the lead on cleaning this up and just highlighting what we're dealing with now? FreeBSD, OS/2, and Solaris? Link to that from the announcement/blog and would make that a precedent for future announcements. Although these are not Apache releases, they are part of the close ecosystem, with developers working directly in our project to support these ports. So I think there is some logic to mentioning them in the release announcement. But work that happens entirely outside of the project, like portable applications versions, would not get a mention. I would disagree, somewhat, in that personal preference would be to include the 2 or 3 portable 'wrapper' distributors as this has seemed to be of interest to quite a few folks in the past. Just my .02 //drew Does this seem fair and appropriate? If we agree to do this, I'll need a link for each of BSD, Solaris and OS/2, for more information. The alternative would be to not mention the ports at all. Regards, -Rob -- MzK I'm just a normal jerk who happens to make music. As long as my brain and fingers work, I'm cool. -- Eddie Van Halen
Re: What to say in AOO 3.4.1 release announcement about the ports? (BSD, Solaris, OS/2)?
Hi Drew; That would be a start ;). The FreeBSD site can still have some enhancements, like adding a link to the ports: http://www.freshports.org/editors/openoffice-3/ http://www.freshports.org/editors/openoffice-3-devel/ but I guess I can have a try on that later on with my rudimentary html. :) Pedro. From: drew jensen drewjensen.in...@gmail.com To: Pedro Giffuni p...@apache.org Cc: ooo-dev@incubator.apache.org ooo-dev@incubator.apache.org Sent: Wednesday, August 1, 2012 11:24 AM Subject: Re: What to say in AOO 3.4.1 release announcement about the ports? (BSD, Solaris, OS/2)? On Wed, 2012-08-01 at 09:09 -0700, Pedro Giffuni wrote: Hi Kay; I did some basic update to the FreeBSD porting site sometime ago: http://www.openoffice.org/porting/freebsd/ The site doesn't seem linked from the top-level porting site though. I would prefer to spend my time on the code rather than on the release announcement, however feel free to mention explicitly the FreeBSD port. Just to make it clear: we still have some cleanup to do but the port is fully operational and FreeBSD users are fully aware that it's available on FreeBSD releases. Pedro. Hi Pedro, Then for BSD it should be enough to just point to the page you updated, yes? //drew snip
Re: trunk build fails, likely in python
Thank you Tsutomu!
The other patches should also be used. I am not sure if dmake supports
the += operator so I just went back to the old patching method on
revision 1367616.
This is hopefully the last change there. Sorry to take you guys
as guinea pigs ;).
Pedro.
From: Tsutomu Uchino hanya.r...@gmail.com
To: ooo-dev@incubator.apache.org
Sent: Tuesday, July 31, 2012 8:57 AM
Subject: Re: trunk build fails, likely in python
Hi,
2012/7/31 Regina Henschel rb.hensc...@t-online.de:
Hi Pedro,
I still cannot build Python.
Messages are:
dmake: Warning: -- Found file corresponding to virtual target
[./wntmsci12/misc/build/Python-2.7.3/PC/pyconfig.h].
Build started: Project: _ssl, Configuration: Release|Win32
Performing Pre-Build Event...
Can not find a suitable PERL:
the following perl interpreters were found:
C:\cygwin\bin\perl.exe
None of these versions appear suitable for building OpenSSL
Please install ActivePerl and ensure it appears on your path
No Perl installation was found. Existing Makefiles are used.
Could not find an SSL directory in '('..\\..',)'
Project : error PRJ0019: A tool returned an error code from Performing
Pre-Build Event...
Project : warning PRJ0018 : The following environment variables were not
found:
$(UPDMINOREXT)
Kind regards
Regina
Pedro Giffuni schrieb:
Committed as Revision 1367398 . Please test.
Hopefully I learned from the error that Regina reported to
cleanup better the code.
Pedro.
From: Pedro Giffuni p...@apache.org
To: ooo-dev@incubator.apache.org ooo-dev@incubator.apache.org
Sent: Monday, July 30, 2012 8:34 PM
Subject: Re: trunk build fails, likely in python
Thank you.
I will use this as an opportunity to do some further cleanup
Pedro.
From: Lin Yuan yuanlin@gmail.com
To: ooo-dev@incubator.apache.org
Sent: Monday, July 30, 2012 8:26 PM
Subject: Re: trunk build fails, likely in python
I can reproduce this issue on my Win 7.
In Python-2.7.3\PCbuild\pcbuild.sln, there are two projects related to
sqlite3. One named sqlite3. Another named _sqlite3. Both of them
need
to be remarked. But in python-2.7.3.patch, it only remark project
sqlite3. Need also remark project _sqlite3 in pcbuild.sln.
2012/7/31 Regina Henschel rb.hensc...@t-online.de
Hi Armin,
I have rebased and deleted all the wbtmsci12*, then started a new
build. I
now get the same error as you.
Kind regards
Regina
Armin Le Grand schrieb:
Hi,
just checked out current version and build stopped in python (win7).
Message is as follows.
Where does sqlite3.h come from? There is a folder
main\python\wntmsci12\misc\**build\Python-2.7.3\Doc\**includes\sqlite3
but
no sqlite3.h in there. Should it be there...?
Can someone help please?
--8-
c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\**
python-2.7.3\modules\_sqlite\**connection.h(33)
: fatal error C1083: Cannot open include file: 'sqlite3.h': No such
file
or directory
statement.c
c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\**
python-2.7.3\modules\_sqlite\**connection.h(33)
: fatal error C1083: Cannot open include file: 'sqlite3.h': No such
file
or directory
row.c
c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\**
python-2.7.3\modules\_sqlite\**connection.h(33)
: fatal error C1083: Cannot open include file: 'sqlite3.h': No such
file
or directory
module.c
c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\**
python-2.7.3\modules\_sqlite\**connection.h(33)
: fatal error C1083: Cannot open include file: 'sqlite3.h': No such
file
or directory
microprotocols.c
c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\**
python-2.7.3\modules\_sqlite\**connection.h(33)
: fatal error C1083: Cannot open include file: 'sqlite3.h': No such
file
or directory
cursor.c
c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\**
python-2.7.3\modules\_sqlite\**connection.h(33)
: fatal error C1083: Cannot open include file: 'sqlite3.h': No such
file
or directory
connection.c
c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\**
python-2.7.3\modules\_sqlite\**connection.h(33)
: fatal error C1083: Cannot open include file: 'sqlite3.h': No such
file
or directory
Build log was saved at
file://C:\aoo\svn_trunk13\**main\python\wntmsci12\misc\**
build\Python-2.7.3\PCbuild\**Win32-temp-Release\_sqlite3\**BuildLog.htm
_sqlite3 - 7 error(s), 0 warning(s)
Build started: Project: _testcapi, Configuration: Release|Win32
_testcapi - up-to-date
Build started: Project: select, Configuration: Release|Win32
select - up-to-date
Build started: Project: unicodedata, Configuration: Release|Win32
unicodedata - up-to-date
Build started: Project: pyexpat, Configuration: Release|Win32
pyexpat - up-to-date
Build started: Project: _multiprocessing, Configuration: Release|Win32
_multiprocessing - up-to-date
Build started: Project
Re: trunk build fails, likely in python
Hello Armin; This builds cleanly on FreeBSD/linux , and apparently at least Regina got it to build beyond python. That's pretty weird: python-2.7.3.patch comments out the sqlite3 project for MSVC (just like python-2.6.1.patch did before that). I don't have a Windows build so I am basically doing the same as was done in the previous python. Perhaps it's a cygwin-specific issue. I don't see anything obvious but I will keep looking. Pedro. From: Armin Le Grand armin.le.gr...@me.com To: ooo-dev@incubator.apache.org Sent: Monday, July 30, 2012 11:02 AM Subject: Re: trunk build fails, likely in python Hi, just checked out current version and build stopped in python (win7). Message is as follows. Where does sqlite3.h come from? There is a folder main\python\wntmsci12\misc\build\Python-2.7.3\Doc\includes\sqlite3 but no sqlite3.h in there. Should it be there...? Can someone help please? --8- c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory statement.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory row.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory module.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory microprotocols.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory cursor.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory connection.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory Build log was saved at file://C:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\Python-2.7.3\PCbuild\Win32-temp-Release\_sqlite3\BuildLog.htm _sqlite3 - 7 error(s), 0 warning(s) Build started: Project: _testcapi, Configuration: Release|Win32 _testcapi - up-to-date Build started: Project: select, Configuration: Release|Win32 select - up-to-date Build started: Project: unicodedata, Configuration: Release|Win32 unicodedata - up-to-date Build started: Project: pyexpat, Configuration: Release|Win32 pyexpat - up-to-date Build started: Project: _multiprocessing, Configuration: Release|Win32 _multiprocessing - up-to-date Build started: Project: _ssl, Configuration: Release|Win32 Project : warning PRJ0018 : The following environment variables were not found: $(UPDMINOREXT) _ssl - up-to-date Build complete: 18 Projects succeeded, 1 Projects failed, 1 Projects skipped dmake: Error code 1, while making './wntmsci12/misc/build/so_built_so_python' ERROR: error 65280 occurred while making /cygdrive/c/aoo/svn_trunk13/main/python --8- On 28.07.2012 01:33, Regina Henschel wrote: Hi, I start a build on WinXP with MSVC Express. It fails with error message dmake: Error: -- `./Python-2.7.3-vc.patch' not found, and can't be made What do I miss? Kind regards Regina
Re: trunk build fails, likely in python
FWIW, One hint: googling around it looks like it's and issue when building a debug python. Pedro. From: Armin Le Grand armin.le.gr...@me.com To: ooo-dev@incubator.apache.org Sent: Monday, July 30, 2012 11:02 AM Subject: Re: trunk build fails, likely in python Hi, just checked out current version and build stopped in python (win7). Message is as follows. Where does sqlite3.h come from? There is a folder main\python\wntmsci12\misc\build\Python-2.7.3\Doc\includes\sqlite3 but no sqlite3.h in there. Should it be there...? Can someone help please? --8- c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory statement.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory row.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory module.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory microprotocols.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory cursor.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory connection.c c:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\python-2.7.3\modules\_sqlite\connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory Build log was saved at file://C:\aoo\svn_trunk13\main\python\wntmsci12\misc\build\Python-2.7.3\PCbuild\Win32-temp-Release\_sqlite3\BuildLog.htm _sqlite3 - 7 error(s), 0 warning(s) Build started: Project: _testcapi, Configuration: Release|Win32 _testcapi - up-to-date Build started: Project: select, Configuration: Release|Win32 select - up-to-date Build started: Project: unicodedata, Configuration: Release|Win32 unicodedata - up-to-date Build started: Project: pyexpat, Configuration: Release|Win32 pyexpat - up-to-date Build started: Project: _multiprocessing, Configuration: Release|Win32 _multiprocessing - up-to-date Build started: Project: _ssl, Configuration: Release|Win32 Project : warning PRJ0018 : The following environment variables were not found: $(UPDMINOREXT) _ssl - up-to-date Build complete: 18 Projects succeeded, 1 Projects failed, 1 Projects skipped dmake: Error code 1, while making './wntmsci12/misc/build/so_built_so_python' ERROR: error 65280 occurred while making /cygdrive/c/aoo/svn_trunk13/main/python --8- On 28.07.2012 01:33, Regina Henschel wrote: Hi, I start a build on WinXP with MSVC Express. It fails with error message dmake: Error: -- `./Python-2.7.3-vc.patch' not found, and can't be made What do I miss? Kind regards Regina
Re: trunk build fails, likely in python
Thank you. I will use this as an opportunity to do some further cleanup Pedro. From: Lin Yuan yuanlin@gmail.com To: ooo-dev@incubator.apache.org Sent: Monday, July 30, 2012 8:26 PM Subject: Re: trunk build fails, likely in python I can reproduce this issue on my Win 7. In Python-2.7.3\PCbuild\pcbuild.sln, there are two projects related to sqlite3. One named sqlite3. Another named _sqlite3. Both of them need to be remarked. But in python-2.7.3.patch, it only remark project sqlite3. Need also remark project _sqlite3 in pcbuild.sln. 2012/7/31 Regina Henschel rb.hensc...@t-online.de Hi Armin, I have rebased and deleted all the wbtmsci12*, then started a new build. I now get the same error as you. Kind regards Regina Armin Le Grand schrieb: Hi, just checked out current version and build stopped in python (win7). Message is as follows. Where does sqlite3.h come from? There is a folder main\python\wntmsci12\misc\**build\Python-2.7.3\Doc\**includes\sqlite3 but no sqlite3.h in there. Should it be there...? Can someone help please? --8- c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory statement.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory row.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory module.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory microprotocols.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory cursor.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory connection.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory Build log was saved at file://C:\aoo\svn_trunk13\**main\python\wntmsci12\misc\** build\Python-2.7.3\PCbuild\**Win32-temp-Release\_sqlite3\**BuildLog.htm _sqlite3 - 7 error(s), 0 warning(s) Build started: Project: _testcapi, Configuration: Release|Win32 _testcapi - up-to-date Build started: Project: select, Configuration: Release|Win32 select - up-to-date Build started: Project: unicodedata, Configuration: Release|Win32 unicodedata - up-to-date Build started: Project: pyexpat, Configuration: Release|Win32 pyexpat - up-to-date Build started: Project: _multiprocessing, Configuration: Release|Win32 _multiprocessing - up-to-date Build started: Project: _ssl, Configuration: Release|Win32 Project : warning PRJ0018 : The following environment variables were not found: $(UPDMINOREXT) _ssl - up-to-date Build complete: 18 Projects succeeded, 1 Projects failed, 1 Projects skipped dmake: Error code 1, while making './wntmsci12/misc/build/so_**built_so_python' ERROR: error 65280 occurred while making /cygdrive/c/aoo/svn_trunk13/**main/python --8- On 28.07.2012 01:33, Regina Henschel wrote: Hi, I start a build on WinXP with MSVC Express. It fails with error message dmake: Error: -- `./Python-2.7.3-vc.patch' not found, and can't be made What do I miss? Kind regards Regina
Re: trunk build fails, likely in python
Committed as Revision 1367398 . Please test. Hopefully I learned from the error that Regina reported to cleanup better the code. Pedro. From: Pedro Giffuni p...@apache.org To: ooo-dev@incubator.apache.org ooo-dev@incubator.apache.org Sent: Monday, July 30, 2012 8:34 PM Subject: Re: trunk build fails, likely in python Thank you. I will use this as an opportunity to do some further cleanup Pedro. From: Lin Yuan yuanlin@gmail.com To: ooo-dev@incubator.apache.org Sent: Monday, July 30, 2012 8:26 PM Subject: Re: trunk build fails, likely in python I can reproduce this issue on my Win 7. In Python-2.7.3\PCbuild\pcbuild.sln, there are two projects related to sqlite3. One named sqlite3. Another named _sqlite3. Both of them need to be remarked. But in python-2.7.3.patch, it only remark project sqlite3. Need also remark project _sqlite3 in pcbuild.sln. 2012/7/31 Regina Henschel rb.hensc...@t-online.de Hi Armin, I have rebased and deleted all the wbtmsci12*, then started a new build. I now get the same error as you. Kind regards Regina Armin Le Grand schrieb: Hi, just checked out current version and build stopped in python (win7). Message is as follows. Where does sqlite3.h come from? There is a folder main\python\wntmsci12\misc\**build\Python-2.7.3\Doc\**includes\sqlite3 but no sqlite3.h in there. Should it be there...? Can someone help please? --8- c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory statement.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory row.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory module.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory microprotocols.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory cursor.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory connection.c c:\aoo\svn_trunk13\main\**python\wntmsci12\misc\build\** python-2.7.3\modules\_sqlite\**connection.h(33) : fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory Build log was saved at file://C:\aoo\svn_trunk13\**main\python\wntmsci12\misc\** build\Python-2.7.3\PCbuild\**Win32-temp-Release\_sqlite3\**BuildLog.htm _sqlite3 - 7 error(s), 0 warning(s) Build started: Project: _testcapi, Configuration: Release|Win32 _testcapi - up-to-date Build started: Project: select, Configuration: Release|Win32 select - up-to-date Build started: Project: unicodedata, Configuration: Release|Win32 unicodedata - up-to-date Build started: Project: pyexpat, Configuration: Release|Win32 pyexpat - up-to-date Build started: Project: _multiprocessing, Configuration: Release|Win32 _multiprocessing - up-to-date Build started: Project: _ssl, Configuration: Release|Win32 Project : warning PRJ0018 : The following environment variables were not found: $(UPDMINOREXT) _ssl - up-to-date Build complete: 18 Projects succeeded, 1 Projects failed, 1 Projects skipped dmake: Error code 1, while making './wntmsci12/misc/build/so_**built_so_python' ERROR: error 65280 occurred while making /cygdrive/c/aoo/svn_trunk13/**main/python --8- On 28.07.2012 01:33, Regina Henschel wrote: Hi, I start a build on WinXP with MSVC Express. It fails with error message dmake: Error: -- `./Python-2.7.3-vc.patch' not found, and can't be made What do I miss? Kind regards Regina
Re: T-Shirt for the Apache OpenOffice Project
+1 T-shirts are a a cheap but effective way to motivate committers. - Original Message - ... Hi at all At the old OOo project, we have had T-Shirts. There was existing many different versions of OOo shirts. Moastly they was payed, designed and distributed by one of the OOo related associations. Same Country have had also Fan Shirts wich are selled by OOo related NGO's. One T-Shirt was donated by SUN Microsystems. To have a T-Shirt is a nice thing, if you go to represent AOO at a Event. The old shirts are compleetly outdated. (the old dark blue logo and a logo from a company who is no longer existent) I realy like to have a new Shirt. Samething like a Committer Shirt, what you think about? But there are different problems. Since we have not our own monay at Apache, it's hard to solve the payment question. As far as I know, it's not allowd to put a sponsor on the shirt. I think you hit Traidmarke Issues from the ASF with it. And a Shirt will cost money. Maybe we can offer the Sponsor a Blog Post. The other topic is to distribute the Shirt all over the world. I realy like the Idea, but I'm simply on the wrong place to do samething like that. Switzerland is one of the moast expensive country in the world. Yes, I can do it from here, but finaly, it costs a load more then from a other country. I would realy like to have one for the ApacheCon Europe What do you think about? Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: trunk build fails, likely in python
Thank you Regina! That crept in from a previous patchset and I didn't notice (plus the buildbots havent been building lately). Fixed in r1366577, by removing the extra cruft in python/makefile.mk Pedro. --- Ven 27/7/12, Regina Henschel rb.hensc...@t-online.de ha scritto: Da: Regina Henschel rb.hensc...@t-online.de Oggetto: trunk build fails, likely in python A: Apache OpenOffice dev ooo-dev@incubator.apache.org Data: Venerdì 27 luglio 2012, 18:33 Hi, I start a build on WinXP with MSVC Express. It fails with error message dmake: Error: -- `./Python-2.7.3-vc.patch' not found, and can't be made What do I miss? Kind regards Regina
Re: Bug 119384 : Python update coming after 3.4.1 release
Hi again; My build with the more recent python has gone smoothly. FreeBSDhas been using the system Python 2.7.3 by default for a while. In addition to the general improvements there are also severalimportant enhancements, this version also helps the build onnewer MacOS X and fixes security issues. I will bringing it in either tonight or tomorrow as all our local changeshave been preserved and it won't interfere at all with the new release. Pedro. --- Mer 25/7/12, Pedro Giffuni p...@apache.org ha scritto: Da: Pedro Giffuni p...@apache.org Oggetto: Bug 119384 : Python update coming after 3.4.1 release A: ooo-dev ooo-dev@incubator.apache.org Data: Mercoledì 25 luglio 2012, 17:20 Hello guys; With some help from Hanya I have been slowly working on an update to our internal Python. The patch is rather big but it is necessary because: - The older 2.6.1 python is basically unsupported upstream. - Newer versions of python have better performance and solve security issues. - The world will be moving at some point to Python 3 and as part of the migration path the Python developers have been adding some compatibility in late 2.6.x and 2.7.x versions. The update takes python to version 2.7.3 which means nothing will break but we can start using some Python 3 features. Unfortunately, due to some brokenness in GNU patch which cannot handle some CRLF changes upstream, we will lose a change to support SSL on the internal python but it doesn't seem critical at this time. I am still running a complete build under FreeBSD and, of course, I have no interest in breaking the tree while everyone is busy rolling 3.4.1 so I will leave the update for after the release. For now I will leave the big patch in BZ i119384 JIC there are brave testers interested. regards, Pedro.
Re: [RELEAASE][3.4.1]: propose the next build for 3.4.1 based on revision 1364583
Hello guys; Just wondering .. Can I chop the Python-2.6.1 src tarball now? I left it around to make sure I don't break anything but it shouldn't be needed in trunk anymore. Pedro. --- Gio 26/7/12, Jürgen Schmidt jogischm...@googlemail.com ha scritto: not with the Hunspell update but indirectly by the integration of the new download mechanism. The file is new on the branch and included changes for these version updates that were already done on the trunk. Important for me to understand where it comes from to avoid such things in the future ... Thanks Ariel for detecting it, I would probably have stumbled over it when I would have tested the source release package which is on my plan for this week. Juergen I am currently building a new MacOS and Windows version based on revision 1365887 @Ariel: can you please build the Linux versions based on this revision Juergen
Bug 119384 : Python update coming after 3.4.1 release
Hello guys; With some help from Hanya I have been slowly working on an update to our internal Python. The patch is rather big but it is necessary because: - The older 2.6.1 python is basically unsupported upstream. - Newer versions of python have better performance and solve security issues. - The world will be moving at some point to Python 3 and as part of the migration path the Python developers have been adding some compatibility in late 2.6.x and 2.7.x versions. The update takes python to version 2.7.3 which means nothing will break but we can start using some Python 3 features. Unfortunately, due to some brokenness in GNU patch which cannot handle some CRLF changes upstream, we will lose a change to support SSL on the internal python but it doesn't seem critical at this time. I am still running a complete build under FreeBSD and, of course, I have no interest in breaking the tree while everyone is busy rolling 3.4.1 so I will leave the update for after the release. For now I will leave the big patch in BZ i119384 JIC there are brave testers interested. regards, Pedro.
Re: Bug 119384 : Python update coming after 3.4.1 release
Thank you Ariel. I will see if I can split the patches according to the LF type to solve that issue :(. Pedro. From: Ariel Constenla-Haile arie...@apache.org To: ooo-dev@incubator.apache.org Sent: Wednesday, July 25, 2012 5:48 PM Subject: Re: Bug 119384 : Python update coming after 3.4.1 release Hi Pedro, On Wed, Jul 25, 2012 at 03:20:44PM -0700, Pedro Giffuni wrote: Hello guys; With some help from Hanya I have been slowly working on an update to our internal Python. The patch is rather big but it is necessary because: - The older 2.6.1 python is basically unsupported upstream. - Newer versions of python have better performance and solve security issues. - The world will be moving at some point to Python 3 and as part of the migration path the Python developers have been adding some compatibility in late 2.6.x and 2.7.x versions. The update takes python to version 2.7.3 which means nothing will break but we can start using some Python 3 features. Unfortunately, due to some brokenness in GNU patch which cannot handle some CRLF changes upstream, we will lose a change to support SSL on the internal python but it doesn't seem critical at this time. Most SMTP servers use secure connection. A Python without SSL will likely break the mail merge functionality of many users. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: Bug 119384 : Python update coming after 3.4.1 release
I solved the issue ... building now :). Thank you Ariel. I will see if I can split the patches according to the LF type to solve that issue :(. Pedro.
Re: Question from Twitter regarding OpenIndiana
My understanding is that the unofficial Solaris-i386 port works fine in OpenIndiana. It is built with Solaris C/C++ compiler not gcc. Pedro. From: Rob Weir robw...@apache.org To: ooo-dev@incubator.apache.org Sent: Monday, July 23, 2012 2:13 PM Subject: Question from Twitter regarding OpenIndiana https://twitter.com/hcsaltiel/statuses/226573221728763904 If anyone has more info, feel free to respond directly, or send info to me and I'll respond. Thanks! -Rob
Re: Should quickstarter be enabled or disabled by default?
Hello; From what I understand.. AOO already starts much quicker than before. I vote for it being disabled by default and eventually removed. Pedro. From: Jürgen Lange j...@juergen-lange.de To: ooo-dev@incubator.apache.org Sent: Saturday, July 21, 2012 1:53 PM Subject: Re: Should quickstarter be enabled or disabled by default? I support QuickStart, too. The only issue I had was that it started in full screen mode in version 3.4. Kind regards Jürgen Am 18.07.2012 07:30, schrieb Andrea Pescetti: On 18/07/2012 Rob Weir wrote: On Tue, Jul 17, 2012 at 7:03 PM, Kay Schenk wrote: Well supposedly problems with it have been fixed, but quickstarter does seem to have its issues. ... Maybe this is worth a performance test, to see whether QuickStart really is quick, and by how much? Besides making startup quicker, it also makes access to new documents creation and file opening handier, since the tray icon can be right-clicked for several common functions. I'd support keeping it active by default. The main reason to disable QuickStart in OpenOffice 3.4 is that it starts in full-screen mode due to a bug already fixed for 3.4.1. Regards, Andrea.
Future of the BSD port (was Re: more 3.4.1 questions...supported OSes)
Just thought I'd mention this ... - Original Message - ... I am aware.. the idea would be to make it easier to detect when someone does a BSD-unfriendly change ;-). At the moment I would be glad for a buildbot that would detect any-OS-unfriendly change. At this time I am not too interested in spending time on the FreeBSD buildbot because we (FreeBSD) will be making changes that demand some attention: FreeBSD 10 will be cleaning most, if not all, of the GPL'd code in base. That includes gcc and libstdc++ which will be replaced by clang/libc++. gcc will still be available as a packageand we can use it for the builds but we would really prefer if OpenOffice builds with clang instead of gcc. Recent MacOS X has already moved to clang, of course, so an effort in this lines will help the MacOS X port too. An initial build attempt of OpenOffice breaks in stlport: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20120710033555.pointyhat-west/apache-openoffice-3.4.0_3.log.bz2 Which basically opens a can of worms as stlport seems to be required by the internal icu and silgraphite modules. STLport doesn't support clang and I haven't seen patches for it. We need the icu update and next we need to clean up the --without-stlport option, and then the real porting can start. It may also be possible that we will have problems with the exceptions code: FreeBSD will be replacing the libgcc stuff with libunwind. Pedro.
Re: Coding guideline or common rules
FWIW; - Original Message - ... Hi, I just stumbled over a commit message for the new UOF filter. I think we should agree on a common guideline for our code and how we contribute changes and bring them in the code. SCM's manage the change sets and the information who made the change, that means we don't need further comments like this ///Begin Added by wangyumin for uof2-filter from cs2c ... /// End Added by wangyumin on 2012-2-22 14:32:18 It is somewhat redundant and makes the code not really better readable. Can we agree on the common understanding that we don't need such comments and that we don't want them in the code. We should remove such comments wherever we see or find them. Indeed, I did mention in our local svn tutorial that those comments should be avoided. SVN does a wonderful job maintaining the origin information. Any opinions? As a side note, I recently found similar prominent begin/end lines in another project and the culprit on that project was the GPLv2 section 2a: You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. It's probable that old code from GPLd derivatives still carry such notes. Someone will have to clean them ;). Pedro.
Re: more 3.4.1 questions...supported OSes
Hi Rob; If something is in the release I would expect: 1) We have instructions for building it in the Building Guide 2) A user could download our source from SVN and build it according to the Building Guide Is this true of the BSD port? If so we could include it in the release, I think. If not then maybe we add a ports link to the www.openoffice.org/download page to point to off-site ports. These links could be updated as new BSD releases become available. Except for some minor patches, available here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice-3-devel/files/ the instructions for building on linux apply to FreeBSD too. The port is under control and very stable but we have deferred declaring it official until we find clean ways to fix the remaining patches. Pedro.
Re: more 3.4.1 questions...supported OSes
Hi Kay; - Original Message - ... Eventually we should use the buildbot, but I don't think we are ready for that yet. Pedro, using the buildbot is NOT a requirement for offical releases as far as I know. I am aware.. the idea would be to make it easier to detect when someone does a BSD-unfriendly change ;-). Pedro.
Re: more 3.4.1 questions...supported OSes
- Original Message - ... Except for some minor patches, available here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice-3-devel/files/ the instructions for building on linux apply to FreeBSD too. The port is under control and very stable but we have deferred declaring it official until we find clean ways to fix the remaining patches. But I think there is a distinction between an official BSD release and an official Apache release. An Apache one is one that the PMC votes on. FreeBSD only releases Operating Systems, we don't release office suites. The ports tree does bundle third party software including two AOO versions: Apache OpenOffice 3.4 Apache OpenOffice-devel-3.4.1356713 but FreeBSD releases have their own schedule that doesn't depend on specific ports. So we can sync on schedules and co-promote the port as part of our release announcement, etc. Is that what you want to do? That is easy. I doubt that is possible as our release schedule is somewhat complex: the OS is currently under code freeze but the ports tree is open. We will try to push AOO-3.4.1 into FreeBSD-9.1 Release (expected for August) But calling it an official Apache release, distributing via the mirrors, that might require more work. For example, the BSD specific patches would need to be run through the RAT scans. We'd need to figure out if they are considered 3rd party code and added to LICENSE file, etc. Not impossible, but not something we can ignore. I doubt the patches can even be considered copyrightable (they are just build fixes) but they were authored by maho@ or me and are available under the upsteam license (ALv2 in this case) or BSD 2-clause at your choice. Pedro.
Re: more 3.4.1 questions...supported OSes
- Original Message - ... OK, more from me on the upcoming release. Will ee providing an official FreeBSD and OS/2 release for 3.4.1? We had discussed this a bit in the past, but I haven't seen anything recently. We (actually Maho@) do regular builds but we have no plans to make releases through Apache infrastructure. Release notes can of course mention that FreeBSD is supported if you wish. We should also make some reference to the Solaris port for this release. best regards, Pedro.
Re: more 3.4.1 questions...supported OSes
Hi Maho; - Original Message - ... Hi, I can provide release builds to Apache community. and how I should proceed? I guess you could add links here: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds Eventually we should use the buildbot, but I don't think we are ready for that yet. Pedro.
Re: AOO-LibreOffice comparison?
Hi Peter; I am going to be honest with you. Some people like to make asses of themselves inpublic by posting comparisons of software they develop against software that they have never tried (Hi Michael!). Most of us simply don't run LibreOffice and it would not be honest to say that we can be objective making such comparisons anyways. Both packages are free and have basically the same functionality, my suggestion is to try them both and make your own comparison. cheers, Pedro. From: Peter Brawley peter.braw...@earthlink.net ... Peter, I'm not going to argue with you. Google might be of more utility here than posting such questions to a development list. ?! I'm looking for comparisons that have looked sensible to folks here. PB Good luck with your search. Regards, -Rob PB - Writing reviews of our product is something for others to do, not us. Regards, -Rob P
Re: AOO-LibreOffice comparison?
... On 2012-07-17 9:01 PM, Pedro Giffuni wrote: ... Most of us simply don't run LibreOffice That seems unfortunate, why wouldn't AOO developers want to keep up to date with their main competition? Competition among free software is somewhat of a non-concept. Technically, MS-office is also our competitor. Yes obviously that's a possibility. I was hoping for a shortcut, and for info that transcends my experience. Evidently it's not going to happen here. If it serves your purpose, the SVG drawing feature seems to be well received by our users but in general in AOO we are focusing more on making the product really stable and well behaved on all supported platforms rather than on adding new features. best regards, Pedro.
Re: [Proposal] Remove OpenOffice Consultants list
+1 - Original Message - ... We have this legacy page: http://www.openoffice.org/bizdev/consultants.html Users get to it via three main paths: 1) Google search for openoffice consultants 2) The OpenOffice.org Consultants Directory link from our main support page; http://www.openoffice.org/support/ 3) From the legacy BizDev project page: http://www.openoffice.org/bizdev/ Problem: The consultants list has not been maintained. The Spanish and German links are dead. Information on getting entries added changed points to old openoffice.org email addresses that no longer exist. IMHO, an out of date list is doing more harm than good. My Proposal: Delete the consultants lists and point visitors of the BizDev home page to the ooo-marketing list. If someone is really an OpenOffice consultant they should be easily findable by searching Google, LinkedIn, etc. This is not something that we need to maintain. -Rob
Re: Next steps for Symphony and AOO
--- Ven 13/7/12, Greg Madden ha scritto: ... I have been testing the Symphony deb packages. The 'properties' area is a nice feature, not compelling enough to re-base AOO on Symphony. AOO has progressed, new feaures that I use more than the 'properties area'. thanks for the feedback. The drop down list for 'open document' on the initial screen with all apps is missing. 'ToolsOpenoffice,orgViewUser InterfaceScaleing' is not included. AFAICT, The symphony builds were not meant to be production ready, just meant to show the basic features. I am not interested in losing features that I have incorporated in my work flow, for promises of a 'better whatever' Document fidelity has been outstanding in AOO , add Symphony feaures to AOO if appropriate, by user demand not from the top down. I agree, we all want a better product and the challenge is to preserve all the feature set with no regressions. Pedro.
Re: Next steps for Symphony and AOO
Hi Simon and everyone; --- Gio 12/7/12, Shenfeng Liu ha scritto: ... What hasn't been discussed in detail, and the key issue to me, is how much OpenOffice plus Symphony would differ from Symphony plus OpenOffice. Ideally, finally there will be little difference between OpenOffice plus Symphonyand Symphony plus OpenOffice when we totally integrated the values from both side. But I can see in 2 years or even longer time, we can not make it. So there will be quite big differences. I think we all agree two years is a lot of time. We can always start with option I and re-evaluate later on. I would propose the following: For 3.x Release (x4) we go option I merging only the things that are easy and perhaps a restricted set of CWSs. No UI or drastic changes. For 4.x we go for option II and rebase on Symphony. Part of what was done for 3.5+ will likely be useful here. Another thing that we haven't discussed at all are the patent issues. _ If you don't like speculation please stop reading here. _ The current AOO code has a patent grant from Oracle. The Symphony code adds a patent grant from IBM. It is well known that IBM has more office-relevant patents than Oracle which will likely be an important advantage for most of our users. Pedro.
Re: Next steps for Symphony and AOO
--- Gio 12/7/12, Ariel Constenla-Haile arie...@apache.org ha scritto: ... I think we all agree two years is a lot of time. We can always start with option I and re-evaluate later on. I would propose the following: For 3.x Release (x4) we go option I merging only the things that are easy and perhaps a restricted set of CWSs. No UI or drastic changes. For 4.x we go for option II and rebase on Symphony. Part of what was done for 3.5+ will likely be useful here. I still don't understand what ground you have to support rebasing on Symphony, because as you have answered me before, you didn't try the build they made, nor finished building by yourself. So, unless you started reading the C++ source code, your support is completely unjustified. My current proposal is to continue option I and re-evaluate option II next year. I have been very busy on another project, and you might have noticed that I haven't done anything on AOO lately either but by next year we will surely get the Symphony build issues fixed and we can make a more educated decision. There's no way 4.0 will make it this year so I don't think my proposal is at all disruptive. Pedro.
R: vcl field.cxx issue 150733 invalid float operation
FWIW;
--- Gio 12/7/12, Yuri Dario ha scritto:
Hi,
I finally discovered the cause of a strange crash on some pc
for the os2 port. It is due to an invalid float operation in
MetricField class. It seems that some CPU are processing
some invalid float value, which in turn generates the
exception.
Just for reference: we have an initial patch for this
issue that Yuri is testing.
cheers,
Pedro.
Surprisingly, the source code has this remark
sal_Int64 MetricField::ConvertValue( sal_Int64 nValue,
sal_Int64
mnBaseValue, sal_uInt16 nDecDigits,
FieldUnit eInUnit, FieldUnit
eOutUnit )
{
// caution: precision loss in double cast
return static_castsal_Int64(
// #150733# cast double to
sal_Int64 can throw a
//
EXCEPTION_FLT_INVALID_OPERATION on Windows
nonValueDoubleToValueDouble(
ConvertDoubleValue( (double)nValue, mnBaseValue,
nDecDigits,
eInUnit, eOutUnit ) ) );
}
but issue 150733 is not existing in current bugzilla
database. I think
it is an internal staroffice/sun/oracle issue.
Do someone know how has it been resolved?
This bug is present when users show the page settings dialog
to select
margins and page size. Since it happens when very big
numbers are used
forI found a workaround using
mnMax
= 0xLL;
as initializer in void NumericFormatter::ImplInit()
thanks,
--
Bye,
Yuri Dario
/*
* OS/2 open source software
* http://web.os2power.com/yuri
* http://www.netlabs.org
*/
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Hi Andrea; --- Mer 11/7/12, Andrea Pescetti pesce...@apache.org ha scritto: ... Speaking with (too) little knowledge of the effort involved, I would keep a 3.4.x series with periodic bugfix releases, but use the trunk directly for a 4.0 release including the UI changes from Symphony and the other improvements. I don't see reasons for an intermediate 3.5 version unless the effort to reach 4.0 requires too long (say, one year). I am not an expert, but IMHO ... There are some lower hanging fruit: the ICU update, MSXML improvements and VBA among others, that can probably be easier but the nice things like the accessibility and the new UI will take a lot more time. I can't really quantify times but adding all the Symphony features into AOO would likely take more that a year and can only be done properly by the IBM china guys (and we are really lucky to them here). Working towards version 4.0 will bring even more interest towards the project and, since the changes would be many and substantial, branding the release as 4.0 would be totally justified. I certainly think we should target having the Symphony UI in the future, and it does seem to fit better new platforms like Windows 8, but it is really difficult to know off-hand how our existing users will take it. At this time there is a huge inertia building around Option I but I don't think we should close the doors completely to option II. I would like to hear more from our long-time developers on which approach they like best, but perhaps it's not yet a good time to take a decision. Pedro.
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Ugh.. what I replied here was more pertinent to the Symphony and AOO thread, sorry. One thing that we must consider in the future for is being able to download incremental releases with binary diffs (like bsdiff). that would make it much easier to upgrade between micro releases. Pedro. --- Mer 11/7/12, Pedro Giffuni p...@apache.org ha scritto: Hi Andrea; --- Mer 11/7/12, Andrea Pescetti pesce...@apache.org ha scritto: ... Speaking with (too) little knowledge of the effort involved, I would keep a 3.4.x series with periodic bugfix releases, but use the trunk directly for a 4.0 release including the UI changes from Symphony and the other improvements. I don't see reasons for an intermediate 3.5 version unless the effort to reach 4.0 requires too long (say, one year). I am not an expert, but IMHO ... There are some lower hanging fruit: the ICU update, MSXML improvements and VBA among others, that can probably be easier but the nice things like the accessibility and the new UI will take a lot more time. I can't really quantify times but adding all the Symphony features into AOO would likely take more that a year and can only be done properly by the IBM china guys (and we are really lucky to them here). Working towards version 4.0 will bring even more interest towards the project and, since the changes would be many and substantial, branding the release as 4.0 would be totally justified. I certainly think we should target having the Symphony UI in the future, and it does seem to fit better new platforms like Windows 8, but it is really difficult to know off-hand how our existing users will take it. At this time there is a huge inertia building around Option I but I don't think we should close the doors completely to option II. I would like to hear more from our long-time developers on which approach they like best, but perhaps it's not yet a good time to take a decision. Pedro.
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Just my $0.02 --- Mar 10/7/12, Rob Weir robw...@apache.org ha scritto: But of course the open source ethos is release early; release often. So we need some way to balance that as well. I don't think that would play well for this project. It has certainly been bad for other projects already. We don't want to put out experimental releases. People pretty just much want an Office suite that does what AOO does now but is bug free. I would prefer if we focus on two levels: 3.5 Release including all the low hanging fruit: updates to ICU and Python better support for MS format, VBA. 4.0 Release - Merging Symphony and perhaps adding some new features. We can work on them sequentially (first 3.5 then 4.0) or in parallel letting some fruits from 4.0 fall into 3.5 when they are stable. No strong opinion. Pedro.
Translator roles and access (was Re: comments.apache.org)
The site is cool but on an unrelated comment ... --- Lun 9/7/12, Rob Weir robw...@apache.org ha scritto: ... This looks interesting/useful: https://comments.apache.org/ Would this make sense for our core files under /ooo-site ? Quoting the site: If you are not a committer, you will have to register an account with the system and have a project admin grant you moderator access. This happens to be the same access model we need for Pootle. (Runs and hides in a cave) Pedro.
Re: Next steps for Symphony and AOO
Hello Simon; I know rebasing from Symphony option was never very popular here. Just for the record, I ran a small experiment in the Symphony SVN: I used svn merge to bring some changes from AOO. The process was rather easy and fun. I find the Symphony team did a good job updating a lot of stuff from AOO. The effort was incomplete but it was in the right direction. If we could identify areas that are outdated I think it wouldn't be difficult to merge changes from the legacy SVN server. Some changes would require care but they are doable. I like the current work going on in trunk and I am OK with what seems to be the choice of the majority, just thought I'd share the experience :). best regards, Pedro. --- Gio 5/7/12, Shenfeng Liu liush...@gmail.com ha scritto: Da: Shenfeng Liu liush...@gmail.com Oggetto: Re: Next steps for Symphony and AOO A: ooo-dev@incubator.apache.org Data: Giovedì 5 luglio 2012, 01:28 Hi, all, It was 4 weeks since Rob raised the topic, and there were a lot of discussions. I'm so glad to see that people got more familiar with the values in the code contributed from Symphony, tried it out, and liked to see those values to be integrated into AOO future releases. I treat it as a big recognition to Symphony team. While per my reading from the discussion, we generally agreed that the favorite way of integrating the values is to continuously merging Symphony into AOO, feature by feature. This way is good for community's growth and emotion, keeping strong support to the large OpenOffice users base as well as many BPs, and avoiding the technical uncertainty of the code base switch. I also noticed that this thread is no longer as active as 2 weeks before. So I suggest we close this topic, and move on following the current direction we agreed. We already have a successfully 3.4, and 3.4.1 is coming soon. And we can notice that many people are actively working on the trunk for the next release. I think it is time for us to discuss the target and plan for the next release now. It is long way to go, but as RGB ES quoted, walking slow you'll arrive far. With more contributors, we will have bigger steps to bring Symphony value in and develop new features. Overall, my suggestion is: close this discussion thread, and kick off a new topic for the discussion of our next release. Thanks! - Simon
Re: How to Submit the UOF v2.0 Source Code
--- Gio 5/7/12, hongyun.an hongyun...@cs2c.com.cn ha scritto: Dear everyone: About a week ago,the UOF v2.0 source code was merged to the Aoo3.4(svn version1354914) on my com.And it works well. However,because of my negligence,I have lost my password.These days I am applying for resetting my password. This is unexpected, the process of taking back the password is much more complicated because I have lost my password and email address.So maybe it will take more time to reset my password. Maybe I could give the UOF v2.0 source code patch to somebody of you who has the subbmit right.I think it's a good idea to subbmit the code as soon as possibly. I am very happy to contribute our efforts to the Aoo.I hope the compatibility between UOF v2.0 and ODF is getting better and better. I understand that you want to commit it soon. It's your hard work and you are part of our team now so I personally would like to see it committed by you. This has to be solved so let's be patient for a little while more. Pedro.
Re: Java
Hello; --- Mer 4/7/12, suhail ansari suhaila...@gmail.com ha scritto: ... OpenOffice should be rewritten in JavaFX. OpenOffice is simply too big to propose rewriting it all to a different language. Plus, some modern platforms don't want Java at all :(. Pedro.
Re: Next steps for Symphony and AOO
--- Gio 5/7/12, Ariel Constenla-Haile arie...@apache.org ha scritto: ... Hi Pedro, On Thu, Jul 5, 2012 at 12:30 PM, Pedro Giffuni p...@apache.org wrote: I know rebasing from Symphony option was never very popular here. Just for the record, I ran a small experiment in the Symphony SVN: I used svn merge to bring some changes from AOO. The process was rather easy and fun. I find the Symphony team did a good job updating a lot of stuff from AOO. The effort was incomplete but it was in the right direction. If we could identify areas that are outdated I think it wouldn't be difficult to merge changes from the legacy SVN server. Some changes would require care but they are doable. I like the current work going on in trunk and I am OK with what seems to be the choice of the majority, just thought I'd share the experience :). could you build it? or at least try one of the binaries they uploaded? I haven't tried the binaries because they didn't include FreeBSD :). I have been short of time lately but it looks like the FreeBSD patches are in sync with AOO. The FreeBSD port (or at least building it) is certainly in my TODO list, no matter what. Pedro.
Re: Java
Hi; --- Gio 5/7/12, Fernando Cassia fcas...@gmail.com ha scritto: On Thu, Jul 5, 2012 at 1:09 PM, Pedro Giffuni p...@apache.org wrote: Plus, some modern platforms don't want Java at all :(. Ther's an OpenJDK port for the Nokia N9. That's modern in my book. I guess that by modern you mean locked platforms. That's not progress nor modern, in my book. I like my bikesheds apple red (like in red apples, not green or yellow, which are nice and delicious but not red). cheers, Pedro. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/bikeshed.html
Re: CWS swbookmarkfixes01 rebasing and licensing
--- Mar 3/7/12, Simon Phipps si...@webmink.com ha scritto: ... Please can we have an update on that effort to get all the CWS made available then? It seems a perfectly reasonable request, one I and others have been making here since the inception of the project and one I am not able to go negotiate personally so need to keep asking about here. What effort? I think we have been pretty consistent here every time the subject is brought up by someone external to the project. I am not a lawyer and neither is Rob or most of the people doing development here and even if we were lawyers we have no power to relicense code that isn't ours. In general we don't release patches or CWSs other than what you see in our releases (at this time 3.4 only). Pedro.
Re: CWS swbookmarkfixes01 rebasing and licensing
--- Mar 3/7/12, Simon Phipps si...@webmink.com ha scritto: ... On 3 Jul 2012, at 15:29, Pedro Giffuni wrote: --- Mar 3/7/12, Simon Phipps si...@webmink.com ha scritto: ... Please can we have an update on that effort to get all the CWS made available then? It seems a perfectly reasonable request, one I and others have been making here since the inception of the project and one I am not able to go negotiate personally so need to keep asking about here. What effort? Mentioned in an e-mail linked from the OP, dated June 7, 2011 - those of us inside the project have been raising this topic from very early on, as you can see. Making it easy for outside developers to meet their needs is a great way to have them begin to join in and become insiders like you. The message is at http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3c4dee6c86.5070...@oracle.com%3E S. OK. I think that in that mail message we stands for Oracle, not for Apache, so you'd have to ask Andrew Rist with his Oracle hat. We do have a nice relationship with Oracle and they have always been very receptive with our requests so I certainly recommend other communities to solve your issues and approach them constructively. FWIW, other ex-oracle employees have gotten CWSs successfully included in our 3.4 release. AFAICT, all of them signed iCLAs and were actively involved in the community getting their patches cleaned up and working. Pedro.
Re: CWS swbookmarkfixes01 rebasing and licensing
--- Mar 3/7/12, Bjoern Michaelsen ha scritto: Hi Ross, Thanks for the constructive reply! On Tue, Jul 03, 2012 at 03:58:54PM +0100, Ross Gardler wrote: If the CWS was included in the original SGA then it is available under the AL2. How can I check that? It was not integrated in m106 at OOo, if that is the criteria, but I assume there is more to that ;) I don't think we committed it. You can review the SVN history in fisheye, but it's probably easier to look at the code and recognize it. If it was not included in that original SGA, you want to bring it here and the OpenOffice project want to see the work committed then Oracle will, in all likelihood, make it available to us. Great! Therefore, I suggest the following order of execution: - determine whether the OpenOffice committers want the work Where would that be done? Here. You may want to send us a description. If you prefer you can handle it through a bugzilla issue. - confirm that Oracle have already or will make the code available under the AL2 at our request Are there established workflows for that, or should I just go about that ad-hoc? ad-hoc. They are very cooperative. - submit patches against AOO trunk Are the patches already released AL2 by Apache when they are published on the list then? Unfortunately it's not that easy. The code is strictly under ALv2 only when the code has been released by the ASF. We are under incubation still so being strict that means that you can only count with code officially reviewed by the ASF IPMC and released. Given that AOO might switch to the Symphony codebase and fail to even release a version with the patches against the original OOo, I would need that assureance that the effort to rebase the work is not in vain. I think the effort to rebase is actually pretty small as we have avoided wild changes (precisely to ease code merging). If we do rebase on Symphony (which is only an option and not the most popular ATM), merging changes from AOO is still relatively easy (I tried this myself already). I am going to be pretty honest with you (as with everyone). We welcome new contributions, especially from people that have experience with the codebase, but if the idea is simply getting your code relicensed on the short term and leave us with the problem of maintaining it or even worse, fixing it, this is not going to work. best regards, Pedro.
Re: RE: Open the UOF2.0 source codes
--- Gio 28/6/12, hongyun.an hongyun...@cs2c.com.cn ha scritto: ... Dear everyone: Thanks to all your help,so far I have finished merging the UOF v2.0 source code to the Aoo3.4(svn version1354914) both on the Windows and Linux. The source code is 33 files and about 2M，mainly in filter/source/config,filter/source/xmlfilterdetect, filter/source/xsltfilter，scp2/source/ooo. Now it can work very well in sw,sc,sd. It could load as the uof v2.0 format files(uot,uos,uop),also could open them. Nice! thank you,Dennis. But I have forgotten my password. I go to the http://id.apache.org and enter my ID number,then click the Forgot your password. In the new window I enter my ID in the frame which is like this Apache User ID:___...@apache.org, With that I get the message Email sent,Message-ID=20120628100728.462c...@id.apache.org. I don't know whether I have the apache.org email and I could not log in this email. Could you tell me how to reset my password? I don't know about that, but your email address should be an alias to the email you added in your iCLA. Another question: could I commit the source code to the Aoo3.4 trunk? Yes but, if you can, try to schedule it for the weekend since there's less traffic those days. Thanks again for your hard work! Pedro.
Re: Re: Open the UOF2.0 source codes
Hi Hongyun; --- Gio 28/6/12, hongyun.an hongyun...@cs2c.com.cn ha scritto: ... By the way,here is the file list: filter/prj/d.lst; filter/source/config/fragments/fcfg_calc.mk; filter/source/config/fragments/fcfg_impress.mk; filter/source/config/fragments/fcfg_writer.mk; filter/source/config/fragments/filters/NSO_Calc_UOF2.xcu; filter/source/config/fragments/filters/NSO_Calc_UOF2_ui.xcu; filter/source/config/fragments/filters/NSO_Impress_UOF2.xcu; filter/source/config/fragments/filters/NSO_Impress_UOF2_ui.xcu; filter/source/config/fragments/filters/NSO_Writer_UOF2.xcu; filter/source/config/fragments/filters/NSO_Writer_UOF2_ui.xcu; filter/source/config/fragments/types/calc_NSO_UOF2.xcu; filter/source/config/fragments/types/impress_NSO_UOF2.xcu; filter/source/config/fragments/types/writer_NSO_UOF2.xcu; filter/source/xmlfilterdetect/filterdetect.cxx; filter/source/xmlfilterdetect/makefile.mk; filter/source/xslt/export/uof2/odf2uof.xsl; filter/source/xslt/import/uof2/uof2odf.xsl; filter/source/xsltfilter/containerhelper.hxx; filter/source/xsltfilter/makefile.mk; filter/source/xsltfilter/uof2merge.cxx; filter/source/xsltfilter/uof2merge.hxx; filter/source/xsltfilter/uof2splithandler.cxx; filter/source/xsltfilter/uof2splithandler.hxx; filter/source/xsltfilter/uof2splitter.cxx; filter/source/xsltfilter/uof2splitter.hxx; filter/source/xsltfilter/uof2storage.cxx; filter/source/xsltfilter/uof2storage.hxx; filter/source/xsltfilter/XMLBase64Codec.cxx; filter/source/xsltfilter/XMLBase64Codec.hxx; filter/source/xsltfilter/XSLTFilter.cxx; scp2/source/ooo/directory_ooo.scp; scp2/source/ooo/file_ooo.scp; scp2/source/ooo/module_hidden_ooo.scp Only the files uof2odf.xsl,odf2uof.xsl have the Chinese charactors,which specify UTF-8 encoding. It's actually not very big: you have to be careful about the SVN properties before committing. Make sure that the new files set svn:mime-type to text/plain, otherwise UTF-8 may be confused with binary. More information here: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.html I also recommend running svn update just before committing. cheers, Pedro.
Re: Next steps for Symphony and AOO
--- Mer 27/6/12, Rob Weir robw...@apache.org ha scritto: ... Top posting as a comment on the entire post, and what it is and what it isn't. In a recent article [1], later quoted in in LinuxToday [2], a LibreOffice board member was interviewed and made some erroneous statements regarding Apache OpenOffice and Symphony: [W]e are looking forward the interesting switch at Apache OpenOffice from the Openoffice.org codebase to the Symphony codebase; there will certainly be some code we might be able to reuse. Although, when you come to think of it, it’s funny to enter the Apache Incubation Process with one software you’re inheriting, and to use a different software you’ve also inherited just after the incubation process is completed Charles states pretty much the same on the LibreOffice marketing list [3]: AOO 4.0 will have the Symphony interface, and what this means is that it will bring a whole new different set of bugs. This is asserted as a decision. It is not. It is merely one option of several that this project has been considering in this thread. In fact, what IBM employees have been doing most recently, as anyone following this list knows, is merging bug fixes from Symphony into the trunk and the 3.4.1 branch. So we're obviously not currently going down the 2nd option decribed in this thread. For the record, I am probably the only supporter of the so-called option II and I am certainly not an IBM employee. If we do take option II, which I honestly see unlikely, the idea would be to reintegrate all the OpenOffice base on top of Symphony and it would be done simply for practical purposes: we know the OpenOffice code and the related changes better than Symphony and we still have the traditional version control systems in place to do an orderly re-merge. We would (and notice it's an hypothetical situation at this time) just be rebasing, something that LibreOffice should be used to already. It's really disappointing to see uninformed people give opinions about things they evidently don't understand. Pedro.
Re: Next steps for Symphony and AOO
Hi Kevin; --- Mer 27/6/12, Kevin Grignon kevingrignon...@gmail.com ha scritto: Hello All, Sorry for top post. Where are we at? Have we summarized the discussion? Have all expressed their views? How might we crystallized our position and move forward? There is indeed a big problem. I think we all agree there is a lot of nice code to integrate, but beyond the method we use to merge the codebases, there is still the much deeper issue: should we abandon the OOo UI to use a Symphony UI + enhancements? I don't have an answer. Pedro.
Re: Support of system libraries for apr,apr-util,serf,coinmp
Thank you Andre! This is a huge help for packagers. cheers, Pedro. ps. It almost makes me feel bad about Italy beating Germany yet again next Thursday (just kidding ... we'll see ;) ) --- Mar 26/6/12, Andre Fischer a...@a-w-f.de ha scritto: Hi all, I just checked in my changes for issue 118906 [1] that adds support for system libraries for apr, apr-util, serf, and coinmp. These modules can be found in ext_libraries/. By default we still build our own versions of these libraries, so unless you pass any of the switches --with-system-apr --with-system-apr-util --with-system-serf --with-system-coinmp to configure, you should not be able to spot any differences. I have been able to verify the use of the system libraries only on Linux, because on the other platforms I could not successfully install the libraries. There may be minor problems with the OS/2 port. I don't have that platform available for testing but am, of course, willing to help fix any regression. Best regards, Andre [1] https://issues.apache.org/ooo/show_bug.cgi?id=118906
Re: I may don't have much time spend on AOO
Will surely miss you Lily!! Best of lucks in your new role, I am sure you will do fine! Pedro. --- Mar 26/6/12, Xia Zhao lilyzh...@gmail.com ha scritto: Dear all, Due to my job role change, I have to spend much time on new position to face many challenges, so I may haven't much time on AOO. But I will surely keep one eye on this project and continuous contribute my effort on it. For weekly QA report, I propose Yan Ji take this work if he like. As I know, Ji has done many work on BugZilla issues reporting and actively to push test case management tool, 3.4.1 test plan etc. Also he did much work on testing build building. Ji, thanks a lot! -- Best Regards, Lily If you are not part of solution,you are part of problem
Re: [RELEASE][3.4.1]: proposing Bug 118057 [filter] word 2003 XML (wordml) filters broken as release blocker
--- Lun 25/6/12, Jürgen Schmidt jogischm...@googlemail.com ha scritto: ... Most fixes are probably fixed on trunk first and merged after some discussion on the branch. But do we need a fix direction here? I think no because it really depends on the issue. Keep in mind that we have some general tasks to do for each release that are not necessary on trunk. We should use svn merge to integrate a fix from one code base into another one. I am not a svn:mergeinfo expert but I recommend doing svn merge in one direction only. In trunk we want to keep record of the merges from the development branches (Armin has already done it) and in the stable branch (AOO34) we want to track only things from trunk. If we start merging from everywhere we will get a rather messy spaghetti structure but, worse than that, the mergeinfo in trunk will be unnecessarily big and will be inherited into all the branches. Just my $0.002, Pedro.
Re: [RELEASE][3.4.1]: proposing Bug 118057 [filter] word 2003 XML (wordml) filters broken as release blocker
Answering to myself, --- Lun 25/6/12, Pedro Giffuni p...@apache.org ha scritto: ... --- Lun 25/6/12, Jürgen Schmidt jogischm...@googlemail.com ha scritto: ... We should use svn merge to integrate a fix from one code base into another one. I am not a svn:mergeinfo expert but I recommend doing svn merge in one direction only. In trunk we want to keep record of the merges from the development branches (Armin has already done it) and in the stable branch (AOO34) we want to track only things from trunk. If we start merging from everywhere we will get a rather messy spaghetti structure but, worse than that, the mergeinfo in trunk will be unnecessarily big and will be inherited into all the branches. Actually ... This is not a big issue. Tracking merges from different branches is much better than not tracking at all. Pedro. Just my $0.002, Pedro.
Re: [RELEASE][3.4.1]: proposing Bug 118057 [filter] word 2003 XML (wordml) filters broken as release blocker
Ugh ... --- Dom 24/6/12, De Bin Lei debin@gmail.com ha scritto: Da: De Bin Lei debin@gmail.com Oggetto: Re: [RELEASE][3.4.1]: proposing Bug 118057 [filter] word 2003 XML (wordml) filters broken as release blocker A: ooo-dev@incubator.apache.org Data: Domenica 24 giugno 2012, 20:14 2012/6/20 Jürgen Schmidt jogischm...@googlemail.com On 6/20/12 10:14 AM, debin lei wrote: 2012/6/20 Jürgen Schmidt jogischm...@googlemail.com On 6/20/12 8:21 AM, debin lei wrote: +1 from my view. I have checked the fix. It has a very high benefit to risk ratio it could be good for AOO 3.4.1. fix available and reviewed, so it looks fine for me to include it for 3.4.1. Debin, Will you take care of the fix for 3.4.1 on the AOO34 branch ones you have the commit rights ;-) Ok, I will take care of the fix for 3.4.1, when I have the right. perfect, please add the revision of the branch in the issue when you have fixed it. It helps to track it. DONE. The code have checked in 3.4.1 and revision is 1353370. I see the issue appears RESOLVED - FIXED. Was the issue fixed in trunk? In general all fixes should go to trunk first. cheers, Pedro.
Re: [RELEASE][3.4.1]: proposing Bug 118057 [filter] word 2003 XML (wordml) filters broken as release blocker
--- Dom 24/6/12, Lin Yuan yuanlin@gmail.com ha scritto: Da: Lin Yuan yuanlin@gmail.com Oggetto: Re: [RELEASE][3.4.1]: proposing Bug 118057 [filter] word 2003 XML (wordml) filters broken as release blocker A: ooo-dev@incubator.apache.org, p...@apache.org Data: Domenica 24 giugno 2012, 22:18 2012/6/25 Pedro Giffuni p...@apache.org Ugh ... --- Dom 24/6/12, De Bin Lei debin@gmail.com ha scritto: Da: De Bin Lei debin@gmail.com Oggetto: Re: [RELEASE][3.4.1]: proposing Bug 118057 [filter] word 2003 XML (wordml) filters broken as release blocker A: ooo-dev@incubator.apache.org Data: Domenica 24 giugno 2012, 20:14 2012/6/20 Jürgen Schmidt jogischm...@googlemail.com On 6/20/12 10:14 AM, debin lei wrote: 2012/6/20 Jürgen Schmidt jogischm...@googlemail.com On 6/20/12 8:21 AM, debin lei wrote: +1 from my view. I have checked the fix. It has a very high benefit to risk ratio it could be good for AOO 3.4.1. fix available and reviewed, so it looks fine for me to include it for 3.4.1. Debin, Will you take care of the fix for 3.4.1 on the AOO34 branch ones you have the commit rights ;-) Ok, I will take care of the fix for 3.4.1, when I have the right. perfect, please add the revision of the branch in the issue when you have fixed it. It helps to track it. DONE. The code have checked in 3.4.1 and revision is 1353370. I see the issue appears RESOLVED - FIXED. Was the issue fixed in trunk? In general all fixes should go to trunk first. So the code changes in 3.4.1 branch will not be merged to main trunk automaticly after 3.4.1 released? Not automatically: someone has to do it and if the bug is labelled RESOLVED - FIXED it's likely that someone will forget to do it. That's one of the reasons it's preferable to commit the patches to trunk first. Another reason is that using svn merge will keep track of the revisions that have been merged. Cheers, Pedro.
Re: Commit message summaries
Hi; --- Gio 21/6/12, Armin Le Grand armin.le.gr...@me.com ha scritto: ... For me in the order of preference I would use: - #number# (we have only one tracker, no need for flags like 'i') - #inumber# I would not like plain number + :, it is just too hard to recognize (also to grep for). I personally find the #bznumber# notation ugly. I prefer: ibznumber - Short description. but I also use _ Short Description Long description Issue: number Author: name Reviewed by: name2 Discussed with: name3 _ I actually prefer the last one because the issue number takes space from the header and we shouldn't need to check bugzilla to make a good idea of the change. Of course it's just me and I will adhere to the notation decided by the project. Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
--- Lun 18/6/12, Rob Weir robw...@apache.org ha scritto: On Sun, Jun 3, 2012 at 8:40 PM, Pedro Giffuni wrote: ... I certainly think this makes sense. Discriminating the Category-B tarballs in the mirrors is easier and does not give the impression that it is ASF code or that we are maintaining it. Plus mirrors are absolutely more adequate for distributing tarballs than a SVN repository. Hi Pedro, Andrew made some changes to the way ext-sources are downloaded. Does that address the concerns you raised on the graduation thread? Could you confirm? Andre did a nice job but the category B tarballs are still in SVN so I dont consider the issue has been solved. Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
--- Lun 18/6/12, Rob Weir robw...@apache.org ha scritto: Andre did a nice job but the category B tarballs are still in SVN so I dont consider the issue has been solved. Do you have any proposal for how that could addressed without breaking the released AOO 3.4.0 source distribution? Hasn't changed. Axe and add a note to the src distribution to let people know where to find the (already optional) tarballs. Pedro.
Re: Next steps for Symphony and AOO
--- Gio 14/6/12, Marcus (OOo) marcus.m...@wtnet.de ha scritto: ... And I think it's not just about emotions. If you take A as base and pick the enhancements of B you'll get an enhanced A. You won't probably remove features from A but take only some of B. So the decision between Method I and II is also the decision to work for an enhanced OOo/AOO or for an enhanced Symphony. I might have missed something but the idea behind both options is to arrive to the same product, that means reusing as much available code as possible. Also a clear +1 from me to go the way of option I. It would be interesting to could put the options in some time metric. My guess (and it's only a guess, not an estimate) ... Option I : 2 years. Option II: 8 months. Personally, I think I will work on both options at the same time: I do want to have an early Symphony BSD port. No objections if I start merging patches into Symphony once uploaded? :). Pedro.
R: Introduction of myself
Welcome!! --- Gio 14/6/12, Fan Zheng zheng.easy...@gmail.com ha scritto: Hi, Everybody: This is Zheng Fan speaking. Well, I am a brand new face in AOO community, with subscribing the ooo-dev mailing list just 2 weeks ago. I start working in IBM Symhony project in 2003 and being focus in Word Processor corresponding area since 2006, Before that, I was worked in the Presentation team for about 3 years. Now, my mainly responsibility is on the issues and features in the core function of Word Processor, including data model, formatting and user behavior management. Also, I have a little bit experience on the MS Word 2003 binary format interoperability and Mac OS native printing field. Hope that my contribution could make AOO being more strong and fancy, and help you people on issues and requirements. I would be very happen on communicating with all of you, on the issues, suggestions, what ever. That is all. Thanks a lot! yours Zheng Fan 2012-06-15
Re: Next steps for Symphony and AOO
--- Mer 13/6/12, Fernando Cassia fcas...@gmail.com ha scritto: Pedro Giffuni p...@apache.org wrote: Can we really not have the java components from Symphony? Why? Java is an asset rather than a problem. Oh, you misunderstood .. I *want* them. I even updated most of our Java stuff in the hope that we disprove that myth about Java being slow. Pedro. FC
Re: Next steps for Symphony and AOO
On 06/11/12 20:08, Rob Weir wrote: As we wait [0] for the Symphony [1] code to be loaded into Subversion I think it would be good to start a discussion on next steps of how we can make best use of this contribution. Hopefully you've had time to review the list of features on the wiki [2], install one of the binaries [3] , or maybe even download the source [4] and try to build it [5]. As will see by your examination, the Symphony code base has co-evolved with OpenOffice.org for several years now, and continued to co-evolve with Apache OpenOffice even recently. Symphony has many features and bug fixes that AOO lacks. And there are areas where Symphony is missing enhancements or bug fixes that are in OpenOffice. Our challenge is to find the best way to bring these two code bases together, to make the best product. I think there are two main approaches to this problem: I. Merge code, from Symphony, feature by feature, into AOO, in a prioritized order. This is the slow approach, since it would take (by the estimates I've seen) a couple of years to bring all of the Symphony enhancements and bug fixes over to AOO. II. Use Symphony as the the new base, and merge (over time) AOO (and OOo) enhancements and bug fixes into the new trunk. This approach quickly gives a new UI, something we could fairly call Apache OpenOffice 4.0. But this approach would also give us some short-term pain. For example, those involved in porting AOO 3.4 would need to merge their patches into the new trunk. We'd need to update license headers again. Help files and translation are done differently in Symphony, and so on. Looked at another way, option I is a slow, but easy path. Option II is a leap forward, but will be initially more work and disruption. Evolution versus Revolution. So let's discuss. Please ask questions about the pro's and con's of each approach. The code and binaries are all posted, and my IBM colleagues in Beijing are happy to answer your questions. Wow ... First of all let me ask one question: Can we really not have the java components from Symphony? We do have Java stuff already and even if it may not seem so, Eclipse is not really a problem since we can ship Category B binaries. Concerning the dilemma: - Option (I) can basically only be done well by the Symphony guys because they know the changes well enough and only they have access to the history. It will likely take them a lot of time and we may lose some features in the process and we will never know. -On option (II) we can all help as we all have access to the Hg repositories and we can use svn merge for the changes AOO has done. There is the unfortunate risk that we might have issues merging some of the pre-Apache changes. This may also lead to inconsistencies between 3.4 and 4.0. For me option II is more mechanical and although it may seem more work (redo the BSD port!) it is less effort and more predictable. I would go with that one: merging AOO into Symphony. Pedro.
Re: Next steps for Symphony and AOO
On 06/11/12 22:24, Dennis E. Hamilton wrote: Predictably, I prefer approach I on first principles: Never derail the train that's running. From that perspective, there's all of this: - All of the developers and many testers and others know how to build AOO 3.4.0 including people who are working from the source tarball and the folks working on LibreOffice and other co-dependents as well - the current community includes those who build special distros (of OOo and LO), provide QA that serves all of us, etc. I don't think the build procedure would change much at all, but a change would be good. I don't think anyone is proud of the current build system- - There is still IP clearance to be done on the Symphony contribution bits and that can be worked through selectively as staging of features/fixes before merging to the SVN trunk. That is rather minimal from what I have seen (ucpp). - Alignment of the symphony code can be done off-trunk with merging of selected features and fixes on an iterative basis accompanied by testing of various kinds and localized attention to build breakers and other potential regressions. That is likely to be very difficult, and is the reason why alternative II is being proposed. Symphony already works and builds on it's own. - There is an abundance of bug reports and analysis based on the current lineage. - All of the documentation, forum contributions, MediaWiki and user lists are currently oriented around the OOo-lineage and they need to be morphed in a progressive way, not a sudden switch. I am afraid this is something that just has to be done either way. Some bugs are simply old and a lot of the documentation is obsolete or under uncertain copyrights- - Users and others may like new features but for many sudden switches are unsettling - Plan II could end up with us having to maintain OOo-lineage releases and Symphony-merged releases concurrently. That is a frightening prospect. It is like forking ourselves and maintaining both forks. - Then there's the localizations, etc. that would crash against the forked support, etc. We would focus completely on the 4.x release after 3.4.1 is released so I would expect we would EOL 3.4.x soon. We would indeed be forking the code though; not sure what would happen with base. The real question here is what works better for the people doing the work. For me it's easier to take patches from OOo/AOO and merge them than to try to extract features from Symphony, but it would be interesting to hear what the ex-Oracle guys have to say. Pedro. Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Monday, June 11, 2012 18:08 To: ooo-dev@incubator.apache.org Subject: Next steps for Symphony and AOO As we wait [0] for the Symphony [1] code to be loaded into Subversion I think it would be good to start a discussion on next steps of how we can make best use of this contribution. Hopefully you've had time to review the list of features on the wiki [2], install one of the binaries [3] , or maybe even download the source [4] and try to build it [5]. As will see by your examination, the Symphony code base has co-evolved with OpenOffice.org for several years now, and continued to co-evolve with Apache OpenOffice even recently. Symphony has many features and bug fixes that AOO lacks. And there are areas where Symphony is missing enhancements or bug fixes that are in OpenOffice. Our challenge is to find the best way to bring these two code bases together, to make the best product. I think there are two main approaches to this problem: I. Merge code, from Symphony, feature by feature, into AOO, in a prioritized order. This is the slow approach, since it would take (by the estimates I've seen) a couple of years to bring all of the Symphony enhancements and bug fixes over to AOO. II. Use Symphony as the the new base, and merge (over time) AOO (and OOo) enhancements and bug fixes into the new trunk. This approach quickly gives a new UI, something we could fairly call Apache OpenOffice 4.0. But this approach would also give us some short-term pain. For example, those involved in porting AOO 3.4 would need to merge their patches into the new trunk. We'd need to update license headers again. Help files and translation are done differently in Symphony, and so on. Looked at another way, option I is a slow, but easy path. Option II is a leap forward, but will be initially more work and disruption. Evolution versus Revolution. So let's discuss. Please ask questions about the pro's and con's of each approach. The code and binaries are all posted, and my IBM colleagues in Beijing are happy to answer your questions. Regards, -Rob [0] https://issues.apache.org/jira/browse/INFRA-4799 [1] http://wiki.services.openoffice.org/wiki/Symphony [2] http://wiki.services.openoffice.org/wiki/Symphony_contribution [3]
Re: Open the UOF2.0 source codes
This is excellent news! Thank you Hongyun An, we are delighted to have this huge development for/from the Chinese community! Pedro. --- Dom 10/6/12, hongyun.an hongyun...@cs2c.com.cn ha scritto: Hi,everyone: My name is Hongyun An and I am serving in CS2C.Since 2008,I have worked for the document format interoperability. Now I am serving for the China Standard Software Co.,Ltd(CS2C). We are going to open the UOF2.0 source codes which are researched for years based on OpenOffice. Until now We have send the SGA and the SGA from China Standard Software Co, Ltd has been filed in the Apache Software Foundation records. Now let me tell you what UOF2.0 is and how important it is. As a Chinese document format,UOF(Unified Office document Format) describes the document format structure basing on the W3C XML Schema,using Chinese character tags.Now UOF has a wide range of applications.In China,many departments use the UOF as the compatibility format. UOF2.0 is improved more greatly than UOF1.1. It has a better structure, which is multi-file structure,including uof.xml, meta.xml,context.xml,chart.xml,graphics.xml,rules.xml and so on. And UOF2.0 unifies the definition of the public properties, supports the multi-language. Until now we have achieved reading and writing the UOF2.0 documents by modifying the OpenOffice source codes and the style sheets. Hongyun An Office +8610-51659955-3102 CS2C 20F,Yingu Building,No.9 Beisihuan Xilu,Haidian District Beijing China
Re: Re: Open the UOF2.0 source codes
--- Lun 11/6/12, hongyun.an hongyun...@cs2c.com.cn ha scritto: ... Data: Lunedì 11 giugno 2012, 00:20 You are welcome.We hope it will be more compatible between the ODF and UOF2.0. Could anybody tell me how submit the code? -- I guess it depends on the size. One option would be to put up a tarball somewhere, but perhaps its better to create a branch in SVN. It would be great if one of our Chinese commiters takes the lead on this. Pedro. hongyun.an This is excellent news! Thank you Hongyun An, we are delighted to have this huge development for/from the Chinese community! Pedro. --- Dom 10/6/12, hongyun.an hongyun...@cs2c.com.cn ha scritto: Hi,everyone: My name is Hongyun An and I am serving in CS2C.Since 2008,I have worked for the document format interoperability. Now I am serving for the China Standard Software Co.,Ltd(CS2C). We are going to open the UOF2.0 source codes which are researched for years based on OpenOffice. Until now We have send the SGA and the SGA from China Standard Software Co, Ltd has been filed in the Apache Software Foundation records. Now let me tell you what UOF2.0 is and how important it is. As a Chinese document format,UOF(Unified Office document Format) describes the document format structure basing on the W3C XML Schema,using Chinese character tags.Now UOF has a wide range of applications.In China,many departments use the UOF as the compatibility format. UOF2.0 is improved more greatly than UOF1.1. It has a better structure, which is multi-file structure,including uof.xml, meta.xml,context.xml,chart.xml,graphics.xml,rules.xml and so on. And UOF2.0 unifies the definition of the public properties, supports the multi-language. Until now we have achieved reading and writing the UOF2.0 documents by modifying the OpenOffice source codes and the style sheets. Hongyun An Office +8610-51659955-3102 CS2C 20F,Yingu Building,No.9 Beisihuan Xilu,Haidian District Beijing China
Re: Request for Apache License for CWSs
FWIW, --- Ven 8/6/12, Ariel Constenla-Haile ha scritto: ... If Marina was in the internship program, then she was not an Oracle employee, and the joint copyright assignment she signed does not take her rights over the code. AINAL, but I guess the situation is different with code written by former Oracle employees working for OOo. If the internship was paid (which is usual in internships involved in doing anything copyrightable) the code is owned by the employer. If the internship was not paid then the company can argue she used company resources (tutors, etc) that were not available under other conditions. Interns are not different to regular employees in such cases. But IANAL, Pedro.
Re: Request for Apache License for CWSs
Hello Eike; --- Ven 8/6/12, Eike Rathke ha scritto: Hi, On Wednesday, 2012-05-23 13:54:31 +0200, Regina Henschel wrote: For AOO itself the CWS calcishmakkica is important. I'd like to bring this up on the radar again. The CWS contains important work implementing spreadsheet formulas defined by ODF OpenFormula, done by Marina during an OOo internship, myself as mentor and Daniel for the Excel import/export. It would be unnecessary to redo all the work, which is quite some amount, if we could get the changes of this CWS under ALv2 soon. So how to proceed? Well, as you know, the only proved way to get code from a CWS relicensed is to commit it to the tree and wait for the ASF to make a release with it. Other alternatives have to be arranged directly with the copyright owner. Breaking the build or bringing stuff that doesn't work is not acceptable so I would suggest you make available the patch and give a couple of days before committing it just to make sure there are no objections. Of course you are a committer, so you can create a branch if you want to do some special work on it before getting it integrated. best regards, Pedro.
Re: Request for Apache License for CWSs
Hi Ariel; --- Ven 8/6/12, Ariel Constenla-Haile arie...@apache.org ha scritto: ... You are missing the context: - the Internship was http://wiki.services.openoffice.org/wiki/OpenOffice.org_Internship - it was payed by Team OpenOffice.org on behalf of the Community Council with community resources - the contributor signed the SCA http://wiki.services.openoffice.org/wiki/OpenOffice.org_Internship#Terms_.26_Conditions This means the Intern owns the copyright on the code she/he wrote. The issue in this case is that Daniel and Eike both contributed code being Oracle employees. Ah, OK ... I think the owner was the organization that paid, but one of the conditions for the internship was clearly to sign the JCA so only Oracle has control of the copyright without any reasonable doubt. Just for reference.. I once needed a header from a GSoC project that was written for Haiku (under MIT license). I needed that header under BSD 2 Clause license so I contacted the author. The author was paid by Google to do the project so instead of relicensing directly he had me contact the Haiku guys to get the header relicensed. After a long delay to get any answer, finally Haiku said it was OK to relicense the header under a BSD license but it took so long that I didn't really use the header at all. Hopefully we will get to use it for another GSoC this year :-P. Pedro.
Re: Windows 8 Compatibility?
--- Gio 7/6/12, Tor Lillqvist t...@iki.fi ha scritto: ... Data: Giovedì 7 giugno 2012, 00:57 http://www.libreofficeaustralia.org/lt/community/blog/planet/20110328/porting-libreoffice-x64-windows No idea why that blog post of mine shows up on that site, and in a Lithuanian (lt) subdirectory there even. (I have no connections to Australia or the Lithuanian language.) Anyway, the real location is http://tml-blog.blogspot.com/2011/03/porting-libreoffice-to-x64-windows.html . Thanks! Its really nice to see this type of explanations somewhere, and also learn about a new blog to follow ocasionally :). Pedro. --tml
Re: svn commit: r1347062 - /incubator/ooo/trunk/main/instsetoo_native/util/makefile.mk
Hi Andre; --- Gio 7/6/12, Andre Fischer a...@a-w-f.de ha scritto: Hi Pedro, I just saw that you have removed the -u flag from some copy commands in instsetoo_native/util/makefile.mk Can you explain why? Is there a Windows-only problem with the copy command? Maybe this has to be done elsewhere too? I saw a while back here on -dev a report about timestamping issue with Windows (I didn't keep the exact message but I recall it was from someone in China). It seemed that the issue happens when sharing files, like in NFS or samba. AFAICT this is the only place where we depend on gnu cp's -u extension. In general building AOO in a shared disks is a bad idea, so if this has some performance/disk space impact it can be reverted. Pedro. Pedro. Regards, Andre
Re: Correct SVN practices (was Re: Fix for bug 119161)
Hi; I think I like current primer better. http://incubator.apache.org/openofficeorg/svn-basics.html Pedro. --- Mer 6/6/12, Yong Lin Ma mayo...@apache.org ha scritto: Da: Yong Lin Ma mayo...@apache.org Oggetto: Re: Correct SVN practices (was Re: Fix for bug 119161) A: ooo-dev@incubator.apache.org Data: Mercoledì 6 giugno 2012, 07:56 http://wiki.services.openoffice.org/wiki/Svn_practices I would stop for awhile. Please help to update it, especially the branche section. Not all the things are accurate. On Wed, Jun 6, 2012 at 11:06 AM, bjcheny compan...@gmail.com wrote: Hi Eric, I'd like to offer some tips on svn changelist. Let me know your comments. Currently, I see no side-effect on using this feature during fixing bugs. 2012/6/5 Yong Lin Ma mayo...@apache.org Pedro, I will do this. Please brief how do you hope the info will be organized and what should be highlighted. On Tue, Jun 5, 2012 at 12:16 AM, Pedro Giffuni p...@apache.org wrote: --- Lun 4/6/12, Jürgen Schmidt ha scritto: I guess there's going to be no way to convince people to use SVN correctly (hint: svn merge). :( I simply haven't thought about it but I agree svn merge would have been better here. Especially when we want to merge the whole branch later to trunk to ensure that we have all fixes integrated. svn merge actually helps a lot and I find it is really powerful, especially when there are big changes involving creating or moving files. I think part of the problem is that we don't have the procedures documented yet and people are afraid to break something in the main tree. We do have a small primer but it can be improved. For new (and sometimes old) committers it's good to have some reference for doing their first commit, the first merge, creating their own feature branch, etc. Volunteers are welcome; I am a little busy but I can give some pointers if someone wants to take the task. Pedro.
Re: Correct SVN practices (was Re: Fix for bug 119161)
--- Mer 6/6/12, Yong Lin Ma mayo...@apache.org ha scritto: Pedro, Could you update it with svn merge example you mentioned before? That was why we start this. Yes, it's rather easy (we don't need all the stuff the FreeBSD primer does) but I have been very busy lately. I don't have a WM account though so I was thinking of updating the Web primer instead. Pedro.
Re: Correct SVN practices (was Re: Fix for bug 119161)
On 06/06/12 21:20, Pedro Giffuni wrote: --- Mer 6/6/12, Yong Lin Mamayo...@apache.org ha scritto: Pedro, Could you update it with svn merge example you mentioned before? That was why we start this. Yes, it's rather easy (we don't need all the stuff the FreeBSD primer does) but I have been very busy lately. I don't have a WM account though so I was thinking of updating the Web primer instead. Pedro. Done: http://incubator.apache.org/openofficeorg/svn-basics.html There is a new section Merging Changes to a Branch (Markdown didn't catch the new section in the index though). Pedro.
Re: The new fetch_tarballs.sh
--- Mar 5/6/12, Andre Fischer a...@a-w-f.de ha scritto: .. Hi Pedro, On 04.06.2012 22:05, Pedro Giffuni wrote: Thank you Andre! I normally dislike perl but external_libs.lst surely looks nice now. Thanks. Well, I dislike Python and did not want to introduce yet another scripting language. That's fine. One wish for the future .. hmm.. if I use the external package (for example for python) it would be nice to disable downloading the corresponding tarballs too. That is possibly now by just changing the data file. I provided the script. We all can provide the data. There are other things to do, not necessary but nice to have: - Fill in the missing original download sites. - Solve the issues with mismatching MD5 sums. - (mentioned above) Guard more libraries with the same flags that control in their makefiles whether they are build. Oh, BTW, I didn't carry the checksummed license texts in ooo-extras: they are simply useless for building. I moved the relevant parts of the texts to the download descriptions, it seemed more reasonable to have there. I am thinking of adding support for binary blobs in both rhino and saxon as the Apache policy is OK about carrying Java binaries. Pedro. BTW, should I also upload the Category A tarballs to ooo-extras? For me that is a question of convenience. Moving them (not just copying them) to another site would mean that a simple SVN checkout would not put these tarballs on your local disk. Regards, Andre [...]
Re: Draft Blog post: OpenOffice.org is now Apache OpenOffice
--- Lun 4/6/12, Wolf Halton wolf.hal...@gmail.com ha scritto: ... The .org is in Apache is probably too clever, but it the rest of the article is fine. Wolf Hmm ... OK, maybe its better not to be too fancy. Lets leave it out then. Pedro.
Re: Fix for bug 119161
Hmm... Unrelated to the bug fix ... --- Lun 4/6/12, Jürgen Schmidt ha scritto: ... patch reviewed, tested and applied to AOO34 branch and trunk I guess there's going to be no no way to convince people to use SVN correctly (hint: svn merge). :( I will merge some minor fixes so that people can at least notice with good example. :-P. Cheers, Pedro. Thanks for the patch, works well Juergen
Correct SVN practices (was Re: Fix for bug 119161)
--- Lun 4/6/12, Jürgen Schmidt ha scritto: I guess there's going to be no way to convince people to use SVN correctly (hint: svn merge). :( I simply haven't thought about it but I agree svn merge would have been better here. Especially when we want to merge the whole branch later to trunk to ensure that we have all fixes integrated. svn merge actually helps a lot and I find it is really powerful, especially when there are big changes involving creating or moving files. I think part of the problem is that we don't have the procedures documented yet and people are afraid to break something in the main tree. We do have a small primer but it can be improved. For new (and sometimes old) committers it's good to have some reference for doing their first commit, the first merge, creating their own feature branch, etc. Volunteers are welcome; I am a little busy but I can give some pointers if someone wants to take the task. Pedro.
Re: The new fetch_tarballs.sh
Thank you Andre! I normally dislike perl but external_libs.lst surely looks nice now. One wish for the future .. hmm.. if I use the external package (for example for python) it would be nice to disable downloading the corresponding tarballs too. BTW, should I also upload the Category A tarballs to ooo-extras? Pedro. --- Lun 4/6/12, Andre Fischer a...@a-w-f.de ha scritto: Da: Andre Fischer a...@a-w-f.de Oggetto: The new fetch_tarballs.sh A: ooo-dev@incubator.apache.org Data: Lunedì 4 giugno 2012, 11:45 ... is called download_external_libraries.pl. It is a rewrite in Perl with the following improvements: - There can be an arbitrary number of download sites. In fact, I have added all original download sites that I could find (24 of the 38 category-A files, but only 4 of the 14 category-B files). - There can be several download sites per file. If one does not work the next is tried. This allows the use of ooo-extras.apache-extras.org.codespot.com as fallback for the original site and the SVN repository as a second fallback. - Each external library can be included or excluded conditionally. For example the category-B libraries are now loaded only when category-B is enabled. I used this for one other library, seamonkey. Now it is loaded only when it is later built (in the moz module). - On Windows it is much faster when all tar-balls are already present eg when you just re-run configure with a different set of flags. On my machine it runs in under 1 second instead of the 5 seconds of fetch_tarballs.sh: Perl can do most things in process for which fetch_tarballs.sh had to run external programs. These additional processes are apparently quite expensive. Some details: The download script is main/solenv/bin/download_external_libraries.pl. You will find it (I hope) well documented. The data file has a new format and I took the opportunity to rename it to main/external_libs.lst. It is also documented and should not be too hard to figure out. Now the important part: It did not yet make it the default. The changes are substantial and at a very central place. In order to activate it just set the environment variable USE_NEW_EXTLIB_DOWNLOAD to something, before bootstrap is called: export USE_NEW_EXTLIB_DOWNLOAD=t I tested it on Windows, Linux, and Mac but there are so many combinations of configure switches that I may have missed one that does not yet work with the new download script. Please try it and tell me about any errors. I hope this helps in our quest to solve the category-B questions. Andre
Re: Correct SVN practices (was Re: Fix for bug 119161)
Excellent Yonh Lin Ma!! I wasn't expecting anyone would take the offer but I am glad you did. We actually have some of the information here: http://incubator.apache.org/openofficeorg/developer-faqs.html but it doesn't have the best practices mentioned. I think we should have two different chapters: 1) Read-only access. This is meant for people that don't know that well what version control is but want to grab the code and play with it. It should contain how to do a checkout, update your tree, what the branches are and how to apply, revert or generate patches, It's actually a good practice to use svn diff to generate patches as it contains the information of the specific revision used to generate it. 2) Write access. There is a guide for new committers: http://www.apache.org/dev/new-committers-guide.html But I actually think that a quick guide that explains how to set the default properties and how to do the simple tasks would be great. My tips here are I highly recommend: 1) specifying in the command line a list of the files/dirs that are changed to avoid accidentally committing unwanted changes. 2) Use of a template for the log file with the author and other information. This is wrong: svn commit -m My changes This is right: svn commit ci -F ../mychangelog.txt change1 change2 3) Remind people to add the revision information in Bugzilla for crossreference, if it applies. This chapter should also explain how to create branches for bigger tasks and how to merge changes to a branch. For reference, FreeBSD has a SVN Primer, and the Merging section has some complete instructions: http://wiki.freebsd.org/SubversionPrimer/Merging Of course FreeBSD is more complex in structure and has many more committers so some additional rules are in place: In general we don't commit things directly to the branches unless we have to and in that case the Release Engineer has to approve the change. There's no such thing as lazy consensus there ;). We also set as minimum three days (I usually take a couple of weeks) before merging any change to the stable branch. Hope that helps, Pedro. --- Lun 4/6/12, Yong Lin Ma mayo...@apache.org ha scritto: Da: Yong Lin Ma mayo...@apache.org Oggetto: Re: Correct SVN practices (was Re: Fix for bug 119161) A: ooo-dev@incubator.apache.org, p...@apache.org Data: Lunedì 4 giugno 2012, 22:15 Pedro, I will do this. Please brief how do you hope the info will be organized and what should be highlighted. On Tue, Jun 5, 2012 at 12:16 AM, Pedro Giffuni p...@apache.org wrote: --- Lun 4/6/12, Jürgen Schmidt ha scritto: I guess there's going to be no way to convince people to use SVN correctly (hint: svn merge). :( I simply haven't thought about it but I agree svn merge would have been better here. Especially when we want to merge the whole branch later to trunk to ensure that we have all fixes integrated. svn merge actually helps a lot and I find it is really powerful, especially when there are big changes involving creating or moving files. I think part of the problem is that we don't have the procedures documented yet and people are afraid to break something in the main tree. We do have a small primer but it can be improved. For new (and sometimes old) committers it's good to have some reference for doing their first commit, the first merge, creating their own feature branch, etc. Volunteers are welcome; I am a little busy but I can give some pointers if someone wants to take the task. Pedro.
Re: [DISCUSS] Rules of voting for new committers and PPMC members
FWIW, The Foundation Roles are explained here: http://www.apache.org/foundation/how-it-works.html#roles Pretty much in line to what you are thinking. Pedro. --- Dom 3/6/12, Yong Lin Ma mayo...@gmail.com ha scritto: This was a discussion about rules of voting for new committer and PPMC member. We think it is more appropriate to let all contributors get involved in this. So I moved the discussion to ooo-dev. General process about voting in a new committer and PPMC member is here http://incubator.apache.org/guides/ppmc.html By far the practice is most candidates were voted for committer and PPMC member at the same time. And no concreate critrial defined in public for AOO. Your comments are welcomed. A comment from Rob: If it were entirely up to me I'd have it be like: 1) Contributor -- anyone who contributes to the project, mailing list discussions, patches, translations, bug reports, doc, support. This comes in all flavors and sizes. We need to do a better job giving them credit and acknowledging their contributions. If the feeling is that someone is not valued unless they are voted in as a PPMC member, then we're doing something wrong. 2) Committer -- The threshold question: Do we trust their judgement with respect to the area of their contributions? The move from contributor to committer is a move from RTC (patches must be reviewed) to CTR. So we really need to have a sense that they are doing quality work. Committers also have veto rights on all of our commits. So we need to trust their judgement. 3) PMC member -- The threshold question: Do they understand The Apache Way and our community-based decision making? On average are they solving more community problems than they are causing? Are they helping others in the community succeed? When we graduate, and our Mentors move on to other podlings, the PMC collectively needs to mentor new members to the project. So I think the PMC is more about trusting their community skills rather than their technical skills. It might be possible for someone to qualify for 2 and 3 at the same time. But probably not in every case. Note: This is not how we have operated previously. I think there was an bootstrapping issue where we needed to have a PPMC suitably large and diverse to provide balance. We also obviously started with a PPMC consisting of people who did not fully understand Apache. That is the nature of Incubation. But I don't think this approach is necessarily something we should continue with a year later, as we approach graduation.
Re: Draft Blog post: OpenOffice.org is now Apache OpenOffice
--- Dom 3/6/12, RGB ES ha scritto: ... Maybe add both, old and new logo side by side? But I think the post is just perfect as it is now: short and to the point. I would add one line to wrap things up: The .org is now in Apache. Cheers, Pedro.
Re: Draft Blog post: OpenOffice.org is now Apache OpenOffice
--- Dom 3/6/12, Kay Schenk kay.sch...@gmail.com ha scritto: Da: Kay Schenk kay.sch...@gmail.com Oggetto: Re: Draft Blog post: OpenOffice.org is now Apache OpenOffice A: ooo-dev@incubator.apache.org Data: Domenica 3 giugno 2012, 17:23 On 06/03/2012 12:50 PM, Pedro Giffuni wrote: --- Dom 3/6/12, RGB ES ha scritto: ... Maybe add both, old and new logo side by side? But I think the post is just perfect as it is now: short and to the point. I would add one line to wrap things up: The .org is now in Apache. Pedro, Rob -- I see that this comment got added but I can't really say I understand what it means. I wonder if others might have the same problem. It is a reference that as an organization OpenOffice is now part of Apache, which is also a .org . I think it is misplaced: it could be either the title or the last sentence which would make it stronger. But I dont have strong feelings about it. No need to take it out if we feel strongly about it, but FWIW, I think upon graduation we should also make emphasis that being in Apache is a fulfillment of the original promise from SUN to give the code to an independent organization with a governance model based on the ASF. Nowhere better to fulfill that promise than in the ASF ! Pedro. -- MzK So let it rock, let it roll Let the bible belt come and save my soul Hold on to sixteen as long as you can Changes come around real soon make us woman and men. -- Jack and Diane, John Mellencamp
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
--- Sab 2/6/12, Joe Schaefer joe_schae...@yahoo.com ha scritto: This situation doesn't seem to be diffusing itself, even tho I have tried to explain that the 3.4.0 release deps packaging does not comply with infra policy. Surely there is a middle ground here- that the missing release deps package simply be generated from those tarballs in svn. So long as the source release uses deps from the (downloaded from mirrors) deps package instead of directly from svn, AFAICT this project will be in compliance with all legal and infra policies. I certainly think this makes sense. Discriminating the Category-B tarballs in the mirrors is easier and does not give the impression that it is ASF code or that we are maintaining it. Plus mirrors are absolutely more adequate for distributing tarballs than a SVN repository. Pedro.
Re: [DISCUSS] Rules of voting for new committers and PPMC members
... --- Dom 3/6/12, Dave Fisher dave2w...@comcast.net ha scritto: ... On 06/03/2012 11:48 AM, Pedro Giffuni wrote: FWIW, The Foundation Roles are explained here: http://www.apache.org/foundation/how-it-works.html#roles yes, this is standard ASF policy. My question/concern at this point would be -- how well do we think this works for Apache OpenOffice? The PPMC has had the practice of making Committers into PPMC members on the same VOTE. This is the practice for some Apache projects, but not all. I think that from now on this project should always have separate votes as a matter of policy. What do others think? I agree. But I see two level of problems: 1) Pootle. At this time it's not possible to identify contributors and the PPMC is basically forced to bring them in as committers. Here the committer+PPMC vote is usually abused. 2) The PPMC has a tendency to bring in non-developers that usually don't need to be committers at all. I am not sure this fits strictly the Apache model but while it is clear that not all contributions are in code form, there is no other way of empowering them that does not go through making them committers first. If there were a way to make people members of the (P)PMC without making them committers I am sure that would be used a lot but it would seem meritocratically incorrect to bring into the PPMC people that are not committers but not offer the same opportunity to committers by default. Pedro. Regards, Dave Pretty much in line to what you are thinking. Pedro. --- Dom 3/6/12, Yong Lin Mamayo...@gmail.com ha scritto: This was a discussion about rules of voting for new committer and PPMC member. We think it is more appropriate to let all contributors get involved in this. So I moved the discussion to ooo-dev. General process about voting in a new committer and PPMC member is here http://incubator.apache.org/guides/ppmc.html By far the practice is most candidates were voted for committer and PPMC member at the same time. And no concreate critrial defined in public for AOO. Your comments are welcomed. A comment from Rob: If it were entirely up to me I'd have it be like: 1) Contributor -- anyone who contributes to the project, mailing list discussions, patches, translations, bug reports, doc, support.� This comes in all flavors and sizes.� We need to do a better job giving them credit and acknowledging their contributions.� If the feeling is that someone is not valued unless they are voted in as a PPMC member, then we're doing something wrong. 2) Committer -- The threshold question:� Do we trust their judgement with respect to the area of their contributions?� The move from contributor to committer is a move from RTC (patches must be reviewed) to CTR.� So we really need to have a sense that they are doing quality work.� Committers also have veto rights on all of our commits.� So we need to trust their judgement. 3) PMC member -- The threshold question:� Do they understand The Apache Way and our community-based decision making? On average are they solving more community problems than they are causing?� Are they helping others in the community succeed?� When we graduate, and our Mentors move on to other podlings, the PMC collectively needs to mentor new members to the project.� So I think the PMC is more about trusting their community skills rather than their technical skills. It might be possible for someone to qualify for 2 and 3 at the same time.� But probably not in every case. Note:� This is not how we have operated previously.� I think there was an bootstrapping issue where we needed to have a PPMC suitably large and diverse to provide balance.� We also obviously started with a PPMC consisting of people who did not fully understand Apache.� That is the nature of Incubation.� But I don't think this approach is necessarily something we should continue with a year later, as we approach graduation. -- MzK So let it rock, let it roll Let the bible belt come and save my soul Hold on to sixteen as long as you can Changes come around real soon make us woman and men. -- Jack and Diane, John Mellencamp
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
--- Sab 2/6/12, Rob Weir robw...@apache.org ha scritto: ... Pedro, your logic violates every principle of interpretation. If something was in a draft and then was removed from the draft, that suggests that there was not consensus for it to remain. I think the issue is strictly policy related. The approved policy is not a Bible, and even the Bible requires to be put into context. AOO is not a special case in the ASF where we interpret things we can or cannot do. I would prefer if someone qualified (from the IPMC perhaps) would explain to us if the policy has changed and we are now fine with including the sources of SeaMonkey and maintain patches for them in SVN. This said, I think the discussion is losing relevance in light of the developments. I would think the discussion has shifted from SHOULD we remove Cat-B tarballs from SVN to HOW will we remove Cat-B tarballs from SVN. I think this is a positive advance for the project. Pedro. You cannot use its removal as evidence that it is applicable. Please stick to the text of the approved policy. -Rob http://www.apache.org/legal/3party.html#criteriaandcategories /Even optional works must adhere to this policy if they are included as part of the Apache product./ So even when Category B tarballs appear to be optional, in practice they are part of the product and we shouldn't be distributing source code. cheers, Pedro. On 06/01/12 20:08, Pedro Giffuni wrote: Hi Ross; I don't think it's my turn since my issues remain unresolved. However let me recap: 1) I think just having patches that can or cannot be applied to category-B licensed code is OK as long as it is not the default. 2) I don't think we are allowed to distribute source tarballs in subversion. The argument in the legal FAQ would seem not to be specific enough: http://www.apache.org/legal/resolved.html#category-b Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled Redistribution of Category B in small quantities is also permitted but both clarifications clearly imply including source code the size and complexity of Mozilla Seamonkey is prohibited. The draft on which the policy was based is very clear: http://www.apache.org/legal/3party.html#criteriaandcategories Although the source must not be included in Apache products, the NOTICE file, which is required to be included in each ASF distribution,*must point to thesource http://www.apache.org/legal/3party.html#define-sourceform of the included binary*(more on that in the forthcoming Receiving and Releasing Contributions document). I don't think anyone is arguing here that the principle has changed and that we can include Category-B software 3) EPL and other licenses state that we must point to the source code used to generate the binary and this has already been pointed out by external developers like the COIN-OR guys. We are currently carrying outdated versions of Seamonkey and saxon in SVN and we are unable to point to the sources due to 2 reasons: 1) The specific source code is not available upstream anymore. 2) If the code is enabled (which is the default in the buildbots), the specific source code is patched during the build. I sustain that by keeping these sources in our SVN tree we are for all purposes forking the code and to some extent becoming the new upstream maintainers. Even if the original code is available upstream I still don't see a good reason to carry that code under version control. 4) I can't find a precedent among any other Apache Project where the ASF distributes Category-B sources in SVN, so I think hosting them would require a specific approval by legal@. My understanding is that there is work being done to have these issues solved on Monday. Pedro. On 06/01/12 18:09, Ross Gardler wrote: Just bringing this item back to the top. Nobody has linked to a policy that allows this or disallows it yet. However, Pedro has indicated he doesn't object to this specific case. Can we consider this one done? If so that is good progress (thank you Jurgen for making consensus possible on one specific case). Lets move onto the next one. Pedro raised a concern about a specific case and, if I'm following right there isn't consenus on that one (I wouldn't be surprised if I'm not following right since I'm tired of reading the arguments that go round in circles and stopped as soon as it descended again into non-specific cases). Can we have an equally detailed and clear description about the case Pedro highlights? We only need the facts about the problem being solved and the current solution, not the arguments for/against. Pedro, I suggest it's your turn since Jurgen started the ball rolling, Rob can
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
On 06/02/12 15:11, Juergen Schmidt wrote: ... Well I am a committer in the only big UNIX-like distribution that is carrying Apache OpenOffice nowadays. We would really like to use a source distribution through ASF mirrors but since the ASF doesn't provide one that works well we have been rolling our own. Having a working source distribution would help attract linux packagers, I think. well if that is really the case you have failed on several levels - you didn't really have used or tried the source tarball - you didn't gave the appropriate and necessary feedback - you didn't helped to fix your concerns relating the source release. At least it seems you have some concerns Sure, I am not perfect but you can't really blame the messenger if the package was broken. I have huge experience packaging stuff for my own selfish purposes in the past (BRL-CAD, FEM utilities, stuff like that), however I am not a ports committer/packager myself; I am a src committer. You can see my work in some sound drivers, the ext2fs implementation and some compiler updates. I have been very busy between kernel coding and the AOO SVN stuff to work also on the AOO packaging. The vast packaging work in FreeBSD has been done by Maho-san for several years and he has been so efficient I haven't really had to intervene other than to give some minor suggestions. He is a ports committer and I am so glad he has been around to take care of things. I have been busy on some updates and I only noticed a few days ago that we are not using the source tarballs provided by Apache. I can't really test everything behind a release and, with due respect, all I do is voluntary work so I do have to spend my time in other activities too. I am attempting to provide some feedback here but I would suggest you ask the guys doing Ubuntu or Debian packaging if they are using the src tarballs and how we can make the packaging easier. That makes me really thinking ... Please stop imagining things. I know you guys are not happy about having to do extra reshuffling in the tree and playing with scripts to adapt things to what *I* think is the Apache way. In all honesty let's admit I had mentioned this was a grey area since a long time ago and I have even offered to step aside and let the project evolve on it's own. Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Hi Jürgen; On 06/01/12 03:16, Jürgen Schmidt wrote: On 5/31/12 6:26 PM, Pedro Giffuni wrote: ... First of all we should clarify what a source release is in this context. Does our source release contain Category-A tarballs? In other words, does this file: http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2 I hoped that was clear, our source release files don't contain any tar-balls from ext_sources OK. So what we are releasing is only the part of the SVN tree labelled main, (not sure if ext_libraries is included, it should be). I would think a source release should be able to build without having to look for extra libraries in our SVN. Call me old fashioned but I am thinking of people trying to distribute the sources in a CD-ROM. Build on it's own? Or are developers/builders expected to download more tarballs from SVN. yes, you unpack the source, solve some basic build env requirements according the building guide, run configure and build. The tar-balls get downloaded during the bootstrap step automatically. After checking it again, the only drawback currently is that all tar-balls are downloaded even if they are not used. That is true for all categories. But this is something that we can improve for the 3.5 (already started). We should only download the tar-balls that we need by configure ... Why not 3.4.1? Because it is a maintenance release only and we want to be careful. For 3.4.1 we change the url to download from our 3.4 revision. I think all releases must respect Apache policies ASAP. It seems to be really an item for legal to decide if hosting the category-b tar-balls in svn is not allowed for convenience at all. Furthermore we agreed to accept and of course support the move to another server but it is important that we don't break our 3.4 release. As you noted before, removing Category-B tarballs shouldn't break the default build. But I will go further ahead with mentioning that the 3.4 Release is theoretically broken already with the Lucene and Apache Commons updates (the development branch is for development, right?), and since no one complained people must be getting the files from somewhere else. well that is a very bad example and probably wrong. We all know or expect that not many people will build AOO from the source release. People who are interested will more likely check it out from svn as you and I did it as well. I think the problem is your definition of source release. The source release in the source tarballs should be 1:1 equivalent to the source release in SVN. If you think release (in the tarball) is only what you have under main then we do have trouble moving dependencies in the tree. but if you include the tarballs in the release, then we don't have trouble. In other words: If 3.4.1-Release is this: http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/ it has never been broken. If it is only this: http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/main/ Then the release is unbuildable on it's own. We also agreed to clean up as much as possible of the dependencies to category-b stuff over time. But that takes time and is a lot of work. I admit this is very clear. I don't expect such development to be a requirement for graduation but the transitory situation of a source release that depends on carrying category-B tarballs in SVN now is not really acceptable. well that is exactly the question. I don't know for sure if it is a real problem to have them in svn. svn or any other server would be equal as long as we don't change/improve the download part. So the real problem seems to be a different one. I will address the Category-B + patches issue on another email.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Ugh ... --- Ven 1/6/12, Rob Weir robw...@apache.org ha scritto: ... No release is buildable on its own. You need an operating system, a compiler, often other pre-existing libraries on the system, other prerequisites that need to be installed by the developers. And computers need electricity, which is not free and not available under a compatible license. I wish you could keep focused or at least do an effort to understand the issues so we can solve them. The tarball release must be consistent; we cannot hide tarballs in SVN. Creating a directory with the Category-A tarballs that form a base of the release along with the base distribution is not really a problem. Some of them are not available upstream anymore. Pedro. Even in its cleanest form, a Java program using Maven, a release will not build until the user first installs Maven. So no one (except maybe you) is arguing that our release should be buildable without any dependencies that are not included in the release. The real questions should be thought of from the developer's perspective: 1) What dependencies are mandatory and which ones are optional, needed only for specific features? 2) What are the obligations that a developer has when they make use of, or modify code in a particular dependency? 3) What do I need to provision my dev environment to build, with or without any given dependency. What we do at Apache, providing open source software for the good, is directed to making things simple for the downstream consumers of our releases. What we're doing with ext_sources is making #3 far easier, for the developer, compared to tracking down and fetching dependencies from other websites. And I think we've taken the proper steps to provide information, build flags, NOTICE and LICENSE files to cover the other two concerns. We also agreed to clean up as much as possible of the dependencies to category-b stuff over time. But that takes time and is a lot of work. I admit this is very clear. I don't expect such development to be a requirement for graduation but the transitory situation of a source release that depends on carrying category-B tarballs in SVN now is not really acceptable. well that is exactly the question. I don't know for sure if it is a real problem to have them in svn. svn or any other server would be equal as long as we don't change/improve the download part. So the real problem seems to be a different one. I will address the Category-B + patches issue on another email.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
--- Ven 1/6/12, Rob Weir robw...@apache.org ha scritto: ... And computers need electricity, which is not free and not available under a compatible license. I wish you could keep focused or at least do an effort to understand the issues so we can solve them. Be nice. Couldn't resist :-P. But I really think you can bring more intelligent arguments to the discussion if you focus more on solvig the issues and less on making your point. The tarball release must be consistent; we cannot hide tarballs in SVN. Creating a directory with the Category-A tarballs that form a base of the release along with the base distribution is not really a problem. Some of them are not available upstream anymore. That is one possible technique. But not the only one. I'm a committer on another Apache project, the ODF Toolkit, and we do not include any of the dependencies in our release, not even other category-a ones. Well I am a committer in the only big UNIX-like distribution that is carrying Apache OpenOffice nowadays. We would really like to use a source distribution through ASF mirrors but since the ASF doesn't provide one that works well we have been rolling our own. Having a working source distribution would help attract linux packagers, I think. Perhaps you happen to have data about how many people are finding the current source distribution tarballs useful? All of them are downloaded on the fly from a central repository. That is the beauty of Maven. I have personal experience packaging stuff and this is undesirable. One of my ports was rejected recently because its inconvenient to have the buildbot depend on network access. Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Hi Ross; I don't think it's my turn since my issues remain unresolved. However let me recap: 1) I think just having patches that can or cannot be applied to category-B licensed code is OK as long as it is not the default. 2) I don't think we are allowed to distribute source tarballs in subversion. The argument in the legal FAQ would seem not to be specific enough: http://www.apache.org/legal/resolved.html#category-b Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled Redistribution of Category B in small quantities is also permitted but both clarifications clearly imply including source code the size and complexity of Mozilla Seamonkey is prohibited. The draft on which the policy was based is very clear: http://www.apache.org/legal/3party.html#criteriaandcategories Although the source must not be included in Apache products, the NOTICE file, which is required to be included in each ASF distribution,*must point to thesource http://www.apache.org/legal/3party.html#define-sourceform of the included binary*(more on that in the forthcoming Receiving and Releasing Contributions document). I don't think anyone is arguing here that the principle has changed and that we can include Category-B software 3) EPL and other licenses state that we must point to the source code used to generate the binary and this has already been pointed out by external developers like the COIN-OR guys. We are currently carrying outdated versions of Seamonkey and saxon in SVN and we are unable to point to the sources due to 2 reasons: 1) The specific source code is not available upstream anymore. 2) If the code is enabled (which is the default in the buildbots), the specific source code is patched during the build. I sustain that by keeping these sources in our SVN tree we are for all purposes forking the code and to some extent becoming the new upstream maintainers. Even if the original code is available upstream I still don't see a good reason to carry that code under version control. 4) I can't find a precedent among any other Apache Project where the ASF distributes Category-B sources in SVN, so I think hosting them would require a specific approval by legal@. My understanding is that there is work being done to have these issues solved on Monday. Pedro. On 06/01/12 18:09, Ross Gardler wrote: Just bringing this item back to the top. Nobody has linked to a policy that allows this or disallows it yet. However, Pedro has indicated he doesn't object to this specific case. Can we consider this one done? If so that is good progress (thank you Jurgen for making consensus possible on one specific case). Lets move onto the next one. Pedro raised a concern about a specific case and, if I'm following right there isn't consenus on that one (I wouldn't be surprised if I'm not following right since I'm tired of reading the arguments that go round in circles and stopped as soon as it descended again into non-specific cases). Can we have an equally detailed and clear description about the case Pedro highlights? We only need the facts about the problem being solved and the current solution, not the arguments for/against. Pedro, I suggest it's your turn since Jurgen started the ball rolling, Rob can be up next (sorry to sound like a school teacher, please think of me as a conductor not a school teacher - I'm not trying to patronise, it's just it's very late here and I still have a client deliverable that AOO has stood in the way of for the last two days). Once we have the facts laid out nice and cleanly lets seek pointers to policy that allows or disallows the solution in place. If pointers are not possible lets take the specific case to the IPMC for clarification. Ross
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Sorry to highlight something more here... The draft (which I insist is clearer that the resolved FAQ) says, under License Categories: http://www.apache.org/legal/3party.html#criteriaandcategories /Even optional works must adhere to this policy if they are included as part of the Apache product./ So even when Category B tarballs appear to be optional, in practice they are part of the product and we shouldn't be distributing source code. cheers, Pedro. On 06/01/12 20:08, Pedro Giffuni wrote: Hi Ross; I don't think it's my turn since my issues remain unresolved. However let me recap: 1) I think just having patches that can or cannot be applied to category-B licensed code is OK as long as it is not the default. 2) I don't think we are allowed to distribute source tarballs in subversion. The argument in the legal FAQ would seem not to be specific enough: http://www.apache.org/legal/resolved.html#category-b Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled Redistribution of Category B in small quantities is also permitted but both clarifications clearly imply including source code the size and complexity of Mozilla Seamonkey is prohibited. The draft on which the policy was based is very clear: http://www.apache.org/legal/3party.html#criteriaandcategories Although the source must not be included in Apache products, the NOTICE file, which is required to be included in each ASF distribution,*must point to thesource http://www.apache.org/legal/3party.html#define-sourceform of the included binary*(more on that in the forthcoming Receiving and Releasing Contributions document). I don't think anyone is arguing here that the principle has changed and that we can include Category-B software 3) EPL and other licenses state that we must point to the source code used to generate the binary and this has already been pointed out by external developers like the COIN-OR guys. We are currently carrying outdated versions of Seamonkey and saxon in SVN and we are unable to point to the sources due to 2 reasons: 1) The specific source code is not available upstream anymore. 2) If the code is enabled (which is the default in the buildbots), the specific source code is patched during the build. I sustain that by keeping these sources in our SVN tree we are for all purposes forking the code and to some extent becoming the new upstream maintainers. Even if the original code is available upstream I still don't see a good reason to carry that code under version control. 4) I can't find a precedent among any other Apache Project where the ASF distributes Category-B sources in SVN, so I think hosting them would require a specific approval by legal@. My understanding is that there is work being done to have these issues solved on Monday. Pedro. On 06/01/12 18:09, Ross Gardler wrote: Just bringing this item back to the top. Nobody has linked to a policy that allows this or disallows it yet. However, Pedro has indicated he doesn't object to this specific case. Can we consider this one done? If so that is good progress (thank you Jurgen for making consensus possible on one specific case). Lets move onto the next one. Pedro raised a concern about a specific case and, if I'm following right there isn't consenus on that one (I wouldn't be surprised if I'm not following right since I'm tired of reading the arguments that go round in circles and stopped as soon as it descended again into non-specific cases). Can we have an equally detailed and clear description about the case Pedro highlights? We only need the facts about the problem being solved and the current solution, not the arguments for/against. Pedro, I suggest it's your turn since Jurgen started the ball rolling, Rob can be up next (sorry to sound like a school teacher, please think of me as a conductor not a school teacher - I'm not trying to patronise, it's just it's very late here and I still have a client deliverable that AOO has stood in the way of for the last two days). Once we have the facts laid out nice and cleanly lets seek pointers to policy that allows or disallows the solution in place. If pointers are not possible lets take the specific case to the IPMC for clarification. Ross
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Hi Jürgen; Let me clarify some issues too ... On 05/31/12 10:39, Jürgen Schmidt wrote: ... let me explain some details here because I think they can help to understand. 1. we have dependencies to several external libraries including category-b for some features 2. we have checked in all this source tar-balls in ext_sources for convenience and to ensure that they are always available. Another option would have been to host them somewhere else on extras or any other reliable server. We use the easier way for convenience reasons I think. 3. our source release don't contain any category-b source tar-balls First of all we should clarify what a source release is in this context. Does our source release contain Category-A tarballs? In other words, does this file: http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2 Build on it's own? Or are developers/builders expected to download more tarballs from SVN. 4. from a source release perspective we don't make use of any category-b stuff per default. A user have to explicitly trigger the use of category-b stuff and related features. The tar-balls are downloaded on demand, some kind of dependency mechanism if you want. So if we remove the Category-B tarballs from SVN the default build doesn't break, this is important. Now.. if the tarballs are downloaded on demand, are you meaning those are downloaded from SVN? (It's an honest question: I normally checkout all the tree from SVN, including the Category-B, tarballs so I haven't experienced the on-demand part of it) 5. the download on demand is the same and I don't really see a difference between downloading the tar-balls from svn or any other place. OK. Do note that doing a SVN checkout, as suggested in CWiki, there's no easy way to exclude the category-B tarballs: svn co https://svn.apache.org/repos/asf/incubator/ooo/trunk ooo 6. we agreed to upstream changes to external libs where possible and necessary. And we agreed to improve the workflow to use the tar-balls from their original source where possible over time and where we can rely on the overall availability (e.g. dependencies to Apache libs, etc.) Yes. Most of them are just uninteresting upstream. It seems to be really an item for legal to decide if hosting the category-b tar-balls in svn is not allowed for convenience at all. Furthermore we agreed to accept and of course support the move to another server but it is important that we don't break our 3.4 release. As you noted before, removing Category-B tarballs shouldn't break the default build. But I will go further ahead with mentioning that the 3.4 Release is theoretically broken already with the Lucene and Apache Commons updates (the development branch is for development, right?), and since no one complained people must be getting the files from somewhere else. We also agreed to clean up as much as possible of the dependencies to category-b stuff over time. But that takes time and is a lot of work. I admit this is very clear. I don't expect such development to be a requirement for graduation but the transitory situation of a source release that depends on carrying category-B tarballs in SVN now is not really acceptable. We are also open for any other action that we have to take to be conform to existing policies. I think we have shown in the past that we take everything serious and address issues in time where possible. I hope you agree that solving the issue is possible. Pedro.
Re: [PROPOSAL] Starting the graduation process
Hi Andre; --- Mer 30/5/12, Andre Fischer a...@a-w-f.de ha scritto: ... The idea that we have remaining issues with Category-B tarballs in the tree has been around since before the release, and one of our mentors (Ross I recall) did acknowledge my point of view. I did offer to step down then but I don't mean to make a big issue out of this. If I step down it will be communicated in the private list exclusively. I would still be a committer and nothing would really change for me. What I feel is disappointing is the lack of acknowledgement that there *is* an issue. Category-B software can be included in releases in binary form but it should be otherwise actively discouraged, and in general unsupported: it should not be included in the buildbots and using it should be, in general terms, a PITA. But the binary builds have to come from somewhere. Unless we want to drop the features for which we need category-B libraries then making it harder to build them is IMHO not the right way to go. I have an idea: if you look at the stax api module, there is an option to copy the binaries in a download dir. This works very well for java libraries (saxon, rhino, even beanshell). Seamonkey we can probably live without. The big problem is still Coin-MP: we really should have the option to use the external library in configure. But maybe moving the offending libraries to another server would be a first step? If you find a server and copy the files over then I am willing to adapt the scripts accordingly. I will do this next week. I will probably use Apache extras and at a later time we could leave there the old GPL'd stuff too (unsupported of course). Pedro.
Re: [PROPOSAL] Starting the graduation process
--- Mer 30/5/12, Louis Suárez-Potts lui...@gmail.com ha scritto: On 2012-05-30, at 11:05 , Pedro Giffuni wrote: I will do this next week. I will probably use Apache extras and at a later time we could leave there the old GPL'd stuff too (unsupported of course). Pedro. A good solution, i'd guess, and thanks. but this leaves the obvious question, of timing and roadmaps (or equivalent). I'm not rushing or nagging, just curious. IMO, just moving those files would put us in compliance with Apache Policies. I wouldn't start the graduation process before that is done but we can see what other preparations are required. Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Oh boy ... --- Mer 30/5/12, Rob Weir robw...@apache.org ha scritto: ... You can copy the category-b binaries someplace else, but you must not remove the ones that are already here. Otherwise you will break not only the buildbots, but you will also break every one who has downloaded the source from our 3.4 release. So *NOW* you are admitting that those tarballs are part of the Release?? We don't have permission from legal@ to ship Category-B sources .. that must be fixed .. with axe. Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
--- Mer 30/5/12, Rob Weir robw...@apache.org ha scritto: So *NOW* you are admitting that those tarballs are part of the Release?? Not at all. But they are referenced from build files. I hope this distinction is clear. No. If they are just referenced then we don't depend on having them there: we just have to replace the reference. A nice text file mentioning where to find them (ooo-exttas @ Apache Extras) *is* a reference. Again, go back to the licensing page and the principles stated there. This is not a crusade to eradicate category-b code from the face of the earth. I didn'r say I am eradicating anything (yet), they just can't be in SVN. This is about making it clear to downstream consumers what the dependencies are, what obligations those dependencies bring, and to require an explicit, informed decision for the downstream developer to enable the use of category-b binaries. We are doing all of that. We don't have permission from legal@ to ship Category-B sources .. that must be fixed .. with axe. Put the axe away, Pedro. As you know, category-b code is not included in the release. We already went through the audit on that. There was no audit. Mr RAT never examined those and we discussed this was a temporary situation. In case it is not clear, I'll veto any attempt by you to break the 3.4 source distributions. You mean source distribution (tarballs) don't build on their own and depend on what we carry in SVN? Sounds like something is wrong. Well ... those files are not required by default for the build, they are only optionally used and we did it on purpose so as long as we make a small adjustment in the buildbots I don't see what you can veto about it. And while you are so brave about vetoing hypothetical issues ... I already axed a couple of tarballs from the old Apache commons and Lucene. Have fun putting them back :-P. Pedro.
Re: [PROPOSAL] Starting the graduation process
Hi Drew; --- Mar 29/5/12, drew d...@baseanswers.com ha scritto: snip Yes the situation was specifically postponed as a graduation issue, I am not going through that discussion again. I made a concrete proposal with two alternatives: - They are moved to a friendly ftp/http site. - I step down from the PPMC to avoid the community the pain of a -1 vote. ... Could be - it was just the way Pedro phrased his comment I thought perhaps his thinking was being influenced by the earlier remarks. The idea that we have remaining issues with Category-B tarballs in the tree has been around since before the release, and one of our mentors (Ross I recall) did acknowledge my point of view. I did offer to step down then but I don't mean to make a big issue out of this. If I step down it will be communicated in the private list exclusively. I would still be a committer and nothing would really change for me. What I feel is disappointing is the lack of acknowledgement that there *is* an issue. Category-B software can be included in releases in binary form but it should be otherwise actively discouraged, and in general unsupported: it should not be included in the buildbots and using it should be, in general terms, a PITA. IMHO this project benefited greatly from the Category-X replacement and in general I would like the project to head in a direction that will lead to greater license and code simplification but the current situation where we work-around the policy issues instead of solving them is (again IMO) unacceptable. Pedro.
Re: [PROPOSAL] Starting the graduation process
Hi; --- Mar 29/5/12, sebb seb...@gmail.com ha scritto: ... This is admittedly a stop gap solution to comply better with the Apache policies, the real fix would be to work collectively on replacing the code that can be replaced: Alternatively, it is possible to include cat B [1] dependencies in binary form. We do this for FreeBSD and it works great. Is there any need to include the source? No. The real reason why OOo historically has carried the sources for everything is/was that previously the GPL forced developers to make the sources available. The issue is the multiplatform support. For builders on platforms like Windows it's not really fun to go looking for the different dependencies. This said, for Java stuff it is perfectly OK to include only binaries (except for our old saxon-B, which is deprecated upstream so we have to carry the sources somewhere) [1] http://www.apache.org/legal/resolved.html#category-b While [1] is the official document, I find the original draft policy explains things much better: http://www.apache.org/legal/3party.html cheers, Pedro.
Re: [PROPOSAL] Starting the graduation process
Hi Rob; On 05/28/12 13:10, Rob Weir wrote: I'd like to start the graduation process, with the aim of being a TLP in time for the 3.4.1 release. The IPMC has a Guide to Successful Graduation page with a lot of detail and advice: http://incubator.apache.org/guides/graduation.html The calendar here is especially useful: http://incubator.apache.org/guides/graduation.html#toplevel It shows 4 steps: 1) a vote on ooo-dev (a community vote) on whether we want to graduate now 2) a discussion on ooo-dev leading to the draft of a charter for the new TLP 3) an IPMC vote on whether or not to recommend the podling for graduation 4) a vote by the ASF Board on a resolution creating the new TLP This thread is just a proposal. It is not the actual vote called for in #1 above. But I'd like to gauge current sentiment. Are we all +1 for going ahead? If not, please list what pre-graduation tasks you believe need to be done first. Thanks! -Rob A reminder of a small, but IMHO significant, technical issue: We do have to take the category-B tarballs out of the tree before graduation. In general we should also clear out any other unclear content .. so I am not sure what to say about the Symphony code since it also contains some code that has not been fully IP reviewed. Pedro.
Re: [PROPOSAL] Starting the graduation process
On 05/28/12 14:25, Rob Weir wrote: On Mon, May 28, 2012 at 2:45 PM, Pedro Giffunip...@apache.org wrote: Hi Rob; On 05/28/12 13:10, Rob Weir wrote: I'd like to start the graduation process, with the aim of being a TLP in time for the 3.4.1 release. The IPMC has a Guide to Successful Graduation page with a lot of detail and advice: http://incubator.apache.org/guides/graduation.html The calendar here is especially useful: http://incubator.apache.org/guides/graduation.html#toplevel It shows 4 steps: 1) a vote on ooo-dev (a community vote) on whether we want to graduate now 2) a discussion on ooo-dev leading to the draft of a charter for the new TLP 3) an IPMC vote on whether or not to recommend the podling for graduation 4) a vote by the ASF Board on a resolution creating the new TLP This thread is just a proposal. It is not the actual vote called for in #1 above. But I'd like to gauge current sentiment. Are we all +1 for going ahead? If not, please list what pre-graduation tasks you believe need to be done first. Thanks! -Rob A reminder of a small, but IMHO significant, technical issue: We do have to take the category-B tarballs out of the tree before graduation. Do we? If I recall, there were multiple views on this and no consensus. But you are welcome to make a concrete proposal. Yes the situation was specifically postponed as a graduation issue, I am not going through that discussion again. I made a concrete proposal with two alternatives: - They are moved to a friendly ftp/http site. - I step down from the PPMC to avoid the community the pain of a -1 vote. Pedro.
