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 <[email protected]> >To: [email protected] >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 <[email protected]> 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 > > > >
