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