SpiderMonkey standalone builds for Windows on TBPL - should they return?

[Gary Kwong]

Some may believe it is time for SpiderMonkey standalone builds for
Windows to return, as personally I am admittedly increasingly frustrated
at the increasing numbers of Windows-specific build failures. (More may
come as :glandium points out, as long as Windows standalone builds are
not on TBPL)

I understand many developers do not develop on Windows, but Windows is
one of the most widely-used platforms, and one that I fuzz on and not
having it compile blocks using, testing, fuzzing, and bisecting on it.

Bug 785798 removed them due to breakage of some sort and we've had it on
Linux since. Compilation failures have at least been responsible for bug
948301, 951587, 971426, etc.

"Please reinstate standalone SpiderMonkey builds for Windows. Releng
might want a re-assurance that someone will be on the ball to fix build
errors as necessary, but I'll leave it to the JS folks to decide."

Bug 972089[1] has all the gory details.

Does anyone disagree?

-Gary

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=972089

[Steve Fink]

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.

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?

[Gary Kwong]

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.

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.

-Gary

[Mike Hommey]

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.

> 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.

Mike

[Steve Fink]

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).

[Nicholas Nethercote]

We're even close to having warnings-as-errors shell builds on TBPL on
any platform, are we? My local builds certainly don't think so.

N

On Thu, Feb 13, 2014 at 3:59 PM, Steve Fink <sf...@mozilla.com> wrote:
> 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
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

[Nicholas Nethercote]

On Thu, Feb 13, 2014 at 4:11 PM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
> We're even close to having warnings-as-errors shell builds on TBPL on
> any platform, are we? My local builds certainly don't think so.

Dammit, that should be "We're *not* even close..."

Nick

[Steve Fink]

There are a whole bunch of green SM(e) builds. Waldo watches them
sometimes, and philor watches them all the time and nags people.

My local debug builds are warnings-free. My opt builds are definitely
not. Maybe it's because SM(e) builds only do selected warnings?