Because by submitting a JIRA patch explicitly, you are taking thelegal responsibility for the contents of the patch as being a changethat you are authorized to submit under the CA...
I'm not sure that you can even attach a patch to a Clojure ticket inJIRA without being given permission to modify tickets (which means youhave a CA on file)?
As you say, at Mozilla, you have a whole team of legal people makingsure things are safe and acceptable. Clojure/core does not have thatluxury.
On Friday, 2013-01-18 at 18:03 , Sean Corfield wrote:
If these things are intentionally made hard to stop new people with more clojurescipt interests then pleasemake it more clear, cause otherwise it just a motivation killer.
--
--
Irakli:I am curious about the possibility of auto-creating patches from git pull requests, in case that would bridge the divide between people that would prefer submitting pull requests, and Clojure screeners that would prefer evaluating patches and JIRA tickets.Causing a new git pull request to to auto-create a JIRA ticket with a patch sounds easy, but that isn't the whole process.What about comments that are later added to the pull request? Are they auto-added as comments to the JIRA ticket?Are comments added to the JIRA ticket auto-added as comments to the pull request?If the JIRA ticket is closed, does that automatically close the github pull request?If the answer to all of the above is "yes, already works that way", then I'd be willing to spend a little more time looking into it. Do you have links to any info on the tools that enable such behavior?
Thanks,AndyOn Jan 18, 2013, at 5:13 PM, Irakli Gozalishvili wrote:At mozilla we also require signing CA but do accept pull requests and there are whole team of legal people thatmakes sure things like that don't raise any legal concerns. After all it's just .patch to the pull request url gives youan actual change patch so if reviewing patches is desired it's easy to build a tool that attaches it to JIRA. We in factdo that for bugzilla. The good news is that such tools are already written for JIRA so it's just matter of enabling it!
--
--
Irakli:I am curious about the possibility of auto-creating patches from git pull requests, in case that would bridge the divide between people that would prefer submitting pull requests, and Clojure screeners that would prefer evaluating patches and JIRA tickets.Causing a new git pull request to to auto-create a JIRA ticket with a patch sounds easy, but that isn't the whole process.What about comments that are later added to the pull request? Are they auto-added as comments to the JIRA ticket?Are comments added to the JIRA ticket auto-added as comments to the pull request?If the JIRA ticket is closed, does that automatically close the github pull request?If the answer to all of the above is "yes, already works that way", then I'd be willing to spend a little more time looking into it. Do you have links to any info on the tools that enable such behavior?Thanks,Andy
Clojure is hardly the only project that doesn't accept pull requests. The Linux Kernel and Guava are two that immediately come to mind. For Guava's rationale, you might read the following: https://plus.google.com/113026104107031516488/posts/ZRdtjTL1MpM Their reasons are not identical to Rich's, but the sentiment is similar.
Does this mean you shouldn't even try to contribute? No, of course not. But, contributions to clojure are definitely less easy to make than to projects that willy-nilly accept any pull request.
--
Please don't ask people to not rehash this discussion. Don't tell them that it is a 'weak reason' for not contributing and 'not worth fighting over'.
That's ridiculous. How many people have brought this up?
Isn't it a little arrogant to just dismiss the issue as "Meh, they're not as smart as I am
We're all friends here. Everyone wants to help. There are ways to
help that do not involve endless mailing list threads and personal
distaste of process.
I'm sorry but given Clojure/core's track record of *actions* (or lack of them, rather) thissounds a bit offensive to people who are not Clojure/core members, Clojure committers or "screeners".
The current process is broken in many ways:
To make matters worse, Clojure/core consistently avoids discussing these issues in public
Saying "we are all friends here" is a bit optimistic and does not cut it.
To make matters worse, Clojure/core consistently avoids discussing these issues in publicI would guess because their position hasn't changed since the last time. This is only speculation. A page like what Anthony proposes could help, but it wouldn't satisfy everyone. Stuart Sierra wrote up something related, but it doesn't cover everything discussed here http://clojure.com/blog/2012/02/17/clojure-governance.html
--
On Sunday, 2013-01-20 at 14:27 , Michał Marczyk wrote:
On a separate note, if there are indeed "tons of bugs when it comes tocross-browser compatibility" in ClojureScript, pointing (as many aspossible of) them out would be extremely helpful, indeed more thansubmitting the actual patches. That would also not require goingthrough the patch submission process.
> contributions to clojure are definitely less easy to make than to projects
> that willy-nilly accept any pull request.
False dichotomy. Accepting pull requests does not mean you need to be willy-nilly about it.You know how people carefully optimize their signup forms and checkout flows? They do this because there's a (very large) category of people who simply give up when things aren't immediately obvious. Granted, this category is much smaller among the class of folks skilled enough to create a desirable Clojure patch. However, the fact that this topic keeps coming up suggests that maybe that group is large enough to pay attention too.
As the Clojure implementations evolve, fewer and fewer people will discover issues large enough to justify diving into the code base to fix them. Most people just work around the issues. If somebody takes the initiative to properly fix an issue, we shouldn't add yet another hurdle discouraging them from contributing.
Maybe not, but Clojure has managed to collect quite a few contributions over its life, so all I know is that we at least are not at a complete minima.
The flip side, of course, is that having documentation separate from code often leads to the documentation becoming out of sync with the code.
What happens when someone renames or moves some code, but doesn't also move the docs? What happens if they change the implementation? Will people remember that every code change might potentially also require a change to documentation, stored somewhere else, and potentially versioned independently?
- Korny
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en