Branching for stabilization

[Rob Weir <ro...@apache.org>]

Renaming to make this subthread more obvious

On Fri, Mar 16, 2012 at 12:15 PM, Jürgen Schmidt
<jo...@googlemail.com> wrote:
> On 3/16/12 4:26 PM, Pedro Giffuni wrote:
>>
>> On 03/16/12 10:03, Rob Weir wrote:
>>>
>>>
>>>> FWIW,
>>>>
>>>> I suspended some rather cool but drastic updates
>>>> that I was planning, including updating the internal
>>>> python and Apache Commons, to ensure a softer
>>>> landing of the release. Expect a lot of chaos
>>>> afterwards ;).
>>>>
>>> Would it help if we "branched for stabilization" at some point?
>>
>>
>> That's an interesting issue. I do think we should start defining
>> some branching scheme, especially to setup a procedure
>> for future releases.
>>
>> I would think after a Release Candidate is the best time, but
>> there is no hurry.
>
>
> exactly, and that will hopefully happen next week ;-)
>
> At the moment we have only one serious issue
>
> Bug 118895 - aoo3.4 r1240836: some contextmenu entries are not localized
>
> It sounds not a big issue but with my pootle/translation tests I updated the
> relevant strings and thought it would be fixed. Unfortunately it's not and
> it either depends on a build/dependency problem (I am currently building it
> again) or we have potentially a serious problem. Some resource strings were
> moved and maybe we have a problem here.
>
> But anyway if we have a general problem here with the localized strings I
> tend to prepare a RC for en-US only. I think it would make sense to start it
> next week to collect the necessary feedback if we are Apache conform or if
> we have further open issues here.
>
> The localization issue would be addressed next week together with finally
> setup the pootle server with up-to-date data etc. and hopefully integrating
> some returned localizations.
>
> I tested fro example the returned pt-BR and it looks good so far ...
>
> What do others think about this proposed approach?
>

It would be good to know we are with things before branching:

1) Copyright/header updates in source files

2) Rat scans

If we branch and then find out that we have 10,000 more files to
update, then it will be annoying to make these updates in both branch
and trunk.

-Rob

> Juergen
>
>
>
>>
>>> But if we did, where do we point the buildbots: 3.4 branch or trunk?
>>
>>
>> No direct commits should be done on the 3.4 branch: all the
>> commits should go to trunk first and then merged to the
>> branch after some testing period.
>>
>> Since it's desirable to detect breakage before merging anything,
>> we would keep pointing the buildbots to the trunk. Defining where
>> the binary packages for the release are created is another issue,
>> specially since we will be bundling some dictionaries
>>
>> Pedro.
>>
>