Fork me on GitHub
#clojure-dev
<
2021-06-11
>
Cam Saul20:06:28

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

seancorfield20:06:13

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.

seancorfield20:06:23

What Jira ticket is your patch for?

Cam Saul20:06:26

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

Cam Saul20:06:28

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

ghadi20:06:52

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

ghadi20:06:00

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

ghadi20:06:17

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

ghadi20:06:25

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

ghadi20:06:45

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

Cam Saul20:06:42

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

ghadi20:06:14

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

ghadi20:06:10

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

ghadi20:06:25

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

Cam Saul20:06:19

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

seancorfield21:06:12

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…

👍 2
Alex Miller (Clojure team)21:06:50

I added the link from jira to ask

Cam Saul21:06:32

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

seancorfield21:06:54

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 😐

seancorfield21:06:14

(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)

Cam Saul21:06:14

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

Alex Miller (Clojure team)20:06:53

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

Alex Miller (Clojure team)20:06:32

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

ikitommi22:06:23

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.

Alex Miller (Clojure team)22:06:37

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

Alex Miller (Clojure team)22:06:27

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.

Alex Miller (Clojure team)22:06:49

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