Fork me on GitHub
#clojure-dev
<
2015-11-10
>
andy.fingerhut02:11:06

@bronsa: Sure, will get to that some time in the next week or three. Would be nice to include some more expressions like those Alex Miller has been reporting in some of the CLJ JIRA tickets to evaluate changes, although doing all of those would probably be more than anyone would want to look at.

alexmiller02:11:48

well I'd look at them :)

bronsa13:11:07

@alexmiller: I'm releasing tools.analyzer.jvm with a bugfix for the core async bug reported here: https://groups.google.com/forum/#!msg/clojure/NdQMUs1mTUU/_-K_CJSuBQAJ

bronsa13:11:20

also bumping core.memoize and tools.reader deps

bronsa13:11:33

probably worth cutting a core async release using the fixed t.a.jvm version aswell

alexmiller14:11:38

did you get the latest core.memoize update 0.5.8?

ghadi18:11:47

Is it intentional that clojure.lang.Tuple is still active in several codepaths?

ghadi18:11:09

I can file a ticket if not.

ghadi18:11:34

Since a reason for it being removed was that it polluted dispatch caches, then we should make sure that it isn't active at all

bronsa18:11:45

@ghadi: Tuple/create just returns a PV

ghadi18:11:18

thanks, nicola

bronsa19:11:30

https://www.youtube.com/watch?v=-z0Pm7tccvc this video nicely sums up how I feel everytime a ticket's "Fix Version" gets bumped

alexmiller19:11:41

the rules are about the same as every commercial software project I've worked on in the last 20 years. what is surprising to you?

bronsa19:11:32

I understand pushing back features if there's no time to invest on them

bronsa19:11:09

but pushing back on serious bugfixes where the work of fixing them has already been done, that I really don't understand

alexmiller19:11:53

there are an arbitrary amount of bugs with fixes in a variety of states at all times

bronsa19:11:22

but it's the same issue that has been raised to death already, really not much value in arguing about it

alexmiller19:11:37

changing things (anything) introduces more possibilities for interactions. at some point, you stop changing things and wait for a while. then release.

alexmiller19:11:57

the point is arbitrary

alexmiller19:11:15

when your patch is on the other side, it seems capricious

alexmiller19:11:26

but there is always another release

alexmiller19:11:47

by doing these more frequently, hopefully the wait is shorter between arbitrary points

alexmiller19:11:55

these == releases

bronsa19:11:14

but there is always maintenance that has to happen on (my) side to keep the work up to date

bronsa19:11:41

which is often a long time after the original work has been done. mental context is lost and I have to waste even more time to understand it again

alexmiller19:11:52

I feel your pain

alexmiller19:11:59

as I am in the same boat

bronsa19:11:04

I'm talking about myself here, but I'm sure other contributors understand it aswell

alexmiller19:11:15

I feel like there were both a large number of older tickets with reasonable patches and some higher voted/priority tickets that we were able to shepherd through the process in a comparatively short release this time

alexmiller19:11:28

the number of non-feature related tickets was about the same for 1.7 vs 1.8 but with a significantly shorter timespan

bronsa19:11:24

the net increase in the number of closed tickets wasn't that much though. went from 69% to 71%

bronsa19:11:17

don't get me wrong, I'm happy that we got this amount of tickets closed in this short period of time, I just don't think it's nearly enough

bronsa19:11:38

and please don't think I'm bitter about any of my tickets specifically not getting in. For any one of the tickets I've worked on I could name one I haven't that I'd rather be included

andy.fingerhut19:11:40

@bronsa: Might be time to add a new hobby to your list simple_smile Seriously, though, one is always subject to the decisions of a project's deciding person/people, when submitting proposed changes to that project. Clojure is no different there than any other.

alexmiller19:11:27

I could just go close a bunch of tickets if you like :)

alexmiller19:11:08

I once had a manager that came in and closed all tickets more than 6 months old (without looking at them) - "they'll come back if they're important"

sveri20:11:16

we are about to switch back from a 6 month release cycle to 12. Having to support every release puts an enourmous burden on every one of our teams plus the guys managing the old releases, it just becomes to much

alexmiller20:11:28

is that a comment about Clojure's release cycle or just a general release management comment?

sveri20:11:32

@alexmiller: Just a general comment. I don't know enough about the clojure release management to make statements of it. Just wanted to say that support for old versions can become a burned fast.

alexmiller20:11:52

can you say more? just trying to understand the pain point. do you need to support every new clojure release? if so, why? (external users, library upgrades force you to, etc)

sveri20:11:37

*Burden I meant

alexmiller20:11:54

I assumed :)

sveri20:11:45

Sorry, this was not clojure specific. We have a product (webMethods, not sure if you heard of it). Consisting of like 50 sub products and we support 5 + 2 years, meaning maximum 14 releases. So every product team has to support up to 14 releases. My point is, doubling the release cycle can also double/triple/... the cost

alexmiller21:11:35

gotcha (and yes I've heard of webmethods :) - since we don't typically do maintenance releases of old Clojure versions, this has not (to date) been an issue.

alexmiller21:11:11

but I've been in that situation at commercial s/w companies

sveri21:11:48

That's why there was no 1.x.x release yet. I always wondered how it worked out. Seems like that's not a problem yet. I wonder if this might change if "big" corporations start using clojure with fixed versions. Did you ever think of that possibility? Or are you (you as cognitect) just waiting for it to happen?

alexmiller21:11:04

so far, most companies either stick with a version for a multi-year period, then update as part of their normal dev OR update along with the new releases

alexmiller21:11:35

we've done a good enough job with maintaining compatibility that neither has been very problematic as far as I've heard

alexmiller21:11:19

Cognitect does sell Clojure support as well but I can't recall running into an issue related to this through support

sveri21:11:13

Now that is pretty awesome. Having a clean and working upgrade path is better than supporting all that versions. This is something webmethods is clearly lacking. Upgrading is like a 1000-class citizen for us.