Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds
Thanks for asking Jan. I think 16% is the maximum we can save. In talking with a few more people, I think a middle of the road proposal would be to: Turn off linux64/windows7/windows10 opt builds+tests on autoland and mozilla-inbound. Leave them on for mozilla-central and try. What this does is allows for try to be faster as needed, continue to offer peace of mind by running the tests on m-c (and sheriffs can backfill if needed), and removes confusion about building/testing locally vs try. This would be similar to what we already see where many people only test opt on try and land and if a pgo test regresses we would need to backout. Are there any concerns with this latest proposal? On Thu, Jan 17, 2019 at 12:52 PM Jan de Mooij wrote: > Hi Joel, > > Can you say more about this point in your original email: "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." It > seems to me that if we remove non-PGO opt builds even on Try, we might use > more cpu time because there are so many Try pushes requesting opt builds. > Do we have data on this? > > Thanks, > Jan > > On Thu, Jan 17, 2019 at 5:45 PM jmaher wrote: > >> Following up on this, thanks to Chris we have fast artifact builds for >> PGO, so the time to develop and use try server is in parity with current >> opt solutions for many cases (front end development, most bisection cases). >> >> I have also looked in depth at what the impact on the integration >> branches would be. In the data set from July-December (H2 2018) there were >> 11 instances of tests that we originally only scheduled in the OPT config >> and we didn't have PGO or Debug test jobs to point out the regression (this >> is due to scheduling choices). Worse case scenario is finding the >> regression on PGO up to 1 hour later 11 times or roughly 2x/month. >> Backfilling to find the offending patch as we do now 24% of the time would >> be similar time. In fact running the OPT jobs on Debug instead would >> result in same time for all 11 instances (due to more chunks on debug and >> similar runtimes). In short, little to no impact. >> >> Lastly there was a pending question about talos. There is an edge case >> where we can see a regression on talos that is PGO, but it is unrelated to >> the code and just a side effect of how PGO works. I looked into that in >> https://bugzilla.mozilla.org/show_bug.cgi?id=1514829. I found that if >> we didn't get opt alerts that we would not have missed any regressions. >> Furthermore, for the regressions, for the ones that were pgo only >> regressions (very rare) there were many other regressions at the same time >> (say a build change, or test change, etc.) and usually these were accepted >> changes, backed out, or investigated on a different test or platform. In >> the past when we have determined a regression is a PGO artifact we have >> resolved it as WONTFIX and moved on. >> >> Given this summary, I feel that most concerns around removing testing for >> OPT are addressed. I would also like to extend the proposal to remove the >> OPT builds since no unit or perf tests would run on there. >> >> As my original timeline is not realistic, I would like to see if there >> are comments until next Wednesday- January 23rd, then I can follow up on >> remaining issues or work towards ensuring we start the process of making >> this happen and what the right timeline is. >> ___ >> 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: nasm will soon become a build dependency
On 1/18/19 11:20 AM, Kartikaya Gupta wrote: > Any update here? Is there a bug on file for making bootstrap install a > usable nasm? I just made one: https://bugzilla.mozilla.org/show_bug.cgi?id=1521186 It has two deps, on making the actual toolchain scripts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nasm will soon become a build dependency
Any update here? Is there a bug on file for making bootstrap install a usable nasm? On Fri, Dec 28, 2018 at 3:28 PM Andi-Bogdan Postelnicu wrote: > > I can confirm that we are having the same problem on Debian stretch and > before manually building nasm we had to disable av1 in order to be able to > move further with the static analysis builds for coverity. > > > On 28 Dec 2018, at 22:19, Botond Ballo wrote: > > > >> On Fri, Dec 21, 2018 at 4:21 PM Kartikaya Gupta wrote: > >> > >>> On Fri, Dec 21, 2018 at 4:10 PM Thomas Daede wrote: > >>> There is a toolchain build for nasm for windows: > >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1511224 > >>> > >>> If getting a newer nasm version is inconvenient for a majority of linux > >>> users, the toolchain build could be used to produce nasm binaries for > >>> mach bootstrap as well. > >> > >> I would certainly prefer this, and having this work smoothly would > >> also be good for new contributors. Having to build and install extra > >> packages is always a hassle. > > > > +1 > > > > Debian stable is in this boat as well - the latest nasm version in its > > package repositories is 2.12. > > > > This is the first time, as far as I'm aware, that building Firefox > > requires manually building another package - everything else is taken > > care of by |mach bootstrap|. > > > > Thanks, > > Botond > > ___ > > 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: How do we land `./mach vendor rust` patches, these days?
On 1/18/19 4:19 PM, David Teller wrote: > Hi everybody, > > My last two attempts to update our crates with `./mach vendor rust` > failed, not during vendoring, but when I attempted to upload the patch. > Both times, moz-phab/arcanist or phabricator simply choked during the > call and I gave up after waiting 24h for the patch to be uploaded. > > Do we have a better way to do this? Or should I use splinter for such > patches? Some large patches you can upload passing --less-context to arc directly[1]. For others (assuming you're hitting the max_post_size limit) I think you're out of luck and need to submit them via splinter[2]. Hope it helps, -- Emilio [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1517247#c3 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1492214 > Cheers, > Yoric > ___ > 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
How do we land `./mach vendor rust` patches, these days?
Hi everybody, My last two attempts to update our crates with `./mach vendor rust` failed, not during vendoring, but when I attempted to upload the patch. Both times, moz-phab/arcanist or phabricator simply choked during the call and I gave up after waiting 24h for the patch to be uploaded. Do we have a better way to do this? Or should I use splinter for such patches? Cheers, Yoric ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement and Ship: The border-{start, end}-{start, end}-radius CSS properties
> Do other browser engines implement this? > I don't know, there was no WPT for these. I didn't implement them in Blink because they were added into the spec after I sent the intent to implement. So I should send a new one for them. Also, the mapping is not clear in the spec (https://github.com/w3c/csswg-drafts/issues/3034), though there is a csswg resolution, so it should be safe. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
