You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Risto Jääskeläinen <rj...@saunalahti.fi> on 2012/04/24 16:55:30 UTC
Re: Release Apache OpenOffice 3.4 (incubating) RC1
See: Thread: Fix for bug 116639 almost
Yong Lin Ma [mayongl@gmail.com] kirjoitti:
> 2012/4/24 Risto Jääskeläinen <rj...@saunalahti.fi>:
> > -1 (nobody)
> > For Finnish package only.
> > Reason:
> > http://www.saunalahti.fi/rjaaskel/Kuvat/Tulostaikkuna.jpg
> > Print dialog/window is working but it is so wide that it needs two screen
> > (over 2000 pixel).
> > So if Finnish is dropped out now and published with next minor version if
> > there is possible integrate newest translations then? Bug is fixed in
> > Pootle but correct translation is not yet in publshed package.
> > I am sorry if this is not correct way of voting
>
> Could you also try English version in your environment? This may not
> be a Finnish specific issue.
>
> >
> > Regards
> > Risto
> > Jürgen Schmidt [jogischmidt@googlemail.com] kirjoitti:
> >>
> >> Hi all,
> >>
> >> this is a call for vote on releasing the following candidate as Apache
> >> OpenOffice 3.4 (incubating). This will be the first incubator release for
> >> Apache OpenOffice and a key milestone to continue the success of
> >> OpenOffice.org.
> >>
> >>
> >> This release candidate provides the following important key changes
> >> compared to former OpenOffice releases:
> >> (1) Code clean up to remove all copyleft components and external
> >> dependencies
> >> (2) Reworked or introduced LICENSE and NOTICE file to reflect and document
> >> the used licenses of the code itself as well as of external 3rd party
> >> libraries
> >> (3) MD5, SHA1, SHA512 hashes and GPG signatures for all of artifacts
> >>
> >> For a detailed feature overview please see the release notes under
> >> https://cwiki.apache.org/OOOUSERS/aoo-34-release-notes.html.
> >>
> >> The release candidate artifacts (source release, as well as binary
> >> releases for 16 languages) and further information how to verify and review
> >> Apache OpenOffice 3.4 (incubating) can be found on the following wiki page:
> >>
> >>
> >> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+%28incubating%29+Release+Candidate
> >>
> >>
> >> Please vote on releasing this package as Apache OpenOffice 3.4
> >> (incubating).
> >>
> >> The vote starts now and will be open until:
> >>
> >> UTC midnight Wednesday, 25 April: 2012-04-25 24:00 UTC.
> >>
> >> After the vote of the PPMC the vote will start on
> >> general@incubtor.apache.org mailing and will be open for further 72 hours.
> >> But we invite all people to vote (non binding) on this RC. We would like
> >> to provide a release that is supported by the majority of our project
> >> members.
> >>
> >> [ ] +1 Release this package as Apache OpenOffice 3.4 (incubating)
> >> [ ] 0 Don't care
> >> [ ] -1 Do not release this package because...
> >>
> >>
> >
>
Re: Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 4/25/12 12:54 AM, Dave Fisher wrote:
>
> On Apr 24, 2012, at 9:30 AM, Rob Weir wrote:
>
>> On Tue, Apr 24, 2012 at 12:02 PM, Herbert Duerr<hd...@apache.org> wrote:
>>> On 24.04.2012 16:55, Risto Jääskeläinen wrote:
>>>>
>>>> See: Thread: Fix for bug 116639 almost
>>>
>>>
>>> I don't think that 116639 was the root cause. Looking at the problematic
>>> string in the screenshot you provided at
>>> http://www.saunalahti.fi/rjaaskel/Kuvat/Tulostaikkuna.jpg
>>> the reason was simply a strange translation of what is named "Comments",
>>> "Kommentare", "Comentarios", "Commenti", etc. in other languages.
>>>
>>> In the Finnish localization as of AOO340_rc1 it reads:
>>> "Kun tämä valinta on tehty, ohjelman lisäämät tyhjät sivut tulostetaan. Tämä
>>> on tarpeen, kun tulostetaan kaksipuoleisesti. Esimerkiksi kirjassa
>>> \"luku\"-kappaletyyli on määritelty alkavaksi aina parittomalta sivulta. Jos
>>> edellinen luku päättyy parittomalle sivulle, %PRODUCTNAME lisää parillisen
>>> tyhjän sivun. Tämä valinta ohjaa mainitun parillisen sivun tulostusta."
>>> which is defined in the "STR_PRINTOPTUI 18" line of
>>> https://svn.apache.org/repos/asf/incubator/ooo/trunk/extras/l10n/source/fi/localize.sdf
>>> Getting such a long string into a poor little dialog is does of course cause
>>> some trouble.
>>>
>>>>>> [...] Bug is fixed in
>>>>>>
>>>>>> Pootle but correct translation is not yet in publshed package.
>>>
>>>
>>> The other translations for the other STR_PRINTOPTUI lines in the finnish
>>> localize.sdf were also a bit long. Have they been fixed too?
>>>
>>>
>>>>>> I am sorry if this is not correct way of voting
>>>
>>> I'd like to extend that question by asking (e.g. the mentors) if it should
>>> be possible to split the voting in such situations, so that e.g. individual
>>> localization could vote for a different revision? Is a staggered release
>>> process allowed?
>>>
>>> Otherwise there would be a inherent scalability problem in the release
>>> process of such a huge multi-platform and multi-language application
>>> targeted at end users: if one problematic localization could reset the work
>>> of everyone else then this would be a recipe for a lot of frustration, as
>>> building, distributing, announcing and especially testing of a new revision
>>> is a huge effort and a lot of people are involved.
>>>
>>
>>
>> I think we can handle this efficiently. But we would need to take
>> some precautions. Start with making a branch of RC1 in SVN, if RC1 is
>> approved. If we then want to update a single language or a single
>> platform, then we can make those changes in the branch.
>
> Or RC2. A branch this big will require coordination with Infra.
we will need a branch anyway to have a code line for bugfixes etc. based
on the release and the main trunk to continue the development to the
next release.
Juergen
>
>> I think we would still require a release vote for any additional files
>> we publish, such as updated translations, etc. So the same 72-hour
>> voting process.
>
> Makes sense to me.
>
>> But I don't think it would require that the IPMC do an in-depth review
>> of the entire release, and it should not be necessary for us to do a
>> complete regression test. I'd hope the IPMC would be satisfied to
>> look at the SVN logs and see that only translations had been changed,
>> and that would be enough to justify their approval.
>
> Before we hope, let's get through a release with IPMC approval.
>
> Depending on how we do, a push for graduation makes sense. In that case our PMC votes will be enough.
>
> Regards,
> Dave
>
>
>
>>
>> -Rob
>>
>>> Herbert
>
Re: Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Joe Schaefer <jo...@yahoo.com>.
Branches/tags are just server-side copies, which
are O(1). Not a big deal for us- it's the merges
that can be painful.
>________________________________
> From: Dave Fisher <da...@comcast.net>
>To: ooo-dev@incubator.apache.org
>Sent: Tuesday, April 24, 2012 12:54 PM
>Subject: Re: Release Apache OpenOffice 3.4 (incubating) RC1
>
>
>On Apr 24, 2012, at 9:30 AM, Rob Weir wrote:
>
>> On Tue, Apr 24, 2012 at 12:02 PM, Herbert Duerr <hd...@apache.org> wrote:
>>> On 24.04.2012 16:55, Risto Jääskeläinen wrote:
>>>>
>>>> See: Thread: Fix for bug 116639 almost
>>>
>>>
>>> I don't think that 116639 was the root cause. Looking at the problematic
>>> string in the screenshot you provided at
>>> http://www.saunalahti.fi/rjaaskel/Kuvat/Tulostaikkuna.jpg
>>> the reason was simply a strange translation of what is named "Comments",
>>> "Kommentare", "Comentarios", "Commenti", etc. in other languages.
>>>
>>> In the Finnish localization as of AOO340_rc1 it reads:
>>> "Kun tämä valinta on tehty, ohjelman lisäämät tyhjät sivut tulostetaan. Tämä
>>> on tarpeen, kun tulostetaan kaksipuoleisesti. Esimerkiksi kirjassa
>>> \"luku\"-kappaletyyli on määritelty alkavaksi aina parittomalta sivulta. Jos
>>> edellinen luku päättyy parittomalle sivulle, %PRODUCTNAME lisää parillisen
>>> tyhjän sivun. Tämä valinta ohjaa mainitun parillisen sivun tulostusta."
>>> which is defined in the "STR_PRINTOPTUI 18" line of
>>> https://svn.apache.org/repos/asf/incubator/ooo/trunk/extras/l10n/source/fi/localize.sdf
>>> Getting such a long string into a poor little dialog is does of course cause
>>> some trouble.
>>>
>>>>>> [...] Bug is fixed in
>>>>>>
>>>>>> Pootle but correct translation is not yet in publshed package.
>>>
>>>
>>> The other translations for the other STR_PRINTOPTUI lines in the finnish
>>> localize.sdf were also a bit long. Have they been fixed too?
>>>
>>>
>>>>>> I am sorry if this is not correct way of voting
>>>
>>> I'd like to extend that question by asking (e.g. the mentors) if it should
>>> be possible to split the voting in such situations, so that e.g. individual
>>> localization could vote for a different revision? Is a staggered release
>>> process allowed?
>>>
>>> Otherwise there would be a inherent scalability problem in the release
>>> process of such a huge multi-platform and multi-language application
>>> targeted at end users: if one problematic localization could reset the work
>>> of everyone else then this would be a recipe for a lot of frustration, as
>>> building, distributing, announcing and especially testing of a new revision
>>> is a huge effort and a lot of people are involved.
>>>
>>
>>
>> I think we can handle this efficiently. But we would need to take
>> some precautions. Start with making a branch of RC1 in SVN, if RC1 is
>> approved. If we then want to update a single language or a single
>> platform, then we can make those changes in the branch.
>
>Or RC2. A branch this big will require coordination with Infra.
>
>> I think we would still require a release vote for any additional files
>> we publish, such as updated translations, etc. So the same 72-hour
>> voting process.
>
>Makes sense to me.
>
>> But I don't think it would require that the IPMC do an in-depth review
>> of the entire release, and it should not be necessary for us to do a
>> complete regression test. I'd hope the IPMC would be satisfied to
>> look at the SVN logs and see that only translations had been changed,
>> and that would be enough to justify their approval.
>
>Before we hope, let's get through a release with IPMC approval.
>
>Depending on how we do, a push for graduation makes sense. In that case our PMC votes will be enough.
>
>Regards,
>Dave
>
>
>
>>
>> -Rob
>>
>>> Herbert
>
>
>
>
Re: Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Dave Fisher <da...@comcast.net>.
On Apr 24, 2012, at 9:30 AM, Rob Weir wrote:
> On Tue, Apr 24, 2012 at 12:02 PM, Herbert Duerr <hd...@apache.org> wrote:
>> On 24.04.2012 16:55, Risto Jääskeläinen wrote:
>>>
>>> See: Thread: Fix for bug 116639 almost
>>
>>
>> I don't think that 116639 was the root cause. Looking at the problematic
>> string in the screenshot you provided at
>> http://www.saunalahti.fi/rjaaskel/Kuvat/Tulostaikkuna.jpg
>> the reason was simply a strange translation of what is named "Comments",
>> "Kommentare", "Comentarios", "Commenti", etc. in other languages.
>>
>> In the Finnish localization as of AOO340_rc1 it reads:
>> "Kun tämä valinta on tehty, ohjelman lisäämät tyhjät sivut tulostetaan. Tämä
>> on tarpeen, kun tulostetaan kaksipuoleisesti. Esimerkiksi kirjassa
>> \"luku\"-kappaletyyli on määritelty alkavaksi aina parittomalta sivulta. Jos
>> edellinen luku päättyy parittomalle sivulle, %PRODUCTNAME lisää parillisen
>> tyhjän sivun. Tämä valinta ohjaa mainitun parillisen sivun tulostusta."
>> which is defined in the "STR_PRINTOPTUI 18" line of
>> https://svn.apache.org/repos/asf/incubator/ooo/trunk/extras/l10n/source/fi/localize.sdf
>> Getting such a long string into a poor little dialog is does of course cause
>> some trouble.
>>
>>>>> [...] Bug is fixed in
>>>>>
>>>>> Pootle but correct translation is not yet in publshed package.
>>
>>
>> The other translations for the other STR_PRINTOPTUI lines in the finnish
>> localize.sdf were also a bit long. Have they been fixed too?
>>
>>
>>>>> I am sorry if this is not correct way of voting
>>
>> I'd like to extend that question by asking (e.g. the mentors) if it should
>> be possible to split the voting in such situations, so that e.g. individual
>> localization could vote for a different revision? Is a staggered release
>> process allowed?
>>
>> Otherwise there would be a inherent scalability problem in the release
>> process of such a huge multi-platform and multi-language application
>> targeted at end users: if one problematic localization could reset the work
>> of everyone else then this would be a recipe for a lot of frustration, as
>> building, distributing, announcing and especially testing of a new revision
>> is a huge effort and a lot of people are involved.
>>
>
>
> I think we can handle this efficiently. But we would need to take
> some precautions. Start with making a branch of RC1 in SVN, if RC1 is
> approved. If we then want to update a single language or a single
> platform, then we can make those changes in the branch.
Or RC2. A branch this big will require coordination with Infra.
> I think we would still require a release vote for any additional files
> we publish, such as updated translations, etc. So the same 72-hour
> voting process.
Makes sense to me.
> But I don't think it would require that the IPMC do an in-depth review
> of the entire release, and it should not be necessary for us to do a
> complete regression test. I'd hope the IPMC would be satisfied to
> look at the SVN logs and see that only translations had been changed,
> and that would be enough to justify their approval.
Before we hope, let's get through a release with IPMC approval.
Depending on how we do, a push for graduation makes sense. In that case our PMC votes will be enough.
Regards,
Dave
>
> -Rob
>
>> Herbert
Re: Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Rob Weir <ro...@apache.org>.
On Tue, Apr 24, 2012 at 12:02 PM, Herbert Duerr <hd...@apache.org> wrote:
> On 24.04.2012 16:55, Risto Jääskeläinen wrote:
>>
>> See: Thread: Fix for bug 116639 almost
>
>
> I don't think that 116639 was the root cause. Looking at the problematic
> string in the screenshot you provided at
> http://www.saunalahti.fi/rjaaskel/Kuvat/Tulostaikkuna.jpg
> the reason was simply a strange translation of what is named "Comments",
> "Kommentare", "Comentarios", "Commenti", etc. in other languages.
>
> In the Finnish localization as of AOO340_rc1 it reads:
> "Kun tämä valinta on tehty, ohjelman lisäämät tyhjät sivut tulostetaan. Tämä
> on tarpeen, kun tulostetaan kaksipuoleisesti. Esimerkiksi kirjassa
> \"luku\"-kappaletyyli on määritelty alkavaksi aina parittomalta sivulta. Jos
> edellinen luku päättyy parittomalle sivulle, %PRODUCTNAME lisää parillisen
> tyhjän sivun. Tämä valinta ohjaa mainitun parillisen sivun tulostusta."
> which is defined in the "STR_PRINTOPTUI 18" line of
> https://svn.apache.org/repos/asf/incubator/ooo/trunk/extras/l10n/source/fi/localize.sdf
> Getting such a long string into a poor little dialog is does of course cause
> some trouble.
>
>>>> [...] Bug is fixed in
>>>>
>>>> Pootle but correct translation is not yet in publshed package.
>
>
> The other translations for the other STR_PRINTOPTUI lines in the finnish
> localize.sdf were also a bit long. Have they been fixed too?
>
>
>>>> I am sorry if this is not correct way of voting
>
> I'd like to extend that question by asking (e.g. the mentors) if it should
> be possible to split the voting in such situations, so that e.g. individual
> localization could vote for a different revision? Is a staggered release
> process allowed?
>
> Otherwise there would be a inherent scalability problem in the release
> process of such a huge multi-platform and multi-language application
> targeted at end users: if one problematic localization could reset the work
> of everyone else then this would be a recipe for a lot of frustration, as
> building, distributing, announcing and especially testing of a new revision
> is a huge effort and a lot of people are involved.
>
I think we can handle this efficiently. But we would need to take
some precautions. Start with making a branch of RC1 in SVN, if RC1 is
approved. If we then want to update a single language or a single
platform, then we can make those changes in the branch.
I think we would still require a release vote for any additional files
we publish, such as updated translations, etc. So the same 72-hour
voting process.
But I don't think it would require that the IPMC do an in-depth review
of the entire release, and it should not be necessary for us to do a
complete regression test. I'd hope the IPMC would be satisfied to
look at the SVN logs and see that only translations had been changed,
and that would be enough to justify their approval.
-Rob
> Herbert
Re: Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 4/25/12 12:02 AM, Herbert Duerr wrote:
> On 24.04.2012 16:55, Risto Jääskeläinen wrote:
>> See: Thread: Fix for bug 116639 almost
>
> I don't think that 116639 was the root cause. Looking at the problematic
> string in the screenshot you provided at
> http://www.saunalahti.fi/rjaaskel/Kuvat/Tulostaikkuna.jpg
> the reason was simply a strange translation of what is named "Comments",
> "Kommentare", "Comentarios", "Commenti", etc. in other languages.
>
> In the Finnish localization as of AOO340_rc1 it reads:
> "Kun tämä valinta on tehty, ohjelman lisäämät tyhjät sivut tulostetaan.
> Tämä on tarpeen, kun tulostetaan kaksipuoleisesti. Esimerkiksi kirjassa
> \"luku\"-kappaletyyli on määritelty alkavaksi aina parittomalta sivulta.
> Jos edellinen luku päättyy parittomalle sivulle, %PRODUCTNAME lisää
> parillisen tyhjän sivun. Tämä valinta ohjaa mainitun parillisen sivun
> tulostusta."
> which is defined in the "STR_PRINTOPTUI 18" line of
> https://svn.apache.org/repos/asf/incubator/ooo/trunk/extras/l10n/source/fi/localize.sdf
>
> Getting such a long string into a poor little dialog is does of course
> cause some trouble.
>
>>>> [...] Bug is fixed in
>>>> Pootle but correct translation is not yet in publshed package.
>
> The other translations for the other STR_PRINTOPTUI lines in the finnish
> localize.sdf were also a bit long. Have they been fixed too?
>
> >>> I am sorry if this is not correct way of voting
>
> I'd like to extend that question by asking (e.g. the mentors) if it
> should be possible to split the voting in such situations, so that e.g.
> individual localization could vote for a different revision? Is a
> staggered release process allowed?
>
> Otherwise there would be a inherent scalability problem in the release
> process of such a huge multi-platform and multi-language application
> targeted at end users: if one problematic localization could reset the
> work of everyone else then this would be a recipe for a lot of
> frustration, as building, distributing, announcing and especially
> testing of a new revision is a huge effort and a lot of people are
> involved.
I agree in general and it would be good to have more flexibility here.
But in this case we will simply not release Finnish and will move it in
the next micro release.
It was somewhat special for this release because we have underestimate
the effort around the pootle server because the lack of knowledge and
too many other things to do.
Juergen
Re: Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Herbert Duerr <hd...@apache.org>.
On 24.04.2012 16:55, Risto Jääskeläinen wrote:
> See: Thread: Fix for bug 116639 almost
I don't think that 116639 was the root cause. Looking at the problematic
string in the screenshot you provided at
http://www.saunalahti.fi/rjaaskel/Kuvat/Tulostaikkuna.jpg
the reason was simply a strange translation of what is named "Comments",
"Kommentare", "Comentarios", "Commenti", etc. in other languages.
In the Finnish localization as of AOO340_rc1 it reads:
"Kun tämä valinta on tehty, ohjelman lisäämät tyhjät sivut tulostetaan.
Tämä on tarpeen, kun tulostetaan kaksipuoleisesti. Esimerkiksi kirjassa
\"luku\"-kappaletyyli on määritelty alkavaksi aina parittomalta sivulta.
Jos edellinen luku päättyy parittomalle sivulle, %PRODUCTNAME lisää
parillisen tyhjän sivun. Tämä valinta ohjaa mainitun parillisen sivun
tulostusta."
which is defined in the "STR_PRINTOPTUI 18" line of
https://svn.apache.org/repos/asf/incubator/ooo/trunk/extras/l10n/source/fi/localize.sdf
Getting such a long string into a poor little dialog is does of course
cause some trouble.
>>> [...] Bug is fixed in
>>> Pootle but correct translation is not yet in publshed package.
The other translations for the other STR_PRINTOPTUI lines in the finnish
localize.sdf were also a bit long. Have they been fixed too?
>>> I am sorry if this is not correct way of voting
I'd like to extend that question by asking (e.g. the mentors) if it
should be possible to split the voting in such situations, so that e.g.
individual localization could vote for a different revision? Is a
staggered release process allowed?
Otherwise there would be a inherent scalability problem in the release
process of such a huge multi-platform and multi-language application
targeted at end users: if one problematic localization could reset the
work of everyone else then this would be a recipe for a lot of
frustration, as building, distributing, announcing and especially
testing of a new revision is a huge effort and a lot of people are involved.
Herbert