Coordinating rollups across two repos will be a pain. The proposed automation sounds better to me.
-Manish Goregaokar On Thu, Jun 23, 2016 at 10:08 AM, Michael Howell <michaelhowell...@gmail.com > wrote: > If the model you're proposing is "almost isomorphic" to roll ups, then why > not just use roll ups? > > On Wed, Jun 22, 2016, 09:58 Bobby Holley <bobbyhol...@gmail.com> wrote: > > > I just chatted with Manish a little bit to sort out some details and > > misunderstandings, and I think we're much more on the same page now. > > > > A few high-level points worth emphasizing: > > * Making the Homu queue take longer would be bad and we should avoid > that. > > I believe the proposal would actually significantly reduce landing > latency. > > * The proposal does not involve hooking servo/servo up to mozilla-inbound > > and its associated churn. As long as gecko development uses the > > mozilla-inbound model, servo/servo would be linked to a much-more-stable > > "mozilla-servo" integration repo, which will have very few backouts and > > should never be closed modulo infra issues. > > * Updating the code in both repos "in lockstep" is central to the plan, > > because it prevents divergent forks. > > * The details of how/when tests are run involve a lot of tweakable > > parameters, and I am optimistic that we can adjust them to solve any pain > > points. > > > > In a bit more detail, there are basically 3 ways to manage CI: > > (1) The mozilla-inbound model (land possibly-untested stuff, run CI > > post-commit, perform backouts and close tree as necessary) > > (2) The bors/homu model (run the full suite on the precise commit that > will > > be merged, and only merge it when green) > > (3) The relaxed bors/homu model: Run CI in parallel on pending commits. > Any > > mergable commits with "recent enough" green CI runs can be merged. We do > > additional periodic post-merge CI runs on the master branch to spot the > > occasional intra-commit bustage. > > > > (1) obviously sucks and (2) doesn't scale well. The proposal is to do > > something like (3) for both projects [1]. This is the long-term plan for > > Gecko development anyway (i.e. mandatory pre-commit testing), and > relaxing > > the strict homu/bors model would significantly increase responsiveness > and > > throughput on the servo/servo side. > > > > The question of exactly which pre-commit tests should be run for which > > commits is a heuristic one that we can tweak. For example, we may decide > > that changes to components/style require pre-commit gecko test runs, but > > version bumps on leaf-y dependencies are safe enough to leave to the > > post-commit sanity checking. We can play with that as we go. > > > > [1] It's worth noting that (3) is _almost_ isomorphic to what Rust does > > (merging rollups of commits with green CI), which the primary difference > > being whether rollups are tested pre- or post-commit. > > > > On Wed, Jun 22, 2016 at 9:03 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > > > > > On 6/22/16 11:17 AM, Manish Goregaokar wrote: > > > > > >> We don't close down the tree except for CI fires > > >> > > > > > > Yes, I understand your model. You don't have to explain it to me. > > > > > > I was just pointing out that for normal commits you prefer the model of > > > test-each-thing, but for style system you would prefer the model of > > > just-test-every-so-often. I realize the reasons for that too, but I > > think > > > we have a different evaluation of the resulting costs. In > particular.... > > > > > > If the tests fail for a PR, it is taken out of the queue until it is > > fixed > > >> and > > >> reapproved. > > >> > > > > > > My question is what happens when a PR stalls like this for months > because > > > by the time it's fixed something else has broken. I expect this to > > happen > > > every so often when the PR is the style system merge. > > > > > > m-c does not have this model, and I'd also like to prevent marrying our > > CI > > >> times to those of m-c, or being affected by m-c backouts. > > >> > > > > > > I understand and sympathize with that. > > > > > > That's why I like the sync model, it concentrates all of the conflict > in > > >> one operation > > >> > > > > > > At the cost of possibly making that operation impossible to complete. > > > > > > instead of distributing it everywhere and making every PR that touches > > >> anything that affects style suffer. The syncing operation is also > async > > >> (ha!) -- while being performed other Servo work can continue. > > >> > > > > > > Which is what may well make it impossible to complete the sync. > > > > > > Sending PRs which look like they need testing to gecko-try should catch > > >> most issues, > > >> the only remaining issues are when a PR (like a wrong refactor, or > > >> something) which wasn't sent through gecko-try breaks stylo, or when > > >> something on Gecko's vendor dir managed to land between the time the > > Servo > > >> PR was tested and landed. I postulate these two cases will be > relatively > > >> rare, and these will be the only times the sync fails. > > >> > > > > > > Right, I think our fundamental disagreement is a matter of assumptions > > > about frequency. I hope that you're right about these failures being > > rare, > > > but expect that you're wrong and worry about the failure modes if you > > > are.... > > > > > > This is actually pretty close to the proposed model in the doc, but it > > >> gives a lot more leeway in when the sync should happen. > > >> > > > > > > Well, and assumes that reviewers are decent at evaluating the "may need > > > stylo testing" predicate. > > > > > > The proposed model is basically equivalent to this except syncs are > > >> mandatorily part of any PR > > >> that affects style, and can make the queue clog up. Here based on > > various > > >> factors you can choose not to sync (e.g. if the queue is already full; > > you > > >> can wait to trigger the sync until it empties, or if the PR probably > > >> doesn't need a sync). > > >> > > > > > > I agree that having such flexibility is not unreasonable. > > > > > > We can then by trial and error figure out the best > > >> policy for when to sync and when not to sync balancing the need for > fast > > >> CI > > >> times and the need for things to not cause colossal merge conflicts. > > >> > > > > > > That seems fair. Ideally we would end up with a "sync pretty much > every > > > time" setup. > > > > > > Sure they can, but they should be less likely to :) > > >> > > > > > > That hasn't been my experience with refactorings at all! > > > > > > We will still have the full CI run on a sync so these will get caught, > > just > > >> not immediately. > > >> > > > > > > Right. The question is how much piles up before a sync. So more > > granular > > > syncs are better if they can be arranged. > > > > > > > > > -Boris > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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
