Re: Cwiki: use pictures attached on a different page
Ricardo Berlasso wrote: I started a translation for the release notes as a child page of the release notes itself https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=33295326 But pictures attached to the main release notes page are not displayed on the child page. Is there any easy way to show them? Regards Ricardo Ricardo; I did some playing and was able to copy all of the missing graphics except the sidebar ones with the following procedure using Firefox. 1: Open the English page in your browser in view mode. 2: Open the Spanish page in another window in edit mode 3: In the English page right click on the graphic you want to copy and select copy image location. 4: In the Spanish page highlight the file name of the command that did not work and paste. Because the sidebar ones are thumbnails, the same procdure will not work as the thumbnail can only be created from a graphic that is attached to the page. The only way I found to do this was as follows (again using Firefox): 1: Same as above 2: Open the Spanish page in another window in view mode mode 3: In English page click on a thumbnail to open the the original graphic 3.1 Right click full sizd graphic and select save image as and download it to your local machine. 4: In Spanish page Select Add -- Attachment then browse button on the page that opens and select the file you just downloaded and click the attach button. 6: Repeat as needed. It is know 3:00 AM here so I am heading to bed. I can download th rest of the sidebar graphics and attach thm to the Spanish page later today if it will help you out. Regards Keith - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Cwiki: use pictures attached on a different page
Keith N. McKenna wrote: Ricardo Berlasso wrote: I started a translation for the release notes as a child page of the release notes itself https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=33295326 But pictures attached to the main release notes page are not displayed on the child page. Is there any easy way to show them? Regards Ricardo Ricardo; I did some playing and was able to copy all of the missing graphics except the sidebar ones with the following procedure using Firefox. 1: Open the English page in your browser in view mode. 2: Open the Spanish page in another window in edit mode 3: In the English page right click on the graphic you want to copy and select copy image location. 4: In the Spanish page highlight the file name of the command that did not work and paste. Because the sidebar ones are thumbnails, the same procdure will not work as the thumbnail can only be created from a graphic that is attached to the page. The only way I found to do this was as follows (again using Firefox): 1: Same as above 2: Open the Spanish page in another window in view mode mode 3: In English page click on a thumbnail to open the the original graphic 3.1 Right click full sizd graphic and select save image as and download it to your local machine. 4: In Spanish page Select Add -- Attachment then browse button on the page that opens and select the file you just downloaded and click the attach button. 6: Repeat as needed. It is know 3:00 AM here so I am heading to bed. I can download th rest of the sidebar graphics and attach thm to the Spanish page later today if it will help you out. Regards Keith I couldn't sleep so I uploaded all the sidebar screenshots as attachments and know they render correctly. Regards Keith - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE]: Release OpenOffice 4.0 (RC2)
+1 Release this package as Apache OpenOffice 4.0 -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE][DISCUSS]: Release OpenOffice 4.0 (RC2)
Dear all, The translation of Traditional Chinese was finished (100%). Could it be added to the release now? ^_^ https://translate.apache.org/zh_TW/aoo40/ On 2013/07/18 02:57, Juergen Schmidt said: Am Mittwoch, 17. Juli 2013 um 20:31 schrieb Rob Weir: On Wed, Jul 17, 2013 at 1:13 PM, Jürgen Schmidt jogischm...@gmail.com wrote: On 7/17/13 7:04 PM, Rob Weir wrote: I'm trying to download the source, ASC, MD5 and SHA256 files, but I'm getting errors I'm using the links from this page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot The binaries download fine, but I can't verify the source. Anyone else running into this? well access the files directly via http://people.apache.org/~jsc/developer-snapshots/RC/4.0.0/source/ I haven't updated the wiki, sorry. OK. I verified the hashes and signatures. However, we should clarify which public keys to use. Right now we say four different things: 1) We have a KEYS file in the dist/incubator directory: http://www.apache.org/dist/incubator/ooo/KEYS 2) Your RC page points this file, which doesn't exist: https://people.apache.org/keys/group/ooo.asc 3) Your RC page also points to this file, which is not really suitable since it is in your personal directory: http://people.apache.org/~jsc/developer-snapshots/aoo.KEYS 4) The download page instructions (http://www.openoffice.org/download/checksums/3.4.1_checksums.html#howto) points to this file, which does exist: https://people.apache.org/keys/group/openoffice.asc I thought the convention was to put a KEYS file into the root of the project's dist directory. If so we need to remember to copy it over into our TLP directory for AOO 4.0. yes and there is already one that I have copied from the incubator. I will clean this mess up tomorrow ;-) Juergen Regards, -Rob Juergen -Rob - 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ Greenfoot Taiwan http://greenfoot.westart.tw/ signature.asc Description: OpenPGP digital signature
Re: [VOTE]: Release OpenOffice 4.0 (RC2)
-1 for Traditional Chinese version not included yet. On 2013/07/18 16:54, Rory O'Farrell said: +1 Release this package as Apache OpenOffice 4.0 -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ Greenfoot Taiwan http://greenfoot.westart.tw/ signature.asc Description: OpenPGP digital signature
Re: [VOTE]: Release OpenOffice 4.0 (RC2)
On 7/18/13 12:01 PM, imacat wrote: -1 for Traditional Chinese version not included yet. Traditional Chinese is not part of the vote, means your vote is unqualified and not valid. The reason why it is not included is also known, sorry but this makes no sense. Juergen On 2013/07/18 16:54, Rory O'Farrell said: +1 Release this package as Apache OpenOffice 4.0 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.0_release_blocker denied: [Bug 122780] Clicking Insert in dialog Insert Section incorrectly activated by Edit - paste, causes application hung
j...@apache.org has denied fanyuz...@gmail.com's request for 4.0.0_release_blocker: Bug 122780: Clicking Insert in dialog Insert Section incorrectly activated by Edit - paste, causes application hung https://issues.apache.org/ooo/show_bug.cgi?id=122780 --- Additional Comments from j...@apache.org I tried it with RC 2 on Mac and can't reproduce this. In general it is valid to have paste enabled when the clipboard is filled. In my test case the text from the clipboard is pasted in my new document and everything is fine. It probably depends on what you have in the clipboard and we need further information but I don't think it is a showstopper. But I am willing to change the showstopper flag if we come to the conclusion that it is a serious and reproducable problem - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
User Guides
Hi, all, I just noticed that the latest user guides we have is for OpenOffice.org 3.3, as below: http://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides I wonder if any one is willing to help to update the user guides for AOO 4.0? Thanks! - Shenfeng (Simon)
Re: [VOTE][DISCUSS]: Release OpenOffice 4.0 (RC2)
On 7/18/13 12:00 PM, imacat wrote: Dear all, The translation of Traditional Chinese was finished (100%). Could it be added to the release now? ^_^ no, it is too late and I won't do a respin. But I will integrate the translation on trunk immediately and we can build an unofficial snapshot version. The reason is quite simply, it is too late, we don't know potential other problem triggered by incorrect translation or whatever, nobody has tested this version. But as I wrote in another mail I will integrate it on trunk and we can prepare a snapshot version for testing. Sorry but the timeline were clear and I don't want to make any ad-hoc decision. Juergen https://translate.apache.org/zh_TW/aoo40/ On 2013/07/18 02:57, Juergen Schmidt said: Am Mittwoch, 17. Juli 2013 um 20:31 schrieb Rob Weir: On Wed, Jul 17, 2013 at 1:13 PM, Jürgen Schmidt jogischm...@gmail.com wrote: On 7/17/13 7:04 PM, Rob Weir wrote: I'm trying to download the source, ASC, MD5 and SHA256 files, but I'm getting errors I'm using the links from this page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot The binaries download fine, but I can't verify the source. Anyone else running into this? well access the files directly via http://people.apache.org/~jsc/developer-snapshots/RC/4.0.0/source/ I haven't updated the wiki, sorry. OK. I verified the hashes and signatures. However, we should clarify which public keys to use. Right now we say four different things: 1) We have a KEYS file in the dist/incubator directory: http://www.apache.org/dist/incubator/ooo/KEYS 2) Your RC page points this file, which doesn't exist: https://people.apache.org/keys/group/ooo.asc 3) Your RC page also points to this file, which is not really suitable since it is in your personal directory: http://people.apache.org/~jsc/developer-snapshots/aoo.KEYS 4) The download page instructions (http://www.openoffice.org/download/checksums/3.4.1_checksums.html#howto) points to this file, which does exist: https://people.apache.org/keys/group/openoffice.asc I thought the convention was to put a KEYS file into the root of the project's dist directory. If so we need to remember to copy it over into our TLP directory for AOO 4.0. yes and there is already one that I have copied from the incubator. I will clean this mess up tomorrow ;-) Juergen Regards, -Rob Juergen -Rob - 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 - 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: [VOTE][DISCUSS]: Release OpenOffice 4.0 (RC2)
On 7/18/13 1:07 PM, Jürgen Schmidt wrote: On 7/18/13 12:00 PM, imacat wrote: Dear all, The translation of Traditional Chinese was finished (100%). Could it be added to the release now? ^_^ no, it is too late and I won't do a respin. But I will integrate the translation on trunk immediately and we can build an unofficial snapshot version. The reason is quite simply, it is too late, we don't know potential other problem triggered by incorrect translation or whatever, nobody has tested this version. But as I wrote in another mail I will integrate it on trunk and we can prepare a snapshot version for testing. Sorry but the timeline were clear and I don't want to make any ad-hoc decision. and please create a task for this Juergen Juergen https://translate.apache.org/zh_TW/aoo40/ On 2013/07/18 02:57, Juergen Schmidt said: Am Mittwoch, 17. Juli 2013 um 20:31 schrieb Rob Weir: On Wed, Jul 17, 2013 at 1:13 PM, Jürgen Schmidt jogischm...@gmail.com wrote: On 7/17/13 7:04 PM, Rob Weir wrote: I'm trying to download the source, ASC, MD5 and SHA256 files, but I'm getting errors I'm using the links from this page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot The binaries download fine, but I can't verify the source. Anyone else running into this? well access the files directly via http://people.apache.org/~jsc/developer-snapshots/RC/4.0.0/source/ I haven't updated the wiki, sorry. OK. I verified the hashes and signatures. However, we should clarify which public keys to use. Right now we say four different things: 1) We have a KEYS file in the dist/incubator directory: http://www.apache.org/dist/incubator/ooo/KEYS 2) Your RC page points this file, which doesn't exist: https://people.apache.org/keys/group/ooo.asc 3) Your RC page also points to this file, which is not really suitable since it is in your personal directory: http://people.apache.org/~jsc/developer-snapshots/aoo.KEYS 4) The download page instructions (http://www.openoffice.org/download/checksums/3.4.1_checksums.html#howto) points to this file, which does exist: https://people.apache.org/keys/group/openoffice.asc I thought the convention was to put a KEYS file into the root of the project's dist directory. If so we need to remember to copy it over into our TLP directory for AOO 4.0. yes and there is already one that I have copied from the incubator. I will clean this mess up tomorrow ;-) Juergen Regards, -Rob Juergen -Rob - 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 - 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
[PROPOSAL] Remove WikiAdmin email form
Today I woke up to find approximately 15 spam messages to the dev list, all from the WikiAdmin form. It looks like spammers have found it. The signal/noise ratio for this was never good to start with -- maybe 10 misdirected support questions for every legitimate wiki admin question. But now with the spam it is starting to become a burden on list moderators. I'm proposing we replace the form on the wiki with text that either directs the user to send their admin questions to the dev list, or to enter them into Bugzilla where we have a place for issues related to project-owned infrastructure. Alternatively, maybe there is a way to add a CAPTCHA to the form, preferable one that is impossible to solve ;-) Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Structure of the CWiki?
We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: User Guides
On Thu, Jul 18, 2013 at 7:05 AM, Shenfeng Liu liush...@gmail.com wrote: Hi, all, I just noticed that the latest user guides we have is for OpenOffice.org 3.3, as below: http://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides I wonder if any one is willing to help to update the user guides for AOO 4.0? We have a separate doc mailing list and volunteers who have been working on the wiki here: http://wiki.openoffice.org/wiki/Documentation/UserGuide -Rob Thanks! - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL] Remove WikiAdmin email form
Alternatively, maybe there is a way to add a CAPTCHA to the form, preferable one that is impossible to solve ;-) Seems to be possible like this example: http://brightbyte.de/mw/index.php?title=Special:Contact - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE]: Release OpenOffice 4.0 (RC2)
On Wed, Jul 17, 2013 at 3:40 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi all, this is a call for vote on releasing the following release candidate (RC2 revision 1503704) as Apache OpenOffice 4.0. This will be an important release for Apache OpenOffice with bigger visible UI changes. It is a key milestone to continue the success of OpenOffice. This release candidate provides the following important changes compared to former OpenOffice releases: (1) a major UI change/improvement by introducing a new sidebar concept where the idea is the comes from IBM's Symphony. It's the combination of reimplementing a complete new framework for sidebars and merging the existing sidebar in impress and code of various content panels from the Symphony grant in OpenOffice. (2) 190 fixes from Symphony are merged and integrated, mainly interoperability issues (3) 600 defects are fixed (4) many more features and improvements are integrated For a detailed feature overview please see the release notes under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes. But keep in mind that the release notes are not yet final and will be updated and polished ... The release candidate artifacts (source release, as well as binary releases for 23 languages) and further information how to verify and review Apache OpenOffice 4.0 can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot The related and updated RAT scan for this RC can be found under http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html The RC is based on the release branch AOO400, revision 1503704! Please vote on releasing this package as Apache OpenOffice 4.0. The vote starts now and will be open until: UTC 3:00pm on Friday, 19 July: 2013-07-19 3:00 UTC. But we invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [ ] +1 Release this package as Apache OpenOffice 4.0 [ ] 0 Don't care [ ] -1 Do not release this package because... +1 -Rob - 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
Release communications -- plans
The Release Notes are starting to look very nice. It is worth reviewing if you have not looked recently: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes This is the primary statement of what is in the release. The introductory sections are general enough that this page can be used as a self-contained announcement message. It doesn't require additional context. However, we will have additional announcement statements. 1) There will be a press release. This repeats a subset of the contents of the release nots, but it the format and style that is expected in a press release. Don Harbison took the lead on drafting that. 2) We should also have a brief blog post. Maybe only a paragraph or two and then a link to the Release Notes. I don't want to spend too much time on the blog post since I am almost certain the blog will crash under load. For that reason I'd recommend that we don't promote the blog page via social media, etc., Promote the Release Notes instead. In the past we've translated the blog post. But in this case I'd recommend we focus on translating the Release Notes. 3) A brief announcement to our mailing lists, including the 9000 subscribers of our announcement mailing list. Again, linking back to the Release Notes. 4) Posts to Twitter, Google+, Facebook, etc. This is something where everyone can help spread the news, by sharing, +1'ing, RT'ing,. etc. Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Fwd: Issue with dmake of AOO-3.4.1 for the module stlport
Forwarding to our development mailing list where you are more likely to get an answer. -Rob -- Forwarded message -- From: Singhal, Ankur asing...@ptc.com Date: Thu, Jul 18, 2013 at 9:24 AM Subject: Issue with dmake of AOO-3.4.1 for the module stlport To: us...@openoffice.apache.org us...@openoffice.apache.org Hi Team, I need all your help in resolving my issues, while setting up my machine(Windows 7) for development on OpenOffice. Steps I have followed to build (http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7) 1) I have downloaded source code directly from http://www.openoffice.org/download/other.html#tested-sdk . 2) Did my configure using the below paths: --with-cl-home=/cygdrive/f/Microsoft Visual Studio 9.0/VC \ --with-mspdb-path=/cygdrive/f/Microsoft Visual Studio 9.0/Common7/IDE \ --with-frame-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0 \ --with-psdk-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0 \ --with-midl-path=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0/Bin \ --with-asm-home=/cygdrive/f/Microsoft Visual Studio 9.0/VC/bin \ --with-csc-path=/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5 \ --with-jdk-home=/cygdrive/c/Java64/jdk1.6.0_35\ --with-ant-home=/cygdrive/c/apache-ant-1.9.2 \ --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \ --with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz \ --disable-directx \ --enable-dbgutil \ --enable-pch \ --disable-atl \ --disable-activex \ --disable-binfilter \ --without-junit 3) Bootstrap ran properly. 4) dmake is failing to build stlport module with the error File to Patch: Options that I have tried: 1) Resolving the conflicts by going to separate files like VC7.mak, _monetary.c, _num_put.c, _time_facets.c, _list.h. After resolving conflicts it gives error as below: .\streambuf.cpp(43) : error C2511: 'stlp_std::basic_streambuf_CharT,_Traits::basic_streambuf(FILE *,FILE *)' : overloaded member function not found in 'stlp_std::basic_streambuf_CharT,_Traits' 2) I tried moving from Visual Studio 2008 to Visual Studio 2010. It starts giving other error about a file named exception under Visual Studio. I believe Visual Studio 2010 is not supported by OpenOffice. 3) I tried replacing module stlport-4.5 with stlport-5.2.1 and compiling the module. (With Visual Studio 2008) But I am still facing the same issue. .\streambuf.cpp(43) : error C2511: 'stlp_std::basic_streambuf_CharT,_Traits::basic_streambuf(FILE *,FILE *)' : overloaded member function not found in 'stlp_std::basic_streambuf_CharT,_Traits' It would be very helpful if someone can help me in resolving this issue or if someone have faced the same issue earlier. I believe this is not an issue related to code but a configuration issue. Thanks in Advance, Ankur Singhal - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL] Remove WikiAdmin email form
Contact page is removed. Can we please find a way to qualify BZ requests in the future, so we can avoid triple work (add contact page, move contact page, remove contact page). Qualifying request in BZ should make it obvious if its a wish, or something the community have agreed upon. rgds jan I. On 18 July 2013 15:32, FR web forum ooofo...@free.fr wrote: Alternatively, maybe there is a way to add a CAPTCHA to the form, preferable one that is impossible to solve ;-) Seems to be possible like this example: http://brightbyte.de/mw/index.php?title=Special:Contact - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE]: Release OpenOffice 4.0 (RC2)
2013/7/17 Jürgen Schmidt jogischm...@gmail.com Hi all, this is a call for vote on releasing the following release candidate (RC2 revision 1503704) as Apache OpenOffice 4.0. This will be an important release for Apache OpenOffice with bigger visible UI changes. It is a key milestone to continue the success of OpenOffice. This release candidate provides the following important changes compared to former OpenOffice releases: (1) a major UI change/improvement by introducing a new sidebar concept where the idea is the comes from IBM's Symphony. It's the combination of reimplementing a complete new framework for sidebars and merging the existing sidebar in impress and code of various content panels from the Symphony grant in OpenOffice. (2) 190 fixes from Symphony are merged and integrated, mainly interoperability issues (3) 600 defects are fixed (4) many more features and improvements are integrated For a detailed feature overview please see the release notes under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . But keep in mind that the release notes are not yet final and will be updated and polished ... The release candidate artifacts (source release, as well as binary releases for 23 languages) and further information how to verify and review Apache OpenOffice 4.0 can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot The related and updated RAT scan for this RC can be found under http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html The RC is based on the release branch AOO400, revision 1503704! Please vote on releasing this package as Apache OpenOffice 4.0. The vote starts now and will be open until: UTC 3:00pm on Friday, 19 July: 2013-07-19 3:00 UTC. But we invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [ ] +1 Release this package as Apache OpenOffice 4.0 [ ] 0 Don't care [ ] -1 Do not release this package because... +1 Release this package as Apache OpenOffice 4.0 - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fwd: Issue with dmake of AOO-3.4.1 for the module stlport
On 18.07.2013 16:26, Rob Weir wrote: Forwarding to our development mailing list where you are more likely to get an answer. -Rob -- Forwarded message -- From: Singhal, Ankur asing...@ptc.com Date: Thu, Jul 18, 2013 at 9:24 AM Subject: Issue with dmake of AOO-3.4.1 for the module stlport To: us...@openoffice.apache.org us...@openoffice.apache.org Hi Team, I need all your help in resolving my issues, while setting up my machine(Windows 7) for development on OpenOffice. Steps I have followed to build (http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7) 1) I have downloaded source code directly from http://www.openoffice.org/download/other.html#tested-sdk . 2) Did my configure using the below paths: [...] It would be very helpful if someone can help me in resolving this issue or if someone have faced the same issue earlier. I believe this is not an issue related to code but a configuration issue. Please also use the configure option --without-stlport With all platforms not using stlport any longer stlport4 will be removed and this option will be enabled by default. For a little while longer it is still needed. I updated the Wiki page you referenced. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Structure of the CWiki?
On Thu, Jul 18, 2013 at 10:33 AM, janI j...@apache.org wrote: On 18 July 2013 15:29, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. -Rob rgds jan I. -Rob - 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: [PROPOSAL] Remove WikiAdmin email form
On Thu, Jul 18, 2013 at 10:31 AM, janI j...@apache.org wrote: Contact page is removed. Can we please find a way to qualify BZ requests in the future, so we can avoid triple work (add contact page, move contact page, remove contact page). Qualifying request in BZ should make it obvious if its a wish, or something the community have agreed upon. What Infra does in some cases with JIRA, is require a URL to a thread where the requester sought lazy consensus on the dev list first. Maybe for some kinds of requests we do that? Of course, that is not guaranteed to prevent all issues like this. It only reduces them, -Rob rgds jan I. On 18 July 2013 15:32, FR web forum ooofo...@free.fr wrote: Alternatively, maybe there is a way to add a CAPTCHA to the form, preferable one that is impossible to solve ;-) Seems to be possible like this example: http://brightbyte.de/mw/index.php?title=Special:Contact - 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
It is time to update your entry in the Directory of Volunteers
Make sure you are included in our Directory of Volunteers and that the information is as you want it to appear: https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers This page is linked to (indirectly) from the credits link of the Help/About dialog box in AOO 4.0. It will also be mentioned in release announcements. You can sign up for a wiki account, or send your information directly to me and I will add it for you. Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Release communications -- plans
On Thu, Jul 18, 2013 at 9:45 AM, Rob Weir robw...@apache.org wrote: The Release Notes are starting to look very nice. It is worth reviewing if you have not looked recently: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes This is the primary statement of what is in the release. The introductory sections are general enough that this page can be used as a self-contained announcement message. It doesn't require additional context. However, we will have additional announcement statements. 1) There will be a press release. This repeats a subset of the contents of the release nots, but it the format and style that is expected in a press release. Don Harbison took the lead on drafting that. 2) We should also have a brief blog post. Maybe only a paragraph or two and then a link to the Release Notes. I don't want to spend too much time on the blog post since I am almost certain the blog will crash under load. For that reason I'd recommend that we don't promote the blog page via social media, etc., Promote the Release Notes instead. Draft here: https://blogs.apache.org/preview/OOo/?previewEntry=a_short_celebration_and_then In the past we've translated the blog post. But in this case I'd recommend we focus on translating the Release Notes. 3) A brief announcement to our mailing lists, including the 9000 subscribers of our announcement mailing list. Again, linking back to the Release Notes. 4) Posts to Twitter, Google+, Facebook, etc. This is something where everyone can help spread the news, by sharing, +1'ing, RT'ing,. etc. Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Mac release
On 17.07.2013 22:50, Marcus (OOo) wrote: Am 07/15/2013 07:06 PM, schrieb Marcus (OOo): Am 07/15/2013 06:57 PM, schrieb Andre Fischer: On 15.07.2013 18:08, Kay Schenk wrote: On Mon, Jul 15, 2013 at 8:22 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 07/15/2013 10:18 AM, schrieb Andre Fischer: Issue 122732 [1]reminded me of the problem on Mac where the system complains that the AOO installation packaged does not come from the Apple app store. As Ariel pointed out, this is covered in the release notes for AOO 3.4.0 and 3.4.1. I am not sure that that many users would find the note in the release notes, follow the link to the solution and fix it. I wonder if it would be a good idea to explain this at a more visible place, like the download button for the Mac version. Does anybody know if that is possible? -Andre [1] https://issues.apache.org/ooo/**show_bug.cgi?id=122732https://issues.apache.org/ooo/show_bug.cgi?id=122732 It is possible. However I don't like to have an exception for users of platform X. This would make the index.html more unreadable than it is already. Therefore I've created a general text and link to the release notes (of course, it's still intermediate): http://ooo-site.staging.**apache.org/download/test/**index.htmlhttp://ooo-site.staging.apache.org/download/test/index.html 1) Directly in the main green box. 2) In a second sub-green box. Please have a look and tell what you think. IMHO 1) is better. Marcus 1) is better. I like 1 better, too. But it still looks too prominent. We don't want to scare our users (when only a minority will run into this problem). Maybe an explanation in the release notes is enough. I've decreased the font size a bit. And remember only 1) or 2) will survive at the end. Currently it's duplicated which maybe supports the too prominent look feel. @Andre, all: What do you think: Keep or leave? I just need to know this how to handle the final webpage. Better leave it out. -Andre Thanks Marcus maybe change wording to Click here for known installation issues I know this is going to the Release Notes page...but maybe we should focus on highlighting installation. I just edited Release Notes to duplicate the Mac OS X info in the Upgrading/Installing section. Left it in Known Issues as well. Great thanks. - 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: [VOTE][DISCUSS]: Release OpenOffice 4.0 (RC2)
On 2013/07/18 19:09, Jürgen Schmidt said: On 7/18/13 1:07 PM, Jürgen Schmidt wrote: On 7/18/13 12:00 PM, imacat wrote: Dear all, The translation of Traditional Chinese was finished (100%). Could it be added to the release now? ^_^ no, it is too late and I won't do a respin. But I will integrate the translation on trunk immediately and we can build an unofficial snapshot version. The reason is quite simply, it is too late, we don't know potential other problem triggered by incorrect translation or whatever, nobody has tested this version. But as I wrote in another mail I will integrate it on trunk and we can prepare a snapshot version for testing. Sorry but the timeline were clear and I don't want to make any ad-hoc decision. and please create a task for this I see. Thanks. ^_*' And how to create a task? Sorry I haven't done that before. And thanks to you and everyone for all these works for the release of 4.0. Sorry that I did not help much on this. -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ Greenfoot Taiwan http://greenfoot.westart.tw/ signature.asc Description: OpenPGP digital signature
Re: [VOTE][DISCUSS]: Release OpenOffice 4.0 (RC2)
2013/7/18 imacat ima...@mail.imacat.idv.tw On 2013/07/18 19:09, Jürgen Schmidt said: On 7/18/13 1:07 PM, Jürgen Schmidt wrote: On 7/18/13 12:00 PM, imacat wrote: Dear all, The translation of Traditional Chinese was finished (100%). Could it be added to the release now? ^_^ no, it is too late and I won't do a respin. But I will integrate the translation on trunk immediately and we can build an unofficial snapshot version. The reason is quite simply, it is too late, we don't know potential other problem triggered by incorrect translation or whatever, nobody has tested this version. But as I wrote in another mail I will integrate it on trunk and we can prepare a snapshot version for testing. Sorry but the timeline were clear and I don't want to make any ad-hoc decision. and please create a task for this I see. Thanks. ^_*' And how to create a task? Sorry I haven't done that before. Just create a new issue in bugzilla and assign it to Jürgen. Regards Ricardo And thanks to you and everyone for all these works for the release of 4.0. Sorry that I did not help much on this. -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ Greenfoot Taiwan http://greenfoot.westart.tw/
Re: Release communications -- plans
On Thu, Jul 18, 2013 at 8:16 AM, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 9:45 AM, Rob Weir robw...@apache.org wrote: The Release Notes are starting to look very nice. It is worth reviewing if you have not looked recently: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes This is the primary statement of what is in the release. The introductory sections are general enough that this page can be used as a self-contained announcement message. It doesn't require additional context. However, we will have additional announcement statements. 1) There will be a press release. This repeats a subset of the contents of the release nots, but it the format and style that is expected in a press release. Don Harbison took the lead on drafting that. 2) We should also have a brief blog post. Maybe only a paragraph or two and then a link to the Release Notes. I don't want to spend too much time on the blog post since I am almost certain the blog will crash under load. For that reason I'd recommend that we don't promote the blog page via social media, etc., Promote the Release Notes instead. Draft here: https://blogs.apache.org/preview/OOo/?previewEntry=a_short_celebration_and_then I can't get to blogs at the moment. :/ In the past we've translated the blog post. But in this case I'd recommend we focus on translating the Release Notes. 3) A brief announcement to our mailing lists, including the 9000 subscribers of our announcement mailing list. Again, linking back to the Release Notes. 4) Posts to Twitter, Google+, Facebook, etc. This is something where everyone can help spread the news, by sharing, +1'ing, RT'ing,. etc. Regards, -Rob sounds good... - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
Re: Fwd: Issue with dmake of AOO-3.4.1 for the module stlport
Hi Ankur, is it correct, that you want to build the version 3.4.1? Kind regards Regina Rob Weir schrieb: Forwarding to our development mailing list where you are more likely to get an answer. -Rob -- Forwarded message -- From: Singhal, Ankur asing...@ptc.com Date: Thu, Jul 18, 2013 at 9:24 AM Subject: Issue with dmake of AOO-3.4.1 for the module stlport To: us...@openoffice.apache.org us...@openoffice.apache.org Hi Team, I need all your help in resolving my issues, while setting up my machine(Windows 7) for development on OpenOffice. Steps I have followed to build (http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7) 1) I have downloaded source code directly from http://www.openoffice.org/download/other.html#tested-sdk . 2) Did my configure using the below paths: --with-cl-home=/cygdrive/f/Microsoft Visual Studio 9.0/VC \ --with-mspdb-path=/cygdrive/f/Microsoft Visual Studio 9.0/Common7/IDE \ --with-frame-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0 \ --with-psdk-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0 \ --with-midl-path=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0/Bin \ --with-asm-home=/cygdrive/f/Microsoft Visual Studio 9.0/VC/bin \ --with-csc-path=/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5 \ --with-jdk-home=/cygdrive/c/Java64/jdk1.6.0_35\ --with-ant-home=/cygdrive/c/apache-ant-1.9.2 \ --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \ --with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz \ --disable-directx \ --enable-dbgutil \ --enable-pch \ --disable-atl \ --disable-activex \ --disable-binfilter \ --without-junit 3) Bootstrap ran properly. 4) dmake is failing to build stlport module with the error File to Patch: Options that I have tried: 1) Resolving the conflicts by going to separate files like VC7.mak, _monetary.c, _num_put.c, _time_facets.c, _list.h. After resolving conflicts it gives error as below: .\streambuf.cpp(43) : error C2511: 'stlp_std::basic_streambuf_CharT,_Traits::basic_streambuf(FILE *,FILE *)' : overloaded member function not found in 'stlp_std::basic_streambuf_CharT,_Traits' 2) I tried moving from Visual Studio 2008 to Visual Studio 2010. It starts giving other error about a file named exception under Visual Studio. I believe Visual Studio 2010 is not supported by OpenOffice. 3) I tried replacing module stlport-4.5 with stlport-5.2.1 and compiling the module. (With Visual Studio 2008) But I am still facing the same issue. .\streambuf.cpp(43) : error C2511: 'stlp_std::basic_streambuf_CharT,_Traits::basic_streambuf(FILE *,FILE *)' : overloaded member function not found in 'stlp_std::basic_streambuf_CharT,_Traits' It would be very helpful if someone can help me in resolving this issue or if someone have faced the same issue earlier. I believe this is not an issue related to code but a configuration issue. Thanks in Advance, Ankur Singhal - 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: Structure of the CWiki?
On Thu, Jul 18, 2013 at 6:29 AM, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. -Rob yes, this is a good reorganization format. +1 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
Re: Structure of the CWiki?
On 18 July 2013 16:50, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 10:33 AM, janI j...@apache.org wrote: On 18 July 2013 15:29, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. So because its complicated we keep maintaining at 2 different productsWe should have been a goverment agency. But I get your point, and wont press further for a simpler maintenance. rgds jan I. -Rob rgds jan I. -Rob - 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: [VOTE]: Release OpenOffice 4.0 (RC2)
janI wrote: +1 rgds jan I On 17 July 2013 09:40, Jürgen Schmidt jogischm...@gmail.com wrote: Hi all, this is a call for vote on releasing the following release candidate (RC2 revision 1503704) as Apache OpenOffice 4.0. This will be an important release for Apache OpenOffice with bigger visible UI changes. It is a key milestone to continue the success of OpenOffice. This release candidate provides the following important changes compared to former OpenOffice releases: (1) a major UI change/improvement by introducing a new sidebar concept where the idea is the comes from IBM's Symphony. It's the combination of reimplementing a complete new framework for sidebars and merging the existing sidebar in impress and code of various content panels from the Symphony grant in OpenOffice. (2) 190 fixes from Symphony are merged and integrated, mainly interoperability issues (3) 600 defects are fixed (4) many more features and improvements are integrated For a detailed feature overview please see the release notes under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . But keep in mind that the release notes are not yet final and will be updated and polished ... The release candidate artifacts (source release, as well as binary releases for 23 languages) and further information how to verify and review Apache OpenOffice 4.0 can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot The related and updated RAT scan for this RC can be found under http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html The RC is based on the release branch AOO400, revision 1503704! Please vote on releasing this package as Apache OpenOffice 4.0. The vote starts now and will be open until: UTC 3:00pm on Friday, 19 July: 2013-07-19 3:00 UTC. But we invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [X] +1 Release this package as Apache OpenOffice 4.0 [ ] 0 Don't care [ ] -1 Do not release this package because... - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org [X] +1 Release this package as Apache OpenOffice 4.0 [ ] 0 Don't care [ ] -1 Do not release this package because... Regards Keith - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Structure of the CWiki?
On Jul 18, 2013, at 9:43 AM, janI wrote: On 18 July 2013 16:50, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 10:33 AM, janI j...@apache.org wrote: On 18 July 2013 15:29, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. Exactly. So because its complicated we keep maintaining at 2 different productsWe should have been a goverment agency. Don't cast this kind of note about why we have two wikis. We got the CWiki on day one of the project at Apache. The Mwiki remained at Oracle for many months. (1) It took some time to get a volunteer named Terry E to do the migration which you have taken over. Thank you. (2) Ask on #asfinfra if you want to find out about the difficulties that occurred. The CWiki serves its purpose very well. But I get your point, and wont press further for a simpler maintenance. If the project wants to move to one wiki - sure go ahead. I'll help however I can when I have time. I would perfectly happy to longer have to Admin it which quite frankly has not been much of an effort. How much effort has it taken to manage MWiki? The balance is that the ASF manages Confluence, but the project must manage our own MediaWiki. Since the ASF is considering WordPress as a replacement for Roller. Maybe some of the CWiki content belongs there? Anyone object to the deletion of the unused OOODEV cwiki? Regards, Dave rgds jan I. -Rob rgds jan I. -Rob - 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Structure of the CWiki?
On Thu, Jul 18, 2013 at 2:12 PM, Dave Fisher dave2w...@comcast.net wrote: On Jul 18, 2013, at 9:43 AM, janI wrote: On 18 July 2013 16:50, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 10:33 AM, janI j...@apache.org wrote: On 18 July 2013 15:29, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. Exactly. So because its complicated we keep maintaining at 2 different productsWe should have been a goverment agency. Don't cast this kind of note about why we have two wikis. We got the CWiki on day one of the project at Apache. The Mwiki remained at Oracle for many months. (1) It took some time to get a volunteer named Terry E to do the migration which you have taken over. Thank you. (2) Ask on #asfinfra if you want to find out about the difficulties that occurred. The CWiki serves its purpose very well. But I get your point, and wont press further for a simpler maintenance. If the project wants to move to one wiki - sure go ahead. I'll help however I can when I have time. I would perfectly happy to longer have to Admin it which quite frankly has not been much of an effort. How much effort has it taken to manage MWiki? The balance is that the ASF manages Confluence, but the project must manage our own MediaWiki. Since the ASF is considering WordPress as a replacement for Roller. Maybe some of the CWiki content belongs there? Certainly the blog could move to WordPress. I know WordPress pretty well, been using it for 8 years or so on my personal blog. It has support for blog posts as well as pages, which can be static content that is not tied to a post or a typical RSS stream. But I'd probably just use that for content that is very strongly associated with the blog, e.g., a comment policy or a page that tells where to go for support. It might not be worth using it for yet-another-cms for the project. Most of the stuff we have on CWiki is inward-facing pages that we use to coordinate on parts of the project. I think that is distinct from the blog content. And maybe even distinct from what most of the MWiki is used for, which is more user facing. As you know, we've had this discussion before and more than once. We have the same situation with www.openoffice.org versus openoffice.apache.org. Project-facing versus user-facing. Of course, this doesn't determine our technical approach. We could use a single technology and have both project-facing and user-facing content in the same tool, if we structured it right. But the rewards seem less tangible than the effort required to get there. Regards, -Rob Anyone object to the deletion of the unused OOODEV cwiki? Regards, Dave rgds jan I. -Rob rgds jan I. -Rob - 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Structure of the CWiki?
On 18 July 2013 20:12, Dave Fisher dave2w...@comcast.net wrote: On Jul 18, 2013, at 9:43 AM, janI wrote: On 18 July 2013 16:50, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 10:33 AM, janI j...@apache.org wrote: On 18 July 2013 15:29, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. Exactly. So because its complicated we keep maintaining at 2 different productsWe should have been a goverment agency. Don't cast this kind of note about why we have two wikis. We got the CWiki on day one of the project at Apache. The Mwiki remained at Oracle for many months. (1) It took some time to get a volunteer named Terry E to do the migration which you have taken over. Thank you. (2) Ask on #asfinfra if you want to find out about the difficulties that occurred. I know when AOO got CWIKI and also part of the remaining story. I have also seen quite a lot of Terry E work (He has done quite a lot and I am sorry it did not work out between him and infra). on #asfinfra (where I am online) root@ already told me some time ago about the initial setup and terry E. These difficulties was more setup type problems and not really conversion problems (acc. infra) As a maintainer of several servers, I think its normal to think how can we do betterI cannot see why I should not raise concerns, when I have them, to me an argument about a thing being complicated is not an argument for not doing the right thing. Admitted I did not need to write the agency part, but I really feel stuck in the discussion. The CWiki serves its purpose very well. I am sure it does, and did not dispute thatI am solely thinking of our stretched maintenance resources (including infra), at some point we do need to consolidate our information stores. We have our different www's, different wikis and a blog all containing bits and pieces of information, some of it redundant (and often not maintained in some of the flavours), on top of that we have the forums. My point is, independent how difficult it is, we should target a consolidated set of information, with a clear signal, where which info is kept. But I get your point, and wont press further for a simpler maintenance. If the project wants to move to one wiki - sure go ahead. I'll help however I can when I have time. I would perfectly happy to longer have to Admin it which quite frankly has not been much of an effort. How much effort has it taken to manage MWiki? You already help a lot, thanks for that, and you are right it will be a hard job to get it done after a community decision. The balance is that the ASF manages Confluence, but the project must manage our own MediaWiki. I have no opinion on which systems shall survive, if we think CWIKI is the better choice then so be it. But please dont forget ASF is you, me and many others. What I mean is, when I maintain the servers, its hard to see if I wear my AOO cap or my ASF/INFRA cap. Since the ASF is considering WordPress as a replacement for Roller. Maybe some of the CWiki content belongs there? It is at the moment only a infra consideration and test. I have not dared suggest it, but WP would be able to handle blog, cwiki, mediawiki and large parts of www. Anyone object to the deletion of the unused OOODEV cwiki? +1 rgds jan I Regards, Dave
Re: Openoffice Base copy function
On Mon, Jul 15, 2013 at 1:16 PM, John 73 WA4GPS 73wa4...@sc.rr.com wrote: In my club membership data base, I can use Filter by Selection to isolate a group of members that I want to send an E-mail to and, if I click on the E-mail Address field label, the entire column is highlighted but when I click on Copy and then try to Paste the block of E-mail Addresses in the Bcc field of on E-mail, I only get one E-mail address! I need to be able to copy the entire block of E-mail Addresses. John I had the same experience. You might get additional help on how to do what you want from either the users list or the Forums. See our Support page: http://www.openoffice.org/support/index.html -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
Re: Structure of the CWiki?
On Thu, Jul 18, 2013 at 11:12 AM, Dave Fisher dave2w...@comcast.net wrote: On Jul 18, 2013, at 9:43 AM, janI wrote: On 18 July 2013 16:50, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 10:33 AM, janI j...@apache.org wrote: On 18 July 2013 15:29, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. Exactly. So because its complicated we keep maintaining at 2 different productsWe should have been a goverment agency. Don't cast this kind of note about why we have two wikis. We got the CWiki on day one of the project at Apache. The Mwiki remained at Oracle for many months. (1) It took some time to get a volunteer named Terry E to do the migration which you have taken over. Thank you. (2) Ask on #asfinfra if you want to find out about the difficulties that occurred. The CWiki serves its purpose very well. I LIKE CWiki! But I get your point, and wont press further for a simpler maintenance. If the project wants to move to one wiki - sure go ahead. I'll help however I can when I have time. I would perfectly happy to longer have to Admin it which quite frankly has not been much of an effort. How much effort has it taken to manage MWiki? The balance is that the ASF manages Confluence, but the project must manage our own MediaWiki. I propose we take up the issue of wiki merging again soon. A lot has changed since our last in-depth discussion on this. And, a lot has changed with each of these products since that discussion. Since the ASF is considering WordPress as a replacement for Roller. Maybe some of the CWiki content belongs there? Anyone object to the deletion of the unused OOODEV cwiki? Regards, Dave rgds jan I. -Rob rgds jan I. -Rob - 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
Re: Structure of the CWiki?
On Thu, Jul 18, 2013 at 11:40 AM, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 2:12 PM, Dave Fisher dave2w...@comcast.net wrote: On Jul 18, 2013, at 9:43 AM, janI wrote: On 18 July 2013 16:50, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 10:33 AM, janI j...@apache.org wrote: On 18 July 2013 15:29, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki. When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. Exactly. So because its complicated we keep maintaining at 2 different productsWe should have been a goverment agency. Don't cast this kind of note about why we have two wikis. We got the CWiki on day one of the project at Apache. The Mwiki remained at Oracle for many months. (1) It took some time to get a volunteer named Terry E to do the migration which you have taken over. Thank you. (2) Ask on #asfinfra if you want to find out about the difficulties that occurred. The CWiki serves its purpose very well. But I get your point, and wont press further for a simpler maintenance. If the project wants to move to one wiki - sure go ahead. I'll help however I can when I have time. I would perfectly happy to longer have to Admin it which quite frankly has not been much of an effort. How much effort has it taken to manage MWiki? The balance is that the ASF manages Confluence, but the project must manage our own MediaWiki. Since the ASF is considering WordPress as a replacement for Roller. Maybe some of the CWiki content belongs there? Certainly the blog could move to WordPress. I know WordPress pretty well, been using it for 8 years or so on my personal blog. It has support for blog posts as well as pages, which can be static content that is not tied to a post or a typical RSS stream. But I'd probably just use that for content that is very strongly associated with the blog, e.g., a comment policy or a page that tells where to go for support. It might not be worth using it for yet-another-cms for the project. Most of the stuff we have on CWiki is inward-facing pages that we use to coordinate on parts of the project. I think that is distinct from the blog content. And maybe even distinct from what most of the MWiki is used for, which is more user facing. As you know, we've had this discussion before and more than once. We have the same situation with www.openoffice.org versus openoffice.apache.org. Project-facing versus user-facing. Of course, this doesn't determine our technical approach. We could use a single technology and have both project-facing and user-facing content in the same tool, if we structured it right. ...yes... But the rewards seem less tangible than the effort required to get there. I'm not sure about this one. Migration, of some sort, is a one time deal. Administration is forever. Regards, -Rob Anyone object to the deletion of the unused OOODEV cwiki? Regards, Dave rgds jan I. -Rob rgds jan I. -Rob - 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
Re: [VOTE]: Release OpenOffice 4.0 (RC2)
On Wed, Jul 17, 2013 at 12:40 AM, Jürgen Schmidt jogischm...@gmail.comwrote: Hi all, this is a call for vote on releasing the following release candidate (RC2 revision 1503704) as Apache OpenOffice 4.0. This will be an important release for Apache OpenOffice with bigger visible UI changes. It is a key milestone to continue the success of OpenOffice. This release candidate provides the following important changes compared to former OpenOffice releases: (1) a major UI change/improvement by introducing a new sidebar concept where the idea is the comes from IBM's Symphony. It's the combination of reimplementing a complete new framework for sidebars and merging the existing sidebar in impress and code of various content panels from the Symphony grant in OpenOffice. (2) 190 fixes from Symphony are merged and integrated, mainly interoperability issues (3) 600 defects are fixed (4) many more features and improvements are integrated For a detailed feature overview please see the release notes under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . But keep in mind that the release notes are not yet final and will be updated and polished ... The release candidate artifacts (source release, as well as binary releases for 23 languages) and further information how to verify and review Apache OpenOffice 4.0 can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot The related and updated RAT scan for this RC can be found under http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html The RC is based on the release branch AOO400, revision 1503704! Please vote on releasing this package as Apache OpenOffice 4.0. The vote starts now and will be open until: UTC 3:00pm on Friday, 19 July: 2013-07-19 3:00 UTC. But we invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [ ] +1 Release this package as Apache OpenOffice 4.0 [ ] 0 Don't care [ ] -1 Do not release this package because... +1 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7
Who completed the OpenOffice 3.3 Solaris x86 build? It seems that we could easily add the new vendor to the few files listed here, then recompile. I am sure someone already has the environment set up considering the code was compiled for Solaris x86 in the past. This could then become a version 3.3 update to support Java 7. Thought? -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Wednesday, July 03, 2013 11:40 PM To: dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don'; Steele, Raymond Subject: EXTERNAL: Re: OpenOffice 3.3 and Java 7 On 03/07/2013 Dennis E. Hamilton wrote: 2. OpenOffice.org, in part of its detection of available JREs, may be looking for Sun as the provider. It might not recognize JREs that now have Oracle identified as the provider. This used to be a problem (in general, not Solaris-specific) for JREs that had Oracle as a vendor. See https://issues.apache.org/ooo/show_bug.cgi?id=118352 http://svn.apache.org/viewvc?view=revisionrevision=1229371 http://svn.apache.org/viewvc?view=revisionrevision=r1333165 Note that 3.3.0 is unsupported. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7
No distribution of OpenOffice.org 3.3 was built at Apache OpenOffice. (There was an out-of-cycle security fix, but that did not require rebuilding the application. I don't believe that fix was provided for Solaris, however.) The Apache OpenOffice code base was based on OpenOffice.org code that was later than OpenOffice.org 3.3 code. As you know, Apache OpenOffice has not provided any Solaris builds for its releases. It would appear that the best that can happen is if a private party with an eye on this list is able to offer such a rebuild. - Dennis -Original Message- From: Steele, Raymond [mailto:raymond.ste...@lmco.com] Sent: Thursday, July 18, 2013 12:29 PM To: Andrea Pescetti; dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don' Subject: RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7 Who completed the OpenOffice 3.3 Solaris x86 build? It seems that we could easily add the new vendor to the few files listed here, then recompile. I am sure someone already has the environment set up considering the code was compiled for Solaris x86 in the past. This could then become a version 3.3 update to support Java 7. Thought? -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Wednesday, July 03, 2013 11:40 PM To: dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don'; Steele, Raymond Subject: EXTERNAL: Re: OpenOffice 3.3 and Java 7 On 03/07/2013 Dennis E. Hamilton wrote: 2. OpenOffice.org, in part of its detection of available JREs, may be looking for Sun as the provider. It might not recognize JREs that now have Oracle identified as the provider. This used to be a problem (in general, not Solaris-specific) for JREs that had Oracle as a vendor. See https://issues.apache.org/ooo/show_bug.cgi?id=118352 http://svn.apache.org/viewvc?view=revisionrevision=1229371 http://svn.apache.org/viewvc?view=revisionrevision=r1333165 Note that 3.3.0 is unsupported. Regards, Andrea. - 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: EXTERNAL: Re: OpenOffice 3.3 and Java 7
Am 07/18/2013 10:14 PM, schrieb Steele, Raymond: Thanks for responding. Do you know who built the Solaris Intel distributions posted on this page? http://www.openoffice.org/download/legacy/other.html I am not adverse to rebuilding the code for Solaris 10 x86, but in the meantime, I am looking for a quicker solution to my problem. I know my answer will not help you: The inventor of Solaris - Sun Microsystems - has done all the Solaris x86 and Sparc builds offered on the webpage, and also all Windows, Linux and Mac OS builds. Marcus -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Thursday, July 18, 2013 1:08 PM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7 No distribution of OpenOffice.org 3.3 was built at Apache OpenOffice. (There was an out-of-cycle security fix, but that did not require rebuilding the application. I don't believe that fix was provided for Solaris, however.) The Apache OpenOffice code base was based on OpenOffice.org code that was later than OpenOffice.org 3.3 code. As you know, Apache OpenOffice has not provided any Solaris builds for its releases. It would appear that the best that can happen is if a private party with an eye on this list is able to offer such a rebuild. - Dennis -Original Message- From: Steele, Raymond [mailto:raymond.ste...@lmco.com] Sent: Thursday, July 18, 2013 12:29 PM To: Andrea Pescetti; dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don' Subject: RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7 Who completed the OpenOffice 3.3 Solaris x86 build? It seems that we could easily add the new vendor to the few files listed here, then recompile. I am sure someone already has the environment set up considering the code was compiled for Solaris x86 in the past. This could then become a version 3.3 update to support Java 7. Thought? -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Wednesday, July 03, 2013 11:40 PM To: dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don'; Steele, Raymond Subject: EXTERNAL: Re: OpenOffice 3.3 and Java 7 On 03/07/2013 Dennis E. Hamilton wrote: 2. OpenOffice.org, in part of its detection of available JREs, may be looking for Sun as the provider. It might not recognize JREs that now have Oracle identified as the provider. This used to be a problem (in general, not Solaris-specific) for JREs that had Oracle as a vendor. See https://issues.apache.org/ooo/show_bug.cgi?id=118352 http://svn.apache.org/viewvc?view=revisionrevision=1229371 http://svn.apache.org/viewvc?view=revisionrevision=r1333165 Note that 3.3.0 is unsupported. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7
Thanks and yes, no help! -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Thursday, July 18, 2013 1:28 PM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: OpenOffice 3.3 and Java 7 Am 07/18/2013 10:14 PM, schrieb Steele, Raymond: Thanks for responding. Do you know who built the Solaris Intel distributions posted on this page? http://www.openoffice.org/download/legacy/other.html I am not adverse to rebuilding the code for Solaris 10 x86, but in the meantime, I am looking for a quicker solution to my problem. I know my answer will not help you: The inventor of Solaris - Sun Microsystems - has done all the Solaris x86 and Sparc builds offered on the webpage, and also all Windows, Linux and Mac OS builds. Marcus -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Thursday, July 18, 2013 1:08 PM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7 No distribution of OpenOffice.org 3.3 was built at Apache OpenOffice. (There was an out-of-cycle security fix, but that did not require rebuilding the application. I don't believe that fix was provided for Solaris, however.) The Apache OpenOffice code base was based on OpenOffice.org code that was later than OpenOffice.org 3.3 code. As you know, Apache OpenOffice has not provided any Solaris builds for its releases. It would appear that the best that can happen is if a private party with an eye on this list is able to offer such a rebuild. - Dennis -Original Message- From: Steele, Raymond [mailto:raymond.ste...@lmco.com] Sent: Thursday, July 18, 2013 12:29 PM To: Andrea Pescetti; dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don' Subject: RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7 Who completed the OpenOffice 3.3 Solaris x86 build? It seems that we could easily add the new vendor to the few files listed here, then recompile. I am sure someone already has the environment set up considering the code was compiled for Solaris x86 in the past. This could then become a version 3.3 update to support Java 7. Thought? -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Wednesday, July 03, 2013 11:40 PM To: dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don'; Steele, Raymond Subject: EXTERNAL: Re: OpenOffice 3.3 and Java 7 On 03/07/2013 Dennis E. Hamilton wrote: 2. OpenOffice.org, in part of its detection of available JREs, may be looking for Sun as the provider. It might not recognize JREs that now have Oracle identified as the provider. This used to be a problem (in general, not Solaris-specific) for JREs that had Oracle as a vendor. See https://issues.apache.org/ooo/show_bug.cgi?id=118352 http://svn.apache.org/viewvc?view=revisionrevision=1229371 http://svn.apache.org/viewvc?view=revisionrevision=r1333165 Note that 3.3.0 is unsupported. Regards, Andrea.
Re: Structure of the CWiki?
Am 07/18/2013 08:41 PM, schrieb janI: On 18 July 2013 20:12, Dave Fisherdave2w...@comcast.net wrote: On Jul 18, 2013, at 9:43 AM, janI wrote: On 18 July 2013 16:50, Rob Weirrobw...@apache.org wrote: On Thu, Jul 18, 2013 at 10:33 AM, janIj...@apache.org wrote: On 18 July 2013 15:29, Rob Weirrobw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki.When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. Exactly. So because its complicated we keep maintaining at 2 different productsWe should have been a goverment agency. Don't cast this kind of note about why we have two wikis. We got the CWiki on day one of the project at Apache. The Mwiki remained at Oracle for many months. (1) It took some time to get a volunteer named Terry E to do the migration which you have taken over. Thank you. (2) Ask on #asfinfra if you want to find out about the difficulties that occurred. I know when AOO got CWIKI and also part of the remaining story. I have also seen quite a lot of Terry E work (He has done quite a lot and I am sorry it did not work out between him and infra). on #asfinfra (where I am online) root@ already told me some time ago about the initial setup and terry E. These difficulties was more setup type problems and not really conversion problems (acc. infra) As a maintainer of several servers, I think its normal to think how can we do betterI cannot see why I should not raise concerns, when I have them, to me an argument about a thing being complicated is not an argument for not doing the right thing. Admitted I did not need to write the agency part, but I really feel stuck in the discussion. The CWiki serves its purpose very well. I am sure it does, and did not dispute thatI am solely thinking of our stretched maintenance resources (including infra), at some point we do need to consolidate our information stores. We have our different www's, different wikis and a blog all containing bits and pieces of information, some of it redundant (and often not maintained in some of the flavours), on top of that we have the forums. My point is, independent how difficult it is, we should target a consolidated set of information, with a clear signal, where which info is kept. But I get your point, and wont press further for a simpler maintenance. If the project wants to move to one wiki - sure go ahead. I'll help however I can when I have time. I would perfectly happy to longer have to Admin it which quite frankly has not been much of an effort. How much effort has it taken to manage MWiki? You already help a lot, thanks for that, and you are right it will be a hard job to get it done after a community decision. The balance is that the ASF manages Confluence, but the project must manage our own MediaWiki. I have no opinion on which systems shall survive, if we think CWIKI is the better choice then so be it. But please dont forget ASF is you, me and many others. What I mean is, when I maintain the servers, its hard to see if I wear my AOO cap or my ASF/INFRA cap. Since the ASF is considering WordPress as a replacement for Roller. Maybe some of the CWiki content belongs there? It is at the moment only a infra consideration and test. I have not dared suggest it, but WP would be able to handle blog, cwiki, mediawiki and large parts of www. Anyone object to the deletion of the unused OOODEV cwiki? +1 rgds jan I I have nothing against deletion. And I think
Re: Mac release
Am 07/18/2013 05:23 PM, schrieb Andre Fischer: On 17.07.2013 22:50, Marcus (OOo) wrote: Am 07/15/2013 07:06 PM, schrieb Marcus (OOo): Am 07/15/2013 06:57 PM, schrieb Andre Fischer: On 15.07.2013 18:08, Kay Schenk wrote: On Mon, Jul 15, 2013 at 8:22 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 07/15/2013 10:18 AM, schrieb Andre Fischer: Issue 122732 [1]reminded me of the problem on Mac where the system complains that the AOO installation packaged does not come from the Apple app store. As Ariel pointed out, this is covered in the release notes for AOO 3.4.0 and 3.4.1. I am not sure that that many users would find the note in the release notes, follow the link to the solution and fix it. I wonder if it would be a good idea to explain this at a more visible place, like the download button for the Mac version. Does anybody know if that is possible? -Andre [1] https://issues.apache.org/ooo/**show_bug.cgi?id=122732https://issues.apache.org/ooo/show_bug.cgi?id=122732 It is possible. However I don't like to have an exception for users of platform X. This would make the index.html more unreadable than it is already. Therefore I've created a general text and link to the release notes (of course, it's still intermediate): http://ooo-site.staging.**apache.org/download/test/**index.htmlhttp://ooo-site.staging.apache.org/download/test/index.html 1) Directly in the main green box. 2) In a second sub-green box. Please have a look and tell what you think. IMHO 1) is better. Marcus 1) is better. I like 1 better, too. But it still looks too prominent. We don't want to scare our users (when only a minority will run into this problem). Maybe an explanation in the release notes is enough. I've decreased the font size a bit. And remember only 1) or 2) will survive at the end. Currently it's duplicated which maybe supports the too prominent look feel. @Andre, all: What do you think: Keep or leave? I just need to know this how to handle the final webpage. Better leave it out. OK, it's gone from the test webpage. Marcus maybe change wording to Click here for known installation issues I know this is going to the Release Notes page...but maybe we should focus on highlighting installation. I just edited Release Notes to duplicate the Mac OS X info in the Upgrading/Installing section. Left it in Known Issues as well. Great thanks. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Cwiki vs Media WIki again...
In continuing discussions, some of you may be interested in this site: http://www.wikimatrix.org/ No sure about accuracy. -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
Re: Cwiki vs Media WIki again...
Am 07/18/2013 11:21 PM, schrieb Kay Schenk: In continuing discussions, some of you may be interested in this site: http://www.wikimatrix.org/ No sure about accuracy. Great link, thanks! Now both can be compared with facts - assumed they are correct. ;-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Cwiki vs Media WIki again...
On 18 July 2013 23:32, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 07/18/2013 11:21 PM, schrieb Kay Schenk: In continuing discussions, some of you may be interested in this site: http://www.wikimatrix.org/ No sure about accuracy. Great link, thanks! Now both can be compared with facts - assumed they are correct. ;-) great site, thx a lot. I ran a compare and the difference I look after showed up. sadly enough it does not compare to WP. rgds jan I. Marcus --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7
The 3.3.0 Releases were all by Oracle on January 18, 2011. - Dennis -Original Message- From: Steele, Raymond [mailto:raymond.ste...@lmco.com] Sent: Thursday, July 18, 2013 01:15 PM To: dennis.hamil...@acm.org; dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7 Thanks for responding. Do you know who built the Solaris Intel distributions posted on this page? http://www.openoffice.org/download/legacy/other.html I am not adverse to rebuilding the code for Solaris 10 x86, but in the meantime, I am looking for a quicker solution to my problem. -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Thursday, July 18, 2013 1:08 PM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7 No distribution of OpenOffice.org 3.3 was built at Apache OpenOffice. (There was an out-of-cycle security fix, but that did not require rebuilding the application. I don't believe that fix was provided for Solaris, however.) The Apache OpenOffice code base was based on OpenOffice.org code that was later than OpenOffice.org 3.3 code. As you know, Apache OpenOffice has not provided any Solaris builds for its releases. It would appear that the best that can happen is if a private party with an eye on this list is able to offer such a rebuild. - Dennis -Original Message- From: Steele, Raymond [mailto:raymond.ste...@lmco.com] Sent: Thursday, July 18, 2013 12:29 PM To: Andrea Pescetti; dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don' Subject: RE: EXTERNAL: Re: OpenOffice 3.3 and Java 7 Who completed the OpenOffice 3.3 Solaris x86 build? It seems that we could easily add the new vendor to the few files listed here, then recompile. I am sure someone already has the environment set up considering the code was compiled for Solaris x86 in the past. This could then become a version 3.3 update to support Java 7. Thought? -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Wednesday, July 03, 2013 11:40 PM To: dev@openoffice.apache.org Cc: Dennis E. Hamilton; 'Don'; Steele, Raymond Subject: EXTERNAL: Re: OpenOffice 3.3 and Java 7 On 03/07/2013 Dennis E. Hamilton wrote: 2. OpenOffice.org, in part of its detection of available JREs, may be looking for Sun as the provider. It might not recognize JREs that now have Oracle identified as the provider. This used to be a problem (in general, not Solaris-specific) for JREs that had Oracle as a vendor. See https://issues.apache.org/ooo/show_bug.cgi?id=118352 http://svn.apache.org/viewvc?view=revisionrevision=1229371 http://svn.apache.org/viewvc?view=revisionrevision=r1333165 Note that 3.3.0 is unsupported. Regards, Andrea. - 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: [VOTE]: Release OpenOffice 4.0 (RC2)
+1 Marcus Am 07/17/2013 09:40 AM, schrieb Jürgen Schmidt: Hi all, this is a call for vote on releasing the following release candidate (RC2 revision 1503704) as Apache OpenOffice 4.0. This will be an important release for Apache OpenOffice with bigger visible UI changes. It is a key milestone to continue the success of OpenOffice. This release candidate provides the following important changes compared to former OpenOffice releases: (1) a major UI change/improvement by introducing a new sidebar concept where the idea is the comes from IBM's Symphony. It's the combination of reimplementing a complete new framework for sidebars and merging the existing sidebar in impress and code of various content panels from the Symphony grant in OpenOffice. (2) 190 fixes from Symphony are merged and integrated, mainly interoperability issues (3) 600 defects are fixed (4) many more features and improvements are integrated For a detailed feature overview please see the release notes under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes. But keep in mind that the release notes are not yet final and will be updated and polished ... The release candidate artifacts (source release, as well as binary releases for 23 languages) and further information how to verify and review Apache OpenOffice 4.0 can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot The related and updated RAT scan for this RC can be found under http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html The RC is based on the release branch AOO400, revision 1503704! Please vote on releasing this package as Apache OpenOffice 4.0. The vote starts now and will be open until: UTC 3:00pm on Friday, 19 July: 2013-07-19 3:00 UTC. But we invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [ ] +1 Release this package as Apache OpenOffice 4.0 [ ] 0 Don't care [ ] -1 Do not release this package because... - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Volunteering to create Pootle accounts
I expect an increased traffic of Pootle account requests (from non-committers) next week, when we will release version 4.0 and new volunteers will want to translate OpenOffice 4.0 into their mother tongue. Unless we are already covered for a timely creation of accounts, I volunteer to get administrator privileges in Pootle and to standardize the procedure for non-committers to ask for a Pootle account. If we are already covered, or we have someone else wishing to take care of this, just say so, and I'll be happier! But we must avoid delays and standardize procedures, at least for the languages that are already in Pootle. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Structure of the CWiki?
On 18 July 2013 23:31, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 2:41 PM, janI j...@apache.org wrote: On 18 July 2013 20:12, Dave Fisher dave2w...@comcast.net wrote: On Jul 18, 2013, at 9:43 AM, janI wrote: On 18 July 2013 16:50, Rob Weir robw...@apache.org wrote: On Thu, Jul 18, 2013 at 10:33 AM, janI j...@apache.org wrote: On 18 July 2013 15:29, Rob Weir robw...@apache.org wrote: We have the opportunity to restructure the pages on our CWiki. When looking over the current structure it looks like we've been taking two entirely different approaches to organizing the information: 1) A team-oriented approach, where at the top organizational level there are parent pages for each team, dev, qa, doc, l10n., etc. 2) A release-oriented approach, where the top level is a specific release, like AOO 3.4.1 or 4.0, and subpages are used for status and plans for functional groups. These two approaches look like they are both being used, but not consistently. I wonder if would be worth being more consistent, and doing something like: 1) Have a top-level page for each functional group, for tracking release-independent information, e.g., links to useful other pages, lists of volunteers, how to information. The stuff that does not change from release to release. It is information about the team and what they do, not information about tasks for a specific release. 2) Then have top-level release-specific pages, where we store plans and status reports, dashboards, etc., associated with a release. I think this is not so far from what the CWiki was evolving toward. If we anyhow think about restructuring, why not also think of a merge with mwiki...it does not seem correct that we need all these flavours of wiki, and it do cost maintenance. Restructuring is just drag and drop in CWiki. Migration would be more effort, but we could restructure while migrating. But a non-trivial effort unless there is a tool that automates page conversion, moving images, etc. Exactly. So because its complicated we keep maintaining at 2 different productsWe should have been a goverment agency. Don't cast this kind of note about why we have two wikis. We got the CWiki on day one of the project at Apache. The Mwiki remained at Oracle for many months. (1) It took some time to get a volunteer named Terry E to do the migration which you have taken over. Thank you. (2) Ask on #asfinfra if you want to find out about the difficulties that occurred. I know when AOO got CWIKI and also part of the remaining story. I have also seen quite a lot of Terry E work (He has done quite a lot and I am sorry it did not work out between him and infra). on #asfinfra (where I am online) root@ already told me some time ago about the initial setup and terry E. These difficulties was more setup type problems and not really conversion problems (acc. infra) As a maintainer of several servers, I think its normal to think how can we do betterI cannot see why I should not raise concerns, when I have them, to me an argument about a thing being complicated is not an argument for not doing the right thing. Admitted I did not need to write the agency part, but I really feel stuck in the discussion. No one ever said you shouldn't raise concerns. To me it looked like you self-censored yourself when you said you wont press further . But you do overstate things when you express them in absolute terms, e.g., saying this is about doing the right thing. Remember, there are many right things any of us could be doing in the project (or elsewhere), but there are only 24 hours in the day. This necessarily leads to prioritization. Migrating existing, perfectly good content from one technical infrastructure to another is not high on my personal list of priorities. This, however, should not inhibit you are anyone else interested from exploring this further. The direction is set by those who think something is important, not by those, like myself, who are indifferent. you are completly rightdoing the right them was solely from a maintenance perspective I should have added that. its just I am getting a bit tired of doing tiresome maintenance, when I could use the same time to bring us forward (even though I am not sure what the target is). rgds jan I. Regards, -Rob The CWiki serves its purpose very well. I am sure it does, and did not dispute thatI am solely thinking of our stretched maintenance resources (including infra), at some point we do need to consolidate our information stores. We have our different www's, different wikis and a blog all containing bits and pieces of information, some of it redundant (and often not maintained in some of the flavours), on top of that we have the
Re: Volunteering to create Pootle accounts
On 19 July 2013 00:46, Andrea Pescetti pesce...@apache.org wrote: I expect an increased traffic of Pootle account requests (from non-committers) next week, when we will release version 4.0 and new volunteers will want to translate OpenOffice 4.0 into their mother tongue. Unless we are already covered for a timely creation of accounts, I volunteer to get administrator privileges in Pootle and to standardize the procedure for non-committers to ask for a Pootle account. thanks for volunteering, please remember pootle is a infra service (as we wanted) and not a specific AOO service. I personnally welcome you as admin, and will ask in infra if anybody objects. If we are already covered, or we have someone else wishing to take care of this, just say so, and I'll be happier! But we must avoid delays and standardize procedures, at least for the languages that are already in Pootle. I dont know what the state of the pootle files are, that is something jsc have done. I would recommend not to just add new languages, pootle is the least problem here. rgds jan I. 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: [VOTE]: Release OpenOffice 4.0 (RC2)
+1Release this package as Apache OpenOffice 4.0 On 7/17/2013 12:40 AM, Jürgen Schmidt wrote: [ ] +1 Release this package as Apache OpenOffice 4.0 [ ] 0 Don't care [ ] -1 Do not release this package because... - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Volunteering to create Pootle accounts
On 19 July 2013 01:11, janI j...@apache.org wrote: On 19 July 2013 00:46, Andrea Pescetti pesce...@apache.org wrote: I expect an increased traffic of Pootle account requests (from non-committers) next week, when we will release version 4.0 and new volunteers will want to translate OpenOffice 4.0 into their mother tongue. Unless we are already covered for a timely creation of accounts, I volunteer to get administrator privileges in Pootle and to standardize the procedure for non-committers to ask for a Pootle account. thanks for volunteering, please remember pootle is a infra service (as we wanted) and not a specific AOO service. I personnally welcome you as admin, and will ask in infra if anybody objects. You will get admin priviledges for the AOO projects, I just have to make a profile in pootle, should be in place during the weekend. rgds jan I. If we are already covered, or we have someone else wishing to take care of this, just say so, and I'll be happier! But we must avoid delays and standardize procedures, at least for the languages that are already in Pootle. I dont know what the state of the pootle files are, that is something jsc have done. I would recommend not to just add new languages, pootle is the least problem here. rgds jan I. 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: Cwiki vs Media WIki again...
On Thu, Jul 18, 2013 at 2:44 PM, janI j...@apache.org wrote: On 18 July 2013 23:32, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 07/18/2013 11:21 PM, schrieb Kay Schenk: In continuing discussions, some of you may be interested in this site: http://www.wikimatrix.org/ No sure about accuracy. Great link, thanks! Now both can be compared with facts - assumed they are correct. ;-) great site, thx a lot. I ran a compare and the difference I look after showed up. sadly enough it does not compare to WP. rgds jan I. I'm recalling now the biggest drawback to Confluence, for an end user portal, seemed to be -- and likely still is -- the lack of language support. I looked for about an hour before I sent this little e-mail, and could not find anything to the contrary. Marcus --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
Re: [VOTE]: Release OpenOffice 4.0 (RC2)
+1 (!) On Thu, Jul 18, 2013 at 7:20 PM, Andrew Rist andrew.r...@oracle.com wrote: +1Release this package as Apache OpenOffice 4.0 On 7/17/2013 12:40 AM, Jürgen Schmidt wrote: [ ] +1 Release this package as Apache OpenOffice 4.0 [ ] 0 Don't care [ ] -1 Do not release this package because... --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Fwd: Issue with dmake of AOO-3.4.1 for the module stlport
HI Regina, Yes It's correct I am trying to build Version 3.4.1 which is the latest stable version. Thanks and Regards, Ankur Singhal -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: 18 July 2013 22:07 To: dev@openoffice.apache.org; Singhal, Ankur Subject: Re: Fwd: Issue with dmake of AOO-3.4.1 for the module stlport Hi Ankur, is it correct, that you want to build the version 3.4.1? Kind regards Regina Rob Weir schrieb: Forwarding to our development mailing list where you are more likely to get an answer. -Rob -- Forwarded message -- From: Singhal, Ankur asing...@ptc.com Date: Thu, Jul 18, 2013 at 9:24 AM Subject: Issue with dmake of AOO-3.4.1 for the module stlport To: us...@openoffice.apache.org us...@openoffice.apache.org Hi Team, I need all your help in resolving my issues, while setting up my machine(Windows 7) for development on OpenOffice. Steps I have followed to build (http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step _by_step#Windows_7) 1) I have downloaded source code directly from http://www.openoffice.org/download/other.html#tested-sdk . 2) Did my configure using the below paths: --with-cl-home=/cygdrive/f/Microsoft Visual Studio 9.0/VC \ --with-mspdb-path=/cygdrive/f/Microsoft Visual Studio 9.0/Common7/IDE \ --with-frame-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0 \ --with-psdk-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0 \ --with-midl-path=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0/Bin \ --with-asm-home=/cygdrive/f/Microsoft Visual Studio 9.0/VC/bin \ --with-csc-path=/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5 \ --with-jdk-home=/cygdrive/c/Java64/jdk1.6.0_35\ --with-ant-home=/cygdrive/c/apache-ant-1.9.2 \ --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dma ke-4.12.tar.bz2 \ --with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz \ --disable-directx \ --enable-dbgutil \ --enable-pch \ --disable-atl \ --disable-activex \ --disable-binfilter \ --without-junit 3) Bootstrap ran properly. 4) dmake is failing to build stlport module with the error File to Patch: Options that I have tried: 1) Resolving the conflicts by going to separate files like VC7.mak, _monetary.c, _num_put.c, _time_facets.c, _list.h. After resolving conflicts it gives error as below: .\streambuf.cpp(43) : error C2511: 'stlp_std::basic_streambuf_CharT,_Traits::basic_streambuf(FILE *,FILE *)' : overloaded member function not found in 'stlp_std::basic_streambuf_CharT,_Traits' 2) I tried moving from Visual Studio 2008 to Visual Studio 2010. It starts giving other error about a file named exception under Visual Studio. I believe Visual Studio 2010 is not supported by OpenOffice. 3) I tried replacing module stlport-4.5 with stlport-5.2.1 and compiling the module. (With Visual Studio 2008) But I am still facing the same issue. .\streambuf.cpp(43) : error C2511: 'stlp_std::basic_streambuf_CharT,_Traits::basic_streambuf(FILE *,FILE *)' : overloaded member function not found in 'stlp_std::basic_streambuf_CharT,_Traits' It would be very helpful if someone can help me in resolving this issue or if someone have faced the same issue earlier. I believe this is not an issue related to code but a configuration issue. Thanks in Advance, Ankur Singhal - 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
