On 05/13/2016 12:04 AM, Ehsan Akhgari wrote:
On 2016-05-12 9:53 AM, Nicolas B. Pierron wrote:
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.
As someone who has worked on many parts of the browser, I cannot
disagree more. Bugs just don't tend to align themselves within
someone's "domain expertise". I think of bugs which seem to only
require me to only remember knowledge that I have accrued over the years
as "easy bugs", and the more I learn about different parts of the
browser, the more I come across issues that touch on the things that I
have never learned about before, or things that I haven't learned well
enough. Those I call "normal bugs".
Also bugs are only one part of our work. I have found out that the more
parts of the browser I have learned about, the more I have been able to
work on "cross-functional" things that have benefited the browser as a
whole, and nowadays these sorts of stuff are commonplace projects that
we're working on. Take e10s as an example, that project doesn't map at
all to any of the islands that we have created in our organization
and/or code base. We need more and more people to be able and willing
to step out of the little islands, as the whole world has grown much
smaller now and the islands that maybe we created for good reasons back
in the day are really just an artifact of the past.
Yes, e10s is the greatest example to highlight the difficulty which arise
from the coupling of components. How many years did we loose failing at
making it a reality? And now, we only manage to make it a reality by taking
various specialist out of their domain of expertise for multiple years,
before being able to achieve something which comes 7 years[1] (more?) too late?
e10s involves keeping multiple coupled components working as expected. Not
having such coupling, would have made the project simpler, and I think b2g
multi-process is the best way to highlight this. Thus this problems could
have been solved as a per-component bases, with specialist from each team.
[1]
https://wiki.mozilla.org/index.php?title=Electrolysis&offset=&limit=500&action=history
The current reality how web browsers are made don't afford us treating
our codebase in that way any more. To me, discussions around unifying
the coding style drill into the heart of this problem: we need to move
on from having small compartments with people painting the walls to
their heart's content, and treat the browser as the one unified beast
that it truly is. […]
When I describe the difference "style" of implementation between Gecko and
SpiderMonkey, I describe Gecko as being Java-like written in C++, and
SpiderMonkey being C with templates.
Are you suggesting that we rewrite SpiderMonkey in Java-like style?
--
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
