Re: #{:rant} Questions about contribution policy and clojure compiler source.
I take it you have never worked on a patch for clojure. I have, and I can tell you that it's not the indentation style the issue -- everybody likes his own and it's definitely in the maintainer's rights to chose what indentation style should be used and for contributors to adapt, I don't have a problem with that. I have a problem with the fact that the indentation style is not consistent even between lines of the same method, tabs and spaces are mixed everywhere -- for every non trivial patch I submit I have to spend non trivial amounts of time to reindent my code using spaces or tabs where appropriate to be consistent with the surrounding code and making sure I don't accidentally commit whitespace changes in my patches. It's certainly not the biggest issue (not even close to it) in the contributing process, but it definitely is an issue and it doesn't help making the overall contributing experience a pleasant one, or one would want to repeat. And the claim that no indentation fix can happen to avoid breaking existing patches in jira is frankly laughable. With the amount of time that usually passes between the writing of a patch and its application to the code base, a lot of them already need to be rebased/rewritten to apply cleanly, often multiple times. On Sat, Jul 18, 2015 at 5:44 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
--- advanced warning: the following section contains a lethal form of irony, please skip it if your health condition does not tolerate irony --- Sure and I never maintained code written by others in 30 years... Never wrote patches, never had to comply with odd indentation habits. I am an absolute newbie on that subject. I always write new code and leave maintenance to other less fortunate people. --- end of ironic section --- I agree with you. Totally. Maintenance has never been funnier than new dev and will never be. Day to day maintenance specifically is a pain in the ass. Preemptive rewrites as part of maintenance is doable when the code reaches an unbearable state but someone in charge has to call the shots. I had numerous discussions about rewriting in the last few decades and yes patch consistency is always brought forward. The driving factors around a decision like this are: the life expectancy of the code vs it's complexity vs maintenance cost and agility vs risks involved in a rewrite vs budget vs accumulated knowledge. The maintainer's pain is not the only factor taken into account and often not the most important. That's the harsh reality of life. Ideally we would always write new stuff and trash code every 2/3 years to keep our mood at its peak. Life is not like that. Sorry :) Sent from my iPhone On Jul 20, 2015, at 08:14, Nicola Mometto brobro...@gmail.com wrote: I take it you have never worked on a patch for clojure. I have, and I can tell you that it's not the indentation style the issue -- everybody likes his own and it's definitely in the maintainer's rights to chose what indentation style should be used and for contributors to adapt, I don't have a problem with that. I have a problem with the fact that the indentation style is not consistent even between lines of the same method, tabs and spaces are mixed everywhere -- for every non trivial patch I submit I have to spend non trivial amounts of time to reindent my code using spaces or tabs where appropriate to be consistent with the surrounding code and making sure I don't accidentally commit whitespace changes in my patches. It's certainly not the biggest issue (not even close to it) in the contributing process, but it definitely is an issue and it doesn't help making the overall contributing experience a pleasant one, or one would want to repeat. And the claim that no indentation fix can happen to avoid breaking existing patches in jira is frankly laughable. With the amount of time that usually passes between the writing of a patch and its application to the code base, a lot of them already need to be rebased/rewritten to apply cleanly, often multiple times. On Sat, Jul 18, 2015 at 5:44 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Leaving aside your usual humour, you are once again setting up a total strawman. Nicola did not say that maintenance should be as much fun as writing new code, nor did he propose rewriting anything. He made a very specific claim - that contributing to the Clojure codebase is much less pleasant than it could be, not because the indentation style is unusual but because it is inconsistent. Since he has a long history of writing very high quality patches for Clojure whereas you, as far as I can tell, have never written any, means that his opinion holds a lot more weight in this discussion, for me at least. On 20 July 2015 at 14:45, Luc Prefontaine lprefonta...@softaddicts.ca wrote: --- advanced warning: the following section contains a lethal form of irony, please skip it if your health condition does not tolerate irony --- Sure and I never maintained code written by others in 30 years... Never wrote patches, never had to comply with odd indentation habits. I am an absolute newbie on that subject. I always write new code and leave maintenance to other less fortunate people. --- end of ironic section --- I agree with you. Totally. Maintenance has never been funnier than new dev and will never be. Day to day maintenance specifically is a pain in the ass. Preemptive rewrites as part of maintenance is doable when the code reaches an unbearable state but someone in charge has to call the shots. I had numerous discussions about rewriting in the last few decades and yes patch consistency is always brought forward. The driving factors around a decision like this are: the life expectancy of the code vs it's complexity vs maintenance cost and agility vs risks involved in a rewrite vs budget vs accumulated knowledge. The maintainer's pain is not the only factor taken into account and often not the most important. That's the harsh reality of life. Ideally we would always write new stuff and trash code every 2/3 years to keep our mood at its peak. Life is not like that. Sorry :) Sent from my iPhone On Jul 20, 2015, at 08:14, Nicola Mometto brobro...@gmail.com wrote: I take it you have never worked on a patch for clojure. I have, and I can tell you that it's not the indentation style the issue -- everybody likes his own and it's definitely in the maintainer's rights to chose what indentation style should be used and for contributors to adapt, I don't have a problem with that. I have a problem with the fact that the indentation style is not consistent even between lines of the same method, tabs and spaces are mixed everywhere -- for every non trivial patch I submit I have to spend non trivial amounts of time to reindent my code using spaces or tabs where appropriate to be consistent with the surrounding code and making sure I don't accidentally commit whitespace changes in my patches. It's certainly not the biggest issue (not even close to it) in the contributing process, but it definitely is an issue and it doesn't help making the overall contributing experience a pleasant one, or one would want to repeat. And the claim that no indentation fix can happen to avoid breaking existing patches in jira is frankly laughable. With the amount of time that usually passes between the writing of a patch and its application to the code base, a lot of them already need to be rebased/rewritten to apply cleanly, often multiple times. On Sat, Jul 18, 2015 at 5:44 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Lets make it clear (the ironic portion seems to obfuscate my email). I did not criticIzed his work and if you ask me, yes his work is stellar. I fully agreed with him that maintenance is often a less than funny task. Inconsistency in code when maintaining code however is more the norm than the exception even within a single organization. Tension between day to day maintenance pain versus all the other constraints will not disappear tomorrow. Code ages. It takes around 5 years to reach maturity. Afterward you need to prevent decay. This it what I can say after going through so many software projects. I tried to put things in perspective. Real-life constraints exist for business driven projects and open source projects. It seems that you are not interested at all by these. Fine. That's your call. Now if you think that because I did not contribute to patches in Clojure core makes my conclusions about maintenance work unworthy you are erring. And this a very soft statement from my part :) The ironic section was partly about my inadequate skills and you fell happily into this trap. If you really want to discuss my professional achievements send me a private email. This is not the place to discuss this and is orthogonal to the point brought up by Nicola. Which is absolutely valid but hard to solve in a satisfactory way given the constraints. Clojure in Clojure on the JVM and CLR will ease up this... Eventually when some time will have passed. Sent from my iPhone On Jul 20, 2015, at 10:08, Colin Fleming colin.mailingl...@gmail.com wrote: Leaving aside your usual humour, you are once again setting up a total strawman. Nicola did not say that maintenance should be as much fun as writing new code, nor did he propose rewriting anything. He made a very specific claim - that contributing to the Clojure codebase is much less pleasant than it could be, not because the indentation style is unusual but because it is inconsistent. Since he has a long history of writing very high quality patches for Clojure whereas you, as far as I can tell, have never written any, means that his opinion holds a lot more weight in this discussion, for me at least. On 20 July 2015 at 14:45, Luc Prefontaine lprefonta...@softaddicts.ca wrote: --- advanced warning: the following section contains a lethal form of irony, please skip it if your health condition does not tolerate irony --- Sure and I never maintained code written by others in 30 years... Never wrote patches, never had to comply with odd indentation habits. I am an absolute newbie on that subject. I always write new code and leave maintenance to other less fortunate people. --- end of ironic section --- I agree with you. Totally. Maintenance has never been funnier than new dev and will never be. Day to day maintenance specifically is a pain in the ass. Preemptive rewrites as part of maintenance is doable when the code reaches an unbearable state but someone in charge has to call the shots. I had numerous discussions about rewriting in the last few decades and yes patch consistency is always brought forward. The driving factors around a decision like this are: the life expectancy of the code vs it's complexity vs maintenance cost and agility vs risks involved in a rewrite vs budget vs accumulated knowledge. The maintainer's pain is not the only factor taken into account and often not the most important. That's the harsh reality of life. Ideally we would always write new stuff and trash code every 2/3 years to keep our mood at its peak. Life is not like that. Sorry :) Sent from my iPhone On Jul 20, 2015, at 08:14, Nicola Mometto brobro...@gmail.com wrote: I take it you have never worked on a patch for clojure. I have, and I can tell you that it's not the indentation style the issue -- everybody likes his own and it's definitely in the maintainer's rights to chose what indentation style should be used and for contributors to adapt, I don't have a problem with that. I have a problem with the fact that the indentation style is not consistent even between lines of the same method, tabs and spaces are mixed everywhere -- for every non trivial patch I submit I have to spend non trivial amounts of time to reindent my code using spaces or tabs where appropriate to be consistent with the surrounding code and making sure I don't accidentally commit whitespace changes in my patches. It's certainly not the biggest issue (not even close to it) in the contributing process, but it definitely is an issue and it doesn't help making the overall contributing experience a pleasant one, or one would want to repeat. And the claim that no indentation fix can happen to avoid breaking existing patches in jira is frankly laughable. With the amount of time that usually passes between the writing of a patch and its application to the code base, a lot
Re: #{:rant} Questions about contribution policy and clojure compiler source.
True that. While I'd prefer a more common indentation style to be adopted, I'd definitely settle just for Rich's style being applied consistently everywhere. Trying to account for indentation inconsistencies when working on a patch is not fun at all. So yeah - the real problems about the formatting are: * inconsistent indentation * mixing tabs spaces * trailing whitespace (although I guess it's ok to kill it in our patches) The style itself is up to the project's author and of no big importance by itself. On 20 July 2015 at 17:08, Colin Fleming colin.mailingl...@gmail.com wrote: Leaving aside your usual humour, you are once again setting up a total strawman. Nicola did not say that maintenance should be as much fun as writing new code, nor did he propose rewriting anything. He made a very specific claim - that contributing to the Clojure codebase is much less pleasant than it could be, not because the indentation style is unusual but because it is inconsistent. Since he has a long history of writing very high quality patches for Clojure whereas you, as far as I can tell, have never written any, means that his opinion holds a lot more weight in this discussion, for me at least. On 20 July 2015 at 14:45, Luc Prefontaine lprefonta...@softaddicts.ca wrote: --- advanced warning: the following section contains a lethal form of irony, please skip it if your health condition does not tolerate irony --- Sure and I never maintained code written by others in 30 years... Never wrote patches, never had to comply with odd indentation habits. I am an absolute newbie on that subject. I always write new code and leave maintenance to other less fortunate people. --- end of ironic section --- I agree with you. Totally. Maintenance has never been funnier than new dev and will never be. Day to day maintenance specifically is a pain in the ass. Preemptive rewrites as part of maintenance is doable when the code reaches an unbearable state but someone in charge has to call the shots. I had numerous discussions about rewriting in the last few decades and yes patch consistency is always brought forward. The driving factors around a decision like this are: the life expectancy of the code vs it's complexity vs maintenance cost and agility vs risks involved in a rewrite vs budget vs accumulated knowledge. The maintainer's pain is not the only factor taken into account and often not the most important. That's the harsh reality of life. Ideally we would always write new stuff and trash code every 2/3 years to keep our mood at its peak. Life is not like that. Sorry :) Sent from my iPhone On Jul 20, 2015, at 08:14, Nicola Mometto brobro...@gmail.com wrote: I take it you have never worked on a patch for clojure. I have, and I can tell you that it's not the indentation style the issue -- everybody likes his own and it's definitely in the maintainer's rights to chose what indentation style should be used and for contributors to adapt, I don't have a problem with that. I have a problem with the fact that the indentation style is not consistent even between lines of the same method, tabs and spaces are mixed everywhere -- for every non trivial patch I submit I have to spend non trivial amounts of time to reindent my code using spaces or tabs where appropriate to be consistent with the surrounding code and making sure I don't accidentally commit whitespace changes in my patches. It's certainly not the biggest issue (not even close to it) in the contributing process, but it definitely is an issue and it doesn't help making the overall contributing experience a pleasant one, or one would want to repeat. And the claim that no indentation fix can happen to avoid breaking existing patches in jira is frankly laughable. With the amount of time that usually passes between the writing of a patch and its application to the code base, a lot of them already need to be rebased/rewritten to apply cleanly, often multiple times. On Sat, Jul 18, 2015 at 5:44 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sun, Jul 19, 2015 at 10:19 AM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Prioritizing the 'good' form over the substance is the first step toward political correctness and lobotomy. Civility is more about form than If you can't respect people's wishes about how they want to be treated, I suggest you disengage with this community. Being right does not give one an excuse to be a jerk. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Saturday, July 18, 2015 at 5:44:29 PM UTC+2, Luc wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) Comments like that are often linked as an expample of Functional Programmers attitude. Let's not do that. I beleive that talking things out is the only way to improve in cases like that. But it can be only achieved through civil and equal discussion without any attempts to undermine authority of each other. Let's try to do that, I beleive people in the clojure community can do that easily. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Many people feel this way, but ultimately Clojure is Rich's project and I guess Cognitect's to some extent. If they don't want to run it like other more open contribution-friendly OSS projects this is obviously their right. Similar concern and attitude caused apearence of io.js. Do we want similar situation in this community? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sunday, 19 July 2015 00:03:04 UTC+8, Andy Fingerhut wrote: I don't think the tweets you link are the 'normal approach'. I would call them pretty unusual in several aspects. For one, I think that for the vast majority of Clojure tickets created, no on asks and gets Rich's comments on them before they are created. Second, most end up being committed as the submitter created them, with fewer rounds of review and updates. Most of them are a lot less work on the part of the contributor than the two examples mentioned. Note: I am not saying that those two examples didn't happen, or that there are no others like that. I am saying they are unusual examples, as compared to the great majority of Clojure tickets. Most tickets that have a change committed for them end up being committed as a patch submitted by a contributor, without being implemented differently. It is fairly common for there to be months or years of waiting time for a ticket to be considered. Rich is one person, and like most people, he gets to choose how much time he spends on volunteer projects, and what projects those are. Alex Miller spends a significant fraction of his time tending to tickets and commenting on and reviewing patches. This point (i.e. lead time) is by far my biggest gripe about the Clojure contribution process. It causes a number of problems: A) Contributors get de-motivated waiting for feedback / communication B) Patches often become stale. This wastes more time C) People forget what they were thinking about months or years ago D) Improvements take too long to get into Clojure (Zach's CLJ-1517 case is a good example) E) It creates the perception (even if it is not the reality?) that Clojure is unfriendly to contributors My practical suggestion is simple: Clojure needs more trusted maintainers who know particular parts of Clojure well and can work more closely with contributors to get patches in a good state for Rich to review, and potentially even merge the simpler types of changes (bug fixes, documentation updates, basic refactoring, indentation etc.). Rich's time can then be spent on the high value stuff (reviewing good quality patches only when they are ready in the view of the trusted maintainer, considering changes which impact language design etc.). FWIW It's worth comparing the rate of development on Clojure vs. Linux: Clojure: https://github.com/clojure/clojure/graphs/commit-activity (10 commits per week) Linux: https://github.com/torvalds/linux/graphs/commit-activity (500-1500 commits per week) Obviously Linux is a bigger project, but there is still only one BDFL in both cases (and I am sure both BDFLs are very busy!) So how does Linus do it? The answer is organisation. Linux has many trusted subsystem maintainers who do most of the work reviewing and merging patches. Linus may have the final say on everything but the Linux community has done a lot of thinking and self-organisation to make sure that Linus is not usually the bottleneck. Also worth noting that Linus does indeed use pull requests (just not GitHub ones, see the extended discussion here if interested: https://github.com/torvalds/linux/pull/17#issuecomment-5654674 ). Not saying Rich has to do so himself, but the trusted maintainers would be able to do so if it helped with the workflow for work-in-progress patches. As for indentation of Java code, it is called Whitesmiths style: https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style Clojure was the first project I came across using this indentation style, but Rich isn't the only one to use it. A few bits of code have crept in over the years using other indentation styles, usually contributed by others. Andy On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh ni...@niwi.nz javascript: wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation:
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Your comments are one-sided. When I modify code written by others, I follow their style. I do not complain about their code formatting habits. I wrote/modified enough code in 30 years written by hundreds of individuals to find emphasis on code formatting and variable naming a waste of time and effort. If the code structure is good essentially it's maintainable. I answered a recurring subject of low-level importance wrapped in some humorous wording to try to pass under the political correctness radar that will eventually kill humanity. It does not please you ? Let the OP comment on this, it was not addressed to you personally. Just zap. He can rant on me on this mailing list, I will not whine about it. I'm made though. Kumbaya... Sent from my iPhone On Jul 19, 2015, at 04:21, Max Gonzih gon...@gmail.com wrote: On Saturday, July 18, 2015 at 5:44:29 PM UTC+2, Luc wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) Comments like that are often linked as an expample of Functional Programmers attitude. Let's not do that. I beleive that talking things out is the only way to improve in cases like that. But it can be only achieved through civil and equal discussion without any attempts to undermine authority of each other. Let's try to do that, I beleive people in the clojure community can do that easily. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
I agree with you but changes like this need time to bloom and are motivated by increased pressure to release. We have been seeing more of that in the last year. Linus did not find solid maintainers day one. You need to test drive individuals before you can delegate significant chunks and not worry about the minute details and just review work at the end of the pipeline. By now such people should be identified in the community. It's kind of an internal Cognitec subject but some public statement looks to me inevitable :) Alex ? Sent from my iPhone On Jul 19, 2015, at 02:21, Mikera mike.r.anderson...@gmail.com wrote: On Sunday, 19 July 2015 00:03:04 UTC+8, Andy Fingerhut wrote: I don't think the tweets you link are the 'normal approach'. I would call them pretty unusual in several aspects. For one, I think that for the vast majority of Clojure tickets created, no on asks and gets Rich's comments on them before they are created. Second, most end up being committed as the submitter created them, with fewer rounds of review and updates. Most of them are a lot less work on the part of the contributor than the two examples mentioned. Note: I am not saying that those two examples didn't happen, or that there are no others like that. I am saying they are unusual examples, as compared to the great majority of Clojure tickets. Most tickets that have a change committed for them end up being committed as a patch submitted by a contributor, without being implemented differently. It is fairly common for there to be months or years of waiting time for a ticket to be considered. Rich is one person, and like most people, he gets to choose how much time he spends on volunteer projects, and what projects those are. Alex Miller spends a significant fraction of his time tending to tickets and commenting on and reviewing patches. This point (i.e. lead time) is by far my biggest gripe about the Clojure contribution process. It causes a number of problems: A) Contributors get de-motivated waiting for feedback / communication B) Patches often become stale. This wastes more time C) People forget what they were thinking about months or years ago D) Improvements take too long to get into Clojure (Zach's CLJ-1517 case is a good example) E) It creates the perception (even if it is not the reality?) that Clojure is unfriendly to contributors My practical suggestion is simple: Clojure needs more trusted maintainers who know particular parts of Clojure well and can work more closely with contributors to get patches in a good state for Rich to review, and potentially even merge the simpler types of changes (bug fixes, documentation updates, basic refactoring, indentation etc.). Rich's time can then be spent on the high value stuff (reviewing good quality patches only when they are ready in the view of the trusted maintainer, considering changes which impact language design etc.). FWIW It's worth comparing the rate of development on Clojure vs. Linux: Clojure: https://github.com/clojure/clojure/graphs/commit-activity (10 commits per week) Linux: https://github.com/torvalds/linux/graphs/commit-activity (500-1500 commits per week) Obviously Linux is a bigger project, but there is still only one BDFL in both cases (and I am sure both BDFLs are very busy!) So how does Linus do it? The answer is organisation. Linux has many trusted subsystem maintainers who do most of the work reviewing and merging patches. Linus may have the final say on everything but the Linux community has done a lot of thinking and self-organisation to make sure that Linus is not usually the bottleneck. Also worth noting that Linus does indeed use pull requests (just not GitHub ones, see the extended discussion here if interested: https://github.com/torvalds/linux/pull/17#issuecomment-5654674 ). Not saying Rich has to do so himself, but the trusted maintainers would be able to do so if it helped with the workflow for work-in-progress patches. As for indentation of Java code, it is called Whitesmiths style: https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style Clojure was the first project I came across using this indentation style, but Rich isn't the only one to use it. A few bits of code have crept in over the years using other indentation styles, usually contributed by others. Andy On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh ni...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 19:54, Luc Préfontaine lprefonta...@softaddicts.ca wrote: My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I think everyone in this community should aspire to more than I'm not as rude as Linus. There's nothing that makes me shiver more than political correctness. Political correctness has nothing to do with remaining civil in a discussion. On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sunday, July 19, 2015 at 7:02:43 AM UTC-5, Luc wrote: I agree with you but changes like this need time to bloom and are motivated by increased pressure to release. We have been seeing more of that in the last year. Linus did not find solid maintainers day one. You need to test drive individuals before you can delegate significant chunks and not worry about the minute details and just review work at the end of the pipeline. By now such people should be identified in the community. It's kind of an internal Cognitect subject but some public statement looks to me inevitable :) Alex ? There are no plans to change this aspect of the process at this time. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Prioritizing the 'good' form over the substance is the first step toward political correctness and lobotomy. Civility is more about form than substance and has various meaning depending on the people involved. You can say horrendous things using a civil tone. It's as unbearable as a crude statement with a lot of bad words. As far as aspiring to be not as rude as Linus, yeah, he's kind of extreme. But becoming a care bear is not on my list of todos. Dying by civilicide either. As far as I know, I did not used obscene words or used bird names toward people. If my kind of humor is not your taste it's a legit critic and I can take it. If you have specific complaints about my tone we can pursue this off list if needed. That's channel is opened for anyone that may need to let steam out. If there's enough interest, I can even start a blog and publish emailed comments/complaints as is and anonymously if asked for. Some are stamp collectors, I could start an original collection of my own. Sent from my iPad On Jul 19, 2015, at 09:36, Colin Fleming colin.mailingl...@gmail.com wrote: On 18 July 2015 at 19:54, Luc Préfontaine lprefonta...@softaddicts.ca wrote: My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I think everyone in this community should aspire to more than I'm not as rude as Linus. There's nothing that makes me shiver more than political correctness. Political correctness has nothing to do with remaining civil in a discussion. On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Is there any need to speak with this tone and this arrogance? It's just an attempt to improve things, and I think there is nothing negative about it. I think the initial motivation of this email is change things to be better and with good intentions. It make sense to attack good intentions without any needs? We are all adults and we should all be able to talk about issues in a more calm manner, without arrogance and with understanding. This kind of responses not only discourages participating in clojure development, it also damages the community and completely discourages the participation in this mailing list. Personally, this kind of things discourages me completely from participating in this mailing list. My two cents! Andrey On Sun, Jul 19, 2015 at 5:19 PM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Prioritizing the 'good' form over the substance is the first step toward political correctness and lobotomy. Civility is more about form than substance and has various meaning depending on the people involved. You can say horrendous things using a civil tone. It's as unbearable as a crude statement with a lot of bad words. As far as aspiring to be not as rude as Linus, yeah, he's kind of extreme. But becoming a care bear is not on my list of todos. Dying by civilicide either. As far as I know, I did not used obscene words or used bird names toward people. If my kind of humor is not your taste it's a legit critic and I can take it. If you have specific complaints about my tone we can pursue this off list if needed. That's channel is opened for anyone that may need to let steam out. If there's enough interest, I can even start a blog and publish emailed comments/complaints as is and anonymously if asked for. Some are stamp collectors, I could start an original collection of my own. Sent from my iPad On Jul 19, 2015, at 09:36, Colin Fleming colin.mailingl...@gmail.com wrote: On 18 July 2015 at 19:54, Luc Préfontaine lprefonta...@softaddicts.ca wrote: My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I think everyone in this community should aspire to more than I'm not as rude as Linus. There's nothing that makes me shiver more than political correctness. Political correctness has nothing to do with remaining civil in a discussion. On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works
#{:rant} Questions about contribution policy and clojure compiler source.
Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 14:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... Many people feel this way, but ultimately Clojure is Rich's project and I guess Cognitect's to some extent. If they don't want to run it like other more open contribution-friendly OSS projects this is obviously their right. An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? This topic resurfaces all the time. I'd certainly like to see the Java code fixed, as its layout is highly unidiomatic (not to mention somewhat confusing). I doubt this will happen though - seems Rich doesn't think this is a big problem and AFAIK he's concerned that fixing the layout will affect currently submitted patches. Knowing all the hoops one has to jump to get a patch into Clojure, this doesn't sound like a pretty strong argument, but once again - his project, his rules. People seem to undervalue the value of polish in a project, as good style and overall tidiness set apart the good from the great. I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Certainly. As far basic things go, I think it's also discouraging to see commit messages like: * tuples * tuning tuples * tuning tuples * fix And don't get me started on commented out code and Javadoc/Clojure docstrings. It'd be nice if at least improvements of cosmetic nature where easier to contribute, but alas - this also doesn't seem likely to happen. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Btw, here's a bit more colour on the inclusion of tuples, Zack's own thoughts on the subject https://gist.github.com/ztellman/9ded0b77281f48942b68 On Saturday, July 18, 2015 at 2:14:02 PM UTC+3, Andrey Antukh wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - ni...@niwi.nz javascript: http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this are not very complicated to adopt and has a lot of benefit. My two cents! On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 18:48, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). Why do people always say that a committee is the only alternative of having a BDFL? That's clearly not the case. Would it be so bad of Alex Miller had the power to vet and merge certain clear-cut things himself? Or someone else like him? While create artificial bottlenecks when we can do without them? I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 20:18, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates it, I can only imagine the willingness of casual contributors to deal with it. How do you do an inline patch review in JIRA? How do you update patches automatically? It's never about particular tools, it's all about making smart choices. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Laziness? Time is our most important resource and we should always be mindful of the time people have to invest (waste) to contribute to our projects. For me lowering the bar to entry is the same as respecting the time of the person on the other end of the ticket/patch/whatever. If you take a look at my profile on GitHub you'll see I maintain a few projects and I go to great lengths to make sure all the projects are inviting and it's easy for people to start a conversation or pitch in. This pays off big time in the long run. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. Curiously, most of the people who work on Linux are on the payroll of a corporation like Red Hat. If I was getting paid to do something, I'd definitely be more willing to through more hurdles - after all that's part of my job, right? No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). Alex is an amazing fellow, there's no denying this. I only wish we could clone him somehow. :-) +1 for Jira and patches. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 20:18, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates it, I can only imagine the willingness of casual contributors to deal with it. How do you do an inline patch review in JIRA? How do you update patches automatically? It's never about particular tools, it's all about making smart choices. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Laziness? Time is our most important resource and we should always be mindful of the time people have to invest (waste) to contribute to our projects. For me lowering the bar to entry is the same as respecting the time of the person on the other end of the ticket/patch/whatever. If you take a look at my profile on GitHub you'll see I maintain a few projects and I go to great lengths to make sure all the projects are inviting and
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 22:52, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. As this conversation isn't really going anywhere I'll keep my thoughts to myself. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 20:18, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates it, I can only imagine the willingness of casual contributors to deal with it. How do you do an inline patch review in JIRA? How do you update patches automatically? It's never about particular tools, it's all about making smart choices. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Laziness? Time is our most important resource and we should always be mindful of the
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Andrey: Pull requests have come up many times before, but since it has been quite some time since the last time, perhaps most people have not seen Rich's answer the last time he responded to it. Below is a direct link, if you want to read it. The short answer is that he prefers the work flow of reviewing submitted patches. It is easier for him. He is not doing it to try to make it harder on others. https://groups.google.com/forum/#!msg/clojure/jWMaop_eVaQ/3M4gddaXDZoJ Andy On Sat, Jul 18, 2015 at 10:32 AM, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I
Re: #{:rant} Questions about contribution policy and clojure compiler source.
You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :) A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 22:52, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. As this conversation isn't really going anywhere I'll keep my thoughts to myself. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 20:18, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates
Re: #{:rant} Questions about contribution policy and clojure compiler source.
I don't think the tweets you link are the 'normal approach'. I would call them pretty unusual in several aspects. For one, I think that for the vast majority of Clojure tickets created, no on asks and gets Rich's comments on them before they are created. Second, most end up being committed as the submitter created them, with fewer rounds of review and updates. Most of them are a lot less work on the part of the contributor than the two examples mentioned. Note: I am not saying that those two examples didn't happen, or that there are no others like that. I am saying they are unusual examples, as compared to the great majority of Clojure tickets. Most tickets that have a change committed for them end up being committed as a patch submitted by a contributor, without being implemented differently. It is fairly common for there to be months or years of waiting time for a ticket to be considered. Rich is one person, and like most people, he gets to choose how much time he spends on volunteer projects, and what projects those are. Alex Miller spends a significant fraction of his time tending to tickets and commenting on and reviewing patches. As for indentation of Java code, it is called Whitesmiths style: https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style Clojure was the first project I came across using this indentation style, but Rich isn't the only one to use it. A few bits of code have crept in over the years using other indentation styles, usually contributed by others. Andy On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sat, Jul 18, 2015 at 6:21 AM, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 14:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... Many people feel this way, but ultimately Clojure is Rich's project and I guess Cognitect's to some extent. If they don't want to run it like other more open contribution-friendly OSS projects this is obviously their right. This is a line of response I don't really understand; sure, it's within Rich's/Cognitect's rights to run the project as they please, but I don't think any of the aggrieved parties is claiming that Rich did something he had no *right* to do. One can still suggest that the way the project's run (or the way these specific issues were handled) is unwise or shabby or otherwise capable of improvement. No one has to take the suggestion, but it might be better if they did. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this are not very complicated to adopt and has a lot of benefit. My two cents! On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Excuse-me if I hurt your personal feelings but most of the proponents of pull requests so far have been in fact extremely allergic to report problems/improvements in Jira first before submitting a code change. I was addressing this audience because this subject comes back over and over again. My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I restrain myself as much as I can :) Believe me. There's nothing that makes me shiver more than political correctness. Now back to real issues: a) If you have a ticket in Jira and no patch attached to it, how do you link that with your code base ? How can you avoid issuing a patch ? How can a reviewer figure out exactly the scope of your changes if they are no patches attached to it ? b) You can propose improvements through Jira plus the mailing list. What would be a better alternative ? c) How do you preserve history of changes and code mutations throughout this process ? These are practical workflow issues. If you can shed some light on this and suggest an improved workflow, there are people listening. There's no free lunch but many people would like one. To me it boils down to this question: Can the needs of one person compromise a group effort ? I don't think so. But this is only my opinion. Luc P. Sent from my iPad On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this are not very complicated to adopt and has a lot of benefit. My two cents! On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Everyone: let's keep the tone civil. Andrey: thanks for your workflow suggestions. I politely re-decline all of them, having considered all your points multiple times over several years and having chosen approaches that I believe are better matched with my objectives. The objective of Clojure contributions is Clojure, not contribution. The proof is in the pudding. Sent from my iPad On Jul 18, 2015, at 1:32 PM, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this are not very complicated
Re: #{:rant} Questions about contribution policy and clojure compiler source.
+1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz mailto:n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz mailto:n...@niwi.nz
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Re jira: we have started the process to upgrade some of the current infrastructure. This will take a while (likely months) as it involves contracts, purchases, and upgrades (where jira does not have a stellar reputation). Even jira from N years ago is significantly more capable than the github issues of today, for those of us that use it every hour of the day. Re PRs: this has been rehashed a zillion times. It may change in the future. It's not changing right now. I believe the newer jira versions have the ability to do interesting things with patches/PRs and that's something we will look at. Re contribution process: I appreciate Andy's comments and largely agree. The majority of small tickets flow through the existing system just fine and are applied as they were created by the submitter (and/or updated based on review). It's particularly nice to see lots of new names in the commits for 1.8.0-alpha2 (https://github.com/clojure/clojure/commits/master). Re releases and ticket delays: The 1.7 release took an unexpectedly long time to close out. There are many reasons for that, but they're irrelevant. We have published (for the first time ever) a target freeze date for the 1.8 date and are actively moving dozens of tickets through the process (see the Screened report for the next batch). It's hard to see, but a lot of attention has been paid by me to putting highly voted tickets high in this queue (this was done even during the 1.7 close-out, in some cases pulling high desire tickets late in the release). Re bigger features and in particular the comments at the top of this thread: Zach's comments are available. You can see Rich's view in the ticket comments http://dev.clojure.org/jira/browse/CLJ-1517?focusedCommentId=39972page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39972. We will try to set better expectations for these bigger changes in the future. Alex -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
I'm speaking very much as a passenger in this community, and I've had the privilege of meeting just a few of you people, but that may be no handicap. It's a worthwhile debate to have, but this is very much an edge case. Rich has kindly and wisely reduced his own bum-print in the ecosystem so much that the majority of what other languages include is found in higher velocity libraries. For small changes to core (and core libs) as Andy said, contribs are often incorporated whole after feedback. This change by Zach is by these standards enormous, so it's not going to follow that route. Again, for small or cosmetic changes, credit is sufficient feedback for most (otherwise do something else), but in this case there is a question to be answered about the manner by which Zach's hand-wrought (and iterated by request) code was effectively redone unilaterally. I agree with Luc and Colin on the link between the success of Clojure and Rich's insistence on doing things his way. We are all here because this is the case and Clojure the language is as clean and simple as Rich can keep it. However, this example proves that Rich is not omniscient (though we do all love him dearly). It took months of work by Zach to turn a belief into a provable case to make fundamental changes to the implementation of small data structures. We all need to foster such dedication to improving the language many of us have bet our careers on. This episode is not likely to encourage the next girl to do that work. Alex has put ZT front and centre for credit for the update, and made it the centrepiece of the new release, and that's great. But I think some comments from someone inside the temple might also be of use. Who knows, maybe this prompts a rethink of how the pipeline works in the future.. That perhaps would be a suitable response to Zach's contribution to both language and community. -- Fergal Byrne, Brenter IT Author, Real Machine Intelligence with Clortex and NuPIC https://leanpub.com/realsmartmachines Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: http://euroclojure.com/2014/ and at LambdaJam Chicago, July 2014: http://www.lambdajam.com http://inbits.com - Better Living through Thoughtful Technology http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne e:fergalbyrnedub...@gmail.com t:+353 83 4214179 Join the quest for Machine Intelligence at http://numenta.org Formerly of Adnet edi...@adnet.ie http://www.adnet.ie On Saturday 18 Jul 2015 at 17:17, Ben Wolfson wolf...@gmail.com, wrote: On Sat, Jul 18, 2015 at 6:21 AM, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 14:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... Many people feel this way, but ultimately Clojure is Rich's project and I guess Cognitect's to some extent. If they don't want to run it like other more open contribution-friendly OSS projects this is obviously their right. This is a line of response I don't really understand; sure, it's within Rich's/Cognitect's rights to run the project as they please, but I don't think any of the aggrieved parties is claiming that Rich did something he had no *right* to do. One can still suggest that the way the project's run (or the way these specific issues were handled) is unwise or shabby or otherwise capable of improvement. No one has to take the suggestion, but it might be better if they did. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 18:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) That remark is wrong on so many levels... In the words of the legendary SICP authors - Programs must be written for people to read, and only incidentally for machines to execute. Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. I've been involved in many OSS project and certainly there are projects where the contribution process is worse than Clojure's. I do believe, however, that pointing that things could be worse in not the right attitude. There's always room for improvement. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. Central control is not the same as dictator. It's not uncommon for projects to have several leaders. Sure, having less people on the top makes it easier to make decisions, but it also makes it easier to make mistakes (not to mention it creates bottlenecks here and there). This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. I doubt anyone thinks something like this is a big problem. After all it's common for some ideas to be shot down and complex ideas require a lot of time to reach maturity. If there's something I dislike it's that sometimes important bugfixes are delayed for quite a while. Especially in the absense of bugfix releases. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. You're comparing apples to oranges here. Linux is not a one-man show - most subsystems have their own maintainers and Linus monitors the development there only cursory. Not to mention there's no company acting as the steward of the language. I'm not saying one of the approaches is better/worse, I'm just saying that's a poor base for such a comparison. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Linux and Linus? Github vs Jira? Enough of these distractions. The issue here is that brilliant people like Zach Tellman is strongly disinclined to make contributions to the core Clojure implementation in the future. That Kyle Kingsbury, another brilliant developer, feels stonewalled - and even tho he loves Clojure the language and the community - is considering moving on. Because of the way the contribution process works. Or does not work, in these cases. I think Zach summed it up nicely in his gist. I don't think the sky is falling in any way. But don't try to boil this down to a patches vs pull request bike shedding. It is certainly a much more important topic than that. On Saturday, July 18, 2015 at 11:14:58 PM UTC+2, Luc wrote: You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :) A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov bozh...@batsov.com javascript: wrote: On 18 July 2015 at 22:52, Luc Préfontaine lprefo...@softaddicts.ca javascript: wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. As this conversation isn't really going anywhere I'll keep my thoughts to myself. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozh...@batsov.com javascript: wrote: On 18 July 2015 at 20:18, Luc Prefontaine lprefo...@softaddicts.ca javascript: wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Saturday, July 18, 2015 at 9:16:39 PM UTC-4, Linus Ericsson wrote: Dear Mr/Ms/Mme/PhD Dynamics, I have this epic joke I would like yo send you, please fill in your fax number in the boxes below (please write clearly and use a pen with black ink, make sure the two carbon papers are correctly aligned). [_|_|_|_|_|_|_|_|_|_] *Carbon* papers? Sounds like the goddamned Spanish Inquisition! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
It is sad that Zach and Kyle thinks they spent time in vain. Clojure is less about code and more about holistic considerations and intentions than most other software projects. Jira (and mail chains such as this) are probably the worst possible hammers on communicating intentions and more holistic considerations in a focused way which IMHO seem to be what erred here. In cases like these I would strongly suggest Zach, Kyle and the Clojure Core-team to strive to communicate by phone or video-calls, and spend less time misinterpreting each other in asynchronous ticket comments. When in doubt, try to call each other ASAP and sort things out. I do optimistically assume that the Clojure Core team would gladly strive to set away some amount of time to discuss considerations for - not every incoming issue - but such exceptional, clear and well explained issues as these, where there's an overwhelming risk that a lot of work would end up being in vain. Thanks all for your exceptional work, Linus On Sunday, July 19, 2015 at 1:09:17 AM UTC+2, Magnar Sveen wrote: Linux and Linus? Github vs Jira? Enough of these distractions. The issue here is that brilliant people like Zach Tellman is strongly disinclined to make contributions to the core Clojure implementation in the future. That Kyle Kingsbury, another brilliant developer, feels stonewalled - and even tho he loves Clojure the language and the community - is considering moving on. Because of the way the contribution process works. Or does not work, in these cases. I think Zach summed it up nicely in his gist. I don't think the sky is falling in any way. But don't try to boil this down to a patches vs pull request bike shedding. It is certainly a much more important topic than that. On Saturday, July 18, 2015 at 11:14:58 PM UTC+2, Luc wrote: You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :) A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov bozh...@batsov.com wrote: On 18 July 2015 at 22:52, Luc Préfontaine lprefo...@softaddicts.ca wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Saturday, July 18, 2015 at 8:22:35 PM UTC-4, Linus Ericsson wrote: In cases like these I would strongly suggest Zach, Kyle and the Clojure Core-team to strive to communicate by phone My God. First contributor agreements that have to be submitted by Pony Express, and now *phone calls*? What is this, the Dark Ages? We're dealing with medievalism here, Jim! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Dear Mr/Ms/Mme/PhD Dynamics, I have this epic joke I would like yo send you, please fill in your fax number in the boxes below (please write clearly and use a pen with black ink, make sure the two carbon papers are correctly aligned). [_|_|_|_|_|_|_|_|_|_] Thanks, Linus Sent from my Ericsson Hotline Combi 450 Mobile Telephone Den 19 jul 2015 02:56 skrev Fluid Dynamics a2093...@trbvm.com: On Saturday, July 18, 2015 at 8:22:35 PM UTC-4, Linus Ericsson wrote: In cases like these I would strongly suggest Zach, Kyle and the Clojure Core-team to strive to communicate by phone My God. First contributor agreements that have to be submitted by Pony Express, and now *phone calls*? What is this, the Dark Ages? We're dealing with medievalism here, Jim! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/IXKll8tgAXA/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
