Release 1.3?

208 views
Skip to first unread message

Stuart Halloway

unread,
Sep 2, 2011, 11:04:36 AM9/2/11
to cloju...@googlegroups.com
We'll cut a Beta 3 today, which (if nothing shows up amiss) will also become the release.

Why shouldn't we? (Bugs only, please...)

Stu

Stuart Halloway
Clojure/core
http://clojure.com

Sean Corfield

unread,
Sep 2, 2011, 7:40:09 PM9/2/11
to cloju...@googlegroups.com
On Fri, Sep 2, 2011 at 8:04 AM, Stuart Halloway
<stuart....@gmail.com> wrote:
> We'll cut a Beta 3 today, which (if nothing shows up amiss) will also become
> the release.
> Why shouldn't we? (Bugs only, please...)

http://dev.clojure.org/jira/browse/CLJ-829 (transient hashmaps
mishandle hash collisions)

This seems to have been approved to be fixed for 1.3 but still appears open.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

Chas Emerick

unread,
Sep 2, 2011, 9:08:54 PM9/2/11
to cloju...@googlegroups.com

On Sep 2, 2011, at 11:04 AM, Stuart Halloway wrote:

> We'll cut a Beta 3 today, which (if nothing shows up amiss) will also become the release.
>
> Why shouldn't we? (Bugs only, please...)

It's a pity that CLJ-791 and CLJ-830 were screened for 1.3 last weekend, but were dropped into the backlog today.

http://dev.clojure.org/jira/browse/CLJ-791
http://dev.clojure.org/jira/browse/CLJ-830

Was a problem discovered with the patches or the issues' premises, or are the issues considered enhancements?

Also, it's too bad that CLJ-883 will apparently persist. http://dev.clojure.org/jira/browse/CLJ-833

Riding the error message and documentation hobby horse,

- Chas

Alan Malloy

unread,
Sep 2, 2011, 9:44:32 PM9/2/11
to Clojure Dev
http://dev.clojure.org/jira/browse/CLJ-757 is marked as "accept patch
if it fixes the problem", but it hasn't been applied.

Meikel Brandmeyer

unread,
Sep 3, 2011, 7:25:46 AM9/3/11
to cloju...@googlegroups.com
Hi,

Or http://dev.clojure.org/jira/browse/CLJ-832 for that matter.

Meikel

Stuart Sierra

unread,
Sep 3, 2011, 1:04:14 PM9/3/11
to cloju...@googlegroups.com
The hammer came down on enhancements going into 1.3 betas. Bug-fixes only from now on. We want to get this release going. Hopefully -beta3 will be the last one before the 1.3 release.

We're going to try hard to make the *next* release a lot faster than 1.3.0 was. We've got more infrastructure in place to automate testing and releases. The next thing we need to work on is improving our JIRA workflow. I know I'm still struggling with JIRA and the ticket screening process, so I expect other members of Clojure/core are too.

-S

Sean Corfield

unread,
Sep 3, 2011, 2:24:24 PM9/3/11
to cloju...@googlegroups.com
On Sat, Sep 3, 2011 at 10:04 AM, Stuart Sierra
<the.stua...@gmail.com> wrote:
> We're going to try hard to make the *next* release a lot faster than 1.3.0
> was. We've got more infrastructure in place to automate testing and
> releases. The next thing we need to work on is improving our JIRA workflow.
> I know I'm still struggling with JIRA and the ticket screening process, so I
> expect other members of Clojure/core are too.

An area I'd like to see more discussion on is the new contrib libraries.

Currently they're all over the map. Some repos have no code in them,
others are actively being developed. Of the roughly 30 repos on
github, about half have releases on Maven, and those releases range
from 0.0.1 (data.finger-tree) to 0.6.3 (core.logic).

I think the community would appreciate more communication from
Clojure/core about contrib and I think the library maintainers might
also benefit from more guidance from the core team... ;)

Perhaps we can talk about this at the Conj and get some
standardization on releases and better documentation of the contrib
stuff on the dev wiki?

Chas Emerick

unread,
Sep 3, 2011, 7:13:45 PM9/3/11
to cloju...@googlegroups.com

On Sep 3, 2011, at 1:04 PM, Stuart Sierra wrote:

> The hammer came down on enhancements going into 1.3 betas. Bug-fixes only from now on. We want to get this release going. Hopefully -beta3 will be the last one before the 1.3 release.

I'm all for expediency, but being more than a year on from 1.2.0, I think the horse has left the barn on that point. Pushing on a release with various patches left on the cutting room floor that will minimize user confusion and frustration is a mistake. I'll save everyone any angels-on-a-pinhead discussion re: whether documentation+error messages are bugfixes or enhancements; however you classify them, it's not like there's any scope creep going on w.r.t. actual functionality in the patches (or suggested patches) that have been pointed to in this thread.

> We're going to try hard to make the *next* release a lot faster than 1.3.0 was. We've got more infrastructure in place to automate testing and releases.

Indeed, and that sounds good. Even better if the implication is that there will be regular releases — once a month, once a quarter, whatever.

> The next thing we need to work on is improving our JIRA workflow. I know I'm still struggling with JIRA and the ticket screening process, so I expect other members of Clojure/core are too.

It has been suggested that that a custom JIRA workflow would be more approachable and more understandable than the (confusing) custom field(s) currently being used for screen/vetting state. FWIW, JIRA 4.4 added a visual workflow designer that is *very* slick:

http://confluence.atlassian.com/display/JIRA/JIRA+4.4+Release+Notes#JIRA44ReleaseNotes-VisualWorkflowDesigner

Huge improvement over the obtuse form-based configuration process that preceded it. FWIW, upgrading our JIRA from 4.1.x to 4.4 was cake, so presumably Contegix would have an easy time of it.

- Chas

Aaron Bedra

unread,
Sep 3, 2011, 8:33:51 PM9/3/11
to cloju...@googlegroups.com
I understand where you are coming from Chas, and I share your and others
frustrations about not being able to get everything into this release.
That being said, we are facing a bigger issue here than any handful of
patches, and that is adoption of 1.3. With the move to the new contrib
style along with the changes in 1.3, getting a release out the door has
become a major priority. We basically drew a line in the sand and said
what's in is in, and the rest can go into 1.4. I promise there was more
thought put in than that, but it is what happened. A _lot_ of people
have yet to even try 1.3.

I promise I will try my hardest to make all of our new books outdated as
soon as possible by helping get 1.4 out the door quickly. There's a
backlog of stuff building up that can be applied quickly to 1.4, as well
as a bunch of stuff that just needs a small amount of work to make it
in. Like Stuart said, we won't be going this long anymore between releases.

Cheers,

Aaron

On 09/03/2011 07:13 PM, Chas Emerick wrote:
> On Sep 3, 2011, at 1:04 PM, Stuart Sierra wrote:
>
>> The hammer came down on enhancements going into 1.3 betas. Bug-fixes only from now on. We want to get this release going. Hopefully -beta3 will be the last one before the 1.3 release.
> I'm all for expediency, but being more than a year on from 1.2.0, I think the horse has left the barn on that point. Pushing on a release with various patches left on the cutting room floor that will minimize user confusion and frustration is a mistake. I'll save everyone any angels-on-a-pinhead discussion re: whether documentation+error messages are bugfixes or enhancements; however you classify them, it's not like there's any scope creep going on w.r.t. actual functionality in the patches (or suggested patches) that have been pointed to in this thread.
>
>> We're going to try hard to make the *next* release a lot faster than 1.3.0 was. We've got more infrastructure in place to automate testing and releases.

> Indeed, and that sounds good. Even better if the implication is that there will be regular releases � once a month, once a quarter, whatever.

Sean Corfield

unread,
Sep 3, 2011, 8:51:07 PM9/3/11
to cloju...@googlegroups.com
On Sat, Sep 3, 2011 at 5:33 PM, Aaron Bedra <aaron...@gmail.com> wrote:
> That being said, we are facing a bigger issue here than any handful of
> patches, and that is adoption of 1.3.  With the move to the new contrib
> style along with the changes in 1.3, getting a release out the door has
> become a major priority.

I'm very glad to see this recognized by Clojure/core as a big problem.
I already had the impression that a lot of Clojurians have not been
following the contrib changes but it was really brought home to me at
the Bay Area meetup this week when we talked about 1.3 and only two
people (out of 15-20) were using 1.3!

A couple of people felt that 1.3 is not as compelling a release (as
1.2) in terms of "new features" so the justification to move to 1.3 is
harder. Combine that with the pain of dealing with the contrib
reorganization (and the apparent novelty of new contrib based on
version numbers) and I think we have quite a recipe for feet-dragging
- a lot of people will stay on 1.2 for a long time because "It Just
Works" and they'll have to do quite a bit of work to move to new
contrib and then move to 1.3.

Chas Emerick

unread,
Sep 3, 2011, 8:55:11 PM9/3/11
to cloju...@googlegroups.com
I'm happy for the prioritization, don't get me wrong. But the marquee changes in 1.3 have stewed away for a long time, and the new-contrb stuff went "live" even before that (January, maybe? Perhaps earlier…). I just don't see how anything's changed so recently that very sane patches (vetted, even) — some that have sat for some time — can't get in. Far from "everything", those mentioned in this thread are strictly related to improving documentation and error messages, and one that appears to fix a correctness issue in transient hashmaps.

I'd chalk this all up to a simple difference of opinion about what to apply when in a beta cycle, but I see that CLJ-736 and CLJ-815 (rightly, IMO) went into -beta3, both docstring tweaks. Why the difference there? (Not sure if I mean that as a rhetorical question or not… ;-)

Peace,

- Chas

On Sep 3, 2011, at 8:33 PM, Aaron Bedra wrote:

> I understand where you are coming from Chas, and I share your and others
> frustrations about not being able to get everything into this release.
> That being said, we are facing a bigger issue here than any handful of
> patches, and that is adoption of 1.3. With the move to the new contrib
> style along with the changes in 1.3, getting a release out the door has
> become a major priority. We basically drew a line in the sand and said
> what's in is in, and the rest can go into 1.4. I promise there was more
> thought put in than that, but it is what happened. A _lot_ of people
> have yet to even try 1.3.
>
> I promise I will try my hardest to make all of our new books outdated as
> soon as possible by helping get 1.4 out the door quickly. There's a
> backlog of stuff building up that can be applied quickly to 1.4, as well
> as a bunch of stuff that just needs a small amount of work to make it
> in. Like Stuart said, we won't be going this long anymore between releases.
>
> Cheers,
>
> Aaron
>
> On 09/03/2011 07:13 PM, Chas Emerick wrote:
>> On Sep 3, 2011, at 1:04 PM, Stuart Sierra wrote:
>>
>>> The hammer came down on enhancements going into 1.3 betas. Bug-fixes only from now on. We want to get this release going. Hopefully -beta3 will be the last one before the 1.3 release.
>> I'm all for expediency, but being more than a year on from 1.2.0, I think the horse has left the barn on that point. Pushing on a release with various patches left on the cutting room floor that will minimize user confusion and frustration is a mistake. I'll save everyone any angels-on-a-pinhead discussion re: whether documentation+error messages are bugfixes or enhancements; however you classify them, it's not like there's any scope creep going on w.r.t. actual functionality in the patches (or suggested patches) that have been pointed to in this thread.
>>
>>> We're going to try hard to make the *next* release a lot faster than 1.3.0 was. We've got more infrastructure in place to automate testing and releases.

>> Indeed, and that sounds good. Even better if the implication is that there will be regular releases — once a month, once a quarter, whatever.

>>
>>> The next thing we need to work on is improving our JIRA workflow. I know I'm still struggling with JIRA and the ticket screening process, so I expect other members of Clojure/core are too.
>> It has been suggested that that a custom JIRA workflow would be more approachable and more understandable than the (confusing) custom field(s) currently being used for screen/vetting state. FWIW, JIRA 4.4 added a visual workflow designer that is *very* slick:
>>
>> http://confluence.atlassian.com/display/JIRA/JIRA+4.4+Release+Notes#JIRA44ReleaseNotes-VisualWorkflowDesigner
>>
>> Huge improvement over the obtuse form-based configuration process that preceded it. FWIW, upgrading our JIRA from 4.1.x to 4.4 was cake, so presumably Contegix would have an easy time of it.
>>
>> - Chas
>>
>

> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>

Alan Malloy

unread,
Sep 3, 2011, 9:04:22 PM9/3/11
to Clojure Dev
http://dev.clojure.org/jira/browse/CLJ-829 is another correctness
issue for transient hashmaps. I didn't mention it earlier because as
far as I know the cause is not yet known and so a patch could take any
amount of time, but Aaron seems to have indicated a fix should go into
1.3.
> >>http://confluence.atlassian.com/display/JIRA/JIRA+4.4+Release+Notes#J...

Christopher Redinger

unread,
Sep 3, 2011, 9:14:12 PM9/3/11
to cloju...@googlegroups.com
On Saturday, September 3, 2011 2:24:24 PM UTC-4, Sean Corfield wrote:

An area I'd like to see more discussion on is the new contrib libraries.

More than happy to push for more discussion of this. And no need to wait for the Conj!

Maybe a separate thread is warranted. Would you be willing to kick off a discussion with specifically what kind of guidance you are referring to library authors wanting? And maybe some suggestions around the specific documentation that would be useful? It might be the case that a community driven contrib FAQ is enough to get started here.

Aaron Bedra

unread,
Sep 3, 2011, 9:21:40 PM9/3/11
to cloju...@googlegroups.com

On 09/03/2011 09:04 PM, Alan Malloy wrote:
> http://dev.clojure.org/jira/browse/CLJ-829 is another correctness
> issue for transient hashmaps. I didn't mention it earlier because as
> far as I know the cause is not yet known and so a patch could take any
> amount of time, but Aaron seems to have indicated a fix should go into
> 1.3.

I wanted to get a fix in, but since there wasn't a tested patch in
place, it had to be pushed out. It will be on the list for 1.4 though.

Aaron

Sean Corfield

unread,
Sep 3, 2011, 9:43:01 PM9/3/11
to cloju...@googlegroups.com
Will do!

Stuart Halloway

unread,
Sep 4, 2011, 7:43:40 PM9/4/11
to cloju...@googlegroups.com
A couple of people felt that 1.3 is not as compelling a release (as
1.2) in terms of "new features" so the justification to move to 1.3 is
harder. Combine that with the pain of dealing with the contrib
reorganization (and the apparent novelty of new contrib based on
version numbers) and I think we have quite a recipe for feet-dragging
- a lot of people will stay on 1.2 for a long time because "It Just
Works" 

While I agree with many of the "frustration" points on this thread, I want to point out that our biggest opponent (from an adoption perspective) is that 1.2.x "Just Works." 

That is a great and powerful thing, and while we should not rest on our laurels, it does cheer me up when looking at the mountain of things I would like to get done and can't.

Cosmin Stejerean

unread,
Sep 5, 2011, 1:10:53 PM9/5/11
to cloju...@googlegroups.com
I agree with Chas that these things probably should have gone into
1.3. Since it seems that won't happen, how soon can we anticipate to
get a 1.4 or 1.3.1 out the door? I can imagine a 1.3.1 release going
out with all the stuff with all the already vetted fixes that did not
make it into 1.3 and being able to pull this off within a few weeks.
In which case I won't feel nearly as bad about these things not making
1.3


- Cosmin

--
Cosmin Stejerean
http://offbytwo.com

Stuart Sierra

unread,
Sep 5, 2011, 2:26:48 PM9/5/11
to cloju...@googlegroups.com
We definitely want to switch the release timeline from "months" to "weeks" if at all possible.

-S

Sean Corfield

unread,
Sep 6, 2011, 3:42:04 AM9/6/11
to cloju...@googlegroups.com
On Fri, Sep 2, 2011 at 8:04 AM, Stuart Halloway
<stuart....@gmail.com> wrote:
> Why shouldn't we? (Bugs only, please...)

The BigInt optimization seems seriously broken:

user=> (def a 1N)
#'user/a
user=> (* (+ a 10000000000000000) (+ a 10000000000000000))
ArithmeticException integer overflow
clojure.lang.Numbers.throwIntOverflow (Numbers.java:1374)

A BigInt is optimized back to a long and then overflows which is not
what happened in Beta1 and earlier. I'll create a JIRA ticket for
this...

Sean Corfield

unread,
Sep 6, 2011, 3:43:39 AM9/6/11
to cloju...@googlegroups.com

Laurent PETIT

unread,
Sep 6, 2011, 4:23:24 AM9/6/11
to cloju...@googlegroups.com
2011/9/6 Sean Corfield <seanco...@gmail.com>

On Fri, Sep 2, 2011 at 8:04 AM, Stuart Halloway
<stuart....@gmail.com> wrote:
> Why shouldn't we? (Bugs only, please...)

The BigInt optimization seems seriously broken:

user=> (def a 1N)

Isn't bigint literal suffixed by M, and not N ?
 
#'user/a
user=> (* (+ a 10000000000000000) (+ a 10000000000000000))
ArithmeticException integer overflow
clojure.lang.Numbers.throwIntOverflow (Numbers.java:1374)

A BigInt is optimized back to a long and then overflows which is not
what happened in Beta1 and earlier. I'll create a JIRA ticket for
this...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

--

Meikel Brandmeyer

unread,
Sep 6, 2011, 4:26:18 AM9/6/11
to cloju...@googlegroups.com

Am Dienstag, 6. September 2011 10:23:24 UTC+2 schrieb lpetit:
2011/9/6 Sean Corfield <seanco...@gmail.com>

The BigInt optimization seems seriously broken:

user=> (def a 1N)

Isn't bigint literal suffixed by M, and not N ?

M is BigDecimal, I believe.

Meikel
 

Laurent PETIT

unread,
Sep 6, 2011, 5:36:42 AM9/6/11
to cloju...@googlegroups.com
2011/9/6 Meikel Brandmeyer <m...@kotka.de>

Ah.

do you have menotechnics to remember "M for BigDecimal", "N for BigInteger" ?   deciMal , iNteger ?
 

Meikel
 

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/clojure-dev/-/hYJsedNhesYJ.

Stuart Halloway

unread,
Sep 6, 2011, 7:31:03 AM9/6/11
to cloju...@googlegroups.com
Luckily Tuesday is Clojure night at the office. I will fix this tonight if nobody gets to it before then.

Thanks,

Ben Smith-Mannschott

unread,
Sep 6, 2011, 8:49:14 AM9/6/11
to cloju...@googlegroups.com
On Tue, Sep 6, 2011 at 11:36, Laurent PETIT <lauren...@gmail.com> wrote:
> 2011/9/6 Meikel Brandmeyer <m...@kotka.de>
>>
>> Am Dienstag, 6. September 2011 10:23:24 UTC+2 schrieb lpetit:
>>>
>>> 2011/9/6 Sean Corfield <seanco...@gmail.com>
>>>>
>>>> The BigInt optimization seems seriously broken:
>>>>
>>>> user=> (def a 1N)
>>>
>>> Isn't bigint literal suffixed by M, and not N ?
>>
>> M is BigDecimal, I believe.
>
> Ah.
>
> do you have menotechnics to remember "M for BigDecimal", "N for BigInteger"
> ?   deciMal , iNteger ?

This is how I remember it:

M is for "Money" (Which is all I ever use BigDecimal for.)
N is for "Natural number"
(Also Tradition, since the days of FORTRAN suggests that n is an integer...)

Chas Emerick

unread,
Sep 6, 2011, 12:11:24 PM9/6/11
to cloju...@googlegroups.com
May I suggest that the optimization[1] be reverted entirely for 1.3.0, and considered more closely (along with relevant unit tests verifying expected behaviour) for 1.3.1 or whatever?

On a similar note, I notice that HEAD now has a commit for optimizing "intrinsic" primitive operations[2].  Very interesting stuff, and almost surely of high quality (hi, Rich!), but surely this isn't suitable as a last-minute addition?  Or, if it is, then lots of other far less impactful yet helpful patches should be as well.

Even more baffled and frustrated with the meta stuff around patch application and release "policy",

- Chas

Aaron Bedra

unread,
Sep 6, 2011, 12:58:10 PM9/6/11
to cloju...@googlegroups.com
May I suggest that the optimization[1] be reverted entirely for 1.3.0, and considered more closely (along with relevant unit tests verifying expected behaviour) for 1.3.1 or whatever

Since it isn't obvious, here are the real tests that I used throughout the creation of that patch

https://github.com/clojure/test.generative/blob/master/src/examples/clojure/clojure/test/math_test.clj

-- 
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

Christophe Grand

unread,
Sep 9, 2011, 2:09:13 AM9/9/11
to cloju...@googlegroups.com
Hi Alan,

I attached a patch for CLJ-829. I'm sorry for the delay: I was moving and I didn't notice this issue until yesterday.

Christophe
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.cgrand.net/ (en)

Chas Emerick

unread,
Sep 9, 2011, 10:30:34 AM9/9/11
to cloju...@googlegroups.com
"Open source Friday" is upon us, so I thought I'd take one last whack at pushing on this rope.

Over the past week, I've heard privately from at least half a dozen people expressing their own concerns regarding pushing towards a 1.3 release modulo available patches for known reported bugs and documentation/error message issues.  The sudden urgency paired with inconsistency w.r.t. which changes are in and which are not is inexplicable, at least to those of us on the periphery.

Perhaps those individuals will represent their concerns directly; I hope they do.  If not, consider me the canary in the coal mine.[1]

In any case, I'll say again that the current "release plan" makes sense to me.  Personally, I can't imagine shipping a release of any project with bugs for which I have fixes *in hand*, no matter how soon the next release is planned; AFAICT, that's what's planned here.

Cheers,

- Chas

[1] or, "squeaky wheel", "chicken little", "pain in the ass", etc…

Stuart Halloway

unread,
Sep 9, 2011, 11:08:03 AM9/9/11
to cloju...@googlegroups.com
Over the past week, I've heard privately from at least half a dozen people expressing their own concerns regarding pushing towards a 1.3 release modulo available patches for known reported bugs and documentation/error message issues.  The sudden urgency paired with inconsistency w.r.t. which changes are in and which are not is inexplicable, at least to those of us on the periphery.

Agreed that we have sense of urgency around that release. To that end, we are only looking at bug fixes and documentation. There are about 30 git commits since 1.3 beta 1, and I believe they are all bug fixes or documentation related. The only possible point of confusion I see is the commits related to performance. Given that the performance work is a (the?) centerpiece of 1.3, we are treating performance issues as critical.

If there is something else confusing please point it out.

I understand you are frustrated about error message tickets not getting in.  But I don't see any inconsistency, as these are enhancements. We can cut a new release quickly after 1.3 goes final that will include these.   

In any case, I'll say again that the current "release plan" makes sense to me.  Personally, I can't imagine shipping a release of any project with bugs for which I have fixes *in hand*, no matter how soon the next release is planned; AFAICT, that's what's planned here.

Hoping to look at the transient-related tickets today or over the weekend. If there something else you mean besides these?

Phil Hagelberg

unread,
Sep 9, 2011, 12:24:02 PM9/9/11
to cloju...@googlegroups.com
On Fri, Sep 9, 2011 at 8:08 AM, Stuart Halloway
<stuart....@gmail.com> wrote:
> Given that the performance work is a (the?)
> centerpiece of 1.3, we are treating performance issues as critical.
> If there is something else confusing please point it out.
> I understand you are frustrated about error message tickets not getting in.

I find this curious considering that the last State of Clojure survey
showed that the percentage of people concerned about performance is in
the single digits whereas "error messages need improvement"
consistently ranks among the top complaints.

-Phil

David Nolen

unread,
Sep 9, 2011, 12:30:02 PM9/9/11
to cloju...@googlegroups.com
People don't know what they want until they get it. core.match and core.logic are built upon Clojure's performance guarantees.

David 

Hugo Duncan

unread,
Sep 9, 2011, 12:33:58 PM9/9/11
to cloju...@googlegroups.com
On Fri, 09 Sep 2011 11:08:03 -0400, Stuart Halloway
<stuart....@gmail.com> wrote:

> On Fri, 09 Sep 2011 10:30:34 -0400, Chas Emerick <ceme...@snowtide.com>
> wrote:

>> Over the past week, I've heard privately from at least half a dozen
>> people expressing their own concerns regarding pushing towards a 1.3
>> release modulo available patches for known reported bugs and
>> documentation/error message issues. The sudden urgency paired with
>> inconsistency w.r.t. which changes are in and which are not is
>> inexplicable, at least to those of us on the periphery.
>
> Agreed that we have sense of urgency around that release.

That sounds like begging the question to me. Maybe there is a good reason
for a sense of urgency, but it is not apparent to me, or to anyone I have
talked with.

> Given that the performance work is a (the?) centerpiece of 1.3, we are
> treating performance issues as critical.

I think everyone would agree on the importance of this. With the commits
and fixes that have been made since beta3, will there be another beta
release?

> I understand you are frustrated about error message tickets not getting
> in. But I don't see any inconsistency, as these are enhancements. We
> can cut a new release quickly after 1.3 goes final that will include
> these.

It seems there is a difference of opinion as to whether documentation
changes and error message changes are fixes or enhancements. In any case
it would seem these are trivial in scope compared to the changes that are
still going on for transients and performance.

All this is from an "external" point of view. I find it a pity that at
least a part of the community is being frustrated by the release process,
when I am confident that everyone could have been mobilised to speed the
process.

--
Hugo Duncan

Alex Miller

unread,
Sep 9, 2011, 1:54:56 PM9/9/11
to cloju...@googlegroups.com
I was one of the individuals mentioned below. :) Personally, I'd like
to see error message type tickets go in if they are low risk and
substantially improve user experience. I understand there is some
sense of urgency around releasing 1.3. as others have stated, I don't
know why that is. Personally, I'd happily take another beta to get
known fixes in.

From the other side, I've done my share of release mgmt, and I
understand that there is a point where you must say no to stop churn
and grind toward a release. And if we're there, we're there.

I should mention that I'm speaking up (and I will blindly assume Chas
as well) because I care about Clojure. I've staked a chunk of my life
on it, and I'd love to see more people using it. Some of you may be
familiar with the idea of the sales funnel - a series of gates through
which an ever smaller number of people go till they actually give you
money. Examples might be:
1) awareness (# that have heard of Clojure)
2) exposure (# that have seen a talk or been to the web site or read a book)
3) install (# that have downloaded it)
4) toy problem (# that have written a small successful program to do something)
5) real problem
6) production

In prior organizations, we have found it useful to understand which
part of the funnel we are focused on attacking. Early in the
lifecycle, it's all about focusing on #1/2 - how do you get people to
know you even exist. Looking at the current discussion, when I hear
that performance concerns are of top priority, to me that says that
the focus is on the end of the funnel (#6): getting real users in
production and successful. That's an excellent way to create success
stories and flesh out the hard problems. At Revelytix, we're right
there - we have real users at big name companies trying products built
by us in Clojure.

When I hear people talk about Getting Started pages, that's attacking
#3 - getting you from a book into code.

When I hear Chas and others express frustrations about error messages,
to me that is really attacking the middle - #4/5. Once people have
been exposed, bought into the idea of Clojure, and started writing
code, how do you make that experience positive *while they are
learning*.

So my simple analysis of this discussion is that there is a difference
in where Clojure/core is focusing (#6) and where others think 1.3
should focus (#4/5) and thus decisions that make sense to one group
don't make sense to the other. I'd throw in my own experience that
actually I struggle more on a daily basis with the error message kind
of stuff than performance. ymmv.

I have not piped up in the past because either way things go, we will
keep pushing forward. We are on 1.2.1 and probably won't have a
chance to update to 1.3 for a while regardless. I expect the big
changes to affect us will be: numerics, records, and contrib and it
will just take a while to grind through 60k line of Clojure and
address any issues.

Stuart Halloway

unread,
Sep 9, 2011, 2:03:14 PM9/9/11
to cloju...@googlegroups.com
I find this curious considering that the last State of Clojure survey
showed that the percentage of people concerned about performance is in
the single digits whereas "error messages need improvement"
consistently ranks among the top complaints.

-Phil

"Error messages need improvement" is a proposed solution, not a statement of a problem. I would probably infer the problem to be something like "My program doesn't work and it is difficult for me to figure out why."

If that problem were at the top of my personal list, I wouldn't attack it be creating better error messages. That said, I will be happy to screen a ton of error message related improvements. After we ship this release. :-)

Stuart Halloway

unread,
Sep 9, 2011, 2:07:15 PM9/9/11
to cloju...@googlegroups.com
Over the past week, I've heard privately from at least half a dozen people expressing their own concerns regarding pushing towards a 1.3 release modulo available patches for known reported bugs and documentation/error message issues.  The sudden urgency paired with inconsistency w.r.t. which changes are in and which are not is inexplicable, at least to those of us on the periphery.

Agreed that we have sense of urgency around that release.

That sounds like begging the question to me. Maybe there is a good reason for a sense of urgency, but it is not apparent to me, or to anyone I have talked with.

I am personally familiar with several projects whose business stakeholders cannot move to 1.3 until there is an official release. 

Given that the performance work is a (the?) centerpiece of 1.3, we are treating performance issues as critical.

I think everyone would agree on the importance of this. With the commits and fixes that have been made since beta3, will there be another beta release?

You bet.

I understand you are frustrated about error message tickets not getting in.  But I don't see any inconsistency, as these are enhancements. We can cut a new release quickly after 1.3 goes final that will include these.

It seems there is a difference of opinion as to whether documentation changes and error message changes are fixes or enhancements. In any case it would seem these are trivial in scope compared to the changes that are still going on for transients and performance.

Trivial does not equal zero risk.


All this is from an "external" point of view.  I find it a pity that at least a part of the community is being frustrated by the release process, when I am confident that  everyone could have been mobilised to speed the process.

Suggestions on how to do this (mobilise for speed) welcome. Maybe we can have a contributors BOF the Conj. I will buy the beers.

Stuart Halloway

unread,
Sep 9, 2011, 2:09:47 PM9/9/11
to cloju...@googlegroups.com
> I was one of the individuals mentioned below. :) Personally, I'd like
> to see error message type tickets go in if they are low risk and
> substantially improve user experience. I understand there is some
> sense of urgency around releasing 1.3. as others have stated, I don't
> know why that is. Personally, I'd happily take another beta to get
> known fixes in.

There will be another beta, for bug fixes. Not for enhancements, no matter how trivial they seem.

> From the other side, I've done my share of release mgmt, and I
> understand that there is a point where you must say no to stop churn
> and grind toward a release. And if we're there, we're there.

We're there.

> I should mention that I'm speaking up (and I will blindly assume Chas
> as well) because I care about Clojure. I've staked a chunk of my life
> on it, and I'd love to see more people using it. Some of you may be
> familiar with the idea of the sales funnel - a series of gates through
> which an ever smaller number of people go till they actually give you
> money. Examples might be:
> 1) awareness (# that have heard of Clojure)
> 2) exposure (# that have seen a talk or been to the web site or read a book)
> 3) install (# that have downloaded it)
> 4) toy problem (# that have written a small successful program to do something)
> 5) real problem
> 6) production
>

Aaron Bedra

unread,
Sep 9, 2011, 2:16:24 PM9/9/11
to cloju...@googlegroups.com, cloju...@googlegroups.com
I am happy to spend my evening screening patches and organizing 1.3.1 the day 1.3 goes public. I will make myself available as a pair as well for anyone that wants some help working up patches. I want to give all of this attention at the very first responsible moment.

Sent from my iPhone

Paul Stadig

unread,
Sep 9, 2011, 2:17:10 PM9/9/11
to cloju...@googlegroups.com
On Fri, Sep 9, 2011 at 2:03 PM, Stuart Halloway <stuart....@gmail.com> wrote:
I find this curious considering that the last State of Clojure survey
showed that the percentage of people concerned about performance is in
the single digits whereas "error messages need improvement"
consistently ranks among the top complaints.

-Phil

"Error messages need improvement" is a proposed solution, not a statement of a problem.

Honestly, Stu, this has to stop. You can't keep responding to people like this. It's nice that you have opinions like this, but they make absolutely no sense, and many people seem to disagree that the error messages are not a "problem."


Paul

Sean Corfield

unread,
Sep 9, 2011, 2:41:55 PM9/9/11
to cloju...@googlegroups.com

I think Stu's point is that a problem statement would be "This code C
generates this error E but it's confusing / misleading / whatever and
generating error E' instead would address that." - I think we all
agree that, as a general rule, improving error messages helps solve
the user experience problems people are seeing (but that's a
"solution", not a "problem").

So specific, actionable tickets around particular error messages are
useful and can be evaluated on their own merit.

Rich Hickey

unread,
Sep 9, 2011, 4:41:16 PM9/9/11
to cloju...@googlegroups.com

On Sep 9, 2011, at 10:30 AM, Chas Emerick wrote:

> "Open source Friday" is upon us, so I thought I'd take one last whack at pushing on this rope.
>
> Over the past week, I've heard privately from at least half a dozen people expressing their own concerns regarding pushing towards a 1.3 release modulo available patches for known reported bugs and documentation/error message issues. The sudden urgency paired with inconsistency w.r.t. which changes are in and which are not is inexplicable, at least to those of us on the periphery.
>
> Perhaps those individuals will represent their concerns directly; I hope they do. If not, consider me the canary in the coal mine.[1]
>
> In any case, I'll say again that the current "release plan" makes sense to me. Personally, I can't imagine shipping a release of any project with bugs for which I have fixes *in hand*, no matter how soon the next release is planned; AFAICT, that's what's planned here.
>

As long as:

A) producing a beta takes some time
B) that beta will need to be evaluated for some period of time
C) people submit patches during that interval

The choices are:

1) Infinite beta
2) Releasing with unapplied patches in hand

I am choosing #2. People with customers that won't use beta software are currently unable to use significant enhancements I developed over a year ago, for goodness sake. And, I might remind you, they were developed *before* the 1.2 release and held out of it as being potentially too destabilizing to add. That trumps last week's patches. Join the club I've been a member of for over a year.

New stuff will go in next release. We've expressed our desire to significantly shorten the release cycle. Anyone seriously interested in improving the situation will expend effort making the latter easier.

As far as enhancements of my own that I've 'unfairly' slipped in - they followed a weekend lost chasing down and fixing a regression introduced by someone's patch.

You're welcome,

Rich

Paul Stadig

unread,
Sep 9, 2011, 5:16:49 PM9/9/11
to cloju...@googlegroups.com
On Fri, Sep 9, 2011 at 2:41 PM, Sean Corfield <seanco...@gmail.com> wrote:
On Fri, Sep 9, 2011 at 11:17 AM, Paul Stadig <pa...@stadig.name> wrote:
> On Fri, Sep 9, 2011 at 2:03 PM, Stuart Halloway <stuart....@gmail.com>
> wrote:
>> "Error messages need improvement" is a proposed solution, not a statement
>> of a problem.
> Honestly, Stu, this has to stop. You can't keep responding to people like
> this. It's nice that you have opinions like this, but they make absolutely
> no sense, and many people seem to disagree that the error messages are not a
> "problem."

I think Stu's point is that a problem statement would be "This code C
generates this error E but it's confusing / misleading / whatever and
generating error E' instead would address that." - I think we all
agree that, as a general rule, improving error messages helps solve
the user experience problems people are seeing (but that's a
"solution", not a "problem").

So specific, actionable tickets around particular error messages are
useful and can be evaluated on their own merit.

Sean,
I agree there needs to be more detail around specifically which error messages need to be fixed and how, but that is just details. What you're saying is that "error messages need improvement" is not actionable, and I agree.

That's not what Stu said. He said "error messages need improvement" is a solution looking for a problem, and that the real problem is something more like "my code doesn't work," and if that was on the top of his list of problems he wouldn't attack it by creating better error messages.

Perhaps he was joking and I missed the punch line, and if that's the case, then I apologize. Chalk it up to youthful exuberance. However, the idea that unhelpful error messages are not a problem that needs to be fixed is ludicrous.

And this is not the first time that someone posted some idea or something to this or the clojure list and got shot down with "that's a solution looking for a problem." That may be appropriate at times, but it has be come a default response even when it makes absolutely no sense to say it.


Paul

Paul Stadig

unread,
Sep 9, 2011, 5:26:00 PM9/9/11
to cloju...@googlegroups.com
On Fri, Sep 9, 2011 at 4:41 PM, Rich Hickey <richh...@gmail.com> wrote:

On Sep 9, 2011, at 10:30 AM, Chas Emerick wrote:

> "Open source Friday" is upon us, so I thought I'd take one last whack at pushing on this rope.
>
> Over the past week, I've heard privately from at least half a dozen people expressing their own concerns regarding pushing towards a 1.3 release modulo available patches for known reported bugs and documentation/error message issues.  The sudden urgency paired with inconsistency w.r.t. which changes are in and which are not is inexplicable, at least to those of us on the periphery.
>
> Perhaps those individuals will represent their concerns directly; I hope they do.  If not, consider me the canary in the coal mine.[1]
>
> In any case, I'll say again that the current "release plan" makes sense to me.  Personally, I can't imagine shipping a release of any project with bugs for which I have fixes *in hand*, no matter how soon the next release is planned; AFAICT, that's what's planned here.
>

As long as:

A) producing a beta takes some time
B) that beta will need to be evaluated for some period of time
C) people submit patches during that interval

The choices are:

1) Infinite beta
2) Releasing with unapplied patches in hand

I am choosing #2. People with customers that won't use beta software are currently unable to use significant enhancements I developed over a year ago, for goodness sake. And, I might remind you, they were developed *before* the 1.2 release and held out of it as being potentially too destabilizing to add. That trumps last week's patches. Join the club I've been a member of for over a year.

I agree let's get 1.3 out. I think the community is more than willing to help, but the power to commit and release is in the hands of few. It may seem impertinent to complain about there not being a release, or the release taking too long, but I don't think anyone is trying to be malicious, we just lack any other outlet to effect the situation.

New stuff will go in next release. We've expressed our desire to significantly shorten the release cycle. Anyone seriously interested in improving the situation will expend effort making the latter easier.

Yes, and thank you. However we can come together as a community to make that happen, then let's do it.
 
As far as enhancements of my own that I've 'unfairly' slipped in - they followed a weekend lost chasing down and fixing a regression introduced by someone's patch.

I don't mean to be impertinent, but I lost a weekend fixing a bug in your code, where multimethods were holding onto the head of their arguments. So for that, you're welcome as well.

I can't say enough about what you've done for the Clojure community, because obviously it wouldn't exist without you, but it is just as rude for you to make demands and complain about other people as it is for other people to do the same to you.

Clojure isn't just Rich Hickey's work. We're a *co*mmunity. Which means we need to trust each other, work together, and value each other's input. Maybe we all need to just rachet it down a bit, me included.

There seems to be some pent up feelings here, and maybe there is more that needs to be said. My suggestion is we focus on getting 1.3 out the door.


Paul

Stuart Halloway

unread,
Sep 9, 2011, 6:02:52 PM9/9/11
to cloju...@googlegroups.com
Perhaps he was joking and I missed the punch line, and if that's the case, then I apologize. Chalk it up to youthful exuberance. However, the idea that unhelpful error messages are not a problem that needs to be fixed is ludicrous.

And this is not the first time that someone posted some idea or something to this or the clojure list and got shot down with "that's a solution looking for a problem." That may be appropriate at times, but it has be come a default response even when it makes absolutely no sense to say it.

Paul,

Perhaps I was unclear. Let me try again, by replaying the conversation with annotation:

stu:  "Error messages need improvement" is a proposed solution, not a statement of a problem. I would probably infer the problem to be something like "My program doesn't work and it is difficult for me to figure out why.

commentary: I think it is a simple fact that improving error messages is a solution, not a problem. Other possible solutions include: making the error condition go away, training developers, IDE support, better locality (in time or space) for detecting when something has gone amiss, etc.

stu: If that problem were at the top of my personal list, I wouldn't attack it be creating better error messages. That said, I will be happy to screen a ton of error message related improvements. After we ship this release.

commentary: Even though this direction isn't my top priority, I am still willing to work on it.

paul: the idea that unhelpful error messages are not a problem that needs to be fixed is ludicrous

commentary: I think this is the wrong way to approach the problem, but I can't summarize in short form, so for now let's just say we disagree.

paul:  this is not the first time that someone posted some idea or something to this or the clojure list and got shot down

commentary: I questioned the approach and agreed to help out with it anyway. If that constitutes "shooting down," I would welcome anybody on this list shooting down my ideas.

Stu

Stuart Halloway

unread,
Sep 9, 2011, 6:14:36 PM9/9/11
to cloju...@googlegroups.com
 We're a *co*mmunity. Which means we need to trust each other, work together, and value each other's input. Maybe we all need to just rachet it down a bit, me included.

There seems to be some pent up feelings here, and maybe there is more that needs to be said. My suggestion is we focus on getting 1.3 out the door.

Paul

+1. The conversation gets intense here sometimes because we all care passionately about this. I am proud to be part of such a great community.

Rich Hickey

unread,
Sep 9, 2011, 6:54:07 PM9/9/11
to cloju...@googlegroups.com
On Sep 9, 2011, at 5:26 PM, Paul Stadig wrote:

> I can't say enough about what you've done for the Clojure community, because obviously it wouldn't exist without you, but it is just as rude for you to make demands and complain about other people as it is for other people to do the same to you.

Exactly when did I do either of those things? I specifically didn't even call out whose bug it was, and it fact didn't even look when I encountered it, nor after I fixed it.

I'm not interested in blaming anyone, but threads like this put the dev team on the defensive, and defend I will. I sincerely appreciate everyone's contributions, but the effort ratios simply don't justify the pervasive sense of entitlement out there.

Rich

Chas Emerick

unread,
Sep 10, 2011, 12:27:39 AM9/10/11
to cloju...@googlegroups.com

I'm glad for that. The transient issues (first pointed out by Alan, I believe) are indeed the two unambiguous outstanding bugs.

We're all friends here (or, I'd hope so!), but things obviously got tense on the list; unfortunate, but as blow-ups can, I think this one brought to the surface some key missing information and maybe some hidden misconceptions. Since I'm the one that stirred the pot (3 or 4 times, I guess), I feel like I should attempt a retrospective.

The initial root of the confusion was that the first message on the thread indicated that beta3 was ideally going to become the release ("We'll cut a Beta 3 today, which (if nothing shows up amiss) will also become the release."), while those bugs remained outstanding. After a few more messages, it seemed like that was the intention. The perf-related enhancements going in at the same time were baffling and the source of some consternation — the possibility and reality of regressions in e.g. math apparently this close to a release isn't comforting.

I stopped caring particularly much about the error message etc. tickets a while ago in and of themselves. Understanding the rationale behind the sudden urgency + classifying enhancements in one area as bug fixes became my priority, because what I saw happening just didn't make sense to me.

[I'm quoting you from other messages Stu, just so I don't flood the list on multiple threads…]

>> Maybe there is a good reason for a sense of urgency, but it is not apparent to me, or to anyone I have talked with.
>
> I am personally familiar with several projects whose business stakeholders cannot move to 1.3 until there is an official release.

OK! That's entirely understandable — and maybe it's safe to surmise that the performance enhancements landed when they did (during the 'beta' cycle) so as to meet some requirements in certain circles that needed an official release. As long as there's another beta that has some reasonable burn-in time (which has already been confirmed), the aforementioned consternation should abate.

Knowing this at any time would have minimized the confusion re: the perf enhancements going in ahead of other enhancements (regardless of their significance), and even possibly bug fixes. Perhaps I should have sniffed out this dynamic on my own — maybe via e.g. Aaron mentioning "adoption of 1.3" being a serious concern — but I don't think anyone else did, either.

>> It seems there is a difference of opinion as to whether documentation changes and error message changes are fixes or enhancements. In any case it would seem these are trivial in scope compared to the changes that are still going on for transients and performance.
>
> Trivial does not equal zero risk.

True, but the perf "fixes" surely carry more risk than any of the other proposed "enhancements". Maybe it'd be fair to say that what was applied and what wasn't wasn't due to relative risk, it was driven by scope and theme (said explicitly in "Given that the performance work is a (the?) centerpiece of 1.3, we are treating performance issues as critical."). That definitely wasn't understood.

Turning away from the specifics of the (now clarified and settled IMO) issue…

>> All this is from an "external" point of view. I find it a pity that at least a part of the community is being frustrated by the release process, when I am confident that everyone could have been mobilised to speed the process.
>
> Suggestions on how to do this (mobilise for speed) welcome.

Two things come to mind:

1. More frequent releases. Obviously coming soon. This will alleviate pressures to pack the world into Release.Next, for fear of it being the last train until the next year.
2. A real roadmap. This can guide expectations on what the focus is for the next couple of releases, so that people can know what to work on, and what to prioritize. Done well, this might take a lot of the slack out of the workflow, with more people working on patches for the "on deck" topics, and having tickets ready for vetting when core is ready to move on pulling in contributions. Right now, doing work to fix a bug or provide an enhancement is almost entirely speculative, and getting feedback on a case-by-case basis from core members is likely frustrating for all involved. Surely it'd be more pleasant to be able to say "OK, that sounds good; but, we're already planning on working on X in our Q3 release, so let's consider your Y then rather than attempting to slip it into Q2".

I've always been up for helping with (1) and other build/release issues; I'll do whatever I can there. For better or worse, (2) necessarily falls to core, unless there is interest in really opening up management/stewardship of portions of the project to others.

Anyway, I hope the drama wasn't too painful. Insofar as the upshot was perhaps some mutual understanding for all involved and minimized uncertainty for non-core folks, maybe it was worthwhile (though suboptimal)? In any case, I certainly wasn't trying to make anyone feel attacked, unappreciated, etc; just trying my best to facilitate some clarifying dialogue.

I hope everyone has a good weekend,

- Chas

Chas Emerick

unread,
Sep 10, 2011, 12:35:16 AM9/10/11
to cloju...@googlegroups.com

No one is against prioritizing performance, and I don't think anyone is against a 1.3 release. I'm guessing most would have been happy had one happened many moons ago.

Rich: I don't believe anyone ever described your enhancements to Clojure to be 'unfair' or unwelcome or unappreciated. I certainly never intended to imply that, though I believe that that is entirely separate from the validity of conversation about release planning.

[snip from another reply:]
> …threads like this put the dev team on the defensive, and defend I will. I sincerely appreciate everyone's contributions, but the effort ratios simply don't justify the pervasive sense of entitlement out there.


Some of us were confused by the progression of the release process; I spoke up, as did others. As Alex said, we do this because we care a great deal about the project on a number of levels. I apologize to anyone on the core team that felt attacked at any point through this thread; certainly, my (and I'll assume, our) objective has never been to antagonize anyone or put anyone on the defensive. As I said in my other reply, I assume we're all friends here with good intentions.

For my part, I don't believe I have a sense of entitlement. I contribute back as much as I can, technically, financially, and in the community. Many contributions do require more than unquestioning consumption though. Thus, I ask stupid questions, look like a fool if necessary to learn what I don't yet know, and respectfully push back in proper channels in the rare circumstances when I see something that doesn't seem right. IMO, doing anything else would be a disservice to a project I care about and the community around it.

(BTW, if my methods or manner are somehow unproductive or unpleasant, someone should let me know.)

Cheers,

- Chas

Phil Hagelberg

unread,
Sep 10, 2011, 12:49:39 AM9/10/11
to cloju...@googlegroups.com
On Fri, Sep 9, 2011 at 9:27 PM, Chas Emerick <ceme...@snowtide.com> wrote:
> The initial root of the confusion was that the first message on the thread indicated that beta3 was ideally going to become the release ("We'll cut a Beta 3 today, which (if nothing shows up amiss) will also become the release."), while those bugs remained outstanding.  After a few more messages, it seemed like that was the intention.  The perf-related enhancements going in at the same time were baffling and the source of some consternation — the possibility and reality of regressions in e.g. math apparently this close to a release isn't comforting.
>
> I stopped caring particularly much about the error message etc. tickets a while ago in and of themselves.  Understanding the rationale behind the sudden urgency + classifying enhancements in one area as bug fixes became my priority, because what I saw happening just didn't make sense to me.

Agreed; this is not about any particular feature or patch. It's about
communication, transparency, and the gap between those on the inside
and the rest of us. I think we can do better.

-Phil

Paul Stadig

unread,
Sep 10, 2011, 6:50:07 AM9/10/11
to cloju...@googlegroups.com
On Fri, Sep 9, 2011 at 6:54 PM, Rich Hickey <richh...@gmail.com> wrote:
I'm not interested in blaming anyone, but threads like this put the dev team on the defensive, and defend I will. I sincerely appreciate everyone's contributions, but the effort ratios simply don't justify the pervasive sense of entitlement out there.

AFAIK, "the dev team" is this list. I mean I guess there has to be someone in charge, so maybe this is more an internal discussion between the leadership team and the rest on the dev team, which is fine, I just want to try to break down this "us" vs. "them" barrier.

One thing that has been worrying me slightly more and more lately is the fact that this seems to be a Relevance controlled show. Other than Rich, the whole Clojure Core team is employed by Relevance. And please, *please* don't take this the wrong way. I'm not saying that I don't trust you guys or appreciate the work you're doing. But as someone whose livelihood and company's future depends on Clojure, that makes me slightly nervous. I wonder how it appears to people evaluating Clojure for commercial purposes as well. Obviously, Clojure is open source, so I don't think there is a huge risk for us. We can and have made our own builds of Clojure to fix bugs that have particularly effected us.[1]

The corporate controlled open source (like Oracle and Java, or others) is something people find annoying or offensive. Not at all saying that is the case with Clojure, but it may appear that way to people from the outside. I find it difficult to stomach contributing to a corporate controlled project where my gratis sweat is turned into financial benefit for someone else. It feels more one sided, like a company trying to get work out of people for free, and it's not really a community where everyone is contributing and benefiting. I see Clojure as more of a community, where we are all contributing and we are all benefiting.

We seem to have taken ideas from other open source foundations before like the Eclipse Foundation or the Apache Foundation (c.f. the CA). The Eclipse Foundation is essentially made up of companies that have a financial or other stake in the project, and to join the consortium you have to be shipping a product based on Eclipse. The Apache Foundation takes a different tack, and they make it very clear that when someone becomes a committer they do so as an individual, that power stays with them from job to job, and they are not to abuse it for their employer. I think either of these would be better from a business perspective than the Clojure core situation. Clojure is obviously a smaller community than Eclipse or Apache, and I don't mean to say that we need to add levels of bureaucracy, just something more inclusive.

Perhaps Sonian (I haven't actually talked to the higher-ups about this) or Revelytix or other companies who use Clojure day-to-day in production would be interested in joining Clojure/core, or perhaps setting up their own team dedicated to Clojure. Maybe this would include financial support of some kind, it seems it would also include commit access and release powers. Maybe there are individuals who would be glad to contribute to Clojure though they don't want to work for Relevance (no offense). There would have to be more coordination around the direction of Clojure, so that these new committers wouldn't just be committing willy, nilly.

Can we have a discussion about this? I don't think we want to do it now. I don't want to derail the 1.3 release.


Paul

[1] These fixes have either been things that we've contributed back to Clojure, or in some cases were actually backports from 1.3, so we're not keeping anything back from the community.

Aaron Bedra

unread,
Sep 10, 2011, 9:11:16 AM9/10/11
to cloju...@googlegroups.com
Clojure/core is more about a commitment to moving Clojure forward than it is an allegiance to a company.  Given a number of circumstances it has ended up this way.  I do want to focus on our commitment though.  I personally spend somewhere in the realm of 15-20 hours a week working on Clojure related issues.  A lot of this goes unseen because it is stuff like working on the build server, organizing patches, ramping up new contrib authors, and what is otherwise considered grunt work.  In fact, a lot of Clojure/core does these things.  Organizing the conj is another task that takes an incredible effort.  Alex Miller can attest to that :). 

I just want to take the time to point out that although Clojure/core is made up of Relevance employees, those members still spend their personal time supporting Clojure. I think a little more clarity around process, and the amount of effort being poured in may shift opinions about the motivations of Clojure/core.  Supporting the community and moving the language forward is absolutely, without question, our priority.  If we can do that better, I am happy to listen and help.

Stuart Halloway

unread,
Sep 10, 2011, 9:23:56 AM9/10/11
to cloju...@googlegroups.com
One thing that has been worrying me slightly more and more lately is the fact that this seems to be a Relevance controlled show. Other than Rich, the whole Clojure Core team is employed by Relevance. And please, *please* don't take this the wrong way. I'm not saying that I don't trust you guys or appreciate the work you're doing. But as someone whose livelihood and company's future depends on Clojure, that makes me slightly nervous. I wonder how it appears to people evaluating Clojure for commercial purposes as well. Obviously, Clojure is open source, so I don't think there is a huge risk for us. We can and have made our own builds of Clojure to fix bugs that have particularly effected us.[1]

It is important to keep two things separate here:

1. Clojure/dev is the Clojure development team (the people on this list). Participation and advancement is based on merit. The leaders in this group are not formally listed, but I think it is pretty clear to people who they are. They overlap with, but are not the same as, the Clojure/core team.

2. Clojure/core is a business entity within Relevance that funds a bunch of work on Clojure, and works to make Clojure more viable for business adoption.

Perhaps Sonian (I haven't actually talked to the higher-ups about this) or Revelytix or other companies who use Clojure day-to-day in production would be interested in joining Clojure/core, or perhaps setting up their own team dedicated to Clojure. Maybe this would include financial support of some kind, it seems it would also include commit access and release powers. Maybe there are individuals who would be glad to contribute to Clojure though they don't want to work for Relevance (no offense). There would have to be more coordination around the direction of Clojure, so that these new committers wouldn't just be committing willy, nilly.

Two separate threads we should follow up on here:

1. Being on Clojure/core today does not give you commit access, or even screening access. Both of those have to be earned, and cannot be bought, even by being on the core team.

2. Clojure/core would love to see other business entities match their financial/resource commitment to Clojure. Let's talk.

I don't have time to drill into either of these points right now, but wold love to do so at length later.

Can we have a discussion about this? I don't think we want to do it now. I don't want to derail the 1.3 release.

Yes, how about at the Conj?
Reply all
Reply to author
Forward
0 new messages