On Jan 20, 2013, at 7:11 PM, Andy Fingerhut wrote:
> On Jan 20, 2013, at 7:49 AM, Anthony Grimes wrote:
>> In closing, I propose the following. If we're going to continuously deny
>> people things they are accustomed to, instead of treating them like angry
>> children having tantrums, why don't w
Michael, I would also love it if bugs got fixed in master more quickly. I've
done some things to try to make that happen, but for all I know I've only
exacerbated the issue. I'm still searching for ways to improve that.
One thing I know at the base of all such suggestions is: I am not going to
(Thanks for the apology Brandon. For those confused, he was responding to a
private email I sent him that said: "I feel like you read my email until
you found something to nitpick, and then ignored the rest of it.")
On Sat, Jan 19, 2013 at 5:57 PM, Brandon Bloom wrote:
> > contributions to cloju
On Jan 20, 2013, at 7:49 AM, Anthony Grimes wrote:
>
>
> In closing, I propose the following. If we're going to continuously deny
> people things they are accustomed to, instead of treating them like angry
> children having tantrums, why don't we get a response from clojure/core and
> have it
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 to
> cross-browser compatibility" in ClojureScript, pointing (as many as
> possible of) them out would be extremely helpful, indeed more than
> submitting the actual patch
On a separate note, if there are indeed "tons of bugs when it comes to
cross-browser compatibility" in ClojureScript, pointing (as many as
possible of) them out would be extremely helpful, indeed more than
submitting the actual patches. That would also not require going
through the patch submission
Clojure and contrib have long had extremely thorough CI in place,
including matrix testing with multiple JVM implementations:
http://build.clojure.org/
Cheers,
M.
On 20 January 2013 22:04, Brandon Bloom wrote:
> I think the inflammatory thread subject didn't help...
>
> Java and cross-browser
I think the inflammatory thread subject didn't help...
Java and cross-browser CI both sound great. I don't know if Clojure/core
already has CI or what, but maybe you should take these ideas over to
another thread? Possibly on the Dev mailing list. Because of the
intentionally slow pace of Cloju
I just wanted to mention that pull request was one of the several notes I've
made, but looks like it's being irritating enough people that it completely
took over this thread. The problem itself is not a JIRA or that sending patches
is too hard (even though I think it's too much incidental compl
On Sunday, January 20, 2013 11:33:56 AM UTC-6, Fogus wrote:
>
>
>
>> To make matters worse, Clojure/core consistently avoids discussing these
>> issues in public
>>
>
> I would guess because their position hasn't changed since the last time.
> This is only speculation. A page like what Anth
> I'm sorry but given Clojure/core's track record of *actions* (or lack of
> them, rather) this
> sounds a bit offensive to people who are not Clojure/core members, Clojure
> committers or "screeners".
>
Adding source annotations to a Github project's source base and starting an
IRC channel have n
On Sunday, January 20, 2013 10:22:04 AM UTC-6, Fogus wrote:
>
>> 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'.
>>
>
> Well, that's only my opinion. I happen to think it's not worth figh
2013/1/20 Michael Fogus
> 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.
>
Michael,
I'm sorry but given Clojure/core's track record of *actions* (or lack of
them, rather) this
sounds
>
>
> 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'.
>
Well, that's only my opinion. I happen to think it's not worth fighting
over so I don't. Rich has put in place a system he's happy wit
It makes more sense to compare language projects. I note that ClojureScript
does about as well as Scala in this comparison and much better than
CoffeeScript. Scala and CoffeeScript use pull requests.
I also do not like JIRA. But I think the happiness of contributing to
ClojureScript far outweighs
On Sunday, January 20, 2013 9:16:35 AM UTC-6, Fogus wrote:
> I'll just add a few points:
>
> Pull requests are not likely to happen. It's not worth fighting over.
> However, I think that is a weak excuse for not contributing. If you
> want to contribute a complex bug fix, then the patch proc
Well said, Fogus, well said.
On Sunday, January 20, 2013 9:16:35 PM UTC+6, Fogus wrote:
>
> I'll just add a few points:
>
> Pull requests are not likely to happen. It's not worth fighting over.
> However, I think that is a weak excuse for not contributing. If you
> want to contribute a compl
I'll just add a few points:
Pull requests are not likely to happen. It's not worth fighting over.
However, I think that is a weak excuse for not contributing. If you
want to contribute a complex bug fix, then the patch process is
trivial by comparison. If you want to contribute doc fixes and t
2013/1/20 Aaron Cohen
> 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
> reason
On Saturday, January 19, 2013 8:56:28 PM UTC+1, Andy Fingerhut wrote:
>
> 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 tha
There are 176 forks on GitHub. Even assuming that all 51 contributors have
a public fork (most probably do), that's 125 potential contributors
unaccounted for. Only 29% of those forks account for an accepted
contribution. What portion of the remainder might have been contributors?
I was curious
It is great that questions are being asked about how things do, might or
should work - but tone of the original question and the ensuing discussion,
in my view, unfortunate.
On Sunday, 20 January 2013 17:36:11 UTC+11, Irakli Gozalishvili wrote:
>
> Anyway it's seems to me that message in this t
Anyway it's seems to me that message in this thread is pretty clear:
"We're just doing fine without people like you"
It's a shame, but whatever I'll just shut up and let you guys roll as you
pleased
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Saturday, 2013-01-19 at 22:
I would be curious to also see number of lost contributors.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Saturday, 2013-01-19 at 22:00 , David Nolen wrote:
> I have nothing to add to this thread beyond pointing out that ClojureScript
> has had _51_ contributors in the sho
I have nothing to add to this thread beyond pointing out that ClojureScript
has had _51_ contributors in the short year and a half of its existence:
http://github.com/clojure/clojurescript/graphs/contributors.
Via JIRA.
David
--
You received this message because you are subscribed to the Google
Than Sean for pointing to that thread that's helpful although that got me
wondering if Rich is only one
doing the reviews ? If that's not the case maybe there at least on maintainer
that is willing to bridge the
gap here ?
I really hope someone will step up to bridge the gap, maybe setup a fork
On Saturday, 2013-01-19 at 11:56 , Andy Fingerhut wrote:
> 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
As of comments related to projects that also make contributions hard that's
their choice, and I really hope clojure community will do better than that. I
also know that sometimes rewriting patch is a lot less work than making
someones contribution acceptable, my day job involves all of that, but
I think Brandon, in fact I discovered bunch of clojurescript bugs while working
on my wisp project but since submitting and fixing them felt like too much work
I just ignored them. Unfortunately I keep looking into my fixes now to back
port them to cljs_in_cljs.
I also absolutely agree if iss
Yep, tools to maintain tickets suck, Jira, Mantis,...
However, having Clojure code in production 24/7 and ClojureScript code
reaching production status in a month or so, I feel reassured that a
maintenance process
is in place and that patch screening is tight.
We have enough doing the same thin
Aaron, please forgive my failure at formalities: Allow me to add that I
agree with the rest of your post.
The Linux kernel and Guava guys are absolutely right about patches
defaulting to the rejected state. I'm a big believer in the "minus 100
points" philosophy.
It's just that I just really h
> 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
Also, another blog post dealing with the open source code contribution
issue: http://www.igvita.com/2011/12/19/dont-push-your-pull-requests/
On Sat, Jan 19, 2013 at 5:38 PM, Aaron Cohen wrote:
> Being the maintainer of an open source problem is a hard task.
>
> Contributing to a project is not
Being the maintainer of an open source problem is a hard task.
Contributing to a project is not a process that begins and ends with code
submissions. In fact, it's often more work for a maintainer to accept a
patch or pull request than it is for him or her to write the equivalent
code himself.
Cl
+1
On Saturday, January 19, 2013 11:47:56 PM UTC+4, Andy Fingerhut wrote:
>
>
> On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote:
>
> > On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut
> > > wrote:
> >> The issue that Clojure, its contrib libraries, and ClojureScript do not
> accept github pull
Irakli Gozalishvili:
>
> If these things are intentionally made hard to stop new people with more
> clojurescipt interests then please
> make it more clear, cause otherwise it just a motivation killer.
>
>
Irakli,
Over the years, many people have tried raising the question of why
contributing
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 reques
On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote:
> On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut
> wrote:
>> The issue that Clojure, its contrib libraries, and ClojureScript do not
>> accept github pull requests has been brought up several times before on this
>> email list in the past. Fe
BTW also as hugo pointed out with http://www.clahub.com/ one could just reject
pull requests if any of the commit included
is from author who have not signed CLA yet. So looks like CLA problem can be
also easily solved.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Frida
As a matter of fact I have abandoned clojurescript once before and just wrote
my own implementation of JVM free clojurescript
subset:
https://github.com/Gozala/wisp
http://jeditoolkit.com/wisp/
But kanaka's clojurescript in clojurescript
https://github.com/kanaka/clojurescript/ got me excited
On Friday, 2013-01-18 at 18:03 , Sean Corfield wrote:
> Because by submitting a JIRA patch explicitly, you are taking the
> legal responsibility for the contents of the patch as being a change
> that you are authorized to submit under the CA...
>
You can in fact do similar with contributing guidel
For what it's worth, I've submitted 20+ patches to ClojureScript and one or
two to Clojure proper. I still find the process to be extremely unpleasant.
I consistently avoid interacting with JIRA until the last possible minute:
That software is actively user-hostile. Without naming names, I've sp
Because by submitting a JIRA patch explicitly, you are taking the
legal responsibility for the contents of the patch as being a change
that you are authorized to submit under the CA...
I'm not sure that you can even attach a patch to a Clojure ticket in
JIRA without being given permission to modif
One could also copy attach patch with lines that belong to someone else. How is
that different ?
Pull requests are just a tool for working with patches nothing else
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Friday, 2013-01-18 at 16:18 , Sean Corfield wrote:
> That wil
At mozilla we also require signing CA but do accept pull requests and there are
whole team of legal people that
makes sure things like that don't raise any legal concerns. After all it's just
.patch to the pull request url gives you
an actual change patch so if reviewing patches is desired it's e
That will depend on whether it traces the origin of each line in the
patch - just relying on the pull request originator is not sufficient
(unfortunately).
On Fri, Jan 18, 2013 at 4:11 PM, Hugo Duncan wrote:
> Sean Corfield writes:
>
>> My understanding is that with pull requests it becomes much
Sean Corfield writes:
> My understanding is that with pull requests it becomes much harder to
> provide accountability for Intellectual Property which is a legal
> concern, and that's why we have a Contributor's Agreement.
I wonder if the availability of http://www.clahub.com/ changes anything.
On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut
wrote:
> The issue that Clojure, its contrib libraries, and ClojureScript do not
> accept github pull requests has been brought up several times before on this
> email list in the past. Feel free to search the Google group for terms like
> "pull
One process that could be made a little easier is the contribution of code
documentation and suggested improvements of doc-strings.
New or improved doc-strings do not change any functionality, impact any tests,
require peer review…
If we could simply suggest new doc-strings for example in the J
The issue that Clojure, its contrib libraries, and ClojureScript do not accept
github pull requests has been brought up several times before on this email
list in the past. Feel free to search the Google group for terms like "pull
request". Short answer: Rich Hickey prefers a workflow of evalu
I'm not sure I've ever sent an email where the entire content should
be "+1", but this is the one where it felt most compelling.
Please split the list.
Sent from my iPhone
On Jan 18, 2013, at 4:25 PM, Phil Hagelberg wrote:
>
> Irakli Gozalishvili writes:
>
>> - I do understand that most of the
Irakli Gozalishvili writes:
> - I do understand that most of the clojurescript audience is probably
> also interested in clojure, but please don't enforce that. Have a
> separate mailing list so that people interested in clojurescript and
> not clojure could follow relevant discussions without ma
I have being trying to engage community and to contribute to clojurescript for
a while already,
but so far it's being mostly frustrating and difficult. I hope to start
discussion here and maybe
get some constructive outcome.
## Rationale
I'm primarily interested in clojurescript and not at al
53 matches
Mail list logo
