I'll provide some information here which can hopefully enable you guys
make a good decision.
We have a number of temporary project branches which do get regular
builds and tests and have their own TBPL etc. This is usually the
fastest way to get started working on a m-c based feature with full
build/test support. Currently it looks like they're all booked
<https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectBranches#BOOKING_SCHEDULE>
but you can reach out to individual branch owners to see if they're
actively using their branches and if not if they're willing to donate it
to you.
These branches are synced to git in
https://github.com/mozilla/gecko-projects which is a repo which is
separate from gecko-dev on github but actually shares the same history
so you can easily set it up as a remote in git and use it locally.
We currently do not support any kind of build/test infra if you don't
want to touch a mercurial repository at all. But if that is a non-goal,
the above setup should enable you to use git locally.
On the issue of regular merges from m-c to this repo, that is actually
quite easy to automate, I have a script which does that and sends you an
email when a merge goes busted which you're welcome to steal and run it
off of cron.
It's also possible to file a RelEng bug and ask for a named project
branch, but those are slower to setup, and I think there is a limited
number of them.
Another approach is doing everything in git, and just use the try server
for running builds and tests. This will let you collaborate the usual
git style, and everytime you want builds/tests, someone needs to
manually do a git diff origin/master or some such and generate a patch
and push it to the try server.
Hope this helps!
Ehsan
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
