Clojurians Log v2

What's the lead time for bugfix patch consideration look like these days? I know the core team is busy and doesn't owe the community anything, just want to know if a patch I submitted a couple years ago in response to a "patches welcome" comment from Alex just slipped thru the cracks or if it's normal for it to take a few years before bugfix patches get considered

I’d say it’s fairly normal for a patch to sit around for years. Clojure’s development is extremely conservative (which is why it is so stable) and all changes and bug fixes are carefully considered based on perceived priority, such as how many votes on Jira or http://ask.clojure.org.

What Jira ticket is your patch for?

https://clojure.atlassian.net/jira/software/c/projects/CLJ/issues/CLJ-2234. I made some tweaks recently to split out https://clojure.atlassian.net/browse/CLJ-2633 and its fix into a separate issue/patch, but the original 2234 patch is from about 2 years ago

The patch is pretty small, I think it's 4 lines of changes to MultiFn.java and then 35 lines of tests

2633 is untriaged and unvetted, it's going to sit there for a while

don't focus on the patch, that's the easy part

the problem statement and analysis is >90% of the work

connecting the race condition to a real world situation would elevate the priority of that issue

is concurrent extension of a multimethod common in the wild? if not, is it part of a situation that you encountered?

TBH, I'm not not super concerned about 2633, IMO it's a clear bug with a simple fix, but a very low-priority one since people probably aren't doing things that would trigger it. On the other hand I did run in to 2234 in real life, so I'm mainly asking in regards to that issue

tickets are generally vetted and screened in batch phases, and there haven't been any of those phases for 1.11 yet, although planning for 1.11 is well underway

2234 seems legit (at cursory glance), 2633 seems like a hypothetical bug discovered by reading the impl code

I wish people got durable kudos for discovering and articulating problems, not just making patches

we go through periods where we are actively and regularly considering patches and periods where we are focused elsewhere

Yeah, I only discovered 2633 because of the work on the 2234 patch. I would be surprised if anyone ran into it IRL. Altho if they did that would probably be a really nasty bug to try and debug. Thanks for the help and info. I didn't know anything about patches being vetted and screened in batches. I'll keep my fingers crossed and see what happens in the future

when we are working on them, we generally are prioritizing based on: severity, impact, frequency, availability of workarounds, community interest (according to votes on http://ask.clojure.org), etc

well crafted tickets and patches help grease the path (see https://clojure.org/dev/creating_tickets and https://clojure.org/dev/developing_patches)

https://ask.clojure.org/index.php/3332/multifn-prefers-ignores-multimethods-internal-hierarchy has just one vote, BTW, and the JIRA issue has zero so it wouldn’t look like a priority when release planning is being done, I suspect…

I added the link from jira to ask

Thanks for the clarifications everyone. Definitely answers my question. I'll stop bothering people about issues only I'm running in to now 👍

It can be frustrating if you run into an unusual bug and — for you — it ends up being pretty much a showstopper but almost no one else runs into it. That was ultimately why we stopped using Boot at work (and switched completely to deps.edn): we ran into a race condition bug in “pod” refreshing (which is how Boot tasks provide classloader isolation) and we ran into some edge cases in performance around their “fileset” abstraction. Pretty much no one could repro the race condition and even other folks with large Boot-based repos didn’t seem to be seeing the performance issues we were. So neither were going to get fixed 😐

(and I was just looking on GitHub the other day at tickets I’d opened in various repos stretching back nearly a decade — and some from 2012 are still open and still make those features unusable for me)

I totally understand prioritizing issues based on how many people run in to them -- definitely wasn't meant as a complaint. I've had to tell people I don't have time to fix SQL Server 2003 bugs with Metabase more than once myself. I have my own https://github.com/camsaul/methodical that I can hack on if the ones that ship out of the box don't do what I want anyway. So it's not really a showstopper for me at all. I just wanted to get a little more insight into the process behind patches being considered and make sure I wasn't missing some sort of important step in the process

Have the votes been resettled at some point? Some of my old favourite spec issues had much more votes back in the days of old jira, compared to today.

e.g. https://clojure.atlassian.net/browse/CLJ-1965 has now just 23 votes

https://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html

When we moved to jira cloud we only moved over users that had previously submitted patches as we have limits on user count. Because of that, we lost any votes from other users. Most issues had ≤ 1 vote so were unaffected, and the relative ranking of voted issues remained essentially the same.

These days we pay much more attention to the vote counts on ask (but look at both)

This is still one of the highest voted open issues in jira

And ask https://ask.clojure.org/index.php/731/clojure-spec-def-should-support-an-optional-doc-string?show=731#q731