incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
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<hdu@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
>


Mime
View raw message