We need to switch which branch gets populated for gecko.git's v1.2 branch carefully around the 29-oct-2013 merge day. We need to make sure we don't sync any Firefox 27 code to the v1.2 branch!!! So: * pause v1.2 branch syncing (this is currently on aurora); this might be good to do when we pause aurora updates. * relman merges central->aurora * re-enable v1.2 branch syncing, but off the new mozilla-b2g26-v1_2 branch.

We currently mirror from https://hg.mozilla.org/releases/mozilla-aurora/ to http://git.mozilla.org/?p=releases/gecko.git;a=shortlog;h=refs/heads/v1.2 On-or-just-before the migration tracked in bug#842870, we need to: * create repo https://hg.mozilla.org/releases/mozilla-b2g26_v1_2_0/ * initialize https://hg.mozilla.org/releases/mozilla-b2g26_v1_2_0/ with tip of https://hg.mozilla.org/releases/mozilla-aurora/ * switch v1.2 replication and automation from using aurora to using https://hg.mozilla.org/releases/mozilla-b2g26_v1_2_0/ * verify that http://git.mozilla.org/?p=releases/gecko.git;a=shortlog;h=refs/heads/v1.2 is now correctly picking up changes that land in https://hg.mozilla.org/releases/mozilla-b2g26_v1_2_0/. * (anything I missed?) hwine, aki: the migration dates are ~3weeks from today; when does this work need to start in order to have all this setup, tested and ready for calm switchover without disrupting the usual migration mechanics? what other dep bugs need to be filed?

(In reply to John O'Duinn [:joduinn] from comment #1) > We currently mirror from https://hg.mozilla.org/releases/mozilla-aurora/ to > http://git.mozilla.org/?p=releases/gecko.git;a=shortlog;h=refs/heads/v1.2 > > On-or-just-before the migration tracked in bug#842870, we need to: > * create repo https://hg.mozilla.org/releases/mozilla-b2g26_v1_2_0/ > * initialize https://hg.mozilla.org/releases/mozilla-b2g26_v1_2_0/ with tip > of https://hg.mozilla.org/releases/mozilla-aurora/ > * switch v1.2 replication and automation from using aurora to using > https://hg.mozilla.org/releases/mozilla-b2g26_v1_2_0/ > * verify that > http://git.mozilla.org/?p=releases/gecko.git;a=shortlog;h=refs/heads/v1.2 is > now correctly picking up changes that land in > https://hg.mozilla.org/releases/mozilla-b2g26_v1_2_0/. > * (anything I missed?) > > hwine, aki: the migration dates are ~3weeks from today; when does this work > need to start in order to have all this setup, tested and ready for calm > switchover without disrupting the usual migration mechanics? what other dep > bugs need to be filed? We probably want to start this next week or the week after. I don't think we want to switch the syncing over until right before the migration, or our builds will be using a stale version of gecko, and QA won't be verifying the right code.

I agree that we can't "test in advance". Also, this IS invasive to the "usual migration mechanics" -- we need to work very closely with Rel Man during this process. There are several points of manual synchronization. I'll find the notes from the creation of b2g18 branch & cutover before I clear need info

per irc discussion with :aki, no real value in the b2g18 history, as so much has changed. Other items to clarify (additions to comment #1): - which system will be pushing to releases/gecko.git at this time? (Legacy or new) - naming (bug 924643) - coordination with Rel Man on Merge Day activities

configs will be in the merge day bug

Comment on attachment 821805 [details] [diff] [review] hghooks Review of attachment 821805 [details] [diff] [review]: ----------------------------------------------------------------- <stamp/>

Comment on attachment 821846 [details] [diff] [review] tools Review of attachment 821846 [details] [diff] [review]: ----------------------------------------------------------------- <stamp/>

Comment on attachment 821805 [details] [diff] [review] hghooks pushed http://hg.mozilla.org/hgcustom/hghooks/rev/15e5831ab26b

Comment on attachment 821846 [details] [diff] [review] tools pushed https://hg.mozilla.org/build/tools/rev/44f98df872a1

I have just synced m-a to the new repo: https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/pushloghtml?changeset=5c3d00c8fc5d

Another sync https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/pushloghtml?changeset=dba809d7ee66

Another one https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/pushloghtml?changeset=cc371f7026a8

This adds the b2g26 branch to beagle, and switches the 1.2 branch in the [staging] gecko.git to b2g26. It also removes a wildcard tag push to the local beagle test_push repo -- I think this is unnecessary, leftover from testing I think.

Comment on attachment 823483 [details] [diff] [review] (mozharness) b2g26_v1_2_conversion Review of attachment 823483 [details] [diff] [review]: ----------------------------------------------------------------- lgtm -- one question below, but r+ regardless of answer. ::: configs/vcs_sync/beagle.py @@ +101,5 @@ > + "bare_checkout": True, > + "vcs": "hg", > + "branch_config": { > + "branches": { > + "default": "b2g26", Not a blocker -- I'm a trifle concerned to have both 'b2g26', 'b2g26_v1_2' and 'v1.2' all refer to the same thing I assumed there was a "pattern" for beagle that we drop the leading "mozilla-" to get the branch name. I'd lean strongly for consistency, not only as being easier for scripting, but also for casual viewers. Especially those in the future.

Ended up going with b2g26_v1_2.

Oops, looks like a merge made aurora happen twice. I think this was noop, or picked up only latest changes... Fixed now.

add mapping of b2g26_v1_2 to git v1.2

add path to b2g26_v1_2 repo, remove aurora

Comment on attachment 823563 [details] [diff] [review] gaia_bumper_1.2 Review of attachment 823563 [details] [diff] [review]: ----------------------------------------------------------------- no more polling -- I like that!

Note that b2g26 is currently closed due to the bug 932373 and bug 932378 perma-fails.

We also need to land a talos branch in the graphserver: > 13:28:22 INFO - RETURN:No branch_id for a branch_name 'Mozilla-B2g26-v1.2' can be found I tried looking in here https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning but did not find the new instructions on how to do it. I know that IT can do it for us. We used to be able to do it through root@slavealloc before we moved it.

I'm not entirely sure why this has become a "things are broken on the new b2g26 branch after merge day" bug; this was specifically for pausing the hg-git sync script before merge day happens, to prevent non-fastforward commits. I'll let it happen, though, since having *some* location to track these things is probably good.

since it's morphed, moving to releases component

Comment on attachment 825633 [details] [diff] [review] mozharness_configs http://hg.mozilla.org/build/mozharness/rev/0366495a9427 transplanted to production.

all done