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 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 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 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 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. >> > > >> > >> > >> > >> >> >> >> -- >> 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 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. > > -- > 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.
