> How many builds are we going to have? A nightly build, shira build, v1train 
> build, and a leo build?
QA should be engaged on v1.0.0 builds until Friday, and nightly v1.0.1 builds 
after that (basically keeping up with v1-train/mozilla-b2g18 on an ongoing 
basis). After Friday, we'll have to request v1.0.0 builds as necessary, which 
means QA testing of v1.0.0 will no longer be daily.
> We regularly were smoke testing builds from master to nightly to ensure no 
> surprises were caught. With the changes           to the build structure, how 
> is our approach changing? Probably something more for our QA team to think 
> about.
Changes should land and get tested on master/mozilla-central prior to being 
uplifted to v1-train/mozilla-b2g18 or v1.x/mozilla-b2g18-relbranch. That should 
prevent major breakage.
> Are we effectively keeping these branches in sync with each other in places 
> where they need to be in sync? The discussions below imply that might not be 
> true, which I think is concerning, as we'll have branch-specific bugs right 
> now that were fixed on a different branch
As long as the landing instructions on the wiki page are honored, the correct 
branches will be uplifted to in 99% of cases. The only part of our tracking 
that's still a bit hairy is what happens when a v1.0.0 bug is fixed later in 
the game - we don't have a great way of tracking that that same change will be 
uplifted to the v1.0.1 branch as well. We're still thinking about that.

-Alex

On Jan 22, 2013, at 11:07 AM, Jason Smith <[email protected]> wrote:

> Okay, so much discussion on this thread now has my brain confused in the QA 
> world. Now here's my questions:
> How many builds are we going to have? A nightly build, shira build, v1train 
> build, and a leo build?
> We regularly were smoke testing builds from master to nightly to ensure no 
> surprises were caught. With the changes           to the build structure, how 
> is our approach changing? Probably something more for our QA team to think 
> about.
> Are we effectively keeping these branches in sync with each other in places 
> where they need to be in sync? The discussions below imply that might not be 
> true, which I think is concerning, as we'll have branch-specific bugs right 
> now that were fixed on a different branch.
> Let's talk more about this at the 5pm meeting.
> Sincerely,
> Jason Smith
> 
> Desktop QA Engineer
> Mozilla Corporation
> https://quality.mozilla.com
> On 1/22/2013 11:03 AM, Alex Keybl wrote:
>>> 1)As tracking-b2g18+ bugs can only land in v1-train and master branches
>>> (no in v1.0.0), do we still need gaia-master-approval for landing them?
>> We're going to be repurposing approval-gaia-master into 
>> approval-gaia-v1train (approval for tracking-b2g18+ bugs) since master is 
>> now v2 and requires no approval.
>> 
>>> 2) What happens with the patches in the UX branch (without tracking-b218+
>>> flag)? Now they are being merged in the master directly.
>> Given the branching plan proposed, you're correct - they would land on 
>> master without any approvals. If you feel it should be uplifted for v1.x, 
>> please nominate for tracking (tracking-b2g18?) and approval 
>> (approval-gaia-v1train?).
>> 
>> -Alex
>> 
>> On Jan 20, 2013, at 4:27 PM, Mª ANGELES OTEO MARTINEZ <[email protected]> wrote:
>> 
>>> Hi,
>>> As Julien explains, I understand the same:
>>> 
>>> tef+ bugs go to v1.0.0, v1-train, master
>>> shira+ bugs go to v1-train, master
>>> leo+ bugs go to master
>>> approved patches (with tracking-b2g18+ flag) go to v1-train, master.
>>> 
>>> A couple of questions:
>>> 
>>> 1)As tracking-b2g18+ bugs can only land in v1-train and master branches
>>> (no in v1.0.0), do we still need gaia-master-approval for landing them?
>>> 
>>> 2) What happens with the patches in the UX branch (without tracking-b218+
>>> flag)? Now they are being merged in the master directly.
>>> 
>>> Best Regards
>>> Maria
>>> 
>>> 
>>> 
>>> El 20/01/13 22:14, "Julien Wajsberg" <[email protected]> escribió:
>>> 
>>>> Hi,
>>>> 
>>>> something is not clear to me.
>>>> 
>>>> Right now, we have the branches "master", "shira", "v1-train", "v1.0.0".
>>>> I understand that "shira" is the old "v1-train" and will eventually
>>>> disappear.
>>>> 
>>>> So, right now, if I understand correctly, for gaia:
>>>> 
>>>> tef+ bugs go to v1.0.0, v1-train, master
>>>> shira+ bugs go to v1-train, master
>>>> leo+ bugs go to master
>>>> approved patches go to v1-train, master
>>>> v1.0.1 will be created out of v1-train.
>>>> 
>>>> What I don't get is about v1.1.0. Will this come from v1-train or from
>>>> master ? will a "new" v1-train be created ? Because otherwise, how
>>>> current changes for v1.1.0 (leo+ bugs) that land to master will
>>>> ultimately go fo v1-train and then v1.1.0 ?
>>>> 
>>>> May I suggest to call current v1-train v1.0.X instead ? This branch will
>>>> lead  to v1.0.1, v1.0.2, etc.
>>>> 
>>>> And then we'll cut a v1.1.X from master later, that will eventually lead
>>>> to v1.1.0, v1.1.1 etc ?
>>>> 
>>>> --
>>>> Julien
>>>> 
>>>> Le 19/01/2013 02:21, Alex Keybl a écrit :
>>>>> [x-post to dev.b2g and dev.gaia]
>>>>> 
>>>>> Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to
>>>>> bring yourself up to speed about post-1.0 work, especially around
>>>>> landings, approvals, and setting bug status. This wiki page and dates
>>>>> may change, but we'll keep you abreast as we make those changes.
>>>>> 
>>>>> -Alex
>>>>> _______________________________________________
>>>>> dev-gaia mailing list
>>>>> [email protected]
>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>> _______________________________________________
>>>> dev-gaia mailing list
>>>> [email protected]
>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>> 
>>> ________________________________
>>> 
>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
>>> nuestra política de envío y recepción de correo electrónico en el enlace 
>>> situado más abajo.
>>> This message is intended exclusively for its addressee. We only send and 
>>> receive email on the basis of the terms set out at:
>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>> _______________________________________________
>>> dev-gaia mailing list
>>> [email protected]
>>> https://lists.mozilla.org/listinfo/dev-gaia
>> _______________________________________________
>> dev-gaia mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-gaia
> 

_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to