968789 - Need project branch for building the Mulet

Status: RESOLVED FIXED

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Gregor Wagner [:gwagner]]

We need a project branch to build the Mulet. It should replace B2G desktop in the long run. Jonas is about to send out an email explaining the project.

Comment 1

[Jonathan Griffin (:jgriffin)]

Hal, do you own setting up twig repos?

Comment 2

[Hal Wine [:hwine] use NI!]

twigs are self managed by users as per https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectBranches

since there are not any free, we can rattle the cage of current users to give one up.

We don't have any hard policy about adding additional twigs -- twigs imply additional load on the build infrastructure, and our capacity only increases slowly. Ideally, we won't grow the pool of twigs, and bump something else instead.

Also note that twigs are oriented towards FFx builds -- it doesn't provide any repository space for gaia/gonk/etc. And any specific b2g builds need to be requested (per note in wiki). b2g device builds are a very "it depends" subject for legal reasons.

Gregor -- will the self manage work for you (assuming we get one)?  Or will Mulet's needs be significantly outside that scope?

Comment 3

[Alexandre Poirot [:ochameau]]

The main reason to request such branch is to help ateam to start looking at mulet compatibility.
Otherwise, having a branch on git is way easier to maintain!

So that I think it will be more up to the one looking at making the mulet be compatible with the various test runner we have. It may be already possible to do that from the git repo, by fixing stuff locally... I don't really know. It may also require having a hg mozilla repo to ensure that tbpl works correctly.

May be we can hold on on this until we get someone to look at the test story?

Comment 4

[Andrew Halberstadt [:ahal]]

(In reply to Alexandre Poirot (:ochameau) from comment #3)
> The main reason to request such branch is to help ateam to start looking at
> mulet compatibility.
> Otherwise, having a branch on git is way easier to maintain!

If you want to hit the ground running with mochitests, reftest, Gu and Gi already running, then I highly suggest we do the hg route :). If you use a git repo it would still be possible to run the tests locally, but getting everything in a continuous integration system like travis probably won't work. In my experience, without C-I the harnesses will break and it'll take a period of time on the order of months or quarters to get them working again. Also, I'm happy to help make changes to the harnesses as needed along the way.

I don't think infrastructure load would be that big of an issue because on this twig we'd only need to run b2g desktop builds + tests (or maybe b2g desktop + mulet depending on how they plan to implement it). Correct me if I'm wrong?

Comment 5

[Jonathan Griffin (:jgriffin)]

Will this work impact others kinds of builds?  If not, we can just add it to cedar.

Comment 6

[Gregor Wagner [:gwagner]]

(In reply to Jonathan Griffin (:jgriffin) from comment #5)
> Will this work impact others kinds of builds?  If not, we can just add it to
> cedar.

We probably want to land some dirty gecko-hacks in the beginning to get it up and running asap.

Comment 7

[Jonathan Griffin (:jgriffin)]

In that case, we can't use cedar.  Hal, can you help shake a twig loose?  I can help with the needed buildbot-configs patches.

Comment 8

[Hal Wine [:hwine] use NI!]

Fig just freed up thanks to :armenzg -- I'm reserving on the page, by default you'll get "build everything" when you complete the steps in https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectBranches#Book_one_of_our_fabulous_.22disposable.22_project_branches

Comment 9

[Hal Wine [:hwine] use NI!]

Assuming we're done here, since fig is available

Comment 10

[Aki Sasaki (not active)]

Ideally we get Cedar trustable again, so we can move this there.
We're trying to reduce the number of builders since we're hitting buildbot-master-load-related bustage in production, and using two project branches when we can use one isn't efficient.