Release 1.3?
Stuart Halloway
http://clojure.com
Sean Corfield
<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
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
if it fixes the problem", but it hasn't been applied.
Meikel Brandmeyer
Stuart Sierra
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
<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
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:
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
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
> 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
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
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.
Christopher Redinger
An area I'd like to see more discussion on is the new contrib libraries.
Aaron Bedra
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
Stuart Halloway
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"
Cosmin Stejerean
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
-S
Sean Corfield
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
Laurent PETIT
> 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
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
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
Ben Smith-Mannschott
> 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
Aaron Bedra
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
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
Stuart Halloway
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.
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.
Phil Hagelberg
<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
Hugo Duncan
<stuart....@gmail.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
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
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
Stuart Halloway
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.
Stuart Halloway
> 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
Sent from my iPhone
Paul Stadig
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
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
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
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 statementI think Stu's point is that a problem statement would be "This code C
>> 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."
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
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]As long as:
>
> 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.
>
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
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.
Stuart Halloway
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
Rich Hickey
> 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
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
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
> 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
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
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
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]
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.