Upstream wpt commits as they land in m-c

NEW
Unassigned

Status

defect
3 years ago
2 years ago

People

(Reporter: jgraham, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Out current web-platform-tests upstreaming process batch upstreams the tests whenever I do a sync from upstream. This works, but we can do better, and will have to as the commit volume from other vendors (notably Google, who have just launched their own upstreaming bot) increases. The ideal time to upstream a commit would be as soon as it lands in m-c since by this point a backout is unlikely and the chance of an upstream merge conflict is minimised. But we can do even better by engaging early in the process. The system I would like to build/see is:

1) When a review request is opened that touches testing/web-platform/tests we automatically open an upstream PR for the changes (pointing at the related bug). This will cause upstream infrastructure to run (e.g. the stability checker), which we have to skip today (making us unpopular with other wpt contributors). Comments from that infrastructure are mirrored in the original bugzilla bug, telling patch authors the result of their tests on multiple browsers. If the PR can't land we also note that, so that conflicts can be sorted out early.
2) If the bug is closed, we close the corresponding PR. When the patch series is updated, we update the PR.
3) Once the patch series lands on m-c we merge the upstream PR (which hopefully doesn't have travis issues or merge conflicts; if it does a comment is added to the bug and a human has to fix things).
4) In the case of a late backout, we also backout from upstream.
5) In the rare case of a commit that lands on m-c without going via a review request, we create a PR at the time it lands, let the checks run, and then upstream it.

Syncing *from* upstream is unaffected by this proposal, except insofar as it removes one manual step from the current process and so may make pulling easier (we also need to improve that, but it's mostly a separate effort).

It seems like the "is there a patch for a certain part of our tree" part of this process might be easier with project conduit. Will that provide hooks we need on the Mozilla side to build the automation described above? I imagine I can use pulse to monitor commits that make it to m-c.
I have also pondered creating an upstream PR for ongoing reviews in Chromium, and it would mean that the stability checking infrastructure does not need to be duplicated. However, the big issue I see is what happens if an upstream reviewer has comments at that point. They can't comment on the original review, so discussion may be split across review systems. What to do?
My "plan" was just to add a comment in the review, and maybe a label, indicating that review is happening in another system and hope that people don't go looking for extra reviews (the point of this design is obviously to get the early feedback on mergability and stability checking, not to get more review upstream). Having said that, one way sync of all comments made in GH to bugzilla is a thing that one could do.
glob: My understanding is that you are working on something related to this as part of the conduit project (alloy, perhaps?). Can you comment on whether you are expecting to cover any of the use cases above and if so when you expect your tooling to be available?
Flags: needinfo?(glob)
(In reply to James Graham [:jgraham] from comment #4)
> glob: My understanding is that you are working on something related to this
> as part of the conduit project (alloy, perhaps?). Can you comment on whether
> you are expecting to cover any of the use cases above and if so when you
> expect your tooling to be available?

conduit isn't related to this (it's for tracking commits and reviews only), and the alloy design is now defunct.

i'm working on a similar sounding system for overlaying github's servo repo onto mozilla central (servo-vcs-sync).
the core workflow is quite different to what you've described, so your requirements probably will not be satisfied by servo-vcs-sync.

in its simplest form the current plan has all changes to servo flow from github to mercurial; the servo directory on m-c cannot be updated directly by developers.  instead commits that touch servo will be rerouted to github via a PR where they flow through the normal servo CI and landing mechanisms.  all changes to servo on github are continuously synchronised to mercurial.  the complexity comes in dealing with backouts, as well as stylo's requirement to land changes to servo and m-c simultaneously. 

stylo is the focus of this work.  it should be possible to extend it to support other repositories, however that won't be considered until the stylo synchronisation work has been completed.
Flags: needinfo?(glob)
You need to log in before you can comment on or make changes to this bug.