Re: [RELEASE] Releasing new languages for 3.4.1
On 30/10/2012 Rob Weir wrote: However, if we want to have a beta release of these lang packs, then this is not hard either: 1) Checked the PO files into the 3.4.x branch 2) Verify that they have correct license headers (assuming PO files allow a license header) 3) Generate a source package as a diff file of the branch against the 3.4.1 revision 4) Generate the binary packages, perhaps just lang packs, perhaps full installs 5) Sign the source package and binary packages 6) 72 hour release vote 7) Announce via blog, etc. This seems good since it would allow to avoid distributing a 3.4.2 for the only sake of adding new languages: users would be disappointed to see a new 3.4.2 identical to 3.4.1 (since all changes and bugfixes are being applied to trunk only). The only problem I see is that we would then have the distributed 3.4.1 binaries in English compiled from the August sources, and the distributed 3.4.1 binaries in Danish compiled from the November sources. But, so long as the AOO34 branch is updated with new language files only, this approach can work. About 1 and 2: PO files do allow for a license header, but are imported (with conversion) in the sources rather than simply copied, so steps 1 and 2 would be replaced by importing the PO files and clarify their provenance/license. Of course, this all has overhead, especially for you, the release manager. So we don't want to repeat this too frequently. This has overhead on the release managers, package providers, website maintainers, mirror operators and (to a lesser extent) on the whole community. But if we can enable new languages to appear within a few weeks, perhaps in batches of 3-5, this is positive news for the community engagement. Localization volunteers are the ones we are most prepared to handle at the moment, and an important resource for the project. Regards, Andrea.
Re: [RELEASE] Releasing new languages for 3.4.1
On 11/1/12 10:09 AM, Andrea Pescetti wrote: On 31/10/2012 jan iversen wrote: Ok, I thought team meant language teams. But I have searched the Wiki and cannot find any documentation on the required QA procedure relating to national languages. Can it be, that it was never really defined and written down ? It was. We used to have two tools, TCM and QATrack. The former was a test management platform, which (among many other things) contained a Release Sanity test suite, about 30 tests that should be passed to release OpenOffice in a certain language: sorting text with native language characters and so on. The latter was a web panel where responsible QA persons for each language could state that they were running QA on, say, the German Mac OS X version and report whether the build was approved or rejected (and much more, but this is the basic idea). Both tools are unused now. TCM is not accessible but if Oracle manages to provide the testcases (not the platform) we will be able to reuse them. QATrack was initially written by me and then significantly extended by Per Eriksson and we should have it somewhere, but can be easily redone on a proper framework: I wouldn't write a tool explicitly for that purpose any longer these days. I am not sure but maybe we can use TestLink more in the future. I have to confess that I never used QATrack in the past and don't know what it provided exactly and how it was used. http://aootesting.adfinis-sygroup.org/login.php Juergen
Re: [RELEASE] Releasing new languages for 3.4.1
On 10/30/12 4:22 PM, jan iversen wrote: Question: Is there a rule in the apache way defining who can do QA, or is it totally up to the single teams ? It's up to the teams I think Do we use the review statistic in pootle to anything, it seems actually quite clever. we don't make use of it right now and I have to confess that I haven't really looked in it yet because of the lack of time. Juergen Jan. On 30 October 2012 16:17, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. Juergen -Rob Regards Ricardo -Rob -Rob Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
I do not understand the release discussion assuming juergen is right. why don't we ask each team to send a mail confirming they have made QA then we would release the language packs officially (at least this time) this would also give us time to discuss the ideal situation. juergen: you will (hopefully) soon get an extra pair of hands to help! Den 31/10/2012 11.10 skrev Jürgen Schmidt jogischm...@gmail.com: On 10/30/12 4:22 PM, jan iversen wrote: Question: Is there a rule in the apache way defining who can do QA, or is it totally up to the single teams ? It's up to the teams I think Do we use the review statistic in pootle to anything, it seems actually quite clever. we don't make use of it right now and I have to confess that I haven't really looked in it yet because of the lack of time. Juergen Jan. On 30 October 2012 16:17, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. Juergen
Re: [RELEASE] Releasing new languages for 3.4.1
On 10/31/12 12:18 PM, jan iversen wrote: I do not understand the release discussion assuming juergen is right. or I have misunderstand your question ;-) I think we as AOO can define how we do QQ and how we want to ensure the quality of our releases. Besides the functional aspects here we have to follow some Apache rules how releases have to be made. Juergen why don't we ask each team to send a mail confirming they have made QA then we would release the language packs officially (at least this time) this would also give us time to discuss the ideal situation. juergen: you will (hopefully) soon get an extra pair of hands to help! Den 31/10/2012 11.10 skrev Jürgen Schmidt jogischm...@gmail.com: On 10/30/12 4:22 PM, jan iversen wrote: Question: Is there a rule in the apache way defining who can do QA, or is it totally up to the single teams ? It's up to the teams I think Do we use the review statistic in pootle to anything, it seems actually quite clever. we don't make use of it right now and I have to confess that I haven't really looked in it yet because of the lack of time. Juergen Jan. On 30 October 2012 16:17, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations
Re: [RELEASE] Releasing new languages for 3.4.1
Ok, I thought team meant language teams. But I have searched the Wiki and cannot find any documentation on the required QA procedure relating to national languages. Can it be, that it was never really defined and written down ?? For code, there seems to be guidelines, but also no real definition of how much test need to be done (it is pretty well defined what happens when QA finds a problem in a release candidate). For the future, not for the set of languages, it would be a good idea to have a clear definition of - which QA gates has to be passed - who (roles) defines if a gate if full filled (national team, someone else?) Jan. On 31 October 2012 14:42, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/31/12 12:18 PM, jan iversen wrote: I do not understand the release discussion assuming juergen is right. or I have misunderstand your question ;-) I think we as AOO can define how we do QQ and how we want to ensure the quality of our releases. Besides the functional aspects here we have to follow some Apache rules how releases have to be made. Juergen why don't we ask each team to send a mail confirming they have made QA then we would release the language packs officially (at least this time) this would also give us time to discuss the ideal situation. juergen: you will (hopefully) soon get an extra pair of hands to help! Den 31/10/2012 11.10 skrev Jürgen Schmidt jogischm...@gmail.com: On 10/30/12 4:22 PM, jan iversen wrote: Question: Is there a rule in the apache way defining who can do QA, or is it totally up to the single teams ? It's up to the teams I think Do we use the review statistic in pootle to anything, it seems actually quite clever. we don't make use of it right now and I have to confess that I haven't really looked in it yet because of the lack of time. Juergen Jan. On 30 October 2012 16:17, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the
Re: [RELEASE] Releasing new languages for 3.4.1
On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen -Rob -Rob Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Regards Ricardo -Rob -Rob Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
+1, such a download page additional untested language packs would allow us to make a translation official immediately with a limited responsibility, just like the snapshots. jan On 30 October 2012 14:02, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Regards Ricardo -Rob -Rob Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. Juergen -Rob Regards Ricardo -Rob -Rob Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
Question: Is there a rule in the apache way defining who can do QA, or is it totally up to the single teams ? Do we use the review statistic in pootle to anything, it seems actually quite clever. Jan. On 30 October 2012 16:17, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. Juergen -Rob Regards Ricardo -Rob -Rob Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
On Tue, Oct 30, 2012 at 11:17 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. It may be worth reviewing this section on test packages versus releases: http://www.apache.org/dev/release.html#release-types It is possible to have something less than a release. We do that, for example, with snapshots and release candidates. We could do something similar with a language pack as well. But it would need to be an internal only distribution, meaning we do not advertise it with the user community. It is just for internal testing. But if we want to have something available for the public at large to use, even if we indicate it is beta quality, then that is still a release. Specific example: We have 3 or so people helping with the Danish translation on the L10N list. If we make a snapshot build for them, full install or language pack, and advertise it only on that list and ooo-dev, then I don't think that is a problem. But we should not make any user-facing announcements, or website changes to point the public to the new language pack, until it
Re: [RELEASE] Releasing new languages for 3.4.1
Hi Speaking for myself and the other 2 in the teamwe do the translation to get AOO available in denmark (again). Right now another openSource product is using the fact that we cannot release our versions in danish, to their benefit. I do not want to compete (which is why I do not write the name, we all know), but also I want to make that AOO is THE well established, well tested, high quality free Software that the companies want to use. So internal things are handy, when it comes to testing, but not when it comes to showing a danish user commity that we are still alive and kicking. jan. On 30 October 2012 16:48, Rob Weir robw...@apache.org wrote: On Tue, Oct 30, 2012 at 11:17 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. It may be worth reviewing this section on test packages versus releases: http://www.apache.org/dev/release.html#release-types It is possible to have something less than a release. We do that, for
Re: [RELEASE] Releasing new languages for 3.4.1
On 26/10/2012 jan iversen wrote: On 26 October 2012 19:43, Andrea Pescetti wrote: - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. I do not agree to that statement for two reasons - a bad translations will influence the reputation of AOO in that language zone. - Wrong translation of e.g. accelerators, might not break the product technically speaking, but for sure the end-user will experience it as non-functioning. We can do worse as Marcus remembered (and actually we once managed to completely break styles in an Italian release candidate by translating Header and Heading with the same Italian word), but that was not my point. I meant that any damage a translation can do is self-contained: adding a translation will not pose any risk to the English (or other) version of OpenOffice (in other words: I can update the Danish language resources, rebuild and be sure that this does not introduce bugs in the English version). As for testing translations, this goes without saying: for sure we want to distribute only languages that have been tested. We used to have acceptance tests that every N-L team would run on the localized build to give green light for its distribution. The release voting is now different, but I would still expect that we test every language at least at a very basic level. release cycle of quarterly releases (every 3 or 4 months)? This could be a solution too. In this case we would have the problem of choosing what to translate - I think it would be nice to give translators an early start possibility, giving them a choice of working late after freeze or taking parts now with the risk that new messages are added. OK, from this and other comments it seems that the cleanest solution would be to establish a translation deadline (say, near the end of November, but this is purely hypothetical), incorporate all available translations and make a build available a few days later, give one week (or whatever appropriate) for feedback, then release a 3.4.2 with the standard process upon positive feedback. This would avoid creative solutions like publishing patched sources or working around the Apache release process. The 3.4.2 would of course be released from the AOO34 branch, with the new language resources and maybe a few cherry-picked bugfixes. Regards, Andrea.
Re: [RELEASE] Releasing new languages for 3.4.1
On Fri, Oct 26, 2012 at 3:07 AM, Andrea Pescetti pesce...@apache.org wrote: It is now clear that, thanks to new volunteers now coordinating on ooo-l10n, we will soon be in a position to add 3-5 new languages to Apache OpenOffice. It is also clear that at the moment we have no demand for a 3.4.2 with critical bugfixes because... well, 3.4.1 does not have critical bugs. And releasing 3.4.2 only to add new languages seems definitely overkill: 80% of the work would be wasted, we would need a new vote and so on. So, what's the best way to get those new languages released? A few options: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages 3) wait until next planned release (or unplanned release if we find we need a 3.4.2) Can we really skip the release process? PO files == source, right? Maybe it is not C++ code, but it is something like source resources. Maybe a question for legal-discuss if we're not certain. However in options 1 or 2 maybe we can do something lightweight, like release a source package of only the new PO files, or even a diff that can be applied to the base 3.4.1 source package? Another thing to consider is that we could very easily get another 5 languages next month. Once we get the volunteer program up and running, and promote it, I expect these will come in at a rapid pace. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. But if a programmer adds a new feature to the trunk they still need to wait several months for it to be released. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? That way we never need to wait very long to release new features or translations or bug fixes. -Rob Would a checkout of the 3.4.1 tag, where we replace the language files for those 3-5 languages and then build, work as an interim solution? I honestly don't like it very much (it's of course better than committing to a tag, but still not clean), but it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). Any better solutions? Wait for the moment when a 3.4.2 is needed? Picking some bugfixes and forcing a 3.4.2 soon? Regards, Andrea.
Re: [RELEASE] Releasing new languages for 3.4.1
Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). Regards, Andrea.
Re: [RELEASE] Releasing new languages for 3.4.1
just two small comments. have a nice weekend. Jan. On 26 October 2012 19:43, Andrea Pescetti pesce...@apache.org wrote: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. I do not agree to that statement for two reasons - a bad translations will influence the reputation of AOO in that language zone. - Wrong translation of e.g. accelerators, might not break the product technically speaking, but for sure the end-user will experience it as non-functioning. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). - I think it would be nice to give translators an early start possibility, giving them a choice of working late after freeze or taking parts now with the risk that new messages are added. In my experience the risk for changed messages are relatively low. Regards, Andrea.
Re: [RELEASE] Releasing new languages for 3.4.1
Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). In any case we should continue to release new languages; regardless if major or point versions. Marcus
Re: [RELEASE] Releasing new languages for 3.4.1
On 26 October 2012 23:06, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? +1 to a relatively fixed time frame for new releases. Not only developers benefit from that but also end-users ! However do we have the logistic in place to handle ideas/request/bug fixes with these short intervals. It would mean (in my opinion) that we have an open catalog (new development) for 2-3 releases and have to prioritize within a limited timeframe what goes where ? We should also consider to apply a field in bugzilla, targeted for version. I really like the idea, but it has a tendency of killing long term developments, because they are hard to put into this framework, so we need something in the middle. This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). In any case we should continue to release new languages; regardless if major or point versions. Marcus
Re: [RELEASE] Releasing new languages for 3.4.1
On Fri, Oct 26, 2012 at 5:06 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. Certainly the risk is reduced. But there are two areas: 1) Risk of defects caused by interaction between the core product and the translated strings 2) Risk of a bad build, for whatever reason, say due to change in a system library, leading to an undetected new defect. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? Did you do betas for all releases? Or only major ones? Or was this a case-by-case decision? We have the ability to do betas if we want. From an Apache perspective they would still be releases, but we could set the right expectations with users. For example, we wouldn't send update notifications for beta releases. This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). In any case we should continue to release new languages; regardless if major or point versions. Marcus
Re: [RELEASE] Releasing new languages for 3.4.1
Am 10/26/2012 11:20 PM, schrieb jan iversen: On 26 October 2012 23:06, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? +1 to a relatively fixed time frame for new releases. Not only developers benefit from that but also end-users ! Right However do we have the logistic in place to handle ideas/request/bug fixes with these short intervals. It would mean (in my opinion) that we have an OK, maybe the following fitts better to our current situation. Every 6 months a new major release and a point release on demand - enough new languages, urgent/severe bugfixes; that means outside a regular release plan. open catalog (new development) for 2-3 releases and have to prioritize within a limited timeframe what goes where ? We should also consider to apply a field in bugzilla, targeted for version. That's already existing. Just look for the Target Milestone field. I really like the idea, but it has a tendency of killing long term developments, because they are hard to put into this framework, so we need something in the middle. When we plan which new and planned feature goes into what release should work. Marcus This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). In any case we should continue to release new languages; regardless if major or point versions. Marcus
Re: [RELEASE] Releasing new languages for 3.4.1
On 26 October 2012 23:38, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 10/26/2012 11:20 PM, schrieb jan iversen: On 26 October 2012 23:06, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? +1 to a relatively fixed time frame for new releases. Not only developers benefit from that but also end-users ! Right However do we have the logistic in place to handle ideas/request/bug fixes with these short intervals. It would mean (in my opinion) that we have an OK, maybe the following fitts better to our current situation. Every 6 months a new major release and a point release on demand - enough new languages, urgent/severe bugfixes; that means outside a regular release plan. +1 open catalog (new development) for 2-3 releases and have to prioritize within a limited timeframe what goes where ? We should also consider to apply a field in bugzilla, targeted for version. That's already existing. Just look for the Target Milestone field. I think it is not really used (I might be wrong) but with frequent releases we should use it intensively, because today those who submit a bug must be pretty disappointed, I looked at a bug the other day, dated 2007 which are still a bug. I really like the idea, but it has a tendency of killing long term developments, because they are hard to put into this framework, so we need something in the middle. When we plan which new and planned feature goes into what release should work. I think I did not express it correctly, resources tend to be used for short term targets (next release, high motivation, lets make it folks, and after that we do all the rest). Marcus This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). In any case we should continue to release new languages;
Re: [RELEASE] Releasing new languages for 3.4.1
Am 10/26/2012 11:35 PM, schrieb Rob Weir: On Fri, Oct 26, 2012 at 5:06 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. Certainly the risk is reduced. But there are two areas: 1) Risk of defects caused by interaction between the core product and the translated strings 2) Risk of a bad build, for whatever reason, say due to change in a system library, leading to an undetected new defect. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? Did you do betas for all releases? Or only major ones? Or was this a case-by-case decision? Always for big major releases, here in a really public way (with announcements, etc.) and full blown install files. But also here and there also for chosen releases with en-US full install + langpacks. I think everybody remembers the last one - OOo 3.4.0. ;-) We have the ability to do betas if we want. From an Apache perspective they would still be releases, but we could set the right expectations with users. For example, we wouldn't send update notifications for beta releases. Right. And looking into my crystal ball, I predict that AOO 4.0 will start with a beta release. Marcus This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). In any case we should continue to release new languages; regardless if major or point versions. Marcus
Re: [RELEASE] Releasing new languages for 3.4.1
Am 10/26/2012 11:46 PM, schrieb jan iversen: On 26 October 2012 23:38, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/26/2012 11:20 PM, schrieb jan iversen: On 26 October 2012 23:06, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? +1 to a relatively fixed time frame for new releases. Not only developers benefit from that but also end-users ! Right However do we have the logistic in place to handle ideas/request/bug fixes with these short intervals. It would mean (in my opinion) that we have an OK, maybe the following fitts better to our current situation. Every 6 months a new major release and a point release on demand - enough new languages, urgent/severe bugfixes; that means outside a regular release plan. +1 open catalog (new development) for 2-3 releases and have to prioritize within a limited timeframe what goes where ? We should also consider to apply a field in bugzilla, targeted for version. That's already existing. Just look for the Target Milestone field. I think it is not really used (I might be wrong) but with frequent releases we should use it intensively, because today those who submit a bug must be pretty disappointed, I looked at a bug the other day, dated 2007 which are still a bug. Ah, now I get it. This problem comes from the migration from the old OOo's Issuezilla to Apache's Bugzilla. Here the old field disappeared and the information was not shown in Bugzilla. The field you see now was added afterwards and has to be filled newly. Marcus I really like the idea, but it has a tendency of killing long term developments, because they are hard to put into this framework, so we need something in the middle. When we plan which new and planned feature goes into what release should work. I think I did not express it correctly, resources tend to be used for short term targets (next release, high motivation, lets make it folks, and after that we do all the rest). Marcus This could
Re: [RELEASE] Releasing new languages for 3.4.1
On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
+1, being a non-native english speakng person, I want to ensure that we keep the AOO stability in language versions and not just see them as nice to have add-on !! jan On 27 October 2012 01:48, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. -Rob Regards, Dave
