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 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> >>> 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 clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> 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+u...@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. -- 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.
