Re: PSA: nsIDocument is now mozilla::dom::Document.
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). > > Over the last week I decided to change that by first merging both in: > >https://bugzilla.mozilla.org/show_bug.cgi?id=1516366 >https://bugzilla.mozilla.org/show_bug.cgi?id=1516853 > > And finally renaming nsIDocument to the more usual naming convention for > DOM objects / WebIDL-exposed things these days in: > >https://bugzilla.mozilla.org/show_bug.cgi?id=1517241 > > So the end result is that now nsIDocument and nsDocument are the same > thing and are called mozilla::dom::Document. > > It was quite a big patch (thanks Olli for all the reviews!), but > over-all I think the end result is nicer. > > Anyhow, this is just a PSA since it's such a common type to be used, in > case you don't find something that used to live there :) > >-- Emilio > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: nsIDocument is now mozilla::dom::Document.
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: https://bugzilla.mozilla.org/show_bug.cgi?id=1516366 https://bugzilla.mozilla.org/show_bug.cgi?id=1516853 And finally renaming nsIDocument to the more usual naming convention for DOM objects / WebIDL-exposed things these days in: https://bugzilla.mozilla.org/show_bug.cgi?id=1517241 So the end result is that now nsIDocument and nsDocument are the same thing and are called mozilla::dom::Document. It was quite a big patch (thanks Olli for all the reviews!), but over-all I think the end result is nicer. Anyhow, this is just a PSA since it's such a common type to be used, in case you don't find something that used to live there :) -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 builds. On Thu, 3 Jan 2019 at 11:20, 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 in the last 6 > months (all the data I looked at) that are exclusive to OPT builds. > 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO > builds, we do not run tests on plan OPT builds > 3) This will reduce the jobs (about 16%) we run which in turn reduces, cpu > time, money spent, turnaround time, intermittents, complexity of the > taskgraph. > 4) PGO builds are very similar to OPT builds, but we add flags to generate > profile data and small adjustments to build scripts behind MOZ_PGO flag > in-tree, then we launch the browser, collect data, and repack our binaries > for faster performance. > 5) We ship PGO builds, not OPT builds > > 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 is a very low > risk. > > I would like to hear any concerns you might have on this or other areas > which I have overlooked. Assuming there are no risks which block this, I > would like to have a decision by January 11th, and make the adjustments on > January 28th when Firefox 67 is on trunk. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 intermittent Talos orange (affected only Win64 opt and pgo, bug 1516679) and (2) an intermittent dt8 orange (affected only Win32 opt and pgo, bug 1516967). This was a pretty annoying process, but pgo builds would have made this much worse. I'd really appreciate it if we considered keeping "opt" as an optional configuration for these use cases - it will save some people a lot of time. Thanks, Jan > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 make the call on that) ~Justin Wood (Callek) On Thu, Jan 3, 2019 at 1:22 PM Steve Fink wrote: > 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 code maintenance burden is > worth > > it for the benefit but I don't hold a strong opinion there. > > Is it a lot of maintenance? We have this for some other jobs > (linux64-shell-haz is the one I'm most familiar with, but it's a > standalone job so doesn't have non-toolchain graph dependencies). 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. > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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? Looking at Windows 64-bit jobs from a random push ( https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=63027ff03effb04ed4bf53bbb0c9aa1bad4b4c9b ), I see: pgo: build=119min + Wd1=15min opt: build=55min + Wd1=13min debug: build=46min + Wd1=22min So by that, you get opt and debug Wd1 results back at the same time (67-68min) and pgo Wd1 results take twice as long (134min). I imagine there are much slower test jobs that make this situation cloudier, but assuming the general pictures holds then it seems like opt is mostly redundant with debug. I think a good rule of thumb is that debug tests are about twice as slow as opt, with the same chunking. So for a test job taking closer to an hour on opt (which some do), you can easily be at 45 minutes longer for opt results than debug. We could of course chunk more, but there's overhead there that would eat some of the regained capacity. I wonder if an alternative would be running opt+debug on integration branches and pgo+debug on central. That would have the obvious disadvantage that pgo-only failures would be caught much later, but it would keep current end-to-end times for integration and slightly better capacity savings. I don't know how common pgo-only failures are compared to other things that we are only catching on central. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 code maintenance burden is worth it for the benefit but I don't hold a strong opinion there. Is it a lot of maintenance? We have this for some other jobs (linux64-shell-haz is the one I'm most familiar with, but it's a standalone job so doesn't have non-toolchain graph dependencies). 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 once we leave central we do not build OPT, this is a very low risk. It's not just tryserver build times. Presumably this will also tend to increase the time between a patch landing on inbound or autoland and any resulting test failures showing up. This seems like a negative in that it means more patches are likely to have landed on top of the regressing one in the meantime, potentially complicating backouts, and the original developer may be less likely to still be around for a quick investigation/fix. How long does it typically take for full PGO test results to be available for a push? How does that compare to full Opt test results? ISTM that if the increase is quite marginal, this may be OK, but if the latency becomes substantially greater, there will be a continual cost in increased developer and/or sheriff pain. 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? Looking at Windows 64-bit jobs from a random push ( https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=63027ff03effb04ed4bf53bbb0c9aa1bad4b4c9b ), I see: pgo: build=119min + Wd1=15min opt: build=55min + Wd1=13min debug: build=46min + Wd1=22min So by that, you get opt and debug Wd1 results back at the same time (67-68min) and pgo Wd1 results take twice as long (134min). I imagine there are much slower test jobs that make this situation cloudier, but assuming the general pictures holds then it seems like opt is mostly redundant with debug. The majority of your currently opt-triggered backouts will still happen, just using debug results now. This is assuming debug normally catches a superset of the problems that opt would, which is asserted in #1 of jmaher's post. +1 from me for killing off opt tests. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 work taking place prior to my work being complete. 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 code maintenance burden is worth it for the benefit but I don't hold a strong opinion there. ~Justin Wood (Callek) On Thu, Jan 3, 2019 at 11:44 AM Andrew Halberstadt wrote: > 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 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 I looked at) that are exclusive to OPT builds. >> 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO >> builds, we do not run tests on plan OPT builds >> 3) This will reduce the jobs (about 16%) we run which in turn reduces, >> cpu time, money spent, turnaround time, intermittents, complexity of the >> taskgraph. >> 4) PGO builds are very similar to OPT builds, but we add flags to >> generate profile data and small adjustments to build scripts behind MOZ_PGO >> flag in-tree, then we launch the browser, collect data, and repack our >> binaries for faster performance. >> 5) We ship PGO builds, not OPT builds >> >> 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 is a very low >> risk. >> >> I would like to hear any concerns you might have on this or other areas >> which I have overlooked. Assuming there are no risks which block this, I >> would like to have a decision by January 11th, and make the adjustments on >> January 28th when Firefox 67 is on trunk. >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 in the last 6 months (all the data I looked at) that are exclusive to OPT builds. 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO builds, we do not run tests on plan OPT builds 3) This will reduce the jobs (about 16%) we run which in turn reduces, cpu time, money spent, turnaround time, intermittents, complexity of the taskgraph. 4) PGO builds are very similar to OPT builds, but we add flags to generate profile data and small adjustments to build scripts behind MOZ_PGO flag in-tree, then we launch the browser, collect data, and repack our binaries for faster performance. 5) We ship PGO builds, not OPT builds 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 is a very low risk. It's not just tryserver build times. Presumably this will also tend to increase the time between a patch landing on inbound or autoland and any resulting test failures showing up. This seems like a negative in that it means more patches are likely to have landed on top of the regressing one in the meantime, potentially complicating backouts, and the original developer may be less likely to still be around for a quick investigation/fix. How long does it typically take for full PGO test results to be available for a push? How does that compare to full Opt test results? ISTM that if the increase is quite marginal, this may be OK, but if the latency becomes substantially greater, there will be a continual cost in increased developer and/or sheriff pain. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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&revision=7f8ead55ca97821c60ef38af4dec01b8bff0fdf3&selectedJob=219655864). > What's needed to make it work? Requiring a full build for frontend-only > changes would increase the turnaround time and resource savings in (3). > I can partly address this. There are two things at play (at least): 1) automation builds need a special configuration piece in place to properly support artifact builds. Almost certainly that's not in place for PGO builds, since it's such an unusual thing to do: "you want to pack PGO binaries into a development build... why?" But there's really no reason we can't do that in automation so I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=15175323 for these things. It's not high priority but we might as well capture the request; in general, we always want try pushes to succeed with sensible results if we can arrange it. 2) locally, we need to teach the artifact code to sniff whatever mozconfig options say "I'm doing PGO" and fetch the right binaries based on that. I think that enabling PGO locally is a little delicate, and I know that chmanchester (and others?) is working hard to make this more robust, so perhaps this is easy or becomes easy soon. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1517532 to track this. If I'm wrong about the feasibility of these things, please update the tickets! Best, Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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. Brian > On Jan 3, 2019, at 8:17 AM, 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 in the last 6 > months (all the data I looked at) that are exclusive to OPT builds. > 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO builds, > we do not run tests on plan OPT builds > 3) This will reduce the jobs (about 16%) we run which in turn reduces, cpu > time, money spent, turnaround time, intermittents, complexity of the > taskgraph. > 4) PGO builds are very similar to OPT builds, but we add flags to generate > profile data and small adjustments to build scripts behind MOZ_PGO flag > in-tree, then we launch the browser, collect data, and repack our binaries > for faster performance. > 5) We ship PGO builds, not OPT builds > > 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 is a very low risk. > > I would like to hear any concerns you might have on this or other areas which > I have overlooked. Assuming there are no risks which block this, I would > like to have a decision by January 11th, and make the adjustments on January > 28th when Firefox 67 is on trunk. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 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 I looked at) that are exclusive to OPT builds. > 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO > builds, we do not run tests on plan OPT builds > 3) This will reduce the jobs (about 16%) we run which in turn reduces, cpu > time, money spent, turnaround time, intermittents, complexity of the > taskgraph. > 4) PGO builds are very similar to OPT builds, but we add flags to generate > profile data and small adjustments to build scripts behind MOZ_PGO flag > in-tree, then we launch the browser, collect data, and repack our binaries > for faster performance. > 5) We ship PGO builds, not OPT builds > > 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 is a very low > risk. > > I would like to hear any concerns you might have on this or other areas > which I have overlooked. Assuming there are no risks which block this, I > would like to have a decision by January 11th, and make the adjustments on > January 28th when Firefox 67 is on trunk. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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&revision=7f8ead55ca97821c60ef38af4dec01b8bff0fdf3&selectedJob=219655864). What's needed to make it work? Requiring a full build for frontend-only changes would increase the turnaround time and resource savings in (3). Brian > On Jan 3, 2019, at 8:17 AM, 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 in the last 6 > months (all the data I looked at) that are exclusive to OPT builds. > 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO builds, > we do not run tests on plan OPT builds > 3) This will reduce the jobs (about 16%) we run which in turn reduces, cpu > time, money spent, turnaround time, intermittents, complexity of the > taskgraph. > 4) PGO builds are very similar to OPT builds, but we add flags to generate > profile data and small adjustments to build scripts behind MOZ_PGO flag > in-tree, then we launch the browser, collect data, and repack our binaries > for faster performance. > 5) We ship PGO builds, not OPT builds > > 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 is a very low risk. > > I would like to hear any concerns you might have on this or other areas which > I have overlooked. Assuming there are no risks which block this, I would > like to have a decision by January 11th, and make the adjustments on January > 28th when Firefox 67 is on trunk. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 is a very low risk. Couldn't we leave opt enabled for try and just stop running it on integration/central branches? That would allow faster/cheaper try but preserve the benefits you list above without any additional increase in risk compared to today. I do wonder how that would interact with artifact builds though; maybe it would be worth running opt *builds* just not opt *tests* (which I think is your proposal anyway). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 (both the cloud-cost time and the developer turn-around time.) -tom On Thu, Jan 3, 2019 at 4:20 PM 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 in the last 6 > months (all the data I looked at) that are exclusive to OPT builds. > 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO builds, > we do not run tests on plan OPT builds > 3) This will reduce the jobs (about 16%) we run which in turn reduces, cpu > time, money spent, turnaround time, intermittents, complexity of the > taskgraph. > 4) PGO builds are very similar to OPT builds, but we add flags to generate > profile data and small adjustments to build scripts behind MOZ_PGO flag > in-tree, then we launch the browser, collect data, and repack our binaries > for faster performance. > 5) We ship PGO builds, not OPT builds > > 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 is a very low risk. > > I would like to hear any concerns you might have on this or other areas which > I have overlooked. Assuming there are no risks which block this, I would > like to have a decision by January 11th, and make the adjustments on January > 28th when Firefox 67 is on trunk. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposal to adjust testing to run on PGO builds only and not test on OPT builds
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 I looked at) that are exclusive to OPT builds. 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO builds, we do not run tests on plan OPT builds 3) This will reduce the jobs (about 16%) we run which in turn reduces, cpu time, money spent, turnaround time, intermittents, complexity of the taskgraph. 4) PGO builds are very similar to OPT builds, but we add flags to generate profile data and small adjustments to build scripts behind MOZ_PGO flag in-tree, then we launch the browser, collect data, and repack our binaries for faster performance. 5) We ship PGO builds, not OPT builds 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 is a very low risk. I would like to hear any concerns you might have on this or other areas which I have overlooked. Assuming there are no risks which block this, I would like to have a decision by January 11th, and make the adjustments on January 28th when Firefox 67 is on trunk. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to restrict to secure contexts: navigator.geolocation
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 tbis devise is mu partners becasue mine sare going amissin all time or been deliberatly briken this is a js3 devises from apple that i won in 201w have been taken also its trickery if my eyes sught id advise u to talk to naria or pedre i can hear them and its in my circle of peip who are menta b friends but theres onky one person that can be doing this as hes the only 1 with information about these ive been readinf up but i do t k ow whars been done and how but emails are beenmade up in my name from phnes land property cars etc bought in my name or somein whhos pretend to be my career of some sort the email im used is lisalindsa...@live.co.uk but theres about 4 of them as i said im finding out a little each day but i dont know what kind of trouble im in as ive said i know they can see everything i do or write inthis phone if u can hrlp id appreciate your help and support but speak to the phsicics as theyve been given me guidence ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
