incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Release Apache OpenOffice 3.4 (incubating) RC1
Date Tue, 24 Apr 2012 16:54:22 GMT

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


> -Rob
>> Herbert

View raw message