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 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> > > > wrote: > > > > > > On 18 July 2015 at 20:18, Luc Prefontaine > > > <lprefo...@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 <ni...@niwi.nz> wrote: > > >> > > >> > On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates > > >> > <colin...@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 > > >> > > <lprefo...@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 <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 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 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. > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> -- > > >> Luc Préfontaine > > >> > > >> SoftAddicts inc. > > >> Québec, Canada > > >> Mobil: +1 (514) 993-0320 > > >> Fax: +1 (514) 800-2017 > > >> > > >> Rabat, Maroc > > >> Mobil: +1 212 6 98 00 64 47 > > >> > > >> > > >> -- > > >> 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 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 > > ... -- 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.
