An interesting idea, but off-topic for this thread, and probably not helpful to debate at this moment in time.
That is to say: we are inching towards a consensus across several groups on a complicated, important, and time-sensitive topic, so please keep the cats in the bag for now, or at least keep them away from the pigeons. ;-) I have a cat I would like to place among the pigeons. I'm going to start with the brave assertion that ultimately we want Servo based components in Firefox to go directly into Firefox release several times per week. "That's impossible" I hear you cry but it is common practice among web services. Fast feedback improves our ability lean and quickly get value out of our work. It won't be easy and it will require much better tools, infrastructure and processes than we have today. There will probably be some culture shock. Rust has a number of language features that make it safer to iterate quickly compared to C++ or Javascript. The question we all need to ask ourselves is "why not?". We can take that list of blockers and burn them down over the coming months. Anthony On Thursday, 23 June 2016 16:55:04 UTC+12, Manish Goregaokar wrote: > 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 _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
