On Thursday, December 17, 2015 at 3:29:17 PM UTC-8, Bobby Holley wrote: > I had a long conversation about the two-way sync stuff at Orlando with Alex > and some of the Servo folks. > > We concluded that, long-term, we need to let Gecko hackers commit to the > vendored code and have that code automatically upstreamed. Similarly, > upstream fixes need to be automatically merged into Gecko. > > Everyone seemed on board with this plan, but Alex suggested that it should > probably be a separate tool, distinct from Cargo. This tooling is going to > be pretty important, but we should probably wait on it until we've got the > other issues sorted out.
Bi-directional sync in version control is a hard problem. It's possible to deliver something that is correct 90% of the time. But there are inevitably race conditions that lead to divergence, which human intervention is required to correct. The *only* way to prevent this is for there to be a single source of truth and for the repository's locking and transaction mechanism to prevent races. This means version control for Gecko+Servo given the apparent set of requirements is very difficult. As it stands, we're talking about source of truth living in several upstream repositories which are then vendored in mozilla-central. We either have a Gecko developer first committing upstream and then pulling down that change into mozilla-central - likely high latency and frustrating - OR a nasty sync/merge problem coupled with governance and logistical concerns/problems over who can commit to what and with what oversight. It's a nightmare. An alternative is to make mozilla-central the canonical repository. I'm almost certain the thought of this would incite riots. But I don't think this - or something along that vein - is as far fetched as you may think because there are crazy things you can do in version control. Facebook has a crazy version control setup. Internally they have a monorepo with tons of random projects. This includes a number of their popular open source projects. What they do is export sub-directories from their internal monorepo to e.g. GitHub. People submit pull requests and do the typical GitHub workflow. For some projects, they synchronize pull request code reviews into their internal code review tool (Phabricator). Comments left on Phabricator are replicated to GitHub and vice versa. When it comes time to merge a pull request, they don't merge it in GitHub. Instead, a tool grafts the branch onto their monorepo, commits it, syncs it back out to the GitHub project, then closes the pull request. It's a terrific model and something that we (Mozilla) could build if we needed to. Servo isn't along in wanting this. Groups like Firefox Developer Tools and Loop desire to live in a world where their feature behaves like a standalone project - independent of mozilla-central. I understand why there would be visceral reactions to shackling your project to mozilla-central. There is a lot of process and overhead there. But, with some tooling and realized planned improvements to the automation infrastructure that e.g. reduce tree closures, I think many of these concerns would go away. Projects could be canonically located in mozilla-central, but all day-to-day development is performed in GitHub (or wherever). This gives us all the nice properties of the monorepo without the bi-directional syncing problems and hopefully without forcing too many [sub-optimal] workflows and limitations on people. (I'm not expecting to sell people on this idea - I just wanted to suggest crazy alternatives because I feel people don't realize things like this are possible.) _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
