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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > >> >> > <[email protected]> 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 <[email protected]> > >> >> 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: [email protected] > >> >> > > For additional commands, e-mail: [email protected] > >> >> > > > >> >> > > >> >> > > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: [email protected] > >> >> > For additional commands, e-mail: [email protected] > >> >> > > >> >> > > >> >> > >> >> 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: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> > >> > > >> > -- > >> > 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)
