1406792 - Create an officially supported cinnabar clone of mozilla-unified with full CVS history

Status: RESOLVED FIXED

(Developer Services :: Git, enhancement)

Description

[Jonathan Watt [:jwatt]]

Filing this bug to implement the conclusions from the "Canonical cinnabar repository" thread on mozilla.dev.platform:

https://groups.google.com/d/msg/mozilla.dev.platform/kqMX4H6Iw5M/Kfu4x_aFBgAJ

As best I can make out we're currently waiting for dhouse to give feedback on katz's question about what the next steps should be to request this of Developer Services/Release Engineering.

Comment 1

[:dhouse]

That's correct. I think it will be one of my goals for Q1. I'll need to talk more with Myk, Greg, and release engineering folks when I get started on this to determine what the goals are (such as if we can retire the old sync and move feature branches to mozilla/gecko, or if we take a small step in that direction by officially maintaining mozilla/gecko).

Comment 2

[Mike Hommey [:glandium]]

An alternative I've been advocating for a while is switching gecko-dev to use git-cinnabar instead of hg2git for future updates.

Comment 3

[Gregory Szorc [:gps]]

Standing up an official cinnabar-based repo is relatively easy and something I want to see done. Having it work well with various tools and processes is the bulk of the work.

I've very much worried about a Pandora's Box scenario here. That's why I want the expectations/requirements of the proposed repo to be spelled out explicitly before any action is taken.

It isn't clear from various threads that people understand the full scope of the problems and the various limitations and trade-offs in play. So here is a partial list of questions that need answered:

* How is a corresponding Mercurial SHA-1 resolved on the local machine? (This is needed for some operations related to CI. Saying "it can't be" means that the Git repo will lack functionality compared to a Mercurial repo or direct cinnabar clone.
* How will locally created Git commits result in "Try" automation running?
* How will locally created Git commits get turned into review requests? (Probably only worth considering Phabricator at this point.)
* How will locally created Git commits get landed? (I'm not sure if "support Phabricator" is enough here.)
* Can a local Mercurial repo be used for any of the above? Is that a deal breaker?
* As the barrier between version control, the Firefox build system, and CI continues to break down, how do we ensure that support for this new repo doesn't create a substantial burden on long-term development and support costs?

If any of these things require a custom server-side service:

* Who writes it? (And what other work isn't getting done because they are writing it?)
* Who monitors it?
* What's the SLA?
* How does authentication, authorization, and identity management work?
(This set of questions is mostly on me, dhouse, glob, coop, etc.)

Again, I'm not opposed to doing the simple thing of standing up a cinnabar-based repo. (But the simple thing doesn't "solve" things like Try and review integration without local knowledge of Mercurial - either via a) a local hg repo + moz-git-tools or something b) cinnabar.) I just want to be sure expectations around the functionality/limitations of that repo are very clear so support and evolution of the repository can be planned accordingly.

From various mailing list threads, I know different people have vastly different expectations for the proposed repo. And I've even been surprised by a few of them! I'd ask proponents of this repo to please record your expectations. A gdoc or etherpad is probably a better medium for that than bug comments. But if you want to leave comments here, they'll be read.

Comment 4

[Gregory Szorc [:gps]]

FWIW a valid answer is "convert mozilla/gecko-dev to use cinnabar going forward with no other changes." That's certainly the easiest to implement and doesn't invite a larger discussion around integration with other tools and processes. I'm not just sure if that meets various people's expectations...

Comment 5

[Jeff Muizelaar [:jrmuizel]]

I think that an official version of Myk's repo is really all that's in scope for this bug. I think we should start with that and any additional functionality can be considered individually.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

(In reply to Mike Hommey [:glandium] from comment #2)

An alternative I've been advocating for a while is switching gecko-dev to
use git-cinnabar instead of hg2git for future updates.

For the record I'm in favor of this approach. I recently updated searchfox so that it no longer relies on the mapper file from vcs-sync, and instead is using cinnabar-grafted metadata to do git <-> hg mapping. So if the gecko-dev update process switches to cinnabar instead of hg2git, everything will Just Continue To Work on the searchfox side, and gecko-dev can continue to be our canonical repo that has full CVS history, and will also be fully cinnabar-compatible. Anybody using gecko-dev from that point onwards (which includes searchfox) will be able to pull directly from mozilla-unified with cinnabar and get identical SHAs as the official gecko-dev produced by vcs-sync. This seems to me to be the ideal end state.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Now that gecko-dev is being updated via cinnabar, it's an officially maintained repository with full CVS history that individuals can update locally with cinnabar and still remain hash-compatible. So I think we can close this bug.