Hi,
On Tue, Aug 09, 2016 at 08:17:47PM -0500, Lars Bergstrom wrote:
> But in this model, there's also "is this a failure from one of the N
> PRs before me?" which isn't a type of failure that is common (AFAIK)
> when contributing to OSS projects. Intermittents, especially when they
> lead to PR b
On Wed, Aug 10, 2016 at 6:47 AM, Lars Bergstrom
wrote:
> But in this model, there's also "is this a failure from one of the N
> PRs before me?" which isn't a type of failure that is common (AFAIK)
> when contributing to OSS projects. Intermittents, especially when they
> lead to PR bitrot, alread
On Mon, Aug 8, 2016 at 11:16 AM, Olaf Buddenhagen
wrote:
>
>> This seems to trade time for machines by optimistically assuming all
>> previous PRs passed tests.
>
> Right.
>
> As long as intermittent failures are rare, I think it's a fair
> assumption. (Actual bugs showing up in pre-commit testing
If an intermittent failure happens in an auto-rollup job, it'll just split
it and run all the tests again on the halves. Assuming the intermittent is
rare, both those halves will probably pass and it'll land. It has log[2]N
tries before it gives up.
If the intermittent is common, we want to do wha
Hi,
On Thu, Aug 04, 2016 at 09:41:00AM -0600, Jack Moffitt wrote:
> > My point is that I believe it's possible to create a setup doing full
> > pre-commit testing -- with all the advantages it brings over post-commit
> > testing -- while avoiding the scalability problems of the existing setup
> >
Hi,
On Thu, Aug 04, 2016 at 12:45:50PM -0700, Bobby Holley wrote:
> One fundamental problem with precommit testing the precise commit to be
> merged is that intermittents are more costly. You either have to hold up
> the pipeline while you retrigger the intermittent job, or throw away all of
> th
Hi,
On Thu, Aug 04, 2016 at 04:58:06PM +, Michael Howell wrote:
> Actually (though I've been busy implementing other things), I've been
> planning a somewhat different way to solve the scalability problems that I
> called "auto rollup."
[...]
In the absence of intermittent failures, this sho
Hi,
On Thu, Aug 04, 2016 at 12:45:24PM -0600, Jack Moffitt wrote:
> > Actually (though I've been busy implementing other things), I've been
> > planning a somewhat different way to solve the scalability problems that I
> > called "auto rollup."
[...]
> It does share one of the same drawbacks as t
Hi,
On Fri, Aug 05, 2016 at 11:03:27AM +0530, Manish Goregaokar wrote:
> At the time, Firefox's model wouldn't fit well because semantic
> conflicts during merge are an issue -- not actual git merge conflicts,
> but two changes which are compatible with their respective parents
> but not with eac
This reminds me of the original system I proposed for Rust back when
it reached the point where PRs were coming in faster than we could
test them. It's similar to what Michael proposed, though a bit more
involved: https://gist.github.com/Manishearth/f2971973e164be03890a
(yes, it does allude to bina
One fundamental problem with precommit testing the precise commit to be
merged is that intermittents are more costly. You either have to hold up
the pipeline while you retrigger the intermittent job, or throw away all of
the green results you got and try again later. This doesn't scale to that
~600
04.1000 < jgraham> I'm pretty sure every discussion I've ever seen of
commit queues has ended with someone saying "we should binary search on the
queue"
04.1000 < jgraham> I'm also pretty sure that zero times so far has anyone
actually implemented that proposal :/
On Thu, Aug 4, 2016 at 11:45 AM
> Actually (though I've been busy implementing other things), I've been
> planning a somewhat different way to solve the scalability problems that I
> called "auto rollup."
This is more or less the direction I've thought we'd move in as well.
Basically try in bigger batches but have blame pinpoint
Actually (though I've been busy implementing other things), I've been
planning a somewhat different way to solve the scalability problems that I
called "auto rollup."
* Approved Pull Requests (PRs) are pushed to the end of a queue as normal.
They are marked as elligible for auto-rollup by default.
> My point is that I believe it's possible to create a setup doing full
> pre-commit testing -- with all the advantages it brings over post-commit
> testing -- while avoiding the scalability problems of the existing setup
> is Servo.
It depends what you mean by scalability. Doesn't pipelining the
Hi,
On Tue, Aug 02, 2016 at 04:33:12PM +0530, Manish Goregaokar wrote:
> This sounds like a useful optimization; and it can be applied to the system
> after it is set up.
>
> I believe that the autoland model works like this anyway, though I'm not
> 100% sure.
>
> But we could do this on the Se
This sounds like a useful optimization; and it can be applied to the system
after it is set up.
I believe that the autoland model works like this anyway, though I'm not
100% sure.
But we could do this on the Servo side.
-Manish Goregaokar
___
dev-serv
Hi,
On Wed, Jun 22, 2016 at 09:57:22AM -0700, Bobby Holley wrote:
> 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
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 kee
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
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 wrote:
> If the model you're proposing is "almost isomorphic" to roll ups, then why
> not just use roll ups?
>
> On Wed, Jun 22,
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 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 fe
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 sign
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
On Wed, Jun 22, 2016 at 5:17 PM, Manish Goregaokar
wrote:
> On Wed, Jun 22, 2016 at 7:38 PM, Boris Zbarsky wrote:
>
> > As a matter of dealing with test breakage and how it's resolved, do you
> > also prefer doing a bunch of commits and only then running tests, and if
> > they fail closing down
On Wed, Jun 22, 2016 at 7:38 PM, Boris Zbarsky wrote:
> As a matter of dealing with test breakage and how it's resolved, do you
> also prefer doing a bunch of commits and only then running tests, and if
> they fail closing down the tree until it's all resolved? If not, how is
> this substantivel
On 6/22/16 9:52 AM, Manish Goregaokar wrote:
This has one significant drawback: it places a pretty serious burden on
whoever performs the sync. In particular, in addition to merging the
actual code (already needs some expertise), they become responsible for
handling any test failures that arise
> This has one significant drawback: it places a pretty serious burden on
> whoever performs the sync. In particular, in addition to merging the
> actual code (already needs some expertise), they become responsible for
> handling any test failures that arise as a result of changes in the "other"
>
On 22/06/16 14:27, Boris Zbarsky wrote:
1) One side (the wpt side) has pretty trivial integration tests: it
basically just tests filename length. So if Gecko-side changes break
those tests fixing is not too terrible.
2) The other side (the gecko side) has a way to annotate failing
things, and
On 6/22/16 8:47 AM, Manish Goregaokar wrote:
Changes to webrender would be made in m-c or servo/webrender,
whichever is more convenient, and there is a periodic sync operation.
This has one significant drawback: it places a pretty serious burden on
whoever performs the sync. In particular, in
On discussing this in IRC, it occurs to me that my alternate solution was
poorly worded. The idea is not *necessarily* to publish style as a crate.
As I understand it, crates like webrender/rust-url which Gecko would like
to directly use (but are not part of components/) will be vendored in tree,
On 20/06/16 17:01, Lars Bergstrom wrote:
> https://docs.google.com/document/d/1uubYE7JXaVY10PoAY9BVx8A-T11ZxP1RYqNOrFJwdcU
This document proposes, for code in servo/servo that is shared with Gecko:
> 1) The code in servo/servo is all mirrored into a directory in
> mozilla-central
>
> 2) When a P
On 6/21/16 12:20 PM, Lars Bergstrom wrote:
I'm still a bit worried about this unless the revert rate comes down pretty
significantly for any shared branch between servo and gecko.
That's fair. We should certainly not make inbound that shared branch! :)
But we'll see how the proposals come
On Jun 21, 2016, at 8:39 AM, Boris Zbarsky wrote:
> On 6/21/16 8:34 AM, Lars Bergstrom wrote:
>> If a backout lands as a `git revert` of the offending commit(s) I'm
>> certainly less concerned, as that's annoying but not impossible for people
>> to continue rebasing against.
>
> Right, that's
On 6/21/16 8:34 AM, Lars Bergstrom wrote:
If a backout lands as a `git revert` of the offending commit(s) I'm certainly
less concerned, as that's annoying but not impossible for people to continue
rebasing against.
Right, that's how backouts land.
The way it was explained to me (and I may h
On 21/06/16 13:34, Lars Bergstrom wrote:
On Jun 20, 2016, at 9:25 PM, Boris Zbarsky wrote:
On 6/20/16 8:35 PM, Lars Bergstrom wrote:
Backouts came up in the discussion, and I tried to make it pretty
clear that they are not compatible with a GitHub-style
development model (even if you *could*
On Jun 20, 2016, at 9:25 PM, Boris Zbarsky wrote:
>
> On 6/20/16 8:35 PM, Lars Bergstrom wrote:
>> Backouts came up in the discussion, and I tried to make it pretty clear that
>> they are not compatible with a GitHub-style development model (even if you
>> *could* hypothetically do crazy things
My main issue is that backouts aren't addressed. They are reasonably common
in m-c (admittedly, this was a few years ago; I haven't been watching
Firefox dev lately) due to the model where tests run after merges. On the
other hand, Servo's model never has backouts, and isn't well equipped to
deal w
On 6/20/16 8:35 PM, Lars Bergstrom wrote:
Backouts came up in the discussion, and I tried to make it pretty clear that
they are not compatible with a GitHub-style development model (even if you
*could* hypothetically do crazy things like force-pushing rewritten histories
to master).
Wait, wh
On Jun 20, 2016, at 5:18 PM, Jack Moffitt wrote:
>
> I think the idea was that Servo code won't land until post-commit
> Gecko tests pass? Otherwise I'm not sure what we do about Gecko side
> backouts.
The last thing I was told is that we would be landing Servo commits to a branch
that is *neve
> Does this also mean servo is going to move off of homu, and lose pre-commit
> testing? How is the contributor experience going to be impacted by the
> change?
Servo's own tests will still run pre-commit for both Servo and Gecko
changes. Some subset of Gecko test will run post commit. If you chan
Does this also mean servo is going to move off of homu, and lose pre-commit
testing? How is the contributor experience going to be impacted by the
change?
On Mon, Jun 20, 2016 at 8:01 AM, Lars Bergstrom
wrote:
> As many of you may have seen from the document
> (
> https://docs.google.com/documen
> The API is probably fine, but there will be a *ton* of coordinated changes
> across Firefox/WR here. Shader tuning, implementation bug fixing, etc. None
> of these changes will be tested by the autolander in the context of Firefox
> if WR is a separate repo, so they will have to get "bounced"
> On Jun 20, 2016, at 10:16 AM, Jack Moffitt wrote:
>
>> 2) Move webrender and webrender_traits back into the Servo repository.
>
> WebRender has a small and stable API. This API didn't even need to
> change in WebRender 2 from my understanding. This means we'll be
> moving a very low coupling d
> 2) Move webrender and webrender_traits back into the Servo repository.
>
> Because WebRender and Stylo are the two biggest projects that will
> need to be worked on in a cross-cutting way across Firefox and Servo,
> we'd like to have them out of a separate GitHub repo (with its "update
> version,
As many of you may have seen from the document
(https://docs.google.com/document/d/1uubYE7JXaVY10PoAY9BVx8A-T11ZxP1RYqNOrFJwdcU/edit)
and discussions on dev-build and at the workweek, we have an
increasing desire to be able to try to develop and potentially ship
Servo code in Firefox. While this is
46 matches
Mail list logo
