From:  "Nicolas B. Pierron" <>
Date:  12 May 2016 21:53:42 Hong Kong Time

Re: Clang-format


On 05/11/2016 06:31 PM, Bill McCloskey wrote:
> On Wed, May 11, 2016 at 5:01 AM, Nicolas B. Pierron <
>> wrote:
> If the problem are the pointless arguments on dev.platform, which are
>> mistakenly considering SpiderMonkey as Gecko's property, I would totally
>> agree on moving SpiderMonkey into its own repository.
>> I do not see how indentation differences could be a speed bump, and even
>> if this was a problem, I am still not yet convinced this alone could
>> justify changing 95% of the lines of the project.
>> One thing I hate with Gecko undesired continuous integration, is that we
>> are hold responsible for failures in tests that we cannot reproduce. Having
>> a separated project would make explicit the fact that someone is
>> responsible for the integration, and for converting such test cases into
>> SpiderMonkey test cases.  I honestly think I spend more time thinking about
>> how I can reproduce some Gecko failures than anybody spent else spent about
>> thinking about indentation.
> This is a really bad attitude for Mozilla as a whole. Every one of us at
> Mozilla has a responsibility to make Firefox the best web browser. The more
> we divide ourselves into cliques and label bugs as "someone else's
> problem", the sooner we will fail. You might think it's more productive for
> you to focus on SpiderMonkey alone and let other people deal with other
> issues. Unfortunately, many of the most important bugs that span across
> different areas; with your approach, these bugs will never be fixed.

This is not some else problem, this is my problem, except that someone else 
who is much more experienced with the rest of the browser already worked out 
to figure out how to help me reproduce the issue.

Basically, what I am suggesting by having a person responsible for the 
integration of SpiderMonkey in Gecko, is to have one or multiple persons who 
would become knowledgeable about all the various parts where I am not.  Thus 
making *us* (Gecko & SpiderMonkey) more productive, by having competent 
persons working in their domain of expertise.

Thus we should no longer be stuck for weeks on problems that we have no idea 
how to address.

I know the time it takes to investigate such errors, and I value my time and 
choose by priorities, such that I can have the most impact.  When facing 
Gecko failures, I have 2 choices:
  - Spending weeks to figures them out.
  - Switching to something else.

In both cases, I waste something.  I either waste the time to figure out the 
issue, or I waste the time it took me to make the initial work.

I sometime take the second solution, in hope that fuzzers will find the 
issue, or that other bugs would be easier to investigate.  Thus reducing the 
amount of wasted time at the cost of extra latencies.

> Mozilla needs more people who understand multiple browser components. I'll
> call them superheroes because of how valuable they are. Understanding and
> reproducing browser tests can seem unrewarding, but it's a great way to
> start to understand how the rest of the system works. People on the
> SpiderMonkey team are in a great position to be superheroes: SpiderMonkey
> and XPConnect are some of the hardest parts of the browser to understand,
> and it's often necessary to step through them to debug other browser
> issues. People who already understand them have an advantage over everyone
> else.

The need for super heroes only highlight the lack of efforts from us to make 
SpiderMonkey easier to grasp from within a debugger, for embedders.

That's something I wanted to change for a while, and I think we can improve 
SpiderMonkey embedders experience.  I suggested multiple time that we should 
improve SpiderMonkey debugging experience under gdb, by giving the ability 
to set breakpoint in JS code within gdb. (including Jit code)

The more we empower people for working only on their domain(s) of expertise, 
the less we would have need for such heroes.  Having persons responsible for 
the integration would help us on that.

Nicolas B. Pierron