On Mon, Dec 21, 2015 at 6:55 PM, <gsz...@mozilla.com> wrote: > 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. >
This is an interesting idea. However, for the style system case this would involve the entirety of of the top-level Servo living in mozilla-central (or rather, the shared monolithic mega-repo, since both projects would likely end up doing partial checkouts). And even if the tooling were seemless enough that Servo developers were able to transparently hack on the github repo as they do now, we'd still need to unify the CI in order to continue treating both projects as Tier-1. This is theoretically doable, and possibly the right thing if Gecko and Servo start sharing lots and lots of code, but I'm pretty sure we don't want that in the near future. Moreover, as Simon points out, this doesn't really scale to all the other projects that Servo depends on. I recognize that bidirectional sync is imperfect and may require manual resolution of conflicts (source-level, compile-time, or runtime). But I think it makes the right trade-offs for the projects we're pursuing right now. The devil is in the details, and I think it might be worth spinning off a separate thread to discuss the precise mechanics of how that tool would work. I'll do that now. 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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
