From:  Bobby Holley <bobbyholley@gmail.com>
Date:  12 May 2016 01:04:46 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: Clang-format

NNTP-Posting-Host:  63.245.214.181

On Wed, May 11, 2016 at 5:01 AM, Nicolas B. Pierron <
nicolas.b.pierron@mozilla.com> wrote:

> On 05/11/2016 02:15 AM, Jason Orendorff wrote:
>
>> instead go with Terrence’s suggestion and simply adopt the same style as
>>> the rest of Gecko, including the 2-space indent.
>>>
>>>
>> I've said before that we won't do this without talking it over as a team.
>> Well, team? What do you think?
>>
>
> Massive changes are always bad ideas, unless these are used to eliminate
> classes of bugs/crashes, by preventing us from writing them.
>
> Changing the indentation is the kind of thing which brings no value, and
> introduce massive changes.  So, I will always be totally against these kind
> of changes.
>
> I agree that having a tool to *check* one coding style is nicer than
> having no coding style, as long as the tool is flexible enough to allow
> local inconsistencies made to make the code more readable.
>
> Personally I dislike the 2-space indent. But what matters to me here is
>> eliminating a speed bump for both Gecko and SM hackers; and reducing
>> pointless arguments on dev.platform.
>>
>
> 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'm sorry, but that's not how it works. The JS team's primary mandate is to
make Gecko better, as reflected in its cost center and management chain. We
are not going to spin up a separate integration team to insulate SM
developers from interacting with the Platform.

 I honestly think I spend more time thinking about how I can reproduce some
> Gecko failures


We all spend a lot of time trying to figure out how to reproduce weird
Gecko failures. Improvements and clever ideas are always welcome, but we're
in this together. We are all Platform hackers first and SM hackers second.

than anybody spent else spent about thinking about indentation.
>

This compares apples to oranges, and I don't think anyone is claiming the
contrary.


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