What a time to be a committer in 2026

[David Smiley <ds...@apache.org>]

It's never been an easier time as a committer to be the shepherd/reviewer
to a non-committer PR.  We have automated code reviews via GitHub co-pilot
(need to add as a reviewer to engage).  No longer do we have to edit a
massive CHANGES.txt to pick a version that might be wrong or even know the
version.  No longer do we have the chore of back-porting, for the vast
majority of PRs.  Just pick a final destination Milestone on the PR and
please DM me a "thank you" if you appreciate this.  An LLM armed with a
script is usually going to do this more thoroughly than you would have
(i.e. it actually considers multiple CI jobs and usually runs tests before
push).  And recently, I'll manually "resolve" the JIRA issue as well as the
final step (if it looks like a one-shot PR issue) -- Eric cleverly
convinced me I wasn't doing enough, so I've got this ;-).  It's really
rather satisfying.

So with that said, I want to ask the committers here that don't review
other people's PRs to please do so, especially those of contributors.  You
have powers they don't -- you can get something merged.  The contributor
will be grateful; remember being in their shoes.  You can fully handle a PR
responsiby without leaving the GitHub PR issue screen -- at least most of
the time.

p.s. I'm also grateful for Crave.io for very fast builds... but we'll need
to do without this by the end of the year :-(

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

Re: What a time to be a committer in 2026

[sanjay dutt <sa...@apache.org>]

Little warning, this reply can be seen going in a very different direction,
but then I am not here to predict the next best token. So bare with me,
please!

Very interesting title! What a time to be a committer in 2026.

Definitely stayed there with me for some time and now I thought why not I
should add to the pot. And I have decided not to use AI for this, screw you
AI! I should be careful AI is going to write me checks in future.

Going through the thread, I am not really sure where we have arrived, but
it's fun. I think It's AI vs us maybe. I believe the conversation started
because we need more people to review the code or something, then how many
PRs should be allowed, moving from copyright to whatnot.

And as much as I like to review any of the PR code from people using AI or
AI itself, sometimes I am just afraid that I will not say the right thing
because that's where I am in my Open source journey, It's collective
knowledge of all the people who have worked on it for decades. For me it's
not just possible to know ALL. And that's what my first lesson was: that I
need to accept that it's okay to not know everything. Just start with
something. And then you will find ideas to work on and the people who are
also interested in that. It's almost a mystery how we get attracted to some
certain part of the codebase and there are so many other things that can
fulfill so many like me.

Yes my AI can give me answers to be sure of something but my brain is like
please, I had enough! It's just this thing is always conceptually way
ahead. Nowadays it feels like I am working for AI.

Reading a ticket from AI, or a code throws me off, I can tell it's AI. But
then I ask myself what would make it more human? Is it the errors? Is it
some ticket which looks half-cooked and the idea is not final yet because
someone has to work through it and then I can contribute along the way. I
loved that actually. I try to imagine a future, just thinking about the
state of software. And, will there be only bots talking to each other,
looking at each other's work, reviewing, approving, merging and back
porting. Two possibilities: In 2139, the most famous committer will be the
one backed with the best AI assuming AI will keep on growing. Second
possibility: AI will eventually hit a plateau and we will make a comeback
-- let's go. That makes me also question about the days when the bar was
low, anyone could start contributing and now I think people with the best
access to models could contribute a lot more. Something to think about when
it comes to restricting PR from one person. Or how ASF should make models
available to others as well.

But at the same time, I also want to say that I have read tickets from the
past where the best of best have contributed. I have to admit it requires
major hardwork and years of devotion to a skill before you can actually
make a ticket like that or a comment on PR which makes others rethink their
whole strategy. AI still cannot do it. Writing something which is personal
is like a piece of puzzle that only you can produce but we cannot just do
that we have to be really interested in it. An idea that I can use for
myself while working on the tickets or PRs. Going to end here, because then
I will have the urge to give it to AI so that it can correct it. Sending it
out there with all it's errors,

-- Sanjay








On Sat, Oct 24, 2026 at 5:27 PM Jan Høydahl <ja...@apache.org> wrote:

> It's unfortunate that we as a project do not have a clear way to express
> what bugs or features we currently care about or what is just old garbage.
>
> So where we could really use a software factory is in triaging new and old
> JIRA issues. Reproduce bugs. Respond to reporter with clarifying questions,
> set a better severify, classify component, set label, contribute to
> landing a
> design where for complex things that require one etc.
>
> In dev@ thread "[DISCUSS] JIRA housekeeping — let's prune 3,000+ stale
> issues"
> I described our backlog problem (also analysis <
> https://claude.ai/public/artifacts/81fe75ce-e387-4b88-81fb-d4fc8b90a1a9>)
> and proposed a brute
> force approach of bulk closing old issues, to let only those someone still
> care about remain open. I have not come around to executing the plan yet.
> But if each and every of those 4000 open JIRAs could get individual
> judgement
> by an LLM, it would perhaps be easier to accept heavy pruning. A 3+ years
> old feature request means nothing, no matter how "good" an idea it may
> have been.
>
> Once the backlog came down to stuff we care about, we could apply a
> nightly
> JIRA triaging bot that assigns category/label, @metion people, ask
> reporter for
> reproduction steps, identifies duplicates etc, and we'd keep our JIRA
> backlog
> relevant and actionable. Easier to contribute for humans and bots alike.
>
> PS: This comment may be a slight tangent, belonging mainly to another dev@
> thread,
> so if you want to discuss JIRA pruning not in the context of LLM/software
> factory,
> please reply to the other thread.
>
> Jan
>
> > 24. okt. 2026 kl. 08:03 skrev David Smiley <ds...@apache.org>:
> >
> > I said we haven't been using "priority" much but I totally forgot a
> > narrow case where we definitely do:  Issues marked as priority=Blocker
> > AND with a "fix version" are intended to block that release, or at
> > least force a conversation about the matter as that release gets
> > close.  For example, there's a backwards-compatibiltiy concern that
> > can't be backported, like dropping the "collection" param.  I think
> > prioritizing such work right now doesn't make sense; Solr 11 isn't
> > soon; we don't even have 10.1!  If we want your help, we might
> > expressly ask for it or you should ask for a reviewer _first_ (and I
> > won't respond to you -- crickets may mean eventually but definitely
> > not now).  I can see now that you/your-factory has prioritized
> > priority=Blocker.  And now you/Eric requests my review on your PR...
> > sigh... so much to review, one more PR on top of who knows how many
> > that are still waiting...
> >
> > On Fri, Oct 23, 2026 at 7:02 PM Mike Drob <md...@mdrob.com> wrote:
> >>
> >> I’ll add in a bit of personal perspective. Working on Solr used to be my
> >> full time job; I have since moved on to other (sometimes less green)
> >> pastures. I still keep an eye on the project because it interests me
> and I
> >> enjoy the people. But anything I filed as a feature or improvement back
> in
> >> 2022 was probably a wish list item to make my own job easier. Those
> might
> >> still be helpful if they generalize but they also might not. I never
> went
> >> back and said “this is no longer important” on that list.
> >>
> >> An analogy, I walk to school every day and asked the city to put in some
> >> flowers along the path. Then I graduate and move to a new place, and
> some
> >> city administrator sees my request after a while. They put in the
> flowers
> >> but I’m not there to enjoy them. Maybe I was the only one to walk that
> >> path, or maybe there are others who will appreciate them.
> >>
> >> Mike
> >>
> >> On Fri, Oct 23, 2026 at 3:37 PM David Smiley <ds...@apache.org>
> wrote:
> >>
> >>> Hello Nick!
> >>>
> >>> Thanks for contributing to the discussion here.
> >>>
> >>> If you (Nick) were doing work on matters of specific interest to you,
> >>> then I wouldn't advise you much on selecting such work since they
> >>> matter to you enough to bother producing a solution.  And one person's
> >>> actual focus can only be so much.  But that's not the case here;
> >>> you've built a software factory that could work on anything with
> >>> boundless focuss.  I want to flip this around so that *committers*
> >>> (not your factory!) choose what to really start work on!  Committers
> >>> (or any human I guess) should first confirm that we want solutions for
> >>> certain JIRA issues.  Otherwise (current state), your choices have
> >>> dominated our review time, even when you don't know what the
> >>> committers collectively consider to be important (i.e. by at least one
> >>> of us, *wanting* a solution to a specific issue to review).  Any PRs
> >>> aren't going to even get a review.  **Basically, I want your factory
> >>> to solicit a reviewer on a specific issue before starting work.**
> >>> That's the ask.  Not merely whether someone cares, but who will
> >>> review?  The next step might be a PR but I hope in many cases would be
> >>> a *plan* (comment on a JIRA issue) of work that could first be
> >>> negotiated.  For example if there's an alleged bug, maybe the first
> >>> step is simply a reproduction attempt to validate it, or a code
> >>> reading assessment of the bug as a substitute (if not easily
> >>> reproduced).
> >>>
> >>> The JIRA issue "priority" hasn't been populated with selection
> >>> criteria or consequence for the choice, so it's often the default
> >>> value of "Major".  Often it's chosen by a contributor, not a
> >>> committer.  We mostly ignore it TBH.  I can sympathize your factory
> >>> needs *something* to use as a backlock prioritizer, and might as well
> >>> pick this.  I just want to highlight how inadequate it is at the
> >>> moment.  I may bump up the priortity of some JIRA issues to "Critical"
> >>> despite that word sounding rather alarmist/excessive for some work.
> >>> I don't think "newdev" should be a backlog prioritization factor.
> >>>
> >>> Take care to see when there's existing work on an issue (PR or
> >>> attached patch) or if it's "Assigned" to someone.  Avoid those.
> >>>
> >>> ~ David
> >>>
> >>> On Fri, Oct 23, 2026 at 12:15 PM Nick Boss <ni...@gmail.com>
> wrote:
> >>>>
> >>>> Hello, Solr!
> >>>> Nick here, I had a great chat with Eric and I am excited to be here. I
> >>> know
> >>>> I opened many PRs and I look forward to being part of the community
> while
> >>>> following community norms.
> >>>>
> >>>> There has never been a better time to be a contributor; I have a lot
> to
> >>>> share.
> >>>> Big thanks to David Smiley for all the backports.
> >>>> This email is my attempt at the follow-through this thread asks for.
> >>>>
> >>>> TL/DR: I will clear out blocker and critical items first. A list of 10
> >>> easy
> >>>> PRs and 10 Blocker/Critical PRs is at the bottom.
> >>>>
> >>>> 1. How the work is done
> >>>> - I work through the backlog with AI assistance, and every PR
> description
> >>>> says so.
> >>>> - Nothing goes out under my name that I have not read first.
> >>>> - I direct the work and I stand behind it; the commits carry my name
> >>>> because they are mine to answer for.
> >>>> - Results: 90 open PRs, 12 that have merged.
> >>>> - I answer review comments the day they arrive.
> >>>> - I reply with my human voice when I can.
> >>>>
> >>>> 2. Taking the criticism
> >>>> - The criticism I take from this thread is about closure, not effort,
> >>> and I
> >>>> think that is fair.
> >>>> - A PR that sits open is not finished work, however fast its author
> >>> replies.
> >>>> - Spread out is a fair description of the queue. It is not a fair
> >>>> description of any single PR in it.
> >>>> - Software factories are not built in a day and quality beats volume.
> >>>>
> >>>> 3. What follow-through means from my side
> >>>> - Every comment gets an answer.
> >>>> - I check if a change is even worth it first. I check if code could be
> >>>> removed rather than added. I slow down to try to understand more.
> >>>> - If a PR of mine goes quiet because the next step is mine, that is on
> >>> me.
> >>>> - I will talk about my PRs on the mailing list.
> >>>>
> >>>> 4. The two-sided part
> >>>> - Closure takes two people. A PR can be ready, answered, and green,
> and
> >>> it
> >>>> still closes only when a reviewer picks it up.
> >>>>
> >>>> 5. The priority commitment
> >>>> - My order from here is Blockers and Criticals first, then "new
> >>> developer".
> >>>> I also check PRs from others.
> >>>> - Open Blocker tickets will get PRs or JIRA notes this week.
> >>>>
> >>>> 6. Drafts
> >>>> - I will stop parking finished work as drafts.
> >>>> - Drafts from me will mean genuinely unfinished, and there will be
> few of
> >>>> them.
> >>>>
> >>>> 7. What I am not asking
> >>>> - For the cap to be lifted for me.
> >>>> - For anyone to believe I am a human.
> >>>>
> >>>> In closing,
> >>>> - Tell me where this is wrong. I am teachable.
> >>>> - Thank you to the people who have been merging this work, including
> this
> >>>> week.
> >>>>
> >>>>
> >>>> 10 Blocker/Critical PRs:
> >>>> - #5181 https://github.com/apache/solr/pull/5181 · SOLR-18552 ·
> Blocker
> >>> ·
> >>>> 9.x launcher passes the MMapDirectory arena permits
> >>>> - #5199 https://github.com/apache/solr/pull/5199 · SOLR-14200 ·
> >>> Critical ·
> >>>> streaming fails clearly instead of an NPE on a missing shards-map
> entry
> >>>> - #5200 https://github.com/apache/solr/pull/5200 · SOLR-16155 ·
> >>> Critical ·
> >>>> field values out of indexing error messages
> >>>> - #5003 https://github.com/apache/solr/pull/5003 · SOLR-7394 ·
> Critical
> >>> ·
> >>>> clear the recovering shard-terms entry when recovery is abandoned
> >>>> - #5139 https://github.com/apache/solr/pull/5139 · SOLR-7550 ·
> Critical
> >>> · a
> >>>> 500 for the versions request counts as success when
> cantReachIsSuccess is
> >>>> set, same as a 503
> >>>> - #5093 https://github.com/apache/solr/pull/5093 · SOLR-16655 ·
> >>> Critical ·
> >>>> indexing nested documents and update processors
> >>>> - #5118 https://github.com/apache/solr/pull/5118 · SOLR-18010 ·
> >>> Critical ·
> >>>> security.json replacement through a synced temp file
> >>>> - #5203 https://github.com/apache/solr/pull/5203 · SOLR-17844 ·
> Blocker
> >>> ·
> >>>> sort-assertion test repair
> >>>> - #5202 https://github.com/apache/solr/pull/5202 · SOLR-18446 ·
> Blocker
> >>> ·
> >>>> collection routing follows the path, not the parameter
> >>>> - #5117 https://github.com/apache/solr/pull/5117 · SOLR-18541 ·
> Major ·
> >>>> distributed search returns wrong totals, silently
> >>>>
> >>>>
> >>>> 10 Easy-to-review PRs:
> >>>> - #5116 https://github.com/apache/solr/pull/5116 · SOLR-18540 ·
> gradlew
> >>>> under Git Bash · 13 lines
> >>>> - #5098 https://github.com/apache/solr/pull/5098 · SOLR-18530 · route
> >>> adds
> >>>> after the proxy cut in recovery · 20
> >>>> - #5002 https://github.com/apache/solr/pull/5002 · SOLR-11431 · a
> core
> >>> that
> >>>> fails to load returns 503, not 500 · 23
> >>>> - #5090 https://github.com/apache/solr/pull/5090 · SOLR-14262 ·
> skipped
> >>>> commit and the update log · 34
> >>>> - #5094 https://github.com/apache/solr/pull/5094 · SOLR-16673 ·
> numeric
> >>>> field update processors · 34
> >>>> - #5104 https://github.com/apache/solr/pull/5104 · SOLR-2681 ·
> original
> >>>> highlighter term extraction · 35
> >>>> - #5086 https://github.com/apache/solr/pull/5086 · SOLR-12864 · test
> >>>> coverage for echo with mapUniqueKeyOnly · 37
> >>>> - #5131 https://github.com/apache/solr/pull/5131 · SOLR-5394 ·
> default
> >>>> per-field thread count · 37
> >>>> - #5158 https://github.com/apache/solr/pull/5158 · SOLR-10305 ·
> >>> distributed
> >>>> request on a schema with no unique key · 42
> >>>> - #5105 https://github.com/apache/solr/pull/5105 · SOLR-4540 ·
> >>>> FastVectorHighlighter per-field work · 43
> >>>>
> >>>> On Thu, Oct 22, 2026 at 4:26 PM David Smiley <ds...@apache.org>
> wrote:
> >>>>
> >>>>> So well written AB; exactly.  My attempt:  FOLLOW-THROUGH (closure ==
> >>>>> success) is valued over a great quantity of first-drafts.  Same
> energy
> >>>>> level is appreciated, just focused instead of spread out.
> >>>>>
> >>>>> On Sun, Oct 18, 2026 at 9:35 AM Andrzej Białecki <ab...@getopt.org>
> >>> wrote:
> >>>>>>
> >>>>>> Eric wrote:
> >>>>>>
> >>>>>>> 1) We could limit the number of PR's opened, but to me, it just
> >>> seems
> >>>>> like we are gating potential new contributions (and anyway we close
> >>> PR's if
> >>>>> they don't get activity after a period of time anyway).
> >>>>>>>
> >>>>>>
> >>>>>> I don’t see this as gating in the sense of discouraging new
> >>> contributors
> >>>>> - quite the opposite, I see this as a quality and closure gate. If
> all
> >>> you
> >>>>> can open is 7 PRs you will think twice before opening the 7th one,
> and
> >>> you
> >>>>> will be more invested in helping close the first 6. Current situation
> >>> where
> >>>>> anyone can open 50 PRs and then follow up with rote AI responses is
> >>>>> untenable.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Andrzej
> >>>>>>
> >>>>>>> On 16 Oct 2026, at 16:16, Eric Pugh <ep...@apache.org> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> >>>>>>>> I'm not sure I agree with the bullish assessment on all fronts
> >>> haha,
> >>>>>>>> but I love the call to action! Both as individuals and as a group
> >>> we
> >>>>>>>> can be doing more to help out contributors.
> >>>>>>>>
> >>>>>>>> As an aside - I haven't played around with the Github Copilot
> >>> stuff
> >>>>>>>> you mentioned.  (Largely because I've been pretty happy with
> >>> Claude).
> >>>>>>>> Maybe I'm alone in being a late adopter there, but if I'm not then
> >>>>>>>> maybe that'd make a good demo for our community meetup?  Show
> >>> other
> >>>>>>>> committers something that you've seemingly found revolutionary in
> >>> your
> >>>>>>>> review workflow.
> >>>>>>>>
> >>>>>>>>> Eric cleverly convinced me I wasn't doing enough
> >>>>>>>>
> >>>>>>>> Never listen to Eric :-p
> >>>>>>>>
> >>>>>>>> Jason
> >>>>>>>>
> >>>>>>>> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> >>>>>>>> <ar...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Maybe we can get a dedicated open source code review bot and
> >>> tweak
> >>>>> it’s code for us. That should instill more confidence :)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
> >>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> It's never been an easier time as a committer to be the
> >>>>> shepherd/reviewer
> >>>>>>>>>> to a non-committer PR.  We have automated code reviews via
> >>> GitHub
> >>>>> co-pilot
> >>>>>>>>>> (need to add as a reviewer to engage).  No longer do we have to
> >>>>> edit a
> >>>>>>>>>> massive CHANGES.txt to pick a version that might be wrong or
> >>> even
> >>>>> know the
> >>>>>>>>>> version.  No longer do we have the chore of back-porting, for
> >>> the
> >>>>> vast
> >>>>>>>>>> majority of PRs.  Just pick a final destination Milestone on
> >>> the PR
> >>>>> and
> >>>>>>>>>> please DM me a "thank you" if you appreciate this.  An LLM armed
> >>>>> with a
> >>>>>>>>>> script is usually going to do this more thoroughly than you
> >>> would
> >>>>> have
> >>>>>>>>>> (i.e. it actually considers multiple CI jobs and usually runs
> >>> tests
> >>>>> before
> >>>>>>>>>> push).  And recently, I'll manually "resolve" the JIRA issue as
> >>>>> well as the
> >>>>>>>>>> final step (if it looks like a one-shot PR issue) -- Eric
> >>> cleverly
> >>>>>>>>>> convinced me I wasn't doing enough, so I've got this ;-).  It's
> >>>>> really
> >>>>>>>>>> rather satisfying.
> >>>>>>>>>>
> >>>>>>>>>> So with that said, I want to ask the committers here that don't
> >>>>> review
> >>>>>>>>>> other people's PRs to please do so, especially those of
> >>>>> contributors.  You
> >>>>>>>>>> have powers they don't -- you can get something merged.  The
> >>>>> contributor
> >>>>>>>>>> will be grateful; remember being in their shoes.  You can fully
> >>>>> handle a PR
> >>>>>>>>>> responsiby without leaving the GitHub PR issue screen -- at
> >>> least
> >>>>> most of
> >>>>>>>>>> the time.
> >>>>>>>>>>
> >>>>>>>>>> p.s. I'm also grateful for Crave.io for very fast builds... but
> >>>>> we'll need
> >>>>>>>>>> to do without this by the end of the year :-(
> >>>>>>>>>>
> >>>>>>>>>> ~ David Smiley
> >>>>>>>>>> Apache Lucene/Solr Search Developer
> >>>>>>>>>> http://www.linkedin.com/in/davidwsmiley
> >>>>>>>>>
> >>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> A big topic at Community/Code this past week across all the
> >>> projects
> >>>>> (not just ours) was the benefits and perils of AI assisted coding.
> >>> During
> >>>>> the past few months we've seen some very prolific new contributors
> >>> (thanks
> >>>>> Serhiy!) start contributing to Solr.   The fresh energy has really
> >>>>> increased our project development.   Then we've had Nick join the
> >>> party,
> >>>>> and he has gone through our JIRA backlog and cranked out quite a few
> >>> PR's
> >>>>> that deal with long dormant tickets.
> >>>>>>>
> >>>>>>> I wanted to start a thread and share some thoughts with the dev@
> >>> list.
> >>>>>>>
> >>>>>>> There are a couple of approaches we could take to these new
> >>>>> contributions.
> >>>>>>>
> >>>>>>> 1) We could limit the number of PR's opened, but to me, it just
> >>> seems
> >>>>> like we are gating potential new contributions (and anyway we close
> >>> PR's if
> >>>>> they don't get activity after a period of time anyway).
> >>>>>>>
> >>>>>>> 2) We probably *should* go back through our JIRA and close issues
> >>> that
> >>>>> are no longer relevant to the project so that new contributors don't
> >>> get
> >>>>> mislead.  Today I would consider any JIRA issue open for Solr as a
> >>> valid
> >>>>> one to be worked, but maybe that isnt' the case.
> >>>>>>>
> >>>>>>> 3) We could establish strong prioritization for what PR's need
> >>>>> review.  For example, when I look at what Nick has provided, maybe we
> >>> want
> >>>>> to focus first on bugs before we focus on feature oriented PR's?
> >>>>>>>
> >>>>>>> 4) We could lean more heavily into AI for evaluating PRs so we can
> >>> get
> >>>>> through them easier?  I know I struggle with PR's that I want to
> >>> review,
> >>>>> but aren't in an area that I have deep expertise in.  Unforutantly,
> too
> >>>>> many of those PRs then just wither on the vine.
> >>>>>>>
> >>>>>>> 5) We can try and activate more committers and contributors to be
> >>>>> reviwers.  I'm referencing David's email: "What a time to be a
> >>> committer in
> >>>>> 2026".
> >>>>>
> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
> >>>>>>>
> >>>>>>> I don't know what the right path forward is, though I suspect it
> >>> all
> >>>>> requires us to grow the set of people reviewing PR's.   Any approach
> we
> >>>>> take hits up against the fundamental limit of us having only so many
> >>> folks
> >>>>> actively working PR's and merging them.
> >>>>>>>
> >>>>>>> Beyond that, I wanted to start thinking about who to tag for review
> >>>>> beyond the immediate suspects that Github recommends.  My thought was
> >>> "Who
> >>>>> are the specialists in various areas" that maybe aren't super active,
> >>> but
> >>>>> would be happy to engage on a PR.
> >>>>>>>
> >>>>>>> So I put together this analysis:
> >>>>>
> >>>
> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> >>>>>>>
> >>>>>>> I'd love feedback on it, I suspect it will go through some
> >>> iterations
> >>>>> to be accurate.
> >>>>>>>
> >>>>>>> Secondly, I wanted to get my arms around the contributions from
> >>> Nick,
> >>>>> as there are 30 of them which makes it tough to figure out where to
> >>> start.
> >>>>> I went ahead and leaned into my current "Pacific Rim" movie
> >>> fascination,
> >>>>> and did an analysis of them.   I tried to seperate out the pure bug
> fix
> >>>>> from the feature fixes, and get a quick sense of the complexity of
> >>> going
> >>>>> through them.
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>
> >>>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
>

Re: What a time to be a committer in 2026

[Jan Høydahl <ja...@apache.org>]

It's unfortunate that we as a project do not have a clear way to express
what bugs or features we currently care about or what is just old garbage.

So where we could really use a software factory is in triaging new and old
JIRA issues. Reproduce bugs. Respond to reporter with clarifying questions,
set a better severify, classify component, set label, contribute to landing a
design where for complex things that require one etc.

In dev@ thread "[DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues"
I described our backlog problem (also analysis <https://claude.ai/public/artifacts/81fe75ce-e387-4b88-81fb-d4fc8b90a1a9>) and proposed a brute
force approach of bulk closing old issues, to let only those someone still
care about remain open. I have not come around to executing the plan yet.
But if each and every of those 4000 open JIRAs could get individual judgement
by an LLM, it would perhaps be easier to accept heavy pruning. A 3+ years
old feature request means nothing, no matter how "good" an idea it may have been.

Once the backlog came down to stuff we care about, we could apply a nightly 
JIRA triaging bot that assigns category/label, @metion people, ask reporter for
reproduction steps, identifies duplicates etc, and we'd keep our JIRA backlog
relevant and actionable. Easier to contribute for humans and bots alike.

PS: This comment may be a slight tangent, belonging mainly to another dev@ thread,
so if you want to discuss JIRA pruning not in the context of LLM/software factory,
please reply to the other thread.

Jan

> 24. okt. 2026 kl. 08:03 skrev David Smiley <ds...@apache.org>:
> 
> I said we haven't been using "priority" much but I totally forgot a
> narrow case where we definitely do:  Issues marked as priority=Blocker
> AND with a "fix version" are intended to block that release, or at
> least force a conversation about the matter as that release gets
> close.  For example, there's a backwards-compatibiltiy concern that
> can't be backported, like dropping the "collection" param.  I think
> prioritizing such work right now doesn't make sense; Solr 11 isn't
> soon; we don't even have 10.1!  If we want your help, we might
> expressly ask for it or you should ask for a reviewer _first_ (and I
> won't respond to you -- crickets may mean eventually but definitely
> not now).  I can see now that you/your-factory has prioritized
> priority=Blocker.  And now you/Eric requests my review on your PR...
> sigh... so much to review, one more PR on top of who knows how many
> that are still waiting...
> 
> On Fri, Oct 23, 2026 at 7:02 PM Mike Drob <md...@mdrob.com> wrote:
>> 
>> I’ll add in a bit of personal perspective. Working on Solr used to be my
>> full time job; I have since moved on to other (sometimes less green)
>> pastures. I still keep an eye on the project because it interests me and I
>> enjoy the people. But anything I filed as a feature or improvement back in
>> 2022 was probably a wish list item to make my own job easier. Those might
>> still be helpful if they generalize but they also might not. I never went
>> back and said “this is no longer important” on that list.
>> 
>> An analogy, I walk to school every day and asked the city to put in some
>> flowers along the path. Then I graduate and move to a new place, and some
>> city administrator sees my request after a while. They put in the flowers
>> but I’m not there to enjoy them. Maybe I was the only one to walk that
>> path, or maybe there are others who will appreciate them.
>> 
>> Mike
>> 
>> On Fri, Oct 23, 2026 at 3:37 PM David Smiley <ds...@apache.org> wrote:
>> 
>>> Hello Nick!
>>> 
>>> Thanks for contributing to the discussion here.
>>> 
>>> If you (Nick) were doing work on matters of specific interest to you,
>>> then I wouldn't advise you much on selecting such work since they
>>> matter to you enough to bother producing a solution.  And one person's
>>> actual focus can only be so much.  But that's not the case here;
>>> you've built a software factory that could work on anything with
>>> boundless focuss.  I want to flip this around so that *committers*
>>> (not your factory!) choose what to really start work on!  Committers
>>> (or any human I guess) should first confirm that we want solutions for
>>> certain JIRA issues.  Otherwise (current state), your choices have
>>> dominated our review time, even when you don't know what the
>>> committers collectively consider to be important (i.e. by at least one
>>> of us, *wanting* a solution to a specific issue to review).  Any PRs
>>> aren't going to even get a review.  **Basically, I want your factory
>>> to solicit a reviewer on a specific issue before starting work.**
>>> That's the ask.  Not merely whether someone cares, but who will
>>> review?  The next step might be a PR but I hope in many cases would be
>>> a *plan* (comment on a JIRA issue) of work that could first be
>>> negotiated.  For example if there's an alleged bug, maybe the first
>>> step is simply a reproduction attempt to validate it, or a code
>>> reading assessment of the bug as a substitute (if not easily
>>> reproduced).
>>> 
>>> The JIRA issue "priority" hasn't been populated with selection
>>> criteria or consequence for the choice, so it's often the default
>>> value of "Major".  Often it's chosen by a contributor, not a
>>> committer.  We mostly ignore it TBH.  I can sympathize your factory
>>> needs *something* to use as a backlock prioritizer, and might as well
>>> pick this.  I just want to highlight how inadequate it is at the
>>> moment.  I may bump up the priortity of some JIRA issues to "Critical"
>>> despite that word sounding rather alarmist/excessive for some work.
>>> I don't think "newdev" should be a backlog prioritization factor.
>>> 
>>> Take care to see when there's existing work on an issue (PR or
>>> attached patch) or if it's "Assigned" to someone.  Avoid those.
>>> 
>>> ~ David
>>> 
>>> On Fri, Oct 23, 2026 at 12:15 PM Nick Boss <ni...@gmail.com> wrote:
>>>> 
>>>> Hello, Solr!
>>>> Nick here, I had a great chat with Eric and I am excited to be here. I
>>> know
>>>> I opened many PRs and I look forward to being part of the community while
>>>> following community norms.
>>>> 
>>>> There has never been a better time to be a contributor; I have a lot to
>>>> share.
>>>> Big thanks to David Smiley for all the backports.
>>>> This email is my attempt at the follow-through this thread asks for.
>>>> 
>>>> TL/DR: I will clear out blocker and critical items first. A list of 10
>>> easy
>>>> PRs and 10 Blocker/Critical PRs is at the bottom.
>>>> 
>>>> 1. How the work is done
>>>> - I work through the backlog with AI assistance, and every PR description
>>>> says so.
>>>> - Nothing goes out under my name that I have not read first.
>>>> - I direct the work and I stand behind it; the commits carry my name
>>>> because they are mine to answer for.
>>>> - Results: 90 open PRs, 12 that have merged.
>>>> - I answer review comments the day they arrive.
>>>> - I reply with my human voice when I can.
>>>> 
>>>> 2. Taking the criticism
>>>> - The criticism I take from this thread is about closure, not effort,
>>> and I
>>>> think that is fair.
>>>> - A PR that sits open is not finished work, however fast its author
>>> replies.
>>>> - Spread out is a fair description of the queue. It is not a fair
>>>> description of any single PR in it.
>>>> - Software factories are not built in a day and quality beats volume.
>>>> 
>>>> 3. What follow-through means from my side
>>>> - Every comment gets an answer.
>>>> - I check if a change is even worth it first. I check if code could be
>>>> removed rather than added. I slow down to try to understand more.
>>>> - If a PR of mine goes quiet because the next step is mine, that is on
>>> me.
>>>> - I will talk about my PRs on the mailing list.
>>>> 
>>>> 4. The two-sided part
>>>> - Closure takes two people. A PR can be ready, answered, and green, and
>>> it
>>>> still closes only when a reviewer picks it up.
>>>> 
>>>> 5. The priority commitment
>>>> - My order from here is Blockers and Criticals first, then "new
>>> developer".
>>>> I also check PRs from others.
>>>> - Open Blocker tickets will get PRs or JIRA notes this week.
>>>> 
>>>> 6. Drafts
>>>> - I will stop parking finished work as drafts.
>>>> - Drafts from me will mean genuinely unfinished, and there will be few of
>>>> them.
>>>> 
>>>> 7. What I am not asking
>>>> - For the cap to be lifted for me.
>>>> - For anyone to believe I am a human.
>>>> 
>>>> In closing,
>>>> - Tell me where this is wrong. I am teachable.
>>>> - Thank you to the people who have been merging this work, including this
>>>> week.
>>>> 
>>>> 
>>>> 10 Blocker/Critical PRs:
>>>> - #5181 https://github.com/apache/solr/pull/5181 · SOLR-18552 · Blocker
>>> ·
>>>> 9.x launcher passes the MMapDirectory arena permits
>>>> - #5199 https://github.com/apache/solr/pull/5199 · SOLR-14200 ·
>>> Critical ·
>>>> streaming fails clearly instead of an NPE on a missing shards-map entry
>>>> - #5200 https://github.com/apache/solr/pull/5200 · SOLR-16155 ·
>>> Critical ·
>>>> field values out of indexing error messages
>>>> - #5003 https://github.com/apache/solr/pull/5003 · SOLR-7394 · Critical
>>> ·
>>>> clear the recovering shard-terms entry when recovery is abandoned
>>>> - #5139 https://github.com/apache/solr/pull/5139 · SOLR-7550 · Critical
>>> · a
>>>> 500 for the versions request counts as success when cantReachIsSuccess is
>>>> set, same as a 503
>>>> - #5093 https://github.com/apache/solr/pull/5093 · SOLR-16655 ·
>>> Critical ·
>>>> indexing nested documents and update processors
>>>> - #5118 https://github.com/apache/solr/pull/5118 · SOLR-18010 ·
>>> Critical ·
>>>> security.json replacement through a synced temp file
>>>> - #5203 https://github.com/apache/solr/pull/5203 · SOLR-17844 · Blocker
>>> ·
>>>> sort-assertion test repair
>>>> - #5202 https://github.com/apache/solr/pull/5202 · SOLR-18446 · Blocker
>>> ·
>>>> collection routing follows the path, not the parameter
>>>> - #5117 https://github.com/apache/solr/pull/5117 · SOLR-18541 · Major ·
>>>> distributed search returns wrong totals, silently
>>>> 
>>>> 
>>>> 10 Easy-to-review PRs:
>>>> - #5116 https://github.com/apache/solr/pull/5116 · SOLR-18540 · gradlew
>>>> under Git Bash · 13 lines
>>>> - #5098 https://github.com/apache/solr/pull/5098 · SOLR-18530 · route
>>> adds
>>>> after the proxy cut in recovery · 20
>>>> - #5002 https://github.com/apache/solr/pull/5002 · SOLR-11431 · a core
>>> that
>>>> fails to load returns 503, not 500 · 23
>>>> - #5090 https://github.com/apache/solr/pull/5090 · SOLR-14262 · skipped
>>>> commit and the update log · 34
>>>> - #5094 https://github.com/apache/solr/pull/5094 · SOLR-16673 · numeric
>>>> field update processors · 34
>>>> - #5104 https://github.com/apache/solr/pull/5104 · SOLR-2681 · original
>>>> highlighter term extraction · 35
>>>> - #5086 https://github.com/apache/solr/pull/5086 · SOLR-12864 · test
>>>> coverage for echo with mapUniqueKeyOnly · 37
>>>> - #5131 https://github.com/apache/solr/pull/5131 · SOLR-5394 · default
>>>> per-field thread count · 37
>>>> - #5158 https://github.com/apache/solr/pull/5158 · SOLR-10305 ·
>>> distributed
>>>> request on a schema with no unique key · 42
>>>> - #5105 https://github.com/apache/solr/pull/5105 · SOLR-4540 ·
>>>> FastVectorHighlighter per-field work · 43
>>>> 
>>>> On Thu, Oct 22, 2026 at 4:26 PM David Smiley <ds...@apache.org> wrote:
>>>> 
>>>>> So well written AB; exactly.  My attempt:  FOLLOW-THROUGH (closure ==
>>>>> success) is valued over a great quantity of first-drafts.  Same energy
>>>>> level is appreciated, just focused instead of spread out.
>>>>> 
>>>>> On Sun, Oct 18, 2026 at 9:35 AM Andrzej Białecki <ab...@getopt.org>
>>> wrote:
>>>>>> 
>>>>>> Eric wrote:
>>>>>> 
>>>>>>> 1) We could limit the number of PR's opened, but to me, it just
>>> seems
>>>>> like we are gating potential new contributions (and anyway we close
>>> PR's if
>>>>> they don't get activity after a period of time anyway).
>>>>>>> 
>>>>>> 
>>>>>> I don’t see this as gating in the sense of discouraging new
>>> contributors
>>>>> - quite the opposite, I see this as a quality and closure gate. If all
>>> you
>>>>> can open is 7 PRs you will think twice before opening the 7th one, and
>>> you
>>>>> will be more invested in helping close the first 6. Current situation
>>> where
>>>>> anyone can open 50 PRs and then follow up with rote AI responses is
>>>>> untenable.
>>>>>> 
>>>>>> Cheers,
>>>>>> Andrzej
>>>>>> 
>>>>>>> On 16 Oct 2026, at 16:16, Eric Pugh <ep...@apache.org> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 2026/09/03 22:44:13 Jason Gerlowski wrote:
>>>>>>>> I'm not sure I agree with the bullish assessment on all fronts
>>> haha,
>>>>>>>> but I love the call to action! Both as individuals and as a group
>>> we
>>>>>>>> can be doing more to help out contributors.
>>>>>>>> 
>>>>>>>> As an aside - I haven't played around with the Github Copilot
>>> stuff
>>>>>>>> you mentioned.  (Largely because I've been pretty happy with
>>> Claude).
>>>>>>>> Maybe I'm alone in being a late adopter there, but if I'm not then
>>>>>>>> maybe that'd make a good demo for our community meetup?  Show
>>> other
>>>>>>>> committers something that you've seemingly found revolutionary in
>>> your
>>>>>>>> review workflow.
>>>>>>>> 
>>>>>>>>> Eric cleverly convinced me I wasn't doing enough
>>>>>>>> 
>>>>>>>> Never listen to Eric :-p
>>>>>>>> 
>>>>>>>> Jason
>>>>>>>> 
>>>>>>>> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
>>>>>>>> <ar...@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> Maybe we can get a dedicated open source code review bot and
>>> tweak
>>>>> it’s code for us. That should instill more confidence :)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> It's never been an easier time as a committer to be the
>>>>> shepherd/reviewer
>>>>>>>>>> to a non-committer PR.  We have automated code reviews via
>>> GitHub
>>>>> co-pilot
>>>>>>>>>> (need to add as a reviewer to engage).  No longer do we have to
>>>>> edit a
>>>>>>>>>> massive CHANGES.txt to pick a version that might be wrong or
>>> even
>>>>> know the
>>>>>>>>>> version.  No longer do we have the chore of back-porting, for
>>> the
>>>>> vast
>>>>>>>>>> majority of PRs.  Just pick a final destination Milestone on
>>> the PR
>>>>> and
>>>>>>>>>> please DM me a "thank you" if you appreciate this.  An LLM armed
>>>>> with a
>>>>>>>>>> script is usually going to do this more thoroughly than you
>>> would
>>>>> have
>>>>>>>>>> (i.e. it actually considers multiple CI jobs and usually runs
>>> tests
>>>>> before
>>>>>>>>>> push).  And recently, I'll manually "resolve" the JIRA issue as
>>>>> well as the
>>>>>>>>>> final step (if it looks like a one-shot PR issue) -- Eric
>>> cleverly
>>>>>>>>>> convinced me I wasn't doing enough, so I've got this ;-).  It's
>>>>> really
>>>>>>>>>> rather satisfying.
>>>>>>>>>> 
>>>>>>>>>> So with that said, I want to ask the committers here that don't
>>>>> review
>>>>>>>>>> other people's PRs to please do so, especially those of
>>>>> contributors.  You
>>>>>>>>>> have powers they don't -- you can get something merged.  The
>>>>> contributor
>>>>>>>>>> will be grateful; remember being in their shoes.  You can fully
>>>>> handle a PR
>>>>>>>>>> responsiby without leaving the GitHub PR issue screen -- at
>>> least
>>>>> most of
>>>>>>>>>> the time.
>>>>>>>>>> 
>>>>>>>>>> p.s. I'm also grateful for Crave.io for very fast builds... but
>>>>> we'll need
>>>>>>>>>> to do without this by the end of the year :-(
>>>>>>>>>> 
>>>>>>>>>> ~ David Smiley
>>>>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>>> 
>>>>>>>>> 
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> A big topic at Community/Code this past week across all the
>>> projects
>>>>> (not just ours) was the benefits and perils of AI assisted coding.
>>> During
>>>>> the past few months we've seen some very prolific new contributors
>>> (thanks
>>>>> Serhiy!) start contributing to Solr.   The fresh energy has really
>>>>> increased our project development.   Then we've had Nick join the
>>> party,
>>>>> and he has gone through our JIRA backlog and cranked out quite a few
>>> PR's
>>>>> that deal with long dormant tickets.
>>>>>>> 
>>>>>>> I wanted to start a thread and share some thoughts with the dev@
>>> list.
>>>>>>> 
>>>>>>> There are a couple of approaches we could take to these new
>>>>> contributions.
>>>>>>> 
>>>>>>> 1) We could limit the number of PR's opened, but to me, it just
>>> seems
>>>>> like we are gating potential new contributions (and anyway we close
>>> PR's if
>>>>> they don't get activity after a period of time anyway).
>>>>>>> 
>>>>>>> 2) We probably *should* go back through our JIRA and close issues
>>> that
>>>>> are no longer relevant to the project so that new contributors don't
>>> get
>>>>> mislead.  Today I would consider any JIRA issue open for Solr as a
>>> valid
>>>>> one to be worked, but maybe that isnt' the case.
>>>>>>> 
>>>>>>> 3) We could establish strong prioritization for what PR's need
>>>>> review.  For example, when I look at what Nick has provided, maybe we
>>> want
>>>>> to focus first on bugs before we focus on feature oriented PR's?
>>>>>>> 
>>>>>>> 4) We could lean more heavily into AI for evaluating PRs so we can
>>> get
>>>>> through them easier?  I know I struggle with PR's that I want to
>>> review,
>>>>> but aren't in an area that I have deep expertise in.  Unforutantly, too
>>>>> many of those PRs then just wither on the vine.
>>>>>>> 
>>>>>>> 5) We can try and activate more committers and contributors to be
>>>>> reviwers.  I'm referencing David's email: "What a time to be a
>>> committer in
>>>>> 2026".
>>>>> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
>>>>>>> 
>>>>>>> I don't know what the right path forward is, though I suspect it
>>> all
>>>>> requires us to grow the set of people reviewing PR's.   Any approach we
>>>>> take hits up against the fundamental limit of us having only so many
>>> folks
>>>>> actively working PR's and merging them.
>>>>>>> 
>>>>>>> Beyond that, I wanted to start thinking about who to tag for review
>>>>> beyond the immediate suspects that Github recommends.  My thought was
>>> "Who
>>>>> are the specialists in various areas" that maybe aren't super active,
>>> but
>>>>> would be happy to engage on a PR.
>>>>>>> 
>>>>>>> So I put together this analysis:
>>>>> 
>>> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
>>>>>>> 
>>>>>>> I'd love feedback on it, I suspect it will go through some
>>> iterations
>>>>> to be accurate.
>>>>>>> 
>>>>>>> Secondly, I wanted to get my arms around the contributions from
>>> Nick,
>>>>> as there are 30 of them which makes it tough to figure out where to
>>> start.
>>>>> I went ahead and leaned into my current "Pacific Rim" movie
>>> fascination,
>>>>> and did an analysis of them.   I tried to seperate out the pure bug fix
>>>>> from the feature fixes, and get a quick sense of the complexity of
>>> going
>>>>> through them.
>>>>>>> 
>>>>>>> 
>>>>> 
>>> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>> 
>>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>> 
>>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
> 

Re: What a time to be a committer in 2026

[David Smiley <ds...@apache.org>]

I said we haven't been using "priority" much but I totally forgot a
narrow case where we definitely do:  Issues marked as priority=Blocker
AND with a "fix version" are intended to block that release, or at
least force a conversation about the matter as that release gets
close.  For example, there's a backwards-compatibiltiy concern that
can't be backported, like dropping the "collection" param.  I think
prioritizing such work right now doesn't make sense; Solr 11 isn't
soon; we don't even have 10.1!  If we want your help, we might
expressly ask for it or you should ask for a reviewer _first_ (and I
won't respond to you -- crickets may mean eventually but definitely
not now).  I can see now that you/your-factory has prioritized
priority=Blocker.  And now you/Eric requests my review on your PR...
sigh... so much to review, one more PR on top of who knows how many
that are still waiting...

On Fri, Oct 23, 2026 at 7:02 PM Mike Drob <md...@mdrob.com> wrote:
>
> I’ll add in a bit of personal perspective. Working on Solr used to be my
> full time job; I have since moved on to other (sometimes less green)
> pastures. I still keep an eye on the project because it interests me and I
> enjoy the people. But anything I filed as a feature or improvement back in
> 2022 was probably a wish list item to make my own job easier. Those might
> still be helpful if they generalize but they also might not. I never went
> back and said “this is no longer important” on that list.
>
> An analogy, I walk to school every day and asked the city to put in some
> flowers along the path. Then I graduate and move to a new place, and some
> city administrator sees my request after a while. They put in the flowers
> but I’m not there to enjoy them. Maybe I was the only one to walk that
> path, or maybe there are others who will appreciate them.
>
> Mike
>
> On Fri, Oct 23, 2026 at 3:37 PM David Smiley <ds...@apache.org> wrote:
>
> > Hello Nick!
> >
> > Thanks for contributing to the discussion here.
> >
> > If you (Nick) were doing work on matters of specific interest to you,
> > then I wouldn't advise you much on selecting such work since they
> > matter to you enough to bother producing a solution.  And one person's
> > actual focus can only be so much.  But that's not the case here;
> > you've built a software factory that could work on anything with
> > boundless focuss.  I want to flip this around so that *committers*
> > (not your factory!) choose what to really start work on!  Committers
> > (or any human I guess) should first confirm that we want solutions for
> > certain JIRA issues.  Otherwise (current state), your choices have
> > dominated our review time, even when you don't know what the
> > committers collectively consider to be important (i.e. by at least one
> > of us, *wanting* a solution to a specific issue to review).  Any PRs
> > aren't going to even get a review.  **Basically, I want your factory
> > to solicit a reviewer on a specific issue before starting work.**
> > That's the ask.  Not merely whether someone cares, but who will
> > review?  The next step might be a PR but I hope in many cases would be
> > a *plan* (comment on a JIRA issue) of work that could first be
> > negotiated.  For example if there's an alleged bug, maybe the first
> > step is simply a reproduction attempt to validate it, or a code
> > reading assessment of the bug as a substitute (if not easily
> > reproduced).
> >
> > The JIRA issue "priority" hasn't been populated with selection
> > criteria or consequence for the choice, so it's often the default
> > value of "Major".  Often it's chosen by a contributor, not a
> > committer.  We mostly ignore it TBH.  I can sympathize your factory
> > needs *something* to use as a backlock prioritizer, and might as well
> > pick this.  I just want to highlight how inadequate it is at the
> > moment.  I may bump up the priortity of some JIRA issues to "Critical"
> > despite that word sounding rather alarmist/excessive for some work.
> > I don't think "newdev" should be a backlog prioritization factor.
> >
> > Take care to see when there's existing work on an issue (PR or
> > attached patch) or if it's "Assigned" to someone.  Avoid those.
> >
> > ~ David
> >
> > On Fri, Oct 23, 2026 at 12:15 PM Nick Boss <ni...@gmail.com> wrote:
> > >
> > > Hello, Solr!
> > > Nick here, I had a great chat with Eric and I am excited to be here. I
> > know
> > > I opened many PRs and I look forward to being part of the community while
> > > following community norms.
> > >
> > > There has never been a better time to be a contributor; I have a lot to
> > > share.
> > > Big thanks to David Smiley for all the backports.
> > > This email is my attempt at the follow-through this thread asks for.
> > >
> > > TL/DR: I will clear out blocker and critical items first. A list of 10
> > easy
> > > PRs and 10 Blocker/Critical PRs is at the bottom.
> > >
> > > 1. How the work is done
> > > - I work through the backlog with AI assistance, and every PR description
> > > says so.
> > > - Nothing goes out under my name that I have not read first.
> > > - I direct the work and I stand behind it; the commits carry my name
> > > because they are mine to answer for.
> > > - Results: 90 open PRs, 12 that have merged.
> > > - I answer review comments the day they arrive.
> > > - I reply with my human voice when I can.
> > >
> > > 2. Taking the criticism
> > > - The criticism I take from this thread is about closure, not effort,
> > and I
> > > think that is fair.
> > > - A PR that sits open is not finished work, however fast its author
> > replies.
> > > - Spread out is a fair description of the queue. It is not a fair
> > > description of any single PR in it.
> > > - Software factories are not built in a day and quality beats volume.
> > >
> > > 3. What follow-through means from my side
> > > - Every comment gets an answer.
> > > - I check if a change is even worth it first. I check if code could be
> > > removed rather than added. I slow down to try to understand more.
> > > - If a PR of mine goes quiet because the next step is mine, that is on
> > me.
> > > - I will talk about my PRs on the mailing list.
> > >
> > > 4. The two-sided part
> > > - Closure takes two people. A PR can be ready, answered, and green, and
> > it
> > > still closes only when a reviewer picks it up.
> > >
> > > 5. The priority commitment
> > > - My order from here is Blockers and Criticals first, then "new
> > developer".
> > > I also check PRs from others.
> > > - Open Blocker tickets will get PRs or JIRA notes this week.
> > >
> > > 6. Drafts
> > > - I will stop parking finished work as drafts.
> > > - Drafts from me will mean genuinely unfinished, and there will be few of
> > > them.
> > >
> > > 7. What I am not asking
> > > - For the cap to be lifted for me.
> > > - For anyone to believe I am a human.
> > >
> > > In closing,
> > > - Tell me where this is wrong. I am teachable.
> > > - Thank you to the people who have been merging this work, including this
> > > week.
> > >
> > >
> > > 10 Blocker/Critical PRs:
> > > - #5181 https://github.com/apache/solr/pull/5181 · SOLR-18552 · Blocker
> > ·
> > > 9.x launcher passes the MMapDirectory arena permits
> > > - #5199 https://github.com/apache/solr/pull/5199 · SOLR-14200 ·
> > Critical ·
> > > streaming fails clearly instead of an NPE on a missing shards-map entry
> > > - #5200 https://github.com/apache/solr/pull/5200 · SOLR-16155 ·
> > Critical ·
> > > field values out of indexing error messages
> > > - #5003 https://github.com/apache/solr/pull/5003 · SOLR-7394 · Critical
> > ·
> > > clear the recovering shard-terms entry when recovery is abandoned
> > > - #5139 https://github.com/apache/solr/pull/5139 · SOLR-7550 · Critical
> > · a
> > > 500 for the versions request counts as success when cantReachIsSuccess is
> > > set, same as a 503
> > > - #5093 https://github.com/apache/solr/pull/5093 · SOLR-16655 ·
> > Critical ·
> > > indexing nested documents and update processors
> > > - #5118 https://github.com/apache/solr/pull/5118 · SOLR-18010 ·
> > Critical ·
> > > security.json replacement through a synced temp file
> > > - #5203 https://github.com/apache/solr/pull/5203 · SOLR-17844 · Blocker
> > ·
> > > sort-assertion test repair
> > > - #5202 https://github.com/apache/solr/pull/5202 · SOLR-18446 · Blocker
> > ·
> > > collection routing follows the path, not the parameter
> > > - #5117 https://github.com/apache/solr/pull/5117 · SOLR-18541 · Major ·
> > > distributed search returns wrong totals, silently
> > >
> > >
> > > 10 Easy-to-review PRs:
> > > - #5116 https://github.com/apache/solr/pull/5116 · SOLR-18540 · gradlew
> > > under Git Bash · 13 lines
> > > - #5098 https://github.com/apache/solr/pull/5098 · SOLR-18530 · route
> > adds
> > > after the proxy cut in recovery · 20
> > > - #5002 https://github.com/apache/solr/pull/5002 · SOLR-11431 · a core
> > that
> > > fails to load returns 503, not 500 · 23
> > > - #5090 https://github.com/apache/solr/pull/5090 · SOLR-14262 · skipped
> > > commit and the update log · 34
> > > - #5094 https://github.com/apache/solr/pull/5094 · SOLR-16673 · numeric
> > > field update processors · 34
> > > - #5104 https://github.com/apache/solr/pull/5104 · SOLR-2681 · original
> > > highlighter term extraction · 35
> > > - #5086 https://github.com/apache/solr/pull/5086 · SOLR-12864 · test
> > > coverage for echo with mapUniqueKeyOnly · 37
> > > - #5131 https://github.com/apache/solr/pull/5131 · SOLR-5394 · default
> > > per-field thread count · 37
> > > - #5158 https://github.com/apache/solr/pull/5158 · SOLR-10305 ·
> > distributed
> > > request on a schema with no unique key · 42
> > > - #5105 https://github.com/apache/solr/pull/5105 · SOLR-4540 ·
> > > FastVectorHighlighter per-field work · 43
> > >
> > > On Thu, Oct 22, 2026 at 4:26 PM David Smiley <ds...@apache.org> wrote:
> > >
> > > > So well written AB; exactly.  My attempt:  FOLLOW-THROUGH (closure ==
> > > > success) is valued over a great quantity of first-drafts.  Same energy
> > > > level is appreciated, just focused instead of spread out.
> > > >
> > > > On Sun, Oct 18, 2026 at 9:35 AM Andrzej Białecki <ab...@getopt.org>
> > wrote:
> > > > >
> > > > > Eric wrote:
> > > > >
> > > > > > 1) We could limit the number of PR's opened, but to me, it just
> > seems
> > > > like we are gating potential new contributions (and anyway we close
> > PR's if
> > > > they don't get activity after a period of time anyway).
> > > > > >
> > > > >
> > > > > I don’t see this as gating in the sense of discouraging new
> > contributors
> > > > - quite the opposite, I see this as a quality and closure gate. If all
> > you
> > > > can open is 7 PRs you will think twice before opening the 7th one, and
> > you
> > > > will be more invested in helping close the first 6. Current situation
> > where
> > > > anyone can open 50 PRs and then follow up with rote AI responses is
> > > > untenable.
> > > > >
> > > > > Cheers,
> > > > > Andrzej
> > > > >
> > > > > > On 16 Oct 2026, at 16:16, Eric Pugh <ep...@apache.org> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> > > > > >> I'm not sure I agree with the bullish assessment on all fronts
> > haha,
> > > > > >> but I love the call to action! Both as individuals and as a group
> > we
> > > > > >> can be doing more to help out contributors.
> > > > > >>
> > > > > >> As an aside - I haven't played around with the Github Copilot
> > stuff
> > > > > >> you mentioned.  (Largely because I've been pretty happy with
> > Claude).
> > > > > >> Maybe I'm alone in being a late adopter there, but if I'm not then
> > > > > >> maybe that'd make a good demo for our community meetup?  Show
> > other
> > > > > >> committers something that you've seemingly found revolutionary in
> > your
> > > > > >> review workflow.
> > > > > >>
> > > > > >>> Eric cleverly convinced me I wasn't doing enough
> > > > > >>
> > > > > >> Never listen to Eric :-p
> > > > > >>
> > > > > >> Jason
> > > > > >>
> > > > > >> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> > > > > >> <ar...@gmail.com> wrote:
> > > > > >>>
> > > > > >>> Maybe we can get a dedicated open source code review bot and
> > tweak
> > > > it’s code for us. That should instill more confidence :)
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
> > > > wrote:
> > > > > >>>>
> > > > > >>>> It's never been an easier time as a committer to be the
> > > > shepherd/reviewer
> > > > > >>>> to a non-committer PR.  We have automated code reviews via
> > GitHub
> > > > co-pilot
> > > > > >>>> (need to add as a reviewer to engage).  No longer do we have to
> > > > edit a
> > > > > >>>> massive CHANGES.txt to pick a version that might be wrong or
> > even
> > > > know the
> > > > > >>>> version.  No longer do we have the chore of back-porting, for
> > the
> > > > vast
> > > > > >>>> majority of PRs.  Just pick a final destination Milestone on
> > the PR
> > > > and
> > > > > >>>> please DM me a "thank you" if you appreciate this.  An LLM armed
> > > > with a
> > > > > >>>> script is usually going to do this more thoroughly than you
> > would
> > > > have
> > > > > >>>> (i.e. it actually considers multiple CI jobs and usually runs
> > tests
> > > > before
> > > > > >>>> push).  And recently, I'll manually "resolve" the JIRA issue as
> > > > well as the
> > > > > >>>> final step (if it looks like a one-shot PR issue) -- Eric
> > cleverly
> > > > > >>>> convinced me I wasn't doing enough, so I've got this ;-).  It's
> > > > really
> > > > > >>>> rather satisfying.
> > > > > >>>>
> > > > > >>>> So with that said, I want to ask the committers here that don't
> > > > review
> > > > > >>>> other people's PRs to please do so, especially those of
> > > > contributors.  You
> > > > > >>>> have powers they don't -- you can get something merged.  The
> > > > contributor
> > > > > >>>> will be grateful; remember being in their shoes.  You can fully
> > > > handle a PR
> > > > > >>>> responsiby without leaving the GitHub PR issue screen -- at
> > least
> > > > most of
> > > > > >>>> the time.
> > > > > >>>>
> > > > > >>>> p.s. I'm also grateful for Crave.io for very fast builds... but
> > > > we'll need
> > > > > >>>> to do without this by the end of the year :-(
> > > > > >>>>
> > > > > >>>> ~ David Smiley
> > > > > >>>> Apache Lucene/Solr Search Developer
> > > > > >>>> http://www.linkedin.com/in/davidwsmiley
> > > > > >>>
> > > > > >>>
> > ---------------------------------------------------------------------
> > > > > >>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > >>> For additional commands, e-mail: dev-help@solr.apache.org
> > > > > >>>
> > > > > >>
> > > > > >>
> > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > >> For additional commands, e-mail: dev-help@solr.apache.org
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > A big topic at Community/Code this past week across all the
> > projects
> > > > (not just ours) was the benefits and perils of AI assisted coding.
> >  During
> > > > the past few months we've seen some very prolific new contributors
> > (thanks
> > > > Serhiy!) start contributing to Solr.   The fresh energy has really
> > > > increased our project development.   Then we've had Nick join the
> > party,
> > > > and he has gone through our JIRA backlog and cranked out quite a few
> > PR's
> > > > that deal with long dormant tickets.
> > > > > >
> > > > > > I wanted to start a thread and share some thoughts with the dev@
> > list.
> > > > > >
> > > > > > There are a couple of approaches we could take to these new
> > > > contributions.
> > > > > >
> > > > > > 1) We could limit the number of PR's opened, but to me, it just
> > seems
> > > > like we are gating potential new contributions (and anyway we close
> > PR's if
> > > > they don't get activity after a period of time anyway).
> > > > > >
> > > > > > 2) We probably *should* go back through our JIRA and close issues
> > that
> > > > are no longer relevant to the project so that new contributors don't
> > get
> > > > mislead.  Today I would consider any JIRA issue open for Solr as a
> > valid
> > > > one to be worked, but maybe that isnt' the case.
> > > > > >
> > > > > > 3) We could establish strong prioritization for what PR's need
> > > > review.  For example, when I look at what Nick has provided, maybe we
> > want
> > > > to focus first on bugs before we focus on feature oriented PR's?
> > > > > >
> > > > > > 4) We could lean more heavily into AI for evaluating PRs so we can
> > get
> > > > through them easier?  I know I struggle with PR's that I want to
> > review,
> > > > but aren't in an area that I have deep expertise in.  Unforutantly, too
> > > > many of those PRs then just wither on the vine.
> > > > > >
> > > > > > 5) We can try and activate more committers and contributors to be
> > > > reviwers.  I'm referencing David's email: "What a time to be a
> > committer in
> > > > 2026".
> > > > https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
> > > > > >
> > > > > > I don't know what the right path forward is, though I suspect it
> > all
> > > > requires us to grow the set of people reviewing PR's.   Any approach we
> > > > take hits up against the fundamental limit of us having only so many
> > folks
> > > > actively working PR's and merging them.
> > > > > >
> > > > > > Beyond that, I wanted to start thinking about who to tag for review
> > > > beyond the immediate suspects that Github recommends.  My thought was
> > "Who
> > > > are the specialists in various areas" that maybe aren't super active,
> > but
> > > > would be happy to engage on a PR.
> > > > > >
> > > > > > So I put together this analysis:
> > > >
> > https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> > > > > >
> > > > > > I'd love feedback on it, I suspect it will go through some
> > iterations
> > > > to be accurate.
> > > > > >
> > > > > > Secondly, I wanted to get my arms around the contributions from
> > Nick,
> > > > as there are 30 of them which makes it tough to figure out where to
> > start.
> > > >  I went ahead and leaned into my current "Pacific Rim" movie
> > fascination,
> > > > and did an analysis of them.   I tried to seperate out the pure bug fix
> > > > from the feature fixes, and get a quick sense of the complexity of
> > going
> > > > through them.
> > > > > >
> > > > > >
> > > >
> > https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org

Re: What a time to be a committer in 2026

[Mike Drob <md...@mdrob.com>]

I’ll add in a bit of personal perspective. Working on Solr used to be my
full time job; I have since moved on to other (sometimes less green)
pastures. I still keep an eye on the project because it interests me and I
enjoy the people. But anything I filed as a feature or improvement back in
2022 was probably a wish list item to make my own job easier. Those might
still be helpful if they generalize but they also might not. I never went
back and said “this is no longer important” on that list.

An analogy, I walk to school every day and asked the city to put in some
flowers along the path. Then I graduate and move to a new place, and some
city administrator sees my request after a while. They put in the flowers
but I’m not there to enjoy them. Maybe I was the only one to walk that
path, or maybe there are others who will appreciate them.

Mike

On Fri, Oct 23, 2026 at 3:37 PM David Smiley <ds...@apache.org> wrote:

> Hello Nick!
>
> Thanks for contributing to the discussion here.
>
> If you (Nick) were doing work on matters of specific interest to you,
> then I wouldn't advise you much on selecting such work since they
> matter to you enough to bother producing a solution.  And one person's
> actual focus can only be so much.  But that's not the case here;
> you've built a software factory that could work on anything with
> boundless focuss.  I want to flip this around so that *committers*
> (not your factory!) choose what to really start work on!  Committers
> (or any human I guess) should first confirm that we want solutions for
> certain JIRA issues.  Otherwise (current state), your choices have
> dominated our review time, even when you don't know what the
> committers collectively consider to be important (i.e. by at least one
> of us, *wanting* a solution to a specific issue to review).  Any PRs
> aren't going to even get a review.  **Basically, I want your factory
> to solicit a reviewer on a specific issue before starting work.**
> That's the ask.  Not merely whether someone cares, but who will
> review?  The next step might be a PR but I hope in many cases would be
> a *plan* (comment on a JIRA issue) of work that could first be
> negotiated.  For example if there's an alleged bug, maybe the first
> step is simply a reproduction attempt to validate it, or a code
> reading assessment of the bug as a substitute (if not easily
> reproduced).
>
> The JIRA issue "priority" hasn't been populated with selection
> criteria or consequence for the choice, so it's often the default
> value of "Major".  Often it's chosen by a contributor, not a
> committer.  We mostly ignore it TBH.  I can sympathize your factory
> needs *something* to use as a backlock prioritizer, and might as well
> pick this.  I just want to highlight how inadequate it is at the
> moment.  I may bump up the priortity of some JIRA issues to "Critical"
> despite that word sounding rather alarmist/excessive for some work.
> I don't think "newdev" should be a backlog prioritization factor.
>
> Take care to see when there's existing work on an issue (PR or
> attached patch) or if it's "Assigned" to someone.  Avoid those.
>
> ~ David
>
> On Fri, Oct 23, 2026 at 12:15 PM Nick Boss <ni...@gmail.com> wrote:
> >
> > Hello, Solr!
> > Nick here, I had a great chat with Eric and I am excited to be here. I
> know
> > I opened many PRs and I look forward to being part of the community while
> > following community norms.
> >
> > There has never been a better time to be a contributor; I have a lot to
> > share.
> > Big thanks to David Smiley for all the backports.
> > This email is my attempt at the follow-through this thread asks for.
> >
> > TL/DR: I will clear out blocker and critical items first. A list of 10
> easy
> > PRs and 10 Blocker/Critical PRs is at the bottom.
> >
> > 1. How the work is done
> > - I work through the backlog with AI assistance, and every PR description
> > says so.
> > - Nothing goes out under my name that I have not read first.
> > - I direct the work and I stand behind it; the commits carry my name
> > because they are mine to answer for.
> > - Results: 90 open PRs, 12 that have merged.
> > - I answer review comments the day they arrive.
> > - I reply with my human voice when I can.
> >
> > 2. Taking the criticism
> > - The criticism I take from this thread is about closure, not effort,
> and I
> > think that is fair.
> > - A PR that sits open is not finished work, however fast its author
> replies.
> > - Spread out is a fair description of the queue. It is not a fair
> > description of any single PR in it.
> > - Software factories are not built in a day and quality beats volume.
> >
> > 3. What follow-through means from my side
> > - Every comment gets an answer.
> > - I check if a change is even worth it first. I check if code could be
> > removed rather than added. I slow down to try to understand more.
> > - If a PR of mine goes quiet because the next step is mine, that is on
> me.
> > - I will talk about my PRs on the mailing list.
> >
> > 4. The two-sided part
> > - Closure takes two people. A PR can be ready, answered, and green, and
> it
> > still closes only when a reviewer picks it up.
> >
> > 5. The priority commitment
> > - My order from here is Blockers and Criticals first, then "new
> developer".
> > I also check PRs from others.
> > - Open Blocker tickets will get PRs or JIRA notes this week.
> >
> > 6. Drafts
> > - I will stop parking finished work as drafts.
> > - Drafts from me will mean genuinely unfinished, and there will be few of
> > them.
> >
> > 7. What I am not asking
> > - For the cap to be lifted for me.
> > - For anyone to believe I am a human.
> >
> > In closing,
> > - Tell me where this is wrong. I am teachable.
> > - Thank you to the people who have been merging this work, including this
> > week.
> >
> >
> > 10 Blocker/Critical PRs:
> > - #5181 https://github.com/apache/solr/pull/5181 · SOLR-18552 · Blocker
> ·
> > 9.x launcher passes the MMapDirectory arena permits
> > - #5199 https://github.com/apache/solr/pull/5199 · SOLR-14200 ·
> Critical ·
> > streaming fails clearly instead of an NPE on a missing shards-map entry
> > - #5200 https://github.com/apache/solr/pull/5200 · SOLR-16155 ·
> Critical ·
> > field values out of indexing error messages
> > - #5003 https://github.com/apache/solr/pull/5003 · SOLR-7394 · Critical
> ·
> > clear the recovering shard-terms entry when recovery is abandoned
> > - #5139 https://github.com/apache/solr/pull/5139 · SOLR-7550 · Critical
> · a
> > 500 for the versions request counts as success when cantReachIsSuccess is
> > set, same as a 503
> > - #5093 https://github.com/apache/solr/pull/5093 · SOLR-16655 ·
> Critical ·
> > indexing nested documents and update processors
> > - #5118 https://github.com/apache/solr/pull/5118 · SOLR-18010 ·
> Critical ·
> > security.json replacement through a synced temp file
> > - #5203 https://github.com/apache/solr/pull/5203 · SOLR-17844 · Blocker
> ·
> > sort-assertion test repair
> > - #5202 https://github.com/apache/solr/pull/5202 · SOLR-18446 · Blocker
> ·
> > collection routing follows the path, not the parameter
> > - #5117 https://github.com/apache/solr/pull/5117 · SOLR-18541 · Major ·
> > distributed search returns wrong totals, silently
> >
> >
> > 10 Easy-to-review PRs:
> > - #5116 https://github.com/apache/solr/pull/5116 · SOLR-18540 · gradlew
> > under Git Bash · 13 lines
> > - #5098 https://github.com/apache/solr/pull/5098 · SOLR-18530 · route
> adds
> > after the proxy cut in recovery · 20
> > - #5002 https://github.com/apache/solr/pull/5002 · SOLR-11431 · a core
> that
> > fails to load returns 503, not 500 · 23
> > - #5090 https://github.com/apache/solr/pull/5090 · SOLR-14262 · skipped
> > commit and the update log · 34
> > - #5094 https://github.com/apache/solr/pull/5094 · SOLR-16673 · numeric
> > field update processors · 34
> > - #5104 https://github.com/apache/solr/pull/5104 · SOLR-2681 · original
> > highlighter term extraction · 35
> > - #5086 https://github.com/apache/solr/pull/5086 · SOLR-12864 · test
> > coverage for echo with mapUniqueKeyOnly · 37
> > - #5131 https://github.com/apache/solr/pull/5131 · SOLR-5394 · default
> > per-field thread count · 37
> > - #5158 https://github.com/apache/solr/pull/5158 · SOLR-10305 ·
> distributed
> > request on a schema with no unique key · 42
> > - #5105 https://github.com/apache/solr/pull/5105 · SOLR-4540 ·
> > FastVectorHighlighter per-field work · 43
> >
> > On Thu, Oct 22, 2026 at 4:26 PM David Smiley <ds...@apache.org> wrote:
> >
> > > So well written AB; exactly.  My attempt:  FOLLOW-THROUGH (closure ==
> > > success) is valued over a great quantity of first-drafts.  Same energy
> > > level is appreciated, just focused instead of spread out.
> > >
> > > On Sun, Oct 18, 2026 at 9:35 AM Andrzej Białecki <ab...@getopt.org>
> wrote:
> > > >
> > > > Eric wrote:
> > > >
> > > > > 1) We could limit the number of PR's opened, but to me, it just
> seems
> > > like we are gating potential new contributions (and anyway we close
> PR's if
> > > they don't get activity after a period of time anyway).
> > > > >
> > > >
> > > > I don’t see this as gating in the sense of discouraging new
> contributors
> > > - quite the opposite, I see this as a quality and closure gate. If all
> you
> > > can open is 7 PRs you will think twice before opening the 7th one, and
> you
> > > will be more invested in helping close the first 6. Current situation
> where
> > > anyone can open 50 PRs and then follow up with rote AI responses is
> > > untenable.
> > > >
> > > > Cheers,
> > > > Andrzej
> > > >
> > > > > On 16 Oct 2026, at 16:16, Eric Pugh <ep...@apache.org> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> > > > >> I'm not sure I agree with the bullish assessment on all fronts
> haha,
> > > > >> but I love the call to action! Both as individuals and as a group
> we
> > > > >> can be doing more to help out contributors.
> > > > >>
> > > > >> As an aside - I haven't played around with the Github Copilot
> stuff
> > > > >> you mentioned.  (Largely because I've been pretty happy with
> Claude).
> > > > >> Maybe I'm alone in being a late adopter there, but if I'm not then
> > > > >> maybe that'd make a good demo for our community meetup?  Show
> other
> > > > >> committers something that you've seemingly found revolutionary in
> your
> > > > >> review workflow.
> > > > >>
> > > > >>> Eric cleverly convinced me I wasn't doing enough
> > > > >>
> > > > >> Never listen to Eric :-p
> > > > >>
> > > > >> Jason
> > > > >>
> > > > >> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> > > > >> <ar...@gmail.com> wrote:
> > > > >>>
> > > > >>> Maybe we can get a dedicated open source code review bot and
> tweak
> > > it’s code for us. That should instill more confidence :)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
> > > wrote:
> > > > >>>>
> > > > >>>> It's never been an easier time as a committer to be the
> > > shepherd/reviewer
> > > > >>>> to a non-committer PR.  We have automated code reviews via
> GitHub
> > > co-pilot
> > > > >>>> (need to add as a reviewer to engage).  No longer do we have to
> > > edit a
> > > > >>>> massive CHANGES.txt to pick a version that might be wrong or
> even
> > > know the
> > > > >>>> version.  No longer do we have the chore of back-porting, for
> the
> > > vast
> > > > >>>> majority of PRs.  Just pick a final destination Milestone on
> the PR
> > > and
> > > > >>>> please DM me a "thank you" if you appreciate this.  An LLM armed
> > > with a
> > > > >>>> script is usually going to do this more thoroughly than you
> would
> > > have
> > > > >>>> (i.e. it actually considers multiple CI jobs and usually runs
> tests
> > > before
> > > > >>>> push).  And recently, I'll manually "resolve" the JIRA issue as
> > > well as the
> > > > >>>> final step (if it looks like a one-shot PR issue) -- Eric
> cleverly
> > > > >>>> convinced me I wasn't doing enough, so I've got this ;-).  It's
> > > really
> > > > >>>> rather satisfying.
> > > > >>>>
> > > > >>>> So with that said, I want to ask the committers here that don't
> > > review
> > > > >>>> other people's PRs to please do so, especially those of
> > > contributors.  You
> > > > >>>> have powers they don't -- you can get something merged.  The
> > > contributor
> > > > >>>> will be grateful; remember being in their shoes.  You can fully
> > > handle a PR
> > > > >>>> responsiby without leaving the GitHub PR issue screen -- at
> least
> > > most of
> > > > >>>> the time.
> > > > >>>>
> > > > >>>> p.s. I'm also grateful for Crave.io for very fast builds... but
> > > we'll need
> > > > >>>> to do without this by the end of the year :-(
> > > > >>>>
> > > > >>>> ~ David Smiley
> > > > >>>> Apache Lucene/Solr Search Developer
> > > > >>>> http://www.linkedin.com/in/davidwsmiley
> > > > >>>
> > > > >>>
> ---------------------------------------------------------------------
> > > > >>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > >>> For additional commands, e-mail: dev-help@solr.apache.org
> > > > >>>
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > >> For additional commands, e-mail: dev-help@solr.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > > A big topic at Community/Code this past week across all the
> projects
> > > (not just ours) was the benefits and perils of AI assisted coding.
>  During
> > > the past few months we've seen some very prolific new contributors
> (thanks
> > > Serhiy!) start contributing to Solr.   The fresh energy has really
> > > increased our project development.   Then we've had Nick join the
> party,
> > > and he has gone through our JIRA backlog and cranked out quite a few
> PR's
> > > that deal with long dormant tickets.
> > > > >
> > > > > I wanted to start a thread and share some thoughts with the dev@
> list.
> > > > >
> > > > > There are a couple of approaches we could take to these new
> > > contributions.
> > > > >
> > > > > 1) We could limit the number of PR's opened, but to me, it just
> seems
> > > like we are gating potential new contributions (and anyway we close
> PR's if
> > > they don't get activity after a period of time anyway).
> > > > >
> > > > > 2) We probably *should* go back through our JIRA and close issues
> that
> > > are no longer relevant to the project so that new contributors don't
> get
> > > mislead.  Today I would consider any JIRA issue open for Solr as a
> valid
> > > one to be worked, but maybe that isnt' the case.
> > > > >
> > > > > 3) We could establish strong prioritization for what PR's need
> > > review.  For example, when I look at what Nick has provided, maybe we
> want
> > > to focus first on bugs before we focus on feature oriented PR's?
> > > > >
> > > > > 4) We could lean more heavily into AI for evaluating PRs so we can
> get
> > > through them easier?  I know I struggle with PR's that I want to
> review,
> > > but aren't in an area that I have deep expertise in.  Unforutantly, too
> > > many of those PRs then just wither on the vine.
> > > > >
> > > > > 5) We can try and activate more committers and contributors to be
> > > reviwers.  I'm referencing David's email: "What a time to be a
> committer in
> > > 2026".
> > > https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
> > > > >
> > > > > I don't know what the right path forward is, though I suspect it
> all
> > > requires us to grow the set of people reviewing PR's.   Any approach we
> > > take hits up against the fundamental limit of us having only so many
> folks
> > > actively working PR's and merging them.
> > > > >
> > > > > Beyond that, I wanted to start thinking about who to tag for review
> > > beyond the immediate suspects that Github recommends.  My thought was
> "Who
> > > are the specialists in various areas" that maybe aren't super active,
> but
> > > would be happy to engage on a PR.
> > > > >
> > > > > So I put together this analysis:
> > >
> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> > > > >
> > > > > I'd love feedback on it, I suspect it will go through some
> iterations
> > > to be accurate.
> > > > >
> > > > > Secondly, I wanted to get my arms around the contributions from
> Nick,
> > > as there are 30 of them which makes it tough to figure out where to
> start.
> > >  I went ahead and leaned into my current "Pacific Rim" movie
> fascination,
> > > and did an analysis of them.   I tried to seperate out the pure bug fix
> > > from the feature fixes, and get a quick sense of the complexity of
> going
> > > through them.
> > > > >
> > > > >
> > >
> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>

Re: What a time to be a committer in 2026

[David Smiley <ds...@apache.org>]

Hello Nick!

Thanks for contributing to the discussion here.

If you (Nick) were doing work on matters of specific interest to you,
then I wouldn't advise you much on selecting such work since they
matter to you enough to bother producing a solution.  And one person's
actual focus can only be so much.  But that's not the case here;
you've built a software factory that could work on anything with
boundless focuss.  I want to flip this around so that *committers*
(not your factory!) choose what to really start work on!  Committers
(or any human I guess) should first confirm that we want solutions for
certain JIRA issues.  Otherwise (current state), your choices have
dominated our review time, even when you don't know what the
committers collectively consider to be important (i.e. by at least one
of us, *wanting* a solution to a specific issue to review).  Any PRs
aren't going to even get a review.  **Basically, I want your factory
to solicit a reviewer on a specific issue before starting work.**
That's the ask.  Not merely whether someone cares, but who will
review?  The next step might be a PR but I hope in many cases would be
a *plan* (comment on a JIRA issue) of work that could first be
negotiated.  For example if there's an alleged bug, maybe the first
step is simply a reproduction attempt to validate it, or a code
reading assessment of the bug as a substitute (if not easily
reproduced).

The JIRA issue "priority" hasn't been populated with selection
criteria or consequence for the choice, so it's often the default
value of "Major".  Often it's chosen by a contributor, not a
committer.  We mostly ignore it TBH.  I can sympathize your factory
needs *something* to use as a backlock prioritizer, and might as well
pick this.  I just want to highlight how inadequate it is at the
moment.  I may bump up the priortity of some JIRA issues to "Critical"
despite that word sounding rather alarmist/excessive for some work.
I don't think "newdev" should be a backlog prioritization factor.

Take care to see when there's existing work on an issue (PR or
attached patch) or if it's "Assigned" to someone.  Avoid those.

~ David

On Fri, Oct 23, 2026 at 12:15 PM Nick Boss <ni...@gmail.com> wrote:
>
> Hello, Solr!
> Nick here, I had a great chat with Eric and I am excited to be here. I know
> I opened many PRs and I look forward to being part of the community while
> following community norms.
>
> There has never been a better time to be a contributor; I have a lot to
> share.
> Big thanks to David Smiley for all the backports.
> This email is my attempt at the follow-through this thread asks for.
>
> TL/DR: I will clear out blocker and critical items first. A list of 10 easy
> PRs and 10 Blocker/Critical PRs is at the bottom.
>
> 1. How the work is done
> - I work through the backlog with AI assistance, and every PR description
> says so.
> - Nothing goes out under my name that I have not read first.
> - I direct the work and I stand behind it; the commits carry my name
> because they are mine to answer for.
> - Results: 90 open PRs, 12 that have merged.
> - I answer review comments the day they arrive.
> - I reply with my human voice when I can.
>
> 2. Taking the criticism
> - The criticism I take from this thread is about closure, not effort, and I
> think that is fair.
> - A PR that sits open is not finished work, however fast its author replies.
> - Spread out is a fair description of the queue. It is not a fair
> description of any single PR in it.
> - Software factories are not built in a day and quality beats volume.
>
> 3. What follow-through means from my side
> - Every comment gets an answer.
> - I check if a change is even worth it first. I check if code could be
> removed rather than added. I slow down to try to understand more.
> - If a PR of mine goes quiet because the next step is mine, that is on me.
> - I will talk about my PRs on the mailing list.
>
> 4. The two-sided part
> - Closure takes two people. A PR can be ready, answered, and green, and it
> still closes only when a reviewer picks it up.
>
> 5. The priority commitment
> - My order from here is Blockers and Criticals first, then "new developer".
> I also check PRs from others.
> - Open Blocker tickets will get PRs or JIRA notes this week.
>
> 6. Drafts
> - I will stop parking finished work as drafts.
> - Drafts from me will mean genuinely unfinished, and there will be few of
> them.
>
> 7. What I am not asking
> - For the cap to be lifted for me.
> - For anyone to believe I am a human.
>
> In closing,
> - Tell me where this is wrong. I am teachable.
> - Thank you to the people who have been merging this work, including this
> week.
>
>
> 10 Blocker/Critical PRs:
> - #5181 https://github.com/apache/solr/pull/5181 · SOLR-18552 · Blocker ·
> 9.x launcher passes the MMapDirectory arena permits
> - #5199 https://github.com/apache/solr/pull/5199 · SOLR-14200 · Critical ·
> streaming fails clearly instead of an NPE on a missing shards-map entry
> - #5200 https://github.com/apache/solr/pull/5200 · SOLR-16155 · Critical ·
> field values out of indexing error messages
> - #5003 https://github.com/apache/solr/pull/5003 · SOLR-7394 · Critical ·
> clear the recovering shard-terms entry when recovery is abandoned
> - #5139 https://github.com/apache/solr/pull/5139 · SOLR-7550 · Critical · a
> 500 for the versions request counts as success when cantReachIsSuccess is
> set, same as a 503
> - #5093 https://github.com/apache/solr/pull/5093 · SOLR-16655 · Critical ·
> indexing nested documents and update processors
> - #5118 https://github.com/apache/solr/pull/5118 · SOLR-18010 · Critical ·
> security.json replacement through a synced temp file
> - #5203 https://github.com/apache/solr/pull/5203 · SOLR-17844 · Blocker ·
> sort-assertion test repair
> - #5202 https://github.com/apache/solr/pull/5202 · SOLR-18446 · Blocker ·
> collection routing follows the path, not the parameter
> - #5117 https://github.com/apache/solr/pull/5117 · SOLR-18541 · Major ·
> distributed search returns wrong totals, silently
>
>
> 10 Easy-to-review PRs:
> - #5116 https://github.com/apache/solr/pull/5116 · SOLR-18540 · gradlew
> under Git Bash · 13 lines
> - #5098 https://github.com/apache/solr/pull/5098 · SOLR-18530 · route adds
> after the proxy cut in recovery · 20
> - #5002 https://github.com/apache/solr/pull/5002 · SOLR-11431 · a core that
> fails to load returns 503, not 500 · 23
> - #5090 https://github.com/apache/solr/pull/5090 · SOLR-14262 · skipped
> commit and the update log · 34
> - #5094 https://github.com/apache/solr/pull/5094 · SOLR-16673 · numeric
> field update processors · 34
> - #5104 https://github.com/apache/solr/pull/5104 · SOLR-2681 · original
> highlighter term extraction · 35
> - #5086 https://github.com/apache/solr/pull/5086 · SOLR-12864 · test
> coverage for echo with mapUniqueKeyOnly · 37
> - #5131 https://github.com/apache/solr/pull/5131 · SOLR-5394 · default
> per-field thread count · 37
> - #5158 https://github.com/apache/solr/pull/5158 · SOLR-10305 · distributed
> request on a schema with no unique key · 42
> - #5105 https://github.com/apache/solr/pull/5105 · SOLR-4540 ·
> FastVectorHighlighter per-field work · 43
>
> On Thu, Oct 22, 2026 at 4:26 PM David Smiley <ds...@apache.org> wrote:
>
> > So well written AB; exactly.  My attempt:  FOLLOW-THROUGH (closure ==
> > success) is valued over a great quantity of first-drafts.  Same energy
> > level is appreciated, just focused instead of spread out.
> >
> > On Sun, Oct 18, 2026 at 9:35 AM Andrzej Białecki <ab...@getopt.org> wrote:
> > >
> > > Eric wrote:
> > >
> > > > 1) We could limit the number of PR's opened, but to me, it just seems
> > like we are gating potential new contributions (and anyway we close PR's if
> > they don't get activity after a period of time anyway).
> > > >
> > >
> > > I don’t see this as gating in the sense of discouraging new contributors
> > - quite the opposite, I see this as a quality and closure gate. If all you
> > can open is 7 PRs you will think twice before opening the 7th one, and you
> > will be more invested in helping close the first 6. Current situation where
> > anyone can open 50 PRs and then follow up with rote AI responses is
> > untenable.
> > >
> > > Cheers,
> > > Andrzej
> > >
> > > > On 16 Oct 2026, at 16:16, Eric Pugh <ep...@apache.org> wrote:
> > > >
> > > >
> > > >
> > > > On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> > > >> I'm not sure I agree with the bullish assessment on all fronts haha,
> > > >> but I love the call to action! Both as individuals and as a group we
> > > >> can be doing more to help out contributors.
> > > >>
> > > >> As an aside - I haven't played around with the Github Copilot stuff
> > > >> you mentioned.  (Largely because I've been pretty happy with Claude).
> > > >> Maybe I'm alone in being a late adopter there, but if I'm not then
> > > >> maybe that'd make a good demo for our community meetup?  Show other
> > > >> committers something that you've seemingly found revolutionary in your
> > > >> review workflow.
> > > >>
> > > >>> Eric cleverly convinced me I wasn't doing enough
> > > >>
> > > >> Never listen to Eric :-p
> > > >>
> > > >> Jason
> > > >>
> > > >> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> > > >> <ar...@gmail.com> wrote:
> > > >>>
> > > >>> Maybe we can get a dedicated open source code review bot and tweak
> > it’s code for us. That should instill more confidence :)
> > > >>>
> > > >>>
> > > >>>
> > > >>>> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
> > wrote:
> > > >>>>
> > > >>>> It's never been an easier time as a committer to be the
> > shepherd/reviewer
> > > >>>> to a non-committer PR.  We have automated code reviews via GitHub
> > co-pilot
> > > >>>> (need to add as a reviewer to engage).  No longer do we have to
> > edit a
> > > >>>> massive CHANGES.txt to pick a version that might be wrong or even
> > know the
> > > >>>> version.  No longer do we have the chore of back-porting, for the
> > vast
> > > >>>> majority of PRs.  Just pick a final destination Milestone on the PR
> > and
> > > >>>> please DM me a "thank you" if you appreciate this.  An LLM armed
> > with a
> > > >>>> script is usually going to do this more thoroughly than you would
> > have
> > > >>>> (i.e. it actually considers multiple CI jobs and usually runs tests
> > before
> > > >>>> push).  And recently, I'll manually "resolve" the JIRA issue as
> > well as the
> > > >>>> final step (if it looks like a one-shot PR issue) -- Eric cleverly
> > > >>>> convinced me I wasn't doing enough, so I've got this ;-).  It's
> > really
> > > >>>> rather satisfying.
> > > >>>>
> > > >>>> So with that said, I want to ask the committers here that don't
> > review
> > > >>>> other people's PRs to please do so, especially those of
> > contributors.  You
> > > >>>> have powers they don't -- you can get something merged.  The
> > contributor
> > > >>>> will be grateful; remember being in their shoes.  You can fully
> > handle a PR
> > > >>>> responsiby without leaving the GitHub PR issue screen -- at least
> > most of
> > > >>>> the time.
> > > >>>>
> > > >>>> p.s. I'm also grateful for Crave.io for very fast builds... but
> > we'll need
> > > >>>> to do without this by the end of the year :-(
> > > >>>>
> > > >>>> ~ David Smiley
> > > >>>> Apache Lucene/Solr Search Developer
> > > >>>> http://www.linkedin.com/in/davidwsmiley
> > > >>>
> > > >>> ---------------------------------------------------------------------
> > > >>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > >>> For additional commands, e-mail: dev-help@solr.apache.org
> > > >>>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > >> For additional commands, e-mail: dev-help@solr.apache.org
> > > >>
> > > >>
> > > >
> > > > A big topic at Community/Code this past week across all the projects
> > (not just ours) was the benefits and perils of AI assisted coding.   During
> > the past few months we've seen some very prolific new contributors (thanks
> > Serhiy!) start contributing to Solr.   The fresh energy has really
> > increased our project development.   Then we've had Nick join the party,
> > and he has gone through our JIRA backlog and cranked out quite a few PR's
> > that deal with long dormant tickets.
> > > >
> > > > I wanted to start a thread and share some thoughts with the dev@ list.
> > > >
> > > > There are a couple of approaches we could take to these new
> > contributions.
> > > >
> > > > 1) We could limit the number of PR's opened, but to me, it just seems
> > like we are gating potential new contributions (and anyway we close PR's if
> > they don't get activity after a period of time anyway).
> > > >
> > > > 2) We probably *should* go back through our JIRA and close issues that
> > are no longer relevant to the project so that new contributors don't get
> > mislead.  Today I would consider any JIRA issue open for Solr as a valid
> > one to be worked, but maybe that isnt' the case.
> > > >
> > > > 3) We could establish strong prioritization for what PR's need
> > review.  For example, when I look at what Nick has provided, maybe we want
> > to focus first on bugs before we focus on feature oriented PR's?
> > > >
> > > > 4) We could lean more heavily into AI for evaluating PRs so we can get
> > through them easier?  I know I struggle with PR's that I want to review,
> > but aren't in an area that I have deep expertise in.  Unforutantly, too
> > many of those PRs then just wither on the vine.
> > > >
> > > > 5) We can try and activate more committers and contributors to be
> > reviwers.  I'm referencing David's email: "What a time to be a committer in
> > 2026".
> > https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
> > > >
> > > > I don't know what the right path forward is, though I suspect it all
> > requires us to grow the set of people reviewing PR's.   Any approach we
> > take hits up against the fundamental limit of us having only so many folks
> > actively working PR's and merging them.
> > > >
> > > > Beyond that, I wanted to start thinking about who to tag for review
> > beyond the immediate suspects that Github recommends.  My thought was "Who
> > are the specialists in various areas" that maybe aren't super active, but
> > would be happy to engage on a PR.
> > > >
> > > > So I put together this analysis:
> > https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> > > >
> > > > I'd love feedback on it, I suspect it will go through some iterations
> > to be accurate.
> > > >
> > > > Secondly, I wanted to get my arms around the contributions from Nick,
> > as there are 30 of them which makes it tough to figure out where to start.
> >  I went ahead and leaned into my current "Pacific Rim" movie fascination,
> > and did an analysis of them.   I tried to seperate out the pure bug fix
> > from the feature fixes, and get a quick sense of the complexity of going
> > through them.
> > > >
> > > >
> > https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org

Re: What a time to be a committer in 2026

[Nick Boss <ni...@gmail.com>]

Hello, Solr!
Nick here, I had a great chat with Eric and I am excited to be here. I know
I opened many PRs and I look forward to being part of the community while
following community norms.

There has never been a better time to be a contributor; I have a lot to
share.
Big thanks to David Smiley for all the backports.
This email is my attempt at the follow-through this thread asks for.

TL/DR: I will clear out blocker and critical items first. A list of 10 easy
PRs and 10 Blocker/Critical PRs is at the bottom.

1. How the work is done
- I work through the backlog with AI assistance, and every PR description
says so.
- Nothing goes out under my name that I have not read first.
- I direct the work and I stand behind it; the commits carry my name
because they are mine to answer for.
- Results: 90 open PRs, 12 that have merged.
- I answer review comments the day they arrive.
- I reply with my human voice when I can.

2. Taking the criticism
- The criticism I take from this thread is about closure, not effort, and I
think that is fair.
- A PR that sits open is not finished work, however fast its author replies.
- Spread out is a fair description of the queue. It is not a fair
description of any single PR in it.
- Software factories are not built in a day and quality beats volume.

3. What follow-through means from my side
- Every comment gets an answer.
- I check if a change is even worth it first. I check if code could be
removed rather than added. I slow down to try to understand more.
- If a PR of mine goes quiet because the next step is mine, that is on me.
- I will talk about my PRs on the mailing list.

4. The two-sided part
- Closure takes two people. A PR can be ready, answered, and green, and it
still closes only when a reviewer picks it up.

5. The priority commitment
- My order from here is Blockers and Criticals first, then "new developer".
I also check PRs from others.
- Open Blocker tickets will get PRs or JIRA notes this week.

6. Drafts
- I will stop parking finished work as drafts.
- Drafts from me will mean genuinely unfinished, and there will be few of
them.

7. What I am not asking
- For the cap to be lifted for me.
- For anyone to believe I am a human.

In closing,
- Tell me where this is wrong. I am teachable.
- Thank you to the people who have been merging this work, including this
week.


10 Blocker/Critical PRs:
- #5181 https://github.com/apache/solr/pull/5181 · SOLR-18552 · Blocker ·
9.x launcher passes the MMapDirectory arena permits
- #5199 https://github.com/apache/solr/pull/5199 · SOLR-14200 · Critical ·
streaming fails clearly instead of an NPE on a missing shards-map entry
- #5200 https://github.com/apache/solr/pull/5200 · SOLR-16155 · Critical ·
field values out of indexing error messages
- #5003 https://github.com/apache/solr/pull/5003 · SOLR-7394 · Critical ·
clear the recovering shard-terms entry when recovery is abandoned
- #5139 https://github.com/apache/solr/pull/5139 · SOLR-7550 · Critical · a
500 for the versions request counts as success when cantReachIsSuccess is
set, same as a 503
- #5093 https://github.com/apache/solr/pull/5093 · SOLR-16655 · Critical ·
indexing nested documents and update processors
- #5118 https://github.com/apache/solr/pull/5118 · SOLR-18010 · Critical ·
security.json replacement through a synced temp file
- #5203 https://github.com/apache/solr/pull/5203 · SOLR-17844 · Blocker ·
sort-assertion test repair
- #5202 https://github.com/apache/solr/pull/5202 · SOLR-18446 · Blocker ·
collection routing follows the path, not the parameter
- #5117 https://github.com/apache/solr/pull/5117 · SOLR-18541 · Major ·
distributed search returns wrong totals, silently


10 Easy-to-review PRs:
- #5116 https://github.com/apache/solr/pull/5116 · SOLR-18540 · gradlew
under Git Bash · 13 lines
- #5098 https://github.com/apache/solr/pull/5098 · SOLR-18530 · route adds
after the proxy cut in recovery · 20
- #5002 https://github.com/apache/solr/pull/5002 · SOLR-11431 · a core that
fails to load returns 503, not 500 · 23
- #5090 https://github.com/apache/solr/pull/5090 · SOLR-14262 · skipped
commit and the update log · 34
- #5094 https://github.com/apache/solr/pull/5094 · SOLR-16673 · numeric
field update processors · 34
- #5104 https://github.com/apache/solr/pull/5104 · SOLR-2681 · original
highlighter term extraction · 35
- #5086 https://github.com/apache/solr/pull/5086 · SOLR-12864 · test
coverage for echo with mapUniqueKeyOnly · 37
- #5131 https://github.com/apache/solr/pull/5131 · SOLR-5394 · default
per-field thread count · 37
- #5158 https://github.com/apache/solr/pull/5158 · SOLR-10305 · distributed
request on a schema with no unique key · 42
- #5105 https://github.com/apache/solr/pull/5105 · SOLR-4540 ·
FastVectorHighlighter per-field work · 43

On Thu, Oct 22, 2026 at 4:26 PM David Smiley <ds...@apache.org> wrote:

> So well written AB; exactly.  My attempt:  FOLLOW-THROUGH (closure ==
> success) is valued over a great quantity of first-drafts.  Same energy
> level is appreciated, just focused instead of spread out.
>
> On Sun, Oct 18, 2026 at 9:35 AM Andrzej Białecki <ab...@getopt.org> wrote:
> >
> > Eric wrote:
> >
> > > 1) We could limit the number of PR's opened, but to me, it just seems
> like we are gating potential new contributions (and anyway we close PR's if
> they don't get activity after a period of time anyway).
> > >
> >
> > I don’t see this as gating in the sense of discouraging new contributors
> - quite the opposite, I see this as a quality and closure gate. If all you
> can open is 7 PRs you will think twice before opening the 7th one, and you
> will be more invested in helping close the first 6. Current situation where
> anyone can open 50 PRs and then follow up with rote AI responses is
> untenable.
> >
> > Cheers,
> > Andrzej
> >
> > > On 16 Oct 2026, at 16:16, Eric Pugh <ep...@apache.org> wrote:
> > >
> > >
> > >
> > > On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> > >> I'm not sure I agree with the bullish assessment on all fronts haha,
> > >> but I love the call to action! Both as individuals and as a group we
> > >> can be doing more to help out contributors.
> > >>
> > >> As an aside - I haven't played around with the Github Copilot stuff
> > >> you mentioned.  (Largely because I've been pretty happy with Claude).
> > >> Maybe I'm alone in being a late adopter there, but if I'm not then
> > >> maybe that'd make a good demo for our community meetup?  Show other
> > >> committers something that you've seemingly found revolutionary in your
> > >> review workflow.
> > >>
> > >>> Eric cleverly convinced me I wasn't doing enough
> > >>
> > >> Never listen to Eric :-p
> > >>
> > >> Jason
> > >>
> > >> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> > >> <ar...@gmail.com> wrote:
> > >>>
> > >>> Maybe we can get a dedicated open source code review bot and tweak
> it’s code for us. That should instill more confidence :)
> > >>>
> > >>>
> > >>>
> > >>>> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
> wrote:
> > >>>>
> > >>>> It's never been an easier time as a committer to be the
> shepherd/reviewer
> > >>>> to a non-committer PR.  We have automated code reviews via GitHub
> co-pilot
> > >>>> (need to add as a reviewer to engage).  No longer do we have to
> edit a
> > >>>> massive CHANGES.txt to pick a version that might be wrong or even
> know the
> > >>>> version.  No longer do we have the chore of back-porting, for the
> vast
> > >>>> majority of PRs.  Just pick a final destination Milestone on the PR
> and
> > >>>> please DM me a "thank you" if you appreciate this.  An LLM armed
> with a
> > >>>> script is usually going to do this more thoroughly than you would
> have
> > >>>> (i.e. it actually considers multiple CI jobs and usually runs tests
> before
> > >>>> push).  And recently, I'll manually "resolve" the JIRA issue as
> well as the
> > >>>> final step (if it looks like a one-shot PR issue) -- Eric cleverly
> > >>>> convinced me I wasn't doing enough, so I've got this ;-).  It's
> really
> > >>>> rather satisfying.
> > >>>>
> > >>>> So with that said, I want to ask the committers here that don't
> review
> > >>>> other people's PRs to please do so, especially those of
> contributors.  You
> > >>>> have powers they don't -- you can get something merged.  The
> contributor
> > >>>> will be grateful; remember being in their shoes.  You can fully
> handle a PR
> > >>>> responsiby without leaving the GitHub PR issue screen -- at least
> most of
> > >>>> the time.
> > >>>>
> > >>>> p.s. I'm also grateful for Crave.io for very fast builds... but
> we'll need
> > >>>> to do without this by the end of the year :-(
> > >>>>
> > >>>> ~ David Smiley
> > >>>> Apache Lucene/Solr Search Developer
> > >>>> http://www.linkedin.com/in/davidwsmiley
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > >>> For additional commands, e-mail: dev-help@solr.apache.org
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > >> For additional commands, e-mail: dev-help@solr.apache.org
> > >>
> > >>
> > >
> > > A big topic at Community/Code this past week across all the projects
> (not just ours) was the benefits and perils of AI assisted coding.   During
> the past few months we've seen some very prolific new contributors (thanks
> Serhiy!) start contributing to Solr.   The fresh energy has really
> increased our project development.   Then we've had Nick join the party,
> and he has gone through our JIRA backlog and cranked out quite a few PR's
> that deal with long dormant tickets.
> > >
> > > I wanted to start a thread and share some thoughts with the dev@ list.
> > >
> > > There are a couple of approaches we could take to these new
> contributions.
> > >
> > > 1) We could limit the number of PR's opened, but to me, it just seems
> like we are gating potential new contributions (and anyway we close PR's if
> they don't get activity after a period of time anyway).
> > >
> > > 2) We probably *should* go back through our JIRA and close issues that
> are no longer relevant to the project so that new contributors don't get
> mislead.  Today I would consider any JIRA issue open for Solr as a valid
> one to be worked, but maybe that isnt' the case.
> > >
> > > 3) We could establish strong prioritization for what PR's need
> review.  For example, when I look at what Nick has provided, maybe we want
> to focus first on bugs before we focus on feature oriented PR's?
> > >
> > > 4) We could lean more heavily into AI for evaluating PRs so we can get
> through them easier?  I know I struggle with PR's that I want to review,
> but aren't in an area that I have deep expertise in.  Unforutantly, too
> many of those PRs then just wither on the vine.
> > >
> > > 5) We can try and activate more committers and contributors to be
> reviwers.  I'm referencing David's email: "What a time to be a committer in
> 2026".
> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
> > >
> > > I don't know what the right path forward is, though I suspect it all
> requires us to grow the set of people reviewing PR's.   Any approach we
> take hits up against the fundamental limit of us having only so many folks
> actively working PR's and merging them.
> > >
> > > Beyond that, I wanted to start thinking about who to tag for review
> beyond the immediate suspects that Github recommends.  My thought was "Who
> are the specialists in various areas" that maybe aren't super active, but
> would be happy to engage on a PR.
> > >
> > > So I put together this analysis:
> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> > >
> > > I'd love feedback on it, I suspect it will go through some iterations
> to be accurate.
> > >
> > > Secondly, I wanted to get my arms around the contributions from Nick,
> as there are 30 of them which makes it tough to figure out where to start.
>  I went ahead and leaned into my current "Pacific Rim" movie fascination,
> and did an analysis of them.   I tried to seperate out the pure bug fix
> from the feature fixes, and get a quick sense of the complexity of going
> through them.
> > >
> > >
> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>

Re: What a time to be a committer in 2026

[David Smiley <ds...@apache.org>]

So well written AB; exactly.  My attempt:  FOLLOW-THROUGH (closure ==
success) is valued over a great quantity of first-drafts.  Same energy
level is appreciated, just focused instead of spread out.

On Sun, Oct 18, 2026 at 9:35 AM Andrzej Białecki <ab...@getopt.org> wrote:
>
> Eric wrote:
>
> > 1) We could limit the number of PR's opened, but to me, it just seems like we are gating potential new contributions (and anyway we close PR's if they don't get activity after a period of time anyway).
> >
>
> I don’t see this as gating in the sense of discouraging new contributors - quite the opposite, I see this as a quality and closure gate. If all you can open is 7 PRs you will think twice before opening the 7th one, and you will be more invested in helping close the first 6. Current situation where anyone can open 50 PRs and then follow up with rote AI responses is untenable.
>
> Cheers,
> Andrzej
>
> > On 16 Oct 2026, at 16:16, Eric Pugh <ep...@apache.org> wrote:
> >
> >
> >
> > On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> >> I'm not sure I agree with the bullish assessment on all fronts haha,
> >> but I love the call to action! Both as individuals and as a group we
> >> can be doing more to help out contributors.
> >>
> >> As an aside - I haven't played around with the Github Copilot stuff
> >> you mentioned.  (Largely because I've been pretty happy with Claude).
> >> Maybe I'm alone in being a late adopter there, but if I'm not then
> >> maybe that'd make a good demo for our community meetup?  Show other
> >> committers something that you've seemingly found revolutionary in your
> >> review workflow.
> >>
> >>> Eric cleverly convinced me I wasn't doing enough
> >>
> >> Never listen to Eric :-p
> >>
> >> Jason
> >>
> >> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> >> <ar...@gmail.com> wrote:
> >>>
> >>> Maybe we can get a dedicated open source code review bot and tweak it’s code for us. That should instill more confidence :)
> >>>
> >>>
> >>>
> >>>> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org> wrote:
> >>>>
> >>>> It's never been an easier time as a committer to be the shepherd/reviewer
> >>>> to a non-committer PR.  We have automated code reviews via GitHub co-pilot
> >>>> (need to add as a reviewer to engage).  No longer do we have to edit a
> >>>> massive CHANGES.txt to pick a version that might be wrong or even know the
> >>>> version.  No longer do we have the chore of back-porting, for the vast
> >>>> majority of PRs.  Just pick a final destination Milestone on the PR and
> >>>> please DM me a "thank you" if you appreciate this.  An LLM armed with a
> >>>> script is usually going to do this more thoroughly than you would have
> >>>> (i.e. it actually considers multiple CI jobs and usually runs tests before
> >>>> push).  And recently, I'll manually "resolve" the JIRA issue as well as the
> >>>> final step (if it looks like a one-shot PR issue) -- Eric cleverly
> >>>> convinced me I wasn't doing enough, so I've got this ;-).  It's really
> >>>> rather satisfying.
> >>>>
> >>>> So with that said, I want to ask the committers here that don't review
> >>>> other people's PRs to please do so, especially those of contributors.  You
> >>>> have powers they don't -- you can get something merged.  The contributor
> >>>> will be grateful; remember being in their shoes.  You can fully handle a PR
> >>>> responsiby without leaving the GitHub PR issue screen -- at least most of
> >>>> the time.
> >>>>
> >>>> p.s. I'm also grateful for Crave.io for very fast builds... but we'll need
> >>>> to do without this by the end of the year :-(
> >>>>
> >>>> ~ David Smiley
> >>>> Apache Lucene/Solr Search Developer
> >>>> http://www.linkedin.com/in/davidwsmiley
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
> >
> > A big topic at Community/Code this past week across all the projects (not just ours) was the benefits and perils of AI assisted coding.   During the past few months we've seen some very prolific new contributors (thanks Serhiy!) start contributing to Solr.   The fresh energy has really increased our project development.   Then we've had Nick join the party, and he has gone through our JIRA backlog and cranked out quite a few PR's that deal with long dormant tickets.
> >
> > I wanted to start a thread and share some thoughts with the dev@ list.
> >
> > There are a couple of approaches we could take to these new contributions.
> >
> > 1) We could limit the number of PR's opened, but to me, it just seems like we are gating potential new contributions (and anyway we close PR's if they don't get activity after a period of time anyway).
> >
> > 2) We probably *should* go back through our JIRA and close issues that are no longer relevant to the project so that new contributors don't get mislead.  Today I would consider any JIRA issue open for Solr as a valid one to be worked, but maybe that isnt' the case.
> >
> > 3) We could establish strong prioritization for what PR's need review.  For example, when I look at what Nick has provided, maybe we want to focus first on bugs before we focus on feature oriented PR's?
> >
> > 4) We could lean more heavily into AI for evaluating PRs so we can get through them easier?  I know I struggle with PR's that I want to review, but aren't in an area that I have deep expertise in.  Unforutantly, too many of those PRs then just wither on the vine.
> >
> > 5) We can try and activate more committers and contributors to be reviwers.  I'm referencing David's email: "What a time to be a committer in 2026".   https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
> >
> > I don't know what the right path forward is, though I suspect it all requires us to grow the set of people reviewing PR's.   Any approach we take hits up against the fundamental limit of us having only so many folks actively working PR's and merging them.
> >
> > Beyond that, I wanted to start thinking about who to tag for review beyond the immediate suspects that Github recommends.  My thought was "Who are the specialists in various areas" that maybe aren't super active, but would be happy to engage on a PR.
> >
> > So I put together this analysis: https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> >
> > I'd love feedback on it, I suspect it will go through some iterations to be accurate.
> >
> > Secondly, I wanted to get my arms around the contributions from Nick, as there are 30 of them which makes it tough to figure out where to start.   I went ahead and leaned into my current "Pacific Rim" movie fascination, and did an analysis of them.   I tried to seperate out the pure bug fix from the feature fixes, and get a quick sense of the complexity of going through them.
> >
> > https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org

Re: What a time to be a committer in 2026

[Andrzej Białecki <ab...@getopt.org>]

Eric wrote:

> 1) We could limit the number of PR's opened, but to me, it just seems like we are gating potential new contributions (and anyway we close PR's if they don't get activity after a period of time anyway).
> 

I don’t see this as gating in the sense of discouraging new contributors - quite the opposite, I see this as a quality and closure gate. If all you can open is 7 PRs you will think twice before opening the 7th one, and you will be more invested in helping close the first 6. Current situation where anyone can open 50 PRs and then follow up with rote AI responses is untenable.

Cheers,
Andrzej

> On 16 Oct 2026, at 16:16, Eric Pugh <ep...@apache.org> wrote:
> 
> 
> 
> On 2026/09/03 22:44:13 Jason Gerlowski wrote:
>> I'm not sure I agree with the bullish assessment on all fronts haha,
>> but I love the call to action! Both as individuals and as a group we
>> can be doing more to help out contributors.
>> 
>> As an aside - I haven't played around with the Github Copilot stuff
>> you mentioned.  (Largely because I've been pretty happy with Claude).
>> Maybe I'm alone in being a late adopter there, but if I'm not then
>> maybe that'd make a good demo for our community meetup?  Show other
>> committers something that you've seemingly found revolutionary in your
>> review workflow.
>> 
>>> Eric cleverly convinced me I wasn't doing enough
>> 
>> Never listen to Eric :-p
>> 
>> Jason
>> 
>> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
>> <ar...@gmail.com> wrote:
>>> 
>>> Maybe we can get a dedicated open source code review bot and tweak it’s code for us. That should instill more confidence :)
>>> 
>>> 
>>> 
>>>> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org> wrote:
>>>> 
>>>> It's never been an easier time as a committer to be the shepherd/reviewer
>>>> to a non-committer PR.  We have automated code reviews via GitHub co-pilot
>>>> (need to add as a reviewer to engage).  No longer do we have to edit a
>>>> massive CHANGES.txt to pick a version that might be wrong or even know the
>>>> version.  No longer do we have the chore of back-porting, for the vast
>>>> majority of PRs.  Just pick a final destination Milestone on the PR and
>>>> please DM me a "thank you" if you appreciate this.  An LLM armed with a
>>>> script is usually going to do this more thoroughly than you would have
>>>> (i.e. it actually considers multiple CI jobs and usually runs tests before
>>>> push).  And recently, I'll manually "resolve" the JIRA issue as well as the
>>>> final step (if it looks like a one-shot PR issue) -- Eric cleverly
>>>> convinced me I wasn't doing enough, so I've got this ;-).  It's really
>>>> rather satisfying.
>>>> 
>>>> So with that said, I want to ask the committers here that don't review
>>>> other people's PRs to please do so, especially those of contributors.  You
>>>> have powers they don't -- you can get something merged.  The contributor
>>>> will be grateful; remember being in their shoes.  You can fully handle a PR
>>>> responsiby without leaving the GitHub PR issue screen -- at least most of
>>>> the time.
>>>> 
>>>> p.s. I'm also grateful for Crave.io for very fast builds... but we'll need
>>>> to do without this by the end of the year :-(
>>>> 
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>> 
>> 
> 
> A big topic at Community/Code this past week across all the projects (not just ours) was the benefits and perils of AI assisted coding.   During the past few months we've seen some very prolific new contributors (thanks Serhiy!) start contributing to Solr.   The fresh energy has really increased our project development.   Then we've had Nick join the party, and he has gone through our JIRA backlog and cranked out quite a few PR's that deal with long dormant tickets.
> 
> I wanted to start a thread and share some thoughts with the dev@ list.   
> 
> There are a couple of approaches we could take to these new contributions.   
> 
> 1) We could limit the number of PR's opened, but to me, it just seems like we are gating potential new contributions (and anyway we close PR's if they don't get activity after a period of time anyway).
> 
> 2) We probably *should* go back through our JIRA and close issues that are no longer relevant to the project so that new contributors don't get mislead.  Today I would consider any JIRA issue open for Solr as a valid one to be worked, but maybe that isnt' the case.
> 
> 3) We could establish strong prioritization for what PR's need review.  For example, when I look at what Nick has provided, maybe we want to focus first on bugs before we focus on feature oriented PR's?    
> 
> 4) We could lean more heavily into AI for evaluating PRs so we can get through them easier?  I know I struggle with PR's that I want to review, but aren't in an area that I have deep expertise in.  Unforutantly, too many of those PRs then just wither on the vine.
> 
> 5) We can try and activate more committers and contributors to be reviwers.  I'm referencing David's email: "What a time to be a committer in 2026".   https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
> 
> I don't know what the right path forward is, though I suspect it all requires us to grow the set of people reviewing PR's.   Any approach we take hits up against the fundamental limit of us having only so many folks actively working PR's and merging them.   
> 
> Beyond that, I wanted to start thinking about who to tag for review beyond the immediate suspects that Github recommends.  My thought was "Who are the specialists in various areas" that maybe aren't super active, but would be happy to engage on a PR.   
> 
> So I put together this analysis: https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> 
> I'd love feedback on it, I suspect it will go through some iterations to be accurate.
> 
> Secondly, I wanted to get my arms around the contributions from Nick, as there are 30 of them which makes it tough to figure out where to start.   I went ahead and leaned into my current "Pacific Rim" movie fascination, and did an analysis of them.   I tried to seperate out the pure bug fix from the feature fixes, and get a quick sense of the complexity of going through them.
> 
> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
> 

Re: What a time to be a committer in 2026

[Gus Heck <gu...@gmail.com>]

I expect the ASF policy to track the legal realities, and only change when
that changes. One of the benefits of being an ASF project is that there is
a legal team offering us guidance.

On Sat, Oct 17, 2026 at 11:42 AM Eric Pugh via dev <de...@solr.apache.org>
wrote:

> Having said that, there is “Use AI for tooling around our code” and then
> “write our source code with AI”.
>
> I probably am leaning more and more into using AI to help with the review
> work.   Especially when I’m trying to review code that I am not already an
> expert.  Having the “back and forth” conversation is awamzing.   I’d rather
> have it with a Human, but…
>
>
> > On Oct 17, 2026, at 11:40 AM, Eric Pugh <ep...@opensourceconnections.com>
> wrote:
> >
> > The AI policy and our own AI policy probably need some refreshing and
> looking at.   I haven’t written a line of Solr that wasn’t AI assisted in
> someway or another in weeks.
> >
> > And I think it has let me be a better more active reviewer of PR’s.
>  Now if only JIRA had a better MCP/CLI tool ;-)
> >
> >
> >> On Oct 17, 2026, at 10:36 AM, Gus Heck <gu...@gmail.com> wrote:
> >>
> >> Another thing to consider when reading that link is that very large AI
> >> companies, which have a HUGE vested interest in the copyright status of
> AI
> >> outputs likely have lobbyists, and could offer campaign contributions
> >> contingent on support for changes to the laws surrounding AI outputs.
> >>
> >> On Sat, Oct 17, 2026 at 10:27 AM Gus Heck <gu...@gmail.com> wrote:
> >>
> >> > Nobody liked it when I pointed it out on the lucene list, but there
> is ASF
> >> > guidance on this:
> >> >
> https://www.apache.org/legal/generative-tooling.html#include-in-contributions
> <
> https://www.apache.org/legal/generative-tooling.html#include-in-contributions
> >
> >> > Note especially the bits about copyright.
> >> >
> >> > The more AI code we accept the more easily disputed our copyright
> claim
> >> > is.
> >> >
> >> > People seem to get upset, as if I'm trying to take away their candy
> when I
> >> > point this out, but someday some project will become the test case...
> >> >
> >> > On Fri, Oct 16, 2026 at 10:16 AM Eric Pugh <ep...@apache.org> wrote:
> >> >
> >> >>
> >> >>
> >> >> On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> >> >> > I'm not sure I agree with the bullish assessment on all fronts
> haha,
> >> >> > but I love the call to action! Both as individuals and as a group
> we
> >> >> > can be doing more to help out contributors.
> >> >> >
> >> >> > As an aside - I haven't played around with the Github Copilot stuff
> >> >> > you mentioned. (Largely because I've been pretty happy with
> Claude).
> >> >> > Maybe I'm alone in being a late adopter there, but if I'm not then
> >> >> > maybe that'd make a good demo for our community meetup? Show other
> >> >> > committers something that you've seemingly found revolutionary in
> your
> >> >> > review workflow.
> >> >> >
> >> >> > > Eric cleverly convinced me I wasn't doing enough
> >> >> >
> >> >> > Never listen to Eric :-p
> >> >> >
> >> >> > Jason
> >> >> >
> >> >> > On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> >> >> > <ar...@gmail.com> wrote:
> >> >> > >
> >> >> > > Maybe we can get a dedicated open source code review bot and
> tweak
> >> >> it’s code for us. That should instill more confidence :)
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > > On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
> >> >> wrote:
> >> >> > > >
> >> >> > > > It's never been an easier time as a committer to be the
> >> >> shepherd/reviewer
> >> >> > > > to a non-committer PR. We have automated code reviews via
> GitHub
> >> >> co-pilot
> >> >> > > > (need to add as a reviewer to engage). No longer do we have to
> >> >> edit a
> >> >> > > > massive CHANGES.txt to pick a version that might be wrong or
> even
> >> >> know the
> >> >> > > > version. No longer do we have the chore of back-porting, for
> the
> >> >> vast
> >> >> > > > majority of PRs. Just pick a final destination Milestone on
> the PR
> >> >> and
> >> >> > > > please DM me a "thank you" if you appreciate this. An LLM armed
> >> >> with a
> >> >> > > > script is usually going to do this more thoroughly than you
> would
> >> >> have
> >> >> > > > (i.e. it actually considers multiple CI jobs and usually runs
> tests
> >> >> before
> >> >> > > > push). And recently, I'll manually "resolve" the JIRA issue as
> >> >> well as the
> >> >> > > > final step (if it looks like a one-shot PR issue) -- Eric
> cleverly
> >> >> > > > convinced me I wasn't doing enough, so I've got this ;-). It's
> >> >> really
> >> >> > > > rather satisfying.
> >> >> > > >
> >> >> > > > So with that said, I want to ask the committers here that don't
> >> >> review
> >> >> > > > other people's PRs to please do so, especially those of
> >> >> contributors. You
> >> >> > > > have powers they don't -- you can get something merged. The
> >> >> contributor
> >> >> > > > will be grateful; remember being in their shoes. You can fully
> >> >> handle a PR
> >> >> > > > responsiby without leaving the GitHub PR issue screen -- at
> least
> >> >> most of
> >> >> > > > the time.
> >> >> > > >
> >> >> > > > p.s. I'm also grateful for Crave.io for very fast builds... but
> >> >> we'll need
> >> >> > > > to do without this by the end of the year :-(
> >> >> > > >
> >> >> > > > ~ David Smiley
> >> >> > > > Apache Lucene/Solr Search Developer
> >> >> > > > http://www.linkedin.com/in/davidwsmiley <
> http://www.linkedin.com/in/davidwsmiley>
> >> >> > >
> >> >> > >
> ---------------------------------------------------------------------
> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> >> > > For additional commands, e-mail: dev-help@solr.apache.org
> >> >> > >
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> >> > For additional commands, e-mail: dev-help@solr.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >> A big topic at Community/Code this past week across all the projects
> (not
> >> >> just ours) was the benefits and perils of AI assisted coding. During
> the
> >> >> past few months we've seen some very prolific new contributors
> (thanks
> >> >> Serhiy!) start contributing to Solr. The fresh energy has really
> >> >> increased our project development. Then we've had Nick join the
> party,
> >> >> and he has gone through our JIRA backlog and cranked out quite a few
> PR's
> >> >> that deal with long dormant tickets.
> >> >>
> >> >> I wanted to start a thread and share some thoughts with the dev@
> list.
> >> >>
> >> >> There are a couple of approaches we could take to these new
> >> >> contributions.
> >> >>
> >> >> 1) We could limit the number of PR's opened, but to me, it just seems
> >> >> like we are gating potential new contributions (and anyway we close
> PR's if
> >> >> they don't get activity after a period of time anyway).
> >> >>
> >> >> 2) We probably *should* go back through our JIRA and close issues
> that
> >> >> are no longer relevant to the project so that new contributors don't
> get
> >> >> mislead. Today I would consider any JIRA issue open for Solr as a
> valid
> >> >> one to be worked, but maybe that isnt' the case.
> >> >>
> >> >> 3) We could establish strong prioritization for what PR's need
> review.
> >> >> For example, when I look at what Nick has provided, maybe we want to
> focus
> >> >> first on bugs before we focus on feature oriented PR's?
> >> >>
> >> >> 4) We could lean more heavily into AI for evaluating PRs so we can
> get
> >> >> through them easier? I know I struggle with PR's that I want to
> review,
> >> >> but aren't in an area that I have deep expertise in. Unforutantly,
> too
> >> >> many of those PRs then just wither on the vine.
> >> >>
> >> >> 5) We can try and activate more committers and contributors to be
> >> >> reviwers. I'm referencing David's email: "What a time to be a
> committer in
> >> >> 2026".
> >> >>
> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79 <
> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79>
> >> >>
> >> >> I don't know what the right path forward is, though I suspect it all
> >> >> requires us to grow the set of people reviewing PR's. Any approach we
> >> >> take hits up against the fundamental limit of us having only so many
> folks
> >> >> actively working PR's and merging them.
> >> >>
> >> >> Beyond that, I wanted to start thinking about who to tag for review
> >> >> beyond the immediate suspects that Github recommends. My thought was
> "Who
> >> >> are the specialists in various areas" that maybe aren't super
> active, but
> >> >> would be happy to engage on a PR.
> >> >>
> >> >> So I put together this analysis:
> >> >>
> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> <
> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
> >
> >> >>
> >> >> I'd love feedback on it, I suspect it will go through some
> iterations to
> >> >> be accurate.
> >> >>
> >> >> Secondly, I wanted to get my arms around the contributions from
> Nick, as
> >> >> there are 30 of them which makes it tough to figure out where to
> start. I
> >> >> went ahead and leaned into my current "Pacific Rim" movie
> fascination, and
> >> >> did an analysis of them. I tried to seperate out the pure bug fix
> from
> >> >> the feature fixes, and get a quick sense of the complexity of going
> through
> >> >> them.
> >> >>
> >> >>
> >> >>
> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> <
> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
> >
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> >> For additional commands, e-mail: dev-help@solr.apache.org
> >> >>
> >> >>
> >> >
> >> > --
> >> > http://www.needhamsoftware.com <http://www.needhamsoftware.com>
> (work)
> >> > https://a.co/d/b2sZLD9 <https://a.co/d/b2sZLD9> (my fantasy fiction
> book)
> >> >
> >>
> >>
> >> --
> >> http://www.needhamsoftware.com <http://www.needhamsoftware.com> (work)
> >> https://a.co/d/b2sZLD9 <https://a.co/d/b2sZLD9> (my fantasy fiction
> book)
> >
>
> Disclaimer
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by Mimecast, a leader in email security and cyber
> resilience. Mimecast integrates email defenses with brand protection,
> security awareness training, web security, compliance and other essential
> capabilities. Mimecast helps protect large and small organizations from
> malicious activity, human error and technology failure; and to lead the
> movement toward building a more resilient world. To find out more, visit
> our website.
>


-- 
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)

Re: What a time to be a committer in 2026

[Eric Pugh via dev <de...@solr.apache.org>]

Having said that, there is “Use AI for tooling around our code” and then “write our source code with AI”.

I probably am leaning more and more into using AI to help with the review work.   Especially when I’m trying to review code that I am not already an expert.  Having the “back and forth” conversation is awamzing.   I’d rather have it with a Human, but…


> On Oct 17, 2026, at 11:40 AM, Eric Pugh <ep...@opensourceconnections.com> wrote:
> 
> The AI policy and our own AI policy probably need some refreshing and looking at.   I haven’t written a line of Solr that wasn’t AI assisted in someway or another in weeks.
> 
> And I think it has let me be a better more active reviewer of PR’s.   Now if only JIRA had a better MCP/CLI tool ;-)
> 
> 
>> On Oct 17, 2026, at 10:36 AM, Gus Heck <gu...@gmail.com> wrote:
>> 
>> Another thing to consider when reading that link is that very large AI
>> companies, which have a HUGE vested interest in the copyright status of AI
>> outputs likely have lobbyists, and could offer campaign contributions
>> contingent on support for changes to the laws surrounding AI outputs.
>> 
>> On Sat, Oct 17, 2026 at 10:27 AM Gus Heck <gu...@gmail.com> wrote:
>> 
>> > Nobody liked it when I pointed it out on the lucene list, but there is ASF
>> > guidance on this:
>> > https://www.apache.org/legal/generative-tooling.html#include-in-contributions <https://www.apache.org/legal/generative-tooling.html#include-in-contributions>
>> > Note especially the bits about copyright.
>> >
>> > The more AI code we accept the more easily disputed our copyright claim
>> > is.
>> >
>> > People seem to get upset, as if I'm trying to take away their candy when I
>> > point this out, but someday some project will become the test case...
>> >
>> > On Fri, Oct 16, 2026 at 10:16 AM Eric Pugh <ep...@apache.org> wrote:
>> >
>> >>
>> >>
>> >> On 2026/09/03 22:44:13 Jason Gerlowski wrote:
>> >> > I'm not sure I agree with the bullish assessment on all fronts haha,
>> >> > but I love the call to action! Both as individuals and as a group we
>> >> > can be doing more to help out contributors.
>> >> >
>> >> > As an aside - I haven't played around with the Github Copilot stuff
>> >> > you mentioned. (Largely because I've been pretty happy with Claude).
>> >> > Maybe I'm alone in being a late adopter there, but if I'm not then
>> >> > maybe that'd make a good demo for our community meetup? Show other
>> >> > committers something that you've seemingly found revolutionary in your
>> >> > review workflow.
>> >> >
>> >> > > Eric cleverly convinced me I wasn't doing enough
>> >> >
>> >> > Never listen to Eric :-p
>> >> >
>> >> > Jason
>> >> >
>> >> > On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
>> >> > <ar...@gmail.com> wrote:
>> >> > >
>> >> > > Maybe we can get a dedicated open source code review bot and tweak
>> >> it’s code for us. That should instill more confidence :)
>> >> > >
>> >> > >
>> >> > >
>> >> > > > On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
>> >> wrote:
>> >> > > >
>> >> > > > It's never been an easier time as a committer to be the
>> >> shepherd/reviewer
>> >> > > > to a non-committer PR. We have automated code reviews via GitHub
>> >> co-pilot
>> >> > > > (need to add as a reviewer to engage). No longer do we have to
>> >> edit a
>> >> > > > massive CHANGES.txt to pick a version that might be wrong or even
>> >> know the
>> >> > > > version. No longer do we have the chore of back-porting, for the
>> >> vast
>> >> > > > majority of PRs. Just pick a final destination Milestone on the PR
>> >> and
>> >> > > > please DM me a "thank you" if you appreciate this. An LLM armed
>> >> with a
>> >> > > > script is usually going to do this more thoroughly than you would
>> >> have
>> >> > > > (i.e. it actually considers multiple CI jobs and usually runs tests
>> >> before
>> >> > > > push). And recently, I'll manually "resolve" the JIRA issue as
>> >> well as the
>> >> > > > final step (if it looks like a one-shot PR issue) -- Eric cleverly
>> >> > > > convinced me I wasn't doing enough, so I've got this ;-). It's
>> >> really
>> >> > > > rather satisfying.
>> >> > > >
>> >> > > > So with that said, I want to ask the committers here that don't
>> >> review
>> >> > > > other people's PRs to please do so, especially those of
>> >> contributors. You
>> >> > > > have powers they don't -- you can get something merged. The
>> >> contributor
>> >> > > > will be grateful; remember being in their shoes. You can fully
>> >> handle a PR
>> >> > > > responsiby without leaving the GitHub PR issue screen -- at least
>> >> most of
>> >> > > > the time.
>> >> > > >
>> >> > > > p.s. I'm also grateful for Crave.io for very fast builds... but
>> >> we'll need
>> >> > > > to do without this by the end of the year :-(
>> >> > > >
>> >> > > > ~ David Smiley
>> >> > > > Apache Lucene/Solr Search Developer
>> >> > > > http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>> >> > >
>> >> > > ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> >> > > For additional commands, e-mail: dev-help@solr.apache.org
>> >> > >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> >> > For additional commands, e-mail: dev-help@solr.apache.org
>> >> >
>> >> >
>> >>
>> >> A big topic at Community/Code this past week across all the projects (not
>> >> just ours) was the benefits and perils of AI assisted coding. During the
>> >> past few months we've seen some very prolific new contributors (thanks
>> >> Serhiy!) start contributing to Solr. The fresh energy has really
>> >> increased our project development. Then we've had Nick join the party,
>> >> and he has gone through our JIRA backlog and cranked out quite a few PR's
>> >> that deal with long dormant tickets.
>> >>
>> >> I wanted to start a thread and share some thoughts with the dev@ list.
>> >>
>> >> There are a couple of approaches we could take to these new
>> >> contributions.
>> >>
>> >> 1) We could limit the number of PR's opened, but to me, it just seems
>> >> like we are gating potential new contributions (and anyway we close PR's if
>> >> they don't get activity after a period of time anyway).
>> >>
>> >> 2) We probably *should* go back through our JIRA and close issues that
>> >> are no longer relevant to the project so that new contributors don't get
>> >> mislead. Today I would consider any JIRA issue open for Solr as a valid
>> >> one to be worked, but maybe that isnt' the case.
>> >>
>> >> 3) We could establish strong prioritization for what PR's need review.
>> >> For example, when I look at what Nick has provided, maybe we want to focus
>> >> first on bugs before we focus on feature oriented PR's?
>> >>
>> >> 4) We could lean more heavily into AI for evaluating PRs so we can get
>> >> through them easier? I know I struggle with PR's that I want to review,
>> >> but aren't in an area that I have deep expertise in. Unforutantly, too
>> >> many of those PRs then just wither on the vine.
>> >>
>> >> 5) We can try and activate more committers and contributors to be
>> >> reviwers. I'm referencing David's email: "What a time to be a committer in
>> >> 2026".
>> >> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79 <https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79>
>> >>
>> >> I don't know what the right path forward is, though I suspect it all
>> >> requires us to grow the set of people reviewing PR's. Any approach we
>> >> take hits up against the fundamental limit of us having only so many folks
>> >> actively working PR's and merging them.
>> >>
>> >> Beyond that, I wanted to start thinking about who to tag for review
>> >> beyond the immediate suspects that Github recommends. My thought was "Who
>> >> are the specialists in various areas" that maybe aren't super active, but
>> >> would be happy to engage on a PR.
>> >>
>> >> So I put together this analysis:
>> >> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q <https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q>
>> >>
>> >> I'd love feedback on it, I suspect it will go through some iterations to
>> >> be accurate.
>> >>
>> >> Secondly, I wanted to get my arms around the contributions from Nick, as
>> >> there are 30 of them which makes it tough to figure out where to start. I
>> >> went ahead and leaned into my current "Pacific Rim" movie fascination, and
>> >> did an analysis of them. I tried to seperate out the pure bug fix from
>> >> the feature fixes, and get a quick sense of the complexity of going through
>> >> them.
>> >>
>> >>
>> >> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog <https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> >> For additional commands, e-mail: dev-help@solr.apache.org
>> >>
>> >>
>> >
>> > --
>> > http://www.needhamsoftware.com <http://www.needhamsoftware.com> (work)
>> > https://a.co/d/b2sZLD9 <https://a.co/d/b2sZLD9> (my fantasy fiction book)
>> >
>> 
>> 
>> -- 
>> http://www.needhamsoftware.com <http://www.needhamsoftware.com> (work)
>> https://a.co/d/b2sZLD9 <https://a.co/d/b2sZLD9> (my fantasy fiction book)
> 

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.

Re: What a time to be a committer in 2026

[Eric Pugh via dev <de...@solr.apache.org>]

The AI policy and our own AI policy probably need some refreshing and looking at.   I haven’t written a line of Solr that wasn’t AI assisted in someway or another in weeks.

And I think it has let me be a better more active reviewer of PR’s.   Now if only JIRA had a better MCP/CLI tool ;-)


> On Oct 17, 2026, at 10:36 AM, Gus Heck <gu...@gmail.com> wrote:
> 
> Another thing to consider when reading that link is that very large AI
> companies, which have a HUGE vested interest in the copyright status of AI
> outputs likely have lobbyists, and could offer campaign contributions
> contingent on support for changes to the laws surrounding AI outputs.
> 
> On Sat, Oct 17, 2026 at 10:27 AM Gus Heck <gu...@gmail.com> wrote:
> 
> > Nobody liked it when I pointed it out on the lucene list, but there is ASF
> > guidance on this:
> > https://www.apache.org/legal/generative-tooling.html#include-in-contributions <https://www.apache.org/legal/generative-tooling.html#include-in-contributions>
> > Note especially the bits about copyright.
> >
> > The more AI code we accept the more easily disputed our copyright claim
> > is.
> >
> > People seem to get upset, as if I'm trying to take away their candy when I
> > point this out, but someday some project will become the test case...
> >
> > On Fri, Oct 16, 2026 at 10:16 AM Eric Pugh <ep...@apache.org> wrote:
> >
> >>
> >>
> >> On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> >> > I'm not sure I agree with the bullish assessment on all fronts haha,
> >> > but I love the call to action! Both as individuals and as a group we
> >> > can be doing more to help out contributors.
> >> >
> >> > As an aside - I haven't played around with the Github Copilot stuff
> >> > you mentioned. (Largely because I've been pretty happy with Claude).
> >> > Maybe I'm alone in being a late adopter there, but if I'm not then
> >> > maybe that'd make a good demo for our community meetup? Show other
> >> > committers something that you've seemingly found revolutionary in your
> >> > review workflow.
> >> >
> >> > > Eric cleverly convinced me I wasn't doing enough
> >> >
> >> > Never listen to Eric :-p
> >> >
> >> > Jason
> >> >
> >> > On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> >> > <ar...@gmail.com> wrote:
> >> > >
> >> > > Maybe we can get a dedicated open source code review bot and tweak
> >> it’s code for us. That should instill more confidence :)
> >> > >
> >> > >
> >> > >
> >> > > > On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
> >> wrote:
> >> > > >
> >> > > > It's never been an easier time as a committer to be the
> >> shepherd/reviewer
> >> > > > to a non-committer PR. We have automated code reviews via GitHub
> >> co-pilot
> >> > > > (need to add as a reviewer to engage). No longer do we have to
> >> edit a
> >> > > > massive CHANGES.txt to pick a version that might be wrong or even
> >> know the
> >> > > > version. No longer do we have the chore of back-porting, for the
> >> vast
> >> > > > majority of PRs. Just pick a final destination Milestone on the PR
> >> and
> >> > > > please DM me a "thank you" if you appreciate this. An LLM armed
> >> with a
> >> > > > script is usually going to do this more thoroughly than you would
> >> have
> >> > > > (i.e. it actually considers multiple CI jobs and usually runs tests
> >> before
> >> > > > push). And recently, I'll manually "resolve" the JIRA issue as
> >> well as the
> >> > > > final step (if it looks like a one-shot PR issue) -- Eric cleverly
> >> > > > convinced me I wasn't doing enough, so I've got this ;-). It's
> >> really
> >> > > > rather satisfying.
> >> > > >
> >> > > > So with that said, I want to ask the committers here that don't
> >> review
> >> > > > other people's PRs to please do so, especially those of
> >> contributors. You
> >> > > > have powers they don't -- you can get something merged. The
> >> contributor
> >> > > > will be grateful; remember being in their shoes. You can fully
> >> handle a PR
> >> > > > responsiby without leaving the GitHub PR issue screen -- at least
> >> most of
> >> > > > the time.
> >> > > >
> >> > > > p.s. I'm also grateful for Crave.io for very fast builds... but
> >> we'll need
> >> > > > to do without this by the end of the year :-(
> >> > > >
> >> > > > ~ David Smiley
> >> > > > Apache Lucene/Solr Search Developer
> >> > > > http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> > > For additional commands, e-mail: dev-help@solr.apache.org
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> > For additional commands, e-mail: dev-help@solr.apache.org
> >> >
> >> >
> >>
> >> A big topic at Community/Code this past week across all the projects (not
> >> just ours) was the benefits and perils of AI assisted coding. During the
> >> past few months we've seen some very prolific new contributors (thanks
> >> Serhiy!) start contributing to Solr. The fresh energy has really
> >> increased our project development. Then we've had Nick join the party,
> >> and he has gone through our JIRA backlog and cranked out quite a few PR's
> >> that deal with long dormant tickets.
> >>
> >> I wanted to start a thread and share some thoughts with the dev@ list.
> >>
> >> There are a couple of approaches we could take to these new
> >> contributions.
> >>
> >> 1) We could limit the number of PR's opened, but to me, it just seems
> >> like we are gating potential new contributions (and anyway we close PR's if
> >> they don't get activity after a period of time anyway).
> >>
> >> 2) We probably *should* go back through our JIRA and close issues that
> >> are no longer relevant to the project so that new contributors don't get
> >> mislead. Today I would consider any JIRA issue open for Solr as a valid
> >> one to be worked, but maybe that isnt' the case.
> >>
> >> 3) We could establish strong prioritization for what PR's need review.
> >> For example, when I look at what Nick has provided, maybe we want to focus
> >> first on bugs before we focus on feature oriented PR's?
> >>
> >> 4) We could lean more heavily into AI for evaluating PRs so we can get
> >> through them easier? I know I struggle with PR's that I want to review,
> >> but aren't in an area that I have deep expertise in. Unforutantly, too
> >> many of those PRs then just wither on the vine.
> >>
> >> 5) We can try and activate more committers and contributors to be
> >> reviwers. I'm referencing David's email: "What a time to be a committer in
> >> 2026".
> >> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79 <https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79>
> >>
> >> I don't know what the right path forward is, though I suspect it all
> >> requires us to grow the set of people reviewing PR's. Any approach we
> >> take hits up against the fundamental limit of us having only so many folks
> >> actively working PR's and merging them.
> >>
> >> Beyond that, I wanted to start thinking about who to tag for review
> >> beyond the immediate suspects that Github recommends. My thought was "Who
> >> are the specialists in various areas" that maybe aren't super active, but
> >> would be happy to engage on a PR.
> >>
> >> So I put together this analysis:
> >> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q <https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q>
> >>
> >> I'd love feedback on it, I suspect it will go through some iterations to
> >> be accurate.
> >>
> >> Secondly, I wanted to get my arms around the contributions from Nick, as
> >> there are 30 of them which makes it tough to figure out where to start. I
> >> went ahead and leaned into my current "Pacific Rim" movie fascination, and
> >> did an analysis of them. I tried to seperate out the pure bug fix from
> >> the feature fixes, and get a quick sense of the complexity of going through
> >> them.
> >>
> >>
> >> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog <https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
> >
> > --
> > http://www.needhamsoftware.com <http://www.needhamsoftware.com> (work)
> > https://a.co/d/b2sZLD9 <https://a.co/d/b2sZLD9> (my fantasy fiction book)
> >
> 
> 
> -- 
> http://www.needhamsoftware.com <http://www.needhamsoftware.com> (work)
> https://a.co/d/b2sZLD9 <https://a.co/d/b2sZLD9> (my fantasy fiction book)

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.

Re: What a time to be a committer in 2026

[Gus Heck <gu...@gmail.com>]

Another thing to consider when reading that link is that very large AI
companies, which have a HUGE vested interest in the copyright status of AI
outputs likely have lobbyists, and could offer campaign contributions
contingent on support for changes to the laws surrounding AI outputs.

On Sat, Oct 17, 2026 at 10:27 AM Gus Heck <gu...@gmail.com> wrote:

> Nobody liked it when I pointed it out on the lucene list, but there is ASF
> guidance on this:
> https://www.apache.org/legal/generative-tooling.html#include-in-contributions
> Note especially the bits about copyright.
>
> The more AI code we accept the more easily disputed our copyright claim
> is.
>
> People seem to get upset, as if I'm trying to take away their candy when I
> point this out, but someday some project will become the test case...
>
> On Fri, Oct 16, 2026 at 10:16 AM Eric Pugh <ep...@apache.org> wrote:
>
>>
>>
>> On 2026/09/03 22:44:13 Jason Gerlowski wrote:
>> > I'm not sure I agree with the bullish assessment on all fronts haha,
>> > but I love the call to action! Both as individuals and as a group we
>> > can be doing more to help out contributors.
>> >
>> > As an aside - I haven't played around with the Github Copilot stuff
>> > you mentioned.  (Largely because I've been pretty happy with Claude).
>> > Maybe I'm alone in being a late adopter there, but if I'm not then
>> > maybe that'd make a good demo for our community meetup?  Show other
>> > committers something that you've seemingly found revolutionary in your
>> > review workflow.
>> >
>> > > Eric cleverly convinced me I wasn't doing enough
>> >
>> > Never listen to Eric :-p
>> >
>> > Jason
>> >
>> > On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
>> > <ar...@gmail.com> wrote:
>> > >
>> > > Maybe we can get a dedicated open source code review bot and tweak
>> it’s code for us. That should instill more confidence :)
>> > >
>> > >
>> > >
>> > > > On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org>
>> wrote:
>> > > >
>> > > > It's never been an easier time as a committer to be the
>> shepherd/reviewer
>> > > > to a non-committer PR.  We have automated code reviews via GitHub
>> co-pilot
>> > > > (need to add as a reviewer to engage).  No longer do we have to
>> edit a
>> > > > massive CHANGES.txt to pick a version that might be wrong or even
>> know the
>> > > > version.  No longer do we have the chore of back-porting, for the
>> vast
>> > > > majority of PRs.  Just pick a final destination Milestone on the PR
>> and
>> > > > please DM me a "thank you" if you appreciate this.  An LLM armed
>> with a
>> > > > script is usually going to do this more thoroughly than you would
>> have
>> > > > (i.e. it actually considers multiple CI jobs and usually runs tests
>> before
>> > > > push).  And recently, I'll manually "resolve" the JIRA issue as
>> well as the
>> > > > final step (if it looks like a one-shot PR issue) -- Eric cleverly
>> > > > convinced me I wasn't doing enough, so I've got this ;-).  It's
>> really
>> > > > rather satisfying.
>> > > >
>> > > > So with that said, I want to ask the committers here that don't
>> review
>> > > > other people's PRs to please do so, especially those of
>> contributors.  You
>> > > > have powers they don't -- you can get something merged.  The
>> contributor
>> > > > will be grateful; remember being in their shoes.  You can fully
>> handle a PR
>> > > > responsiby without leaving the GitHub PR issue screen -- at least
>> most of
>> > > > the time.
>> > > >
>> > > > p.s. I'm also grateful for Crave.io for very fast builds... but
>> we'll need
>> > > > to do without this by the end of the year :-(
>> > > >
>> > > > ~ David Smiley
>> > > > Apache Lucene/Solr Search Developer
>> > > > http://www.linkedin.com/in/davidwsmiley
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> > > For additional commands, e-mail: dev-help@solr.apache.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> > For additional commands, e-mail: dev-help@solr.apache.org
>> >
>> >
>>
>> A big topic at Community/Code this past week across all the projects (not
>> just ours) was the benefits and perils of AI assisted coding.   During the
>> past few months we've seen some very prolific new contributors (thanks
>> Serhiy!) start contributing to Solr.   The fresh energy has really
>> increased our project development.   Then we've had Nick join the party,
>> and he has gone through our JIRA backlog and cranked out quite a few PR's
>> that deal with long dormant tickets.
>>
>> I wanted to start a thread and share some thoughts with the dev@ list.
>>
>> There are a couple of approaches we could take to these new
>> contributions.
>>
>> 1) We could limit the number of PR's opened, but to me, it just seems
>> like we are gating potential new contributions (and anyway we close PR's if
>> they don't get activity after a period of time anyway).
>>
>> 2) We probably *should* go back through our JIRA and close issues that
>> are no longer relevant to the project so that new contributors don't get
>> mislead.  Today I would consider any JIRA issue open for Solr as a valid
>> one to be worked, but maybe that isnt' the case.
>>
>> 3) We could establish strong prioritization for what PR's need review.
>> For example, when I look at what Nick has provided, maybe we want to focus
>> first on bugs before we focus on feature oriented PR's?
>>
>> 4) We could lean more heavily into AI for evaluating PRs so we can get
>> through them easier?  I know I struggle with PR's that I want to review,
>> but aren't in an area that I have deep expertise in.  Unforutantly, too
>> many of those PRs then just wither on the vine.
>>
>> 5) We can try and activate more committers and contributors to be
>> reviwers.  I'm referencing David's email: "What a time to be a committer in
>> 2026".
>> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
>>
>> I don't know what the right path forward is, though I suspect it all
>> requires us to grow the set of people reviewing PR's.   Any approach we
>> take hits up against the fundamental limit of us having only so many folks
>> actively working PR's and merging them.
>>
>> Beyond that, I wanted to start thinking about who to tag for review
>> beyond the immediate suspects that Github recommends.  My thought was "Who
>> are the specialists in various areas" that maybe aren't super active, but
>> would be happy to engage on a PR.
>>
>> So I put together this analysis:
>> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
>>
>> I'd love feedback on it, I suspect it will go through some iterations to
>> be accurate.
>>
>> Secondly, I wanted to get my arms around the contributions from Nick, as
>> there are 30 of them which makes it tough to figure out where to start.   I
>> went ahead and leaned into my current "Pacific Rim" movie fascination, and
>> did an analysis of them.   I tried to seperate out the pure bug fix from
>> the feature fixes, and get a quick sense of the complexity of going through
>> them.
>>
>>
>> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)
>


-- 
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)

Re: What a time to be a committer in 2026

[Gus Heck <gu...@gmail.com>]

Nobody liked it when I pointed it out on the lucene list, but there is ASF
guidance on this:
https://www.apache.org/legal/generative-tooling.html#include-in-contributions
Note especially the bits about copyright.

The more AI code we accept the more easily disputed our copyright claim is.

People seem to get upset, as if I'm trying to take away their candy when I
point this out, but someday some project will become the test case...

On Fri, Oct 16, 2026 at 10:16 AM Eric Pugh <ep...@apache.org> wrote:

>
>
> On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> > I'm not sure I agree with the bullish assessment on all fronts haha,
> > but I love the call to action! Both as individuals and as a group we
> > can be doing more to help out contributors.
> >
> > As an aside - I haven't played around with the Github Copilot stuff
> > you mentioned.  (Largely because I've been pretty happy with Claude).
> > Maybe I'm alone in being a late adopter there, but if I'm not then
> > maybe that'd make a good demo for our community meetup?  Show other
> > committers something that you've seemingly found revolutionary in your
> > review workflow.
> >
> > > Eric cleverly convinced me I wasn't doing enough
> >
> > Never listen to Eric :-p
> >
> > Jason
> >
> > On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> > <ar...@gmail.com> wrote:
> > >
> > > Maybe we can get a dedicated open source code review bot and tweak
> it’s code for us. That should instill more confidence :)
> > >
> > >
> > >
> > > > On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org> wrote:
> > > >
> > > > It's never been an easier time as a committer to be the
> shepherd/reviewer
> > > > to a non-committer PR.  We have automated code reviews via GitHub
> co-pilot
> > > > (need to add as a reviewer to engage).  No longer do we have to edit
> a
> > > > massive CHANGES.txt to pick a version that might be wrong or even
> know the
> > > > version.  No longer do we have the chore of back-porting, for the
> vast
> > > > majority of PRs.  Just pick a final destination Milestone on the PR
> and
> > > > please DM me a "thank you" if you appreciate this.  An LLM armed
> with a
> > > > script is usually going to do this more thoroughly than you would
> have
> > > > (i.e. it actually considers multiple CI jobs and usually runs tests
> before
> > > > push).  And recently, I'll manually "resolve" the JIRA issue as well
> as the
> > > > final step (if it looks like a one-shot PR issue) -- Eric cleverly
> > > > convinced me I wasn't doing enough, so I've got this ;-).  It's
> really
> > > > rather satisfying.
> > > >
> > > > So with that said, I want to ask the committers here that don't
> review
> > > > other people's PRs to please do so, especially those of
> contributors.  You
> > > > have powers they don't -- you can get something merged.  The
> contributor
> > > > will be grateful; remember being in their shoes.  You can fully
> handle a PR
> > > > responsiby without leaving the GitHub PR issue screen -- at least
> most of
> > > > the time.
> > > >
> > > > p.s. I'm also grateful for Crave.io for very fast builds... but
> we'll need
> > > > to do without this by the end of the year :-(
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
> A big topic at Community/Code this past week across all the projects (not
> just ours) was the benefits and perils of AI assisted coding.   During the
> past few months we've seen some very prolific new contributors (thanks
> Serhiy!) start contributing to Solr.   The fresh energy has really
> increased our project development.   Then we've had Nick join the party,
> and he has gone through our JIRA backlog and cranked out quite a few PR's
> that deal with long dormant tickets.
>
> I wanted to start a thread and share some thoughts with the dev@ list.
>
> There are a couple of approaches we could take to these new
> contributions.
>
> 1) We could limit the number of PR's opened, but to me, it just seems like
> we are gating potential new contributions (and anyway we close PR's if they
> don't get activity after a period of time anyway).
>
> 2) We probably *should* go back through our JIRA and close issues that are
> no longer relevant to the project so that new contributors don't get
> mislead.  Today I would consider any JIRA issue open for Solr as a valid
> one to be worked, but maybe that isnt' the case.
>
> 3) We could establish strong prioritization for what PR's need review.
> For example, when I look at what Nick has provided, maybe we want to focus
> first on bugs before we focus on feature oriented PR's?
>
> 4) We could lean more heavily into AI for evaluating PRs so we can get
> through them easier?  I know I struggle with PR's that I want to review,
> but aren't in an area that I have deep expertise in.  Unforutantly, too
> many of those PRs then just wither on the vine.
>
> 5) We can try and activate more committers and contributors to be
> reviwers.  I'm referencing David's email: "What a time to be a committer in
> 2026".
> https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79
>
> I don't know what the right path forward is, though I suspect it all
> requires us to grow the set of people reviewing PR's.   Any approach we
> take hits up against the fundamental limit of us having only so many folks
> actively working PR's and merging them.
>
> Beyond that, I wanted to start thinking about who to tag for review beyond
> the immediate suspects that Github recommends.  My thought was "Who are the
> specialists in various areas" that maybe aren't super active, but would be
> happy to engage on a PR.
>
> So I put together this analysis:
> https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q
>
> I'd love feedback on it, I suspect it will go through some iterations to
> be accurate.
>
> Secondly, I wanted to get my arms around the contributions from Nick, as
> there are 30 of them which makes it tough to figure out where to start.   I
> went ahead and leaned into my current "Pacific Rim" movie fascination, and
> did an analysis of them.   I tried to seperate out the pure bug fix from
> the feature fixes, and get a quick sense of the complexity of going through
> them.
>
>
> https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>

-- 
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)

Re: What a time to be a committer in 2026

[Eric Pugh <ep...@apache.org>]

On 2026/09/03 22:44:13 Jason Gerlowski wrote:
> I'm not sure I agree with the bullish assessment on all fronts haha,
> but I love the call to action! Both as individuals and as a group we
> can be doing more to help out contributors.
> 
> As an aside - I haven't played around with the Github Copilot stuff
> you mentioned.  (Largely because I've been pretty happy with Claude).
> Maybe I'm alone in being a late adopter there, but if I'm not then
> maybe that'd make a good demo for our community meetup?  Show other
> committers something that you've seemingly found revolutionary in your
> review workflow.
> 
> > Eric cleverly convinced me I wasn't doing enough
> 
> Never listen to Eric :-p
> 
> Jason
> 
> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
> <ar...@gmail.com> wrote:
> >
> > Maybe we can get a dedicated open source code review bot and tweak it’s code for us. That should instill more confidence :)
> >
> >
> >
> > > On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org> wrote:
> > >
> > > It's never been an easier time as a committer to be the shepherd/reviewer
> > > to a non-committer PR.  We have automated code reviews via GitHub co-pilot
> > > (need to add as a reviewer to engage).  No longer do we have to edit a
> > > massive CHANGES.txt to pick a version that might be wrong or even know the
> > > version.  No longer do we have the chore of back-porting, for the vast
> > > majority of PRs.  Just pick a final destination Milestone on the PR and
> > > please DM me a "thank you" if you appreciate this.  An LLM armed with a
> > > script is usually going to do this more thoroughly than you would have
> > > (i.e. it actually considers multiple CI jobs and usually runs tests before
> > > push).  And recently, I'll manually "resolve" the JIRA issue as well as the
> > > final step (if it looks like a one-shot PR issue) -- Eric cleverly
> > > convinced me I wasn't doing enough, so I've got this ;-).  It's really
> > > rather satisfying.
> > >
> > > So with that said, I want to ask the committers here that don't review
> > > other people's PRs to please do so, especially those of contributors.  You
> > > have powers they don't -- you can get something merged.  The contributor
> > > will be grateful; remember being in their shoes.  You can fully handle a PR
> > > responsiby without leaving the GitHub PR issue screen -- at least most of
> > > the time.
> > >
> > > p.s. I'm also grateful for Crave.io for very fast builds... but we'll need
> > > to do without this by the end of the year :-(
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
> 
> 

A big topic at Community/Code this past week across all the projects (not just ours) was the benefits and perils of AI assisted coding.   During the past few months we've seen some very prolific new contributors (thanks Serhiy!) start contributing to Solr.   The fresh energy has really increased our project development.   Then we've had Nick join the party, and he has gone through our JIRA backlog and cranked out quite a few PR's that deal with long dormant tickets.

I wanted to start a thread and share some thoughts with the dev@ list.   

There are a couple of approaches we could take to these new contributions.   

1) We could limit the number of PR's opened, but to me, it just seems like we are gating potential new contributions (and anyway we close PR's if they don't get activity after a period of time anyway).

2) We probably *should* go back through our JIRA and close issues that are no longer relevant to the project so that new contributors don't get mislead.  Today I would consider any JIRA issue open for Solr as a valid one to be worked, but maybe that isnt' the case.

3) We could establish strong prioritization for what PR's need review.  For example, when I look at what Nick has provided, maybe we want to focus first on bugs before we focus on feature oriented PR's?    

4) We could lean more heavily into AI for evaluating PRs so we can get through them easier?  I know I struggle with PR's that I want to review, but aren't in an area that I have deep expertise in.  Unforutantly, too many of those PRs then just wither on the vine.

5) We can try and activate more committers and contributors to be reviwers.  I'm referencing David's email: "What a time to be a committer in 2026".   https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79

I don't know what the right path forward is, though I suspect it all requires us to grow the set of people reviewing PR's.   Any approach we take hits up against the fundamental limit of us having only so many folks actively working PR's and merging them.   

Beyond that, I wanted to start thinking about who to tag for review beyond the immediate suspects that Github recommends.  My thought was "Who are the specialists in various areas" that maybe aren't super active, but would be happy to engage on a PR.   

So I put together this analysis: https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q

I'd love feedback on it, I suspect it will go through some iterations to be accurate.

Secondly, I wanted to get my arms around the contributions from Nick, as there are 30 of them which makes it tough to figure out where to start.   I went ahead and leaned into my current "Pacific Rim" movie fascination, and did an analysis of them.   I tried to seperate out the pure bug fix from the feature fixes, and get a quick sense of the complexity of going through them.

https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org

Re: What a time to be a committer in 2026

[Jason Gerlowski <ge...@gmail.com>]

I'm not sure I agree with the bullish assessment on all fronts haha,
but I love the call to action! Both as individuals and as a group we
can be doing more to help out contributors.

As an aside - I haven't played around with the Github Copilot stuff
you mentioned.  (Largely because I've been pretty happy with Claude).
Maybe I'm alone in being a late adopter there, but if I'm not then
maybe that'd make a good demo for our community meetup?  Show other
committers something that you've seemingly found revolutionary in your
review workflow.

> Eric cleverly convinced me I wasn't doing enough

Never listen to Eric :-p

Jason

On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan
<ar...@gmail.com> wrote:
>
> Maybe we can get a dedicated open source code review bot and tweak it’s code for us. That should instill more confidence :)
>
>
>
> > On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org> wrote:
> >
> > It's never been an easier time as a committer to be the shepherd/reviewer
> > to a non-committer PR.  We have automated code reviews via GitHub co-pilot
> > (need to add as a reviewer to engage).  No longer do we have to edit a
> > massive CHANGES.txt to pick a version that might be wrong or even know the
> > version.  No longer do we have the chore of back-porting, for the vast
> > majority of PRs.  Just pick a final destination Milestone on the PR and
> > please DM me a "thank you" if you appreciate this.  An LLM armed with a
> > script is usually going to do this more thoroughly than you would have
> > (i.e. it actually considers multiple CI jobs and usually runs tests before
> > push).  And recently, I'll manually "resolve" the JIRA issue as well as the
> > final step (if it looks like a one-shot PR issue) -- Eric cleverly
> > convinced me I wasn't doing enough, so I've got this ;-).  It's really
> > rather satisfying.
> >
> > So with that said, I want to ask the committers here that don't review
> > other people's PRs to please do so, especially those of contributors.  You
> > have powers they don't -- you can get something merged.  The contributor
> > will be grateful; remember being in their shoes.  You can fully handle a PR
> > responsiby without leaving the GitHub PR issue screen -- at least most of
> > the time.
> >
> > p.s. I'm also grateful for Crave.io for very fast builds... but we'll need
> > to do without this by the end of the year :-(
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org

Re: What a time to be a committer in 2026

[Arup Chauhan <ar...@gmail.com>]

Maybe we can get a dedicated open source code review bot and tweak it’s code for us. That should instill more confidence :)



> On Sep 2, 2026, at 8:02 PM, David Smiley <ds...@apache.org> wrote:
> 
> It's never been an easier time as a committer to be the shepherd/reviewer
> to a non-committer PR.  We have automated code reviews via GitHub co-pilot
> (need to add as a reviewer to engage).  No longer do we have to edit a
> massive CHANGES.txt to pick a version that might be wrong or even know the
> version.  No longer do we have the chore of back-porting, for the vast
> majority of PRs.  Just pick a final destination Milestone on the PR and
> please DM me a "thank you" if you appreciate this.  An LLM armed with a
> script is usually going to do this more thoroughly than you would have
> (i.e. it actually considers multiple CI jobs and usually runs tests before
> push).  And recently, I'll manually "resolve" the JIRA issue as well as the
> final step (if it looks like a one-shot PR issue) -- Eric cleverly
> convinced me I wasn't doing enough, so I've got this ;-).  It's really
> rather satisfying.
> 
> So with that said, I want to ask the committers here that don't review
> other people's PRs to please do so, especially those of contributors.  You
> have powers they don't -- you can get something merged.  The contributor
> will be grateful; remember being in their shoes.  You can fully handle a PR
> responsiby without leaving the GitHub PR issue screen -- at least most of
> the time.
> 
> p.s. I'm also grateful for Crave.io for very fast builds... but we'll need
> to do without this by the end of the year :-(
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org