Closed Bug 968789 Opened 7 years ago Closed 7 years ago
Need project branch for building the Mulet
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.
Component: General → Repos and Hooks
Product: Firefox OS → Release Engineering
QA Contact: hwine
Hal, do you own setting up twig repos?
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?
Flags: needinfo?(hwine) → needinfo?(anygregor)
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?
(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?
Will this work impact others kinds of builds? If not, we can just add it to cedar.
(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.
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.
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
Assuming we're done here, since fig is available
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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.
Product: Release Engineering → Developer Services
You need to log in before you can comment on or make changes to this bug.