Re: Dual licensing of patches and code
The conversation below happened in public, but not on the OpenOffice public lists. I believe it's good to record its outcome here on the OpenOffice dev list too. Summary: - Question from Jim Jagielski: Is a contribution under ALv2 + MPL + LGPLv3+ acceptable to both OpenOffice and LibreOffice (and Apache Software Foundation and The Document Foundation)? - Answer by the OpenOffice PMC: Yes (speaking for the OpenOffice project). See http://openoffice.apache.org/contributing-code.html No further discussion needed on the OpenOffice dev list. The ongoing conversation can be read at: http://listarchives.documentfoundation.org/www/discuss/ Regards, Andrea. On 05/03/2013 Jim Jagielski wrote: On Mar 5, 2013, at 10:34 AM, Jim Jagielskij...@jagunet.com wrote: So far, I've rec'd an answer from AOO... I'd appreciate an answer from TDF as well. On Mar 4, 2013, at 11:39 AM, Jim Jagielskij...@jagunet.com wrote: BTW, Please be sure that I'm on the CC list, so I get any and all responses :) On Mar 4, 2013, at 8:08 AM, Jim Jagielskij...@jagunet.com wrote: Hello there. This Email is being directed to the 2 controlling bodies of the Apache OpenOffice Project and LibreOffice (TDF). You will notice that I am sending this from my non-ASF account. Recently, at various conferences, I have been approached by numerous people, both 100% volunteer as well as more corporate affiliated, wondering if it was OK for them to submit code, patches and fixes to both AOO and LO at the same time. In general, these people have code that directly patches LO but they also want to dual-license the code such that it can also be consumed by AOO even if it requires work and modification for it to be committed to, and folded into, the AOO repo. My response has always been that as the orig author of their code/patches/whatever, they can license their contributions as they see fit. However, I have been told that they have rec'd word that such dual-licensed code would not be accepted by, or acceptable to, either the AOO project and/or LO and/or TDF and/or the ASF. Therefore, I am asking for official confirmation from both projects and both entities that both projectsSo are fully OK with accepting code/patches/etc that are licensed in such a way as to be 100% consumable by both projects. For example, if I have a code patch which is dual-licensed both under LGPLv3 and ALv2, that such a patch would be acceptable to both LO and AOO. Thank you. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Review Board
Dave Fisher wrote on Fri, Mar 08, 2013 at 15:35:31 -0800: On Mar 8, 2013, at 1:47 PM, Rob Weir wrote: On Fri, Mar 8, 2013 at 4:21 PM, janI j...@apache.org wrote: On 8 March 2013 22:16, Rob Weir robw...@apache.org wrote: On Fri, Mar 8, 2013 at 3:51 PM, Dave Fisher dave2w...@comcast.net wrote: Only if we are going to become a Review Then Commit project. I was thinking more of whether it would be useful for working with patch contributions from contributors. Just be careful not to set level too high for volunteers, in my opinion the mailing list is more than enough, no need for extra layers to complicate matters. That's exactly the issue. The mailing list is so busy that new volunteers get lost, and their patches as well. And if they toss their patches to bugzilla, the patches can easily be lost there was well. So the question is whether a dedicated place for patches, with no distracting complications, would be preferred. If there are volunteers who will do RTC work for new code contributors then this might be an improvement to bug tracking. FWIW, over at Subversion we (a) have a 'patch' label in the bug tracker, (b) have a volunteer who pings [patch] threads that have petered out without the patch being either applie or rejected. http://subversion.apache.org/docs/community-guide/roles#patch-manager Perhaps one or both of these ideas would be useful here. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
office 3.4
Hi I have been using office for years without problems. Today I tried updating to 3.4 - with disastrous results. It has taken me all morning to get rid of the wretched thing. When opening 3.4 all I got was a blue mark on the screen about 20mm by 4 mm. I tried reinstalling a couple of times. So now I've got rid of it and have just downloaded 3.3. Regards -- Phil Robinson Baslow Hall Calver Road Bakewell Derbyshire DE45 1RR Phone 01246 583639 Mobile 07914778370 skype philip.robinson35 email:* phil@ phil...@gmail.compcrobinson.co.uk* Web site: www.pcrobinson.co.uk
Re: update service for not released languages [was: Re: Registration]
On 9 March 2013 12:52, Andrea Pescetti pesce...@apache.org wrote: On 03/03/2013 janI wrote: On 3 March 2013 17:47, Andrea Pescetti wrote: 1) Check on the Pootle 2.5 release date and features. I would like to see it running on other sites the translate itself, but I am just a negative (have been too long in support). My rule of thumb is release date + 1 month, in order not to fight fight with start problems. Here I agree with Rob that we need to set a deadline. A natural one is the translation period set at https://cwiki.apache.org/** confluence/display/OOOUSERS/**AOO+4.0+Release+Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Planning(beginning in one month). So, considering installation and testing, we would need Pootle 2.5 to be available soon. I've asked the developers if they have a timeline, just to get an idea. 2) Check that policy-wise it's fine to authenticate committers on LDAP and all other volunteers on a local backend. ... infra (gmcdonald) was not positive, but I still think we have a case and should go for it...I do however think a compromise could be a signed ICLA. This has been clarified in the meantime on the Incubator lists (in a discussion otherwise unrelated to OpenOffice). No ICLA needed. http://mail-archives.apache.**org/mod_mbox/incubator-** general/201303.mbox/%3CCAAS6%**3D7hybut%**3DLGZQRkuuJPXKK4KPS6CiXDYE5-** QTmvguYHOVFA%40mail.gmail.com%**3Ehttp://mail-archives.apache.org/mod_mbox/incubator-general/201303.mbox/%3CCAAS6%3D7hybut%3DLGZQRkuuJPXKK4KPS6CiXDYE5-QTmvguYHOVFA%40mail.gmail.com%3E That does not (as I read it) state that we can bypass RTC for non-committers. Allowing non-committers access is one thing, but allowing them to change the source (in this case text) directly is quite another. Translated text is being compiled into our binaries, so there are no difference for source code and and translations. I have no problem (infra might see it differently) if non-committers do a login and provide suggestions (as today), that way we keep RTC. rgds Jan I. 3) Optimize performance so that Pootle is actually usable by several users. That is something on my list of todos, and infra ask me regulary when I do it. ...a bottle of good italian wine when if finally works, together with genLang. OK. And OK for the bottle too! Regards, Andrea. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: update service for not released languages [was: Re: Registration]
janI wrote: That does not (as I read it) state that we can bypass RTC for non-committers. Allowing non-committers access is one thing, but allowing them to change the source (in this case text) directly is quite another. Sure. The setting for new volunteers would be: 1) No paperwork, no ICLA, just create an account on Pootle 2) Translate through suggestions (equivalent to contributing patches) 3) RTC in place (i.e., strings are committed after a review by a committer, exactly as it happens now; what a review is in this context will vary, as it is now, depending on availability and skills of volunteers). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Dual licensing of patches and code
On 13-03-09, at 05:39 , Andrea Pescetti pesce...@apache.org wrote: The conversation below happened in public, but not on the OpenOffice public lists. I believe it's good to record its outcome here on the OpenOffice dev list too. Yes; thanks! Summary: - Question from Jim Jagielski: Is a contribution under ALv2 + MPL + LGPLv3+ acceptable to both OpenOffice and LibreOffice (and Apache Software Foundation and The Document Foundation)? - Answer by the OpenOffice PMC: Yes (speaking for the OpenOffice project). See http://openoffice.apache.org/contributing-code.html Quite. No further discussion needed on the OpenOffice dev list. The ongoing conversation can be read at: http://listarchives.documentfoundation.org/www/discuss/ Thanks, Andrea, this is very useful. Regards, Andrea. Best louis On 05/03/2013 Jim Jagielski wrote: On Mar 5, 2013, at 10:34 AM, Jim Jagielskij...@jagunet.com wrote: So far, I've rec'd an answer from AOO... I'd appreciate an answer from TDF as well. On Mar 4, 2013, at 11:39 AM, Jim Jagielskij...@jagunet.com wrote: BTW, Please be sure that I'm on the CC list, so I get any and all responses :) On Mar 4, 2013, at 8:08 AM, Jim Jagielskij...@jagunet.com wrote: Hello there. This Email is being directed to the 2 controlling bodies of the Apache OpenOffice Project and LibreOffice (TDF). You will notice that I am sending this from my non-ASF account. Recently, at various conferences, I have been approached by numerous people, both 100% volunteer as well as more corporate affiliated, wondering if it was OK for them to submit code, patches and fixes to both AOO and LO at the same time. In general, these people have code that directly patches LO but they also want to dual-license the code such that it can also be consumed by AOO even if it requires work and modification for it to be committed to, and folded into, the AOO repo. My response has always been that as the orig author of their code/patches/whatever, they can license their contributions as they see fit. However, I have been told that they have rec'd word that such dual-licensed code would not be accepted by, or acceptable to, either the AOO project and/or LO and/or TDF and/or the ASF. Therefore, I am asking for official confirmation from both projects and both entities that both projectsSo are fully OK with accepting code/patches/etc that are licensed in such a way as to be 100% consumable by both projects. For example, if I have a code patch which is dual-licensed both under LGPLv3 and ALv2, that such a patch would be acceptable to both LO and AOO. Thank you. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Dual licensing of patches and code
It is not clear to me that the Apache OpenOffice statement answers the question as it was asked at [tdf-discuss]. I read Jim's question as being about multi-licensing (dual- or more). Not about a contributor making a contribution of their original work in two places and under different licenses in each place. That's very different. If the AOO page is considered an affirmative response to Jim's question, then so is Florian Effenberger's pointing to The Document Foundation license-policy page, https://wiki.documentfoundation.org/License_Policy. For me, multi-licensing would be a kind of one-stop contribution that allows the contribution to be used by those who obtain it in accordance with whichever of the multi-licensings they choose. Nothing is done to facilitate that by either project. Furthermore, all of the licenses that are considered have strings on how a contri- bution is accounted for in any combined/derivative work. By the way, there is no mention of the Apache License (any version) in the iCLA that is offered to the ASF and that all committers have on record. It strikes me that a contribution in accordance with the default case in section 5 of the ALv2 is similarly entirely about sections 2, 3 and related definitions. The sections about recipients is not something that governs the contributor's use of their own contribution (a good reason those are not in the iCLA, since an iCLA is entirely about contribution). Cf. http://www.apache.org/licenses/LICENSE-2.0. The manner in which TDF collects license grants is rather different, with contributors specifying the licenses that their work can be released under (i.e., they are multi-licensing their contributions). From all of this, you can surmise what I mean to accomplish by my blanket, public grants regarding my contributions to LibreOffice and Apache projects, so that anyone can make us of those contributions, no matter which project the contributed is made to, with the same permissiveness granted to the ASF in an Apache iCLA. And that can be done without my having to make direct contributions in more than one of those places. - Dennis PS: I am not cross-posting this response. I shall forward my part to [tdf-discuss] however. -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Saturday, March 09, 2013 02:40 To: dev@openoffice.apache.org Cc: Jim Jagielski; disc...@documentfoundation.org; i...@documentfoundation.org Subject: Re: Dual licensing of patches and code The conversation below happened in public, but not on the OpenOffice public lists. I believe it's good to record its outcome here on the OpenOffice dev list too. Summary: - Question from Jim Jagielski: Is a contribution under ALv2 + MPL + LGPLv3+ acceptable to both OpenOffice and LibreOffice (and Apache Software Foundation and The Document Foundation)? - Answer by the OpenOffice PMC: Yes (speaking for the OpenOffice project). See http://openoffice.apache.org/contributing-code.html No further discussion needed on the OpenOffice dev list. The ongoing conversation can be read at: http://listarchives.documentfoundation.org/www/discuss/ Regards, Andrea. [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
FW: GRANT OF LICENSE: Dennis Hamilton LibreOffice contributions
I have made this grant known to The Document Foundation and the LibreOffice project. The TDF notification appears at http://listarchives.documentfoundation.org/www/discuss/msg09424.html. If any use of my contributions to LibreOffice by Apache Projects is questioned, you can cite this grant if applicable. Likewise, before someone on AOO becomes too exercised on seeing any Apache OpenOffice contribution of mine used by the LibreOffice project, please have them be aware of the grant I have made here on the AOO dev list. I will also provide this information on a web site of mine where it may be easier to consult and reference. - Dennis PS: One difference. I replaced recipients, below, with parties obtaining in the ASF Contributions grant. I don't want to churn these, but I will make that update to the LibO one also if anyone finds it preferable (and more clear). -Original Message- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Thursday, March 07, 2013 19:48 To: LOffice Developers List (libreoff...@lists.freedesktop.org) Cc: 'disc...@documentfoundation.org' Subject: Grant of License This grant does not specify any particular open-source license. My intention is to not limit in any way the licensing of works that my contributions are incorporated in. The license is self- contained for that reason. There is no conflict with how LibreOffice releases are licensed and there is nothing that has to be done about the presence of my contributions or derivatives thereof. It is also my intention that everyone having access to my contributions to LibreOffice where they are so contributed be be granted the license whether or not the contribution is accepted into LibreOffice and wherever those recipients might choose to rely on its provisions. The license makes no stipulations one way or the other concerning works of mine that are not contributions to LibreOffice. The license does not transfer copyright nor does it assign patents. - Dennis -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 GrantTDF 1.00 UTF-8 dh:2013-03-07 GRANT OF LICENSE All of my past and future contributions to LibreOffice are with the following stipulations: 1. I hereby grant to all recipients of my LibreOffice contributions a perpetual, worldwide, non-exclusive, no- charge, royalty-free, irrevocable copyright license to reproduce, combine, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute the contributions and such derivative works. 2. I hereby grant to all recipients of my LibreOffice contributions a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer works employing my contributions or derivatives thereof, with such license applying only to those claims controlled by myself, now or in the future, that are necessarily infringed due to characteristics of my LibreOffice contributions and such of those that survive in derivatives. I represent that I am legally entitled to grant the above licenses. March 7, 2013 Dennis E. Hamilton 4401 44th Ave SW Seattle, WA 98116 USA orc...@apache.org PGP Fingerprint 169F 4BC4 3C47 18B2 7062 E04C B011 4B87 2E94 D8E4 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJROVBzAAoJELARS4culNjkfR0H/i/U9lv0jYy8XD/BD4JaFD49 r8ixUNb1FcNxe4ICGaz/2e53doc0wPPgVUyzpB/+nURgObDBBE8eK96RqZ+zt22N yOpxlynRPBxkjfqtw/kaG+v9concl7khghsyZVyieIFOwhMGpMNiZ2tJFDMnKKgW /s3bva+1lsGTUNBJOoNLXyP9iQUWNLFByI15vUshL4aqLsHmdT25gkmDggWQR//h NHH07nJA7mRDY2DotX3IwZrUinyM0rmWpKshF3GTQ+/beuTu2ZBPYFmG3GH4Bx9X UISQoGOKLI1NwtEGkzaao2tYC4QSV7vGXqQDg+A9DMEJ1LFis3iL5wKXUuOJknI= =KW4c -END PGP SIGNATURE- -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cleanup of cwiki...
On Thu, Mar 7, 2013 at 9:44 AM, Kay Schenk kay.sch...@gmail.com wrote: On Wed, Mar 6, 2013 at 4:41 PM, Rob Weir robw...@apache.org wrote: On Wed, Mar 6, 2013 at 6:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Wed, Mar 6, 2013 at 3:50 PM, Alexandro Colorado j...@oooes.org wrote: I rarerly go to the cwiki nowadays. I think this info should be archieved. if there is such a process. However I should also include the things for 3.4.0. Well cwiki is part of our public information, so this is mostly why I ask. We do have an Archive folder. Yes, I created that Archive folder and have gradually been moving pages that were no longer relevant there. This will make it easier if we later want to migrate to MWiki for these. Then we only need to to worry about the active pages. The planning pages you link to were the pages we used to plan the incubation process. These pages were used before we even migrated MWiki over to Apache. -Rob OK, I'll move them to the Archive folder by the end of the weekend. There may be other pages that should moved as well, or at least renamed. Others can decide on this. Ok, I just got done with this bunch of moves. More reorg of the cwiki on a new thread. On 3/6/13, Kay Schenk kay.sch...@gmail.com wrote: In our attempts to try to keep information current, do the following cwiki entries have any relevance any more (the first 6 entries under Project Planning)? https://cwiki.apache.org/confluence/display/OOOUSERS/Build-Dev-Plan https://cwiki.apache.org/confluence/display/OOOUSERS/Build-QA-Plan https://cwiki.apache.org/confluence/display/OOOUSERS/Build-Translate-Plan https://cwiki.apache.org/confluence/display/OOOUSERS/Release-PPMC-Plan https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Dev-Plan https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan Should these be archived? or perhaps deleted entirely? -- MzK Achieving happiness requires the right combination of Zen and Zin. -- Alexandro Colorado Apache OpenOffice Contributor http://es.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK Achieving happiness requires the right combination of Zen and Zin. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK Achieving happiness requires the right combination of Zen and Zin. -- MzK Achieving happiness requires the right combination of Zen and Zin.
suggestion for another cwiki change..new
Right now, for top level categories on cwiki, we have the following: - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Project Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# User Documentation Planhttps://cwiki.apache.org/confluence/display/OOOUSERS/User+Documentation+Plan - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Marketing Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/Marketing+Planning - Development Snapshot Buildshttps://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Project Reportinghttps://cwiki.apache.org/confluence/display/OOOUSERS/Project+Reporting - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Localization Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/Localization+Planning - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# QA Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/QA+Planning - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# AOO4 Brainstorminghttps://cwiki.apache.org/confluence/display/OOOUSERS/AOO4+Brainstorming - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Board Reportshttps://cwiki.apache.org/confluence/display/OOOUSERS/Board+Reports - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Directory of Volunteershttps://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Archive https://cwiki.apache.org/confluence/display/OOOUSERS/Archive - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Strategic Planshttps://cwiki.apache.org/confluence/display/OOOUSERS/Strategic+Plans Now for releases, release planning, we have the AOO 3.4 Release Plan is its own subcategory under Project Planning. However, other Release Plans are under a sub-category called Releases. Are there any objections to promoting Releases to a top-level category and put the various version release plans under that (including 3.4)? I must be in a spring cleaning mood! :} -- MzK Achieving happiness requires the right combination of Zen and Zin.
Re: suggestion for another cwiki change..new
I am personally fine with whatever you do along the lines of surfacing current planning efforts and archiving old efforts. For cwiki articles that should be moved to Mwiki then perhaps a For MWiki category would make sense. If you need someone with full confluence admin rights let me know, I'm happy to help. Regards, Dave On Mar 9, 2013, at 2:23 PM, Kay Schenk wrote: Right now, for top level categories on cwiki, we have the following: - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Project Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# User Documentation Planhttps://cwiki.apache.org/confluence/display/OOOUSERS/User+Documentation+Plan - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Marketing Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/Marketing+Planning - Development Snapshot Buildshttps://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Project Reportinghttps://cwiki.apache.org/confluence/display/OOOUSERS/Project+Reporting - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Localization Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/Localization+Planning - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# QA Planninghttps://cwiki.apache.org/confluence/display/OOOUSERS/QA+Planning - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# AOO4 Brainstorminghttps://cwiki.apache.org/confluence/display/OOOUSERS/AOO4+Brainstorming - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Board Reportshttps://cwiki.apache.org/confluence/display/OOOUSERS/Board+Reports - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Directory of Volunteershttps://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Archive https://cwiki.apache.org/confluence/display/OOOUSERS/Archive - https://cwiki.apache.org/confluence/display/OOOUSERS/Release-Translate-Plan?moved=true# Strategic Planshttps://cwiki.apache.org/confluence/display/OOOUSERS/Strategic+Plans Now for releases, release planning, we have the AOO 3.4 Release Plan is its own subcategory under Project Planning. However, other Release Plans are under a sub-category called Releases. Are there any objections to promoting Releases to a top-level category and put the various version release plans under that (including 3.4)? I must be in a spring cleaning mood! :} -- MzK Achieving happiness requires the right combination of Zen and Zin. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Board report April: infrastructure wishlist
The periodic report to the Apache Board about the status of the OpenOffice project and community is due in about one month. You can find an initial draft of the April report at https://cwiki.apache.org/confluence/display/OOOUSERS/2013+Apr but it is almost completely empty and not worth reading yet. Remember that we have rarely used it this way so far, but the Board report is also an occasion to officially notify the Apache Board about our needs: the Board can decide how to allocate resources, but they need our input for that. Seeing the many recent discussions about infrastructure (wiki, forum, buildbots, Pootle, domains, certificates...) I believe we should use the report to make a sort of Infrastructure wishlist. The aim is to avoid annoying the Infrastructure staff and volunteers with requests; we should tell the Board what our priorities are, so that they can use these priorities in allocating resources. So, feel free to discuss the Infrastructure wishlist here and I will then include it in https://cwiki.apache.org/confluence/display/OOOUSERS/2013+Apr for consideration by the Apache Board (we will probably ask Infra to take a look too before sending). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
