incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: Release Apache OpenOffice 3.4 (incubating) RC1
Date Tue, 24 Apr 2012 23:34:40 GMT
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<>  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
>>> 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.
>>> 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
>>> 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.


>> 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

View raw message