Agreed to everything Bill said.
When it comes to the styling discussion, I don't really care about
using one style or the other. I didn't like SM style at first, and now
I am so used to it that I naturally use it everywhere (Stockholm
What I do care about though is to be able to automate formatting as
much as we could. What if we could just not have to blame style nits
during reviews? If contributors and employees could not have to worry
about this, wouldn't it be great? I even dare to imagine a future in
which MozReview automatically fixes style nits before submitting a
patch to review. In that perspective, having a way to automate
re-formatting seems important to me. According to the first posts, our
current style doesn't allow this. So I am all in for changing our
style guide to enable this.
On Wed, May 11, 2016 at 7:04 PM, Bobby Holley wrote:
> On Wed, May 11, 2016 at 5:01 AM, Nicolas B. Pierron <
> firstname.lastname@example.org> 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
>> Nicolas B. Pierron
>> dev-tech-js-engine-internals mailing list
> dev-tech-js-engine-internals mailing list