On 05/11/2016 06:31 PM, Bill McCloskey wrote:
On Wed, May 11, 2016 at 5:01 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> 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
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
