Re: "Roadmap"
Hi Jim, Am 24.10.23 um 14:44 schrieb Jim Jagielski: Yep. macOS and Linux 32 and 64 bit builds (as source) are uploaded to dist/dev Windows builds are also uploaded now. Regards, Matthias On Oct 24, 2023, at 5:52 AM, Matthias Seidel wrote: Hi Jim, Am 23.10.23 um 14:34 schrieb Jim Jagielski: I'll start some dev builds for 0a12a2c1 So this is already RC1? Regards, Matthias - 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 smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
Yep. macOS and Linux 32 and 64 bit builds (as source) are uploaded to dist/dev > On Oct 24, 2023, at 5:52 AM, Matthias Seidel > wrote: > > Hi Jim, > > Am 23.10.23 um 14:34 schrieb Jim Jagielski: >> I'll start some dev builds for 0a12a2c1 > > So this is already RC1? > > Regards, > >Matthias > >> >> - >> 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: "Roadmap"
Hi Jim, Am 23.10.23 um 14:34 schrieb Jim Jagielski: I'll start some dev builds for 0a12a2c1 So this is already RC1? Regards, Matthias - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
I have now started Test builds for Windows (0a12a2c1). Am 23.10.23 um 14:34 schrieb Jim Jagielski: I'll start some dev builds for 0a12a2c1 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
I'll start some dev builds for 0a12a2c1 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: "Roadmap"
Am 20.10.23 um 14:59 schrieb Jim Jagielski: I'm back from the All Things Open event, so I signed up for some tasks as well. Great! Welcome back, Jim. There are still enough tasks open for volunteers... ;-) Regards, Matthias On Oct 18, 2023, at 5:52 PM, Marcus wrote: Am 17.10.23 um 16:52 schrieb Matthias Seidel: Am 05.10.23 um 16:50 schrieb Keith N. McKenna: Matthias Seidel wrote: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Maybe we could release AOO420-dev5 to the public in early 2024? After the release of AOO 4.1.15 we should have the AOO41X branch ready for an "urgent" release, but otherwise concentrate on AOO42X. I expect a long testing phase for AOO 4.2.0 because of the new translations, new code (in parts 10 years old, but never released to the public) and expected problems with user profiles when updating. What do you think? Regarding a 4.1.15 release: I am ready when you are! That said, I will not be available between Christmas and New Year. ;-) The Release Schedule is already open for volunteers: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15 I've put my name to many tasks. However, there are still many tasks for more volunteers. Marcus - 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 smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
I'm back from the All Things Open event, so I signed up for some tasks as well. > On Oct 18, 2023, at 5:52 PM, Marcus wrote: > > Am 17.10.23 um 16:52 schrieb Matthias Seidel: >> Am 05.10.23 um 16:50 schrieb Keith N. McKenna: >>> Matthias Seidel wrote: >>>> >>>> I would like to collect ideas for some kind of roadmap for AOO: >>>> >>>> - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good >>>> condition, but personally I would like to have the "ugly UI" fixed on some >>>> Linux distribution. >>>> >>>> - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already >>>> fixed two with one commit) with a release date 2024 in mind. >>>> Maybe we could release AOO420-dev5 to the public in early 2024? >>>> >>>> After the release of AOO 4.1.15 we should have the AOO41X branch ready >>>> for an "urgent" release, but otherwise concentrate on AOO42X. >>>> >>>> I expect a long testing phase for AOO 4.2.0 because of the new >>>> translations, new code (in parts 10 years old, but never released to the >>>> public) and expected problems with user profiles when updating. >>>> >>>> What do you think? >> Regarding a 4.1.15 release: I am ready when you are! >> That said, I will not be available between Christmas and New Year. ;-) >> The Release Schedule is already open for volunteers: >> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15 > > I've put my name to many tasks. > However, there are still many tasks for more volunteers. > > Marcus > > > - > 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: "Roadmap"
Am 17.10.23 um 16:52 schrieb Matthias Seidel: Am 05.10.23 um 16:50 schrieb Keith N. McKenna: Matthias Seidel wrote: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Maybe we could release AOO420-dev5 to the public in early 2024? After the release of AOO 4.1.15 we should have the AOO41X branch ready for an "urgent" release, but otherwise concentrate on AOO42X. I expect a long testing phase for AOO 4.2.0 because of the new translations, new code (in parts 10 years old, but never released to the public) and expected problems with user profiles when updating. What do you think? Regarding a 4.1.15 release: I am ready when you are! That said, I will not be available between Christmas and New Year. ;-) The Release Schedule is already open for volunteers: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15 I've put my name to many tasks. However, there are still many tasks for more volunteers. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: "Roadmap"
Hi All, Am 05.10.23 um 16:50 schrieb Keith N. McKenna: Matthias Seidel wrote: Hi All, I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Maybe we could release AOO420-dev5 to the public in early 2024? After the release of AOO 4.1.15 we should have the AOO41X branch ready for an "urgent" release, but otherwise concentrate on AOO42X. I expect a long testing phase for AOO 4.2.0 because of the new translations, new code (in parts 10 years old, but never released to the public) and expected problems with user profiles when updating. What do you think? Regarding a 4.1.15 release: I am ready when you are! That said, I will not be available between Christmas and New Year. ;-) The Release Schedule is already open for volunteers: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15 Regards, Matthias Regards, Matthias a BIG +1 Matthias. Regards Keith - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: Kryptografische S/MIME-Signatur
Re: Ugly UI [Was: "Roadmap"]
Hello, On Fri, Oct 06, 2023 at 11:14:41PM +0200, Marcus wrote: [...] > @All: > Please have a look if that psart of text is OK or what should be written in > another way. Fixed on the wiki: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15+Release+Notes Best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ugly UI [Was: "Roadmap"]
Am 06.10.23 um 22:07 schrieb Arrigo Marchiori: On Fri, Oct 06, 2023 at 07:18:37PM +0200, Marcus wrote: Am 06.10.23 um 18:39 schrieb Rory O'Farrell: On Fri, 6 Oct 2023 18:31:01 +0200 Marcus wrote: Am 06.10.23 um 18:02 schrieb Pedro Lino: Hi Matthias On 10/06/2023 3:44 PM WEST Matthias Seidel wrote: Does it mean we need to include this library in the installer? Either bundle it (when possible) or include instructions in the Release Notes. If it's not possible to bundle it (due to the *Open* Source license!) would it be possible to create a library dependency (or something similar) so that it is automatically installed after? I hope so, as this is a good way to get it installed when necessary. Adding manual instructions is a further complication. OpenOffice has mostly been abandoned by Linux users, adding further separate requirements is adding another reason not to install it... Nevertheless is a hint is helpful. ;-) Therefore I've create new release notes for 4.1.15 and add a text at the end "For Linux Users": https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15+Release+Notes +1 for mentioning it in the release notes. Help needed: I know how to check and install the library via RPM. But how to do it with the DEB package system? Typically in a deb system the install command for package.deb is sudo dpkg -i package.deb I'd rather suggest: sudo apt install libgdk-pixbuf-xlib-2.0-0 On Debian-based systems, apt fetches the package from the distribution's archives, together with any missing dependencies, and then install it. It's more like the dnf comand. dpkg only works on packages you already downloaded. It's like the rpm command. OK, as I've used dnf for RPMs I've now also used apt for DEBs. @All: Please have a look if that psart of text is OK or what should be written in another way. Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ugly UI [Was: "Roadmap"]
Hello All, On Fri, Oct 06, 2023 at 07:18:37PM +0200, Marcus wrote: > Am 06.10.23 um 18:39 schrieb Rory O'Farrell: > > On Fri, 6 Oct 2023 18:31:01 +0200 > > Marcus wrote: > > > > > Am 06.10.23 um 18:02 schrieb Pedro Lino: > > > > Hi Matthias > > > > > > > > > On 10/06/2023 3:44 PM WEST Matthias Seidel > > > > > wrote: > > > > > > > > > > Does it mean we need to include this library in the installer? > > > > > > > > > > Either bundle it (when possible) or include instructions in the > > > > > Release > > > > > Notes. > > > > > > > > If it's not possible to bundle it (due to the *Open* Source license!) > > > > would it be possible to create a library dependency (or something > > > > similar) so that it is automatically installed after? > > > > > > I hope so, as this is a good way to get it installed when necessary. > > > > > > > Adding manual instructions is a further complication. OpenOffice has > > > > mostly been abandoned by Linux users, adding further separate > > > > requirements is adding another reason not to install it... > > > > > > Nevertheless is a hint is helpful. ;-) > > > Therefore I've create new release notes for 4.1.15 and add a text at the > > > end "For Linux Users": > > > > > > https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15+Release+Notes +1 for mentioning it in the release notes. > > > Help needed: > > > I know how to check and install the library via RPM. But how to do it > > > with the DEB package system? > > > > Typically in a deb system the install command for package.deb is > > > > sudo dpkg -i package.deb I'd rather suggest: sudo apt install libgdk-pixbuf-xlib-2.0-0 On Debian-based systems, apt fetches the package from the distribution's archives, together with any missing dependencies, and then install it. It's more like the dnf comand. dpkg only works on packages you already downloaded. It's like the rpm command. Best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ugly UI [Was: "Roadmap"]
Am 06.10.23 um 18:39 schrieb Rory O'Farrell: On Fri, 6 Oct 2023 18:31:01 +0200 Marcus wrote: Am 06.10.23 um 18:02 schrieb Pedro Lino: Hi Matthias On 10/06/2023 3:44 PM WEST Matthias Seidel wrote: Funny, I *thought* I already did that... But yes, that solves the problem. Thank you! Maybe I missed your previous solution. Sorry! Does it mean we need to include this library in the installer? Either bundle it (when possible) or include instructions in the Release Notes. If it's not possible to bundle it (due to the *Open* Source license!) would it be possible to create a library dependency (or something similar) so that it is automatically installed after? I hope so, as this is a good way to get it installed when necessary. Adding manual instructions is a further complication. OpenOffice has mostly been abandoned by Linux users, adding further separate requirements is adding another reason not to install it... Nevertheless is a hint is helpful. ;-) Therefore I've create new release notes for 4.1.15 and add a text at the end "For Linux Users": https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15+Release+Notes Help needed: I know how to check and install the library via RPM. But how to do it with the DEB package system? Typically in a deb system the install command for package.deb is sudo dpkg -i package.deb thanks, than I use dkpg -l to check for the package. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ugly UI [Was: "Roadmap"]
On Fri, 6 Oct 2023 18:31:01 +0200 Marcus wrote: > Am 06.10.23 um 18:02 schrieb Pedro Lino: > > Hi Matthias > > > >> On 10/06/2023 3:44 PM WEST Matthias Seidel > >> wrote: > > > >> Funny, I *thought* I already did that... > >> But yes, that solves the problem. Thank you! > > > > Maybe I missed your previous solution. Sorry! > > > >>> Does it mean we need to include this library in the installer? > >> > >> Either bundle it (when possible) or include instructions in the Release > >> Notes. > > > > If it's not possible to bundle it (due to the *Open* Source license!) would > > it be possible to create a library dependency (or something similar) so > > that it is automatically installed after? > > I hope so, as this is a good way to get it installed when necessary. > > > Adding manual instructions is a further complication. OpenOffice has mostly > > been abandoned by Linux users, adding further separate requirements is > > adding another reason not to install it... > > Nevertheless is a hint is helpful. ;-) > Therefore I've create new release notes for 4.1.15 and add a text at the > end "For Linux Users": > > https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15+Release+Notes > > Help needed: > I know how to check and install the library via RPM. But how to do it > with the DEB package system? Typically in a deb system the install command for package.deb is sudo dpkg -i package.deb > > Thanks > > Marcus > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ugly UI [Was: "Roadmap"]
Am 06.10.23 um 18:02 schrieb Pedro Lino: Hi Matthias On 10/06/2023 3:44 PM WEST Matthias Seidel wrote: Funny, I *thought* I already did that... But yes, that solves the problem. Thank you! Maybe I missed your previous solution. Sorry! Does it mean we need to include this library in the installer? Either bundle it (when possible) or include instructions in the Release Notes. If it's not possible to bundle it (due to the *Open* Source license!) would it be possible to create a library dependency (or something similar) so that it is automatically installed after? I hope so, as this is a good way to get it installed when necessary. Adding manual instructions is a further complication. OpenOffice has mostly been abandoned by Linux users, adding further separate requirements is adding another reason not to install it... Nevertheless is a hint is helpful. ;-) Therefore I've create new release notes for 4.1.15 and add a text at the end "For Linux Users": https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.15+Release+Notes Help needed: I know how to check and install the library via RPM. But how to do it with the DEB package system? Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ugly UI [Was: "Roadmap"]
Hi Pedro, Am 06.10.23 um 18:02 schrieb Pedro Lino: Hi Matthias On 10/06/2023 3:44 PM WEST Matthias Seidel wrote: Funny, I *thought* I already did that... But yes, that solves the problem. Thank you! Maybe I missed your previous solution. Sorry! No, you didn't miss anything! I was simply under the impression that I already installed that lib. ;-) Regards, Matthias Does it mean we need to include this library in the installer? Either bundle it (when possible) or include instructions in the Release Notes. If it's not possible to bundle it (due to the *Open* Source license!) would it be possible to create a library dependency (or something similar) so that it is automatically installed after? Adding manual instructions is a further complication. OpenOffice has mostly been abandoned by Linux users, adding further separate requirements is adding another reason not to install it... Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: Kryptografische S/MIME-Signatur
Re: Ugly UI [Was: "Roadmap"]
Hi Matthias > On 10/06/2023 3:44 PM WEST Matthias Seidel wrote: > Funny, I *thought* I already did that... > But yes, that solves the problem. Thank you! Maybe I missed your previous solution. Sorry! > > Does it mean we need to include this library in the installer? > > Either bundle it (when possible) or include instructions in the Release > Notes. If it's not possible to bundle it (due to the *Open* Source license!) would it be possible to create a library dependency (or something similar) so that it is automatically installed after? Adding manual instructions is a further complication. OpenOffice has mostly been abandoned by Linux users, adding further separate requirements is adding another reason not to install it... Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ugly UI [Was: "Roadmap"]
On Fri, Oct 6, 2023 at 10:57 AM Pedro Lino wrote: > Hi Arrigo, all > > This does solve the UI problem. > > Does it mean we need to include this library in the installer? > > The licence is LGPL-2+, so we can't ship it, right? Regards Damjan
Re: Ugly UI [Was: "Roadmap"]
Am 06.10.23 um 16:44 schrieb Matthias Seidel: Am 06.10.23 um 12:56 schrieb Pedro Lino: This does solve the UI problem. Funny, I *thought* I already did that... But yes, that solves the problem. Thank you! oh f**k, what a difference. :-O Arrigo, thanks for this great hint. Matthias, thanks for the screenshot. Somehow I don't got the difference compared to my older Fedora installlation from last year. Does it mean we need to include this library in the installer? Maybe ... Either bundle it (when possible) or include instructions in the Release Notes. ... at least a new paragraph for this would be very helpful. Marcus On 10/06/2023 9:56 AM WEST Arrigo Marchiori wrote: Hello All, On Thu, Oct 05, 2023 at 11:49:34PM +0200, Matthias Seidel wrote: Am 05.10.23 um 23:25 schrieb Matthias Seidel: Hi Marcus, Am 05.10.23 um 23:17 schrieb Marcus: Am 05.10.23 um 21:25 schrieb Matthias Seidel: Am 05.10.23 um 21:06 schrieb Marcus: Am 05.10.23 um 15:23 schrieb Matthias Seidel: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. I've no discussions about this in mind. Do you have the BZ issue(s) at hand? No, I think it was discussed on a user list but more or less ignored. I only recently moved from Ubuntu 16.04 to 22.04 and discovered the "ugly UI". But everyone using a newer distribution with Gnome should probably see it. I've Fedora 36 with Gnome 43.1. How / where can I see what you mean? Found a screenshot... https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png According to: https://forum.openoffice.org/en/forum/viewtopic.php?t=103671 the solution is: install the libgdk-pixbuf-xlib package. On Ubuntu Jammy, it is named libgdk-pixbuf-xlib-2.0-0 I hope this helps. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ugly UI [Was: "Roadmap"]
Hi Pedro, Arrigo, Am 06.10.23 um 12:56 schrieb Pedro Lino: Hi Arrigo, all This does solve the UI problem. Funny, I *thought* I already did that... But yes, that solves the problem. Thank you! Does it mean we need to include this library in the installer? Either bundle it (when possible) or include instructions in the Release Notes. Regards, Matthias Best, Pedro On 10/06/2023 9:56 AM WEST Arrigo Marchiori wrote: Hello All, On Thu, Oct 05, 2023 at 11:49:34PM +0200, Matthias Seidel wrote: Am 05.10.23 um 23:25 schrieb Matthias Seidel: Hi Marcus, Am 05.10.23 um 23:17 schrieb Marcus: Am 05.10.23 um 21:25 schrieb Matthias Seidel: Am 05.10.23 um 21:06 schrieb Marcus: Am 05.10.23 um 15:23 schrieb Matthias Seidel: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. I've no discussions about this in mind. Do you have the BZ issue(s) at hand? No, I think it was discussed on a user list but more or less ignored. I only recently moved from Ubuntu 16.04 to 22.04 and discovered the "ugly UI". But everyone using a newer distribution with Gnome should probably see it. I've Fedora 36 with Gnome 43.1. How / where can I see what you mean? Found a screenshot... https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png According to: https://forum.openoffice.org/en/forum/viewtopic.php?t=103671 the solution is: install the libgdk-pixbuf-xlib package. On Ubuntu Jammy, it is named libgdk-pixbuf-xlib-2.0-0 I hope this helps. Best regards, -- Arrigo - 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 smime.p7s Description: Kryptografische S/MIME-Signatur
Re: Ugly UI [Was: "Roadmap"]
Hi Arrigo, all This does solve the UI problem. Does it mean we need to include this library in the installer? Best, Pedro > On 10/06/2023 9:56 AM WEST Arrigo Marchiori wrote: > > > Hello All, > > On Thu, Oct 05, 2023 at 11:49:34PM +0200, Matthias Seidel wrote: > > > Am 05.10.23 um 23:25 schrieb Matthias Seidel: > > > Hi Marcus, > > > > > > Am 05.10.23 um 23:17 schrieb Marcus: > > > > Am 05.10.23 um 21:25 schrieb Matthias Seidel: > > > > > Am 05.10.23 um 21:06 schrieb Marcus: > > > > > > Am 05.10.23 um 15:23 schrieb Matthias Seidel: > > > > > > > I would like to collect ideas for some kind of roadmap for AOO: > > > > > > > > > > > > > > - Release AOO 4.1.15 before the end of 2023. Branch > > > > > > > AOO41X is in good condition, but personally I would like > > > > > > > to have the "ugly UI" fixed on some Linux distribution. > > > > > > > > > > > > I've no discussions about this in mind. Do you have the BZ > > > > > > issue(s) at hand? > > > > > > > > > > No, I think it was discussed on a user list but more or less ignored. > > > > > > > > > > I only recently moved from Ubuntu 16.04 to 22.04 and discovered > > > > > the "ugly UI". But everyone using a newer distribution with > > > > > Gnome should probably see it. > > > > > > > > I've Fedora 36 with Gnome 43.1. > > > > How / where can I see what you mean? > > > > Found a screenshot... > > > > https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png > > According to: > https://forum.openoffice.org/en/forum/viewtopic.php?t=103671 > the solution is: install the libgdk-pixbuf-xlib package. > > On Ubuntu Jammy, it is named libgdk-pixbuf-xlib-2.0-0 > > I hope this helps. > > Best regards, > -- > Arrigo > > - > 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: "Roadmap"
Hi Damjan, all I just installed AOO 4.1.14 in my Ubuntu 22.04.3 USB drive in Persistence mode and can see the "ugly" Windows 3.x interface Matthias showed. > On 10/06/2023 5:27 AM CEST Damjan Jovanovic wrote: > Actually as per main/vcl/unx/generic/desktopdetect/desktopdetector.cxx: > Try setting the OOO_FORCE_DESKTOP environment variable to "gnome", eg. > OOO_FORCE_DESKTOP=gnome ./soffice ubuntu@ubuntu:/opt/openoffice4/program$ OOO_FORCE_DESKTOP=gnome ./soffice Segmentation fault (core dumped) Opens AOO but shows the Win3x UI. Ends with core dump Is there a file somewhere that logs the crash? > Also, what does this return: > $ echo $GNOME_DESKTOP_SESSION_ID this-is-deprecated > and does this: > $ xprop -root > return a value for GNOME_SM_PROXY or NAUTILUS_DESKTOP_WINDOW_ID? ubuntu@ubuntu:~$ xprop -root _MUTTER_SENTINEL(CARDINAL) = 0 _GTK_WORKAREAS_D1(CARDINAL) = 70, 27, 1850, 1053 _ICC_PROFILE_IN_X_VERSION(CARDINAL) = 3 _ICC_PROFILE(CARDINAL) = 0, 0, 2, 212, 108, 99, 109, 115, 4, 48, 0, 0, 109, 110, 116, 114, 82, 71, 66, 32, 88, 89, 90, 32, 7, 231, 0, 10, 0, 6, 0, 7, 0, 48, 0, 31, 97, 99, 115, 112, 65, 80, 80, 76, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 246, 214, 0, 1, 0, 0, 0, 0, 211, 45, 108, 99, 109, 115, 16, 92, 70, 20, 151, 132, 170, 116, 184, 20, 238, 130, 13, 242, 93, 61, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 12, 100, 101, 115, 99, 0, 0, 1, 20, 0, 0, 0, 54, 99, 112, 114, 116, 0, 0, 1, 76, 0, 0, 0, 76, 119, 116, 112, 116, 0, 0, 1, 152, 0, 0, 0, 20, 99, 104, 97, 100, 0, 0, 1, 172, 0, 0, 0, 44, 114, 88, 89, 90, 0, 0, 1, 216, 0, 0, 0, 20, 98, 88, 89, 90, 0, 0, 1, 236, 0, 0, 0, 20, 103, 88, 89, 90, 0, 0, 2, 0, 0, 0, 0, 20, 114, 84, 82, 67, 0, 0, 2, 20, 0, 0, 0, 32, 103, 84, 82, 67, 0, 0, 2, 20, 0, 0, 0, 32, 98, 84, 82, 67, 0, 0, 2, 20, 0, 0, 0, 32, 99, 104, 114, 109, 0, 0, 2, 52, 0, 0, 0, 36, 109, 101, 116 , 97, 0, 0, 2, 88, 0, 0, 0, 122, 109, 108, 117, 99, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 12, 101, 110, 85, 83, 0, 0, 0, 26, 0, 0, 0, 28, 0, 115, 0, 82, 0, 71, 0, 66, 0, 32, 0, 98, 0, 117, 0, 105, 0, 108, 0, 116, 0, 45, 0, 105, 0, 110, 0, 0, 109, 108, 117, 99, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 12, 101, 110, 85, 83, 0, 0, 0, 48, 0, 0, 0, 28, 0, 78, 0, 111, 0, 32, 0, 99, 0, 111, 0, 112, 0, 121, 0, 114, 0, 105, 0, 103, 0, 104, 0, 116, 0, 44, 0, 32, 0, 117, 0, 115, 0, 101, 0, 32, 0, 102, 0, 114, 0, 101, 0, 101, 0, 108, 0, 121, 88, 89, 90, 32, 0, 0, 0, 0, 0, 0, 246, 214, 0, 1, 0, 0, 0, 0, 211, 45, 115, 102, 51, 50, 0, 0, 0, 0, 0, 1, 12, 66, 0, 0, 5, 222, 255, 255, 243, 37, 0, 0, 7, 147, 0, 0, 253, 144, 255, 255, 251, 161, 255, 255, 253, 162, 0, 0, 3, 220, 0, 0, 192, 110, 88, 89, 90, 32, 0, 0, 0, 0, 0, 0, 111, 160, 0, 0, 56, 245, 0, 0, 3, 144, 88, 89, 90, 32, 0, 0, 0, 0, 0, 0, 36, 159, 0, 0, 15, 132, 0, 0, 182, 195, 88, 89, 90, 32, 0, 0, 0, 0, 0, 0, 98, 151, 0, 0, 183, 135, 0, 0, 24, 217, 112, 97, 114, 97, 0, 0, 0, 0, 0, 3, 0, 0, 0, 2, 102, 102, 0, 0, 242, 167, 0, 0, 13, 89, 0, 0, 19, 208, 0, 0, 10, 91, 99, 104, 114, 109, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 163, 215, 0, 0, 84, 123, 0, 0, 76, 205, 0, 0, 153, 154, 0, 0, 38, 102, 0, 0, 15, 92, 100, 105, 99, 116, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 16, 0, 0, 0, 48, 0, 0, 0, 22, 0, 0, 0, 70, 0, 0, 0, 16, 0, 0, 0, 86, 0, 0, 0, 28, 0, 0, 0, 114, 0, 0, 0, 8, 0, 68, 0, 65, 0, 84, 0, 65, 0, 95, 0, 115, 0, 111, 0, 117, 0, 114, 0, 99, 0, 101, 0, 115, 0, 116, 0, 97, 0, 110, 0, 100, 0, 97, 0, 114, 0, 100, 0, 83, 0, 84, 0, 65, 0, 78, 0, 68, 0, 65, 0, 82, 0, 68, 0, 95, 0, 115, 0, 112, 0, 97, 0, 99, 0, 101, 0, 115, 0, 114, 0, 103, 0, 98, 0, 0 RESOURCE_MANAGER(STRING) = "Xft.dpi:\t96\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t64\nXcursor.theme:\tYaru\n" XIM_SERVERS(ATOM) = @server=ibus _NET_ACTIVE_WINDOW(WINDOW): window id # 0x28a _NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x243, 0x34000f8, 0x80003e, 0x28a _NET_CLIENT_LIST(WINDOW): window id # 0x243, 0x80003e, 0x34000f8, 0x28a _NET_CURRENT_DESKTOP(CARDINAL) = 0 _NET_WORKAREA(CARDINAL) = 70, 27, 1850, 1053, 70, 27, 1850, 1053 _GTK_WORKAREAS_D0(CARDINAL) = 70, 27, 1850, 1053 _NET_DESKTOP_NAMES(UTF8_STRING) = "Workspace 1" _NET_SHOWING_DESKTOP(CARDINAL) = 0 _NET_NUMBER_OF_DESKTOPS(CARDINAL) = 2 _NET_DESKTOP_GEOMETRY(CARDINAL) = 1920, 1080 _NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0 _NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x46 _NET_SUPPORTED(ATOM) = _NET_WM_NAME, _NET_CLOSE_WINDOW, _NET_WM_STATE, _NET_WM_STATE_SHADED, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_DESKTOP, _NET_NUMBER_OF_DESKTOPS, _NET_CURRENT_DESKTOP, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_DESKTOP, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU,
Ugly UI [Was: "Roadmap"]
Hello All, On Thu, Oct 05, 2023 at 11:49:34PM +0200, Matthias Seidel wrote: > Am 05.10.23 um 23:25 schrieb Matthias Seidel: > > Hi Marcus, > > > > Am 05.10.23 um 23:17 schrieb Marcus: > > > Am 05.10.23 um 21:25 schrieb Matthias Seidel: > > > > Am 05.10.23 um 21:06 schrieb Marcus: > > > > > Am 05.10.23 um 15:23 schrieb Matthias Seidel: > > > > > > I would like to collect ideas for some kind of roadmap for AOO: > > > > > > > > > > > > - Release AOO 4.1.15 before the end of 2023. Branch > > > > > > AOO41X is in good condition, but personally I would like > > > > > > to have the "ugly UI" fixed on some Linux distribution. > > > > > > > > > > I've no discussions about this in mind. Do you have the BZ > > > > > issue(s) at hand? > > > > > > > > No, I think it was discussed on a user list but more or less ignored. > > > > > > > > I only recently moved from Ubuntu 16.04 to 22.04 and discovered > > > > the "ugly UI". But everyone using a newer distribution with > > > > Gnome should probably see it. > > > > > > I've Fedora 36 with Gnome 43.1. > > > How / where can I see what you mean? > > Found a screenshot... > > https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png According to: https://forum.openoffice.org/en/forum/viewtopic.php?t=103671 the solution is: install the libgdk-pixbuf-xlib package. On Ubuntu Jammy, it is named libgdk-pixbuf-xlib-2.0-0 I hope this helps. Best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: "Roadmap"
On Thu, Oct 5, 2023 at 9:49 PM Matthias Seidel wrote: > Am 05.10.23 um 23:25 schrieb Matthias Seidel: > > Hi Marcus, > > > > Am 05.10.23 um 23:17 schrieb Marcus: > >> Am 05.10.23 um 21:25 schrieb Matthias Seidel: > >>> Am 05.10.23 um 21:06 schrieb Marcus: > >>>> Am 05.10.23 um 15:23 schrieb Matthias Seidel: > >>>>> I would like to collect ideas for some kind of roadmap for AOO: > >>>>> > >>>>> - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in > >>>>> good condition, but personally I would like to have the "ugly UI" > >>>>> fixed on some Linux distribution. > >>>> > >>>> I've no discussions about this in mind. Do you have the BZ issue(s) > >>>> at hand? > >>> > >>> No, I think it was discussed on a user list but more or less ignored. > >>> > >>> I only recently moved from Ubuntu 16.04 to 22.04 and discovered the > >>> "ugly UI". But everyone using a newer distribution with Gnome should > >>> probably see it. > >> > >> I've Fedora 36 with Gnome 43.1. > >> How / where can I see what you mean? > > Found a screenshot... > > https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png > > Matthias > > Actually as per main/vcl/unx/generic/desktopdetect/desktopdetector.cxx: Try setting the OOO_FORCE_DESKTOP environment variable to "gnome", eg. OOO_FORCE_DESKTOP=gnome ./soffice Also, what does this return: $ echo $GNOME_DESKTOP_SESSION_ID and does this: $ xprop -root return a value for GNOME_SM_PROXY or NAUTILUS_DESKTOP_WINDOW_ID?
Re: "Roadmap"
On Thu, Oct 5, 2023 at 9:49 PM Matthias Seidel wrote: > Am 05.10.23 um 23:25 schrieb Matthias Seidel: > > Hi Marcus, > > > > Am 05.10.23 um 23:17 schrieb Marcus: > >> Am 05.10.23 um 21:25 schrieb Matthias Seidel: > >>> Am 05.10.23 um 21:06 schrieb Marcus: > >>>> Am 05.10.23 um 15:23 schrieb Matthias Seidel: > >>>>> I would like to collect ideas for some kind of roadmap for AOO: > >>>>> > >>>>> - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in > >>>>> good condition, but personally I would like to have the "ugly UI" > >>>>> fixed on some Linux distribution. > >>>> > >>>> I've no discussions about this in mind. Do you have the BZ issue(s) > >>>> at hand? > >>> > >>> No, I think it was discussed on a user list but more or less ignored. > >>> > >>> I only recently moved from Ubuntu 16.04 to 22.04 and discovered the > >>> "ugly UI". But everyone using a newer distribution with Gnome should > >>> probably see it. > >> > >> I've Fedora 36 with Gnome 43.1. > >> How / where can I see what you mean? > > Found a screenshot... > > https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png > > Ubuntu 22.04 and Fedora 36 both use Wayland, which may be breaking our GTK+ v2 backend somehow and falling back to the "generic" UI. A debug build should log relevant info to stdout, if you start it from the command line.
Re: "Roadmap"
Am 05.10.23 um 23:25 schrieb Matthias Seidel: Hi Marcus, Am 05.10.23 um 23:17 schrieb Marcus: Am 05.10.23 um 21:25 schrieb Matthias Seidel: Am 05.10.23 um 21:06 schrieb Marcus: Am 05.10.23 um 15:23 schrieb Matthias Seidel: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. I've no discussions about this in mind. Do you have the BZ issue(s) at hand? No, I think it was discussed on a user list but more or less ignored. I only recently moved from Ubuntu 16.04 to 22.04 and discovered the "ugly UI". But everyone using a newer distribution with Gnome should probably see it. I've Fedora 36 with Gnome 43.1. How / where can I see what you mean? Found a screenshot... https://home.apache.org/~mseidel/bildschirmfoto_vom_2023-08-05_13-16-38.png Matthias If you ask, you don't have it. ;-) Just imagine how AOO on Windows 98 would look like... Regards, Matthias P.S.: For German readers https://www.mail-archive.com/users-de@openoffice.apache.org/msg09186.html Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
Hi Marcus, Am 05.10.23 um 23:17 schrieb Marcus: Am 05.10.23 um 21:25 schrieb Matthias Seidel: Am 05.10.23 um 21:06 schrieb Marcus: Am 05.10.23 um 15:23 schrieb Matthias Seidel: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. I've no discussions about this in mind. Do you have the BZ issue(s) at hand? No, I think it was discussed on a user list but more or less ignored. I only recently moved from Ubuntu 16.04 to 22.04 and discovered the "ugly UI". But everyone using a newer distribution with Gnome should probably see it. I've Fedora 36 with Gnome 43.1. How / where can I see what you mean? If you ask, you don't have it. ;-) Just imagine how AOO on Windows 98 would look like... Regards, Matthias P.S.: For German readers https://www.mail-archive.com/users-de@openoffice.apache.org/msg09186.html Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
Am 05.10.23 um 21:25 schrieb Matthias Seidel: Am 05.10.23 um 21:06 schrieb Marcus: Am 05.10.23 um 15:23 schrieb Matthias Seidel: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. I've no discussions about this in mind. Do you have the BZ issue(s) at hand? No, I think it was discussed on a user list but more or less ignored. I only recently moved from Ubuntu 16.04 to 22.04 and discovered the "ugly UI". But everyone using a newer distribution with Gnome should probably see it. I've Fedora 36 with Gnome 43.1. How / where can I see what you mean? Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: "Roadmap"
Hi Marcus, Am 05.10.23 um 21:06 schrieb Marcus: Am 05.10.23 um 15:23 schrieb Matthias Seidel: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. I've no discussions about this in mind. Do you have the BZ issue(s) at hand? No, I think it was discussed on a user list but more or less ignored. I only recently moved from Ubuntu 16.04 to 22.04 and discovered the "ugly UI". But everyone using a newer distribution with Gnome should probably see it. Regards, Matthias - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Even when it's - very likely? - just by accident ;-) , it's nevertheless a great start. I hope that we can go on with fixing all. Maybe we could release AOO420-dev5 to the public in early 2024? +1 After the release of AOO 4.1.15 we should have the AOO41X branch ready for an "urgent" release, but otherwise concentrate on AOO42X. Yes I expect a long testing phase for AOO 4.2.0 because of the new translations, new code (in parts 10 years old, but never released to the public) and expected problems with user profiles when updating. We have done many, many changes between 41X and 42X. If it's just issues with the profile, we could be very happy. What do you think? I also recommend to do a long testing phase. Therefore we should think about to combine this with a Beta test - or more than 1. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
Am 05.10.23 um 15:23 schrieb Matthias Seidel: I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. I've no discussions about this in mind. Do you have the BZ issue(s) at hand? - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Even when it's - very likely? - just by accident ;-) , it's nevertheless a great start. I hope that we can go on with fixing all. Maybe we could release AOO420-dev5 to the public in early 2024? +1 After the release of AOO 4.1.15 we should have the AOO41X branch ready for an "urgent" release, but otherwise concentrate on AOO42X. Yes I expect a long testing phase for AOO 4.2.0 because of the new translations, new code (in parts 10 years old, but never released to the public) and expected problems with user profiles when updating. We have done many, many changes between 41X and 42X. If it's just issues with the profile, we could be very happy. What do you think? I also recommend to do a long testing phase. Therefore we should think about to combine this with a Beta test - or more than 1. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: "Roadmap"
Sent from my iPhone > On Oct 5, 2023, at 8:12 AM, Matthias Seidel > wrote: > > Hi Pedro, > >> Am 05.10.23 um 16:32 schrieb Pedro Lino: >> Hi Matthias, all >> On 10/05/2023 2:23 PM WEST Matthias Seidel wrote: >>> - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good >>> condition, but personally I would like to have the "ugly UI" fixed on >>> some Linux distribution. >> Agree. What ugly UI issues does 4.1.15 fix? > > Until now it isn't fixed... ;-) > > On my Ubuntu 22.04 AOO 4.1.14 falls back to a Windows 98-like UI. > > Funny fact: The 4.1.15 builds from our buildbot (Ubuntu 18.04) look OK. > >> >>> - Start on removing the blocker_s_ for AOO 4.2.0 (in fact Damjan already >>> fixed two with one commit) with a release date 2024 in mind. >>> Maybe we could release AOO420-dev5 to the public in early 2024? >>> >> Agree. Yes for dev5. >> >>> I expect a long testing phase for AOO 4.2.0 because of the new >>> translations, new code (in parts 10 years old, but never released to the >>> public) and expected problems with user profiles when updating. >> Updating translations will be an issue. I volunteered to learn the process >> from Mechtilde but I got stuck in some bureaucratic permissions (not from >> Mechtilde)... > > The translations itself are not the main problem, we need to be able to > synchronize Pootle and our code in a structured way. The Pootle server needs > an update before we can proceed. What are the required updates? Is there a tracker or wiki page? I might be able to help in a couple of weeks. As far as sysadmin work Pootle is #1 #2 is MediaWiki version update. #3 is Forum version update - there it’s only a single minor version and it’s more about knowledge transfer and configuration documentation. Best, Dave > >> >> Why do you expect profile updating problems? > Maybe because I am always a bit pessimistic? ;-) > > But we had reports of profile corruption with every release (esp. on > Windows). A lot of code has changed so we need to test it and if we find > problems provide a "workaround". 4.2.0 should be a smooth upgrade. > > Personally, I had to reset my 4.2.0 profile recently. But that was probably > from an extension corruption that happened before Damjan's fix (my extension > manager looked totally empty). > > Regards, > >Matthias > >> >> Best, >> Pedro >> >> - >> 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: "Roadmap"
Hi, Am 05.10.23 um 18:25 schrieb Damjan Jovanovic: On Thu, Oct 5, 2023 at 1:24 PM Matthias Seidel wrote: Hi All, I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Maybe we could release AOO420-dev5 to the public in early 2024? Unfortunately I found a new regression we'll have to fix for 4.2.0: https://bz.apache.org/ooo/show_bug.cgi?id=128579 Additionally, I would really like to have https://bz.apache.org/ooo/show_bug.cgi?id=127661 fixed for AOO 4.2.0. We may add that to our list: https://cwiki.apache.org/confluence/display/OOOUSERS/Blocker+issues+4.2.0 Regards, Matthias Regards Damjan smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
On Thu, Oct 5, 2023 at 1:24 PM Matthias Seidel wrote: > Hi All, > > I would like to collect ideas for some kind of roadmap for AOO: > > - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good > condition, but personally I would like to have the "ugly UI" fixed on > some Linux distribution. > > - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already > fixed two with one commit) with a release date 2024 in mind. > Maybe we could release AOO420-dev5 to the public in early 2024? > > Unfortunately I found a new regression we'll have to fix for 4.2.0: https://bz.apache.org/ooo/show_bug.cgi?id=128579 Regards Damjan
Re: "Roadmap"
Hi Pedro, Am 05.10.23 um 16:32 schrieb Pedro Lino: Hi Matthias, all On 10/05/2023 2:23 PM WEST Matthias Seidel wrote: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. Agree. What ugly UI issues does 4.1.15 fix? Until now it isn't fixed... ;-) On my Ubuntu 22.04 AOO 4.1.14 falls back to a Windows 98-like UI. Funny fact: The 4.1.15 builds from our buildbot (Ubuntu 18.04) look OK. - Start on removing the blocker_s_ for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Maybe we could release AOO420-dev5 to the public in early 2024? Agree. Yes for dev5. I expect a long testing phase for AOO 4.2.0 because of the new translations, new code (in parts 10 years old, but never released to the public) and expected problems with user profiles when updating. Updating translations will be an issue. I volunteered to learn the process from Mechtilde but I got stuck in some bureaucratic permissions (not from Mechtilde)... The translations itself are not the main problem, we need to be able to synchronize Pootle and our code in a structured way. The Pootle server needs an update before we can proceed. Why do you expect profile updating problems? Maybe because I am always a bit pessimistic? ;-) But we had reports of profile corruption with every release (esp. on Windows). A lot of code has changed so we need to test it and if we find problems provide a "workaround". 4.2.0 should be a smooth upgrade. Personally, I had to reset my 4.2.0 profile recently. But that was probably from an extension corruption that happened before Damjan's fix (my extension manager looked totally empty). Regards, Matthias Best, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: Kryptografische S/MIME-Signatur
Re: "Roadmap"
Matthias Seidel wrote: Hi All, I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Maybe we could release AOO420-dev5 to the public in early 2024? After the release of AOO 4.1.15 we should have the AOO41X branch ready for an "urgent" release, but otherwise concentrate on AOO42X. I expect a long testing phase for AOO 4.2.0 because of the new translations, new code (in parts 10 years old, but never released to the public) and expected problems with user profiles when updating. What do you think? Regards, Matthias a BIG +1 Matthias. Regards Keith - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: "Roadmap"
Hi Matthias, all > On 10/05/2023 2:23 PM WEST Matthias Seidel wrote: > - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good > condition, but personally I would like to have the "ugly UI" fixed on > some Linux distribution. Agree. What ugly UI issues does 4.1.15 fix? > - Start on removing the blocker_s_ for AOO 4.2.0 (in fact Damjan already > fixed two with one commit) with a release date 2024 in mind. > Maybe we could release AOO420-dev5 to the public in early 2024? > Agree. Yes for dev5. > I expect a long testing phase for AOO 4.2.0 because of the new > translations, new code (in parts 10 years old, but never released to the > public) and expected problems with user profiles when updating. Updating translations will be an issue. I volunteered to learn the process from Mechtilde but I got stuck in some bureaucratic permissions (not from Mechtilde)... Why do you expect profile updating problems? Best, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
"Roadmap"
Hi All, I would like to collect ideas for some kind of roadmap for AOO: - Release AOO 4.1.15 before the end of 2023. Branch AOO41X is in good condition, but personally I would like to have the "ugly UI" fixed on some Linux distribution. - Start on removing the blocker for AOO 4.2.0 (in fact Damjan already fixed two with one commit) with a release date 2024 in mind. Maybe we could release AOO420-dev5 to the public in early 2024? After the release of AOO 4.1.15 we should have the AOO41X branch ready for an "urgent" release, but otherwise concentrate on AOO42X. I expect a long testing phase for AOO 4.2.0 because of the new translations, new code (in parts 10 years old, but never released to the public) and expected problems with user profiles when updating. What do you think? Regards, Matthias smime.p7s Description: Kryptografische S/MIME-Signatur
Re: [discussion] Roadmap for Open Office
On 12/5/2016 12:35 PM, Peter Kovacs wrote: ... # Concerning 12h period. (did not find who brought this up :) ) What I mean is that it would be great if we could devide all activities in good estimate able chunks. Agile methology claims everything that an experienced developer estimates beyond 24h h (3 working days) of effort is inaccurate and there is a high propability that something has been forgotten. ... There are important, even essential, tasks that cannot be handled in neat, tidy, estimatable chunks. I am trying to simultaneously learn AOO internals and analyze a bug. Debug on a very large body of unfamiliar, long-maintained code is a messy process. I have done it intermittently for decades, and still don't know a way to make it clean and tidy. I usually know what to do for the current step, but the next step will depend on its results. It is less a matter of "something has been forgotten" than of "most of the necessary knowledge is not yet known". It would be great if we could divide **some** activities in good estimatable chunks. I just don't think aiming for "all" makes sense. On the other hand, the tasks that can be handled in tidy pieces are exactly the ones relatively inexperienced contributors should be starting on. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
On 12/06/2016 01:39 AM, Peter Kovacs wrote: I have created a page on the Confluence Wiki https://cwiki.apache.org/confluence/display/OOOUSERS/Roadmap I made a start, with Points that came into my mind without haveing to check on something. I thought we have in the upper Region our Release Plan and the a Backlog where we simply collect Toppics which we can then devide and maybe add to our release plan by copy paste. I have kept every point quite short and crisp. Please feel free to add or change Points. As soon as I have access I would like to delete the Roadmap on Media wiki Page and refered Files. (-> https://wiki.openoffice.org/wiki/Features and http://www.openoffice.org/development/releases/ooo_roadmap.pdf ) Maybe it would make sense to add to https://wiki.openoffice.org/wiki/Product_Release the Releases 4.1.4 with some rough estimate (my suggestion would be Q1 2017) and also add 4.2.0 with a note to be decided or something. So it is clear that we have more Releases in the pipe. That would clear the situation up a bit. All the best Peter Hi Peter, Thanks for the initiative. I agree, some people may show up and need a place to find helpful tasks. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
Peter Kovacs wrote: Also there are lots of document that describe old processes in Planing and so forth. We should Archive them too. However I can not move things to an appropriate Folder. So I left the Link to avoid unlinked pages. Can we maybe add a Open Office.org Archieve and move all the depricated pages there? Sure. Why can't you move pages? Do you think it's a matter of permissions? We can look into giving additional permissions. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
Am 12/06/2016 07:39 AM, schrieb Peter Kovacs: I have created a page on the Confluence Wiki https://cwiki.apache.org/confluence/display/OOOUSERS/Roadmap I made a start, with Points that came into my mind without haveing to check on something. I thought we have in the upper Region our Release Plan and the a Backlog where we simply collect Toppics which we can then devide and maybe add to our release plan by copy paste. I have kept every point quite short and crisp. Please feel free to add or change Points. great, thanks for the start. As soon as I have access I would like to delete the Roadmap on Media wiki Page and refered Files. (-> https://wiki.openoffice.org/wiki/Features and http://www.openoffice.org/development/releases/ooo_roadmap.pdf ) Right, they are really outdated and no longer needed. Maybe it would make sense to add to https://wiki.openoffice.org/wiki/Product_Release the Releases 4.1.4 with some rough estimate (my suggestion would be Q1 2017) and also add 4.2.0 with a note to be decided or something. I've added a line for 4.1.4 and 4.2.0. Let's see if this makes a difference. ;-) Marcus On 05.12.2016 22:18, Matthias Seidel wrote: Yes, we could use our cWiki for that... Apart from that, it would be a good idea to give our users a small overview of what is planned for the future. Maybe combined with a Christmas greeting? ;-) regards, Matthias Am 04.12.2016 um 15:11 schrieb Marcus: Am 12/03/2016 01:21 PM, schrieb Peter Kovacs: So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo backlog List type. I love Agile methology. Never came to use it thought, because companies can not deal well if there is no timeframe. But I think for us its perfect. we have already so many tools that some of us still don't know any of them. So, it won't help us when we have just another tool to document some tasks. We should use our Wiki like we do for other tasks. My 2 ct. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
I have now Archieved the Roadmap on the Mediawiki. It is now in a subpage features/Archieve/OOo 3.3 And put a note out that the new Roadmap is to be found on the Confluence Wiki. But I have not delivered any link. Should I add it? Also there are lots of document that describe old processes in Planing and so forth. We should Archive them too. However I can not move things to an appropriate Folder. So I left the Link to avoid unlinked pages. Can we maybe add a Open Office.org Archieve and move all the depricated pages there? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
I have created a page on the Confluence Wiki https://cwiki.apache.org/confluence/display/OOOUSERS/Roadmap I made a start, with Points that came into my mind without haveing to check on something. I thought we have in the upper Region our Release Plan and the a Backlog where we simply collect Toppics which we can then devide and maybe add to our release plan by copy paste. I have kept every point quite short and crisp. Please feel free to add or change Points. As soon as I have access I would like to delete the Roadmap on Media wiki Page and refered Files. (-> https://wiki.openoffice.org/wiki/Features and http://www.openoffice.org/development/releases/ooo_roadmap.pdf ) Maybe it would make sense to add to https://wiki.openoffice.org/wiki/Product_Release the Releases 4.1.4 with some rough estimate (my suggestion would be Q1 2017) and also add 4.2.0 with a note to be decided or something. So it is clear that we have more Releases in the pipe. That would clear the situation up a bit. All the best Peter On 05.12.2016 22:18, Matthias Seidel wrote: Yes, we could use our cWiki for that... Apart from that, it would be a good idea to give our users a small overview of what is planned for the future. Maybe combined with a Christmas greeting? ;-) regards, Matthias Am 04.12.2016 um 15:11 schrieb Marcus: Am 12/03/2016 01:21 PM, schrieb Peter Kovacs: So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo backlog List type. I love Agile methology. Never came to use it thought, because companies can not deal well if there is no timeframe. But I think for us its perfect. we have already so many tools that some of us still don't know any of them. So, it won't help us when we have just another tool to document some tasks. We should use our Wiki like we do for other tasks. My 2 ct. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
Am 12/05/2016 09:35 PM, schrieb Peter Kovacs: Because I read much concern about the freedom of activity and meritocratic spirit of the Project. In my eyes it is not about who does what, but where we want to go. This has to be a common understanding. Nothing more, nothing less is the intent. The meritocratic workbase is not affected by this. If people do not agree, on a single common goal, then this is as okay as we agree on one vision how Open Office will change. it's not pro or contra regarding a product roadmap. It's just where to document this. Maybe this was not clearly enough expressed. Marcus On 04.12.2016 15:11, Marcus wrote: Am 12/03/2016 01:21 PM, schrieb Peter Kovacs: So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo backlog List type. I love Agile methology. Never came to use it thought, because companies can not deal well if there is no timeframe. But I think for us its perfect. we have already so many tools that some of us still don't know any of them. So, it won't help us when we have just another tool to document some tasks. We should use our Wiki like we do for other tasks. My 2 ct. I think a Wiki is a good Documenting Platform. For tracking tasks it is more medicore tool in my Opinion. esspecially when it starts changeing all the time. And I think that will happen when topics get started and then delays for some reasons, while other Topics having a drive. Plans will have to constantly be revised and changed. On the other hand you are right. To get started again Wiki is as good as any other approach. @Patricia In my opinion the building tool is part of our Roadmap. Not only that we need to document things, but we also need to think to extend its functionality to support us in future requirements. For example the requirement to sign Packages as our Product to prohibit that other sites change our product without changing the name. Also I agree with Jörg that the Roadmap should contain tasks that this list is concerned about but are not necessary a programming task. # Concerning 12h period. (did not find who brought this up :) ) What I mean is that it would be great if we could devide all activities in good estimate able chunks. Agile methology claims everything that an experienced developer estimates beyond 24h h (3 working days) of effort is inaccurate and there is a high propability that something has been forgotten. Thanks for you feedback! I will overhaul now our outdated Roadmaps, and start a base for a new Roadmap. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
On 12/4/2016 2:13 PM, toki wrote: > > > On 03/12/16 12:21, Peter Kovacs wrote: > >> But then wrote nothing more. I think if you come here, with the >> will to fight alone through all the mess, you will give up fast because >> you have no Idea what your next step is. > > https://wiki.openoffice.org/wiki/Features > http://www.openoffice.org/development/releases/ooo_roadmap.pdf > https://wiki.openoffice.org/wiki/Product_Release Product Release was updated today. Was a simple one line addition to add 4.1.3 Release which you could have added when you saw it was missing. > > > But as can be seen, they are unmaintained. > > > jonathon > signature.asc Description: OpenPGP digital signature
Re: [discussion] Roadmap for Open Office
Yes, we could use our cWiki for that... Apart from that, it would be a good idea to give our users a small overview of what is planned for the future. Maybe combined with a Christmas greeting? ;-) regards, Matthias Am 04.12.2016 um 15:11 schrieb Marcus: > Am 12/03/2016 01:21 PM, schrieb Peter Kovacs: >> So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo >> backlog List type. I love Agile methology. Never came to use it thought, >> because companies can not deal well if there is no timeframe. But I >> think for us its perfect. > > we have already so many tools that some of us still don't know any of > them. So, it won't help us when we have just another tool to document > some tasks. We should use our Wiki like we do for other tasks. > > My 2 ct. > > Marcus > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > smime.p7s Description: S/MIME Cryptographic Signature
Re: [discussion] Roadmap for Open Office
Hi All, Because I read much concern about the freedom of activity and meritocratic spirit of the Project. In my eyes it is not about who does what, but where we want to go. This has to be a common understanding. Nothing more, nothing less is the intent. The meritocratic workbase is not affected by this. If people do not agree, on a single common goal, then this is as okay as we agree on one vision how Open Office will change. On 04.12.2016 15:11, Marcus wrote: Am 12/03/2016 01:21 PM, schrieb Peter Kovacs: So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo backlog List type. I love Agile methology. Never came to use it thought, because companies can not deal well if there is no timeframe. But I think for us its perfect. we have already so many tools that some of us still don't know any of them. So, it won't help us when we have just another tool to document some tasks. We should use our Wiki like we do for other tasks. My 2 ct. I think a Wiki is a good Documenting Platform. For tracking tasks it is more medicore tool in my Opinion. esspecially when it starts changeing all the time. And I think that will happen when topics get started and then delays for some reasons, while other Topics having a drive. Plans will have to constantly be revised and changed. On the other hand you are right. To get started again Wiki is as good as any other approach. @Patricia In my opinion the building tool is part of our Roadmap. Not only that we need to document things, but we also need to think to extend its functionality to support us in future requirements. For example the requirement to sign Packages as our Product to prohibit that other sites change our product without changing the name. Also I agree with Jörg that the Roadmap should contain tasks that this list is concerned about but are not necessary a programming task. # Concerning 12h period. (did not find who brought this up :) ) What I mean is that it would be great if we could devide all activities in good estimate able chunks. Agile methology claims everything that an experienced developer estimates beyond 24h h (3 working days) of effort is inaccurate and there is a high propability that something has been forgotten. Thanks for you feedback! I will overhaul now our outdated Roadmaps, and start a base for a new Roadmap. All the best Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
Hi Peter, * Am 12/3/2016 um 1:21 PM schrieb Peter Kovacs: Hello all, I thought a little. There were some people claiming that they want to help. But then wrote nothing more. I think if you come here, with the will to fight alone through all the mess, you will give up fast because you have no Idea what your next step is. I personally do not have the Problem, since I have a plan what I want to do. However I think this is not true for a lot of people. I would like to get us a bit organized. Get people work to do, while giving everyone the freedom the need / claim in order to advance. This can be one reason. An other one could be, that they see, that all is more complicated as they expect, and they give up.. It's a common thing, that a much more people offer help than realy jump in. So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo backlog List type. I love Agile methology. Never came to use it thought, because companies can not deal well if there is no timeframe. But I think for us its perfect. This is something that might be small sounding, but there are lots of tasks involved. We collect all the necessary tasks List them up, and offer them on the TODO Bazar (The Backlog). Listing where we working on, is a good idea. But also keep in mind, that everyone deside on there own if what they do Volunteers can take the task from there, and solve it. It gets introduced into our trunc. If task is fullfilled, we generate a release out of it. I do not have an example ready. But maybe just roughly the signing issue: # EPIC: Signing in MAC ## Extend build tool with sign task ## build Online certificate vault plus client ## Test system Some thing like this. Maybe a bit more detailed, best Idea would be that no task takes more then estimated 12h to accomplish. If we manage to chop tasks into small pieces like this It is easy to wor through the tasks. I believe 12h task is unrealistic What do you think? Is this nuts? What are your thoughts? I think if we have such a roadmap, we can go also on public and have something to talk about. I think it would make our Project a lot more lovely. At least, I think, OpenOffice stays OpenOffice. It's big, complicated and not a smart project for programmer. It's mor a challange as fun. But there are people who search the challenge and they are right here. Regards Raphael - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
On 03/12/16 12:21, Peter Kovacs wrote: > But then wrote nothing more. I think if you come here, with the > will to fight alone through all the mess, you will give up fast because > you have no Idea what your next step is. https://wiki.openoffice.org/wiki/Features http://www.openoffice.org/development/releases/ooo_roadmap.pdf https://wiki.openoffice.org/wiki/Product_Release But as can be seen, they are unmaintained. jonathon - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
Am 12/03/2016 01:21 PM, schrieb Peter Kovacs: So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo backlog List type. I love Agile methology. Never came to use it thought, because companies can not deal well if there is no timeframe. But I think for us its perfect. we have already so many tools that some of us still don't know any of them. So, it won't help us when we have just another tool to document some tasks. We should use our Wiki like we do for other tasks. My 2 ct. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
Hello, > From: Peter Kovacs [mailto:legi...@gmail.com] > I thought a little. There were some people claiming that they want to > help. But then wrote nothing more. I think if you come here, with the > will to fight alone through all the mess, you will give up > fast because > you have no Idea what your next step is. I personally do not have the > Problem, since I have a plan what I want to do. However I > think this is > not true for a lot of people. > I would like to get us a bit organized. Get people work to do, while > giving everyone the freedom the need / claim in order to advance. > > So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo > backlog List type. I love Agile methology. Never came to use > it thought, > because companies can not deal well if there is no timeframe. But I > think for us its perfect. > > This is something that might be small sounding, but there are lots of > tasks involved. We collect all the necessary tasks List them up, and > offer them on the TODO Bazar (The Backlog). > Volunteers can take the task from there, and solve it. It gets > introduced into our trunc. If task is fullfilled, we generate > a release > out of it. > > I do not have an example ready. But maybe just roughly the > signing issue: > # EPIC: Signing in MAC > ## Extend build tool with sign task > ## build Online certificate vault plus client > ## Test system > > Some thing like this. Maybe a bit more detailed, best Idea > would be that > no task takes more then estimated 12h to accomplish. > If we manage to chop tasks into small pieces like this It is > easy to wor > through the tasks. > > What do you think? Is this nuts? What are your thoughts? > I think if we have such a roadmap, we can go also on public and have > something to talk about. I think it would make our Project a lot more > lovely. +1 Basically, I support your statements. Please understand, however, that I do not want to interfere in details if these details concern the work of programmers because the project works meritocratically. On the margins, I would like to point out that a roadmap, when it comes about, should also consider non-programming tasks. Greetings, Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] Roadmap for Open Office
+1 for a roadmap! regards, Matthias Am 03.12.2016 um 13:21 schrieb Peter Kovacs: > Hello all, > > I thought a little. There were some people claiming that they want to > help. But then wrote nothing more. I think if you come here, with the > will to fight alone through all the mess, you will give up fast > because you have no Idea what your next step is. I personally do not > have the Problem, since I have a plan what I want to do. However I > think this is not true for a lot of people. > I would like to get us a bit organized. Get people work to do, while > giving everyone the freedom the need / claim in order to advance. > > So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo > backlog List type. I love Agile methology. Never came to use it > thought, because companies can not deal well if there is no timeframe. > But I think for us its perfect. > > This is something that might be small sounding, but there are lots of > tasks involved. We collect all the necessary tasks List them up, and > offer them on the TODO Bazar (The Backlog). > Volunteers can take the task from there, and solve it. It gets > introduced into our trunc. If task is fullfilled, we generate a > release out of it. > > I do not have an example ready. But maybe just roughly the signing issue: > # EPIC: Signing in MAC > ## Extend build tool with sign task > ## build Online certificate vault plus client > ## Test system > > Some thing like this. Maybe a bit more detailed, best Idea would be > that no task takes more then estimated 12h to accomplish. > If we manage to chop tasks into small pieces like this It is easy to > wor through the tasks. > > What do you think? Is this nuts? What are your thoughts? > I think if we have such a roadmap, we can go also on public and have > something to talk about. I think it would make our Project a lot more > lovely. > > All the best > Peter > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: [discussion] Roadmap for Open Office
I think there is something that comes before this. Developers need to be able to build AOO. I think we still need more work on the step-by-step instructions, making sure they are complete and work for all systems. On 12/3/2016 4:21 AM, Peter Kovacs wrote: Hello all, I thought a little. There were some people claiming that they want to help. But then wrote nothing more. I think if you come here, with the will to fight alone through all the mess, you will give up fast because you have no Idea what your next step is. I personally do not have the Problem, since I have a plan what I want to do. However I think this is not true for a lot of people. I would like to get us a bit organized. Get people work to do, while giving everyone the freedom the need / claim in order to advance. So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo backlog List type. I love Agile methology. Never came to use it thought, because companies can not deal well if there is no timeframe. But I think for us its perfect. This is something that might be small sounding, but there are lots of tasks involved. We collect all the necessary tasks List them up, and offer them on the TODO Bazar (The Backlog). Volunteers can take the task from there, and solve it. It gets introduced into our trunc. If task is fullfilled, we generate a release out of it. I do not have an example ready. But maybe just roughly the signing issue: # EPIC: Signing in MAC ## Extend build tool with sign task ## build Online certificate vault plus client ## Test system Some thing like this. Maybe a bit more detailed, best Idea would be that no task takes more then estimated 12h to accomplish. If we manage to chop tasks into small pieces like this It is easy to wor through the tasks. What do you think? Is this nuts? What are your thoughts? I think if we have such a roadmap, we can go also on public and have something to talk about. I think it would make our Project a lot more lovely. All the best Peter - 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
[discussion] Roadmap for Open Office
Hello all, I thought a little. There were some people claiming that they want to help. But then wrote nothing more. I think if you come here, with the will to fight alone through all the mess, you will give up fast because you have no Idea what your next step is. I personally do not have the Problem, since I have a plan what I want to do. However I think this is not true for a lot of people. I would like to get us a bit organized. Get people work to do, while giving everyone the freedom the need / claim in order to advance. So I suggest to keep Bugzilla as Bugtracker, and use Jira as a Todo backlog List type. I love Agile methology. Never came to use it thought, because companies can not deal well if there is no timeframe. But I think for us its perfect. This is something that might be small sounding, but there are lots of tasks involved. We collect all the necessary tasks List them up, and offer them on the TODO Bazar (The Backlog). Volunteers can take the task from there, and solve it. It gets introduced into our trunc. If task is fullfilled, we generate a release out of it. I do not have an example ready. But maybe just roughly the signing issue: # EPIC: Signing in MAC ## Extend build tool with sign task ## build Online certificate vault plus client ## Test system Some thing like this. Maybe a bit more detailed, best Idea would be that no task takes more then estimated 12h to accomplish. If we manage to chop tasks into small pieces like this It is easy to wor through the tasks. What do you think? Is this nuts? What are your thoughts? I think if we have such a roadmap, we can go also on public and have something to talk about. I think it would make our Project a lot more lovely. All the best Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
On 08/06/2013 RGB ES wrote: At this point, I think we all agree that we have a bit of a license mess that needs to be fixed in order to clarify the documentation project. So here is one possible idea: 1- Move the current /Documentation page to /Documentation-OLD or /Documentation-LEGACY(1), indicating at the begining that the content is outdated 2- Create a new portal page on the old url with the characteristic described bellow This could work. But I'm tired of seeing Legacy notices everywhere. I'd prefer to call the legacy stuff Documentation-3 or something related to version 3. And new stuff should not be Documentation-AOO but simply Documentation. Apache OpenOffice is not a guest on the wiki, it is the main subject of the wiki, so it is redundant to say in the title that wiki pages discuss Apache OpenOffice. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
2013/6/9 Andrea Pescetti pesce...@apache.org On 08/06/2013 RGB ES wrote: At this point, I think we all agree that we have a bit of a license mess that needs to be fixed in order to clarify the documentation project. So here is one possible idea: 1- Move the current /Documentation page to /Documentation-OLD or /Documentation-LEGACY(1), indicating at the begining that the content is outdated 2- Create a new portal page on the old url with the characteristic described bellow This could work. But I'm tired of seeing Legacy notices everywhere. I'd prefer to call the legacy stuff Documentation-3 or something related to version 3. Agree. Calling it Documentation-3 is perfect. And new stuff should not be Documentation-AOO but simply Documentation. Sure, that was the original idea. I just mentioned Documentation-AOO as a transitional page where we can work without hurry, and then move the pages to their right positions. From Tuesday I'll start to work on the Draw guide, someone that can help me with the portal page? I can do it myself, of course, but only on a couple of weeks. Regards Ricardo Apache OpenOffice is not a guest on the wiki, it is the main subject of the wiki, so it is redundant to say in the title that wiki pages discuss Apache OpenOffice. 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: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
(top posting, because I'm not answering any particular post) At this point, I think we all agree that we have a bit of a license mess that needs to be fixed in order to clarify the documentation project. So here is one possible idea: 1- Move the current /Documentation page to /Documentation-OLD or /Documentation-LEGACY(1), indicating at the begining that the content is outdated 2- Create a new portal page on the old url with the characteristic described bellow Characteristics for the new portal * Introduction to the project, how to contact the group and participate, pending tasks lists, etc. * Links to the new, Apache licensed documentation (user guide, building guide, etcetera) indicating that it's a work in progress and that new contributors are welcomed. * Add a section that points to the legacy page. Something like Apache OpenOffice inherited not only the code from former OpenOffice.org project, but also a huge amount of documentation. Some of those documents are still valid, some don't, but you can find all of them here. Once this new structure is in place for the main EN site, propagate it to other languages will be easier than fixing current PDL licensed pages. What do you think? (1) Maybe it's better to first create the new portal on /Documentation-AOO, when that new page is ready move /Documentation to /Documentation-Legacy, then move /Documentation-AOO to /Documentation Regards Ricardo 2013/6/5 Dennis E. Hamilton dennis.hamil...@acm.org I don't believe the ASF iCLA I filed stipulates anything about ALv2, although it certainly stipulates what my contributions grant to the ASF and to anyone who receives my contribution via the ASF. (Note that the grant to recipients is directly from me, via the iCLA, no matter what the ALv2 says.) My comment is mainly with respect to pages on the wiki that are covered by licenses other than the ALv2 and what contributing any modifications to them entails, no matter what the ASF gets from me under the terms of my iCLA. Of course, a click-through registration that asserts ALv2 for contributions is fine, although the ASF and recipients still have more rights than that for any contribution I make. The current statement about treating materials not under the default license still applies and I suspect a form of that has to remain in any click-through on registration. The iCLA doesn't (and can't) alter that situation. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, June 5, 2013 01:24 PM To: dev@openoffice.apache.org Cc: l...@openoffice.apache.org; d...@openoffice.apache.org Subject: Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap] On Wed, Jun 5, 2013 at 4:12 PM, Dennis E. Hamilton orc...@apache.org wrote: +1 I prepared my response before I saw this one. There is still need to be careful around this: However, when we create new material, including enhancements Of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. 1. When enhancing existing materials, the existing license must be honored. How additional licensing works depends on the specific Conditions. It should not be automatically assumed possible. 2. Since our having accounts on the wiki are subject to the rules for The wiki, I'm not sure the ICLA governs (1). As committers, we certainly shouldn't be asserting any other license, but the current license on the work is going to determine whether and how the ALv2 can be introduced. The ICLA says: Contribution shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Foundation for inclusion in, or documentation of, any of the products owned or managed by the Foundation (the Work). For the purposes of this definition, submitted means any form of electronic, verbal, or written communication sent to the Foundation or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Foundation for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as Not a Contribution. So I think that covers wiki contributions as well since that is documentation of, yes? -Rob -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, June 5, 2013 10:28 AM To: dev@openoffice.apache.org Cc: l...@openoffice.apache.org; d...@openoffice.apache.org Subject: Re: [Discuss][Wiki]Synchronizing (or not) localized
Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
Hi 2013/6/3 RGB ES rgb.m...@gmail.com: 2013/6/3 Andrea Pescetti pesce...@apache.org On 02/06/2013 RGB ES wrote: Do we want to clone, for example, the documentation section on all the localized sites, just translating it? On Sun times that was the idea, with sub sites (portals) like http://wiki.services.**openoffice.org/wiki/**Documentationhttp://wiki.services.openoffice.org/wiki/Documentation http://wiki.services.**openoffice.org/wiki/DE/**Documentationhttp://wiki.services.openoffice.org/wiki/DE/Documentation http://wiki.services.**openoffice.org/wiki/FR/**Documentationhttp://wiki.services.openoffice.org/wiki/FR/Documentation etc looking almost the same on all languages. Ricardo, we can go by two ways, based in commom practice for mediawiki: http://wiki.../Documentation and http://wiki.../Documentation/lang - for localized pages from the core http://wiki.../LANG/anything - for local/native texts. This can work. We also have this other infrastructure in place http://wiki.openoffice.org/**wiki/Main_Testhttp://wiki.openoffice.org/wiki/Main_Test added by Claudio a few months ago. See http://wiki.openoffice.org/**wiki/Template:Langhttp://wiki.openoffice.org/wiki/Template:Lang to see how it works. I don't know which approach is best for our case. The *Template:* technology is for many other things, like menus, sorts, and others. I think that we can use this first step based in review the core and a way to translate it for other languages. How our system is a mediawiki, i did a research about localization in this software with the last methods, where i found some interesting contents. I believe that with translate extension for mediawiki we have the tool for this goal. http://commons.wikimedia.org/wiki/File:Making_Multilingual_Wikis_a_Reality_-_Niklas_Laxstr%C3%B6m_and_Claus_Christensen.ogv http://www.mediawiki.org/wiki/Help:Extension:Translate http://translatewiki.net/wiki/Translating:MediaWiki As for keeping subsites synchronized, in theory this allows to have a Master copy in English and then translate it in the various languages as volunteers become available. In practice, we can't stop someone from editing or creating a translated page to add new content in a language only, but ideally this would imply that the English version is updated to reflect the changes too. If i understood right, the translate extension will help us in this task. All those portal pages are under PDL license (look at the categories at the bottom of those pages). If we want to promote new wiki content under Apache license, this means a problem. If I read this page right http://www.openoffice.org/licenses/PDL.html PDL is a sort of copyleft license. This is a excelent question. I ask to my self how the TDF did about (more) this question. Can we do like them? Simply overwrite the license and to continue the devel? (i remember when they copied all sites/docs/contents, like api site, and changed the license) Re-license those pages is not possible without the explicit consent of the author, and those pages are so old that contact the authors is almost impossible. Suppose we update those pages to point to the new material. A potential contributor (or just a casual reader) will see the PDL notice on the portal page, and no notice on the new pages: from the user perspective, does this means that the new page is also under PDL? We know it isn't, but this could be a cause of confusion, IMO. So, which is the best way to work around this problem? Reimplement those pages, making a clear separation between new material (under Apache) and legacy content? Maybe this is the unique way. By other hand, is a opportunity of review all content in the wiki, reorder and clean it, and evolve based in the correct license. In some cases, we can see the page history and try to find the author. Some parts, i believe that is all from Sun/Oracle copyright, so transfered to ASF. My 2¢ Claudio - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
On Wed, Jun 5, 2013 at 12:02 PM, janI j...@apache.org wrote: On 5 June 2013 16:36, Claudio Filho filh...@gmail.com wrote: Hi 2013/6/3 RGB ES rgb.m...@gmail.com: 2013/6/3 Andrea Pescetti pesce...@apache.org On 02/06/2013 RGB ES wrote: Do we want to clone, for example, the documentation section on all the localized sites, just translating it? On Sun times that was the idea, with sub sites (portals) like http://wiki.services.**openoffice.org/wiki/**Documentation http://wiki.services.openoffice.org/wiki/Documentation http://wiki.services.**openoffice.org/wiki/DE/**Documentation http://wiki.services.openoffice.org/wiki/DE/Documentation http://wiki.services.**openoffice.org/wiki/FR/**Documentation http://wiki.services.openoffice.org/wiki/FR/Documentation etc looking almost the same on all languages. Ricardo, we can go by two ways, based in commom practice for mediawiki: http://wiki.../Documentation and http://wiki.../Documentation/lang - for localized pages from the core http://wiki.../LANG/anything - for local/native texts. This can work. We also have this other infrastructure in place http://wiki.openoffice.org/**wiki/Main_Test http://wiki.openoffice.org/wiki/Main_Test added by Claudio a few months ago. See http://wiki.openoffice.org/**wiki/Template:Lang http://wiki.openoffice.org/wiki/Template:Lang to see how it works. I don't know which approach is best for our case. The *Template:* technology is for many other things, like menus, sorts, and others. I think that we can use this first step based in review the core and a way to translate it for other languages. How our system is a mediawiki, i did a research about localization in this software with the last methods, where i found some interesting contents. I believe that with translate extension for mediawiki we have the tool for this goal. http://commons.wikimedia.org/wiki/File:Making_Multilingual_Wikis_a_Reality_-_Niklas_Laxstr%C3%B6m_and_Claus_Christensen.ogv http://www.mediawiki.org/wiki/Help:Extension:Translate http://translatewiki.net/wiki/Translating:MediaWikie I checked the extension, it is possible to install it on our mwiki. As for keeping subsites synchronized, in theory this allows to have a Master copy in English and then translate it in the various languages as volunteers become available. In practice, we can't stop someone from editing or creating a translated page to add new content in a language only, but ideally this would imply that the English version is updated to reflect the changes too. If i understood right, the translate extension will help us in this task. All those portal pages are under PDL license (look at the categories at the bottom of those pages). If we want to promote new wiki content under Apache license, this means a problem. If I read this page right http://www.openoffice.org/licenses/PDL.html PDL is a sort of copyleft license. We've tried to avoid this problem by starting new documentation in ALv2, not using the prior materials. And remember, if we want to borrow material, we have access to the complete Symphony documentation as well, which is included in the IBM SGA for Symphony. So all of that can be treated as ALv2. This is a excelent question. I ask to my self how the TDF did about (more) this question. Can we do like them? Simply overwrite the license and to continue the devel? (i remember when they copied all sites/docs/contents, like api site, and changed the license) I have seen similar things happen in other wikis. The way forward seems to be 1) announce the intention of changing license. 2) request contributors who do not agree, to remove their pages (we have mail adresses on the users) 3) give contributors time to do it. 4) change license. This is overkill. There is no need to remove PDL pages. Maybe just move them if they are inconvenient? But if the content is relevant, why remove? The way forward is to respect the licenses as they are. We have greater latitude in what legacy licenses are used on the website than we do in the AOO product itself. We've had no problems at all hosting Creative Content licensed documentation, PDL content, etc., on the website, wiki, etc. Nothing has changed in that regard. However, when we create new material, including enhancements of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. This should not be a problem. We should put the license in as part of create user, as an do you accept, thereby we only have a problem with existing users. This would be nice. Re-license those pages is not possible without the explicit consent of the author, and those pages are so old that contact the authors is almost impossible. Suppose we update those pages to point to the new material. A potential contributor
RE: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
@JanI, Uh oh. If you don't have explicit agreement from the contributor(s) to a page concerning it being offered under a different license, either leave the existing license or remove the content. Those are the only legally-sanitary options for works still under copyright. Declaring a work still in copyright to be orphaned does not give you permission to republish it with a different license. Copyright doesn't work that way, not merely in the US. Secondly, the web site and wiki content were not, as far as I know, included in the grant from Oracle. There has clearly been no objection, the domains were transferred to the ASF, but technically that does not in any way change the copyright status of any of the content. (The source-code grant, by the way, did not transfer any copyright to the ASF. It simply provided a license to the ASF that allowed the ASF to publish and make derivatives under its license. Copyright in the original content continues to abide with Oracle.) While casual treatment of this sort of thing succeeds in some situations, here the interests and concerns of The Apache Software Foundation as a public-interest entity come into play. It is expected that folks on Apache projects will play nice with the intellectual property of others. In particular, 2) We are allowed to copy the pages, with changes, and the new page can be under a new license is not ever automatically true. If there is already a license, the terms of that license will determine what is possible with a derivative work (with changes). Even copying is an exclusive right of the copyright holder, so the license matters there too. In the absence of a license, (2) is not permitted at all by anyone but the copyright holder or someone authorized by the copyright holder (i.e., being licensed to do so). Finally, and most important, making changes does not give anyone different rights to the parts that survive from the original work. (Fine points about license conditions apply here, but one should never assume that a legitimate licensing of a derivative work has any impact on the IP interests in the surviving content of the original work.) - Dennis -Original Message- From: janI [mailto:j...@apache.org] Sent: Wednesday, June 5, 2013 09:02 AM To: dev@openoffice.apache.org Cc: l...@openoffice.apache.org; d...@openoffice.apache.org Subject: Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap] [ ... ] PDL is a sort of copyleft license. This is a excelent question. I ask to my self how the TDF did about (more) this question. Can we do like them? Simply overwrite the license and to continue the devel? (i remember when they copied all sites/docs/contents, like api site, and changed the license) I have seen similar things happen in other wikis. The way forward seems to be 1) announce the intention of changing license. 2) request contributors who do not agree, to remove their pages (we have mail adresses on the users) 3) give contributors time to do it. 4) change license. We should put the license in as part of create user, as an do you accept, thereby we only have a problem with existing users. Re-license those pages is not possible without the explicit consent of the author, and those pages are so old that contact the authors is almost impossible. Suppose we update those pages to point to the new material. A potential contributor (or just a casual reader) will see the PDL notice on the portal page, and no notice on the new pages: from the user perspective, does this means that the new page is also under PDL? We know it isn't, but this could be a cause of confusion, IMO. So, which is the best way to work around this problem? Reimplement those pages, making a clear separation between new material (under Apache) and legacy content? Maybe this is the unique way. By other hand, is a opportunity of review all content in the wiki, reorder and clean it, and evolve based in the correct license. In some cases, we can see the page history and try to find the author. Some parts, i believe that is all from Sun/Oracle copyright, so transfered to ASF. A cleanup would be nice independent of which way we go The word re-licensing is not a show stopper. 1) We are not obligated to store those pages for ever, we can, with notice, delete the pages 2) We are allowed to copy the pages, with changes, and the new page can be under a new license rgds jan I My 2¢ Claudio - 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: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
+1 I prepared my response before I saw this one. There is still need to be careful around this: However, when we create new material, including enhancements Of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. 1. When enhancing existing materials, the existing license must be honored. How additional licensing works depends on the specific Conditions. It should not be automatically assumed possible. 2. Since our having accounts on the wiki are subject to the rules for The wiki, I'm not sure the ICLA governs (1). As committers, we certainly shouldn't be asserting any other license, but the current license on the work is going to determine whether and how the ALv2 can be introduced. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, June 5, 2013 10:28 AM To: dev@openoffice.apache.org Cc: l...@openoffice.apache.org; d...@openoffice.apache.org Subject: Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap] [ ... ] All those portal pages are under PDL license (look at the categories at the bottom of those pages). If we want to promote new wiki content under Apache license, this means a problem. If I read this page right http://www.openoffice.org/licenses/PDL.html PDL is a sort of copyleft license. We've tried to avoid this problem by starting new documentation in ALv2, not using the prior materials. And remember, if we want to borrow material, we have access to the complete Symphony documentation as well, which is included in the IBM SGA for Symphony. So all of that can be treated as ALv2. [ ... ] This is overkill. There is no need to remove PDL pages. Maybe just move them if they are inconvenient? But if the content is relevant, why remove? The way forward is to respect the licenses as they are. We have greater latitude in what legacy licenses are used on the website than we do in the AOO product itself. We've had no problems at all hosting Creative Content licensed documentation, PDL content, etc., on the website, wiki, etc. Nothing has changed in that regard. However, when we create new material, including enhancements of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. This should not be a problem. [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
On Wed, Jun 5, 2013 at 4:12 PM, Dennis E. Hamilton orc...@apache.org wrote: +1 I prepared my response before I saw this one. There is still need to be careful around this: However, when we create new material, including enhancements Of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. 1. When enhancing existing materials, the existing license must be honored. How additional licensing works depends on the specific Conditions. It should not be automatically assumed possible. 2. Since our having accounts on the wiki are subject to the rules for The wiki, I'm not sure the ICLA governs (1). As committers, we certainly shouldn't be asserting any other license, but the current license on the work is going to determine whether and how the ALv2 can be introduced. The ICLA says: Contribution shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Foundation for inclusion in, or documentation of, any of the products owned or managed by the Foundation (the Work). For the purposes of this definition, submitted means any form of electronic, verbal, or written communication sent to the Foundation or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Foundation for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as Not a Contribution. So I think that covers wiki contributions as well since that is documentation of, yes? -Rob -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, June 5, 2013 10:28 AM To: dev@openoffice.apache.org Cc: l...@openoffice.apache.org; d...@openoffice.apache.org Subject: Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap] [ ... ] All those portal pages are under PDL license (look at the categories at the bottom of those pages). If we want to promote new wiki content under Apache license, this means a problem. If I read this page right http://www.openoffice.org/licenses/PDL.html PDL is a sort of copyleft license. We've tried to avoid this problem by starting new documentation in ALv2, not using the prior materials. And remember, if we want to borrow material, we have access to the complete Symphony documentation as well, which is included in the IBM SGA for Symphony. So all of that can be treated as ALv2. [ ... ] This is overkill. There is no need to remove PDL pages. Maybe just move them if they are inconvenient? But if the content is relevant, why remove? The way forward is to respect the licenses as they are. We have greater latitude in what legacy licenses are used on the website than we do in the AOO product itself. We've had no problems at all hosting Creative Content licensed documentation, PDL content, etc., on the website, wiki, etc. Nothing has changed in that regard. However, when we create new material, including enhancements of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. This should not be a problem. [ ... ] - 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: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
I don't believe the ASF iCLA I filed stipulates anything about ALv2, although it certainly stipulates what my contributions grant to the ASF and to anyone who receives my contribution via the ASF. (Note that the grant to recipients is directly from me, via the iCLA, no matter what the ALv2 says.) My comment is mainly with respect to pages on the wiki that are covered by licenses other than the ALv2 and what contributing any modifications to them entails, no matter what the ASF gets from me under the terms of my iCLA. Of course, a click-through registration that asserts ALv2 for contributions is fine, although the ASF and recipients still have more rights than that for any contribution I make. The current statement about treating materials not under the default license still applies and I suspect a form of that has to remain in any click-through on registration. The iCLA doesn't (and can't) alter that situation. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, June 5, 2013 01:24 PM To: dev@openoffice.apache.org Cc: l...@openoffice.apache.org; d...@openoffice.apache.org Subject: Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap] On Wed, Jun 5, 2013 at 4:12 PM, Dennis E. Hamilton orc...@apache.org wrote: +1 I prepared my response before I saw this one. There is still need to be careful around this: However, when we create new material, including enhancements Of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. 1. When enhancing existing materials, the existing license must be honored. How additional licensing works depends on the specific Conditions. It should not be automatically assumed possible. 2. Since our having accounts on the wiki are subject to the rules for The wiki, I'm not sure the ICLA governs (1). As committers, we certainly shouldn't be asserting any other license, but the current license on the work is going to determine whether and how the ALv2 can be introduced. The ICLA says: Contribution shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Foundation for inclusion in, or documentation of, any of the products owned or managed by the Foundation (the Work). For the purposes of this definition, submitted means any form of electronic, verbal, or written communication sent to the Foundation or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Foundation for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as Not a Contribution. So I think that covers wiki contributions as well since that is documentation of, yes? -Rob -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, June 5, 2013 10:28 AM To: dev@openoffice.apache.org Cc: l...@openoffice.apache.org; d...@openoffice.apache.org Subject: Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap] [ ... ] All those portal pages are under PDL license (look at the categories at the bottom of those pages). If we want to promote new wiki content under Apache license, this means a problem. If I read this page right http://www.openoffice.org/licenses/PDL.html PDL is a sort of copyleft license. We've tried to avoid this problem by starting new documentation in ALv2, not using the prior materials. And remember, if we want to borrow material, we have access to the complete Symphony documentation as well, which is included in the IBM SGA for Symphony. So all of that can be treated as ALv2. [ ... ] This is overkill. There is no need to remove PDL pages. Maybe just move them if they are inconvenient? But if the content is relevant, why remove? The way forward is to respect the licenses as they are. We have greater latitude in what legacy licenses are used on the website than we do in the AOO product itself. We've had no problems at all hosting Creative Content licensed documentation, PDL content, etc., on the website, wiki, etc. Nothing has changed in that regard. However, when we create new material, including enhancements of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. This should not be a problem
Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
On 02/06/2013 RGB ES wrote: (Top posting, CC to dev, doc and l10n, not sure on which one it is better to continue the discussion) Do we want to clone, for example, the documentation section on all the localized sites, just translating it? On Sun times that was the idea, with sub sites (portals) like http://wiki.services.openoffice.org/wiki/Documentation http://wiki.services.openoffice.org/wiki/DE/Documentation http://wiki.services.openoffice.org/wiki/FR/Documentation etc looking almost the same on all languages. This can work. We also have this other infrastructure in place http://wiki.openoffice.org/wiki/Main_Test added by Claudio a few months ago. See http://wiki.openoffice.org/wiki/Template:Lang to see how it works. I don't know which approach is best for our case. As for keeping subsites synchronized, in theory this allows to have a Master copy in English and then translate it in the various languages as volunteers become available. In practice, we can't stop someone from editing or creating a translated page to add new content in a language only, but ideally this would imply that the English version is updated to reflect the changes too. AFAIK, right now the only of those sub sites updated recently is the French one, though: several of those portals do not see activity since years. Yes, but this does not mean that they are completely outdated: information in those pages is still current and relevant in most cases, and I think it makes sense to continue using it rather than starting clean there too (unless there are plans for a major rewrite). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Fwd: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
Ops! I forgot to add dev and doc as CC... -- Forwarded message -- From: RGB ES rgb.m...@gmail.com Date: 2013/6/3 Subject: Re: [Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap] To: l...@openoffice.apache.org 2013/6/3 Andrea Pescetti pesce...@apache.org On 02/06/2013 RGB ES wrote: (Top posting, CC to dev, doc and l10n, not sure on which one it is better to continue the discussion) Do we want to clone, for example, the documentation section on all the localized sites, just translating it? On Sun times that was the idea, with sub sites (portals) like http://wiki.services.**openoffice.org/wiki/**Documentationhttp://wiki.services.openoffice.org/wiki/Documentation http://wiki.services.**openoffice.org/wiki/DE/**Documentationhttp://wiki.services.openoffice.org/wiki/DE/Documentation http://wiki.services.**openoffice.org/wiki/FR/**Documentationhttp://wiki.services.openoffice.org/wiki/FR/Documentation etc looking almost the same on all languages. This can work. We also have this other infrastructure in place http://wiki.openoffice.org/**wiki/Main_Testhttp://wiki.openoffice.org/wiki/Main_Test added by Claudio a few months ago. See http://wiki.openoffice.org/**wiki/Template:Langhttp://wiki.openoffice.org/wiki/Template:Lang to see how it works. I don't know which approach is best for our case. As for keeping subsites synchronized, in theory this allows to have a Master copy in English and then translate it in the various languages as volunteers become available. In practice, we can't stop someone from editing or creating a translated page to add new content in a language only, but ideally this would imply that the English version is updated to reflect the changes too. AFAIK, right now the only of those sub sites updated recently is the French one, though: several of those portals do not see activity since years. Yes, but this does not mean that they are completely outdated: information in those pages is still current and relevant in most cases, and I think it makes sense to continue using it rather than starting clean there too (unless there are plans for a major rewrite). All those portal pages are under PDL license (look at the categories at the bottom of those pages). If we want to promote new wiki content under Apache license, this means a problem. If I read this page right http://www.openoffice.org/licenses/PDL.html PDL is a sort of copyleft license. Re-license those pages is not possible without the explicit consent of the author, and those pages are so old that contact the authors is almost impossible. Suppose we update those pages to point to the new material. A potential contributor (or just a casual reader) will see the PDL notice on the portal page, and no notice on the new pages: from the user perspective, does this means that the new page is also under PDL? We know it isn't, but this could be a cause of confusion, IMO. So, which is the best way to work around this problem? Reimplement those pages, making a clear separation between new material (under Apache) and legacy content? Regards Ricardo Regards, Andrea. --**--**- To unsubscribe, e-mail: l10n-unsubscribe@openoffice.**apache.orgl10n-unsubscr...@openoffice.apache.org For additional commands, e-mail: l10n-help@openoffice.apache.**orgl10n-h...@openoffice.apache.org
[Discuss][Wiki]Synchronizing (or not) localized wiki sites [was: Fwd: [UserGuide]My roadmap]
(Top posting, CC to dev, doc and l10n, not sure on which one it is better to continue the discussion) Moving the discussion to its own thread, see below for a copy of the previous messages or better here: http://markmail.org/message/x6wntz5nwefj7ko3 (just skip the first message that had a completely different purpose...) The original thread shows two problems. I'll not talk about the first one here (to not communicate what someone is doing, at the risk of waste the efforts of someone else that it's working on the same task). The second problem, the one considered here, is about how do we want to organize the wiki. Do we want to clone, for example, the documentation section on all the localized sites, just translating it? On Sun times that was the idea, with sub sites (portals) like http://wiki.services.openoffice.org/wiki/Documentation http://wiki.services.openoffice.org/wiki/DE/Documentation http://wiki.services.openoffice.org/wiki/FR/Documentation etc looking almost the same on all languages. AFAIK, right now the only of those sub sites updated recently is the French one, though: several of those portals do not see activity since years. I don't think that this cloning is possible or even desirable. Of course an easy way to arrive to the same resources on the different languages *is* desirable, and for this purpose a consolidated directory structure is certainly useful, but if instead of /ES/Documentation we use /ES/Manuales I cannot really see the problem. Also, there is the problem that the content available on those old sites is mainly outdated, build by a third party project and some(many)times with the wrong license. Do we want to update that content or start almost from scratch with the new user guide under Apache license, moving old content to a legacy section? Of course starting from scratch is more work, but updating documents with a cocktail of licenses will be a problem too. And note that starting from scratch does not mean trashing old content, it's just saying this is the old content, maybe it's still useful, but we are working on the new one here. I think this was briefly discussed before on the dev list (with no clear output), but I cannot find the original thread now. Regards Ricardo -- Forwarded message -- From: Alexandro Colorado j...@oooes.org Date: 2013/6/1 Subject: Re: [UserGuide]My roadmap To: OpenOffice Documentation d...@openoffice.apache.org On Sat, Jun 1, 2013 at 3:00 PM, RGB ES rgb.m...@gmail.com wrote: 2013/6/1 Alexandro Colorado j...@oooes.org On Sat, Jun 1, 2013 at 2:23 PM, RGB ES rgb.m...@gmail.com wrote: 2013/6/1 Alexandro Colorado j...@oooes.org Is important to re-gain organization on the documentation project resources like: - ToDo List - Wishlist - Dashboard - Help process This resources althought outdated are pretty helpful for new and experienced contributors to organize the work going on. I generate a spanish version of the portal, but would need more than just cloning old information . http://wiki.openoffice.org/wiki/ES/Documentation Can you please use the ES mailing list to discuss whatever you want to do on the ES wiki FIRST of doing it? There is already a documentation section and a how to participate section here http://wiki.openoffice.org/wiki/ES/Manuales http://wiki.openoffice.org/wiki/ES/Participar If you look carefully you'll see other people beside me that started to work on the site several month ago. As a matter of fact, the Spanish user guide is more advanced than the English one (just see the macro section)... Following discussions on the ES mailing list, the ES wiki was completely cleaned up and rebuilt almost from scratch last year. This is not a ES related matter, but a localization convention on working and organizing languages on the Wiki. There is a PDL and Template for languages, in order to use the different localizations of the projects and the menu extensions labeled Other languages. Documentation or l10n lists is the only propper channels I can think on discussing this since is not only use by ES but the other languages. The content is also outdated on this project, not only on ES. The wishlist hasnt been updated since 2009 and there is already a *NeedsRework* category for the ToDo List. Only the French documentation page was updated recently, all the other localizations do not see work since several years so you are talking about a convention set on the old Sun times that nobody seems to follow now and thus not necessarily valid today. If you want to discuss this or other conventions please start a new thread. But even if we accept a general convention (something that did not happen yet) and even if we accept that this convention is not a matter for the ES list (!), to coordinate the work on the ES wiki IS something to discuss
