This is awesome - thanks Emilio!
On Thu, Jan 3, 2019 at 3:27 PM Emilio Cobos Álvarez
wrote:
> I've always been slightly annoyed at the fact that Gecko used to have
> multiple classes for the same concept of a document node without any
> clear separation these days (nsIDocument and nsDocument).
I've always been slightly annoyed at the fact that Gecko used to have
multiple classes for the same concept of a document node without any
clear separation these days (nsIDocument and nsDocument).
Over the last week I decided to change that by first merging both in:
Thank you Joel for writing up this proposal!
Are you also proposing that we stop the linux64-opt and win64-opt builds as
well, except for leaving them as an available option on try? If we're not
testing them on integration or release branches, there doesn't seem to be
much purpose in doing the
On Thu, Jan 3, 2019 at 7:22 PM Steve Fink wrote:
> I get
> quite a bit of value out of the resulting faster hack-try-debug cycles;
> I would imagine it to be at least as useful to have a turnaround time of
> 1 hour for opt vs 2 hours for pgo.
>
+1. The past week I've been Try-debugging (1) an
I don't think its much burden, but when we have code complexity it can add
up with a matter of "how useful is this really.." Even if maintenance
burden is low it is still a tradeoff. I'm just saying I suspect its
possible to do this, but not sure if it is useful in the end (and I'm not
looking to
On 03/01/2019 18:16, Steve Fink wrote:
Good points, but given that most failures will show up debug builds, it
seems like a more relevant metric is the difference between time(Opt) vs
min(time(debug), time(PGO)). Though debug builds may run slow enough
that it boils down to what you said?
On 01/03/2019 10:07 AM, Justin Wood wrote:
on the specific proposal front I can envision us allowing tests to be run
on non-pgo builds via triggers (so never by default, but always
backfillable/selectable) should someone need to try and bisect an issue
that is discovered... I'm not sure if the
On 01/03/2019 09:51 AM, Jonathan Kew wrote:
On 03/01/2019 16:17, jmaher wrote:
What are the risks associated with this?
1) try server build times will increase as we will be testing on PGO
instead of OPT
2) we could miss a regression that only shows up on OPT, but if we
only ship PGO and
I should say that the shippable build proposal (
https://groups.google.com/d/msg/mozilla.dev.planning/JomJmzGOGMY/vytPViZBDgAJ)
doesn't seem to intersect negatively with this.
And in fact I think these two proposals compliment each other quite nicely.
Additionally I have no concerns over this
On 03/01/2019 16:17, jmaher wrote:
I would like to propose that we do not run tests on linux64-opt, windows7-opt,
and windows10-opt.
Why am I proposing this:
1) All test regressions that were found on trunk are mostly on debug, and in
fewer cases on PGO. There are no unique regressions found
On Thu, Jan 3, 2019 at 8:43 AM Brian Grinstead
wrote:
> Artifact builds don’t work with PGO, do they? When I do `-p all` on an
> artifact try push I get busted PGO builds (for example:
> https://treeherder.mozilla.org/#/jobs?repo=try=7f8ead55ca97821c60ef38af4dec01b8bff0fdf3=219655864).
> What's
Would this apply to talos as well? I’ve wondered before if we should care at
all about opt-only talos regressions for platforms where we ship PGO. IME quite
a number of talos changes (both improvements and regressions) only show up on
one or the other, so dropping one would simplify things.
CC Callek
How will this interact with the "shippable builds" project that Callek
posted
about awhile back? My understanding is there's a high probability PGO is
going away. Would it make sense to wait for that to project to wrap up?
-Andrew
On Thu, Jan 3, 2019 at 11:20 AM jmaher wrote:
> I
Artifact builds don’t work with PGO, do they? When I do `-p all` on an artifact
try push I get busted PGO builds (for example:
https://treeherder.mozilla.org/#/jobs?repo=try=7f8ead55ca97821c60ef38af4dec01b8bff0fdf3=219655864).
What's needed to make it work? Requiring a full build for
On 03/01/2019 16:17, jmaher wrote:
What are the risks associated with this?
1) try server build times will increase as we will be testing on PGO instead of
OPT
2) we could miss a regression that only shows up on OPT, but if we only ship
PGO and once we leave central we do not build OPT, this
Can we set it up so we can manually runs tests on opt builds; but they
aren't by default?
I've had many instances where opt (and pgo) fail; but I can't
reproduce a test failure locally and can only do it on try. Letting me
run that test on the opt build will save the additional pgo build time
I would like to propose that we do not run tests on linux64-opt, windows7-opt,
and windows10-opt.
Why am I proposing this:
1) All test regressions that were found on trunk are mostly on debug, and in
fewer cases on PGO. There are no unique regressions found in the last 6 months
(all the data
This is a hijacked accounts for payments from lotto for a decade
lisalindsa...@live.co.uk li...@gmail.com devises identification etc stolen from
me for the past decade or mabe more ive been talking to phsicics on media web
maria tara Teresa, and mary from america im scottish white 41 years old
18 matches
Mail list logo
