Re: Apache Disavows Team OpenOffice.org e.V.
Hello, Martin Hollmichel wrote: obviously there was not too much knowledge about the former role of Team OpenOffice.org and the relationship among Team OOo and Apache is not really defined right now. I hope the header of this message does not mean that no further communication between Apache and Team OOo is desired ? I dont know this, but i hope there is communication between TeamOOo e.V. and users. I wrote an email (on 13.10.2011) to vorst...@teamopenoffice.de (your email m...@openoffice.org in CC) and got no answer. Why? No interest in communication? Greetings Jörg
Re: Apache Disavows Team OpenOffice.org e.V.
Am 20.10.2011 09:41, schrieb Jörg Schmidt: I wrote an email (on 13.10.2011) tovorst...@teamopenoffice.de (your emai...@openoffice.org in CC) and got no answer. Why? No interest in communication? sorry, for not answering yet, our bandwidth is bit overloaded in the moment, we come back to your email soon, Martin
reply: Extensions Integration into Installation Set
Hello Ariel Constenla-Haile With your help, I solved the Extensions Integration into Installation Set problem, I would like to ask some questions about build.lst file build.lst file myext myextensions: solenv NULL myext myextensions usr1 - all myextensions_mkout NULL myext myextensions \ prj get - all myextensions_prj NULL myext myextensions \ zipped nmake - all myextensions_zipped NULL My question is as follows: What is the meaning of which usr1 Look forward to your reply jianlizhao
working on a OpenOffice roadmap
Hi, Wether to stay with OpenOffice or LibreOffice or to migrate to LibreOffice or to OpenOffce is a question in the recent past often occurred, by users, by people doing business with OpenOffice, by the press. The answer I would like to give is that this question is not really that relevant because there is a roadmap in place and both projects plan to stay close together. I suggest following actions: * A call to LibreOffice contributors also to contribute their changes to Apache as the ASF is the long desired independent foundation for OpenOffice.org. On this basis a collaboration among the OpenOffice.org Apache Project and TDF can be achieved and duplication of efforts get avoided. As a result the question which project/product to choose is not that important any more. * Provide an OpenOffice.org 3.3.1 micro release showing the world that OpenOffice.org continues to move (assuming that an production stable 3.4 release is not ready to get happen within the next months), this release should include a prominent statement to show the upcoming roadmap with the next releases. This 3.3.x release may not comply with the ASF standards but is an ideal vehicle for doing communication and elaborate on the transition from the old to the new environment. * Work on a model or agreement where user donations specific to the project can be continued. This is not only a matter for the ASF (and Team OOo), but for the overall community and we need to find ways to include them (including TDF) into this discussion. It is required that we have a clear communication on how donations will benefit the project and to provide transparency on the execution. A donation model shall give users a more direct possibility to influence the further development of the product without the filtering by own interests of a profit orientated organization. We need to include the expertise of people doing business with OpenOffice into this approach, so doing this discussion also on disc...@openoffice.org mailto:disc...@openoffice.orgmight makes sense. The employment of full time developers sponsored and directed by the community is IHMO a very good chance and would be examplary for the bigger opensource projects. I think this model is already to be proven as working fine for small OS projects and we now got that chance to introduce this also for OpenOffice.org. Martin PS: I intentionally leave out the Apache vs. GNU license paradigm in these thoughts, assuming that this not the point for most users using product and discussion about this topic are quite predictable.
Re: Apache Disavows Team OpenOffice.org e.V.
On 10/17/11 6:54 PM, Rob Weir wrote: New article out by Brian Profitt on IT World: http://www.itworld.com/it-managementstrategy/213997/apache-disavows-team-openofficeorg-ev He has a good catch here that this page is still calling for donations to Team OpenOffice: http://contributing.openoffice.org/donate.html Is there anyone who can change this page *immediately*? I don't think this is something we should wait until after we migrate the wiki. The information on the page now is wrong, misleading and confuses the Apache statements on fundraising. I'd recommend replacing all the text on that page with a simple statement: Apache projects do not solicit funds directly. However, the Apache Software Foundation graciously accepts donations of all sizes (or other such words as the mentors may suggest) and to put a link to: http://www.apache.org/foundation/contributing.html -Rob we should also clean up the Spanish page that collects donations in some other buckets. http://es.openoffice.org http://es.openoffice.org/lecturas/lecturas_0019.html Juergen
Re: working on a OpenOffice roadmap
On 20 October 2011 10:02, Martin Hollmichel martin.hollmic...@googlemail.com wrote: Hi, Wether to stay with OpenOffice or LibreOffice or to migrate to LibreOffice or to OpenOffce is a question in the recent past often occurred, by users, by people doing business with OpenOffice, by the press. The answer I would like to give is that this question is not really that relevant because there is a roadmap in place and both projects plan to stay close together. I suggest following actions: * A call to LibreOffice contributors also to contribute their changes to Apache as the ASF is the long desired independent foundation for OpenOffice.org. On this basis a collaboration among the OpenOffice.org Apache Project and TDF can be achieved and duplication of efforts get avoided. As a result the question which project/product to choose is not that important any more. * Provide an OpenOffice.org 3.3.1 micro release showing the world that OpenOffice.org continues to move (assuming that an production stable 3.4 release is not ready to get happen within the next months), this release should include a prominent statement to show the upcoming roadmap with the next releases. This 3.3.x release may not comply with the ASF standards but is an ideal vehicle for doing communication and elaborate on the transition from the old to the new environment. * Work on a model or agreement where user donations specific to the project can be continued. This is not only a matter for the ASF (and Team OOo), but for the overall community and we need to find ways to include them (including TDF) into this discussion. It is required that we have a clear communication on how donations will benefit the project and to provide transparency on the execution. A donation model shall give users a more direct possibility to influence the further development of the product without the filtering by own interests of a profit orientated organization. We need to include the expertise of people doing business with OpenOffice into this approach, so doing this discussion also on disc...@openoffice.org mailto:disc...@openoffice.org**might makes sense. The employment of full time developers sponsored and directed by the community is IHMO a very good chance and would be examplary for the bigger opensource projects. I think this model is already to be proven as working fine for small OS projects and we now got that chance to introduce this also for OpenOffice.org. Hi Martin, I'd like to consider the last point first. There is no reason why TeamOO can't carry on as a fund-raising entity independent of ASF and TDF but providing benefit to both. I suggest that this is the simplest way to arrange things because it does not require any changes to the existing structures. Of course getting permission to use trademarks etc from each project is a nice to have but even that is not essential if you don't use the branding except nominatively. Donations are only part of the potential business that such an entity could do but it is a good starting point again because it is simple. With the right business strategy optimising grants from the EU and income from other services and merchandise it is not difficult to envisage resource generation that would be very significant. A further advantage of this approach is that it frees up the people working through TDF and ASF to focus on their core business of getting code done and distributed. Of course close collaboration with both communities would be highly desirable but not a show stopper to start with if it isn't forthcoming. So how would the money be used? The board of TeamOO could include TDF and ASF representation (and from other interested parties). That board would make strategic decisions about what to fund and how to raise further funds supported by volunteers. An alternative approach would be to have a board entirely independent of any particular project in order to sidestep any problems with internal politics. Really, deciding a constitution is something that needs to be thought through as soon as an overall strategy is agreed. It might be that one or other of TDF/ASF wants to cooperate and one not. That then requires some decisions but in effect and independent TeamOO makes such situations at least manageable. -- Ian Ofqual Accredited IT Qualifications (The Schools ITQ) www.theINGOTs.org +44 (0)1827 305940 The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and Wales.
Is the JRE license OK for inclusing in AOO?
Has someone already thought about the license for the included JRE? http://www.oracle.com/technetwork/java/javase/terms/license/index.html With releases from Sun/Oracle we put the JRE into (many) installation sets to make it easier for the user with the installation. But it's also required for some features as the Base module and some wizards. How can we continue this? Is the license compatible? There is already an issue for this: https://issues.apache.org/ooo/show_bug.cgi?id=118532 Marcus
Re: working on a OpenOffice roadmap
Am 20.10.2011 11:02, schrieb Martin Hollmichel: A call to LibreOffice contributors also to contribute their changes to Apache as the ASF is the long desired independent foundation for OpenOffice.org. of course this should read as a call for all people providing patches, to do a dual licensing of their patches to keep as much doors open as possible, Martin
Re: working on a OpenOffice roadmap
Hello Martin; First of all a hats off for the work you#39;ve done in the past for OOo, it#39;s difficult not to have seen your name around in some documents, and my best wishes that you can get some agreement to complement the ASF funding. Given that there has already been a 3.4-RC, I do think we should do a 3.4 non-Apache release in the old infrastructure, especially if there are security concerns. This would also reduce the growing pressure for a new release and would let us work more confortably for the Apache release. Despite not being an Apache release, we would use the AL2 where possible and the PPMC would overview it so that the documentation points to the Apache Podling as the definite reference for future development. Pedro.
Re: working on a OpenOffice roadmap
On 20 October 2011 12:10, Pedro Giffuni p...@apache.org wrote: Hello Martin; First of all a hats off for the work you#39;ve done in the past for OOo, it#39;s difficult not to have seen your name around in some documents, and my best wishes that you can get some agreement to complement the ASF funding. Given that there has already been a 3.4-RC, I do think we should do a 3.4 non-Apache release in the old infrastructure, especially if there are security concerns. This would also reduce the growing pressure for a new release and would let us work more confortably for the Apache release. Despite not being an Apache release, we would use the AL2 where possible and the PPMC would overview it so that the documentation points to the Apache Podling as the definite reference for future development. +1 Especially if a full Apache release looks like being possibly 6 months away or more. -- Ian Ofqual Accredited IT Qualifications (The Schools ITQ) www.theINGOTs.org +44 (0)1827 305940 The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and Wales.
Re: working on a OpenOffice roadmap
Thanks for joining the ooo-dev@ list! On 10/20/2011 5:02 AM, Martin Hollmichel wrote: Hi, Wether to stay with OpenOffice or LibreOffice or to migrate to LibreOffice or to OpenOffce is a question in the recent past often occurred, by users, by people doing business with OpenOffice, by the press. The answer I would like to give is that this question is not really that relevant because there is a roadmap in place and both projects plan to stay close together. I agree that the Apache OpenOffice podling here, via it's PPMC, does need to publish a roadmap in an obvious (to users) place. Even one in draft form would be helpful to users to get an idea of what's expected to be happening (i.e. even some intelligent guesses would be better than nothing). Please note that it's up to TDF to publish a roadmap for LibreOffice releases. I suggest following actions: * A call to LibreOffice contributors also to contribute their changes to Apache as the ASF is the long desired independent foundation for OpenOffice.org. On this basis a collaboration among the OpenOffice.org Apache Project and TDF can be achieved and duplication of efforts get avoided. As a result the question which project/product to choose is not that important any more. The Apache OpenOffice podling would love to get Apache-licensed code contributions from TDF volunteers, as well as everyone else involved in OOo related projects. We've mentioned this before, and certainly hope we can share code (appropriately licensed) in both directions. * Provide an OpenOffice.org 3.3.1 micro release showing the world that OpenOffice.org continues to move (assuming that an production stable 3.4 release is not ready to get happen within the next months), this release should include a prominent statement to show the upcoming roadmap with the next releases. This 3.3.x release may not comply with the ASF standards but is an ideal vehicle for doing communication and elaborate on the transition from the old to the new environment. This is an interesting idea. The three key questions are: -- Are there sufficient volunteers in the Apache OpenOffice podling to actually complete this work in a reasonable time, without impacting (what I think is) the progress to a new Apache OpenOffice 3.4 release? This is a vitally important question, because without sufficient volunteers and committers working on this, it won't be possible to do. -- How much does this idea rely on the existing Oracle-hosted openoffice.org infrastructure? Many parts of that infrastructure will be shut down soon (at Oracle's choice), so only the new Apache services - subtly different I imagine - will be available soon. -- Is there a credible way to produce a release that the ASF is willing to host on it's servers? Normally, I would say this is not possible, because the ASF only ships software under the Apache License (or compatible), and I understand that a significant amount of the existing OOo source code is under LGPL or GPL licenses. Much like some FOSS volunteers really only like to use GPL or related licenses, the ASF really only likes to use the Apache license. However, there is a somewhat related precedent in the Apache Subversion project, which shipped code as a podling under it's previous license before creating a fully ASF blessed release. As a widely used and mature project before it came to the ASF, it made sense to allow the podling to create a bridge release under similar but not identical Apache policies, before they graduated and began producing releases under all Apache policies. Note that this is only somewhat related, because previous Subversion builds used an earlier Apache license or similar, and not GPL style licenses. So I'm not sure the precedent will apply, but it's something we could consider asking if the PPMC is interested in pursuing this. * Work on a model or agreement where user donations specific to the project can be continued. This is not only a matter for the ASF (and Team OOo), but for the overall community and we need to find ways to include them (including TDF) into this discussion. It is required that we have a clear communication on how donations will benefit the project and to provide transparency on the execution. A donation model shall give users a more direct possibility to influence the further development of the product without the filtering by own interests of a profit orientated organization. Any such activity would need to happen outside of the ASF, and would need to respect Apache marks. Please remember that one of the top goals of the incubation process at Apache is to ensure the PPMC governing that project is a healthy one following the Apache Way. In particular, the graduation requirements specifically list these points under Meritocracy / Community: * Demonstrate an active and diverse development community * The project is not highly dependent on any single contributor (there
Re: Apache Disavows Team OpenOffice.org e.V.
Hello, Martin Hollmichel wrote: sorry, for not answering yet, our bandwidth is bit overloaded in the moment, we come back to your email soon, In the moment? Oh no, this is shortened. I have written numerous emails to Team OOo e.V. and members of Team OOo e.V. (and one Fax to), _since November 2010_ - i never got real answers. I ask this again: WHY? What is the self understanding of Team OOo e.V.? It is not my fault if these questions sound unpleasant. Greetings Jörg
Re: Please remove this unused header (was Re: Anti-grain Geometry)
On Tue, Oct 18, 2011 at 1:20 AM, Pedro Giffuni p...@apache.org wrote: Hello; This header has license issues: main/agg/inc/agg_conv_gpc.h It is part of the General Poligon Clipper and unlike the rest of AGG its free only for non commercial use. I would delete it myself but my desktop computer decided it wants vacations in some repair center :( AIUI I have OOo karma but I would prefer to have an issue to work from. Could you open one? Robert
Re: working on a OpenOffice roadmap
On Thu, Oct 20, 2011 at 5:02 AM, Martin Hollmichel martin.hollmic...@googlemail.com wrote: Hi, Wether to stay with OpenOffice or LibreOffice or to migrate to LibreOffice or to OpenOffce is a question in the recent past often occurred, by users, by people doing business with OpenOffice, by the press. The answer I would like to give is that this question is not really that relevant because there is a roadmap in place and both projects plan to stay close together. I suggest following actions: * A call to LibreOffice contributors also to contribute their changes to Apache as the ASF is the long desired independent foundation for OpenOffice.org. On this basis a collaboration among the OpenOffice.org Apache Project and TDF can be achieved and duplication of efforts get avoided. As a result the question which project/product to choose is not that important any more. * Provide an OpenOffice.org 3.3.1 micro release showing the world that OpenOffice.org continues to move (assuming that an production stable 3.4 release is not ready to get happen within the next months), this release should include a prominent statement to show the upcoming roadmap with the next releases. This 3.3.x release may not comply with the ASF standards but is an ideal vehicle for doing communication and elaborate on the transition from the old to the new environment. The focus of the PPMC is aiming to speed towards an Apache 3.4 release, meeting ASF release guidelines. Yes, there is some work to move through the 3rd party code and resolve the issues. I covered this briefly in my blog post.[1] Spending time on a 3.3.1 'micro-release' doesn't do much except consume resources. It would be far preferable to focus our resources as a team on the Apache 3.4 release effort, IMHO. * Work on a model or agreement where user donations specific to the project can be continued. This is not only a matter for the ASF (and Team OOo), but for the overall community and we need to find ways to include them (including TDF) into this discussion. It is required that we have a clear communication on how donations will benefit the project and to provide transparency on the execution. A donation model shall give users a more direct possibility to influence the further development of the product without the filtering by own interests of a profit orientated organization. We need to include the expertise of people doing business with OpenOffice into this approach, so doing this discussion also on disc...@openoffice.org mailto:disc...@openoffice.org**might makes sense. The employment of full time developers sponsored and directed by the community is IHMO a very good chance and would be examplary for the bigger opensource projects. I think this model is already to be proven as working fine for small OS projects and we now got that chance to introduce this also for OpenOffice.org. It may be best to start a [DISCUUSS] thread on this. Shane will advise on proper use of Apache marks and branding. He has already advised you on the imminent change in mail list infrastructure. You could open the discussion here on ooo-dev, since there are TDF folks here already. It will be challenging to broker a model that will be satisfactory to both TDF and the AOOo project communities. Funding to support LibreOffice developers will not benefit the AOOo project unless the developer(s) see fit to sign an ICLA and provide the patches within ASF guidelines. This has the potential to benefit both projects, but there has been little evident support for this approach from the LibreOffice developer(s) to date. Martin PS: I intentionally leave out the Apache vs. GNU license paradigm in these thoughts, assuming that this not the point for most users using product and discussion about this topic are quite predictable. ost users at the consumer level do not have a strong view on the license of the sofware. This is not the case for some large enterprises. Re-opening the license debate will not be productive. There are many past threads on this in the archive already.
[licensing] Re: License implications of build-time or test-time dependencies?
On Tue, Oct 18, 2011 at 4:55 PM, Rob Weir robw...@apache.org wrote: Another question that has come up based on review of OpenOffice code. If a 3rd party module is used as part of the build or test automation, but is not part of our release, do we care about whether it is copyleft? Or do we only care if the 3rd party modules is part of the release? Rules about releases apply only to the artifacts themselves A minority of build and testing tools have licensing impact, and care needs to be taken about them. In particular, some tools produce output which cannot be included within an Apache release. For example, our Windows builds use the Microsoft C/C++ compiler. It is not OSS at all. But installing it is a pre-req to build on Windows. But we don't include the compiler in our release. I assume this is OK. +1 On Linux we rely on available GNU/Linux build tools, almost all copyleft, but they are not part of the release. So I assume it is OK. +1 A trickier case: CppUnit. This is not a standard platform module. It is LGPL. We use it as a framework for unit testing. It is the C++ equivalent of JUnit. I think we should be shipping our unit tests with our source releases. This is really useful for downstream consumers of the code to use when enhancing AOOo, to check for errors. If we don't include CppUnit in our releases, then a consumer of the source releases would need to download CppUnit separately as a pre-req. So would we when building AOOo. Downstream developers working from a source release would need to download and install the package if they want to run unit tests. This is the price they pay for their licensing convenience. For the convenience of downstream consumers who want to build and test for their own use, it would be possible to either * provide an additional build script in the source release that downloads additional dependencies (though IMHO the user should be informed by the script of the licenses for the artifacts downloaded), or * provide a convenience artifact following the binary release rules aimed at this group Are the considerations here, for build-time and test-time dependencies the same as for any other 3rd party modules in our release? Have I covered this well enough above, or would it be helpful for me to expand? Robert
Re: working on a OpenOffice roadmap
Forgot my footnote: [1] https://blogs.apache.org/OOo/entry/what_is_a_podling On Thu, Oct 20, 2011 at 9:41 AM, Donald Harbison dpharbi...@gmail.comwrote: On Thu, Oct 20, 2011 at 5:02 AM, Martin Hollmichel martin.hollmic...@googlemail.com wrote: Hi, Wether to stay with OpenOffice or LibreOffice or to migrate to LibreOffice or to OpenOffce is a question in the recent past often occurred, by users, by people doing business with OpenOffice, by the press. The answer I would like to give is that this question is not really that relevant because there is a roadmap in place and both projects plan to stay close together. I suggest following actions: * A call to LibreOffice contributors also to contribute their changes to Apache as the ASF is the long desired independent foundation for OpenOffice.org. On this basis a collaboration among the OpenOffice.org Apache Project and TDF can be achieved and duplication of efforts get avoided. As a result the question which project/product to choose is not that important any more. * Provide an OpenOffice.org 3.3.1 micro release showing the world that OpenOffice.org continues to move (assuming that an production stable 3.4 release is not ready to get happen within the next months), this release should include a prominent statement to show the upcoming roadmap with the next releases. This 3.3.x release may not comply with the ASF standards but is an ideal vehicle for doing communication and elaborate on the transition from the old to the new environment. The focus of the PPMC is aiming to speed towards an Apache 3.4 release, meeting ASF release guidelines. Yes, there is some work to move through the 3rd party code and resolve the issues. I covered this briefly in my blog post.[1] Spending time on a 3.3.1 'micro-release' doesn't do much except consume resources. It would be far preferable to focus our resources as a team on the Apache 3.4 release effort, IMHO. * Work on a model or agreement where user donations specific to the project can be continued. This is not only a matter for the ASF (and Team OOo), but for the overall community and we need to find ways to include them (including TDF) into this discussion. It is required that we have a clear communication on how donations will benefit the project and to provide transparency on the execution. A donation model shall give users a more direct possibility to influence the further development of the product without the filtering by own interests of a profit orientated organization. We need to include the expertise of people doing business with OpenOffice into this approach, so doing this discussion also on disc...@openoffice.org mailto:disc...@openoffice.org**might makes sense. The employment of full time developers sponsored and directed by the community is IHMO a very good chance and would be examplary for the bigger opensource projects. I think this model is already to be proven as working fine for small OS projects and we now got that chance to introduce this also for OpenOffice.org. It may be best to start a [DISCUUSS] thread on this. Shane will advise on proper use of Apache marks and branding. He has already advised you on the imminent change in mail list infrastructure. You could open the discussion here on ooo-dev, since there are TDF folks here already. It will be challenging to broker a model that will be satisfactory to both TDF and the AOOo project communities. Funding to support LibreOffice developers will not benefit the AOOo project unless the developer(s) see fit to sign an ICLA and provide the patches within ASF guidelines. This has the potential to benefit both projects, but there has been little evident support for this approach from the LibreOffice developer(s) to date. Martin PS: I intentionally leave out the Apache vs. GNU license paradigm in these thoughts, assuming that this not the point for most users using product and discussion about this topic are quite predictable. ost users at the consumer level do not have a strong view on the license of the sofware. This is not the case for some large enterprises. Re-opening the license debate will not be productive. There are many past threads on this in the archive already.
Re: License implications of build-time or test-time dependencies?
On Tue, Oct 18, 2011 at 5:41 PM, Pedro Giffuni p...@apache.org wrote: One observation, before it slips through. Depending on gpl#39;d compilers and tools that we don#39;t carry in the release is fine AFAICT. In our bootstrap procedure we use Dmake (gplv1), which we must remove in favor of the external package, just like other OpenOffice forks do. A more controversial point is our use of GTK and Qt. Have these observations been recorded in an issue tracker? Robert
Re: [PROPOSAL]Apache OpenOffice.org Meetup @ApacheCon
On Wed, Oct 5, 2011 at 2:51 PM, Donald Harbison dpharbi...@gmail.comwrote: Hi Everyone, Following up to my earlier note[1] to discuss and gauge interest in a meetup for the project at ApacheCon. If you will be attending, and wish to participate, what topics do your propose we cover? I picked off the usual suspects; e.g. overview, dev, fora, qa, doc, and marketing, for the wiki entry. Those were just placeholders. Please help me shape this, and get the ball, snow-balling, (apologies to those in the tropics). OK, it's October 20, and our OpenOffice Meetup at ApacheCon is 18 days out. I'm hoping that we can attract attendees who are interested to learn what's going on with the project, so the overview and 'what's happening now?', including easy ways to get started is my priority. I'd love to get the guidance and advice from the members here on ooo-dev. Help me plan this meetup, please by replying here. Thanks! /don h. Also, as Shane has pointed out, please hop over to the conference wiki[2], and plunk down your 'number' that you will attend. Right now, it's me as the one and only. I did hear that Dave Fisher and Ross Gardler are 'in', so that number should jump to a whopping '3' soon. Let's pile on. [1] http://tinyurl.com/4xy7rma [2] http://wiki.apache.org/apachecon/ApacheMeetupsNa11 /don
Re: [Proposal] Shutting down legacy OOo mailing lists
On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi! This is the ezmlm program. I'm managing the ooo-dev@incubator.apache.org mailing list. I'm working for my owner, who can be reached at ooo-dev-ow...@incubator.apache.org. To confirm that you would like f...@bar.com added to the ooo-dev mailing list, please send a short reply to this address: ooo-dev-sc.X.X-foo=bar@incubator.apache.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:ooo-dev-sc.X.XX-foo=bar@incubator.apache.org; - So with the moderator rights available to us now, we can't do a fully automated sign up of existing list members, even if we had resolved the legal and policy issues. I don't know if there are other, administrative functions in ezmlm that could be used, by Apache Infra, to more fully automate this. -Rob
Re: working on a OpenOffice roadmap
On Thu, Oct 20, 2011 at 2:41 PM, Donald Harbison dpharbi...@gmail.comwrote: You could open the discussion here on ooo-dev, since there are TDF folks here already. I don't think this is a good assumption, any more than it would be to note that there are Apache members on the tdf-discuss mailing list so that would be a good place for a conversation. As we've discovered in connection with security collaboration, the legacy StarOffice meta-community has no single venue or authority. From my observations and discussions I'd say that TDF goes to a lot of effort to stay out of AOOo's hair and when people do show up here it's best to assume it's just a visit. Thus any realistic discussions would need to take place in both venues - a newly-elected Board is about to be seated at TDF so now is the time! S.
Re: working on a OpenOffice roadmap
On Thu, Oct 20, 2011 at 5:02 AM, Martin Hollmichel martin.hollmic...@googlemail.com wrote: Hi, Wether to stay with OpenOffice or LibreOffice or to migrate to LibreOffice or to OpenOffce is a question in the recent past often occurred, by users, by people doing business with OpenOffice, by the press. The answer I would like to give is that this question is not really that relevant because there is a roadmap in place and both projects plan to stay close together. I suggest following actions: * A call to LibreOffice contributors also to contribute their changes to Apache as the ASF is the long desired independent foundation for OpenOffice.org. On this basis a collaboration among the OpenOffice.org Apache Project and TDF can be achieved and duplication of efforts get avoided. As a result the question which project/product to choose is not that important any more. It would be good to have a write up on the 'best practices' or 'recommended practices' for doing this. I'm sure there are many developers who would like to make their patches available to both projects, in order to benefit as much open source software as possible. But it may not be clear how they can do this. For example, would it be a good idea, when submitting a patch to LO, for a developer to say something like, I make this patch also available under the Apache 2.0 license? * Provide an OpenOffice.org 3.3.1 micro release showing the world that OpenOffice.org continues to move (assuming that an production stable 3.4 release is not ready to get happen within the next months), this release should include a prominent statement to show the upcoming roadmap with the next releases. This 3.3.x release may not comply with the ASF standards but is an ideal vehicle for doing communication and elaborate on the transition from the old to the new environment. It is probably worth having a discussion on what a 3.4 schedule could look like. I don't think it will be a very long wait. To me it makes more sense to complete a release of 3.4, since the beta was already released previously. 3.3.1 looks like we're going backwards. Maybe we can do both: 1) AOOo 3.4 beta 2, with the copyleft components removed/replaced. This change has the potential to introduce new bugs, so we'll want to be careful with regression testing. Having a 2nd beta might be a good ideas as well. 2) An OOo-branded 3.3.1 if there are any critical bugs that need to be fixed before we have a stable 3.4 ready for release. How much of an effort do you think a 3.3.1 would be? If it was very, very small, then I would support it. But if it was very, very small, then I assume you would have already done it already ;-) * Work on a model or agreement where user donations specific to the project can be continued. This is not only a matter for the ASF (and Team OOo), but for the overall community and we need to find ways to include them (including TDF) into this discussion. It is required that we have a clear communication on how donations will benefit the project and to provide transparency on the execution. A donation model shall give users a more direct possibility to influence the further development of the product without the filtering by own interests of a profit orientated organization. We need to include the expertise of people doing business with OpenOffice into this approach, so doing this discussion also on disc...@openoffice.org mailto:disc...@openoffice.orgmight makes sense. The employment of full time developers sponsored and directed by the community is IHMO a very good chance and would be examplary for the bigger opensource projects. I think this model is already to be proven as working fine for small OS projects and we now got that chance to introduce this also for OpenOffice.org. There is no problem with developers being paid to work on the project. This is a good thing, a sign of a healthy ecosystem. But Apache cannot be involved in collecting money or spending money for that purpose. Martin PS: I intentionally leave out the Apache vs. GNU license paradigm in these thoughts, assuming that this not the point for most users using product and discussion about this topic are quite predictable.
Re: Extensions Integration into Installation Set
Hi jianlizhao On Thu, Oct 20, 2011 at 04:38:55PM +0800, jianlizhao wrote: Hello Ariel Constenla-Haile With your help, I solved the Extensions Integration into Installation Set problem, I would like to ask some questions about build.lst file build.lst file myext myextensions: solenv NULL myext myextensions usr1 - all myextensions_mkout NULL myext myextensions \ prj get - all myextensions_prj NULL myext myextensions \ zipped nmake - all myextensions_zipped NULL My question is as follows: What is the meaning of which usr1 according to http://wiki.services.openoffice.org/wiki/Hacking#prj.2Fbuild.lst it's a meaningless thing. Cf. also http://tools.openoffice.org/tools/build.html The only occurrence found by OpenGrok outside build.lst files is trunk/main/soldep/bootstrp/build_list_converter.pl#149 It looks like the only lines that matter are the ones with nmake, the ones with usr1 and get are treated as lines with comments. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpejNsuwkwCc.pgp Description: PGP signature
Re: Is the JRE license OK for inclusing in AOO?
On Thu, Oct 20, 2011 at 5:58 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Has someone already thought about the license for the included JRE? http://www.oracle.com/technetwork/java/javase/terms/license/index.html With releases from Sun/Oracle we put the JRE into (many) installation sets to make it easier for the user with the installation. But it's also required for some features as the Base module and some wizards. How can we continue this? Is the license compatible? Presumably our Windows install includes Microsoft redistributable binaries as well, MSVCRT DLL, etc.? There is already an issue for this: https://issues.apache.org/ooo/show_bug.cgi?id=118532 Marcus
Re: working on a OpenOffice roadmap
Am 20.10.2011 14:35, schrieb Shane Curcuru: This is an interesting idea. The three key questions are: -- Are there sufficient volunteers in the Apache OpenOffice podling to actually complete this work in a reasonable time, without impacting (what I think is) the progress to a new Apache OpenOffice 3.4 release? This is a vitally important question, because without sufficient volunteers and committers working on this, it won't be possible to do. Agreed, such release should not eat up any ongoing efforts for the Apache OOo 3.4 release. I would think that the amount of changes should be limited the bare necessities, such as security fixes and adoption to the infratructure which is subject to change, such as the crash reporting, user feedback program, registration and many other stuff. I expect that there will be some learnings which will also be helpful for the 3.4 release then. I can imagine that Team OOo will sponsor these efforts if that is desired. -- How much does this idea rely on the existing Oracle-hosted openoffice.org infrastructure? Many parts of that infrastructure will be shut down soon (at Oracle's choice), so only the new Apache services - subtly different I imagine - will be available soon. I think I'm be able to provide a full list of that dependencies, at the first glance I would think this is doable in quite short timeframe and is an excerise which need to be done anyhow. -- Is there a credible way to produce a release that the ASF is willing to host on it's servers? My expectation have been to use the existing download mirror network, but I'm open for anything, Martin
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 10:57 AM, Rob Weir robw...@apache.org wrote: A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: This would seem to be better than simply subscribing everyone silently...making it effectively an opt-in cross subscription. Can the generated message be changed? Customized per the needs of the particular list? Don
Python and other scripting framework
Wonder what is the future of the UNO scripting framework since there are many languages with different languages like Python, Beanshell and other scriptings that OOo ships. OOo builds have a full Python 2.6 version and also IDE like Rhino and other applications that are stringly attached to the OpenOffice.org core. -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6
Re: [Proposal] Shutting down legacy OOo mailing lists
Hi Rob, This is excellent. On Oct 20, 2011, at 7:57 AM, Rob Weir wrote: On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. I'm not a lawyer, but if a user has to approve the new subscription that may be enough to meet even the highest privacy requirements. Next steps if we were to proceed: (1) Getting the emails from Oracle. (2) Consider the @openoffice.org forwarder and that many subscriptions to the OOo MLs use that address. If we had that email map even if scrubbed of the name then we can apply that transformation as well. The subscribe email sent would then use the personal email. The list of OOo emails would be useful for sending warnings that these vanity ids are going away. It would be great to have a single message about the OOo MX transition. Of note, securityteam@oo.o is being kept. Are there other community MLs on OOo that should be kept? That's part of your inventory ;-) Regards, Dave Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi! This is the ezmlm program. I'm managing the ooo-dev@incubator.apache.org mailing list. I'm working for my owner, who can be reached at ooo-dev-ow...@incubator.apache.org. To confirm that you would like f...@bar.com added to the ooo-dev mailing list, please send a short reply to this address: ooo-dev-sc.X.X-foo=bar@incubator.apache.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:ooo-dev-sc.X.XX-foo=bar@incubator.apache.org; - So with the moderator rights available to us now, we can't do a fully automated sign up of existing list members, even if we had resolved the legal and policy issues. I don't know if there are other, administrative functions in ezmlm that could be used, by Apache Infra, to more fully automate this. -Rob
Re: Please remove this unused header (was Re: Anti-grain Geometry)
Actually, upon closer examination this is a non issue, it can be removed but it is not urgent. I will do it when I am back. Pedro.
Re: Is the JRE license OK for inclusing in AOO?
Am 10/20/2011 05:38 PM, schrieb Rob Weir: On Thu, Oct 20, 2011 at 5:58 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Has someone already thought about the license for the included JRE? http://www.oracle.com/technetwork/java/javase/terms/license/index.html With releases from Sun/Oracle we put the JRE into (many) installation sets to make it easier for the user with the installation. But it's also required for some features as the Base module and some wizards. How can we continue this? Is the license compatible? Presumably our Windows install includes Microsoft redistributable binaries as well, MSVCRT DLL, etc.? AFAIK yes, so another dependency that needs to be considered for a release. But I don't know for what it is used and if there is a possibility to avoid or exchange this. Marcus There is already an issue for this: https://issues.apache.org/ooo/show_bug.cgi?id=118532 Marcus
Re: Is the JRE license OK for inclusing in AOO?
On Thu, Oct 20, 2011 at 10:57 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 10/20/2011 05:38 PM, schrieb Rob Weir: On Thu, Oct 20, 2011 at 5:58 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Has someone already thought about the license for the included JRE? http://www.oracle.com/technetwork/java/javase/terms/license/index.html With releases from Sun/Oracle we put the JRE into (many) installation sets to make it easier for the user with the installation. But it's also required for some features as the Base module and some wizards. How can we continue this? Is the license compatible? Presumably our Windows install includes Microsoft redistributable binaries as well, MSVCRT DLL, etc.? AFAIK yes, so another dependency that needs to be considered for a release. But I don't know for what it is used and if there is a possibility to avoid or exchange this. Didn't he just mentioned that is used for the Base module and other things like Scripting framework and such? Ohhlo can give you a measurement of how much Java code is included in OOo: http://www.ohloh.net/p/openoffice/analyses/latest Marcus There is already an issue for this: https://issues.apache.org/ooo/show_bug.cgi?id=118532 Marcus -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6
Re: License implications of build-time or test-time dependencies?
Hmm ... We have discussed some of the things that must be replaced but we have not drawn a roadmap about it beyond the initial migration list. I think we will have to open BZ issues for those. The gtk/qt issue is rather critcal: I do not think there is previous history among Apache projects depending on them but if we cannot consider those system provided libraries it would be a serious setback to an early Apache release. Pedro.
Re: working on a OpenOffice roadmap
Shane Curcuru wrote on Thu, Oct 20, 2011 at 08:35:57 -0400: However, there is a somewhat related precedent in the Apache Subversion project, which shipped code as a podling under it's previous license before creating a fully ASF blessed release. As a widely used and mature project before it came to the ASF, it made sense to allow the podling to create a bridge release under similar but not identical Apache policies, before they graduated and began producing releases under all Apache policies. Note that this is only somewhat related, because previous Subversion builds used an earlier Apache license or similar, and not GPL style licenses. So I'm not sure the precedent will apply, but it's something we could consider asking if the PPMC is interested in pursuing this. Subversion shipped those releases at its pre-Apache home. If you're proposing that OOo ship non-Apache releases for an interim period, where would they be hosted?
Re: Is the JRE license OK for inclusing in AOO?
Am 10/20/2011 06:02 PM, schrieb Alexandro Colorado: On Thu, Oct 20, 2011 at 10:57 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/20/2011 05:38 PM, schrieb Rob Weir: On Thu, Oct 20, 2011 at 5:58 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Has someone already thought about the license for the included JRE? http://www.oracle.com/technetwork/java/javase/terms/license/index.html With releases from Sun/Oracle we put the JRE into (many) installation sets to make it easier for the user with the installation. But it's also required for some features as the Base module and some wizards. How can we continue this? Is the license compatible? Presumably our Windows install includes Microsoft redistributable binaries as well, MSVCRT DLL, etc.? AFAIK yes, so another dependency that needs to be considered for a release. But I don't know for what it is used and if there is a possibility to avoid or exchange this. Didn't he just mentioned that is used for the Base module and other things like Scripting framework and such? Who do you mean with he? If Rob, then I've understood his comment different. Ohhlo can give you a measurement of how much Java code is included in OOo: http://www.ohloh.net/p/openoffice/analyses/latest But when the complete Base module is affected, then IMHO it doesn't make sense to just skip to include a JRE because only 5% source code is Java. ;-) Marcus There is already an issue for this: https://issues.apache.org/ooo/show_bug.cgi?id=118532 Marcus
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 11:48 AM, Dave Fisher dave2w...@comcast.net wrote: Hi Rob, This is excellent. On Oct 20, 2011, at 7:57 AM, Rob Weir wrote: On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. I'm not a lawyer, but if a user has to approve the new subscription that may be enough to meet even the highest privacy requirements. Next steps if we were to proceed: (1) Getting the emails from Oracle. That may not be possible. It depends on how Oracle understands the ToU for the legacy lists and relevant data protection laws. Corporations tend to be conservative and risk-averse, I do not think they would make this data available to us. I was speaking only to the technical steps that someone might take. In any case, I look at this a little differently. We don't need pure numbers. We're not looking for passive viewers. If someone is so disengaged that they are unwilling to subscribe to a new list, then they are probably not going to be active project members. And if they find using mailing lists difficult, then maybe we should be pointing them to the phpBB forums, as an easier interface to use? And for ourtreach where we are looking to get the message out to the maximum number of users, then we should be looking at social media; our blog, Twitter, Facebook, etc. (2) Consider the @openoffice.org forwarder and that many subscriptions to the OOo MLs use that address. If we had that email map even if scrubbed of the name then we can apply that transformation as well. The email forwarding service is something entirely different. I'm not touching that at all in my proposal. It is an independent migration topic. As far as I can tell no one has volunteered to do that. The subscribe email sent would then use the personal email. The list of OOo emails would be useful for sending warnings that these vanity ids are going away. It would be great to have a single message about the OOo MX transition. If there is consensus on how we are treating the email forwarder, we can certainly mention that in the post to the lists. But even if we don't have an answer on this yet, we can link to a migration update page that can be kept current with our high-level status of interest to the wider ecosystem. Of note, securityteam@oo.o is being kept. Are there other community MLs on OOo that should be kept? That's part of your inventory ;-) I'm not touching private lists, at least not initially. I'm looking only at the most-used lists, maybe the top 50 community lists or so. We can iterate. We don't need to do it all at once. -Rob Regards, Dave Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi! This is the ezmlm program. I'm managing the ooo-dev@incubator.apache.org mailing list. I'm working for my owner, who can be reached at ooo-dev-ow...@incubator.apache.org. To confirm that you would like f...@bar.com added to the ooo-dev mailing list, please send a short reply to this address: ooo-dev-sc.X.X-foo=bar@incubator.apache.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:ooo-dev-sc.X.XX-foo=bar@incubator.apache.org; - So with the moderator rights available to us now, we can't do a fully automated sign up of existing list members, even if we had resolved the legal and policy issues. I don't know if there are other, administrative functions in ezmlm that could be used, by Apache Infra, to more fully automate this. -Rob
Re: Is the JRE license OK for inclusing in AOO?
On Thu, Oct 20, 2011 at 11:18 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 10/20/2011 06:02 PM, schrieb Alexandro Colorado: On Thu, Oct 20, 2011 at 10:57 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/20/2011 05:38 PM, schrieb Rob Weir: On Thu, Oct 20, 2011 at 5:58 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Has someone already thought about the license for the included JRE? http://www.oracle.com/technetwork/java/javase/terms/license/index.html With releases from Sun/Oracle we put the JRE into (many) installation sets to make it easier for the user with the installation. But it's also required for some features as the Base module and some wizards. How can we continue this? Is the license compatible? Presumably our Windows install includes Microsoft redistributable binaries as well, MSVCRT DLL, etc.? AFAIK yes, so another dependency that needs to be considered for a release. But I don't know for what it is used and if there is a possibility to avoid or exchange this. Didn't he just mentioned that is used for the Base module and other things like Scripting framework and such? Who do you mean with he? If Rob, then I've understood his comment different. Sorry it was mentioned on a different email. Ohhlo can give you a measurement of how much Java code is included in OOo: http://www.ohloh.net/p/openoffice/analyses/latest But when the complete Base module is affected, then IMHO it doesn't make sense to just skip to include a JRE because only 5% source code is Java. ;-) 5% of the code can be a few millions of line of code that could build UIs like Base or huge part of the scripting framework of OOo that runs all the macros and such. I also wonder how fundamental will Apache be regarding this since OOo was always flexible about including different libraries under different licenses. Marcus There is already an issue for this: https://issues.apache.org/ooo/show_bug.cgi?id=118532 Marcus -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6
RE: Is the JRE license OK for inclusing in AOO?
The Sun/Oracle OO.o distributions satisfy the requirements for installation on Microsoft Windows. The LO distributions do as well. Of course, including JVM in Sun/Oracle distributions was a no-brainer. Since these are distributed in binary form only and the appropriate NOTICE information (formerly THIRDPARTYLICENSE...) is included, one would trust this survives ASF Legal review in all cases of components required to run and that are incorporated in the distribution (a binary release?) in conformance with rules for the respective redistributables. It is not clear to me that either of those bundlings in binary releases is explicitly tolerated by the information that is provided at http://apache.org/legal/resolved.html. There seems to be no help in the older draft either: http://apache.org/legal/3party.html. I also note that if one is bundling the JVM or building Windows distributions, there are library dependencies and API dependencies too, somewhere deep in the works. (The LibreOffice folk have apparently stopped any JVM bundling but I don't know what they do about Microsoft redistributables.) It seems that there is more that needs to be said about binary releases and how non-source, restrictive-license redistributables are incorporated in those releases to satisfy installation requirements and also provide run-time services to an Apache release. I thought I saw how that was tolerable so long as no source was provided and the redistribution terms were honored, NOTICE was provided, etc. I can't find anything clear-cut on looking again. I think more words on this case from Robert Burrell Donkin would be helpful. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 08:39 To: ooo-dev@incubator.apache.org Subject: Re: Is the JRE license OK for inclusing in AOO? On Thu, Oct 20, 2011 at 5:58 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Has someone already thought about the license for the included JRE? http://www.oracle.com/technetwork/java/javase/terms/license/index.html With releases from Sun/Oracle we put the JRE into (many) installation sets to make it easier for the user with the installation. But it's also required for some features as the Base module and some wizards. How can we continue this? Is the license compatible? Presumably our Windows install includes Microsoft redistributable binaries as well, MSVCRT DLL, etc.? There is already an issue for this: https://issues.apache.org/ooo/show_bug.cgi?id=118532 Marcus smime.p7s Description: S/MIME cryptographic signature
RE: [Proposal] Shutting down legacy OOo mailing lists
The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were. A valuable way to do this might be to include a link to an English-language version of the message in all NL ones. Pointing to other useful web pages might also be valuable. I notice that ezmlm is designed to work relying on e-mail alone and that should be preserved, but links to web-based support is also valuable and is very useful to link to. The web page could also deal with thing such as what OOo lists does this one replace, where are the archives for the original list(s), etc. OPEN ITEMS It strikes me that there remains the issue I see, in that the ooo-younameit @ i.a.o lists are considerably less friendly than the theynamedit@ OO.o lists. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 07:57 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi! This is the ezmlm program. I'm managing the ooo-dev@incubator.apache.org mailing list. I'm working for my owner, who can be reached at ooo-dev-ow...@incubator.apache.org. To confirm that you would like f...@bar.com added to the ooo-dev mailing list, please send a short reply to this address: ooo-dev-sc.X.X-foo=bar@incubator.apache.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:ooo-dev-sc.X.XX-foo=bar@incubator.apache.org; - So with the moderator rights available to us now, we can't do a fully automated sign up of existing list members, even if we had resolved the legal and policy issues. I don't know if there are other, administrative functions in ezmlm that could be used, by Apache Infra, to more fully automate this. -Rob smime.p7s Description: S/MIME cryptographic signature
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. I don't see how this could work. Maybe if you happen to be a moderator of the legacy list and are willing to take on yourself any personal liability related to data protection laws. But I don't see how this would work in general. Any thing we do to automate this would still require proactive action by the user, either sending an email, clicking a mailto: link in an email, or going to a website and entering their email address. They would need to do an action like that, and then respond to the confirmation email. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were. A valuable way to do this might be to include a link to an English-language version of the message in all NL ones. Pointing to other useful web pages might also be valuable. I notice that ezmlm is designed to work relying on e-mail alone and that should be preserved, but links to web-based support is also valuable and is very useful to link to. The web page could also deal with thing such as what OOo lists does this one replace, where are the archives for the original list(s), etc. OPEN ITEMS It strikes me that there remains the issue I see, in that the ooo-younameit @ i.a.o lists are considerably less friendly than the theynamedit@ OO.o lists. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 07:57 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi! This is the ezmlm program. I'm managing the ooo-dev@incubator.apache.org mailing list. I'm working for my owner, who can be reached at ooo-dev-ow...@incubator.apache.org. To confirm that you would like f...@bar.com added to the ooo-dev mailing list, please send a short reply to this address: ooo-dev-sc.X.X-foo=bar@incubator.apache.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:ooo-dev-sc.X.XX-foo=bar@incubator.apache.org; - So with the moderator rights available to us now, we can't do a fully automated sign up of existing list members, even if we had resolved the legal and policy issues. I don't know if there are other, administrative functions in ezmlm that could be used, by Apache Infra, to more fully automate this. -Rob
unsubscribe user from us...@de.openoffice.org
Hi all, is here someone who can unsubscribe an user from us...@de.openoffice.org? Please look at http://openoffice.org/projects/de/lists/users/archive/2011-10/message/208 User FAX Praxis praxis.kun...@gmx.de tries to unsubscribe without success and all hints couldn't solve the problem. Kind regards Regina
Re: How voting works...
Op 19-10-2011 14:00, Rob Weir schreef: On Tue, Oct 18, 2011 at 6:50 PM, Ross Gardler rgard...@opendirective.com wrote: I'm not going to dig into all the details of how a vote is called in the ASF. In posting this I am not asking for the current vote to be recalled, there is no need. I am just wanting to flag something that concerns me about how the vote was called (and as per usual this is just advice from a mentor, these are not rules that must be adopted). In an ASF community everyone is entitled to an opinion. Everyone should be encouraged to express that opinion in a formal vote, just as much as they should be encouraged to express their opinions in day to day discussion. We're very concerned, as we should be, to ensure that everyone, even non-PPMC members, can weigh in on all project discussions and decisions, including policy and governance questions. As we should. I applaud that commitment to openness. However, the proposal that we're voting on has this clause regarding the support forums: Forum governance will be discussed in a publicly readable forum. Write access will be limited to those with at least 10 posts. In other words, we're agreeing to a proposal where it is not true that In an ASF community everyone is entitled to an opinion. Everyone should be encouraged to express that opinion in a formal vote, just as much as they should be encouraged to express their opinions in day to day discussion. *You're forgetting that the forums aren't an almost closed mailing list like ooo-dev. How many people are subscribed to ooo-dev? As of 9/20 the number of registered users of the forums is 44830 and the number of people with over 10 posts still exceeds 1000. If we'd open the gates to anyone, you'd probably soon see bored kids pollute the discussions with the kind of crap that they now post on Wikipedia. If you don't like the forum, I suggest that you just ignore it. **Peter aka floris v* ** When I brought that up in the discussion thread I was shut down by a mentor for introducing an overly legalistic parsing of the proposal. I take that to mean I was thinking too much. I'll stop now, because honestly the incongruity if our words and actions is shameful and painful to observe. -Rob It is true that only some members of the community have binding votes. However, this only becomes important in the event of an absence of community consensus. Therefore, when calling a vote please do not word it in such a way that implies others in the community do not have a vote that counts. It does count. A responsible PPMC member will use their own vote to support any appropriate objections from the community. They can only do that if the community is encouraged to express their views alongside everyone else.. Specifically, there is no need to define binding votes in the vote thread, the way Apache Projects vote is well documented and, over time, the AOOo project will gain its own guidelines. Secondly, do not list the people who are important enough to have a binding vote. Thirdly, explicitly call for all community members to express their preferences in the vote. In other words, make every action of the PPMC as inclusive as possible. Finally, Denis - thank you for calling the vote. Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: [Proposal] Shutting down legacy OOo mailing lists
On Oct 20, 2011, at 9:20 AM, Rob Weir wrote: On Thu, Oct 20, 2011 at 11:48 AM, Dave Fisher dave2w...@comcast.net wrote: Hi Rob, This is excellent. On Oct 20, 2011, at 7:57 AM, Rob Weir wrote: On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. I'm not a lawyer, but if a user has to approve the new subscription that may be enough to meet even the highest privacy requirements. Next steps if we were to proceed: (1) Getting the emails from Oracle. That may not be possible. It depends on how Oracle understands the ToU for the legacy lists and relevant data protection laws. Corporations tend to be conservative and risk-averse, I do not think they would make this data available to us. You are making an assumption. If we asked for only the map of OOo to real emails so that we can handle the retirement of the forwarder in some way other than the most precipitous (goes away when the OOo MX moves away from Oracle) we might have a chance. I suppose someone will need to ask Andrew Rist. I was speaking only to the technical steps that someone might take. Concrete abilities are good to discuss. I thought you were leading us somewhere. In any case, I look at this a little differently. We don't need pure numbers. We're not looking for passive viewers. If someone is so disengaged that they are unwilling to subscribe to a new list, then they are probably not going to be active project members. And if they find using mailing lists difficult, then maybe we should be pointing them to the phpBB forums, as an easier interface to use? And for ourtreach where we are looking to get the message out to the maximum number of users, then we should be looking at social media; our blog, Twitter, Facebook, etc. I don't want to bikeshed on Social Networks and ML vs. Fora, I want to focus on what is going to actually happen to the OOo MX and ML infrastructure. (2) Consider the @openoffice.org forwarder and that many subscriptions to the OOo MLs use that address. If we had that email map even if scrubbed of the name then we can apply that transformation as well. The email forwarding service is something entirely different. I'm not touching that at all in my proposal. It is an independent migration topic. As far as I can tell no one has volunteered to do that. So, you have no real plans to implement re-subscription? Or, if you do you don't have a problem resubscribing people with emails addresses that are going away in another month? The subscribe email sent would then use the personal email. The list of OOo emails would be useful for sending warnings that these vanity ids are going away. It would be great to have a single message about the OOo MX transition. If there is consensus on how we are treating the email forwarder, we can certainly mention that in the post to the lists. But even if we don't have an answer on this yet, we can link to a migration update page that can be kept current with our high-level status of interest to the wider ecosystem. Whatever we say about the OOo ML and MX transition needs to be based in fact and not assumptions. Of note, securityteam@oo.o is being kept. Are there other community MLs on OOo that should be kept? That's part of your inventory ;-) I'm not touching private lists, at least not initially. I'm looking only at the most-used lists, maybe the top 50 community lists or so. We can iterate. We don't need to do it all at once. There will be community lists in addition to securityteam@ that will need to be considered. Given the repeated warnings we are getting about Oracle imminent removal of some resources. I think we are going to need to execute a plan that encompasses what happens to all of the OOo MX at once and in a coherent manner. Regards, Dave -Rob Regards, Dave Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi!
RE: [Proposal] Shutting down legacy OOo mailing lists
Rob, As were you, I was looking at the value of the ezmlm confirmation e-mail and its opt-in requirement for moderator-initiated subscriptions. It seemed to me that would provide a clean opt-in point for users of lists about to be retired. The process for the moderator-initiated subscription needs to know subscription e-mail addresses for the current members of the to-be-retired list.It depends, of course, on a moderator having the subscriber e-mail addresses, and I did not indicate how that could be solved any more than your experiment did. I think the modifications to ezmlm messages is important regardless. - Dennis STILL THINKING OUT LOUD On the other hand, making moderators of the current list be moderators on the new list and being sure that they notify the list of the move prospect would be a way to subdivide the work with people who presumably do have access to the distribution list of the retiring ML. Those moderators can be expected to follow the rules that apply in their jurisdictions. And wait: Aren't the lists on a US hosted site already? The Oracle Privacy Policy might be the governing situation. Providing an opt-in migration that is not a surprise to the list members, announced clearly in advance, might be a clean way to navigate all of this. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. I don't see how this could work. Maybe if you happen to be a moderator of the legacy list and are willing to take on yourself any personal liability related to data protection laws. But I don't see how this would work in general. Any thing we do to automate this would still require proactive action by the user, either sending an email, clicking a mailto: link in an email, or going to a website and entering their email address. They would need to do an action like that, and then respond to the confirmation email. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were. A valuable way to do this might be to include a link to an English-language version of the message in all NL ones. Pointing to other useful web pages might also be valuable. I notice that ezmlm is designed to work relying on e-mail alone and that should be preserved, but links to web-based support is also valuable and is very useful to link to. The web page could also deal with thing such as what OOo lists does this one replace, where are the archives for the original list(s), etc. OPEN ITEMS It strikes me that there remains the issue I see, in that the ooo-younameit @ i.a.o lists are considerably less friendly than the theynamedit@ OO.o lists. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 07:57 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi! This is the ezmlm program. I'm managing the ooo-dev@incubator.apache.org mailing list. I'm working for my owner, who can be reached at ooo-dev-ow...@incubator.apache.org. To confirm that you would like f...@bar.com added to the ooo-dev mailing list, please send a short reply to this address: ooo-dev-sc.X.X-foo=bar@incubator.apache.org Usually, this happens when you just hit the
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 12:51 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 20, 2011, at 9:20 AM, Rob Weir wrote: On Thu, Oct 20, 2011 at 11:48 AM, Dave Fisher dave2w...@comcast.net wrote: Hi Rob, This is excellent. On Oct 20, 2011, at 7:57 AM, Rob Weir wrote: On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. I'm not a lawyer, but if a user has to approve the new subscription that may be enough to meet even the highest privacy requirements. Next steps if we were to proceed: (1) Getting the emails from Oracle. That may not be possible. It depends on how Oracle understands the ToU for the legacy lists and relevant data protection laws. Corporations tend to be conservative and risk-averse, I do not think they would make this data available to us. You are making an assumption. If we asked for only the map of OOo to real emails so that we can handle the retirement of the forwarder in some way other than the most precipitous (goes away when the OOo MX moves away from Oracle) we might have a chance. I suppose someone will need to ask Andrew Rist. My pessimism based on previous conversations should not deter you, if you want to give this a try. I was speaking only to the technical steps that someone might take. Concrete abilities are good to discuss. I thought you were leading us somewhere. In any case, I look at this a little differently. We don't need pure numbers. We're not looking for passive viewers. If someone is so disengaged that they are unwilling to subscribe to a new list, then they are probably not going to be active project members. And if they find using mailing lists difficult, then maybe we should be pointing them to the phpBB forums, as an easier interface to use? And for ourtreach where we are looking to get the message out to the maximum number of users, then we should be looking at social media; our blog, Twitter, Facebook, etc. I don't want to bikeshed on Social Networks and ML vs. Fora, I want to focus on what is going to actually happen to the OOo MX and ML infrastructure. Focus is good. I'm focusing on the mailing lists. (2) Consider the @openoffice.org forwarder and that many subscriptions to the OOo MLs use that address. If we had that email map even if scrubbed of the name then we can apply that transformation as well. The email forwarding service is something entirely different. I'm not touching that at all in my proposal. It is an independent migration topic. As far as I can tell no one has volunteered to do that. So, you have no real plans to implement re-subscription? Or, if you do you don't have a problem resubscribing people with emails addresses that are going away in another month? Go back and read my proposal. It never mentioned auto-subscribing people. I mentioned the technical details of moderator-initiated subscriptions merely as a follow up to a side proposal that Andrea had made for the Italian lists. The subscribe email sent would then use the personal email. The list of OOo emails would be useful for sending warnings that these vanity ids are going away. It would be great to have a single message about the OOo MX transition. If there is consensus on how we are treating the email forwarder, we can certainly mention that in the post to the lists. But even if we don't have an answer on this yet, we can link to a migration update page that can be kept current with our high-level status of interest to the wider ecosystem. Whatever we say about the OOo ML and MX transition needs to be based in fact and not assumptions. It will be based on consensus, and consensus may be based on assumptions. In any case it will be on the wiki. Edits will be welcome. Of note, securityteam@oo.o is being kept. Are there other community MLs on OOo that should be kept? That's part of your inventory ;-) I'm not touching private lists, at least not initially. I'm looking only at the most-used lists, maybe the top 50 community lists or so. We can iterate. We don't need to do it all at once. There will be community lists in addition to securityteam@ that will need to be considered. The lists are general of three kinds: 1) Project related lists, for people who are working on core product functions, dev, qa, translation, marketing, etc. These naturally fit into the
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 1:14 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Rob, As were you, I was looking at the value of the ezmlm confirmation e-mail and its opt-in requirement for moderator-initiated subscriptions. It seemed to me that would provide a clean opt-in point for users of lists about to be retired. The process for the moderator-initiated subscription needs to know subscription e-mail addresses for the current members of the to-be-retired list. It depends, of course, on a moderator having the subscriber e-mail addresses, and I did not indicate how that could be solved any more than your experiment did. So you are recommending that we send an unsolicited opt-in message to all list subscribers, including the spammers that have taken over many of the lists? Work it through and see what the savings in effort really is for the user: 1) They still need to read two emails: One that tells them to expect an opt-in email and then the actual opt-in notice. If we don't do the first one then the 2nd note will scare many of them, since it appears to come unsolicited. 2) Whatever we do, they still need to respond to the opt-in email 3) The net savings in effort is that the user does not not need to click an initial mailto: link to generate the confirmation email. So in order to save the user a single click, we're going to risk going against data protection laws as well as sending an invite to spammers to join our list? This makes zero sense for me. If you want to do it, then please volunteer. But as an employee of a large multinational corporation that does care about data protection laws, I will not be involved in any such approach. -Rob I think the modifications to ezmlm messages is important regardless. - Dennis STILL THINKING OUT LOUD On the other hand, making moderators of the current list be moderators on the new list and being sure that they notify the list of the move prospect would be a way to subdivide the work with people who presumably do have access to the distribution list of the retiring ML. Those moderators can be expected to follow the rules that apply in their jurisdictions. And wait: Aren't the lists on a US hosted site already? The Oracle Privacy Policy might be the governing situation. Providing an opt-in migration that is not a surprise to the list members, announced clearly in advance, might be a clean way to navigate all of this. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. I don't see how this could work. Maybe if you happen to be a moderator of the legacy list and are willing to take on yourself any personal liability related to data protection laws. But I don't see how this would work in general. Any thing we do to automate this would still require proactive action by the user, either sending an email, clicking a mailto: link in an email, or going to a website and entering their email address. They would need to do an action like that, and then respond to the confirmation email. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were. A valuable way to do this might be to include a link to an English-language version of the message in all NL ones. Pointing to other useful web pages might also be valuable. I notice that ezmlm is designed to work relying on e-mail alone and that should be preserved, but links to web-based support is also valuable and is very useful to link to. The web page could also deal with thing such as what OOo lists does this one replace, where are the archives for the original list(s), etc. OPEN ITEMS It strikes me that there remains the issue I see, in that the ooo-younameit @ i.a.o lists are considerably less friendly than the theynamedit@ OO.o lists. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 07:57 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a
Re: How voting works...
On Thu, Oct 20, 2011 at 12:41 PM, floris v floris...@gmail.com wrote: Op 19-10-2011 14:00, Rob Weir schreef: On Tue, Oct 18, 2011 at 6:50 PM, Ross Gardler rgard...@opendirective.com wrote: I'm not going to dig into all the details of how a vote is called in the ASF. In posting this I am not asking for the current vote to be recalled, there is no need. I am just wanting to flag something that concerns me about how the vote was called (and as per usual this is just advice from a mentor, these are not rules that must be adopted). In an ASF community everyone is entitled to an opinion. Everyone should be encouraged to express that opinion in a formal vote, just as much as they should be encouraged to express their opinions in day to day discussion. We're very concerned, as we should be, to ensure that everyone, even non-PPMC members, can weigh in on all project discussions and decisions, including policy and governance questions. As we should. I applaud that commitment to openness. However, the proposal that we're voting on has this clause regarding the support forums: Forum governance will be discussed in a publicly readable forum. Write access will be limited to those with at least 10 posts. In other words, we're agreeing to a proposal where it is not true that In an ASF community everyone is entitled to an opinion. Everyone should be encouraged to express that opinion in a formal vote, just as much as they should be encouraged to express their opinions in day to day discussion. *You're forgetting that the forums aren't an almost closed mailing list like ooo-dev. How many people are subscribed to ooo-dev? As of 9/20 the number of registered users of the forums is 44830 and the number of people with over 10 posts still exceeds 1000. If we'd open the gates to anyone, you'd probably soon see bored kids pollute the discussions with the kind of crap that they now post on Wikipedia. If you don't like the forum, I suggest that you just ignore it. I do care about the forums. That is why in my feedback I said that I was concerned that your over-cautious approach cuts you off from potential sources of useful community feedback. You already have the ability to remove posts and users who violate the board standards. But these should be conduct standards, but post count standards. You might have the most brilliant observation come from a new user on their first day on the list. I don't think you should assume that just because someone has made 10 posts on spreadsheet import filters, that their observations on forum governance are worth hearing, but someone who has only posted 8 is not worth hearing. This is very un-Apache. My opinion, of course. And keep in mind that Apache has large mailing lists as well. users @ tomcat.apache.org has over 3200, for example. -Rob **Peter aka floris v* ** When I brought that up in the discussion thread I was shut down by a mentor for introducing an overly legalistic parsing of the proposal. I take that to mean I was thinking too much. I'll stop now, because honestly the incongruity if our words and actions is shameful and painful to observe. -Rob It is true that only some members of the community have binding votes. However, this only becomes important in the event of an absence of community consensus. Therefore, when calling a vote please do not word it in such a way that implies others in the community do not have a vote that counts. It does count. A responsible PPMC member will use their own vote to support any appropriate objections from the community. They can only do that if the community is encouraged to express their views alongside everyone else.. Specifically, there is no need to define binding votes in the vote thread, the way Apache Projects vote is well documented and, over time, the AOOo project will gain its own guidelines. Secondly, do not list the people who are important enough to have a binding vote. Thirdly, explicitly call for all community members to express their preferences in the vote. In other words, make every action of the PPMC as inclusive as possible. Finally, Denis - thank you for calling the vote. Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
RE: [Proposal] Shutting down legacy OOo mailing lists
I did not assert anything about how the auto-subscription offer is done. I did note that the lists may already be in the custody of a US-hosted system, so transnational border crossing is not involved in any movement of subscribers. Since this is an opt-in, not an opt-out procedure, it might be considered that the benefit far outweighs the harm. Of course, this is all speculative because there is likely not time to do any of these things. My thinking is that the current moderators be the ones best able to determine which subscribers are real. Also, the current moderators, if they can be found, are appropriate folks for notifying the lists they moderate of the imminent retirement, the opportunity to subscribe to ooo-listX@ i.a.o, and of the plan to offer them an opt-in message for subscription to ooo-listX. Also for translating ezmlm messages into the native language that is the working language of a particular list. There are problems when moderators have absented themselves. Regina just posted a message on ooo-dev looking for a moderator of users@ de.openoffice.org to solve a problem with an user who can't find a way to unsubscribe and whose efforts at following the various instructions have failed. So there is a problem with moderator abandonment. It is clear that there are any number of folks still on that list who could moderate it, if there was a way to grant moderation. Maybe that is something Andrew Rist can help with. With regard to pulling the plug, I am not sure how it is possible to even warn folks of this, unless material can be put in known web locations that informs list users of the possible sudden retirement of the lists they subscribe to. Again, our not having the keys to openoffice.org properties is a barrier. It might fall on us bloggers to have a joint message that is propagated as far as our reach allows, including the podling blog. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 10:24 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 1:14 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Rob, As were you, I was looking at the value of the ezmlm confirmation e-mail and its opt-in requirement for moderator-initiated subscriptions. It seemed to me that would provide a clean opt-in point for users of lists about to be retired. The process for the moderator-initiated subscription needs to know subscription e-mail addresses for the current members of the to-be-retired list.It depends, of course, on a moderator having the subscriber e-mail addresses, and I did not indicate how that could be solved any more than your experiment did. So you are recommending that we send an unsolicited opt-in message to all list subscribers, including the spammers that have taken over many of the lists? Work it through and see what the savings in effort really is for the user: 1) They still need to read two emails: One that tells them to expect an opt-in email and then the actual opt-in notice. If we don't do the first one then the 2nd note will scare many of them, since it appears to come unsolicited. 2) Whatever we do, they still need to respond to the opt-in email 3) The net savings in effort is that the user does not not need to click an initial mailto: link to generate the confirmation email. So in order to save the user a single click, we're going to risk going against data protection laws as well as sending an invite to spammers to join our list? This makes zero sense for me. If you want to do it, then please volunteer. But as an employee of a large multinational corporation that does care about data protection laws, I will not be involved in any such approach. -Rob I think the modifications to ezmlm messages is important regardless. - Dennis STILL THINKING OUT LOUD On the other hand, making moderators of the current list be moderators on the new list and being sure that they notify the list of the move prospect would be a way to subdivide the work with people who presumably do have access to the distribution list of the retiring ML. Those moderators can be expected to follow the rules that apply in their jurisdictions. And wait: Aren't the lists on a US hosted site already? The Oracle Privacy Policy might be the governing situation. Providing an opt-in migration that is not a surprise to the list members, announced clearly in advance, might be a clean way to navigate all of this. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 1:55 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: I did not assert anything about how the auto-subscription offer is done. I did note that the lists may already be in the custody of a US-hosted system, so transnational border crossing is not involved in any movement of subscribers. Since this is an opt-in, not an opt-out procedure, it might be considered that the benefit far outweighs the harm. Of course, this is all speculative because there is likely not time to do any of these things. It still comes down to saving a single mouse click, while also gaining more spammers. So the argument is not very persuasive, IMHO. My thinking is that the current moderators be the ones best able to determine which subscribers are real. Also, the current moderators, if they can be found, are appropriate folks for notifying the lists they moderate of the imminent retirement, the opportunity to subscribe to ooo-listX@ i.a.o, and of the plan to offer them an opt-in message for subscription to ooo-listX. Also for translating ezmlm messages into the native language that is the working language of a particular list. Volunteers are welcome, to translate and send out the notice to the various lists. This includes legacy list moderators. There will be a place on the wiki page for anyone to affix their name. I'll send out a note for any lists that receive no other volunteers. There is a moderator list at OOo. I can send them a note at the same time I notify the PPMC that I have the initial migration list ready for review. That way any existing moderators can jump in if they want. There are problems when moderators have absented themselves. Regina just posted a message on ooo-dev looking for a moderator of users@ de.openoffice.org to solve a problem with an user who can't find a way to unsubscribe and whose efforts at following the various instructions have failed. So there is a problem with moderator abandonment. It is clear that there are any number of folks still on that list who could moderate it, if there was a way to grant moderation. Maybe that is something Andrew Rist can help with. As you know, users will always have problems with mailing lists. This will be true on Apache lists as well. I think one thing we'll want to do is cross-promote the user forums in the initial post, at least the post to the user forums. With regard to pulling the plug, I am not sure how it is possible to even warn folks of this, unless material can be put in known web locations that informs list users of the possible sudden retirement of the lists they subscribe to. Again, our not having the keys to openoffice.org properties is a barrier. It might fall on us bloggers to have a joint message that is propagated as far as our reach allows, including the podling blog. Why do you think sending notes to the lists themselves would be inadequate? Isn't that the most direct and logical way to engage with a list subscriber? The number of list subscribers that also read the project blog is probably miniscule. And those would be the ones that are already more engaged and know what is going on. But you are welcome to do a blog post on this if you want. -Rob - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 10:24 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 1:14 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Rob, As were you, I was looking at the value of the ezmlm confirmation e-mail and its opt-in requirement for moderator-initiated subscriptions. It seemed to me that would provide a clean opt-in point for users of lists about to be retired. The process for the moderator-initiated subscription needs to know subscription e-mail addresses for the current members of the to-be-retired list. It depends, of course, on a moderator having the subscriber e-mail addresses, and I did not indicate how that could be solved any more than your experiment did. So you are recommending that we send an unsolicited opt-in message to all list subscribers, including the spammers that have taken over many of the lists? Work it through and see what the savings in effort really is for the user: 1) They still need to read two emails: One that tells them to expect an opt-in email and then the actual opt-in notice. If we don't do the first one then the 2nd note will scare many of them, since it appears to come unsolicited. 2) Whatever we do, they still need to respond to the opt-in email 3) The net savings in effort is that the user does not not need to click an initial mailto: link to generate the confirmation email. So in order to save the user a single click, we're going to risk going against data protection laws as well as sending an invite to spammers to join our list?
Re: [Proposal] Shutting down legacy OOo mailing lists
Do any of these lists have publicly accessible archives? It would be a shame to lose those, when the lists shut down. I suspect messages about OOo 1.x are pretty much dead, or at least the software is pretty much obsoleted. Those archives might be less useful. Just wondering.. -- This Apt Has Super Cow Powers - http://sourcefreedom.com
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 2:15 PM, Wolf Halton wolf.hal...@gmail.com wrote: Do any of these lists have publicly accessible archives? It would be a shame to lose those, when the lists shut down. I suspect messages about OOo 1.x are pretty much dead, or at least the software is pretty much obsoleted. Those archives might be less useful. Yes, there is a MarkMail archive of 333 OOo mailing lists, 1.6 million messages, going back to the project's start in 2000. See: http://openoffice.markmail.org/ What may be missing are archives of any private mailing lists. -Rob Just wondering.. -- This Apt Has Super Cow Powers - http://sourcefreedom.com
Re: [Proposal] Renaming of OpenOffice.org
On Tue, Oct 18, 2011 at 7:14 PM, TJ Frazier tjfraz...@cfl.rr.com wrote: On 10/18/2011 18:53, Kay Schenk wrote: On 10/18/2011 02:58 PM, Jürgen Schmidt wrote: massive snippery snip-ectomy Why not have both Apache Open Office and OpenOffice.org? 1) We already have both and people are getting used to that who are liable to do so. 2) Other brands have started using other names for themselves and for their products without much confusion. Daimler Chrysler Dodge Ram? All brand names for pickup trucks, which have almost no name at all (1500, 2500, 3500). This is an egregious example of a messy name that consumers have no troub;le sorting out. -- This Apt Has Super Cow Powers - http://sourcefreedom.com
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 2:28 PM, Rob Weir robw...@apache.org wrote: On Thu, Oct 20, 2011 at 2:15 PM, Wolf Halton wolf.hal...@gmail.com wrote: Do any of these lists have publicly accessible archives? It would be a shame to lose those, when the lists shut down. I suspect messages about OOo 1.x are pretty much dead, or at least the software is pretty much obsoleted. Those archives might be less useful. Yes, there is a MarkMail archive of 333 OOo mailing lists, 1.6 million messages, going back to the project's start in 2000. See: http://openoffice.markmail.org/ What may be missing are archives of any private mailing lists. -Rob Just wondering.. Will those archives be brought into ASF, do you think, or are we to find a place for them outside the fold? -Wolf -- This Apt Has Super Cow Powers - http://sourcefreedom.com
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 2:31 PM, Wolf Halton wolf.hal...@gmail.com wrote: On Thu, Oct 20, 2011 at 2:28 PM, Rob Weir robw...@apache.org wrote: On Thu, Oct 20, 2011 at 2:15 PM, Wolf Halton wolf.hal...@gmail.com wrote: Do any of these lists have publicly accessible archives? It would be a shame to lose those, when the lists shut down. I suspect messages about OOo 1.x are pretty much dead, or at least the software is pretty much obsoleted. Those archives might be less useful. Yes, there is a MarkMail archive of 333 OOo mailing lists, 1.6 million messages, going back to the project's start in 2000. See: http://openoffice.markmail.org/ What may be missing are archives of any private mailing lists. -Rob Just wondering.. Will those archives be brought into ASF, do you think, or are we to find a place for them outside the fold? I think they already have a place: markmail.org. I'm not proposing to do anything beyond that. But if someone wants to volunteer to make an additional archival copy, they are welcome to try. -Wolf -- This Apt Has Super Cow Powers - http://sourcefreedom.com
Re: [Proposal] Shutting down legacy OOo mailing lists
Hi Rob, Your technical item was an interesting distraction. It may have a use. I think below you give a good explanation of your plan. Let me express a recommendation that ought to alleviate my concerns about the full MX issues. I am still concerned that we may be abandoning a database of over 450,000 OOo users, but that is another, related, topic. On Oct 20, 2011, at 10:24 AM, Rob Weir wrote: On Thu, Oct 20, 2011 at 1:14 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Rob, As were you, I was looking at the value of the ezmlm confirmation e-mail and its opt-in requirement for moderator-initiated subscriptions. It seemed to me that would provide a clean opt-in point for users of lists about to be retired. The process for the moderator-initiated subscription needs to know subscription e-mail addresses for the current members of the to-be-retired list.It depends, of course, on a moderator having the subscriber e-mail addresses, and I did not indicate how that could be solved any more than your experiment did. So you are recommending that we send an unsolicited opt-in message to all list subscribers, including the spammers that have taken over many of the lists? Work it through and see what the savings in effort really is for the user: 1) They still need to read two emails: One that tells them to expect an opt-in email and then the actual opt-in notice. If we don't do the first one then the 2nd note will scare many of them, since it appears to come unsolicited. 2) Whatever we do, they still need to respond to the opt-in email 3) The net savings in effort is that the user does not not need to click an initial mailto: link to generate the confirmation email. So in order to save the user a single click, we're going to risk going against data protection laws as well as sending an invite to spammers to join our list? Got it. One email - repeated. If the text around the mailto: informs the user not to use an @openoffice.org address for their new subscription then my concerns are moot. It should be something like All personal @openoffice.org email address forwarders will be dropped on migration. The text of this email needs to be carefully considered on ooo-dev. Since you plan a review then I am fine. I also think that the one (or more) OOo legacy ML that are being continued should be clearly mentioned as well. Look at this email as the one opportunity to get a clear message about AOOo out to all of these subscribers. We have a difficult story for the user and it needs to be the most positive and consistent message possible. This makes zero sense for me. If you want to do it, then please volunteer. But as an employee of a large multinational corporation that does care about data protection laws, I will not be involved in any such approach. I am looking at this as due diligence before making a decision where there is no going back. Regards, Dave -Rob I think the modifications to ezmlm messages is important regardless. - Dennis STILL THINKING OUT LOUD On the other hand, making moderators of the current list be moderators on the new list and being sure that they notify the list of the move prospect would be a way to subdivide the work with people who presumably do have access to the distribution list of the retiring ML. Those moderators can be expected to follow the rules that apply in their jurisdictions. And wait: Aren't the lists on a US hosted site already? The Oracle Privacy Policy might be the governing situation. Providing an opt-in migration that is not a surprise to the list members, announced clearly in advance, might be a clean way to navigate all of this. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. I don't see how this could work. Maybe if you happen to be a moderator of the legacy list and are willing to take on yourself any personal liability related to data protection laws. But I don't see how this would work in general. Any thing we do to automate this would still require proactive action by the user, either sending an email, clicking a mailto: link in an email, or going to a website and entering their email address. They would need to do an action like that, and then respond to the confirmation email. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were.
How to handle the native language lists?
This question came up a few months ago, when we initially started the podling. The legacy OOo project had many mailing lists which were for non-English list traffic. This included user lists as well as project lists (marketing and translation mainly). Many of these lists are showing up in my survey of the most-used lists in OOo, the list I'm using for migration planning. We've deferred resolving this question so far. I think we've run out of time. We can't delay figuring this much longer. So what do we want to do with these lists, and more importantly, with the community on these lists? The native language communities are an important part of the vitality of the OOo community, and we need to agree on a good way to integrate them into the AOOo community. On the other hand, we don't want to fragment the community into very many small compartments, were we are ineffective in combining our strengths together to solve larger problems and undertake larger initiatives. So we need some sort of balance. OOo, with its 300+ mailing lists, probably did not achieve the optimal balance. Let's see if we can do better. Proposal: 1) Create a single user-language list for each native language where there is an active user list today, and where we can identify three committed moderators, preferably at least one from the PMC. If there is currently a discuss list as well as a user list in that language, combine then into the user list. Currently, that would mean the creation of the following new lists (assuming we find moderators), like: ooo-users-de (German) ooo-users-fr (French) ooo-users-it (Italian) ooo-users-es (Spanish) ooo-users-br-pt (Brazilian Portuguese) (or can we generalize this to pt in general?) ooo-nl (Dutch) ooo-ja (Japanese) There may be other language we want to cover as well.The list above is intended to illustrative, not exclusive. The important thing is that when dealing with users, we need to meet them on their terms, not ours. The request for at least three moderators is because a user list needs more than just spam protection. We need moderators committed to actively participate on those lists. A user list that has been abandoned is very bad for the image of the project. Since the PPMC cannot easily monitor what is happening on a non-English mailing list, we will need to have high confidence that there are sufficient volunteers on the list to make it succeed. 2) For project-related (as opposed to user-related) lists, align them with the closest existing AOOo list. For example: de.business -- ooo-marketing nl.marketing -- ooo-marketing fr.dev -- ooo-dev and so on. We're a single Apache project with a single product. Although there may be local marketing efforts, there should be a single marketing conversation. Ditto for other aspects of the project. The net result will be take 300+ existing OOo mailing lists and map them to a much smaller number of AOOo mailing lists, maybe a dozen total in the end. This will require understanding and good will from all. Non-native English speakers and native speakers will need to adjust how they interact, and in general be more understanding. So that's my proposal. I have my asbestos underwear on. Feel free to start the flaming, -Rob
Re: [Proposal] Shutting down legacy OOo mailing lists
On Thu, Oct 20, 2011 at 2:53 PM, Dave Fisher dave2w...@comcast.net wrote: Hi Rob, Your technical item was an interesting distraction. It may have a use. I think below you give a good explanation of your plan. Let me express a recommendation that ought to alleviate my concerns about the full MX issues. I am still concerned that we may be abandoning a database of over 450,000 OOo users, but that is another, related, topic. On Oct 20, 2011, at 10:24 AM, Rob Weir wrote: On Thu, Oct 20, 2011 at 1:14 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Rob, As were you, I was looking at the value of the ezmlm confirmation e-mail and its opt-in requirement for moderator-initiated subscriptions. It seemed to me that would provide a clean opt-in point for users of lists about to be retired. The process for the moderator-initiated subscription needs to know subscription e-mail addresses for the current members of the to-be-retired list. It depends, of course, on a moderator having the subscriber e-mail addresses, and I did not indicate how that could be solved any more than your experiment did. So you are recommending that we send an unsolicited opt-in message to all list subscribers, including the spammers that have taken over many of the lists? Work it through and see what the savings in effort really is for the user: 1) They still need to read two emails: One that tells them to expect an opt-in email and then the actual opt-in notice. If we don't do the first one then the 2nd note will scare many of them, since it appears to come unsolicited. 2) Whatever we do, they still need to respond to the opt-in email 3) The net savings in effort is that the user does not not need to click an initial mailto: link to generate the confirmation email. So in order to save the user a single click, we're going to risk going against data protection laws as well as sending an invite to spammers to join our list? Got it. One email - repeated. If the text around the mailto: informs the user not to use an @openoffice.org address for their new subscription then my concerns are moot. It should be something like All personal @openoffice.org email address forwarders will be dropped on migration. OOo was providing only a forwarder, right? No SMTP server for sending an email from an @openoffice.org address. So this might solve itself by the nature of how a user signs up for the list, i.e., by sending an email from a non-openoffice.org email address. Or would spoofed return addresses as GMail does them be an issue? Do you know off hand if our ezmlm subscribes users via spoofed addresses? Or would it only take the real address? But if technical means are not sufficient, then a message, along the lines you suggest would work. The text of this email needs to be carefully considered on ooo-dev. Since you plan a review then I am fine. I also think that the one (or more) OOo legacy ML that are being continued should be clearly mentioned as well. Look at this email as the one opportunity to get a clear message about AOOo out to all of these subscribers. We have a difficult story for the user and it needs to be the most positive and consistent message possible. In some cases this may be the first time that a subscriber has heard from us. So yes, we need to make a good first impression. We're trying to start or continue a relationship with them. This makes zero sense for me. If you want to do it, then please volunteer. But as an employee of a large multinational corporation that does care about data protection laws, I will not be involved in any such approach. I am looking at this as due diligence before making a decision where there is no going back. Regards, Dave -Rob I think the modifications to ezmlm messages is important regardless. - Dennis STILL THINKING OUT LOUD On the other hand, making moderators of the current list be moderators on the new list and being sure that they notify the list of the move prospect would be a way to subdivide the work with people who presumably do have access to the distribution list of the retiring ML. Those moderators can be expected to follow the rules that apply in their jurisdictions. And wait: Aren't the lists on a US hosted site already? The Oracle Privacy Policy might be the governing situation. Providing an opt-in migration that is not a surprise to the list members, announced clearly in advance, might be a clean way to navigate all of this. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the
Re: How to handle the native language lists?
On Thu, Oct 20, 2011 at 8:04 PM, Rob Weir robw...@apache.org wrote: This question came up a few months ago, when we initially started the podling. The legacy OOo project had many mailing lists which were for non-English list traffic. snip So that's my proposal. I have my asbestos underwear on. Feel free to start the flaming, :-) (In these sorts of circumstances, I tend to deploy the infamous strawman phraseology rather than proposal) Robert
[DISCUSS] Bugzilla Admin (was RE: Bugzilla notifications not going to an ASF mailing list)
I believe the next-action on administration of the ooo-bz is ours. It looks like there need to be some @apache.org administrators, and the hierarchy of administration with respect to the various categories also needs to be dealt with. From the list that Mark Thomas provided, I only see 2 apache.org e-mail addresses that have administrative logins, Mark Thomas himself and Herbert Dürr. The rest are openoffice.org addresses of people who may or may not be here, may or may not be committers/PPMC members. They might not have even restored access to their bugzilla account after the move, but I suspect they are still getting automated traffic from ooo-bz!?. My thought is that this is an appropriate migration case to handle with more detail on OOOUSER. I am raising this flag for discussion. I think a couple of admins should be nominated and option 2 taken. The mapping could be explained on the wiki. Who already knows enough ins-and-outs of Bugzilla administration to land running? - Dennis I would also like to know as soon as possible where bugs about the ooo-bz itself can be posted. There are also migration-completion actions to be worked through (maybe on OOOUSER in concept with individual concrete actionables as ooo-bz tasks? -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, October 14, 2011 15:32 To: OOo-dev Apache Incubator Cc: Apache Infrastructure Subject: Re: Bugzilla notifications not going to an ASF mailing list On 14/10/2011 18:34, Dave Fisher wrote: Hi Mark, Thanks. I believe that the podling PPMC needs to make sure there are people who are able to be sysadmins. Agreed. A quick glance at the lists below suggests that quite a few additional admins are required. Option 1: Identify a few folks to be in the admin group who can then add other users to groups as required and provide the list of login_names to infra. Option 2: Same as 1 plus provide infra with a suitably formatted list (plain text) of login_name to group name mappings that you want created in bulk as a one-off In both cases, the OOo project would manage users of the OOo Bz instance moving forwards. Please create an infrastructure Jira ticket when you are ready to take this forward. Is it possible for you to identify who currently has a sysadmin role in the AOOo BZ. Send it to ooo-private if you prefer. The current mapping of users to admin roles for active users (those that have reset their password) is as follows: +---+--+ | login_name| name | +---+--+ | ma...@apache.org | admin| | ma...@apache.org | admin| | j...@openoffice.org| api-admin| | j...@openoffice.org| bizdev-admin | | j...@openoffice.org| certification-admin | | pja...@openoffice.org | cs-admin | | j...@openoffice.org| education-admin | | j...@openoffice.org| es-admin | | j...@openoffice.org| extensions-admin | | m...@openoffice.org| framework-admin | | c...@openoffice.org | graphics-admin | | h...@apache.org| gsl-admin| | ti...@openoffice.org | hu-admin | | r4z...@openoffice.org | hu-admin | | cl...@openoffice.org | infrastructure-admin | | pesce...@openoffice.org | it-admin | | o...@erack.de | l10n-admin | | pja...@openoffice.org | l10n-admin | | nem...@openoffice.org | lingucomponent-admin | | joost.and...@gmx.de | qa-admin | | o...@erack.de | sc-admin | | goranra...@openoffice.org | sr-admin | | m...@openoffice.org| sw-admin | | c...@openoffice.org| sw-admin | | orwittm...@googlemail.com | sw-admin | | s...@openoffice.org | udk-admin| | o...@openoffice.org | ui-admin | +---+--+ The current mapping of all users to admin roles is: +---+--+ | login_name| name | +---+--+ | kenaiad...@openoffice.org | aa-admin | | ooo...@openoffice.org | aa-admin | | admin...@openoffice.org | aa-admin | | s...@openoffice.org | about-admin | | kenaiad...@openoffice.org | about-admin | | ma...@apache.org | admin| | ma...@apache.org | admin| | lo...@openoffice.org | af-admin | | kenaiad...@openoffice.org | af-admin | | fwo...@openoffice.org |
Re: How to handle the native language lists?
A strong +1 - this is consistent with my memory of what was discussed three months ago. On Oct 20, 2011, at 12:04 PM, Rob Weir wrote: This question came up a few months ago, when we initially started the podling. The legacy OOo project had many mailing lists which were for non-English list traffic. This included user lists as well as project lists (marketing and translation mainly). Many of these lists are showing up in my survey of the most-used lists in OOo, the list I'm using for migration planning. We've deferred resolving this question so far. I think we've run out of time. We can't delay figuring this much longer. So what do we want to do with these lists, and more importantly, with the community on these lists? The native language communities are an important part of the vitality of the OOo community, and we need to agree on a good way to integrate them into the AOOo community. On the other hand, we don't want to fragment the community into very many small compartments, were we are ineffective in combining our strengths together to solve larger problems and undertake larger initiatives. So we need some sort of balance. OOo, with its 300+ mailing lists, probably did not achieve the optimal balance. Let's see if we can do better. Proposal: 1) Create a single user-language list for each native language where there is an active user list today, and where we can identify three committed moderators, preferably at least one from the PMC. We might quibble with the number. For some two might be sufficient. If there is currently a discuss list as well as a user list in that language, combine then into the user list. Currently, that would mean the creation of the following new lists (assuming we find moderators), like: ooo-users-de (German) ooo-users-fr (French) ooo-users-it (Italian) ooo-users-es (Spanish) ooo-users-br-pt (Brazilian Portuguese) (or can we generalize this to pt in general?) ooo-nl (Dutch) ooo-ja (Japanese) While the forum people aren't ML people they will certainly have a sense for the languages that they support. Someone made a comment about Vietnamese being a problem right now. I'd like to know which Languages might be abandoned. I know that in the website there are two levels of support described. The range of NL projects with more than a placeholder for a website would be interesting. There may be other language we want to cover as well.The list above is intended to illustrative, not exclusive. The important thing is that when dealing with users, we need to meet them on their terms, not ours. The request for at least three moderators is because a user list needs more than just spam protection. We need moderators committed to actively participate on those lists. A user list that has been abandoned is very bad for the image of the project. Since the PPMC cannot easily monitor what is happening on a non-English mailing list, we will need to have high confidence that there are sufficient volunteers on the list to make it succeed. 2) For project-related (as opposed to user-related) lists, align them with the closest existing AOOo list. For example: de.business -- ooo-marketing nl.marketing -- ooo-marketing fr.dev -- ooo-dev Here is what people might debate, but I like the inclusive direction. and so on. We're a single Apache project with a single product. Although there may be local marketing efforts, there should be a single marketing conversation. Ditto for other aspects of the project. The net result will be take 300+ existing OOo mailing lists and map them to a much smaller number of AOOo mailing lists, maybe a dozen total in the end. This will require understanding and good will from all. Non-native English speakers and native speakers will need to adjust how they interact, and in general be more understanding. So that's my proposal. I have my asbestos underwear on. Feel free to start the flaming, Regards, Dave -Rob
Re: [DISCUSS] Bugzilla Admin (was RE: Bugzilla notifications not going to an ASF mailing list)
On Oct 20, 2011, at 12:20 PM, Dennis E. Hamilton wrote: I believe the next-action on administration of the ooo-bz is ours. It looks like there need to be some @apache.org administrators, and the hierarchy of administration with respect to the various categories also needs to be dealt with. From the list that Mark Thomas provided, I only see 2 apache.org e-mail addresses that have administrative logins, Mark Thomas himself and Herbert Dürr. The rest are openoffice.org addresses of people who may or may not be here, may or may not be committers/PPMC members. They might not have even restored access to their bugzilla account after the move, but I suspect they are still getting automated traffic from ooo-bz!?. Most of these are here and on the PPMC. jza, jsc, pjanik, r4zoli, pescetti, ... But it is a long list. I think we need a languages properties file with items like BZ, Forum, ML, Language Pack, etc. My thought is that this is an appropriate migration case to handle with more detail on OOOUSER. Yes. I am raising this flag for discussion. I think a couple of admins should be nominated and option 2 taken. The mapping could be explained on the wiki. Who already knows enough ins-and-outs of Bugzilla administration to land running? Volunteers? Leaders? Let's not all step backwards at once :-) Regards, Dave - Dennis I would also like to know as soon as possible where bugs about the ooo-bz itself can be posted. There are also migration-completion actions to be worked through (maybe on OOOUSER in concept with individual concrete actionables as ooo-bz tasks? -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, October 14, 2011 15:32 To: OOo-dev Apache Incubator Cc: Apache Infrastructure Subject: Re: Bugzilla notifications not going to an ASF mailing list On 14/10/2011 18:34, Dave Fisher wrote: Hi Mark, Thanks. I believe that the podling PPMC needs to make sure there are people who are able to be sysadmins. Agreed. A quick glance at the lists below suggests that quite a few additional admins are required. Option 1: Identify a few folks to be in the admin group who can then add other users to groups as required and provide the list of login_names to infra. Option 2: Same as 1 plus provide infra with a suitably formatted list (plain text) of login_name to group name mappings that you want created in bulk as a one-off In both cases, the OOo project would manage users of the OOo Bz instance moving forwards. Please create an infrastructure Jira ticket when you are ready to take this forward. Is it possible for you to identify who currently has a sysadmin role in the AOOo BZ. Send it to ooo-private if you prefer. The current mapping of users to admin roles for active users (those that have reset their password) is as follows: +---+--+ | login_name| name | +---+--+ | ma...@apache.org | admin| | ma...@apache.org | admin| | j...@openoffice.org| api-admin| | j...@openoffice.org| bizdev-admin | | j...@openoffice.org| certification-admin | | pja...@openoffice.org | cs-admin | | j...@openoffice.org| education-admin | | j...@openoffice.org| es-admin | | j...@openoffice.org| extensions-admin | | m...@openoffice.org| framework-admin | | c...@openoffice.org | graphics-admin | | h...@apache.org| gsl-admin| | ti...@openoffice.org | hu-admin | | r4z...@openoffice.org | hu-admin | | cl...@openoffice.org | infrastructure-admin | | pesce...@openoffice.org | it-admin | | o...@erack.de | l10n-admin | | pja...@openoffice.org | l10n-admin | | nem...@openoffice.org | lingucomponent-admin | | joost.and...@gmx.de | qa-admin | | o...@erack.de | sc-admin | | goranra...@openoffice.org | sr-admin | | m...@openoffice.org| sw-admin | | c...@openoffice.org| sw-admin | | orwittm...@googlemail.com | sw-admin | | s...@openoffice.org | udk-admin| | o...@openoffice.org | ui-admin | +---+--+ The current mapping of all users to admin roles is: +---+--+ | login_name| name | +---+--+ | kenaiad...@openoffice.org | aa-admin | | ooo...@openoffice.org | aa-admin | | admin...@openoffice.org
Re: Is the JRE license OK for inclusing in AOO?
On Thu, Oct 20, 2011 at 5:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: snip It is not clear to me that either of those bundlings in binary releases is explicitly tolerated by the information that is provided at http://apache.org/legal/resolved.html. There seems to be no help in the older draft either: http://apache.org/legal/3party.html. I also note that if one is bundling the JVM or building Windows distributions, there are library dependencies and API dependencies too, somewhere deep in the works. (The LibreOffice folk have apparently stopped any JVM bundling but I don't know what they do about Microsoft redistributables.) It seems that there is more that needs to be said about binary releases and how non-source, restrictive-license redistributables are incorporated in those releases to satisfy installation requirements and also provide run-time services to an Apache release. I thought I saw how that was tolerable so long as no source was provided and the redistribution terms were honored, NOTICE was provided, etc. I can't find anything clear-cut on looking again. IIRC Apache has historically strongly disliked but tolerated releases containing non-open-source but appropriately redistributable artifacts. When there is no clear consensus, there will be no clear policy. Would any of the open source options for executing Java code (Harmony, OpenJDK, etc) work? Robert
Re: License implications of build-time or test-time dependencies?
On Thu, Oct 20, 2011 at 12:08 PM, Pedro Giffuni p...@apache.org wrote: Hmm ... We have discussed some of the things that must be replaced but we have not drawn a roadmap about it beyond the initial migration list. I think we will have to open BZ issues for those. The gtk/qt issue is rather critcal: I do not think there is previous history among Apache projects depending on them but if we cannot consider those system provided libraries it would be a serious setback to an early Apache release. I would support allowing C/C++ code to link to gtk and/or qt, provided we don't distribute gtk or qt themselves. Both are LGPL. The LGPL is clear for languages like C, C++. Pedro.
RE: [DISCUSS] Bugzilla Admin (was RE: Bugzilla notifications not going to an ASF mailing list)
I don't understand what this means: I think we need a languages properties file with items like BZ, Forum, ML, Language Pack, etc. - Dennis -Original Message- From: Dave Fisher [mailto:dave2w...@comcast.net] Sent: Thursday, October 20, 2011 12:29 To: ooo-dev@incubator.apache.org Subject: Re: [DISCUSS] Bugzilla Admin (was RE: Bugzilla notifications not going to an ASF mailing list) On Oct 20, 2011, at 12:20 PM, Dennis E. Hamilton wrote: I believe the next-action on administration of the ooo-bz is ours. It looks like there need to be some @apache.org administrators, and the hierarchy of administration with respect to the various categories also needs to be dealt with. From the list that Mark Thomas provided, I only see 2 apache.org e-mail addresses that have administrative logins, Mark Thomas himself and Herbert Dürr. The rest are openoffice.org addresses of people who may or may not be here, may or may not be committers/PPMC members. They might not have even restored access to their bugzilla account after the move, but I suspect they are still getting automated traffic from ooo-bz!?. Most of these are here and on the PPMC. jza, jsc, pjanik, r4zoli, pescetti, ... But it is a long list. I think we need a languages properties file with items like BZ, Forum, ML, Language Pack, etc. My thought is that this is an appropriate migration case to handle with more detail on OOOUSER. Yes. I am raising this flag for discussion. I think a couple of admins should be nominated and option 2 taken. The mapping could be explained on the wiki. Who already knows enough ins-and-outs of Bugzilla administration to land running? Volunteers? Leaders? Let's not all step backwards at once :-) Regards, Dave [ ... ]
Re: License implications of build-time or test-time dependencies?
On Thu, Oct 20, 2011 at 4:07 PM, Sam Ruby ru...@intertwingly.net wrote: On Thu, Oct 20, 2011 at 12:08 PM, Pedro Giffuni p...@apache.org wrote: Hmm ... We have discussed some of the things that must be replaced but we have not drawn a roadmap about it beyond the initial migration list. I think we will have to open BZ issues for those. The gtk/qt issue is rather critcal: I do not think there is previous history among Apache projects depending on them but if we cannot consider those system provided libraries it would be a serious setback to an early Apache release. I would support allowing C/C++ code to link to gtk and/or qt, provided we don't distribute gtk or qt themselves. Both are LGPL. The LGPL is clear for languages like C, C++. Clear in what sense? Dynamic linking and such? Pedro.
Re: [licensing] On Apache Releases [WAS Re: Clarification on treatment of weak copyleft components]
On Thu, Oct 20, 2011 at 9:01 PM, Rob Weir robw...@apache.org wrote: On Thu, Oct 20, 2011 at 9:06 AM, Robert Burrell Donkin snip At Apache, a source release is (just) what's in version control when the release is cut, is canonical and mandatory. Other artifacts follow the binary release rules, are optional and secondary. OK. So obviously no weak copyleft source files in our source release, i.e., in our source tarballs. +1 snip The approach we currently have for these components, in OpenOffice, is: 1) The 3rd party components are stored in a separate repository, not with the core product's SVN. So we reduce the opportunity for contamination. 2) The build script downloads the source for these components and compiles them. So we avoid the pre-req/provisioning issue. And we don't need to include the MPL code in the source distribution. It comes down automatically at build time, That may satisfy the letter of what I'm reading. But I'd be interested to hear what you think, whether something like that had been done at Apache before. Most projects use this sort of approach (though there is a strong minority view that thinks that they are wrong to do so) There has been historic resistance to hosting weak copyleft source at Apache but there's now a consensus that requirements to supply source in perpetuity mean that we'll have to host it sooner or later, most likely in a separate repository. Maybe it would be better, for example, to allow two build modes, one with and one without the copyleft components, and force the downstream developer to explicitly enable the compilation with weak copyleft components by changing a flag or something? Always a good idea to let developers know what's happening Some downstream consumers (in particular, packagers) want to compile against their own system dependencies so IMHO it'd be cleaner just to switch on or off dependency download, preferrably with fine control. Robert
Re: License implications of build-time or test-time dependencies?
On Thu, Oct 20, 2011 at 4:37 PM, Rob Weir robw...@apache.org wrote: On Thu, Oct 20, 2011 at 4:07 PM, Sam Ruby ru...@intertwingly.net wrote: On Thu, Oct 20, 2011 at 12:08 PM, Pedro Giffuni p...@apache.org wrote: Hmm ... We have discussed some of the things that must be replaced but we have not drawn a roadmap about it beyond the initial migration list. I think we will have to open BZ issues for those. The gtk/qt issue is rather critcal: I do not think there is previous history among Apache projects depending on them but if we cannot consider those system provided libraries it would be a serious setback to an early Apache release. I would support allowing C/C++ code to link to gtk and/or qt, provided we don't distribute gtk or qt themselves. Both are LGPL. The LGPL is clear for languages like C, C++. Clear in what sense? Dynamic linking and such? Excellent question. The definition of 'link' is well understood in the context of C/C++. That's all I meant to say. I'll go further and state that what I said I would support is intentionally limited in scope to only gtk and qt. Both are commonly distributed with Linux distributions. Other candidate LGPL licensed dependencies would have to be evaluated separately. - Sam Ruby
Re: Clarification on treatment of weak copyleft components
On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir robw...@apache.org wrote: One last question, based on OpenOffice 3rd party dependencies. We have a good number of MPL dependencies. I'm trying, with some difficulty, to interpret what we can do based on the description here: http://www.apache.org/legal/resolved.html#category-b How does this fit into a release strategy that has both source and binary releases. Is this the idea: 1) Source releases would include binary object files/libraries for these 3rd party components, but not their source. 2) Binary releases could link into such objects/libraries. 3) We give proper notices 4) Downstream consumer would need to make extra effort to retrieve and modify the source of the MPL components, since we're not including the source. Is that the idea? Yup. Now, for our SVN, we need to host the actual source of the MPL components, since we need to build the binaries on the platforms that we support. And in several cases we have patches the original source. Is this a problem? That normally is highly discouraged / not allowed. Why can't the patches be contributed back to the original projects? One party that is left out in this scenario is the downstream consumer who wishes to port AOOo to another platform. They would not receive the source to the MPL components. And if they downloaded the original source from the original OSS project, it would lack our patches. So they only thing they can do is download from our SVN (or from Apache-Extras if we decide to do that). Apache-Extras was not intended as a means to bypass Apache policies. (Or back to an earlier note, is there any problem with having the build script automatically download such 3rd party dependencies?) Automatically is typically the hang-up in discussions such as these, but a specific exemption for well-disclosed sources to despondencies which are distributed with the project could be discussed. Any suggestions? Note that in some cases, these dependencies have no reasonable alternatives. For example, if we want to integrate with Mozilla's address book for supporting mail merging in memos, then we need to use the interface that Mozilla has defined, with the library they provide, which is naturally MPL. Any reason such integration couldn't be an option? -Rob - Sam Ruby
Re: Clarification on treatment of weak copyleft components
On Thu, Oct 20, 2011 at 5:27 PM, Sam Ruby ru...@intertwingly.net wrote: On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir robw...@apache.org wrote: One last question, based on OpenOffice 3rd party dependencies. We have a good number of MPL dependencies. I'm trying, with some difficulty, to interpret what we can do based on the description here: http://www.apache.org/legal/resolved.html#category-b How does this fit into a release strategy that has both source and binary releases. Is this the idea: 1) Source releases would include binary object files/libraries for these 3rd party components, but not their source. 2) Binary releases could link into such objects/libraries. 3) We give proper notices 4) Downstream consumer would need to make extra effort to retrieve and modify the source of the MPL components, since we're not including the source. Is that the idea? Yup. Now, for our SVN, we need to host the actual source of the MPL components, since we need to build the binaries on the platforms that we support. And in several cases we have patches the original source. Is this a problem? That normally is highly discouraged / not allowed. Why can't the patches be contributed back to the original projects? There is no intent to hoard. From talking to developers on this project I get the sense that they want to upstream patches more than was done previously. But contributing a patch is no guarantee that it will be integrated by the other project in a timely manner. Simply having it checked in by the 3rd party component, but not yet in their release, is also not optimal, for stability and supportability reasons. Release schedules don't always sync up. One party that is left out in this scenario is the downstream consumer who wishes to port AOOo to another platform. They would not receive the source to the MPL components. And if they downloaded the original source from the original OSS project, it would lack our patches. So they only thing they can do is download from our SVN (or from Apache-Extras if we decide to do that). Apache-Extras was not intended as a means to bypass Apache policies. OK (Or back to an earlier note, is there any problem with having the build script automatically download such 3rd party dependencies?) Automatically is typically the hang-up in discussions such as these, but a specific exemption for well-disclosed sources to despondencies which are distributed with the project could be discussed. Any suggestions? Note that in some cases, these dependencies have no reasonable alternatives. For example, if we want to integrate with Mozilla's address book for supporting mail merging in memos, then we need to use the interface that Mozilla has defined, with the library they provide, which is naturally MPL. Any reason such integration couldn't be an option? It was not clear to me when I originally asked the question. But after reading Robert's comments (and yours) I think we're OK here. -Rob - Sam Ruby
Re: [Proposal] Shutting down legacy OOo mailing lists
On 10/20/2011 10:14 AM, Dennis E. Hamilton wrote: Rob, As were you, I was looking at the value of the ezmlm confirmation e-mail and its opt-in requirement for moderator-initiated subscriptions. It seemed to me that would provide a clean opt-in point for users of lists about to be retired. The process for the moderator-initiated subscription needs to know subscription e-mail addresses for the current members of the to-be-retired list.It depends, of course, on a moderator having the subscriber e-mail addresses, and I did not indicate how that could be solved any more than your experiment did. I think the modifications to ezmlm messages is important regardless. - Dennis STILL THINKING OUT LOUD On the other hand, making moderators of the current list be moderators on the new list and being sure that they notify the list of the move prospect would be a way to subdivide the work with people who presumably do have access to the distribution list of the retiring ML. Those moderators can be expected to follow the rules that apply in their jurisdictions. And wait: Aren't the lists on a US hosted site already? The Oracle Privacy Policy might be the governing situation. Providing an opt-in migration that is not a surprise to the list members, announced clearly in advance, might be a clean way to navigate all of this. My guess here is that it is highly unlikely that lists of users or the forwarding map will be made available. The best approach for contacting these users is to send messages to the various ML. Also, there is no imminent shutdown of the ML infrastructure or any of the other infrastructure hosted on Kenai (including the hg svn). The hosting for the forums and wiki is going away, and we need to look at doing the cut-over. Andrew -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. I don't see how this could work. Maybe if you happen to be a moderator of the legacy list and are willing to take on yourself any personal liability related to data protection laws. But I don't see how this would work in general. Any thing we do to automate this would still require proactive action by the user, either sending an email, clicking a mailto: link in an email, or going to a website and entering their email address. They would need to do an action like that, and then respond to the confirmation email. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were. A valuable way to do this might be to include a link to an English-language version of the message in all NL ones. Pointing to other useful web pages might also be valuable. I notice that ezmlm is designed to work relying on e-mail alone and that should be preserved, but links to web-based support is also valuable and is very useful to link to. The web page could also deal with thing such as what OOo lists does this one replace, where are the archives for the original list(s), etc. OPEN ITEMS It strikes me that there remains the issue I see, in that the ooo-younameit @ i.a.o lists are considerably less friendly than the theynamedit@ OO.o lists. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 07:57 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to
Re: Clarification on treatment of weak copyleft components
On Thu, Oct 20, 2011 at 5:41 PM, Rob Weir robw...@apache.org wrote: There is no intent to hoard. From talking to developers on this project I get the sense that they want to upstream patches more than was done previously. But contributing a patch is no guarantee that it will be integrated by the other project in a timely manner. Simply having it checked in by the 3rd party component, but not yet in their release, is also not optimal, for stability and supportability reasons. Release schedules don't always sync up. Much more of a Java developer than a C++ developer, so I don't know how C++ linking is managed. In Java you give a list of .jar files for the loader to use, in order of preference; hence you can patch a class in a 3rd party library by supplying your own version of that class in a library that's examined before the 3rd party library. Does C++ have something similar? Such that you can supply both the original untouched 3rd party binary library and your own binary library that only contains the modified code? Don
Re: Clarification on treatment of weak copyleft components
On Thu, Oct 20, 2011 at 5:48 PM, Donald Whytock dwhyt...@gmail.com wrote: On Thu, Oct 20, 2011 at 5:41 PM, Rob Weir robw...@apache.org wrote: There is no intent to hoard. From talking to developers on this project I get the sense that they want to upstream patches more than was done previously. But contributing a patch is no guarantee that it will be integrated by the other project in a timely manner. Simply having it checked in by the 3rd party component, but not yet in their release, is also not optimal, for stability and supportability reasons. Release schedules don't always sync up. Much more of a Java developer than a C++ developer, so I don't know how C++ linking is managed. In Java you give a list of .jar files for the loader to use, in order of preference; hence you can patch a class in a 3rd party library by supplying your own version of that class in a library that's examined before the 3rd party library. Does C++ have something similar? Such that you can supply both the original untouched 3rd party binary library and your own binary library that only contains the modified code? You can do something similar, but it is a build-time pattern, not a runtime one. So you can store the original source code of the 3rd party module, as well as a patch, and then apply that source patch at build time. -Rob Don
Re: [Proposal] Shutting down legacy OOo mailing lists
On Oct 20, 2011, at 2:44 PM, Andrew Rist wrote: On 10/20/2011 10:14 AM, Dennis E. Hamilton wrote: Rob, As were you, I was looking at the value of the ezmlm confirmation e-mail and its opt-in requirement for moderator-initiated subscriptions. It seemed to me that would provide a clean opt-in point for users of lists about to be retired. The process for the moderator-initiated subscription needs to know subscription e-mail addresses for the current members of the to-be-retired list.It depends, of course, on a moderator having the subscriber e-mail addresses, and I did not indicate how that could be solved any more than your experiment did. I think the modifications to ezmlm messages is important regardless. - Dennis STILL THINKING OUT LOUD On the other hand, making moderators of the current list be moderators on the new list and being sure that they notify the list of the move prospect would be a way to subdivide the work with people who presumably do have access to the distribution list of the retiring ML. Those moderators can be expected to follow the rules that apply in their jurisdictions. And wait: Aren't the lists on a US hosted site already? The Oracle Privacy Policy might be the governing situation. Providing an opt-in migration that is not a surprise to the list members, announced clearly in advance, might be a clean way to navigate all of this. My guess here is that it is highly unlikely that lists of users or the forwarding map will be made available. The best approach for contacting these users is to send messages to the various ML. Also, there is no imminent shutdown of the ML infrastructure or any of the other infrastructure hosted on Kenai (including the hg svn). The hosting for the forums and wiki is going away, and we need to look at doing the cut-over. Thanks for the clarification. It really helps. Are there other services that will go away when the forums and mediawiki do? Regards, Dave Andrew -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. I don't see how this could work. Maybe if you happen to be a moderator of the legacy list and are willing to take on yourself any personal liability related to data protection laws. But I don't see how this would work in general. Any thing we do to automate this would still require proactive action by the user, either sending an email, clicking a mailto: link in an email, or going to a website and entering their email address. They would need to do an action like that, and then respond to the confirmation email. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were. A valuable way to do this might be to include a link to an English-language version of the message in all NL ones. Pointing to other useful web pages might also be valuable. I notice that ezmlm is designed to work relying on e-mail alone and that should be preserved, but links to web-based support is also valuable and is very useful to link to. The web page could also deal with thing such as what OOo lists does this one replace, where are the archives for the original list(s), etc. OPEN ITEMS It strikes me that there remains the issue I see, in that the ooo-younameit @ i.a.o lists are considerably less friendly than the theynamedit@ OO.o lists. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 07:57 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list,
Re: [Proposal] Shutting down legacy OOo mailing lists
On 10/20/2011 03:22 PM, Dave Fisher wrote: On Oct 20, 2011, at 2:44 PM, Andrew Rist wrote: -- snipped -- My guess here is that it is highly unlikely that lists of users or the forwarding map will be made available. The best approach for contacting these users is to send messages to the various ML. Also, there is no imminent shutdown of the ML infrastructure or any of the other infrastructure hosted on Kenai (including the hg svn). The hosting for the forums and wiki is going away, and we need to look at doing the cut-over. Thanks for the clarification. It really helps. Are there other services that will go away when the forums and mediawiki do? Regards, Dave ...and, what's the drop-dead date for these? actually I guess anything at .services.openoffice.org Andrew -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. I don't see how this could work. Maybe if you happen to be a moderator of the legacy list and are willing to take on yourself any personal liability related to data protection laws. But I don't see how this would work in general. Any thing we do to automate this would still require proactive action by the user, either sending an email, clicking a mailto: link in an email, or going to a website and entering their email address. They would need to do an action like that, and then respond to the confirmation email. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were. A valuable way to do this might be to include a link to an English-language version of the message in all NL ones. Pointing to other useful web pages might also be valuable. I notice that ezmlm is designed to work relying on e-mail alone and that should be preserved, but links to web-based support is also valuable and is very useful to link to. The web page could also deal with thing such as what OOo lists does this one replace, where are the archives for the original list(s), etc. OPEN ITEMS It strikes me that there remains the issue I see, in that the ooo-younameit @ i.a.o lists are considerably less friendly than the theynamedit@ OO.o lists. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 07:57 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi! This is the ezmlm program. I'm managing the ooo-dev@incubator.apache.org mailing list. I'm working for my owner, who can be reached at ooo-dev-ow...@incubator.apache.org. To confirm that you would like f...@bar.com added to the ooo-dev mailing list, please send a short reply to this address: ooo-dev-sc.X.X-foo=bar@incubator.apache.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:ooo-dev-sc.X.XX-foo=bar@incubator.apache.org; - So with the moderator rights available to us now, we can't do a fully automated sign up of existing list members, even if we had resolved the legal and policy issues. I don't know if there are other, administrative functions in ezmlm that could be used, by Apache Infra, to more fully automate this. -Rob --
Re: [Proposal] Shutting down legacy OOo mailing lists
-- snipped -- My guess here is that it is highly unlikely that lists of users or the forwarding map will be made available. The best approach for contacting these users is to send messages to the various ML. Also, there is no imminent shutdown of the ML infrastructure or any of the other infrastructure hosted on Kenai (including the hg svn). The hosting for the forums and wiki is going away, and we need to look at doing the cut-over. Thanks for the clarification. It really helps. Are there other services that will go away when the forums and mediawiki do? Regards, Dave ...and, what's the drop-dead date for these? We should not expect them to be available after next Friday actually I guess anything at .services.openoffice.org yes - with the caveat that this does not effect hg.services.o.o or svn.services.o.o Andrew snip -- Oracle Email Signature Logo Andrew Rist | Interoperability Architect Oracle Corporate Architecture Group Redwood Shores, CA | 650.506.9847
Re: [Proposal] Shutting down legacy OOo mailing lists
Am 10/21/2011 12:27 AM, schrieb Kay Schenk: On 10/20/2011 03:22 PM, Dave Fisher wrote: On Oct 20, 2011, at 2:44 PM, Andrew Rist wrote: -- snipped -- My guess here is that it is highly unlikely that lists of users or the forwarding map will be made available. The best approach for contacting these users is to send messages to the various ML. Also, there is no imminent shutdown of the ML infrastructure or any of the other infrastructure hosted on Kenai (including the hg svn). The hosting for the forums and wiki is going away, and we need to look at doing the cut-over. Thanks for the clarification. It really helps. Are there other services that will go away when the forums and mediawiki do? Regards, Dave ...and, what's the drop-dead date for these? actually I guess anything at .services.openoffice.org If so, then also download.s.oo.o will be dead sooner than later. However, we have not done a transition to Apache and its network. The currently used Mirrorbrain service seems not welcomed at ASF as it would mean to install and support another software currently only for this podling. Marcus -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 09:29 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Thu, Oct 20, 2011 at 12:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The moderator-issued subscription e-mail seems useful, especially because it is done as an opt-in (requiring confirmation from the recipient). If the list to be retired was informed of this process, its near-automatic operation could be considered. I don't see how this could work. Maybe if you happen to be a moderator of the legacy list and are willing to take on yourself any personal liability related to data protection laws. But I don't see how this would work in general. Any thing we do to automate this would still require proactive action by the user, either sending an email, clicking a mailto: link in an email, or going to a website and entering their email address. They would need to do an action like that, and then respond to the confirmation email. - Dennis THINKING OUT LOUD With regard to the messages from ezmlm, I wonder if these are ones that are customizable by list. I thought they were. A valuable way to do this might be to include a link to an English-language version of the message in all NL ones. Pointing to other useful web pages might also be valuable. I notice that ezmlm is designed to work relying on e-mail alone and that should be preserved, but links to web-based support is also valuable and is very useful to link to. The web page could also deal with thing such as what OOo lists does this one replace, where are the archives for the original list(s), etc. OPEN ITEMS It strikes me that there remains the issue I see, in that the ooo-younameit @ i.a.o lists are considerably less friendly than the theynamedit@ OO.o lists. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 07:57 To: ooo-dev@incubator.apache.org Subject: Re: [Proposal] Shutting down legacy OOo mailing lists On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti pesce...@openoffice.org wrote: snip I would turn the post you describe into a warning that the mailing list address will change, including all information about Apache but not requiring users to take action. I volunteer to consolidate the 12 lists into 3 and to subscribe users to the right ones (of course, being project owner of it.openoffice.org, I have a list of all subscribers to the 12 lists). I did an experiment on how we can subscribe users to the mailing list automatically. I looked just at the technical aspect of this. I did not look at the legal or policy implications. Moderators of Apache lists can subscribe new users to the list, by sending a specially addressed email to the list manager. For example, to subscribe f...@bar.com to this list, you would send an email to: ooo-dev-subscribe-foo=bar@incubator.apache.org Note the @ in the address is replaced by an = A moderator can do the above, but this still will generate a confirmation email, to f...@bar.com, in English: - Subject: confirm subscribe to ooo-dev@incubator.apache.org Hi! This is the ezmlm program. I'm managing the ooo-dev@incubator.apache.org mailing list. I'm working for my owner, who can be reached at ooo-dev-ow...@incubator.apache.org. To confirm that you would like f...@bar.com added to the ooo-dev mailing list, please send a short reply to this address: ooo-dev-sc.X.X-foo=bar@incubator.apache.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:ooo-dev-sc.X.XX-foo=bar@incubator.apache.org; - So with the moderator rights
RE: Clarification on treatment of weak copyleft components
I want to point out another case that I have seen in practice, including in the construction and deployment of binary releases for OpenOffice.org. This discussion may impinge on that practice in terms of how it can be retained in Apache OpenOffice.org binary releases and their deployment. - Dennis QUASI ARMS-LENGTH DEPENDENCIES: In the cases of licenses where the source is not compatible for inclusion in a release and [patched] libraries are needed to build the OpenOffice.org code, the practice that I have seen already used is the following: The build process includes a script that 1. downloads a source tarball of a specific version from a known external location, 2. extracts the source from the tarball into a working directory, 3, applies any patches, 4. compiles the library, 5. uses the library in the build, and then 6. erases all of that ephemeral stuff so that there is no residue in the released source nor in the shipped binary package, 7. provides for a NOTICE (or equivalent) that indicates the dependency (and could provide links to the origin and the specific source code, for that matter). Variations on this theme include (1) making/redistributing [the Microsoft redistributables case] a run-time shared library that is shipped and installed with the binaries, the source/redistribution license permitting, and (2) using libraries, even source, that may already be available on the platform used to make the build. This seems to have happened with libraries from the Boost collection that are shipped with some GNU/Linux compiler configurations. Note that dependencies on header files for C/C++ have to be addressed as well, since it may be tricky to even include those in an Apache project source release, depending on notices affixed to those files. Some of the libraries in the Boost collection consist entirely of C++ header files. I can't speak to whether or not patches are submitted back to the upstream source in the cases I've noticed in the current OpenOffice.org build process, but they certainly should be. And when a version including an upstream-acceptable patch is available, the build process could be adjusted accordingly. The remark made about LGPL elsewhere seems to work here, but I don't think the above scenario relieves us of reciprocity concerning patches in the case of LGPL and certain other reciprocal licenses. (I must constantly remind myself that the LGPL includes the GPL by reference and the modifications it makes to GPL provisions are specific and limited.) [Note: The Boost collection is a bad choice because (a) it may be found to be Apache compatible and (b) it is going to show up, over time, as standard in C++ compiler distributions that honor the 2011 ISO specifications.] There are murky dependency interactions that become tricky as well. For example, dependency on an address-book service may also be required to locate public-key infrastructure certificates. -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Thursday, October 20, 2011 14:27 To: ooo-dev@incubator.apache.org Cc: legal-disc...@apache.org Subject: Re: Clarification on treatment of weak copyleft components [ ... ] Now, for our SVN, we need to host the actual source of the MPL components, since we need to build the binaries on the platforms that we support. And in several cases we have patches the original source. Is this a problem? That normally is highly discouraged / not allowed. Why can't the patches be contributed back to the original projects? [ ... ] (Or back to an earlier note, is there any problem with having the build script automatically download such 3rd party dependencies?) Automatically is typically the hang-up in discussions such as these, but a specific exemption for well-disclosed sources to despondencies which are distributed with the project could be discussed. [ ... ]
RE: [DISCUSS] Bugzilla Admin (was RE: Bugzilla notifications not going to an ASF mailing list)
I think that you and I aren't using properties the same way in this context. I was using it by analogy to the way a real-estate agent or a rental property manager would use it. I thought I cleared that up. Can you explain what you mean without using property and being specific to the Bugzilla Admin topic? I apologize for being so thick about this. I can't visualize what you are proposing. - Dennis -Original Message- From: Dave Fisher [mailto:dave2w...@comcast.net] Sent: Thursday, October 20, 2011 13:27 To: ooo-dev@incubator.apache.org Subject: Re: [DISCUSS] Bugzilla Admin (was RE: Bugzilla notifications not going to an ASF mailing list) On Oct 20, 2011, at 1:08 PM, Dennis E. Hamilton wrote: I don't understand what this means: I think we need a languages properties file with items like BZ, Forum, ML, Language Pack, etc. Just like you stated the need for OOo domain/website/project properties. I think there is a related need for a language properties collection. There are several dimensions to language support in OpenOffice, we need a way to navigate users to all the support for their language. With a proper properties file the webpages for each language can include some language specific navigation. Early on there was discussion that Apache websites can identify the incoming language. It would be good to provide a property that for example could be used to determine a German user of www.openoffice.org can automatically be sent to de.openoffice.org (or www.openoffice.org/de/.) Regards, Dave - Dennis -Original Message- From: Dave Fisher [mailto:dave2w...@comcast.net] Sent: Thursday, October 20, 2011 12:29 To: ooo-dev@incubator.apache.org Subject: Re: [DISCUSS] Bugzilla Admin (was RE: Bugzilla notifications not going to an ASF mailing list) On Oct 20, 2011, at 12:20 PM, Dennis E. Hamilton wrote: I believe the next-action on administration of the ooo-bz is ours. It looks like there need to be some @apache.org administrators, and the hierarchy of administration with respect to the various categories also needs to be dealt with. From the list that Mark Thomas provided, I only see 2 apache.org e-mail addresses that have administrative logins, Mark Thomas himself and Herbert Dürr. The rest are openoffice.org addresses of people who may or may not be here, may or may not be committers/PPMC members. They might not have even restored access to their bugzilla account after the move, but I suspect they are still getting automated traffic from ooo-bz!?. Most of these are here and on the PPMC. jza, jsc, pjanik, r4zoli, pescetti, ... But it is a long list. I think we need a languages properties file with items like BZ, Forum, ML, Language Pack, etc. My thought is that this is an appropriate migration case to handle with more detail on OOOUSER. Yes. I am raising this flag for discussion. I think a couple of admins should be nominated and option 2 taken. The mapping could be explained on the wiki. Who already knows enough ins-and-outs of Bugzilla administration to land running? Volunteers? Leaders? Let's not all step backwards at once :-) Regards, Dave [ ... ]
Re: Clarification on treatment of weak copyleft components
On Thu, Oct 20, 2011 at 7:53 PM, Dennis E. Hamilton orc...@apache.org wrote: I want to point out another case that I have seen in practice, including in the construction and deployment of binary releases for OpenOffice.org. This discussion may impinge on that practice in terms of how it can be retained in Apache OpenOffice.org binary releases and their deployment. Life is too short to read all of your notes, Dennis. Could you maybe state up front, in a summary, whether you are raising a question. answering a question, or just digressing? In this case I have no idea what your point is. Thanks, -Rob - Dennis QUASI ARMS-LENGTH DEPENDENCIES: In the cases of licenses where the source is not compatible for inclusion in a release and [patched] libraries are needed to build the OpenOffice.org code, the practice that I have seen already used is the following: The build process includes a script that 1. downloads a source tarball of a specific version from a known external location, 2. extracts the source from the tarball into a working directory, 3, applies any patches, 4. compiles the library, 5. uses the library in the build, and then 6. erases all of that ephemeral stuff so that there is no residue in the released source nor in the shipped binary package, 7. provides for a NOTICE (or equivalent) that indicates the dependency (and could provide links to the origin and the specific source code, for that matter). Variations on this theme include (1) making/redistributing [the Microsoft redistributables case] a run-time shared library that is shipped and installed with the binaries, the source/redistribution license permitting, and (2) using libraries, even source, that may already be available on the platform used to make the build. This seems to have happened with libraries from the Boost collection that are shipped with some GNU/Linux compiler configurations. Note that dependencies on header files for C/C++ have to be addressed as well, since it may be tricky to even include those in an Apache project source release, depending on notices affixed to those files. Some of the libraries in the Boost collection consist entirely of C++ header files. I can't speak to whether or not patches are submitted back to the upstream source in the cases I've noticed in the current OpenOffice.org build process, but they certainly should be. And when a version including an upstream-acceptable patch is available, the build process could be adjusted accordingly. The remark made about LGPL elsewhere seems to work here, but I don't think the above scenario relieves us of reciprocity concerning patches in the case of LGPL and certain other reciprocal licenses. (I must constantly remind myself that the LGPL includes the GPL by reference and the modifications it makes to GPL provisions are specific and limited.) [Note: The Boost collection is a bad choice because (a) it may be found to be Apache compatible and (b) it is going to show up, over time, as standard in C++ compiler distributions that honor the 2011 ISO specifications.] There are murky dependency interactions that become tricky as well. For example, dependency on an address-book service may also be required to locate public-key infrastructure certificates. -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Thursday, October 20, 2011 14:27 To: ooo-dev@incubator.apache.org Cc: legal-disc...@apache.org Subject: Re: Clarification on treatment of weak copyleft components [ ... ] Now, for our SVN, we need to host the actual source of the MPL components, since we need to build the binaries on the platforms that we support. And in several cases we have patches the original source. Is this a problem? That normally is highly discouraged / not allowed. Why can't the patches be contributed back to the original projects? [ ... ] (Or back to an earlier note, is there any problem with having the build script automatically download such 3rd party dependencies?) Automatically is typically the hang-up in discussions such as these, but a specific exemption for well-disclosed sources to despondencies which are distributed with the project could be discussed. [ ... ] - To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org For additional commands, e-mail: legal-discuss-h...@apache.org
RE: Clarification on treatment of weak copyleft components
Well, that will teach me to read the wrong list first. Rob already identified the quasi case, etc., on ooo-dev at least. I hereby cease cross-list posting. -Original Message- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Thursday, October 20, 2011 16:54 To: legal-disc...@apache.org; ooo-dev@incubator.apache.org Subject: RE: Clarification on treatment of weak copyleft components I want to point out another case that I have seen in practice, including in the construction and deployment of binary releases for OpenOffice.org. This discussion may impinge on that practice in terms of how it can be retained in Apache OpenOffice.org binary releases and their deployment. - Dennis QUASI ARMS-LENGTH DEPENDENCIES: In the cases of licenses where the source is not compatible for inclusion in a release and [patched] libraries are needed to build the OpenOffice.org code, the practice that I have seen already used is the following: The build process includes a script that 1. downloads a source tarball of a specific version from a known external location, 2. extracts the source from the tarball into a working directory, 3, applies any patches, 4. compiles the library, 5. uses the library in the build, and then 6. erases all of that ephemeral stuff so that there is no residue in the released source nor in the shipped binary package, 7. provides for a NOTICE (or equivalent) that indicates the dependency (and could provide links to the origin and the specific source code, for that matter). Variations on this theme include (1) making/redistributing [the Microsoft redistributables case] a run-time shared library that is shipped and installed with the binaries, the source/redistribution license permitting, and (2) using libraries, even source, that may already be available on the platform used to make the build. This seems to have happened with libraries from the Boost collection that are shipped with some GNU/Linux compiler configurations. Note that dependencies on header files for C/C++ have to be addressed as well, since it may be tricky to even include those in an Apache project source release, depending on notices affixed to those files. Some of the libraries in the Boost collection consist entirely of C++ header files. I can't speak to whether or not patches are submitted back to the upstream source in the cases I've noticed in the current OpenOffice.org build process, but they certainly should be. And when a version including an upstream-acceptable patch is available, the build process could be adjusted accordingly. The remark made about LGPL elsewhere seems to work here, but I don't think the above scenario relieves us of reciprocity concerning patches in the case of LGPL and certain other reciprocal licenses. (I must constantly remind myself that the LGPL includes the GPL by reference and the modifications it makes to GPL provisions are specific and limited.) [Note: The Boost collection is a bad choice because (a) it may be found to be Apache compatible and (b) it is going to show up, over time, as standard in C++ compiler distributions that honor the 2011 ISO specifications.] There are murky dependency interactions that become tricky as well. For example, dependency on an address-book service may also be required to locate public-key infrastructure certificates. -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Thursday, October 20, 2011 14:27 To: ooo-dev@incubator.apache.org Cc: legal-disc...@apache.org Subject: Re: Clarification on treatment of weak copyleft components [ ... ] Now, for our SVN, we need to host the actual source of the MPL components, since we need to build the binaries on the platforms that we support. And in several cases we have patches the original source. Is this a problem? That normally is highly discouraged / not allowed. Why can't the patches be contributed back to the original projects? [ ... ] (Or back to an earlier note, is there any problem with having the build script automatically download such 3rd party dependencies?) Automatically is typically the hang-up in discussions such as these, but a specific exemption for well-disclosed sources to despondencies which are distributed with the project could be discussed. [ ... ] - To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org For additional commands, e-mail: legal-discuss-h...@apache.org
RE: Clarification on treatment of weak copyleft components
It doesn't matter Rob.. You already covered this case over here and I hadn't seen that when I replied over there. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 17:11 To: ooo-dev@incubator.apache.org Subject: Re: Clarification on treatment of weak copyleft components On Thu, Oct 20, 2011 at 7:53 PM, Dennis E. Hamilton orc...@apache.org wrote: I want to point out another case that I have seen in practice, including in the construction and deployment of binary releases for OpenOffice.org. This discussion may impinge on that practice in terms of how it can be retained in Apache OpenOffice.org binary releases and their deployment. Life is too short to read all of your notes, Dennis. Could you maybe state up front, in a summary, whether you are raising a question. answering a question, or just digressing? In this case I have no idea what your point is. Thanks, -Rob - Dennis QUASI ARMS-LENGTH DEPENDENCIES: In the cases of licenses where the source is not compatible for inclusion in a release and [patched] libraries are needed to build the OpenOffice.org code, the practice that I have seen already used is the following: The build process includes a script that 1. downloads a source tarball of a specific version from a known external location, 2. extracts the source from the tarball into a working directory, 3, applies any patches, 4. compiles the library, 5. uses the library in the build, and then 6. erases all of that ephemeral stuff so that there is no residue in the released source nor in the shipped binary package, 7. provides for a NOTICE (or equivalent) that indicates the dependency (and could provide links to the origin and the specific source code, for that matter). Variations on this theme include (1) making/redistributing [the Microsoft redistributables case] a run-time shared library that is shipped and installed with the binaries, the source/redistribution license permitting, and (2) using libraries, even source, that may already be available on the platform used to make the build. This seems to have happened with libraries from the Boost collection that are shipped with some GNU/Linux compiler configurations. Note that dependencies on header files for C/C++ have to be addressed as well, since it may be tricky to even include those in an Apache project source release, depending on notices affixed to those files. Some of the libraries in the Boost collection consist entirely of C++ header files. I can't speak to whether or not patches are submitted back to the upstream source in the cases I've noticed in the current OpenOffice.org build process, but they certainly should be. And when a version including an upstream-acceptable patch is available, the build process could be adjusted accordingly. The remark made about LGPL elsewhere seems to work here, but I don't think the above scenario relieves us of reciprocity concerning patches in the case of LGPL and certain other reciprocal licenses. (I must constantly remind myself that the LGPL includes the GPL by reference and the modifications it makes to GPL provisions are specific and limited.) [Note: The Boost collection is a bad choice because (a) it may be found to be Apache compatible and (b) it is going to show up, over time, as standard in C++ compiler distributions that honor the 2011 ISO specifications.] There are murky dependency interactions that become tricky as well. For example, dependency on an address-book service may also be required to locate public-key infrastructure certificates. -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Thursday, October 20, 2011 14:27 To: ooo-dev@incubator.apache.org Cc: legal-disc...@apache.org Subject: Re: Clarification on treatment of weak copyleft components [ ... ] Now, for our SVN, we need to host the actual source of the MPL components, since we need to build the binaries on the platforms that we support. And in several cases we have patches the original source. Is this a problem? That normally is highly discouraged / not allowed. Why can't the patches be contributed back to the original projects? [ ... ] (Or back to an earlier note, is there any problem with having the build script automatically download such 3rd party dependencies?) Automatically is typically the hang-up in discussions such as these, but a specific exemption for well-disclosed sources to despondencies which are distributed with the project could be discussed. [ ... ] - To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org For additional commands, e-mail: legal-discuss-h...@apache.org
Re: Clarification on treatment of weak copyleft components
On Thu, Oct 20, 2011 at 8:20 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: It doesn't matter Rob.. You already covered this case over here and I hadn't seen that when I replied over there. OK. That may explain it. I was vainly searching for what you were saying new. I assumed you were trying to point out some fine distinction over what I had said, but couldn't find it ;-) -Rob - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, October 20, 2011 17:11 To: ooo-dev@incubator.apache.org Subject: Re: Clarification on treatment of weak copyleft components On Thu, Oct 20, 2011 at 7:53 PM, Dennis E. Hamilton orc...@apache.org wrote: I want to point out another case that I have seen in practice, including in the construction and deployment of binary releases for OpenOffice.org. This discussion may impinge on that practice in terms of how it can be retained in Apache OpenOffice.org binary releases and their deployment. Life is too short to read all of your notes, Dennis. Could you maybe state up front, in a summary, whether you are raising a question. answering a question, or just digressing? In this case I have no idea what your point is. Thanks, -Rob - Dennis QUASI ARMS-LENGTH DEPENDENCIES: In the cases of licenses where the source is not compatible for inclusion in a release and [patched] libraries are needed to build the OpenOffice.org code, the practice that I have seen already used is the following: The build process includes a script that 1. downloads a source tarball of a specific version from a known external location, 2. extracts the source from the tarball into a working directory, 3, applies any patches, 4. compiles the library, 5. uses the library in the build, and then 6. erases all of that ephemeral stuff so that there is no residue in the released source nor in the shipped binary package, 7. provides for a NOTICE (or equivalent) that indicates the dependency (and could provide links to the origin and the specific source code, for that matter). Variations on this theme include (1) making/redistributing [the Microsoft redistributables case] a run-time shared library that is shipped and installed with the binaries, the source/redistribution license permitting, and (2) using libraries, even source, that may already be available on the platform used to make the build. This seems to have happened with libraries from the Boost collection that are shipped with some GNU/Linux compiler configurations. Note that dependencies on header files for C/C++ have to be addressed as well, since it may be tricky to even include those in an Apache project source release, depending on notices affixed to those files. Some of the libraries in the Boost collection consist entirely of C++ header files. I can't speak to whether or not patches are submitted back to the upstream source in the cases I've noticed in the current OpenOffice.org build process, but they certainly should be. And when a version including an upstream-acceptable patch is available, the build process could be adjusted accordingly. The remark made about LGPL elsewhere seems to work here, but I don't think the above scenario relieves us of reciprocity concerning patches in the case of LGPL and certain other reciprocal licenses. (I must constantly remind myself that the LGPL includes the GPL by reference and the modifications it makes to GPL provisions are specific and limited.) [Note: The Boost collection is a bad choice because (a) it may be found to be Apache compatible and (b) it is going to show up, over time, as standard in C++ compiler distributions that honor the 2011 ISO specifications.] There are murky dependency interactions that become tricky as well. For example, dependency on an address-book service may also be required to locate public-key infrastructure certificates. -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Thursday, October 20, 2011 14:27 To: ooo-dev@incubator.apache.org Cc: legal-disc...@apache.org Subject: Re: Clarification on treatment of weak copyleft components [ ... ] Now, for our SVN, we need to host the actual source of the MPL components, since we need to build the binaries on the platforms that we support. And in several cases we have patches the original source. Is this a problem? That normally is highly discouraged / not allowed. Why can't the patches be contributed back to the original projects? [ ... ] (Or back to an earlier note, is there any problem with having the build script automatically download such 3rd party dependencies?) Automatically is typically the hang-up in discussions such as these, but a specific exemption for well-disclosed sources to despondencies which are distributed with the project could be discussed. [ ... ]
How to re-package openoffice?
openoffice installation program has hundreds of megabytes, which includes Writer, Calc and Draw, and other modules. Due to hardware resource constraints, combined with the actual demand, packaged to meet the requirements write, how packaged write it?How to modify the SCP2 project?
Re: [Proposal] Shutting down legacy OOo mailing lists
On 10/20/2011 11:28 AM, Rob Weir wrote: On Thu, Oct 20, 2011 at 2:15 PM, Wolf Halton wolf.hal...@gmail.com wrote: Do any of these lists have publicly accessible archives? It would be a shame to lose those, when the lists shut down. I suspect messages about OOo 1.x are pretty much dead, or at least the software is pretty much obsoleted. Those archives might be less useful. Yes, there is a MarkMail archive of 333 OOo mailing lists, 1.6 million messages, going back to the project's start in 2000. See: http://openoffice.markmail.org/ ... I fail to understand why you continue to fall back on MarkMail for archives rather than simply pulling the archives over to an Apache server. MarkMail is a third party service that can terminate it's services at any time have their own ToU. See: http://markmail.org/docs/terms-of-use.xqy quote 2. Provision of Service You understand and agree that MarkMail is provided to you on an as is and as available basis. You understand that MarkMail is experimental, that its availability may be intermittent, and that its content may be incomplete. Furthermore, We reserve the right, without any notice or liability to you, to change the functionality of the Service or to cease providing the Service at any time. Finally, We reserve the right to refuse service to anyone at our sole discretion. /quote Might be worth reading the entire ToU... and http://markmail.org/docs/content-policy.xqy Content Not Complete Usage and Personal Information Point is that Apache have no control over MarkMail, or their services. Should MarkMail go belly up tomorrow Apache would have no archives at all. Certainly if list archivals like gmane, nabble, and MarkMail can do this without issue, Apache should be able to do the same... particularly since the lists are already archived on the kenai servers. http://kenai.com/projects/ooo-migration/lists http://kenai.com/projects/ooo-migration/pages/Home Or am I missing something/misunderstanding your reasoning to rely on a third party to archive the OOo lists?
Re: How to re-package openoffice?
On Thu, Oct 20, 2011 at 7:47 PM, jianlizhao jianlizh...@hotmail.com wrote: openoffice installation program has hundreds of megabytes, which includes Writer, Calc and Draw, and other modules. Due to hardware resource constraints, combined with the actual demand, packaged to meet the requirements write, how packaged write it?How to modify the SCP2 project? Writer Calc and the rest of the modules use the same toolkit and engine which is not as modular so is not currently possible to divide the core modules. -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6
Re: [REVIEW] Staged Migration of OO.o domain properties (long)
On Thu, Oct 20, 2011 at 3:56 PM, Kay Schenk kay.sch...@gmail.com wrote: On 10/17/2011 07:32 AM, Alexandro Colorado wrote: On Mon, Oct 17, 2011 at 9:25 AM, Shane Curcurua...@shanecurcuru.org wrote: On 10/14/2011 7:56 PM, Dennis E. Hamilton wrote: I've been pondering what it takes to choreograph migration of the live OpenOffice.org properties into Apache custodianship. ...snip... Great starts all. Where is the noodling and proposed list of what domains we want to keep (i.e. host as *.oo.o to keep links, or host at ooo.a.o/* because it's project oriented information) and what ones we're not going to keep? I would preffer an *.oo.o is easier to manage and recognized, create shorter URLs and also reinforce branding. I *thought* sometime back we'd had the discussion on the user facing area -- www.openoffice.org along with whatever subdomains we wanted to use there -- vs the development portion currently on Apache -- e.g openoffice.apache.org (or currently http://incubator.apache.org/openofficeorg/). There was some need (reason) to separate these as I recall. There was some ideas but they were all hard sales because they want the domain name to be exact to the brand (for some reason). The idea was http://ooo.apache.org like they have with the wiki and other domains (currently) http://ooo-wiki.apache.org http://ooo-forums.apache.org/ The next idea is having http://openofficeorg.apache.org but this idea would involve eliminate the dot, which I didnt thought it was a big deal but the person opposed unless we change the actual brand in itself. In other words, a name like .net would never be possible under apache because they have a strict policy of matching a brand with the domain name. Which in all honestly I dont see a relationship. In particular, other than keeping some of the highly linked informational domains from oo.o, I would expect that there would be significantly fewer major domain names being used in the future project. But maybe that's just me. Surely many projects are not mantained anymore or their existance could be reincorporated into larger projects like development.openoffice.org as you could see on the traffic of the mailing list some components experience a low volume of traffic that could be re-incorporated into a larger project. Example the CD-ROM project back into distribution. see https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-to-ASF-site-recommendation for some recommendations/observations I had made a while back. We really DO need to discuss combining projects from the old world vs the new. Especially with regard to the development areas I would think. Maybe I'll start that discussion. It could be that all previous area having to do with development should just be linked to the development web site. ALL the web areas have been moved over to our temporary holding area but nothing has been done with them currently. A parallel discussion might be how we use oo.o versus ooo.a.o in the future. The development core of the project needs to be on ooo.a.o (or whatever name y'all choose), as do the actual future download sites. yes... this needs better definition. I'm thinking of oo.o as an informational portal, mostly with either immediate redirects or with informational pages that point people towards the appropriate ooo.a.o pages. Then we can in the future consider adding additional user-based information on the whole OOo ecosystem to the oo.o site. Most of the visits from users are to simply download the app, they need a quick link like the www.openoffice.org domain. Everything besides that would be hard for the user. Even Mozilla has two domains for their products, the core Firefox like http://www.mozilla.org/en-US/firefox/new/ and a more user friendly domain: http://www.getfirefox.net/ which works as a re-director like http://www.firefox.com and others. there are micro-sites like http://why.openoffice.org which serves as a marketing e-flyer for users of different markets. One important aspect is to ensure that user expectations for Apache software are met. That means anything served off of an *.apache.orgdomain must meet the project branding requirements, be under the Apache license, etc. For normal projects, we'd ask that oo.o redirect to the ooo.a.o domain, but in this case, with the huge and valuable history of the OOo project, I think we'll end up treating oo.o subtly different than other Apache domains in terms of what content we're comfortable hosting there. - Shane -- MzK There is no such thing as coincidence. -- Leroy Jethro Gibbs, Rule #39 -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6
Google code-in 2011: can we still make it?
Hi; In case you are not aware, Google has a code-in program where teenagers get involved in open-source projects. http://www.google-melange.com/gci/homepage/google/gci2011 Compared to a GSoC, this usually involves tasks that are more related to documentation or alternative task rather than heavy coding. I am not sure if we are still in time to apply, or if ASF is applying for this program but it would be very valuable for some taks like the Wiki migration, and having young people involved in the project would be great! Pedro.
