1.2 branching

[Aki Sasaki]

Hi all,

Per Tuesday's cross-functional meeting, it seems we want to branch all
b2g repos that we control for 1.2.

Open questions:

1. If we branch all the below repos now, the downside is any changes for
1.2 will need to double-land. The upside is we will have a better idea
of which changes went into which version. We believe this is the right
tradeoff, but we wanted to make it clear that we're making this tradeoff.
1a. Which revision should we branch from? We can choose current
tip-of-master, or look at the built-manifest from the original build
https://tbpl.mozilla.org/?tree=Mozilla-Aurora&rev=6f0f535a5eae and use
those revisions.

2. Do we freeze external repos' revisions in b2g-manifests? For example,
we did this for 1.0.1:
https://github.com/mozilla-b2g/b2g-manifest/blob/v1.0.1/hamachi.xml#L25

3. Here's our plan; does this look correct?

* Branch these repos (at current tip):
b2g/B2G
b2g/Negatus
b2g/android-development
b2g/android-device-crespo
b2g/android-device-crespo4g
b2g/android-device-galaxys2
b2g/android-device-hamachi
b2g/android-device-m4
b2g/android-device-maguro
b2g/android-device-otoro
b2g/android-device-panda
b2g/android-device-tuna
b2g/android-device-unagi
b2g/android-sdk
b2g/b2g-manifest (already branched)
b2g/codeaurora_kernel_msm
b2g/device-helix
b2g/device-inari
b2g/device-leo
b2g/device-mako
b2g/device_generic_goldfish
b2g/fake-dalvik
b2g/fake-libdvm
b2g/gaia-ui-tests
b2g/gonk-misc
b2g/gonk-patches
b2g/hardware_qcom_display
b2g/librecovery
b2g/moztt
b2g/orangutan
b2g/platform_build
releases/gaia (already branched)
releases/gecko (already branched)

* Update all 1.2 manifests to point at the 1.2 branch of the above
repos, e.g.
https://github.com/mozilla-b2g/b2g-manifest/blob/v1.2/hamachi.xml#L23

* Potentially freeze the revision of each of the external repos, as we
did for 1.0.1 here:
https://github.com/mozilla-b2g/b2g-manifest/blob/v1.0.1/hamachi.xml#L25

[Alex Keybl]

> 1. If we branch all the below repos now, the downside is any changes for
> 1.2 will need to double-land. The upside is we will have a better idea
> of which changes went into which version. We believe this is the right
> tradeoff, but we wanted to make it clear that we're making this tradeoff.

Is there anybody not on dev.b2g that we now need to communicate this to to ensure proper landing?

-Alex

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

[Aki Sasaki]

On 9/18/13 1:10 PM, Alex Keybl wrote:
>> 1. If we branch all the below repos now, the downside is any changes for
>> 1.2 will need to double-land. The upside is we will have a better idea
>> of which changes went into which version. We believe this is the right
>> tradeoff, but we wanted to make it clear that we're making this tradeoff.
>
> Is there anybody not on dev.b2g that we now need to communicate this to to ensure proper landing?

I don't know how to answer this, but if there's a larger or
more-appropriate distribution list, or other way to reach everyone who
would ever commit to a b2g repository, I can cc them.

aki

[Aki Sasaki]

On 9/18/13 1:10 PM, Alex Keybl wrote:

>> 1. If we branch all the below repos now, the downside is any changes for
>> 1.2 will need to double-land. The upside is we will have a better idea
>> of which changes went into which version. We believe this is the right
>> tradeoff, but we wanted to make it clear that we're making this tradeoff.
>
> Is there anybody not on dev.b2g that we now need to communicate this to to ensure proper landing?

I don't know how to answer this, but if there's a larger or
more-appropriate distribution list, or other way to reach everyone who
would ever commit to a b2g repository, I can cc them.

aki

>

[Alex Keybl]

More of a general question, for those dealing with the long tail of repos here.

-Alex

On Sep 18, 2013, at 4:20 PM, Aki Sasaki <a...@mozilla.com> wrote:

> On 9/18/13 1:10 PM, Alex Keybl wrote:

>>> 1. If we branch all the below repos now, the downside is any changes for
>>> 1.2 will need to double-land. The upside is we will have a better idea
>>> of which changes went into which version. We believe this is the right
>>> tradeoff, but we wanted to make it clear that we're making this tradeoff.
>>
>> Is there anybody not on dev.b2g that we now need to communicate this to to ensure proper landing?
>

> I don't know how to answer this, but if there's a larger or
> more-appropriate distribution list, or other way to reach everyone who
> would ever commit to a b2g repository, I can cc them.
>
> aki
>
>>

[Julien Wajsberg]

Le 18/09/2013 21:50, Aki Sasaki a écrit :
> Hi all,
>
> Per Tuesday's cross-functional meeting, it seems we want to branch all
> b2g repos that we control for 1.2.
>
> Open questions:
>
> 1. If we branch all the below repos now, the downside is any changes for
> 1.2 will need to double-land. The upside is we will have a better idea
> of which changes went into which version. We believe this is the right
> tradeoff, but we wanted to make it clear that we're making this tradeoff.
> 1a. Which revision should we branch from? We can choose current
> tip-of-master, or look at the built-manifest from the original build
> https://tbpl.mozilla.org/?tree=Mozilla-Aurora&rev=6f0f535a5eae and use
> those revisions.

Open question too: was it considered to have a a "1-week buffer" where
only koi+ bugs could land on master, and branch only at the end of this
week ? I'd say: let's see if the double land is painful for this
version, and maybe let's consider this for next version ?

--
Julien

[Alex Keybl]

We defaulted to a single branch day this time, but we remain flexible for future merges. May end up being a good idea depending on the number of Gaia uplifts this week.

-Alex