Now that bug 871231 moved m-cMerge to Mozilla servers, we have no visibility into the box on which it runs, nor the ability to update/deploy ourselves. Given how m-cMerge's primary point of access is via TBPL, one idea would be to import m-cMerge into the TBPL repo, so we can deploy along with TBPL. Graeme would you be ok with this? If so, I don't suppose you could commit a change to the bitbucket repo mentioning the licence under which you are happy to release m-cMerge? (eg in the readme) Do also credit yourself by name in there as the original creator :-) If you are happy with doing this, then I think the best plan is to: 1) Commit the above licence clarification. 2) Use hg convert to remap the m-cMerge repo to place all files inside a subfolder named "mcmerge". 3) Do a |pull -f <remapped_m-cMerge_repo>| from inside TBPL's repo, so we preserve all of m-cMerge's history. 4) Merge the two heads. 5) Change the TBPL links to point to https://tbpl.mozilla.org/mcmerge/ 6) Test both the php component and the client from a TBPL Vagrant instance. Graeme, do you have a strong preference for 'm-cMerge'? I frequently get the hyphenation wrong, so was wondering if we could stick with 'mcMerge' (and lowercase for the directory name)? :-)

Graeme, don't suppose you saw comment 0? :-)

Released under the MIT License, pushed a commit to that effect. What's the review policy for TBPL? i.e. when I get around to refactoring this horrible, ugly code, who do I ping for review? Going forward, I assume bugs will be tracked here, in Webtools:TBPL? (In reply to Ed Morley [:edmorley UTC+1] from comment #0) > Graeme, do you have a strong preference for 'm-cMerge'? I frequently get the > hyphenation wrong, so was wondering if we could stick with 'mcMerge' (and > lowercase for the directory name)? :-) But then what am I supposed to do with my warehouse full of m-cMerge branded mugs, pens and hoodies? In other words, no preference. The hyphenation came from the traditional shorthand for mozilla-central.

(In reply to Graeme McCutcheon [:graememcc] from comment #2) > Released under the MIT License, pushed a commit to that effect. Thank you :-) > What's the review policy for TBPL? i.e. when I get around to refactoring > this horrible, ugly code, who do I ping for review? It's pretty informal tbh (r=me if it's straight forwards, otherwise one of me, Ryan, mstange, Swatinem, philor, mbrubeck), however we needn't even follow that for changes to /mcmerge/* > Going forward, I assume bugs will be tracked here, in Webtools:TBPL? Good point - we could always create a new product/component at some point, but the TBPL one will work temporarily. > (In reply to Ed Morley [:edmorley UTC+1] from comment #0) > But then what am I supposed to do with my warehouse full of m-cMerge branded > mugs, pens and hoodies? In other words, no preference. The hyphenation came > from the traditional shorthand for mozilla-central. hehe :-)

/c/src $ cat filemap.txt rename . mcmerge /c/src $ hg convert --filemap filemap.txt mcmerge mcmerge-redone initializing destination mcmerge-redone repository scanning source... sorting... converting... <snip> /c/src $ cd mcmerge-redone /c/src/mcmerge-redone $ hg update 43 files updated, 0 files merged, 0 files removed, 0 files unresolved /c/src/mcmerge-redone $ cd ../tbpl /c/src/tbpl $ hg pull -f ../mcmerge-redone/ pulling from ../mcmerge-redone/ searching for changes warning: repository is unrelated requesting all changes adding changesets adding manifests adding file changes added 122 changesets with 273 changes to 76 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge) /c/src/tbpl $ hg merge 43 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) /c/src/tbpl $ hg commit -m "Bug 875323 - Import m-cMerge" mcmerge/LICENSE mcmerge/README.md mcmerge/css/opensans.woff mcmerge/css/style.css mcmerge/images/ajax-loader.gif mcmerge/images/background.png mcmerge/images/holly.png mcmerge/images/ie.gif mcmerge/images/loading.gif mcmerge/images/sky.png mcmerge/images/snowy.jpg mcmerge/images/stone.png mcmerge/index.html mcmerge/js/BugData.js mcmerge/js/Config.js mcmerge/js/ConfigurationData.js mcmerge/js/DebugUI.js mcmerge/js/FlagLoader.js mcmerge/js/PushData.js mcmerge/js/Remapper.js mcmerge/js/Step.js mcmerge/js/Summary.js mcmerge/js/UI.js mcmerge/js/Utils.js mcmerge/js/Viewer.js mcmerge/js/ViewerController.js mcmerge/js/mcMerge.js mcmerge/php/getFlags.php mcmerge/thirdparty/bzjs/LICENSE mcmerge/thirdparty/bzjs/bz.js mcmerge/thirdparty/chai/LICENSE mcmerge/thirdparty/chai/chai.js mcmerge/thirdparty/jquery/MIT-LICENSE.txt mcmerge/thirdparty/jquery/jquery-1.7.2.min.js mcmerge/thirdparty/mocha/LICENSE mcmerge/thirdparty/mocha/mocha.css mcmerge/thirdparty/mocha/mocha.js mcmerge/thirdparty/requirejs/LICENSE mcmerge/thirdparty/requirejs/require.js mcmerge/thirdparty/toast/grid.css mcmerge/thirdparty/toast/reset.css mcmerge/thirdparty/toast/toast.css mcmerge/thirdparty/toast/type.css committed changeset 1221:6df37a22aef7

Landed the import to avoid having to rebase if something else lands on the TBPL repo in the meantime: https://hg.mozilla.org/webtools/tbpl/pushloghtml?changeset=6df37a22aef7 Patches to get us using the TBPL repo version to follow.

(And make them work when running TBPL from the local filesystem by appending 'index.html').

Makes mcMerge call the production getFlags.php if being run from the local filesystem. (Similar to how we implement TBPL frontend testing).

Comment on attachment 764160 [details] [diff] [review] Part 2: Make mcMerge work from the local filesystem Meant to say: this patch also removes the obsolete reference to getVersion.php since the file no longer exists.

Comment on attachment 764158 [details] [diff] [review] Part 1: Adjust links pointing to m-cMerge Landed part 1 so we can start testing on tbpl-dev (the rest is just to help local filesystem testing or else aesthetic): https://hg.mozilla.org/webtools/tbpl/rev/a4a05db5315d

Quick sanity-check of the imported backend (not that there were any likely dependency issues)... https://mcmerge.mozilla.org/php/getFlags.php?cset=58b1f6b4b570&tree=mozilla-central {"tracking":"tracking_firefox24","status":"status_firefox24"} https://tbpl-dev.allizom.org/mcmerge/php/getFlags.php?cset=58b1f6b4b570&tree=mozilla-central {"tracking":"tracking_firefox24","status":"status_firefox24"}

Thank you for the reviews :-) https://hg.mozilla.org/webtools/tbpl/rev/d6e9f3824674 https://hg.mozilla.org/webtools/tbpl/rev/8defe52551ff Graeme: For reference, https://tbpl-dev.allizom.org/ updates on a 15 min cron straight from the TBPL repo tip (and no longer requires credentials to access). The TBPL repo needs level 3 commit access (let me know if you don't have level 3). Pushes to production are done via Chief (self-deploy system), which requires MPT-VPN access and a password (I've been doing them until now, since easier to coordinate and make sure we don't inadvertently push not-fully-tested staged changesets to production).

images/stone.png images/ajax-loader.gif images/loading.gif images/ie.gif are redundant. For a bit of whimsy, I'm leaving last year's Christmas theme graphics in place (though the code should be changed to select those programatically rather than requiring a deployment every December).

In production :-) (Will give it a day more and then ask to shut down mcmerge.mozilla.org).