On Thu 13 Feb 2014 03:03:23 PM PST, Mike Hommey wrote: > On Thu, Feb 13, 2014 at 01:31:55PM -0800, Gary Kwong wrote: >> On 2/13/14, 12:18 PM, Steve Fink wrote: >>> Sounds like the sticking point is finding someone who will agree to >>> keep them alive. There's no point in turning them on if they're going >>> to be broken for weeks/months at a stretch. >>> >> >> This can be mitigated as per Valgrind by having per-commit builds as >> well as the build running on all important branches (fx-team, >> inbound, try, etc.) Sheriffs can back out changes which break the >> shell build. >> >>> From skimming the discussion, one thing that's unclear to me is if >>> we're talking about Windows shell builds, or Windows shell builds with >>> warnings-as-errors. I would guess the latter is what causes most of the >>> maintenance overhead? >>> >> >> I at least would like the former. > > Likewise.
So I think the decision should be about getting a warnings-as-warnings shell build, since that seems easier to achieve. How much easier; I'm not sure. I'm one of those obnoxious js devs who has never helped fix the windows builds. I seem to recall Waldo struggling to get the windows shell builds back alive not too long ago; I had the impression that was just to get it building, not warning-free. >> I suspect some folks would like the latter (warnings-as-errors), but >> that's up for discussion because there's also differing viewpoints. >> This could be a separate discussion. > > Also note that in an ideal world, there would also be mac shell builds. I *think* those were gated on switching to tooltool. Which I could probably do now without too much trouble, after having fought through it for the hazards build. Sadly, those are done with completely separate scripts. (build/tools shell script vs mozharness script). _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
