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
