On Tue, Dec 22, 2015 at 7:02 AM, Simon Sapin <simon.sa...@exyr.org> wrote:
> On 22/12/15 03:55, gsz...@mozilla.com wrote: > >> The *only* way to prevent [race conditions] is for there to be a >> single source of truth. >> > > Yes, I think that’s an important point. > > > An alternative is to make mozilla-central the canonical repository. >> >> Facebook has [...] >> 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. >> >> 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. >> > > As the primary maintainer of rust-url, I’m willing to try this. > > But to be honest, it feels backwards from how things "should" be. Servo > and Firefox are two of many projects using rust-url. (Which replaces what > used to be a module in the Rust standard library.) I don’t think we can ask > the same of Rust projects whose maintainer don’t happen to be on the Servo > team. At worst this could be perceived like a hostile take-over. > > I’m also worried about the process and overhead you mention. > > Gecko developer first committing upstream and then pulling down that >> change into mozilla-central - likely high latency and frustrating >> > > Isn’t that latency and frustration the same the other way around? > > How long would it typically take between approving a GitHub PR and having > it land in GitHub master? (This matters when a conflicting PR needs to be > rebased.) Would it be blocked on mozilla-inbound being merged into > mozilla-central? To be clear, there is a lot of hand waving assuming future improvements in my "proposal." First, mozilla-inbound (and other integration repositories like fx-team) should not exist. They were created a few years ago so tree closures wouldn't stop the world and so there would be a tip that was more or less always "green." More diligent and proper usage of Try (facilitated through autoland) will reduce tree closures and eventually lead to integration repositories going away because they are no longer needed. Assuming you don't have to wait for a merge from an integration repository, there is still the issue of waiting for automation to mark the commit as stable before it is incorporated [and mirrored back to GitHub]. The mozilla-central automation is currently very liberal about what it runs. If you e.g. change Firefox frontend JS code, we run all the layout tests, even though there is a ~0.00% chance that JS change will impact the layout code. This means that it takes hours for a commit to be marked as stable. This is horrible and needs to improve. People are working on it. I'm not sure exactly what the final state will be, but I think it is possible to get the turnaround time under 10 minutes, if not shorter for really simple changes (like docs only changes). This requires rethinking "tree rules" a bit and I'm intentionally being vague with details because I don't want to invite bikeshedding :) _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
