Once bug 774766 is fixed, we'll no longer have a need to use: https://hg.mozilla.org/webtools/tbpl/file/default/mcmerge/php/getFlags.php This will simplify the migration of mcMerge away from the TBPL box - which is required for bug 1050477 and thus bug 1054977.

Can you poke IT about that? Looks like it stalled at "coordinate with sheriffs for a deployment time".

Although actually, I think this got fixed at some point because I'm fetching files directly from hg.mo on whattrainisitnow.com: https://github.com/luser/whatthetrain/commit/4609b3e133b0d208cbb77126a57385da111e31ee

Current values returned by FlagLoader (I've included the special-cased repos and a handful of others): mozilla-central ?tree=mozilla-central&cset=0c66a9fd9085 "status_firefox36", "tracking_firefox36" mozilla-aurora ?tree=mozilla-aurora&cset=972131c0128e "status_firefox35", "tracking_firefox35" mozilla-beta ?tree=mozilla-beta&cset=43e9c7a57468 "status_firefox34", "tracking_firefox34" mozilla-release ?tree=mozilla-release&cset=ff5068a4aa0c "status_firefox33", "tracking_firefox33" mozilla-esr31 ?tree=mozilla-esr31&cset=dbeda9908c05 "status_esr31", "tracking_esr31" mozilla-b2g34-v2.1 ?tree=mozilla-b2g34-v2.1&cset=780af6b71bf2 undefined (error: unknown tree) mozilla-b2g32-v2.0 ?tree=mozilla-b2g32-v2.0&cset=dbf49343e889 undefined (error: unknown tree) mozilla-b2g30-v1.4 ?tree=mozilla-b2g30-v1.4&cset=a45dc349f0a9 undefined (error: unknown tree) mozilla-b2g28-v1.3t ?tree=mozilla-b2g28-v1.3t&cset=2d419d110f66 undefined (error: unknown tree) comm-central ?tree=comm-central&cset=e4dbeb8f01a8 "status_thunderbird36", "tracking_thunderbird36" comm-esr31 ?tree=comm-esr31&cset=9f538ce73c06 "status_thunderbird_esr31", "tracking_thunderbird_esr31"

The version for ESR repositories is a constant, since they're release branches. This means we can skip fetching the version number from the repo, a perf win. However it makes more sense to handle this client side, and doing so also helps with the deprecation of getFlags.php.

Prior to this patch, getFlags.php was out of date with respect to the list of valid B2G release repos. In the future we should fix the handling of these repos (they use a different versioning scheme and do not use tracking flags, only status), however to simplify the transition away from getFlags.php, this patch maintains the unsupported B2G repo behaviour - that is mcMerge.trackingFlag and mcMerge.statusFlag have the same value before and after this patch: null.

To help with the deprecation of getFlags.php, the determination of the flag product name (eg "firefox" or "thunderbird") is now moved from getFlags.php to FlagLoader.js, leaving getFlags.php as simply a means to obtain the version number.

Previously, version.txt was retrieved from hg.mozilla.org via getFlags.php, since the access control header did not permit us to do so in the client. That has now been fixed (bug 774766), so we can now remove the only server-side component of mcMerge, thereby simplifying hosting requirements. To compare before/after values for tracking and status flags, set a breakpoint in the devtools debugger on mcMerge.js:214, use the params in comment 3 and then when you hit the breakpoint, inspect this.trackingFlag and this.statusFlag. There are definitely much cleaner ways to implement all this (eg using properties on special-cased repos in Config.js), however I'd like to keep this bug purely about moving away from getFlags.php in the least risky way possible (given no unit tests - something else we should add later, sigh).

Perhaps you could try using this from the local filesystem for the next few merges to act as another sanity check? :-)

Just marked the below merge with these 4 patches applied without any obvious issues. https://treeherder.mozilla.org/ui/#/jobs?repo=mozilla-central&revision=c39ff12ad6eb

Comment on attachment 8519016 [details] [diff] [review] Part 1: Move handling of ESR repo flags to FlagLoader.js Review of attachment 8519016 [details] [diff] [review]: ----------------------------------------------------------------- I'm not really comfortable being a reviewer for these. That said, I'll feedback+ them for at least a high-level "does this make sense and seem to work OK?" rubberstamp :)

Comment on attachment 8519024 [details] [diff] [review] Part 4: Move hgweb version.txt retrieval client-side Review of attachment 8519024 [details] [diff] [review]: ----------------------------------------------------------------- \m/

I used a locally-patched instance for multiple merges and checkin-needed pushes today without any unexpected behavior.

remote: https://hg.mozilla.org/webtools/tbpl/rev/b8f24892d9b8 remote: https://hg.mozilla.org/webtools/tbpl/rev/7725633cee8b remote: https://hg.mozilla.org/webtools/tbpl/rev/c0963ecd8360 remote: https://hg.mozilla.org/webtools/tbpl/rev/32b447b266ab