761868 - We need daily b2g builds with tip of m-c for Gecko

Status: VERIFIED FIXED

(Release Engineering :: General, defect)

Description

[Alex Keybl [:akeybl]]

Currently we fork m-c and qualify it before including that version of Gecko in daily builds, since we don't have daily automated testing that we're confident with. In the meantime, we should have a second build available with tip of tree m-c Gecko, for QA qualification.

Comment 1

[Jonathan Griffin (:jgriffin)]

This bug is for B2G builds, right?

I can set up the existing QA build infrastructure to build daily "trunk" builds alongside the current builds that are built with a vetted m-c.

Comment 2

[Alex Keybl [:akeybl]]

(In reply to Jonathan Griffin (:jgriffin) from comment #1)
> This bug is for B2G builds, right?

Yep

> I can set up the existing QA build infrastructure to build daily "trunk"
> builds alongside the current builds that are built with a vetted m-c.

Awesome - I think that's what we want.

Comment 3

[Tony Chung [:tchung]]

I just found out that TEF has also been pulling daily gecko code from https://github.com/mozilla-b2g/B2G.git, and building with their OWD repo.   They were under the impression they were also seeing daily gecko m-c.    So certainly confirmation that this is important to fix.

Thanks!

Comment 4

[chris hofmann]

also whats the plan here for later this summer?

we also need to start figuring out a build system for localizations of b2g.

if we are going to re-purpose core gecko strings related to error responses for api calls and such (that are in toolkit?) into b2g, then it will be best to pick something off of the aurora or beta repositories. Most localization teams work on aurora.

we probably also need to open up a parallel bug for getting a standard l10n build process in place that deals with all the technical and configuration management issues like this, and leverages off the en-US process.  We will also need to figure out an owner for that work.

Comment 5

[Jonathan Griffin (:jgriffin)]

(In reply to chris hofmann from comment #4)
> also whats the plan here for later this summer?
> 
> we also need to start figuring out a build system for localizations of b2g.
> 
> if we are going to re-purpose core gecko strings related to error responses
> for api calls and such (that are in toolkit?) into b2g, then it will be best
> to pick something off of the aurora or beta repositories. Most localization
> teams work on aurora.
> 
> we probably also need to open up a parallel bug for getting a standard l10n
> build process in place that deals with all the technical and configuration
> management issues like this, and leverages off the en-US process.  We will
> also need to figure out an owner for that work.

These builds are primarily for QA use.  I think for l10n we probably need rel-eng to get involved to create "official" builds.

Comment 6

[Jonathan Griffin (:jgriffin)]

Our builder ran out of disk space last night while attempting to build these trunk builds, and it looks like it might not be easy to add capacity quickly.  I've rearranged a bunch of files on the VM and am trying to the builds again.  If that fails, we might be OK with stopping the emulator-x86 build (and just leaving the emulator-arm build, which is more stable); this might free up enough space to allow trunk builds on the SGS2 and Nexus-S.

Comment 7

[Chris AtLee [:catlee]]

should releng be doing these builds instead?

Comment 8

[Alex Keybl [:akeybl]]

(In reply to Chris AtLee [:catlee] from comment #7)
> should releng be doing these builds instead?

I didn't realize these builds weren't already happening in RelEng - we should be driving towards having:

* Bleeding edge dev builds: tip of specific gecko/gaia/gonk branches built together nightly
* Testing builds: closer to what we have now, where we can select stable gecko/gaia/gonk changesets to build

Comment 9

[Jonathan Griffin (:jgriffin)]

Yes, we should definitely work on transitioning all the building to rel-eng.  I can work with :catlee on this.

Comment 10

[Jonathan Griffin (:jgriffin)]

So I was successful in jiggering some space on the builder, and we're now making SGS2 and Nexus-S builds with tip m-c, along with the other builds.  The new builds have "trunk" in their filename, e.g., https://releases.mozilla.com/b2g/2012-06-07/sgs2_2012-06-07_trunk.zip.

I think we can close this bug, unless you want to leave it open to track rel-eng work.

Comment 11

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to Alex Keybl [:akeybl] from comment #8)
> (In reply to Chris AtLee [:catlee] from comment #7)
> > should releng be doing these builds instead?
> 
> I didn't realize these builds weren't already happening in RelEng - we
> should be driving towards having:
> 
> * Bleeding edge dev builds: tip of specific gecko/gaia/gonk branches built
> together nightly
> * Testing builds: closer to what we have now, where we can select stable
> gecko/gaia/gonk changesets to build

(In reply to Jonathan Griffin (:jgriffin) from comment #9)
> Yes, we should definitely work on transitioning all the building to rel-eng.
> I can work with :catlee on this.

We're already running some B2G builds in RelEng, some other builds in ATeam, and are figuring out what further builds exactly are wanted by the b2g team. Offline discussions continue, with b2g team and akeybl.

Grabbing this bug after in-person discussion w/akeybl so we dont spin our wheels here until we know what is being asked by b2g group.

Comment 12

[Jonathan Griffin (:jgriffin)]

Can we remove the blocking-basecamp flag?  I think so, since we're producing these builds now, even though they may eventually transition to rel-eng.

Comment 13

[Alex Keybl [:akeybl]]

I've asked Geo/Tony to let us know if there are any issues with these new nightly builds.

Comment 14

[Tony Chung [:tchung]]

(In reply to Alex Keybl [:akeybl] from comment #13)
> I've asked Geo/Tony to let us know if there are any issues with these new
> nightly builds.

tested on 6-11-2012 build.   AFAICT, i'm running the latest gonk (cause jgriffin said so), gecko (viewing application.ini), and gaia (settings > git commit).

I'll file a separate bug to add Otoro devices to the mix.