[asdfasgasdgasdg]

> Of course the author is unlikely to present it that way.

I don't really get this accusation in light of the author leading the article with admissions of their own failings in terms of how they communicated with the maintainers of the project?

[jlokier]

I'm writing in response to this remark, presented in the parent to my comment:

> he claims that the Elm community will excommunicate you for forking.

If that is correct, what I said is less accusation and more descriptive, and should really say something stronger: "the author hasn't presented it that way."

However if the parent to my comment is mistaken, then I agree that would make that sentence in my response unfairly speculative.

[asdfasgasdgasdg]

The bit about "excommunication" is very explicitly linked to the author's plan to fork Elm. Now, I don't think "excommunication" is necessarily the correct descriptor. The Elm maintainer who made the threat said that he considered making a fork on "attack" on Elm's goals [1], and that the project would not be greeted with open arms. (Although in the original comment it was a little less clear whether it was the project or the person to whom arms would not be open.) In any case, I think the comment is very clear that the hostility is to the action of forking, irrespective of previous communication problems.

[1]: https://github.com/gdotdesign/elm-github-install/issues/62#i...

[jlokier]

I don't see anything about making a fork in the linked GitHub issue.

(The word "fork" appears once elsewhere, in an unrelated context in a different comment.)

The thing about open arms is not about forking (or if it is, it's not obvious to me), and reads to me more like "assuming you are not making your own fork, can you please stop pressuring upstream to accomodate designs which are explicitly against our clearly communicated design goals".

The quote is:

> @spookylukey It's one thing to build tooling around an implementation flaw without knowing the history, but that's all pretty well communicated at this point.

> If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals?

> As someone who has spent a lot of time collaborating with many others to help Elm achieve its stated design goals, intentionally working against those goals feels to me like an attack on our efforts. We have been really clear about our design goals in this area, and you shouldn't expect a project that works against those goals to be greeted with open arms—especially not from those of us who have been working hard for years to achieve those goals.

[asdfasgasdgasdg]

The comment immediately before rtfeldman's references patching the compiler for this project, which is an implied necessity if js code is to continue to be used. It's essentially a soft-fork, and that is what rtfeldman is objecting to.

[jlokier]

Thanks, fair enough although rtfeldman appears to be responding to spookeylukey about divergent design goals, while it's norpan who is talking about maintaining a locally patched compiler.

I still see no objections to maintaining a fork or local patch from rtfeldman. Just "if you go against our explicit design goals don't expect us to want to merge it upstream for first-class support".

TBH a locally patched compiler sounds like not a huge deal to me. I have lived with locally patched GCCs before :-)

But maybe I'm unusual. I surprised someone, once, when they found some code not working and I suggested they look at their compiler source for the cause. Their response: "Wow, I hadn't ever thought of the compiler as something that might have a bug, let alone read and modify it".

[Talanes]

IT was norpan and spookeylukey talking about patching the compiler together, and rtfeldman jumping in with references to PAST discussions of design goals with spookeylukey.