Re: How can I suggest a new component application?
I was wondering where I can suggest a new component application for the Apache OpenOffice project? Presumably the same way as in any Open Source project: By implementing it. (Or money/employment to people implementing it.) --tml
Re: Copyright statements and some other stuff
On 1/12/12 8:40 PM, Ariel Constenla-Haile wrote: Hi Jürgen, On Thu, Jan 12, 2012 at 12:29:50PM +0100, Jürgen Schmidt wrote: 3. Values in minor.mk The main/solenv/inc/minor.mk contains several values that have influence on several places. For example the name of the download files, the content of the About dialog, etc. The value are current: RSCVERSION=340 RSCREVISION=340m1(Build:9584) BUILD=9584 LAST_MINOR=m1 SOURCEVERSION=OOO340 I think we should define new values and the question is how we want to use this values. I would propose the following for the short term: RSCVERSION=340 - we keep this for now because are working on an AOO 3.4 and we will change it when we work on 4.0 or 3.4.1 accordingly RSCREVISION=340m1(Build:9584) - here i am not sure how we should handle this. We have currently no similar build process that we had in the past. I would propose a value like 340 (Rev.: r1230461) where we change the revision number dynamically. BUILD - don't have a good idea yet LAST_MINOR - the same, I haven't a good idea yet. I've been working on this http://s.apache.org/X2B and in the meantime found a solution, I'll post something on the weekend. great, to good to hear that. What do you think about the dynamical update of the revision number during the build? Or maybe a special script that can be triggered after an update. I know you get the revision number during the configure switch but I think about an update without configure. For a minor update of only a few files i would simply rebuild without configure. Juergen
Re: Status of OOo NetBeans Plugin
Hi Carl, thanks for the reminder, I will work with Andrew on this and we can hopefully provide the sources asap. But the plugin will need some maintenance work ;-) Juergen On 1/13/12 12:54 AM, Carl Marcum wrote: Hi all, I've seen mentioned in another thread, the OOo NetBeans plugin was to be part of the SGA, but not yet available. Does anyone know the status of the code, or when we should see it? Best regards, Carl
Re: Real life preview of some of the proposed images
On 1/12/12 9:04 PM, Ariel Constenla-Haile wrote: Hi *, On Thu, Jan 12, 2012 at 05:31:20PM +0100, Jürgen Schmidt wrote: Hi, for the dev builds I plan to provide (asap) I have simply used Drew's proposals, added some of by my own and have built a Mac version. I have some minor problems with the OOo-Dev dmg installer background images where I am working on. But ou can get a first impression how would look like under Backing window + About box http://people.apache.org/~jsc/screenshots/backing_window-about.png Intro image http://people.apache.org/~jsc/screenshots/intro.png MacOS dmg background http://people.apache.org/~jsc/screenshots/mac_install_dmg.png well the quality of this image is too bad right now and I will try to improve it. But I know Drew will give me support ;-) Juergen they look nice. I wonder if Incubating is required there. This is an Apache jargon, I doubt it would have any sense for English speaking users; and more problematic for non-English speaking user: the text is not localized. IMO Incubating only adds more confusion to the already existing confusion in our user base. If this is not an Apache requirement, it would be nice to remove it from the logos. I agree and would prefer this as well. The important point for me is that the project is incubating but not the product. And I agree to rob that it should be sufficient to mentioned this in the text on the project sites. Well we can use logos with the Incubating string on the websites but we should not use it in the product if possible. Juergen Reading http://incubator.apache.org/guides/branding.html it is not very clear to me: Naming After a podling has been approved, the lists are created, and the initial code drop has commenced, the podling MUST be referred to as Apache Podling-Name AND mention that the project is under Incubation. Suitable mentions include: Inclusion of the http://incubator.apache.org/podling-name; URL Apache Podling-Name is currently undergoing Incubation at the Apache Software Foundation. Other references may only be used upon prior approval by the Incubator PMC. These statements only need to be disclosed upon the first reference in a document. Incubator Logo Podlings websites SHOULD contain the Apache Incubator Project logo as sign of affiliation. I understand this as: We have to MENTION that the project is under Incubation, this does not mean to put Incubating in the logo: * the splash screen already says AOO is incubating in the text Build contributed... * The can be done in the About dialog edit field * etc etc Regards
Re: [NIGHTLY BUILD]
On 12.01.2012 22:27, Andrew Rist wrote: Andre , I think one of the fixes you made to main/vcl/Library_vclplug_gtk.mk is breaking the build on the buildbot. see view-source:http://ci.apache.org/projects/openoffice/buildlogs/main/vcl/unxlngx6.pro/misc/logs/prj.txt Sorry about that. I am working on it. -Andre cd .. make -r -j1 [ clean ] ERROR: Please give only libary basenames to gb_LinkTarget_add_external_libs [ clean ] ERROR: (no prefixes -l% or lib%, no suffixes %.so or %.lib) [ clean ] ERROR: libraries given: -pthread -L/lib -ldbus-glib-1 -ldbus-1 -lpthread -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 [ clean ] ERROR: offending: -ldbus-glib-1 -ldbus-1 -lpthread -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 /home/buildslave19/slave19/openofficeorg-nightly/build/main/vcl/Library_vclplug_gtk.mk:59: *** . Stop. dmake: Error code 2, while making 'all' Andrew
Re: Status of OOo NetBeans Plugin
I am also interested in the status of OOo plugin for Netbeans. Appreciate if you could add me in the list too. Best regards CM 2012/1/13 Jürgen Schmidt jogischm...@googlemail.com Hi Carl, thanks for the reminder, I will work with Andrew on this and we can hopefully provide the sources asap. But the plugin will need some maintenance work ;-) Juergen On 1/13/12 12:54 AM, Carl Marcum wrote: Hi all, I've seen mentioned in another thread, the OOo NetBeans plugin was to be part of the SGA, but not yet available. Does anyone know the status of the code, or when we should see it? Best regards, Carl
Re: Category-B tarballs in SVN (was Re: External libraries)
On 12.01.2012 20:59, Pedro Giffuni wrote: --- Gio 12/1/12, Rob Weirrobw...@apache.org ha scritto: ... If you look carefully, you'll see that SVN, via the website stuff that is now there, has tons of content now that is in incompatible licenses, in the form of GPL and other licensed documentation. Ditto for the wiki. Ditto for extensions site. These are all hosted by the Apache, on behalf of the project, but they are not part of our releases. Are you saying SVN must be cleaned of all of that, even if it is not part of our releases? I certainly had understood the policy for website, Wiki and even the extensions site is that we shouldn't be hosting copyleft content. There might be a transitory situation during incubation and some things are still to be decided but even you have clearly stood in the position where any new content in the Wiki, etc should be under AL2. I'm happy to have someone review the issue, if you can state what the policy issue is. I simply don't see any problem here. We're not including category-b source code in our release, period. I am really not going into this discussion with you again. I think the issue is very easy to resolve: drop the tarballs from SVN and provide sufficient instructions so that the people doing the builds can download the tarballs themselves: we even have nice fetch_tarball.sh script to do just that. I am not quite sure that I understand the problem here. Would it be OK to move the category-b tar balls to eg SourceForge or Google and just adapt the URL in the ooo.lst file? -Andre Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
On 1/12/12 9:29 PM, Rob Weir wrote: On Thu, Jan 12, 2012 at 2:59 PM, Pedro Giffunip...@apache.org wrote: --- Gio 12/1/12, Rob Weirrobw...@apache.org ha scritto: ... If you look carefully, you'll see that SVN, via the website stuff that is now there, has tons of content now that is in incompatible licenses, in the form of GPL and other licensed documentation. Ditto for the wiki. Ditto for extensions site. These are all hosted by the Apache, on behalf of the project, but they are not part of our releases. Are you saying SVN must be cleaned of all of that, even if it is not part of our releases? I certainly had understood the policy for website, Wiki and even the extensions site is that we shouldn't be hosting copyleft content. There might be a transitory situation during incubation and some things are still to be decided but even you have clearly stood in the position where any new content in the Wiki, etc should be under AL2. My point about website content being ALv2 was to give us the flexibility of including website content in a future release. Even online documentation might have a role if it could be bundled in a release, since that would allow downstream consumers to modify that documentation website and reuse it for their products. But it still comes down to the question of what is in a release. I'm happy to have someone review the issue, if you can state what the policy issue is. I simply don't see any problem here. We're not including category-b source code in our release, period. I am really not going into this discussion with you again. I think the issue is very easy to resolve: drop the tarballs from SVN and provide sufficient instructions so that the people doing the builds can download the tarballs themselves: we even have nice fetch_tarball.sh script to do just that. The advice we've received in the past is that no policy issue related to a release is resolved simply by moving code. Back up and look at the downstream consumer, the person receiving a release. How do we feature AL as the default? How are we ensuring that category-b is included only by their explicit choice, rather than automatically? How are we ensuring that the downstream consumer has proper notice of the licenses and notices relevant to the code that they are downloading in our releases? How are we avoiding forking MPL components or doing further development work on them? How are we making an effort to push patches upstream? Those are the things we should be careful about. But in an automated script, whether it downloads MPL tarballs from an Apache server or an Apache Extras, I simply don't see any policy concern one way or another there. On the other hand, I do see relevant technical issues, including how do we ensure that we can maintain prior releases, including via security patches, if our binary releases are based on code that is scattered all over the web and which could disappear tomorrow based on the whim of other less stable OSS maintainers, or based on corporations merging or existing the business. I think the only prudent thing we can do is maintain a copy of all of our dependencies. that is a very important point and we should keep the practical relevance in mind. I normally build with --with-dmake-url to test this because it is currently very important for people who wants to start building AOO on their own. As long as we haven't switched completely to gnu make. I think it was on Wednesday or so where stumbled over the problem that the mentioned Url to Apache extras was not reachable for a day or at least several hours. That was not really satisfying from a user perspective :-( Juergen Another way to think of it is this: the rights and obligations of a downstream consumer are invariant over the choice of where the category-b code is downloaded from. Would you agree with that much? If so, I don't see any basis for a policy distinction purely based on the location of the downloaded code. Pedro.
[BUILD] License header in map files - Win build breaker
Hi *,
this is a funny build breaker:
cat version.map | awk -f Y:/apache/trunk/main/solenv/bin/getcsym.awk
../../wntmsci12.pro/misc/version_sofficeapp.dxp
awk: Y:/apache/trunk/main/solenv/bin/getcsym.awk:23: (FILENAME=- FNR=7)
fatal: Unmatched ( or \(: /# to you under the Apache License, Version 2.0 (the/
dmake: Error code 2, while making
'../../wntmsci12.pro/misc/version_sofficeapp.dxp'
dmake: '../../wntmsci12.pro/misc/version_sofficeapp.dxp' removed.
ERROR: error 65280 occurred while making
/cygdrive/y/apache/trunk/main/desktop/source/app
It happens while building
desktop/source/app/version.map
desktop/source/pkgchk/unopkg/version.map
The issue is with solenv/bin/getcsym.awk that can't handle an opening
'(' with the closing ')' in the next line, as in the License header:
# to you under the Apache License, Version 2.0 (the
# License); you may not use this file except in compliance
If someone knows awk, please fix solenv/bin/getcsym.awk
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
pgpCsBgNyMJZz.pgp
Description: PGP signature
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
Hi Claudio, On Thu, Jan 12, 2012 at 06:46:26PM -0200, Claudio Filho wrote: was more easy to migrate to LibO. Today, only René, a Debian Developer, maintains the package there. Thats not true. I do work on that too as is Lionel Elie Mamane and sometimes Matthias Klose (for ARM). Rene is clearly the final judge on contributions and changes to LibreOffice packaging on Debian as he is doing an excellent job there. Best, Bjoern
Re: Extensions hosting
On 1/13/12 4:00 AM, Dave Fisher wrote: Sent from my iPhone On Jan 12, 2012, at 6:18 PM, Ross Gardlerrgard...@opendirective.com wrote: On 12 January 2012 19:01, Dave Fisherdave2w...@comcast.net wrote: Sorry to top post. A distinction exists between extensions.oo.o and extensions.services.oo.o. The first is part of the OOo-site and the second is the service. Thanks Dave. Just so I'm absolutely clear does this change the proposal other than the precise domain names allocated? I'm not sure this distinction had been made before. Specifically is the SF proposal to take both the site and the service? They would be hosting the service domain at extensions.services.oo.o. The ASF hosts extensions.oo.o within www.oo.o/extensions/ Your second mention of e.oo.o makes sense the others should use the services URL. Try the two urls to see what I mean yes that was always a problem and often confusing. For the future I would propose that we drop the page on extensions.openoffice.org and merge the minimal content there with the api.openoffice.org page. Most of the content is already in the wiki anyway. And we should use extensions.openoffice.org as the new Url for extensions.services.openoffice.org. Similar to a proposed change of wiki.services.openoffice.org to wiki.openoffice.org. Where possible we should drop *.services.openoffice.org with *.openoffice.org Juergen
Re: [NIGHTLY BUILD]
On 13.01.2012 09:39, Andre Fischer wrote: On 12.01.2012 22:27, Andrew Rist wrote: Andre , I think one of the fixes you made to main/vcl/Library_vclplug_gtk.mk is breaking the build on the buildbot. see view-source:http://ci.apache.org/projects/openoffice/buildlogs/main/vcl/unxlngx6.pro/misc/logs/prj.txt Sorry about that. I am working on it. Just saw that Arial already fixed this. @Arial: Great work. Thanks for cleaning up my mess. -Andre cd .. make -r -j1 [ clean ] ERROR: Please give only libary basenames to gb_LinkTarget_add_external_libs [ clean ] ERROR: (no prefixes -l% or lib%, no suffixes %.so or %.lib) [ clean ] ERROR: libraries given: -pthread -L/lib -ldbus-glib-1 -ldbus-1 -lpthread -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 [ clean ] ERROR: offending: -ldbus-glib-1 -ldbus-1 -lpthread -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 /home/buildslave19/slave19/openofficeorg-nightly/build/main/vcl/Library_vclplug_gtk.mk:59: *** . Stop. dmake: Error code 2, while making 'all' Andrew
Re: How can I suggest a new component application?
Hi Michael, On 1/13/12 5:52 AM, Michael Acevedo wrote: Hi, I was wondering where I can suggest a new component application for the Apache OpenOffice project? Thanks for your assistance on this matter... you can always start a discussion on such things here on the mailing list. And ideally you find people who like the idea and are willing to help with the realization. But you can't expect that anybody simply does it. That is the same for any feature people would like to see in the project. Juergen
Re: Extensions hosting
Got it - thanks Dave. Ross On 13 January 2012 03:00, Dave Fisher dave2w...@comcast.net wrote: Sent from my iPhone On Jan 12, 2012, at 6:18 PM, Ross Gardler rgard...@opendirective.com wrote: On 12 January 2012 19:01, Dave Fisher dave2w...@comcast.net wrote: Sorry to top post. A distinction exists between extensions.oo.o and extensions.services.oo.o. The first is part of the OOo-site and the second is the service. Thanks Dave. Just so I'm absolutely clear does this change the proposal other than the precise domain names allocated? I'm not sure this distinction had been made before. Specifically is the SF proposal to take both the site and the service? They would be hosting the service domain at extensions.services.oo.o. The ASF hosts extensions.oo.o within www.oo.o/extensions/ Your second mention of e.oo.o makes sense the others should use the services URL. Try the two urls to see what I mean Regards, Dave Ross Regards, Dave Sent from my iPhone On Jan 12, 2012, at 9:34 AM, Ross Gardler rgard...@opendirective.com wrote: I'm attempting to summarise this thread and thus I'm top-posting on the orginal opening thread. I will send the below text to the board for consideration. I'll feedback here after the next board meeting (18th) or sooner if possible. Dear Board, The Apache Open Office project needs to stabilise the hosting of their extensions.openoffice.org service. The code needs updating and bandwidth requirements need to be addressed. Gav, on behalf of the infra team, has offered to move the server to ASF hardware and stabilise the code. Longer term Gav indicated that his desire was to turn the service into a meta-data hosting service whereby extensions could be discovered via extensions.openoffice.,org but hosted in third party locations. This plan requires the hosting non-apache software (including closed source) on ASF hardware. This was approved by the board with responsibility for resolving the IP issues being delegated to the IPMC (http://s.apache.org/fO - members only link). In the meantime Sourceforge have offered to help, initially through an approach to Rob Weir of the AOO project and then through myself. I took this proposal (via infra@ who requested the PPMC bring it to the boards attention) to the AOO dev project for discussion. The thread can be found at http://s.apache.org/sz6 (public) - the first post in that thread includes the proposal from Jeff Drobnick (President and CEO of Geeknet media, it also includes a number of clarifications from Roberto Gallopini of Geeknet. I've tried to summarise for you here. After a long discussion the AOO podling has reached a consensus that the best way forward would be to accept the proposal from Sourceforge as a short term solution whilst working towards the meta-data site for the long term. The PPMC feels that moving the service to a non-ASF host now will minimise disruption for extensions developers and end-users who are unwilling or unable to conform to ASF policy in the long term. Similarly the PPMC feels there is a sufficiently large number of edge cases to make changes in policy more complex than is necessary since it is the PPMCs desire to provide an approved list of extensions which are expected to conform to existing ASF IP policies, whilst also enabling third parties to host their own extensions sites that users can choose to access via a meta-data service. We have assurances from SF that they are not interested in locking the AOO project to their hosted services. Members of the AOO PPMC will have shell access to the system and no attempt will be made by SF to own any of the IP involved. SF reserve the right to serve advertising on the downloads site (and possibly on the extensions site, this needs to be clarified). Downloads would be served from the existing SF mirror network. It is possible for AOO to point to an intermediate page giving users the option of visiting other extensions sites if required. That is extensions.openoffice.org could point to an ASF hosted web page listing multiple third party sites, one of which would be the SF hosted service. Consequently, if necessary it is possible for the PPMC to move hosting to a SF but not to point extensions.openoffice.org there. It is hoped that later releases of AOO will include the ability to search for extensions via a meta-data service managed by the AOO project. At this point extensions.openoffice.org would return to ASF hardware. It is expected that the SF hosted extensions repository will continue to exist and will be one of the first repositories from which users will be able to download non-ASF extensions. This proposal raises a few interesting policy questions. Therefore I would like to ask for guidance on how best to help the AOO project realise this objective. A few questions that come to mind are: Will it be necessary to draw up an MoU with SF? If so what are
Re: Extensions hosting
Hi Ross, sorry for my top posting. I have only one point that is important for me. The hosting aspect of binary extensions and templates is a very important part and we should ensure can we can provide such a service in some way. And here it is not important for our users if it is on Apache servers or any where else. Important is the usage from a user perspective of such a service. It is a huge difference if you put your binary on for example Sourceforge, move to extension.openoffice.org and register your extension with an Url. Or simply upload the binary during the registration on extensions.openoffice.org directly. Keep in mind we have it here to do with experienced users and not always developers. Especially when you think about simply macro collections and templates. Juergen On 1/12/12 6:34 PM, Ross Gardler wrote: I'm attempting to summarise this thread and thus I'm top-posting on the orginal opening thread. I will send the below text to the board for consideration. I'll feedback here after the next board meeting (18th) or sooner if possible. Dear Board, The Apache Open Office project needs to stabilise the hosting of their extensions.openoffice.org service. The code needs updating and bandwidth requirements need to be addressed. Gav, on behalf of the infra team, has offered to move the server to ASF hardware and stabilise the code. Longer term Gav indicated that his desire was to turn the service into a meta-data hosting service whereby extensions could be discovered via extensions.openoffice.,org but hosted in third party locations. This plan requires the hosting non-apache software (including closed source) on ASF hardware. This was approved by the board with responsibility for resolving the IP issues being delegated to the IPMC (http://s.apache.org/fO - members only link). In the meantime Sourceforge have offered to help, initially through an approach to Rob Weir of the AOO project and then through myself. I took this proposal (via infra@ who requested the PPMC bring it to the boards attention) to the AOO dev project for discussion. The thread can be found at http://s.apache.org/sz6 (public) - the first post in that thread includes the proposal from Jeff Drobnick (President and CEO of Geeknet media, it also includes a number of clarifications from Roberto Gallopini of Geeknet. I've tried to summarise for you here. After a long discussion the AOO podling has reached a consensus that the best way forward would be to accept the proposal from Sourceforge as a short term solution whilst working towards the meta-data site for the long term. The PPMC feels that moving the service to a non-ASF host now will minimise disruption for extensions developers and end-users who are unwilling or unable to conform to ASF policy in the long term. Similarly the PPMC feels there is a sufficiently large number of edge cases to make changes in policy more complex than is necessary since it is the PPMCs desire to provide an approved list of extensions which are expected to conform to existing ASF IP policies, whilst also enabling third parties to host their own extensions sites that users can choose to access via a meta-data service. We have assurances from SF that they are not interested in locking the AOO project to their hosted services. Members of the AOO PPMC will have shell access to the system and no attempt will be made by SF to own any of the IP involved. SF reserve the right to serve advertising on the downloads site (and possibly on the extensions site, this needs to be clarified). Downloads would be served from the existing SF mirror network. It is possible for AOO to point to an intermediate page giving users the option of visiting other extensions sites if required. That is extensions.openoffice.org could point to an ASF hosted web page listing multiple third party sites, one of which would be the SF hosted service. Consequently, if necessary it is possible for the PPMC to move hosting to a SF but not to point extensions.openoffice.org there. It is hoped that later releases of AOO will include the ability to search for extensions via a meta-data service managed by the AOO project. At this point extensions.openoffice.org would return to ASF hardware. It is expected that the SF hosted extensions repository will continue to exist and will be one of the first repositories from which users will be able to download non-ASF extensions. This proposal raises a few interesting policy questions. Therefore I would like to ask for guidance on how best to help the AOO project realise this objective. A few questions that come to mind are: Will it be necessary to draw up an MoU with SF? If so what are the key points the board would like to see covered? Will it be sufficient for the PPMC to work with SF to ensure the extensions site they provide respects the existing trademark policy? (bearing in mind that we will eventually be moving extensions.openoffice.org back to ASF hardware)
Re: Moving ahead with the AOO logo and rebranding
On 1/13/12 5:50 AM, Michael Acevedo wrote: Hi again! I added more logo proposals since my last post in this mailing list. Let me know what you think... The logo font is Verdana and uses the seagull orb as the principal part of the branding... On Fri, Jan 6, 2012 at 12:21 AM, Michael Acevedovea...@gmail.com wrote: Greetings, I've made the following logo proposals in the OpenOffice wiki found here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27834483 Hope you like them! what I don't understand is why we not use only one page for logo proposals. That would make it much easier to get an overview and it would of course improve the overall structure in the wiki. Juergen
Re: Seeking Bugzilla Admin Volunteers
On 1/12/2012 14:16, Rob Weir wrote: [snip] So if you want to be on the initial batch, please respond to this note and let me know what your Bugzilla ID is. This is not necessarily the same as your Apache ID. And if you don't yet have a Bugzilla account for the project, you can request one here: https://issues.apache.org/ooo/ Thanks! -Rob Count me in (t...@apache.org) for both permissions and admin. I already have some elevated permissions for Documentation project bugs. I will try to make contact with David McKay, to see if he's still interested. It would be nice to have an admin who actually knows what to do. -- /tj/
Re: [BUILD] License header in map files - Win build breaker
On 13.01.2012 09:52, Ariel Constenla-Haile wrote:
Hi *,
this is a funny build breaker:
cat version.map | awk -f Y:/apache/trunk/main/solenv/bin/getcsym.awk
../../wntmsci12.pro/misc/version_sofficeapp.dxp
awk: Y:/apache/trunk/main/solenv/bin/getcsym.awk:23: (FILENAME=- FNR=7)
fatal: Unmatched ( or \(: /# to you under the Apache License, Version 2.0 (the/
dmake: Error code 2, while making
'../../wntmsci12.pro/misc/version_sofficeapp.dxp'
dmake: '../../wntmsci12.pro/misc/version_sofficeapp.dxp' removed.
ERROR: error 65280 occurred while making
/cygdrive/y/apache/trunk/main/desktop/source/app
It happens while building
desktop/source/app/version.map
desktop/source/pkgchk/unopkg/version.map
The issue is with solenv/bin/getcsym.awk that can't handle an opening
'(' with the closing ')' in the next line, as in the License header:
# to you under the Apache License, Version 2.0 (the
# License); you may not use this file except in compliance
If someone knows awk, please fix solenv/bin/getcsym.awk
getcsysm.awk contains the line
/[ \t]*#/ { sub( substr( $0, index($0, #)), ) }
that matches a #-comment and replaces it with the empty string.
The error is caused by sub() that interprets its first argument as
regexp. Parentheses are special characters in regular expressions which
must only occur in pairs. This is not the case with the
input line
# to you under the Apache License, Version 2.0 (the
Fixed by using the line
/[ \t]*#/ { sub(#.*, ) }
to cut away the comments (SVN revision 1230971)
-Andre
Regards
Re: [BUILD] License header in map files - Win build breaker
On 13.01.2012 09:52, Ariel Constenla-Haile wrote:
Hi *,
this is a funny build breaker:
cat version.map | awk -f Y:/apache/trunk/main/solenv/bin/getcsym.awk
../../wntmsci12.pro/misc/version_sofficeapp.dxp
awk: Y:/apache/trunk/main/solenv/bin/getcsym.awk:23: (FILENAME=- FNR=7)
fatal: Unmatched ( or \(: /# to you under the Apache License, Version 2.0 (the/
dmake: Error code 2, while making
'../../wntmsci12.pro/misc/version_sofficeapp.dxp'
dmake: '../../wntmsci12.pro/misc/version_sofficeapp.dxp' removed.
ERROR: error 65280 occurred while making
/cygdrive/y/apache/trunk/main/desktop/source/app
It happens while building
desktop/source/app/version.map
desktop/source/pkgchk/unopkg/version.map
The issue is with solenv/bin/getcsym.awk that can't handle an opening
'(' with the closing ')' in the next line, as in the License header:
# to you under the Apache License, Version 2.0 (the
# License); you may not use this file except in compliance
If someone knows awk, please fix solenv/bin/getcsym.awk
getcsysm.awk contains the line
/[ \t]*#/ { sub( substr( $0, index($0, #)), ) }
that matches a #-comment and replaces it with the empty string.
The error is caused by sub() that interprets its first argument as
regexp. Parentheses are special characters in regular expressions which
must only occur in pairs. This is not the case with the
input line
# to you under the Apache License, Version 2.0 (the
Fixed by using the line
/[ \t]*#/ { sub(#.*, ) }
to cut away the comments (SVN revision 1230971)
-Andre
Regards
Re: Status of OOo NetBeans Plugin
On 01/13/2012 03:24 AM, Jürgen Schmidt wrote: Hi Carl, thanks for the reminder, I will work with Andrew on this and we can hopefully provide the sources asap. But the plugin will need some maintenance work ;-) I haven't worked on it before, but I use it and would like to update it to NB 7.1 and AOO SDK. Best regards, Carl
Re: [BUILD]solaris build failed again.
Today i try to build failure, it appear this error message. Maybe recently have modified some code about gtk? == [ build LNK ] Library/libvclplug_gtk.so Undefined first referenced symbol in file g_thread_init /UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/CxxObject/vcl/unx/gtk/app/gtkinst.o ld: fatal: symbol referencing errors. No output written to /UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libvclplug_gtk.so make: *** [/UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libvclplug_gtk.so] Error 2 dmake: Error code 2, while making 'all' ---* RULES.MK *--- 1 module(s): vcl need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /UNIX-LAB/ooo/main/vcl/prj When you have fixed the errors in that module you can resume the build by running: build --all:vcl
Re: [BUILD]solaris build failed again.
Hi, you have to update the sources, there was a fix already from Ariel that should solve your problem hopefully Juergen On 1/13/12 12:09 PM, L'oiseau de mer wrote: Today i try to build failure, it appear this error message. Maybe recently have modified some code about gtk? == [ build LNK ] Library/libvclplug_gtk.so Undefined first referenced symbol in file g_thread_init /UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/CxxObject/vcl/unx/gtk/app/gtkinst.o ld: fatal: symbol referencing errors. No output written to /UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libvclplug_gtk.so make: *** [/UNIX-LAB/ooo/main/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libvclplug_gtk.so] Error 2 dmake: Error code 2, while making 'all' ---* RULES.MK *--- 1 module(s): vcl need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /UNIX-LAB/ooo/main/vcl/prj When you have fixed the errors in that module you can resume the build by running: build --all:vcl
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13 January 2012 01:31, Rob Weir robw...@apache.org wrote: On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler rgard...@opendirective.com wrote: It was said in reply to the VP Legal affairs saying That [holding MPL code in SVN] normally is highly discouraged / not allowed. You are putting words in Sam's mouth. The topic there was about forking MPL components, i.e., having an Apache project act as a maintainer of a fork of MPL and doing MPL development. If I am putting words in Sams mouth then I apologise. However, the goal posts appear to be moving here. I thought I was safe quoting from that thread since you referred to it yourself, indicating that it gave approval for what you want to do. It can't be relevant in your defence and not in mine. Are we talking at cross-purposes? ... You might check out this thread for another angle on the subject, also from Sam, dealing with dev tools: http://markmail.org/message/jnuec5saca7wjoue It's interesting that you should refer to that thread. Notice that it is me who started that thread. I spent my personal time on the legal-discuss thread because my position [1] as a mentor was not accepted as being correct by the community. Funny how I find myself in exactly the same position again and again. My original question in that thread was: What I'm interested in at this point is getting an authoritative answer to the specific question of having GPL software in an incubating projects SVN and, subsequently, in a TLPs SVN. This information will feed into the wider discussions about whether having it there is the optimal solution. Note this is about GPL not about MPL. There are similarities but it would be wrong to assume the conclusions there necessarily apply here. However, the policy in question is indeed the same one so some lessons may be drawn from that thread. After a few false starts from other commentators Sam said: One of the purposes of incubation is IP clearance. What that means is that in order to exit incubation the distribution must conform to our policies, which includes not distributing code under the GPL license. Is it the intent to resolve this prior to exiting incubation? Elsewhere in this thread Rob states that the MPL source in question is not in the distribution. Since the ASF *only* distributes source releases I don't really see how this can be the case. If it is true then why is it in our SVN? Furthermore, in my opinion our SVN is a form of distribution (I'm not sure if this view is also held by the VP Legal). Back to the legal-discuss thread. In response to Sams question above I clarified that this was the root cause of the conflicting advice the AOO podling was getting: This is ultimately the question. One view is that the GPL build tool dependency would need to be removed in order to graduate (or would be a separate download from non-ASF hardware). However other advice is that as long as it is not distributed in a release (source or binary) it is OK to have a build dependency on GPL code that is stored on ASF hardware. So, we can see this is a similar issue. It does refer to GPL rather than MPL, so it can (and should) be argued that it is not the same issue. Nevertheless since Rob provides this thread as evidence to support his counter argument to Pedro lets continue... My expectations are that this podling would not successfully graduate with a dependency as you described it. (Sam Ruby) Some more unimportant distractions and I try to bring things back on track with a closing statement: Jurgen has indicated that there is a plan to move away from this GPL code before graduation, however on the dev list this plan has not yet been finalised and my assertion that we do not, as a matter of policy, have GPL code on our servers has been questioned by the OOo community. I was seeking a clarification on this specific case as a test case for other similar issues relating to GPL dependencies that will come up in the near future (in fact have already emerged on the OOo-dev list). I now have the clarification that I needed in order to enable the OOo-dev discussion to proceed (thank you Sam). Note how I explicitly state that this issue was taken to the legal-discuss list as a test case for similar issues. Here we are, revisiting it with a similar case. It's interesting that the advice from the legal team was the same advice I gave in the original contested thread [1]. Finally, for completeness allow me to quote from the part of the thread Rob links to. I'd hate to appear to be ignoring the specific evidence provided: In the short term, everyone agrees that checking the source of this into ASF SVN is not acceptable. (Benson) A statement that was, in my opinion too strong, Sam responded: I for one never said that. If there is a demonstrable need coupled with a credible plan then we could discuss how to address the issue. Sam concludes with Automatically installing GPL code on developer's machines is the issue to be worked.
Re: Extensions hosting
2012/1/13 Jürgen Schmidt jogischm...@googlemail.com: Hi Ross, sorry for my top posting. I have only one point that is important for me. The hosting aspect of binary extensions and templates is a very important part and we should ensure can we can provide such a service in some way. Yes, I think we all (including the board) agree. This is evidenced by their willingness to approve Gavs proposal. Can you please state explicitly whether you perceive a problem with the SF proposal or not. It is my understanding that the consensus here is to accept the SF proposal, it is this that I am seeking advice from the board on. I don't want to open up the whole discussion again, the majority position is certainly to accept the SF proposal. However, if you feel this is a mistake I would like to understand you precise concerns so that I might respond to any questions from the board with maximum clarity. Note the proposal taken to the board is for the SF proposal to be an interim solution with the intention of the AOO project providing a longer term solution more tailored to the needs of the project and its users. Ross
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
Hi Bjoern 2012/1/13 Bjoern Michaelsen bjoern.michael...@canonical.com: Thats not true. I do work on that too as is Lionel Elie Mamane and sometimes Matthias Klose (for ARM). Rene is clearly the final judge on contributions and changes to LibreOffice packaging on Debian as he is doing an excellent job there. Absolutely! I agree with you that René doing an excellent work and he knows all inside the OOo/LibO packaging process! What i (try) say is that we have a small number of people envolved in this process. As you said, are 3 people for a *big* project. Think this 3 people looking *two* bigs projects. IMO, I can't see how. IMHO, we need more people that know the debian package process to maintain AOOo inside Debian. if I maintain a package and its project forked in two, i should choice one branch too. I think that is impossible maintain two enormous packages like AOOo and LibO. And, when Debian drop a package, generally all derivated distros drop too. See the case of Java. Debian dropped java and Ubuntu some days ago. Now, Oracle's Java for ubuntu users only through a ppa repository. And please, my focus is on the lack of people, and not who does the work. Claudio
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
Hi, Le 13 janv. 12 à 10:02, Bjoern Michaelsen a écrit : Hi Claudio, On Thu, Jan 12, 2012 at 06:46:26PM -0200, Claudio Filho wrote: was more easy to migrate to LibO. Today, only René, a Debian Developer, maintains the package there. Thats not true. I do work on that too as is Lionel Elie Mamane and sometimes Matthias Klose (for ARM). Rene is clearly the final judge on contributions and changes to LibreOffice packaging on Debian That's true, Rene is free to create a NEW application, using OpenOffice.org resources. But so far, rename everything LibreOffice in the files concerning OpenOffice.org is not fair. As I wrote, apt-get install openoffice.org should lead to no longer maintained, or something like that, but NOT lead to replaced by LibreOffice or whatever. IMHO, the right decision could have been : - clone openoffice.org source files (all the Debian bazaar , like Control and so on files) - create / declare libreoffice as a NEW application in Debian repos - put openoffice.org in unmaintained or whatever similar status. That's just a personal opinion, but I hope I was clear. If not please ask me and I'll reformulate. as he is doing an excellent job there. Nobody told he didn't and nobody will contest. Since years Rene does a great work for OpenOffice.org and now LibreOffice. Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: Moving ahead with the AOO logo and rebranding
On Friday 13 Jan 2012 17:50:49 Michael Acevedo wrote: Hi again! I added more logo proposals since my last post in this mailing list. Let me know what you think... The logo font is Verdana and uses the seagull orb as the principal part of the branding... On Fri, Jan 6, 2012 at 12:21 AM, Michael Acevedo vea...@gmail.com wrote: Greetings, I've made the following logo proposals in the OpenOffice wiki found here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27834483 Hope you like them! Verdana is a proprietary typeface owned by MS. An open licensed Typeface would be preferred. Cheers GL
Re: Category-B tarballs in SVN (was Re: External libraries)
On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 01:31, Rob Weir robw...@apache.org wrote: On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler rgard...@opendirective.com wrote: It was said in reply to the VP Legal affairs saying That [holding MPL code in SVN] normally is highly discouraged / not allowed. You are putting words in Sam's mouth. The topic there was about forking MPL components, i.e., having an Apache project act as a maintainer of a fork of MPL and doing MPL development. If I am putting words in Sams mouth then I apologise. However, the goal posts appear to be moving here. I thought I was safe quoting from that thread since you referred to it yourself, indicating that it gave approval for what you want to do. It can't be relevant in your defence and not in mine. Are we talking at cross-purposes? I'm trying to develop understanding. To me it appears (and this is my personal opinion only) that you are cobbling together quotes out of context to support an undocumented position. So yes, we are talking at cross-purposes. It might be worth going back to the IPMC discussion from December on concerns about high overhead in Apache incubator releases. There were a lot of good comments, along the lines of: there aren't that many rules so before assuming something really is a rule try to find where its document that it is, and if no one can find that doc then its not a rule. Also, rules are only defined on policy pages so just because some guide type page says something doesn't make it true. or Not everything was written in docs, and still not. Not everything needs to be, as lots is common sense. The email archives are documents. Once one understands the principles of why the ASF as a foundation needs to do certain things, then the so-called rules are obvious consequences. and Enumerate these principles and demonstrate the logical entailment of source releases. That is why it would be particularly useful if you could articulate some reasoning behind your statements, rather than just say something not-very-useful like I am the policy book and claiming some unwritten policy without even defining what that unwritten policy is. If you explain the reasoning, then this and other things should amount to common sense. ... You might check out this thread for another angle on the subject, also from Sam, dealing with dev tools: http://markmail.org/message/jnuec5saca7wjoue It's interesting that you should refer to that thread. Notice that it is me who started that thread. I spent my personal time on the legal-discuss thread because my position [1] as a mentor was not accepted as being correct by the community. Funny how I find myself in exactly the same position again and again. snip I'm really not sure why Rob thinks this thread supports the position that no policy of no copyleft in our servers. I'm sure I must be missing something. I therefore looked back at Pedro's original objection and realise that he his objecting to both a release and graduation. Perhaps this is the point of confusion. You are getting lost in the weeds. The point about that thread, or at least what I hoped would catch your eye, was Sam's statement, which he says in several other threads, so I'd consider it to be something worth understanding as a general rule, is that technical workarounds to ASF policy are not acceptable. Specifically, if something is out of policy for a release, then moving it to another host does not solve the problem. You need to distinguish what the essential problem is, and for that it is unavoidable (IMHO) to go back to the basic questions of what is in a release and what obligations and restrictions does that put on Apache and consumers of our releases. So Pedro's proposal to simply move MPL code to Google Code or whatever solve nothing. And any interpretation of ASF policy that thinks that something real is solved by shuffling code around with not a a single bit's different to the actual releases, is ministerial at best. My support is for Pedro is limited to the graduation point. AOO can do a release from the incubator in this way, but in order to graduate it needs to either get approval for hosting of copyleft code or it needs to remove it. In other words, you agree with me, that this is not a problem for our release. I realize there are additional graduation requirements. There were shorter ways of saying this. As we've said many times before the ASF is not a place where every rule is written down. This has its advantages and its disadvantages. The nearest I can provide is the one you linked to in your mail in the above discussed thread. It can be found at http://www.apache.org/legal/resolved.html#category-b I understand that. That's why I asked if you could not point to a policy, whether you could make a cogent argument for why something like this would be problematic. If you
Re: Seeking Bugzilla Admin Volunteers
On Fri, Jan 13, 2012 at 4:48 AM, tj t...@apache.org wrote: On 1/12/2012 14:16, Rob Weir wrote: [snip] So if you want to be on the initial batch, please respond to this note and let me know what your Bugzilla ID is. This is not necessarily the same as your Apache ID. And if you don't yet have a Bugzilla account for the project, you can request one here: https://issues.apache.org/ooo/ Thanks! -Rob Count me in (t...@apache.org) for both permissions and admin. I already have some elevated permissions for Documentation project bugs. I will try to make contact with David McKay, to see if he's still interested. It would be nice to have an admin who actually knows what to do. I'd consider him as already volunteered per his previous statements. Do you know his Bugzilla ID? -Rob -- /tj/
Re: Extensions hosting
On 1/13/12 12:32 PM, Ross Gardler wrote: 2012/1/13 Jürgen Schmidtjogischm...@googlemail.com: Hi Ross, sorry for my top posting. I have only one point that is important for me. The hosting aspect of binary extensions and templates is a very important part and we should ensure can we can provide such a service in some way. Yes, I think we all (including the board) agree. This is evidenced by their willingness to approve Gavs proposal. Can you please state explicitly whether you perceive a problem with the SF proposal or not. It is my understanding that the consensus here is to accept the SF proposal, it is this that I am seeking advice from the board on. yes i support the SF proposal as well. My point was that in your email to the board this point was not clear enough for me. I don't want to open up the whole discussion again, me too Juergen the majority position is certainly to accept the SF proposal. However, if you feel this is a mistake I would like to understand you precise concerns so that I might respond to any questions from the board with maximum clarity. Note the proposal taken to the board is for the SF proposal to be an interim solution with the intention of the AOO project providing a longer term solution more tailored to the needs of the project and its users. Ross
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
On 1/13/12 1:03 PM, eric b wrote: Hi, Le 13 janv. 12 à 10:02, Bjoern Michaelsen a écrit : Hi Claudio, On Thu, Jan 12, 2012 at 06:46:26PM -0200, Claudio Filho wrote: was more easy to migrate to LibO. Today, only René, a Debian Developer, maintains the package there. Thats not true. I do work on that too as is Lionel Elie Mamane and sometimes Matthias Klose (for ARM). Rene is clearly the final judge on contributions and changes to LibreOffice packaging on Debian That's true, Rene is free to create a NEW application, using OpenOffice.org resources. But so far, rename everything LibreOffice in the files concerning OpenOffice.org is not fair. As I wrote, apt-get install openoffice.org should lead to no longer maintained, or something like that, but NOT lead to replaced by LibreOffice or whatever. IMHO, the right decision could have been : - clone openoffice.org source files (all the Debian bazaar , like Control and so on files) - create / declare libreoffice as a NEW application in Debian repos - put openoffice.org in unmaintained or whatever similar status. That's just a personal opinion, but I hope I was clear. If not please ask me and I'll reformulate. please let us stop this discussion for now, we will address this when we have a release in the appropriate way. The thread started to become off-topic Juergen as he is doing an excellent job there. Nobody told he didn't and nobody will contest. Since years Rene does a great work for OpenOffice.org and now LibreOffice. Regards, Eric
Re: Extensions hosting
2012/1/13 Jürgen Schmidt jogischm...@googlemail.com: On 1/13/12 12:32 PM, Ross Gardler wrote: .. My point was that in your email to the board this point was not clear enough for me. OK. The board are clear in this point. When they discussed the infrastructure proposal Gav asked them to consider JIRA or Hudson without plugins in order to make this point. However, if I see any evidence of this not being understood I'll be sure to correct that. Thanks for flagging. Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13.01.2012 13:31, Rob Weir wrote: On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 01:31, Rob Weirrobw...@apache.org wrote: On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler rgard...@opendirective.com wrote: It was said in reply to the VP Legal affairs saying That [holding MPL code in SVN] normally is highly discouraged / not allowed. You are putting words in Sam's mouth.The topic there was about forking MPL components, i.e., having an Apache project act as a maintainer of a fork of MPL and doing MPL development. If I am putting words in Sams mouth then I apologise. However, the goal posts appear to be moving here. I thought I was safe quoting from that thread since you referred to it yourself, indicating that it gave approval for what you want to do. It can't be relevant in your defence and not in mine. Are we talking at cross-purposes? I'm trying to develop understanding. To me it appears (and this is my personal opinion only) that you are cobbling together quotes out of context to support an undocumented position. So yes, we are talking at cross-purposes. It might be worth going back to the IPMC discussion from December on concerns about high overhead in Apache incubator releases. There were a lot of good comments, along the lines of: there aren't that many rules so before assuming something really is a rule try to find where its document that it is, and if no one can find that doc then its not a rule. Also, rules are only defined on policy pages so just because some guide type page says something doesn't make it true. or Not everything was written in docs, and still not. Not everything needs to be, as lots is common sense. The email archives are documents. Once one understands the principles of why the ASF as a foundation needs to do certain things, then the so-called rules are obvious consequences. and Enumerate these principles and demonstrate the logical entailment of source releases. That is why it would be particularly useful if you could articulate some reasoning behind your statements, rather than just say something not-very-useful like I am the policy book and claiming some unwritten policy without even defining what that unwritten policy is. If you explain the reasoning, then this and other things should amount to common sense. +1 -Andre [...]
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13 January 2012 12:31, Rob Weir robw...@apache.org wrote: On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 01:31, Rob Weir robw...@apache.org wrote: On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler rgard...@opendirective.com wrote: It was said in reply to the VP Legal affairs saying That [holding MPL code in SVN] normally is highly discouraged / not allowed. You are putting words in Sam's mouth. The topic there was about forking MPL components, i.e., having an Apache project act as a maintainer of a fork of MPL and doing MPL development. If I am putting words in Sams mouth then I apologise. However, the goal posts appear to be moving here. I thought I was safe quoting from that thread since you referred to it yourself, indicating that it gave approval for what you want to do. It can't be relevant in your defence and not in mine. Are we talking at cross-purposes? I'm trying to develop understanding. ... That is why it would be particularly useful if you could articulate some reasoning behind your statements OK. The ASF chooses a very permissive licence so as to enable downstream developers of the code to do whatever they want with it. We have strong IP policies to prevent that licence being inadvertently contaminated with more restrictive licenses. One of those policies is to only distribute weak-copyleft in binary form This insistence on weak copyleft is to remove the possibility of an ASF project containing modified code with more restrictive terms. The inclusion of source code in a ASF products is counter to this long held ASF policy. The policy is documented under How should so-called Weak Copyleft Licenses be handled? at http://www.apache.org/legal/resolved.html The question then arises as to whether holding source tarballs in SVN and distributing only binaries with AOO releases is counter to this policy or not. In my opinion it is. I have confirmed this, to my own satisfaction, and provided references to discussions on the topic in this thread. Some argue that this is not the case, or at least is too restrictive for the project. Fine - then go and ask if the policy applies in this case. The advice of your mentor is that it does apply. ... You might check out this thread for another angle on the subject, also from Sam, dealing with dev tools: http://markmail.org/message/jnuec5saca7wjoue It's interesting that you should refer to that thread. Notice that it is me who started that thread. I spent my personal time on the legal-discuss thread because my position [1] as a mentor was not accepted as being correct by the community. Funny how I find myself in exactly the same position again and again. snip I'm really not sure why Rob thinks this thread supports the position that no policy of no copyleft in our servers. I'm sure I must be missing something. I therefore looked back at Pedro's original objection and realise that he his objecting to both a release and graduation. Perhaps this is the point of confusion. You are getting lost in the weeds. The point about that thread, or at least what I hoped would catch your eye, was Sam's statement, which he says in several other threads, so I'd consider it to be something worth understanding as a general rule, is that technical workarounds to ASF policy are not acceptable. Specifically, if something is out of policy for a release, then moving it to another host does not solve the problem. I am not arguing against that point. I'm not sure why you think I am. I make it clear below what my argument is. ... My support is for Pedro is limited to the graduation point. AOO can do a release from the incubator in this way, but in order to graduate it needs to either get approval for hosting of copyleft code or it needs to remove it. In other words, you agree with me, that this is not a problem for our release. I do. I realize there are additional graduation requirements. Good. There were shorter ways of saying this. Ho Hum... Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
It's certainly an edge case, and I'm not completely convinced that I agree with you about it Ross. The ASF's position on svn distributions is that you can put anything in there that you like, provided we have the legal authority to redistribute it. There are no other conditions to my knowledge, which is why we've had GPL code amongst other code in there. - Original Message - From: Ross Gardler rgard...@opendirective.com To: ooo-dev@incubator.apache.org Cc: Sent: Friday, January 13, 2012 8:17 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) On 13 January 2012 12:31, Rob Weir robw...@apache.org wrote: On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 01:31, Rob Weir robw...@apache.org wrote: On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler rgard...@opendirective.com wrote: It was said in reply to the VP Legal affairs saying That [holding MPL code in SVN] normally is highly discouraged / not allowed. You are putting words in Sam's mouth. The topic there was about forking MPL components, i.e., having an Apache project act as a maintainer of a fork of MPL and doing MPL development. If I am putting words in Sams mouth then I apologise. However, the goal posts appear to be moving here. I thought I was safe quoting from that thread since you referred to it yourself, indicating that it gave approval for what you want to do. It can't be relevant in your defence and not in mine. Are we talking at cross-purposes? I'm trying to develop understanding. ... That is why it would be particularly useful if you could articulate some reasoning behind your statements OK. The ASF chooses a very permissive licence so as to enable downstream developers of the code to do whatever they want with it. We have strong IP policies to prevent that licence being inadvertently contaminated with more restrictive licenses. One of those policies is to only distribute weak-copyleft in binary form This insistence on weak copyleft is to remove the possibility of an ASF project containing modified code with more restrictive terms. The inclusion of source code in a ASF products is counter to this long held ASF policy. The policy is documented under How should so-called Weak Copyleft Licenses be handled? at http://www.apache.org/legal/resolved.html The question then arises as to whether holding source tarballs in SVN and distributing only binaries with AOO releases is counter to this policy or not. In my opinion it is. I have confirmed this, to my own satisfaction, and provided references to discussions on the topic in this thread. Some argue that this is not the case, or at least is too restrictive for the project. Fine - then go and ask if the policy applies in this case. The advice of your mentor is that it does apply. ... You might check out this thread for another angle on the subject, also from Sam, dealing with dev tools: http://markmail.org/message/jnuec5saca7wjoue It's interesting that you should refer to that thread. Notice that it is me who started that thread. I spent my personal time on the legal-discuss thread because my position [1] as a mentor was not accepted as being correct by the community. Funny how I find myself in exactly the same position again and again. snip I'm really not sure why Rob thinks this thread supports the position that no policy of no copyleft in our servers. I'm sure I must be missing something. I therefore looked back at Pedro's original objection and realise that he his objecting to both a release and graduation. Perhaps this is the point of confusion. You are getting lost in the weeds. The point about that thread, or at least what I hoped would catch your eye, was Sam's statement, which he says in several other threads, so I'd consider it to be something worth understanding as a general rule, is that technical workarounds to ASF policy are not acceptable. Specifically, if something is out of policy for a release, then moving it to another host does not solve the problem. I am not arguing against that point. I'm not sure why you think I am. I make it clear below what my argument is. ... My support is for Pedro is limited to the graduation point. AOO can do a release from the incubator in this way, but in order to graduate it needs to either get approval for hosting of copyleft code or it needs to remove it. In other words, you agree with me, that this is not a problem for our release. I do. I realize there are additional graduation requirements. Good. There were shorter ways of saying this. Ho Hum... Ross
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
Hi Claudio, On Fri, Jan 13, 2012 at 09:46:05AM -0200, Claudio Filho wrote: Absolutely! I agree with you that René doing an excellent work and he knows all inside the OOo/LibO packaging process! Great to see we agree there! What i (try) say is that we have a small number of people envolved in this process. As you said, are 3 people for a *big* project. Think this 3 people looking *two* bigs projects. IMO, I can't see how. The small number of people involved are not really the problem. The core issue is how bad OpenOffice.org historically was prepared for releases on *nix platforms, requiring huge amounts of fragile workarounds. At LibreOffice a lot of this stuff has already been simplifed upstream, there has been good (invisible to the enduser) progress here. The only reason packaging of OpenOffice.org was sustainable with the given resources for OpenOffice.org was because of the slow developement velocity and longwinding release cycles. Given the progress at LibreOffice, I think the motivation to go back to the messy, wasteful and fragile release process of OpenOffice.org (which is where AOOoI is currently at) is very limited for all current participants (who are all involved in some way in upstream LibreOffice development btw). if I maintain a package and its project forked in two, i should choice one branch too. I think that is impossible maintain two enormous packages like AOOo and LibO. Given that LibreOffice is actively maintained, that OpenOffice.org is dead and Apache OpenOffice (Incubating) has not even released yet, I think there is an obvious conclusion from your statements. Best, Bjoern
Re: Java 7 and Apache OpenOffice
Am 12.01.2012 03:35, schrieb Ariel Constenla-Haile: Thanks for the fix. Could you set up the issue status? https://issues.apache.org/ooo/show_bug.cgi?id=118352 IIRC I resolved as fixed only 2 issues I fixed in order to test the new bugzilla instancia was keeping my can-confirm privileges. Now I'm uncertain about what to do in these cases. In OpenOffice.org times, the developer who fixed the issue didn't resolve it as fixed. Someone else had to do the QA in order to confirm the fix and change the issue status. I'm not sure what the new rules are, so I will wait to resolve this as fixed until someone can confirm it is actually fixed. Regards Due to issue 118352 I've made some tests with AOO and Java 7. Java 7 is detected now by AOO but AOO doesn't support it (see issue 118352). So my conclusion is not to detect it if it's not supported. Regards, Olaf
orw's developer snapshot builds for Windows again ready
Hi, I have created new installation sets of revision 1229435 for Windows. You can find them under http://people.apache.org/~orw/DevSnapshots-Rev.1229535/ in folder win32. Compared to the previous ones I have added language pt-BR, a multi-language set and the SDK. Please try them out. Best regards, Oliver.
Re: Repository for documentation
Hi Juan, On Jan 12, 2012, at 1:29 PM, Juan C. Sanz wrote: In the old infrastructure we used to put the published documentation chapters in a place that we used to call documents settings. Now I can access the documents in this URL http://openoffice.org/downloads/es/. How can I access there to put new documents or update them? Is it the right place to store documents to be linked from web pages or there are a better repository to store them? These files are not yet migrated. The files are still on Oracle's Kenai. We are going to need to make a place. Why not move these to: http://www.openoffice.org/es/downloads/. by adding files to svn at ooo-site/trunk/content/es/downloads/. This looks like an issue for several other NLC projects. I'm not authorized to look at http://openoffice.org/downloads/ just some of the subs. Regards, Dave
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13 January 2012 13:23, Joe Schaefer joe_schae...@yahoo.com wrote: It's certainly an edge case, and I'm not completely convinced that I agree with you about it Ross. The ASF's position on svn distributions is that you can put anything in there that you like, provided we have the legal authority to redistribute it. There are no other conditions to my knowledge, which is why we've had GPL code amongst other code in there. Thanks Joe. It is useful to confirm this is an edge case and thus needs proper guidance (prior to graduation, not prior to release) from legal@ as suggested by Pedro. For the benefit of PPMC understanding there are many factors affecting whether this would be OK, these include, but are not limited to: - is the source modified - is there a good reason not to pull the source from upstream - is there good reason why we don't make binaries available (preferably via upstream) - is the component a required component In general, it is my understanding that, the ASF prefers not to host code that the ASF does not own unless it is the only sensible option. So the question is whether it is the only sensible option. Ross - Original Message - From: Ross Gardler rgard...@opendirective.com To: ooo-dev@incubator.apache.org Cc: Sent: Friday, January 13, 2012 8:17 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) On 13 January 2012 12:31, Rob Weir robw...@apache.org wrote: On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 01:31, Rob Weir robw...@apache.org wrote: On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler rgard...@opendirective.com wrote: It was said in reply to the VP Legal affairs saying That [holding MPL code in SVN] normally is highly discouraged / not allowed. You are putting words in Sam's mouth. The topic there was about forking MPL components, i.e., having an Apache project act as a maintainer of a fork of MPL and doing MPL development. If I am putting words in Sams mouth then I apologise. However, the goal posts appear to be moving here. I thought I was safe quoting from that thread since you referred to it yourself, indicating that it gave approval for what you want to do. It can't be relevant in your defence and not in mine. Are we talking at cross-purposes? I'm trying to develop understanding. ... That is why it would be particularly useful if you could articulate some reasoning behind your statements OK. The ASF chooses a very permissive licence so as to enable downstream developers of the code to do whatever they want with it. We have strong IP policies to prevent that licence being inadvertently contaminated with more restrictive licenses. One of those policies is to only distribute weak-copyleft in binary form This insistence on weak copyleft is to remove the possibility of an ASF project containing modified code with more restrictive terms. The inclusion of source code in a ASF products is counter to this long held ASF policy. The policy is documented under How should so-called Weak Copyleft Licenses be handled? at http://www.apache.org/legal/resolved.html The question then arises as to whether holding source tarballs in SVN and distributing only binaries with AOO releases is counter to this policy or not. In my opinion it is. I have confirmed this, to my own satisfaction, and provided references to discussions on the topic in this thread. Some argue that this is not the case, or at least is too restrictive for the project. Fine - then go and ask if the policy applies in this case. The advice of your mentor is that it does apply. ... You might check out this thread for another angle on the subject, also from Sam, dealing with dev tools: http://markmail.org/message/jnuec5saca7wjoue It's interesting that you should refer to that thread. Notice that it is me who started that thread. I spent my personal time on the legal-discuss thread because my position [1] as a mentor was not accepted as being correct by the community. Funny how I find myself in exactly the same position again and again. snip I'm really not sure why Rob thinks this thread supports the position that no policy of no copyleft in our servers. I'm sure I must be missing something. I therefore looked back at Pedro's original objection and realise that he his objecting to both a release and graduation. Perhaps this is the point of confusion. You are getting lost in the weeds. The point about that thread, or at least what I hoped would catch your eye, was Sam's statement, which he says in several other threads, so I'd consider it to be something worth understanding as a general rule, is that technical workarounds to ASF policy are not acceptable. Specifically, if something is out of policy for a release, then moving it to another host does not solve the problem. I am not arguing
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
Hi, On 13.01.2012 14:25, Bjoern Michaelsen wrote: Hi Claudio, On Fri, Jan 13, 2012 at 09:46:05AM -0200, Claudio Filho wrote: Absolutely! I agree with you that René doing an excellent work and he knows all inside the OOo/LibO packaging process! Great to see we agree there! What i (try) say is that we have a small number of people envolved in this process. As you said, are 3 people for a *big* project. Think this 3 people looking *two* bigs projects. IMO, I can't see how. The small number of people involved are not really the problem. The core issue is how bad OpenOffice.org historically was prepared for releases on *nix platforms, requiring huge amounts of fragile workarounds. At LibreOffice a lot of this stuff has already been simplifed upstream, there has been good (invisible to the enduser) progress here. That is good to hear, maybe we can learn from that improvement. The only reason packaging of OpenOffice.org was sustainable with the given resources for OpenOffice.org was because of the slow developement velocity and longwinding release cycles. I can accept longwinding release cycles but not slow developement velocity. After all Sun/Oracle has been the biggest contributor for OpenOffice. LibreOffice is still integrating features made by Sun/Oracle (it has just been a month or two since my new Impress slide sorter turned up in LibreOffice.) Given the progress at LibreOffice, I think the motivation to go back to the messy, wasteful and fragile release process of OpenOffice.org (which is where AOOoI is currently at) is very limited for all current participants (who are all involved in some way in upstream LibreOffice development btw). You are right that our old release process was not the best. Still, I would choose friendlier words. At Apache OpenOffice we are working to improve on that. Any help from LibreOffice is welcome. if I maintain a package and its project forked in two, i should choice one branch too. I think that is impossible maintain two enormous packages like AOOo and LibO. Given that LibreOffice is actively maintained, that OpenOffice.org is dead and Apache OpenOffice (Incubating) has not even released yet, I think there is an obvious conclusion from your statements. Well, no. After all, OpenOffice.org is not dead. It just got a new home. Regards, Andre Best, Bjoern
Re: Category-B tarballs in SVN (was Re: External libraries)
--- Ven 13/1/12, Jürgen Schmidt jogischm...@googlemail.com ha scritto: that is a very important point and we should keep the practical relevance in mind. I normally build with --with-dmake-url to test this because it is currently very important for people who wants to start building AOO on their own. As long as we haven't switched completely to gnu make. I think it was on Wednesday or so where stumbled over the problem that the mentioned Url to Apache extras was not reachable for a day or at least several hours. That was not really satisfying from a user perspective :-( Network outrages are unfortunate and can happen anywhere. FreeBSD is currently mirroring the files and Debian mirrors carry an older version that works well enough. Pedro. Juergen Another way to think of it is this: the rights and obligations of a downstream consumer are invariant over the choice of where the category-b code is downloaded from. Would you agree with that much? If so, I don't see any basis for a policy distinction purely based on the location of the downloaded code. Pedro.
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
Hi Andre, On Fri, Jan 13, 2012 at 02:54:27PM +0100, Andre Fischer wrote: I can accept longwinding release cycles but not slow developement velocity. After all Sun/Oracle has been the biggest contributor for OpenOffice. LibreOffice is still integrating features made by Sun/Oracle (it has just been a month or two since my new Impress slide sorter turned up in LibreOffice.) Sorry, that wasnt meant to be derogative. I think we can agree upon Sun/Oracle being quite a bit more conservative wrt to how to implement changes, which resulted in a higher overhead to get features completed. A more aggressive use of the developer resources available to Sun/Oracle would have allowed much faster progress. You are right that our old release process was not the best. Still, I would choose friendlier words. I do not intend to offend the developers involved. But the fact that the *.deb files published the OOo website were rarely downloaded and didnt even install without some major tweaking on default installs show that *nix packaging was never a priority at OOo. Well, no. After all, OpenOffice.org is not dead. It just got a new home. The project OpenOffice.org is dead, the trademark obviously survived as it is currently owned by a different project with a different name: Apache OpenOffice (Incubating) Best, Bjoern
Re: Category-B tarballs in SVN (was Re: External libraries)
--- Ven 13/1/12, Andre Fischer a...@a-w-f.de ha scritto: ... I think the issue is very easy to resolve: drop the tarballs from SVN and provide sufficient instructions so that the people doing the builds can download the tarballs themselves: we even have nice fetch_tarball.sh script to do just that. I am not quite sure that I understand the problem here. Well perhaps I can explain it better as I *am* creating source releases for my own personal use. The normal way to build a source releases is to pull the code from SVN (as described in the web page). This will download category-A and Category-B software. Category-B is not built by default but it is in the same directory with Category-A software so I don't find a clear separation. Technically, we are indeed forking the mozilla code: we carry the source tarballs and patches, so we indeed have our own distributions here and that is a legal gray area. FWIW, I use saxon prepackaged already an I will likely be using theprepackaged beanshell so I don't need those tarballs. Seamonkey takes too long to build and nss involves security risks so this just adds bloat to my sources. Would it be OK to move the category-b tar balls to eg SourceForge or Google and just adapt the URL in the ooo.lst file? I was thinking we should point users directly to the mozilla foundation but I think an external site would effectively solve the Category-B issues. All just IMHO. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13 January 2012 14:43, Rob Weir robw...@apache.org wrote: ... If I were on the IPMC, and AOO came up for graduation, I wouldn't be too concerned out the MPL license category being in SVN, so long as the releases were in policy and so long as the PPMC could demonstrate how they are addressing good practices related to code segregation, etc. Can someone please explain why it is necessary to have the code here at all? Why is it not pulled from the upstream project? Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Hello; --- Ven 13/1/12, Joe Schaefer joe_schae...@yahoo.com ha scritto: It's certainly an edge case, and I'm not completely convinced that I agree with you about it Ross. The ASF's position on svn distributions is that you can put anything in there that you like, provided we have the legal authority to redistribute it. There are no other conditions to my knowledge, which is why we've had GPL code amongst other code in there. I for one signed an iCLA and considering section 7, I wouldn't go ahead and commit copyleft content to SVN without discussing it carefully. Rob has gone unilaterally about declaring what he thinks as a known truth and assuming because he wrote it on a wiki and no one has complained then it is the one true way (TM). In his defense I have to say he did ask the right questions but he didn't get concrete answers. I think Andrea Pescetti has given us a lesson on how things are done. Who knows, I think if Rob does a well thought proposal to legal@ and we all give our feedback concerning the shortcomings or relative virtues of this approach we may get to something. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Why hasn't there been a LEGAL jira issue filed about this at this point? As I said it's a gray area that I'm certain the IPMC has no existing governing policy on, and I'm also certain that your mentors will disagree in the opinions they are providing to you. As a practical matter, I doubt the legal team will express anything other than a preference, deferring the policy question to the IPMC. So if you are dissatisfied with their preference, the nexthoop to jump thru is general@incubator, where Ross' already-provided opinion is what I'd bet the majority will agree with. Good luck. From: Pedro Giffuni p...@apache.org To: ooo-dev@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Sent: Friday, January 13, 2012 9:52 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) Hello; --- Ven 13/1/12, Joe Schaefer joe_schae...@yahoo.com ha scritto: It's certainly an edge case, and I'm not completely convinced that I agree with you about it Ross. The ASF's position on svn distributions is that you can put anything in there that you like, provided we have the legal authority to redistribute it. There are no other conditions to my knowledge, which is why we've had GPL code amongst other code in there. I for one signed an iCLA and considering section 7, I wouldn't go ahead and commit copyleft content to SVN without discussing it carefully. Rob has gone unilaterally about declaring what he thinks as a known truth and assuming because he wrote it on a wiki and no one has complained then it is the one true way (TM). In his defense I have to say he did ask the right questions but he didn't get concrete answers. I think Andrea Pescetti has given us a lesson on how things are done. Who knows, I think if Rob does a well thought proposal to legal@ and we all give our feedback concerning the shortcomings or relative virtues of this approach we may get to something. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
--- Ven 13/1/12, Ross Gardler rgard...@opendirective.com ha scritto: ... Can someone please explain why it is necessary to have the code here at all? Why is it not pulled from the upstream project? It is there only for convenience: to make it easier to fetch and maintain. I think it's pretty clear we don't strictly need it under version control. At SUN/Oracle it was kept in another repository. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
On Fri, Jan 13, 2012 at 9:50 AM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 14:43, Rob Weir robw...@apache.org wrote: ... If I were on the IPMC, and AOO came up for graduation, I wouldn't be too concerned out the MPL license category being in SVN, so long as the releases were in policy and so long as the PPMC could demonstrate how they are addressing good practices related to code segregation, etc. Can someone please explain why it is necessary to have the code here at all? Why is it not pulled from the upstream project? The particular reasons why this is necessary would be on a case-by-case basis. But here is the general reason why it is a good idea for any 3rd party component: A fundamental principle of software design: Never depend on a component less stable than you. URL's change. Projects fold. Corporations divest from open source projects. Websites get hacked and source code changed. If we really want to be able to reliably build and maintain AOO, and allow downstream providers to do the same, then we need to have archival copies of all 3rd party components we depend on (or at least the major ones), and to keep then versioned and associated with our release branches. This is the same reason Apache has its own mailing list archive and its own URL shortener. Having control over these assets, from an archival standpoint, is critical. This does not mean that we should be developing such software at Apache. It just means that the ability to maintain this software is only as reliable as our ability to retrieve any third party components it relies on, regardless of license. I don't think the above is a policy question, but a technical one that each PMC should be evaluating on its own. OpenOffice, an 11 year old project, with many years ahead of it, has relevant experience in this area. We've already outlived at least one upstream component. Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
If you are asking me (and only me); --- Ven 13/1/12, Joe Schaefer joe_schae...@yahoo.com ha scritto: Why hasn't there been a LEGAL jira issue filed about this at this point? As I said it's a gray area that I'm certain the IPMC has no existing governing policy on, and I'm also certain that your mentors will disagree in the opinions they are providing to you. I don't like gray areas: I think we should comply crystal clear with Apache policies and solve this beyond doubt. As I said before, the solution is easy: dropping the files from SVN and providing sufficient instructions on where to get them. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Perfectly valid answer with one caveat: I don't know of any Apache policy that directly applies here. I'd bet that if httpd had what it considered a valid reason for including the source of a Category-B licensed product in their svn tree, nobody, not even the board, would have grounds to object, especially not if they'd passed the issue off to LEGAL and didn't receive a negative response. From: Pedro Giffuni p...@apache.org To: ooo-dev@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Sent: Friday, January 13, 2012 10:08 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) If you are asking me (and only me); --- Ven 13/1/12, Joe Schaefer joe_schae...@yahoo.com ha scritto: Why hasn't there been a LEGAL jira issue filed about this at this point? As I said it's a gray area that I'm certain the IPMC has no existing governing policy on, and I'm also certain that your mentors will disagree in the opinions they are providing to you. I don't like gray areas: I think we should comply crystal clear with Apache policies and solve this beyond doubt. As I said before, the solution is easy: dropping the files from SVN and providing sufficient instructions on where to get them. Pedro.
Re: Java 7 and Apache OpenOffice
2012.01.13. 14:30 keltezéssel, O.Felka írta: Am 12.01.2012 03:35, schrieb Ariel Constenla-Haile: Thanks for the fix. Could you set up the issue status? https://issues.apache.org/ooo/show_bug.cgi?id=118352 IIRC I resolved as fixed only 2 issues I fixed in order to test the new bugzilla instancia was keeping my can-confirm privileges. Now I'm uncertain about what to do in these cases. In OpenOffice.org times, the developer who fixed the issue didn't resolve it as fixed. Someone else had to do the QA in order to confirm the fix and change the issue status. I'm not sure what the new rules are, so I will wait to resolve this as fixed until someone can confirm it is actually fixed. Regards Due to issue 118352 I've made some tests with AOO and Java 7. Java 7 is detected now by AOO but AOO doesn't support it (see issue 118352). So my conclusion is not to detect it if it's not supported. Regards, Olaf Try orw's build it works with java 1.7. : http://people.apache.org/~orw/ Regards, Zoltan
Re: Category-B tarballs in SVN (was Re: External libraries)
For what it is worth, I agree with Joe here. The question is whether there is a valid reason to keep them here. Ross Sent from my mobile device, please forgive errors and brevity. On Jan 13, 2012 3:13 PM, Joe Schaefer joe_schae...@yahoo.com wrote: Perfectly valid answer with one caveat: I don't know of any Apache policy that directly applies here. I'd bet that if httpd had what it considered a valid reason for including the source of a Category-B licensed product in their svn tree, nobody, not even the board, would have grounds to object, especially not if they'd passed the issue off to LEGAL and didn't receive a negative response. From: Pedro Giffuni p...@apache.org To: ooo-dev@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Sent: Friday, January 13, 2012 10:08 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) If you are asking me (and only me); --- Ven 13/1/12, Joe Schaefer joe_schae...@yahoo.com ha scritto: Why hasn't there been a LEGAL jira issue filed about this at this point? As I said it's a gray area that I'm certain the IPMC has no existing governing policy on, and I'm also certain that your mentors will disagree in the opinions they are providing to you. I don't like gray areas: I think we should comply crystal clear with Apache policies and solve this beyond doubt. As I said before, the solution is easy: dropping the files from SVN and providing sufficient instructions on where to get them. Pedro.
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
On 13.01.2012 15:37, Bjoern Michaelsen wrote: Hi Andre, On Fri, Jan 13, 2012 at 02:54:27PM +0100, Andre Fischer wrote: I can accept longwinding release cycles but not slow developement velocity. After all Sun/Oracle has been the biggest contributor for OpenOffice. LibreOffice is still integrating features made by Sun/Oracle (it has just been a month or two since my new Impress slide sorter turned up in LibreOffice.) Sorry, that wasnt meant to be derogative. I think we can agree upon Sun/Oracle being quite a bit more conservative wrt to how to implement changes, which resulted in a higher overhead to get features completed. Yes, as well as a higher code quality. A more aggressive use of the developer resources available to Sun/Oracle would have allowed much faster progress. I disagree. The same number of people would not have written more code. Of course, we could have released more often, but in the long run we would have produced the same amount of features and bug fixes. You are right that our old release process was not the best. Still, I would choose friendlier words. I do not intend to offend the developers involved. But the fact that the *.deb files published the OOo website were rarely downloaded and didnt even install without some major tweaking on default installs show that *nix packaging was never a priority at OOo. This may be one reason but it is certainly not the only one. OpenOffice is (today in the form of LibreOffice) included in all major Linux distributions. There is no need for the average user to download and install it again. Well, no. After all, OpenOffice.org is not dead. It just got a new home. The project OpenOffice.org is dead, the trademark obviously survived as it is currently owned by a different project with a different name: Apache OpenOffice (Incubating) Again, I disagree. Oracle gave the source code to the Apache Foundation to continue work on OpenOffice. Some time ago we at Apache voted on a name change and to drop the .org. But Apache has taken over the original code, the infrastructure, and a part of the community. So I personally think of OpenOffice under the ASF to be the continuation of OpenOffice under Oracle. And there is a lot of work going on to produce the first release of Apache OpenOffice, which will likely attract more people to join the Apache community. Regards, Andre
Re: Category-B tarballs in SVN (was Re: External libraries)
On 1/13/12 3:42 PM, Pedro Giffuni wrote: --- Ven 13/1/12, Andre Fischera...@a-w-f.de ha scritto: ... I think the issue is very easy to resolve: drop the tarballs from SVN and provide sufficient instructions so that the people doing the builds can download the tarballs themselves: we even have nice fetch_tarball.sh script to do just that. I am not quite sure that I understand the problem here. Well perhaps I can explain it better as I *am* creating source releases for my own personal use. The normal way to build a source releases is to pull the code from SVN (as described in the web page). This will download category-A and Category-B software. Category-B is not built by default but it is in the same directory with Category-A software so I don't find a clear separation. well that is a valid point that comes into my mind as well when I have read the mails and thought a little bit longer. If that is the only reason than we can move it besides trunk. But that is a technical solution only and it doesn't solve the underlying problem. And what is more important we can't exchange everything now and we can't remove all the features that depends on this category-b stuff. Otherwise the office is no longer useable and we can stop here or can kill the project directly. Or we take it serious and find compromises and exchange stuff over time when possible. Apache got for whatever reason the source grant and the trademarks of one of the biggest and most successful open source projects. So far so good. Normally I would expect the organization would be happy and would do everything that this project can continue in the way as before. Yes there are changes necessary and again we are working on it but we can't do everything at once ... The whole discussion is not really motivating for project members and of course does not really promote the Apache way or the ASF in general. Technically, we are indeed forking the mozilla code: we carry the source tarballs and patches, so we indeed have our own distributions here and that is a legal gray area. maybe but again we don't have any other chance here right now. We can only work on it in the future and can try to replace it by newer code. But we need somebody who can do that, it's far from trivial. FWIW, I use saxon prepackaged already an I will likely be using theprepackaged beanshell so I don't need those tarballs. Seamonkey takes too long to build and nss involves security risks so this just adds bloat to my sources. it's your personal opinion and many users simply rely on these features and use it. Your are on FreeBSD a minor platform that has no real relevance for the user base of OpenOffice. So we always have to take Windows into account and on Windows you don't have system libraries for this stuff. So please come back to reality. Juergen PS who will go demotivated into the weekend Would it be OK to move the category-b tar balls to eg SourceForge or Google and just adapt the URL in the ooo.lst file? I was thinking we should point users directly to the mozilla foundation but I think an external site would effectively solve the Category-B issues. All just IMHO. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Your mentors would prefer to treat the members of this podling as a group of adults, and if given compelling reasons to do unusual things in this podling will often avoid telling you otherwise. But if people insist on infighting and backbiting each other about differences of opinions, we'll just shut up and wait for more intelligent emails to emerge. I've given the group my opinion on how to proceed on this issue if the consensus of the PPMC is to continue including Category-B sources in its svn tree. Please don't make me think I've wasted my time in providing that opinion. From: Jürgen Schmidt jogischm...@googlemail.com To: ooo-dev@incubator.apache.org Sent: Friday, January 13, 2012 10:32 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) On 1/13/12 3:42 PM, Pedro Giffuni wrote: --- Ven 13/1/12, Andre Fischera...@a-w-f.de ha scritto: ... I think the issue is very easy to resolve: drop the tarballs from SVN and provide sufficient instructions so that the people doing the builds can download the tarballs themselves: we even have nice fetch_tarball.sh script to do just that. I am not quite sure that I understand the problem here. Well perhaps I can explain it better as I *am* creating source releases for my own personal use. The normal way to build a source releases is to pull the code from SVN (as described in the web page). This will download category-A and Category-B software. Category-B is not built by default but it is in the same directory with Category-A software so I don't find a clear separation. well that is a valid point that comes into my mind as well when I have read the mails and thought a little bit longer. If that is the only reason than we can move it besides trunk. But that is a technical solution only and it doesn't solve the underlying problem. And what is more important we can't exchange everything now and we can't remove all the features that depends on this category-b stuff. Otherwise the office is no longer useable and we can stop here or can kill the project directly. Or we take it serious and find compromises and exchange stuff over time when possible. Apache got for whatever reason the source grant and the trademarks of one of the biggest and most successful open source projects. So far so good. Normally I would expect the organization would be happy and would do everything that this project can continue in the way as before. Yes there are changes necessary and again we are working on it but we can't do everything at once ... The whole discussion is not really motivating for project members and of course does not really promote the Apache way or the ASF in general. Technically, we are indeed forking the mozilla code: we carry the source tarballs and patches, so we indeed have our own distributions here and that is a legal gray area. maybe but again we don't have any other chance here right now. We can only work on it in the future and can try to replace it by newer code. But we need somebody who can do that, it's far from trivial. FWIW, I use saxon prepackaged already an I will likely be using theprepackaged beanshell so I don't need those tarballs. Seamonkey takes too long to build and nss involves security risks so this just adds bloat to my sources. it's your personal opinion and many users simply rely on these features and use it. Your are on FreeBSD a minor platform that has no real relevance for the user base of OpenOffice. So we always have to take Windows into account and on Windows you don't have system libraries for this stuff. So please come back to reality. Juergen PS who will go demotivated into the weekend Would it be OK to move the category-b tar balls to eg SourceForge or Google and just adapt the URL in the ooo.lst file? I was thinking we should point users directly to the mozilla foundation but I think an external site would effectively solve the Category-B issues. All just IMHO. Pedro.
Re: Java 7 and Apache OpenOffice
2012.01.13. 16:43 keltezéssel, O.Felka írta: Am 13.01.2012 16:21, schrieb Reizinger Zoltán: 2012.01.13. 14:30 keltezéssel, O.Felka írta: Am 12.01.2012 03:35, schrieb Ariel Constenla-Haile: Thanks for the fix. Could you set up the issue status? https://issues.apache.org/ooo/show_bug.cgi?id=118352 IIRC I resolved as fixed only 2 issues I fixed in order to test the new bugzilla instancia was keeping my can-confirm privileges. Now I'm uncertain about what to do in these cases. In OpenOffice.org times, the developer who fixed the issue didn't resolve it as fixed. Someone else had to do the QA in order to confirm the fix and change the issue status. I'm not sure what the new rules are, so I will wait to resolve this as fixed until someone can confirm it is actually fixed. Regards Due to issue 118352 I've made some tests with AOO and Java 7. Java 7 is detected now by AOO but AOO doesn't support it (see issue 118352). So my conclusion is not to detect it if it's not supported. Regards, Olaf Try orw's build it works with java 1.7. : http://people.apache.org/~orw/ Regards, Zoltan It's the same with the builds of Olive: Java 7 has been detected but the Wizard doesn't work. Regards, Olaf It shows a debug messeage: Debug Output --- Error: SfxHTMLParser::SfxHTMLParser: Wo kommt der ZS her? From File c:/AOO/sources/firsttasks/main/sfx2/source/bastyp/sfxhtml.cxx at Line 79 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Click no, then second debug error: --- Debug Output --- Error: Don't close the medium when loading documents! From File c:/AOO/sources/firsttasks/main/sfx2/source/doc/objmisc.cxx at Line 1444 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Click No, the wizard starts. May be the debug allowed switch was set and they created a debug version of AOO. Regards, Zoltan
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13.01.2012 16:25, Ross Gardler wrote: For what it is worth, I agree with Joe here. The question is whether there is a valid reason to keep them here. I don't know if the reasons are valid. We are trying to find a pragmatical solution that is a good compromise for the different requirements of the ASF, the OpenOffice developers/community, and the OpenOffice users: - For the ASF we use no code under category X license and try to use as little code under category B license. - For the users we want to retain as many features as possible. - For the developers we want to make development as accessible as possible. We should also keep in mind that, compared to before the transition from Oracle to Apache, at the moment there are only a few developers working on the code: - Every category B project that is removed will lead to missing features because we do not have the resources to replace it. - Loading the cat B tar balls from their home servers a) is not always possible (eg because the version we use is no longer available, or the server is not reliable or can not handle the load) b) will make setting up of a development environment more difficult and may scare away new developers c) does not solve the underlying legal problems anyway (as far as I understand the discussion so far) [...] I think that we should try to work an a pragmatical compromise. We should also keep our users in mind, which do not have a voice in this discussion. An who may not be too interested in licenses and policies. Regards, Andre
Re: Java 7 and Apache OpenOffice
Am 13.01.2012 16:55, schrieb Reizinger Zoltán: 2012.01.13. 16:43 keltezéssel, O.Felka írta: Am 13.01.2012 16:21, schrieb Reizinger Zoltán: 2012.01.13. 14:30 keltezéssel, O.Felka írta: Am 12.01.2012 03:35, schrieb Ariel Constenla-Haile: Thanks for the fix. Could you set up the issue status? https://issues.apache.org/ooo/show_bug.cgi?id=118352 IIRC I resolved as fixed only 2 issues I fixed in order to test the new bugzilla instancia was keeping my can-confirm privileges. Now I'm uncertain about what to do in these cases. In OpenOffice.org times, the developer who fixed the issue didn't resolve it as fixed. Someone else had to do the QA in order to confirm the fix and change the issue status. I'm not sure what the new rules are, so I will wait to resolve this as fixed until someone can confirm it is actually fixed. Regards Due to issue 118352 I've made some tests with AOO and Java 7. Java 7 is detected now by AOO but AOO doesn't support it (see issue 118352). So my conclusion is not to detect it if it's not supported. Regards, Olaf Try orw's build it works with java 1.7. : http://people.apache.org/~orw/ Regards, Zoltan It's the same with the builds of Olive: Java 7 has been detected but the Wizard doesn't work. Regards, Olaf It shows a debug messeage: Debug Output --- Error: SfxHTMLParser::SfxHTMLParser: Wo kommt der ZS her? From File c:/AOO/sources/firsttasks/main/sfx2/source/bastyp/sfxhtml.cxx at Line 79 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Click no, then second debug error: --- Debug Output --- Error: Don't close the medium when loading documents! From File c:/AOO/sources/firsttasks/main/sfx2/source/doc/objmisc.cxx at Line 1444 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Click No, the wizard starts. May be the debug allowed switch was set and they created a debug version of AOO. Regards, Zoltan I don't get a debug output. Just a message box that says that the selected JRE is defective and I should choose another one. Regards, Olaf
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13.01.2012 15:59, Pedro Giffuni wrote: --- Ven 13/1/12, Ross Gardlerrgard...@opendirective.com ha scritto: ... Can someone please explain why it is necessary to have the code here at all? Why is it not pulled from the upstream project? It is there only for convenience: to make it easier to fetch and maintain. Agreed. I think it's pretty clear we don't strictly need it under version control. At SUN/Oracle it was kept in another repository. Yes, in fact there are technical reasons for not putting it under SVN: - its mostly binary code for which SVN can not provide diffs - it does not change very frequently - if it does we do not need the old versions any more. But, as I have read many times now, it does not matter much where the tar balls are placed, as long as it is an Apache Server. As long as that is true I opt for the convenience of putting them into ext_sources/ -Andre Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Sent from my mobile device, please forgive errors and brevity. On Jan 13, 2012 4:02 PM, Andre Fischer a...@a-w-f.de wrote: On 13.01.2012 16:25, Ross Gardler wrote: For what it is worth, I agree with Joe here. The question is whether there is a valid reason to keep them here. I don't know if the reasons are valid. We are trying to find a pragmatical solution that is a good compromise for the different requirements of the ASF, the OpenOffice developers/community, and the OpenOffice users: - For the ASF we use no code under category X license and try to use as little code under category B license. - For the users we want to retain as many features as possible. - For the developers we want to make development as accessible as possible. Why is it necessary to include source rather than just binaries? Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
From: Andre Fischer a...@a-w-f.de To: ooo-dev@incubator.apache.org Sent: Friday, January 13, 2012 11:09 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) On 13.01.2012 15:59, Pedro Giffuni wrote: --- Ven 13/1/12, Ross Gardlerrgard...@opendirective.com ha scritto: ... Can someone please explain why it is necessary to have the code here at all? Why is it not pulled from the upstream project? It is there only for convenience: to make it easier to fetch and maintain. Agreed. I think it's pretty clear we don't strictly need it under version control. At SUN/Oracle it was kept in another repository. Yes, in fact there are technical reasons for not putting it under SVN: - its mostly binary code for which SVN can not provide diffs - it does not change very frequently - if it does we do not need the old versions any more. But, as I have read many times now, it does not matter much where the tar balls are placed, as long as it is an Apache Server. As long as that is true I opt for the convenience of putting them into ext_sources/ I'm not sure the IPMC will be sympathetic to the idea that this is done solely for the sake of convenience. ASF's buildbot for instance is capable of downloading source dependencies prior to building the software, and you could even make it part of the build scripts to download Category-B sources before building them as part of AOO builds. The IPMC tends to want compliance with what it considers best practice for its podlings, and if that's not able to be met, clear and compelling reasons for an alternative solution will be expected. But you're on the right track in first determining what the actual consensus of the PPMC is. Please continue...
Re: Category-B tarballs in SVN (was Re: External libraries)
- Original Message - From: Ross Gardler rgard...@opendirective.com To: ooo-dev@incubator.apache.org Cc: Sent: Friday, January 13, 2012 11:15 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) Sent from my mobile device, please forgive errors and brevity. On Jan 13, 2012 4:02 PM, Andre Fischer a...@a-w-f.de wrote: On 13.01.2012 16:25, Ross Gardler wrote: For what it is worth, I agree with Joe here. The question is whether there is a valid reason to keep them here. I don't know if the reasons are valid. We are trying to find a pragmatical solution that is a good compromise for the different requirements of the ASF, the OpenOffice developers/community, and the OpenOffice users: - For the ASF we use no code under category X license and try to use as little code under category B license. - For the users we want to retain as many features as possible. - For the developers we want to make development as accessible as possible. Why is it necessary to include source rather than just binaries? The likely reason is that binaries aren't readily downloadable for all the specific platforms AOO intends to support.
Re: Category-B tarballs in SVN (was Re: External libraries)
On Fri, Jan 13, 2012 at 11:15 AM, Ross Gardler rgard...@opendirective.com wrote: Sent from my mobile device, please forgive errors and brevity. On Jan 13, 2012 4:02 PM, Andre Fischer a...@a-w-f.de wrote: On 13.01.2012 16:25, Ross Gardler wrote: For what it is worth, I agree with Joe here. The question is whether there is a valid reason to keep them here. I don't know if the reasons are valid. We are trying to find a pragmatical solution that is a good compromise for the different requirements of the ASF, the OpenOffice developers/community, and the OpenOffice users: - For the ASF we use no code under category X license and try to use as little code under category B license. - For the users we want to retain as many features as possible. - For the developers we want to make development as accessible as possible. Why is it necessary to include source rather than just binaries? With C/C++ code, binaries are built from source, and the source has to come from somewhere. If there is a need to fix a security problem, we need ready access to the source. The binaries alone would not be sufficient. Also look at this from the perspective of a downstream consumer who is porting the product to another platform. The binaries would be of zero use to them,since the binaries would not be compiled for their platform. But having the source archives for the dependencies readily available, that is exactly what a porter would need. Ross
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
Andre Fischer wrote: Yes, as well as a higher code quality. Metrics please, or didn't happen! ;) Cheers from the off, -- Thorsten pgpGf0wXp2F6G.pgp Description: PGP signature
Re: Java 7 and Apache OpenOffice
2012.01.13. 17:21 keltezéssel, O.Felka írta: Am 13.01.2012 17:18, schrieb Reizinger Zoltán: 2012.01.13. 17:06 keltezéssel, O.Felka írta: Am 13.01.2012 16:55, schrieb Reizinger Zoltán: 2012.01.13. 16:43 keltezéssel, O.Felka írta: Am 13.01.2012 16:21, schrieb Reizinger Zoltán: 2012.01.13. 14:30 keltezéssel, O.Felka írta: Am 12.01.2012 03:35, schrieb Ariel Constenla-Haile: Thanks for the fix. Could you set up the issue status? https://issues.apache.org/ooo/show_bug.cgi?id=118352 IIRC I resolved as fixed only 2 issues I fixed in order to test the new bugzilla instancia was keeping my can-confirm privileges. Now I'm uncertain about what to do in these cases. In OpenOffice.org times, the developer who fixed the issue didn't resolve it as fixed. Someone else had to do the QA in order to confirm the fix and change the issue status. I'm not sure what the new rules are, so I will wait to resolve this as fixed until someone can confirm it is actually fixed. Regards Due to issue 118352 I've made some tests with AOO and Java 7. Java 7 is detected now by AOO but AOO doesn't support it (see issue 118352). So my conclusion is not to detect it if it's not supported. Regards, Olaf Try orw's build it works with java 1.7. : http://people.apache.org/~orw/ Regards, Zoltan It's the same with the builds of Olive: Java 7 has been detected but the Wizard doesn't work. Regards, Olaf It shows a debug messeage: Debug Output --- Error: SfxHTMLParser::SfxHTMLParser: Wo kommt der ZS her? From File c:/AOO/sources/firsttasks/main/sfx2/source/bastyp/sfxhtml.cxx at Line 79 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Click no, then second debug error: --- Debug Output --- Error: Don't close the medium when loading documents! From File c:/AOO/sources/firsttasks/main/sfx2/source/doc/objmisc.cxx at Line 1444 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Click No, the wizard starts. May be the debug allowed switch was set and they created a debug version of AOO. Regards, Zoltan I don't get a debug output. Just a message box that says that the selected JRE is defective and I should choose another one. Regards, Olaf May be we use different OS, I run under Windows 7. Regards, Zoltan I'm using this Office http://people.apache.org/~orw/DevSnapshots-Rev.1229535/win32/OOo-Dev_OOO340m1_Win_x86_install_de.exe on WinXP - SP3. Regards, Olaf I'm using http://people.apache.org/~orw/DevSnapshots-Rev.1229535/win32/OOo-Dev_OOO340m1_Win_x86_install_en-US.exe Regards, Zoltan
Re: Category-B tarballs in SVN (was Re: External libraries)
Please do not step down from the PPMC Pedro, you have done good work here and it is very important that the PPMC consist of such people going forward. Creating a class of active committers who are not on the PPMC will not help move this project closer to graduation. Let's please avoid that circumstance over what appears to be a simple disagreement. - Original Message - From: Pedro Giffuni p...@apache.org To: ooo-dev@incubator.apache.org Cc: Sent: Friday, January 13, 2012 11:31 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) --- Ven 13/1/12, Jürgen Schmidt ha scritto: ... well that is a valid point that comes into my mind as well when I have read the mails and thought a little bit longer. If that is the only reason than we can move it besides trunk. But that is a technical solution only and it doesn't solve the underlying problem. And what is more important we can't exchange everything now and we can't remove all the features that depends on this category-b stuff. Otherwise the office is no longer useable and we can stop here or can kill the project directly. I am only asking for the technical solution. I think we have discussed sufficiently that replacing this stuff is possible but will take time. I am also not setting any time frame for moving those files. beyond that we should do it somewhen before release. The whole discussion is not really motivating for project members and of course does not really promote the Apache way or the ASF in general. I agree it's not very motivating but in my defense it was something that had to be discussed sooner better than later. So we always have to take Windows into account and on Windows you don't have system libraries for this stuff. We can do packages of this stuff. It will even save time from building over and over again the same stuff. So please come back to reality. Juergen PS who will go demotivated into the weekend OK, this is something I really didn't intend. This was meant to be discussed on a strictly technical level without demotivating developers or calling bloody murder on the project. I hereby drop *any* claim that we may not be complying with any relevant policy. Also to give full assurance that I will not be problem to the project I will be stepping down from the PPMC so my vote will not be binding: I am really only interested in technical discussions anyway. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Hello Joe; --- Ven 13/1/12, Joe Schaefer joe_schae...@yahoo.com ha scritto: Please do not step down from the PPMC Pedro, you have done good work here and it is very important that the PPMC consist of such people going forward. Creating a class of active committers who are not on the PPMC will not help move this project closer to graduation. Let's please avoid that circumstance over what appears to be a simple disagreement. It is a simple disagreement but I happen to feel exactly like Juergen about this. There is an interesting, and rather funny, theory to explain this situation and technically speaking we are in a region of stupidity: http://cantrip.org/stupidity.html At this time it is better to leave such region so I am willing to drop this discussion entirely. If things come to vote I do have to be consistent with what I think and it would probably be better to the to avoid me causing conflicts, but I will better take such a decision with a clear head and not now. Pedro.
Re: Status of OOo NetBeans Plugin
Where should we check it in? If there is a consensus on the location, I'll check it in and change the headers... A. On 1/13/2012 12:24 AM, Jürgen Schmidt wrote: Hi Carl, thanks for the reminder, I will work with Andrew on this and we can hopefully provide the sources asap. But the plugin will need some maintenance work ;-) Juergen On 1/13/12 12:54 AM, Carl Marcum wrote: Hi all, I've seen mentioned in another thread, the OOo NetBeans plugin was to be part of the SGA, but not yet available. Does anyone know the status of the code, or when we should see it? Best regards, Carl -- Andrew Rist | Interoperability Architect OracleCorporate Architecture Group Redwood Shores, CA | 650.506.9847
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13 January 2012 16:28, Rob Weir robw...@apache.org wrote: On Fri, Jan 13, 2012 at 11:15 AM, Ross Gardler rgard...@opendirective.com wrote: Sent from my mobile device, please forgive errors and brevity. On Jan 13, 2012 4:02 PM, Andre Fischer a...@a-w-f.de wrote: On 13.01.2012 16:25, Ross Gardler wrote: For what it is worth, I agree with Joe here. The question is whether there is a valid reason to keep them here. I don't know if the reasons are valid. We are trying to find a pragmatical solution that is a good compromise for the different requirements of the ASF, the OpenOffice developers/community, and the OpenOffice users: - For the ASF we use no code under category X license and try to use as little code under category B license. - For the users we want to retain as many features as possible. - For the developers we want to make development as accessible as possible. Why is it necessary to include source rather than just binaries? With C/C++ code, binaries are built from source, and the source has to come from somewhere. If there is a need to fix a security problem, we need ready access to the source. The binaries alone would not be sufficient. This is a modification of the code, which I was told earlier in this thread was not the case we were discussing. Is this a hypothetical or an actual situation? Why can't this situation be managed via the upstream project? Also look at this from the perspective of a downstream consumer who is porting the product to another platform. The binaries would be of zero use to them,since the binaries would not be compiled for their platform. But having the source archives for the dependencies readily available, that is exactly what a porter would need. Why does the source have to come from AOO? Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13 January 2012 16:35, Joe Schaefer joe_schae...@yahoo.com wrote: Please do not step down from the PPMC Pedro, you have done good work here and it is very important that the PPMC consist of such people going forward. +1000 Creating a class of active committers who are not on the PPMC will not help move this project closer to graduation. Let's please avoid that circumstance over what appears to be a simple disagreement. +1000 - there are many difficult things to resolve, we need all perspectives to find the optimal solution. Ross - Original Message - From: Pedro Giffuni p...@apache.org To: ooo-dev@incubator.apache.org Cc: Sent: Friday, January 13, 2012 11:31 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) --- Ven 13/1/12, Jürgen Schmidt ha scritto: ... well that is a valid point that comes into my mind as well when I have read the mails and thought a little bit longer. If that is the only reason than we can move it besides trunk. But that is a technical solution only and it doesn't solve the underlying problem. And what is more important we can't exchange everything now and we can't remove all the features that depends on this category-b stuff. Otherwise the office is no longer useable and we can stop here or can kill the project directly. I am only asking for the technical solution. I think we have discussed sufficiently that replacing this stuff is possible but will take time. I am also not setting any time frame for moving those files. beyond that we should do it somewhen before release. The whole discussion is not really motivating for project members and of course does not really promote the Apache way or the ASF in general. I agree it's not very motivating but in my defense it was something that had to be discussed sooner better than later. So we always have to take Windows into account and on Windows you don't have system libraries for this stuff. We can do packages of this stuff. It will even save time from building over and over again the same stuff. So please come back to reality. Juergen PS who will go demotivated into the weekend OK, this is something I really didn't intend. This was meant to be discussed on a strictly technical level without demotivating developers or calling bloody murder on the project. I hereby drop *any* claim that we may not be complying with any relevant policy. Also to give full assurance that I will not be problem to the project I will be stepping down from the PPMC so my vote will not be binding: I am really only interested in technical discussions anyway. Pedro. -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: Category-B tarballs in SVN (was Re: External libraries)
On Fri, Jan 13, 2012 at 12:31 PM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 16:28, Rob Weir robw...@apache.org wrote: On Fri, Jan 13, 2012 at 11:15 AM, Ross Gardler rgard...@opendirective.com wrote: Sent from my mobile device, please forgive errors and brevity. On Jan 13, 2012 4:02 PM, Andre Fischer a...@a-w-f.de wrote: On 13.01.2012 16:25, Ross Gardler wrote: For what it is worth, I agree with Joe here. The question is whether there is a valid reason to keep them here. I don't know if the reasons are valid. We are trying to find a pragmatical solution that is a good compromise for the different requirements of the ASF, the OpenOffice developers/community, and the OpenOffice users: - For the ASF we use no code under category X license and try to use as little code under category B license. - For the users we want to retain as many features as possible. - For the developers we want to make development as accessible as possible. Why is it necessary to include source rather than just binaries? With C/C++ code, binaries are built from source, and the source has to come from somewhere. If there is a need to fix a security problem, we need ready access to the source. The binaries alone would not be sufficient. This is a modification of the code, which I was told earlier in this thread was not the case we were discussing. Is this a hypothetical or an actual situation? Why can't this situation be managed via the upstream project? Also look at this from the perspective of a downstream consumer who is porting the product to another platform. The binaries would be of zero use to them,since the binaries would not be compiled for their platform. But having the source archives for the dependencies readily available, that is exactly what a porter would need. Why does the source have to come from AOO? You are trying to argue the necessity point. I'm not. That is a red herring. There is no necessity that we make things easier for downstream consumers, that we react quickly to security issues, that we maintain the code in a way that buffers us from changing URL's, moving and canceled projects. None of this is required. But I think it is a very good idea. I'm arguing common sense and engineering prudence. Remember, not every other open source project in the world practices best practices with regards to hosting their source artifacts at stable URL's, of maintaining prior versions indefinitely, of securing their servers so no one hacks into them and changes source code, etc. I'm arguing that this is a good thing, a service to downstream consumers and is compatible with all Apache policies and the principles behind them. Arguing whether or not it is necessary in a cosmic sense is not useful. It is not necessary that this podling even exist. Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Am Freitag, 13. Januar 2012 schrieb Pedro Giffuni p...@apache.org: --- Ven 13/1/12, Jürgen Schmidt ha scritto: ... well that is a valid point that comes into my mind as well when I have read the mails and thought a little bit longer. If that is the only reason than we can move it besides trunk. But that is a technical solution only and it doesn't solve the underlying problem. And what is more important we can't exchange everything now and we can't remove all the features that depends on this category-b stuff. Otherwise the office is no longer useable and we can stop here or can kill the project directly. I am only asking for the technical solution. I think we have discussed sufficiently that replacing this stuff is possible but will take time. I am also not setting any time frame for moving those files. beyond that we should do it somewhen before release. The whole discussion is not really motivating for project members and of course does not really promote the Apache way or the ASF in general. I agree it's not very motivating but in my defense it was something that had to be discussed sooner better than later. So we always have to take Windows into account and on Windows you don't have system libraries for this stuff. We can do packages of this stuff. It will even save time from building over and over again the same stuff. I would prefer to build it where possible. So please come back to reality. Juergen PS who will go demotivated into the weekend OK, this is something I really didn't intend. This was meant to be discussed on a strictly technical level without demotivating developers or calling bloody murder on the project. I don't have a problem with your mail I simply thought wr had solved this. At least in a way that is not optimal but aligned with Apache. What makes me crazy was the style of the discussion. I don't like it to play with words, phrasing and persnicketiness. As a non native speaker I can only loose here I hereby drop *any* claim that we may not be complying with any relevant policy. Also to give full assurance that I will not be problem to the project I will be stepping down from the PPMC so my vote will not be binding: I am really only interested in technical discussions anyway. Please don't do that your input is always highly appreciated. But it's simply hard to follow policies that are not written down exactly. So again my comment has nothing to do with your person, or the topic you wanted to address. It's simply the style of the communication. Juergen. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
On 13 January 2012 17:38, Rob Weir robw...@apache.org wrote: You are trying to argue the necessity point. I'm not arguing any point. I'm asking questions so that I might understand what the sticking point is. Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 17:38, Rob Weir robw...@apache.org wrote: You are trying to argue the necessity point. I'm not arguing any point. I'm asking questions so that I might understand what the sticking point is. OK. You'll understand this better if you think of it as a configuration management question rather than a question of necessity. Consider: AOO has a dependency on component X. Never mind the license. It could be anything. We have a dependency on X, specifically version 1.0 of X. We, in the role of an integrator, write our code to integrate with X, version 1.0. We then release, it gets widely adopted. Time passes. The maintainers of X release version 1.1, with minor feature changes. Then they release version 1.2 with minor feature changes. AOO has no releases in the interim, so we're still dependent on X 1.0. Many things could go wrong at this point. For example, a critical security flaw is found in component X. The X project quickly release a new patched version, X 1.2.1 to fix the problem, and releases a package for that, source and binaries. For sake of argument say they do not patch versions 1.0 and 1.1. What do we do then? We could try to upgrade to version 1.2.1 of their component. It might be possible. We might hope it is possible. But it might not work. It could fail for any number of reasons. Time is ticking. Our users are at risk. What do we do? Well, obviously, we can apply the patch from 1.2.1 to 1.0 and fix the flaw in a way that works with our code and we get that new AOO out to users quickly. And at the same time we make available our patched 1.0 available to the X project if they will host it. If not we make it available to downstream consumers, as courtesy, but not as an Apache release. And then we make an issue in Bugzilla to investigate more thoroughly how to upgrade to 1.2.1 in the future. It is not pretty, but prettiness is not a necessity either. The whole OSS universe does not march lock step on the same release schedule. We're not working with Legos. Things don't always just fit. We need to deal with the messiness of that reality. And obviously do it within policy. It could easily be every worse than that. Suppose, hypothetically, that we could upgrade our code to X 1.2.1, that it was not impractical. But we might still have another dependency, on component Y that also has its own dependency on X 1.0 and which does not work with X 1.2.1. Being an integrator of 3rd party components, regardless of license, is complex. You can get all sorts of interactions like this. What we need to do is get away from false alternatives, that either we have no category-b code in SVN, or we are subverting ASF policy and running stealth copyleft development efforts under the noses of the IPMC. There is plenty in the middle, including the prudent archiving of source code for 3rd party dependencies **regardless of license** and using them, in full conformance with Apache release policies, in order best to serve our users and downstream consumers. None of this would be necessary if there was some master OSS source code archive that was guaranteed to be as reliable and stable and secure and independent as Apache's SVN is. If such an alternative server existed, then we'd just use that. But one does not exist. -Rob Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Am Freitag, 13. Januar 2012 schrieb Rob Weir robw...@apache.org: On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler rgard...@opendirective.com wrote: On 13 January 2012 17:38, Rob Weir robw...@apache.org wrote: You are trying to argue the necessity point. I'm not arguing any point. I'm asking questions so that I might understand what the sticking point is. OK. You'll understand this better if you think of it as a configuration management question rather than a question of necessity. Consider: AOO has a dependency on component X. Never mind the license. It could be anything. We have a dependency on X, specifically version 1.0 of X. We, in the role of an integrator, write our code to integrate with X, version 1.0. We then release, it gets widely adopted. Time passes. The maintainers of X release version 1.1, with minor feature changes. Then they release version 1.2 with minor feature changes. AOO has no releases in the interim, so we're still dependent on X 1.0. Many things could go wrong at this point. For example, a critical security flaw is found in component X. The X project quickly release a new patched version, X 1.2.1 to fix the problem, and releases a package for that, source and binaries. For sake of argument say they do not patch versions 1.0 and 1.1. What do we do then? We could try to upgrade to version 1.2.1 of their component. It might be possible. We might hope it is possible. But it might not work. It could fail for any number of reasons. Time is ticking. Our users are at risk. What do we do? Well, obviously, we can apply the patch from 1.2.1 to 1.0 and fix the flaw in a way that works with our code and we get that new AOO out to users quickly. And at the same time we make available our patched 1.0 available to the X project if they will host it. If not we make it available to downstream consumers, as courtesy, but not as an Apache release. And then we make an issue in Bugzilla to investigate more thoroughly how to upgrade to 1.2.1 in the future. It is not pretty, but prettiness is not a necessity either. The whole OSS universe does not march lock step on the same release schedule. We're not working with Legos. Things don't always just fit. We need to deal with the messiness of that reality. And obviously do it within policy. It could easily be every worse than that. Suppose, hypothetically, that we could upgrade our code to X 1.2.1, that it was not impractical. But we might still have another dependency, on component Y that also has its own dependency on X 1.0 and which does not work with X 1.2.1. Being an integrator of 3rd party components, regardless of license, is complex. You can get all sorts of interactions like this. What we need to do is get away from false alternatives, that either we have no category-b code in SVN, or we are subverting ASF policy and running stealth copyleft development efforts under the noses of the IPMC. There is plenty in the middle, including the prudent archiving of source code for 3rd party dependencies **regardless of license** and using them, in full conformance with Apache release policies, in order best to serve our users and downstream consumers. None of this would be necessary if there was some master OSS source code archive that was guaranteed to be as reliable and stable and secure and independent as Apache's SVN is. If such an alternative server existed, then we'd just use that. But one does not exist. Thanks Rob, that's the mail I needed to finally go in the weekend. Juergen
Building from the Current Source
Dear all, Sorry I lost track of the discussion for awhile, for my school reports and exams. It seems that our source is moved and online now, while many people are already working on building. Can anyone tell me how can I checkout/checkin the current source, or any such document I can refer to? I would like to start looking at some old Chinese problems in the Chinese New Year. Thank you very much in advance. -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice.org http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ signature.asc Description: OpenPGP digital signature
Re: Building from the Current Source
On Fri, Jan 13, 2012 at 1:44 PM, imacat ima...@mail.imacat.idv.tw wrote: Dear all, Sorry I lost track of the discussion for awhile, for my school reports and exams. It seems that our source is moved and online now, while many people are already working on building. Can anyone tell me how can I checkout/checkin the current source, or any such document I can refer to? I would like to start looking at some old Chinese problems in the Chinese New Year. Thank you very much in advance. You can start with the instructions here: http://incubator.apache.org/openofficeorg/source.html What platform will you be building on? -Rob -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice.org http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/
RE: Moving ahead with the AOO logo and rebranding
Jürgen, I'm going to see if I can move Drew's two images for this particular case onto that page also. There is a cross-reference now. It would be good to have all of the proposed images for the same use to be together for easy comparison and mutual appraisal. - Dennis -Original Message- From: Jürgen Schmidt [mailto:jogischm...@googlemail.com] Sent: Friday, January 13, 2012 01:30 To: ooo-dev@incubator.apache.org Subject: Re: Moving ahead with the AOO logo and rebranding On 1/13/12 5:50 AM, Michael Acevedo wrote: Hi again! I added more logo proposals since my last post in this mailing list. Let me know what you think... The logo font is Verdana and uses the seagull orb as the principal part of the branding... On Fri, Jan 6, 2012 at 12:21 AM, Michael Acevedovea...@gmail.com wrote: Greetings, I've made the following logo proposals in the OpenOffice wiki found here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27834483 Hope you like them! what I don't understand is why we not use only one page for logo proposals. That would make it much easier to get an overview and it would of course improve the overall structure in the wiki. Juergen
RE: Category-B tarballs in SVN (was Re: External libraries)
Pedro, That seems like a silly reason to step down from the PPMC. Nothing discussed here has involved a vote and it is not an ooo-private discussion. There is no obligation to vote on any issue and an abstention can be cast with no need for explanation. On a vote carried out on ooo-dev, you can always cast a non-binding vote (or not vote or abstain), although it would be strange to do it that way. Since you are not attempting to veto something, the fact that you are a PPMC member is hardly disruptive to this discussion, which calls attention to edge cases that need to be understood and resolved for graduation to occur. It strikes me that you are raising an appropriate concern that is consistent with the responsibilities of the PPMC. Without expressing a view on deliberation itself, I want to affirm that avoiding a course that may be incompatible with graduation and costly to recover from is an appropriate risk-management consideration. - Dennis -Original Message- From: Pedro Giffuni [mailto:p...@apache.org] Sent: Friday, January 13, 2012 08:32 To: ooo-dev@incubator.apache.org Subject: Re: Category-B tarballs in SVN (was Re: External libraries) --- Ven 13/1/12, Jürgen Schmidt ha scritto: ... [ ... ] The whole discussion is not really motivating for project members and of course does not really promote the Apache way or the ASF in general. I agree it's not very motivating but in my defense it was something that had to be discussed sooner better than later. So we always have to take Windows into account and on Windows you don't have system libraries for this stuff. We can do packages of this stuff. It will even save time from building over and over again the same stuff. So please come back to reality. Juergen PS who will go demotivated into the weekend OK, this is something I really didn't intend. This was meant to be discussed on a strictly technical level without demotivating developers or calling bloody murder on the project. I hereby drop *any* claim that we may not be complying with any relevant policy. Also to give full assurance that I will not be problem to the project I will be stepping down from the PPMC so my vote will not be binding: I am really only interested in technical discussions anyway. Pedro.
RE: Seeking Bugzilla Admin Volunteers
For David McKay, see if thegur...@apache.org is registered. On the other hand, I would not elevate his privileges or ask that he be set up as administrator without having his confirmation that he's still interested and available. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Friday, January 13, 2012 04:35 To: ooo-dev@incubator.apache.org Subject: Re: Seeking Bugzilla Admin Volunteers On Fri, Jan 13, 2012 at 4:48 AM, tj t...@apache.org wrote: On 1/12/2012 14:16, Rob Weir wrote: [snip] So if you want to be on the initial batch, please respond to this note and let me know what your Bugzilla ID is. This is not necessarily the same as your Apache ID. And if you don't yet have a Bugzilla account for the project, you can request one here: https://issues.apache.org/ooo/ Thanks! -Rob Count me in (t...@apache.org) for both permissions and admin. I already have some elevated permissions for Documentation project bugs. I will try to make contact with David McKay, to see if he's still interested. It would be nice to have an admin who actually knows what to do. I'd consider him as already volunteered per his previous statements. Do you know his Bugzilla ID? -Rob -- /tj/
PROPOSAL (was Re: Category-B tarballs in SVN )
Hello fellow indians; ;) I think there is consensus that this is (at least) a gray area so I have the following proposal, which shouldn't get in the way of having this properly solved by legal but which I think should solve at least temporarily the issues that we have. It's actually very simple but who knows, maybe it's even acceptable as a general incubator policy at the ASF. The ext_source in shall be divided, according to the categories of the licenses, into two directories in SVN, namely: ext_source_A ext_source_B - Ext_source_B shall have a prominent text note that warns users that the code there is made available only for builder convenience but that the code is in general not acceptable for inclusion in Apache source code releases. - It is understood that ext_source_B is a quarantine area. The idea is that the code we have there will only shrink with time. The code there can be updated for security reasons but in general no new code should be brought in without specific consensus (voting, checking with the PPMC, etc, but not lazy consensus). NOTE: Consensus for replacing standard OOo 3.4 functionality like the CoinMP solver code is a given (particularly as the licensing is being worked on) but we don't want this to be a loophole to bring in MPL'd code into AOO. Of course we still have to comply with the standard Apache policies concerning Category-B : Code that is more substantial, more volatile, or not directly consumed at runtime in source form may only be distributed in binary form. but at least now it should be pretty clear and easy for everyone downloading the code from SVN where they can expect licensing issues. Pedro.
RE: Category-B tarballs in SVN (was Re: External libraries)
Hi Dennis; --- Ven 13/1/12, Dennis E. Hamilton orc...@apache.org ha scritto: Pedro, That seems like a silly reason to step down from the PPMC. Nothing discussed here has involved a vote and it is not an ooo-private discussion. There is no obligation to vote on any issue and an abstention can be cast with no need for explanation. I don't want to abstain and I do feel that it's preferable to step down if my position causes grief to the community, plus this discussion has taken already too much time from doing real development. I think my recent proposal is very flexible though. I still think copyleft tarballs in SVN are not OK, but at least this should set straight what our plans for those tarballs are. Pedro.
Re: Fwd: Seeking Bugzilla Admin Volunteers
Hi TJ, My real-world job changed on the 1st December 2011 (I moved company), and Bugzilla is no longer part of my day-to-day role, but I guess I still remember most of what I knew! If I can be of assistance I'd be pleased to help. My bugzilla ID is thegur...@openoffice.org. Regards, Dave. On 13/01/12 10:19, tj wrote: Hi, David, Per below, Rob is going to push this. If you're still interested, it would be *very* nice to have an admin like you, who knows what to do and how to do it. --/tj/ Original Message Subject: Seeking Bugzilla Admin Volunteers Date: Thu, 12 Jan 2012 14:16:31 -0500 From: Rob Weir robw...@apache.org Reply-To: ooo-dev@incubator.apache.org To: ooo-dev@incubator.apache.org As far as I have been able to determine, no one in the project seems to have the ability to do anything in our Bugzilla instance beyond the basic operations that any member of the public is able to do. We need to get a handful of people to have some elevated permissions to edit bugs, edit components, etc., so we can manage the quality process for the upcoming 3.4 release. I'll enter a JIRA issue asking that myself, and whichever other committers want to be included, be added to a group that will have the following additional Bugzilla permissions: - editbugs - editcomponents - canconfirm - editkeywords Having these additional permissions will especially be critical for those engaging in QA, I think. I'm not sure if Infra will do it (security concerns, etc.), but it would also be good to have one or two admin-level committers, with the editusers permission, so they can enable the above permissions for other users without going through Infra. So if you want to be on the initial batch, please respond to this note and let me know what your Bugzilla ID is. This is not necessarily the same as your Apache ID. And if you don't yet have a Bugzilla account for the project, you can request one here: https://issues.apache.org/ooo/ Thanks! -Rob
Re: Category-B tarballs in SVN (was Re: External libraries)
+1000. I think this thread is actually getting somewhere. The 45 minutes reading it have been better than the 30 minutes yesterday. Regards, Dave Sent from my iPhone On Jan 13, 2012, at 10:35 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Please do not step down from the PPMC Pedro, you have done good work here and it is very important that the PPMC consist of such people going forward. Creating a class of active committers who are not on the PPMC will not help move this project closer to graduation. Let's please avoid that circumstance over what appears to be a simple disagreement. - Original Message - From: Pedro Giffuni p...@apache.org To: ooo-dev@incubator.apache.org Cc: Sent: Friday, January 13, 2012 11:31 AM Subject: Re: Category-B tarballs in SVN (was Re: External libraries) --- Ven 13/1/12, Jürgen Schmidt ha scritto: ... well that is a valid point that comes into my mind as well when I have read the mails and thought a little bit longer. If that is the only reason than we can move it besides trunk. But that is a technical solution only and it doesn't solve the underlying problem. And what is more important we can't exchange everything now and we can't remove all the features that depends on this category-b stuff. Otherwise the office is no longer useable and we can stop here or can kill the project directly. I am only asking for the technical solution. I think we have discussed sufficiently that replacing this stuff is possible but will take time. I am also not setting any time frame for moving those files. beyond that we should do it somewhen before release. The whole discussion is not really motivating for project members and of course does not really promote the Apache way or the ASF in general. I agree it's not very motivating but in my defense it was something that had to be discussed sooner better than later. So we always have to take Windows into account and on Windows you don't have system libraries for this stuff. We can do packages of this stuff. It will even save time from building over and over again the same stuff. So please come back to reality. Juergen PS who will go demotivated into the weekend OK, this is something I really didn't intend. This was meant to be discussed on a strictly technical level without demotivating developers or calling bloody murder on the project. I hereby drop *any* claim that we may not be complying with any relevant policy. Also to give full assurance that I will not be problem to the project I will be stepping down from the PPMC so my vote will not be binding: I am really only interested in technical discussions anyway. Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Pedro, +1000 to your plan. It is another step in the correct direction. Best Regards, Dave Sent from my iPhone On Jan 13, 2012, at 2:46 PM, Pedro Giffuni p...@apache.org wrote: Hi Dennis; --- Ven 13/1/12, Dennis E. Hamilton orc...@apache.org ha scritto: Pedro, That seems like a silly reason to step down from the PPMC. Nothing discussed here has involved a vote and it is not an ooo-private discussion. There is no obligation to vote on any issue and an abstention can be cast with no need for explanation. I don't want to abstain and I do feel that it's preferable to step down if my position causes grief to the community, plus this discussion has taken already too much time from doing real development. I think my recent proposal is very flexible though. I still think copyleft tarballs in SVN are not OK, but at least this should set straight what our plans for those tarballs are. Pedro.
Re: Seeking Bugzilla Admin Volunteers
On 13/01/12 20:02, Dennis E. Hamilton wrote: For David McKay, see if thegur...@apache.org is registered. On the other hand, I would not elevate his privileges or ask that he be set up as administrator without having his confirmation that he's still interested and available. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Friday, January 13, 2012 04:35 To: ooo-dev@incubator.apache.org Subject: Re: Seeking Bugzilla Admin Volunteers On Fri, Jan 13, 2012 at 4:48 AM, tjt...@apache.org wrote: On 1/12/2012 14:16, Rob Weir wrote: [snip] So if you want to be on the initial batch, please respond to this note and let me know what your Bugzilla ID is. This is not necessarily the same as your Apache ID. And if you don't yet have a Bugzilla account for the project, you can request one here: https://issues.apache.org/ooo/ Thanks! -Rob Count me in (t...@apache.org) for both permissions and admin. I already have some elevated permissions for Documentation project bugs. I will try to make contact with David McKay, to see if he's still interested. It would be nice to have an admin who actually knows what to do. I'd consider him as already volunteered per his previous statements. Do you know his Bugzilla ID? -Rob -- /tj/ I'm still interested and available, real-world job permitting. I'm in the UK time-zone if that has any bearing on anything. Dave.
RE: Moving ahead with the AOO logo and rebranding
On Fri, 2012-01-13 at 12:02 -0800, Dennis E. Hamilton wrote: Jürgen, I'm going to see if I can move Drew's two images for this particular case onto that page also. There is a cross-reference now. It would be good to have all of the proposed images for the same use to be together for easy comparison and mutual appraisal. Hi Dennis Well, I don't mind moving stuff around and/or removing some perhaps, to get it all onto a common page. Not sure how the move part works for Confluence, given it appears at first blush files are attached to specific pages, a minute or two in the help for said same will clear that up I suppose. . and sure enough - so I can move the pages and I can move the attachments fairly easily it seems, actually. @Dennis, if you want to make some changes, fine of course. Otherwise, or also, I was thinking of rearranging the pages to: Branding Planning page (new sub pages) - Logo (the base logo design proposals only, from the two current pages) - Application artwork (splash/info/about.., icons, etc) - General purpose artwork (web buttons, banners, etc ) - Survey design (leave as is) I think that would do it for the moment. //drew -Original Message- From: Jürgen Schmidt [mailto:jogischm...@googlemail.com] Sent: Friday, January 13, 2012 01:30 To: ooo-dev@incubator.apache.org Subject: Re: Moving ahead with the AOO logo and rebranding On 1/13/12 5:50 AM, Michael Acevedo wrote: Hi again! I added more logo proposals since my last post in this mailing list. Let me know what you think... The logo font is Verdana and uses the seagull orb as the principal part of the branding... On Fri, Jan 6, 2012 at 12:21 AM, Michael Acevedovea...@gmail.com wrote: Greetings, I've made the following logo proposals in the OpenOffice wiki found here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27834483 Hope you like them! what I don't understand is why we not use only one page for logo proposals. That would make it much easier to get an overview and it would of course improve the overall structure in the wiki. Juergen
Re: Status of OOo NetBeans Plugin
Hi Andrew, On 01/13/2012 12:08 PM, Andrew Rist wrote: Where should we check it in? If there is a consensus on the location, I'll check it in and change the headers... A. The original discussion is here [1]. I think the proposal is to start something beside 'trunk' like 'devtools' since it won't be included with OOo source. I think we should put it's own directory under 'devtools' like 'netbeans' since there will probably be similar plugins in the future like 'eclipse', etc. [1] http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/20.mbox/%3C4ED5FF8D.4050708%40googlemail.com%3E Thanks, Carl On 1/13/2012 12:24 AM, Jürgen Schmidt wrote: Hi Carl, thanks for the reminder, I will work with Andrew on this and we can hopefully provide the sources asap. But the plugin will need some maintenance work ;-) Juergen On 1/13/12 12:54 AM, Carl Marcum wrote: Hi all, I've seen mentioned in another thread, the OOo NetBeans plugin was to be part of the SGA, but not yet available. Does anyone know the status of the code, or when we should see it? Best regards, Carl
Re: Status of OOo NetBeans Plugin
Sounds good - I'll wait for a day or so to see if there are any alternate opinions, then go for it... A. On 1/13/2012 4:16 PM, Carl Marcum wrote: Hi Andrew, On 01/13/2012 12:08 PM, Andrew Rist wrote: Where should we check it in? If there is a consensus on the location, I'll check it in and change the headers... A. The original discussion is here [1]. I think the proposal is to start something beside 'trunk' like 'devtools' since it won't be included with OOo source. I think we should put it's own directory under 'devtools' like 'netbeans' since there will probably be similar plugins in the future like 'eclipse', etc. [1] http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/20.mbox/%3C4ED5FF8D.4050708%40googlemail.com%3E Thanks, Carl On 1/13/2012 12:24 AM, Jürgen Schmidt wrote: Hi Carl, thanks for the reminder, I will work with Andrew on this and we can hopefully provide the sources asap. But the plugin will need some maintenance work ;-) Juergen On 1/13/12 12:54 AM, Carl Marcum wrote: Hi all, I've seen mentioned in another thread, the OOo NetBeans plugin was to be part of the SGA, but not yet available. Does anyone know the status of the code, or when we should see it? Best regards, Carl -- Andrew Rist | Interoperability Architect OracleCorporate Architecture Group Redwood Shores, CA | 650.506.9847
Re: AOOo in Debian/Ubuntu (Was: Re: /usr/bin/openoffice.org)
Hmm... --- Ven 13/1/12, Bjoern Michaelsen bjoern.michael...@canonical.com ha scritto: ... Well, no. After all, OpenOffice.org is not dead. It just got a new home. The project OpenOffice.org is dead, the trademark obviously survived as it is currently owned by a different project with a different name: Apache OpenOffice (Incubating) This common misconception is the reason why I prepared an educational banner: http://people.apache.org/~pfg/ApacheOO.gif cheers, Pedro. Best, Bjoern
Brand Usage Guidelines: Hands Off management (Was: May I use OpenOffice.org and Apache Incubator logos on OpenOffice.org CD)
On Friday 13 Jan 2012 00:38:44 Rob Weir wrote: On Thu, Jan 12, 2012 at 5:55 AM, Graham Lauder g.a.lau...@gmail.com wrote: On Thursday 12 Jan 2012 12:26:59 Rob Weir wrote: Lets stick with CTR, one thing that history has shown us is that there are a lot of eyes out there, if someone is misusing the brand, it gets back to us pretty fast. Far too much time is being spent on this sort of nonproductive effort where we could simply be using the eyes of the wider community to keep us in touch. That is not current ASF policy. We currently require explicit permission to use the loog. If you want to change policy, I'd recommend starting a new thread on that, so your thoughts are not buried in this one. Good Point, done As for far too much time is being spent, I'd draw your attention to the fact that this is the first logo request we've received for a CD in 6 months, and perhaps only the 4th logo request we've received at all. All our current process requires is lazy consensus, e.g., a 72 hour opportunity for PPMC members to object. And then VP, Branding permission based on our recommendation. I'm talking about the time spent worrying about what people are doing with the trademark and logo, screeds of mail on the TOO thing, Shane tied up with an email tennis match and much brow beating and hair tearing. It is becoming tiresome and it is distracting from our purpose here. Create Software for the public good. We are getting into battles that only limit the ability for the community to connect and all for little or no profit, this project will live and die on what it produces, not on the use or misuse of the logo. We have to get out of this obselete Corporate mind think. Our name is the principle part of the brand, we protect that by producing good product that looks after our users needs. Our highest profile element out in the wild is our software on our Users computers, not thousands of billboards, or hours of TVCs shoving our Logo in people faces. Ours is word of mouth or string of text, definitely not people being drawn to us by seeing our ubiquitous Logo. People usually only get taken once, then they come here and complain and our response is: It's OK, it'll all be good from here. That's as good as it gets in terms of building a community. Community distributors will use it anyway once we get CD art decided on and published on the wiki. So this is neither difficult nor time consuming. And if anyone thinks it is, I'm happy to remove that objection by volunteering to manage the workflow for this myself for this project, something I'm essentially already doing. It may seem that way now, but that's because noone knows us, we have no policies in place, we don't even have any software to distribute. Gad it surprises me that anyone is asking at all right now. However if you want to know where it's heading, check out the Distro and cd-rom lists and ask Andy Shiels and Alex Fisher how non time consuming it was. Hands-off worked in the past, sure there were breaches, but in terms of the greater picture the numbers were very small. The easier we can make it for the brand to be out in the wild the better, if only from a brand recognition point of view. If we want to have absolute control over how and where the brand is used then it will not get the spread it needs without the expense of paid advertising. Not much point in having a a brand if we are the only ones looking at it or recognising it. That is an argument for giving permission broadly. It is not an argument for giving permission without review. Think of this as an opportunity for engagement with the person or group wanting to use the logo. By asking our permission we're introduced. We have the opportunity to explain our preferred ways to use our branding. We can answer their questions. We can perhaps point them to other forms of the logo,. Maybe we identify ways of cross promoting their activity. It opens up a two-way conversation. It is not a bad thing. Indeed that's not a bad thing, but I refer again to the CDROM list and then point to Eric Raymonds famous Essay for some clues. Cathedral Builders can force people into a cue, line up at a desk and get stamped, you may deal with everyone one on one, but it takes too long and the spread is too slow. In the Bazaar model you are standing in the crowd who are all demanding your attention at once, if you try to talk to everyone again you'll run out of time, even if you can make yourself heard. But if you make the logo easy to obtain and put up a big sign that displays a few simple rules that are easy to adhere to. For instance: Always display the web address so that people will eventually always get to the real project. Of course we never had that rule because, well, the name WAS the web address. sarcasm Good heavens, who would have thought of that, what a brilliant idea!
