Here is the PR: https://github.com/apache/solr/pull/2731 Hope it captures the consensus in this thread.. Add a review comment if you want to change something. Will leave it open for several days..
One thing to think about is what will happen with the 92 PRs that are currently open and marked STALE. I counted, and 81 of those 92 are not updated last 60 days, so they'll probably be bulk-closed on first run. That may not be an issue since they did not attract attention first time around, and the close-message will also tell people that it is still possible to re-open. But if we want to be extra cautios we could bulk-remove stale label for all of them and let them trickle through the process again. I'm leaning towards letting them auto-close to avoid 81 mails for removing labels, 81 new mails for stale-msg and then 81 mails for close-msg... Jan > 28. sep. 2024 kl. 13:50 skrev David Eric Pugh <de...@yahoo.com.INVALID>: > > I haven't touch the labeling/workflow stuff, so I'd prefer not to make this > change. Jan, would this be up your alley? I think we have agreement to try > this! > > On Tuesday, September 24, 2024 at 10:36:05 AM EDT, Mike Drob > <md...@mdrob.com> wrote: > > I think this is a common sense of false optimism, that we will come back > and finish that PR we started. I too suffer from this frequently. > > Why does it matter if the PR is open or closed though? Re-opening is a > single click, and after 6 months of zero activity it’s probably full of > merge conflicts anyway. > > If we get to a workflow where open PRs roughly correspond to the direction > of the project then filtering out the false starts by closing them makes a > lot of sense to me. > > Mike > > On Tue, Sep 24, 2024 at 9:28 AM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > >> +1 to try. >> >> Especially if the attempt includes the "exempt PR" label feature that >> Eric linked to. I'd use that pretty frequently in my workflow, as I >> often push code for feedback without knowing exactly when I'll be able >> to return to it and get it "over the finish line". >> >> On Mon, Sep 23, 2024 at 10:46 AM David Smiley <dsmi...@apache.org> wrote: >>> >>> +1 to try >>> >>> On Sun, Sep 22, 2024 at 3:43 PM Jan Høydahl <jan....@cominvent.com> >> wrote: >>> >>>> +1 to try. >>>> >>>> 60 days for stale and another 60 days before close should be enough >> imo. >>>> >>>> We can set the ‘close-pr-label’ for easier reference of what prs were >> auto >>>> closed, should anyone wish to do archeology or re-open stuff that >> obviously >>>> went below people’s radar despite two notifications to the list. >>>> >>>> Jan Høydahl >>>> >>>>> On 22 Sep 2024, at 15:11, Eric Pugh <de...@yahoo.com.invalid> wrote: >>>>> >>>>> What if we tried it for a few months and then reevaluated? >>>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Sep 20, 2024, at 3:02 PM, Jan Høydahl <jan....@cominvent.com> >> wrote: >>>>>> >>>>>> Any commit or comment on a stale PR will make it un-stale for 60 >> more >>>> days too. >>>>>> >>>>>> Jan Høydahl >>>>>> >>>>>>>> On 19 Sep 2024, at 23:14, David Smiley <dsmi...@apache.org> >> wrote: >>>>>>> >>>>>>> Upon seeing a "stale" warning, how do I signal to the bot that >> this PR >>>>>>> shouldn't be closed soon? Or perhaps upon re-opening, the bot >> ought to >>>>>>> back off on this one forevermore? >>>>>>> >>>>>>>>> On Thu, Sep 19, 2024 at 3:06 PM Jan Høydahl < >> jan....@cominvent.com> >>>> wrote: >>>>>>>> >>>>>>>> +1 I’ve tried suggesting this several times, also for abandoned >> JIRA >>>>>>>> issues, but always big pushback. >>>>>>>> >>>>>>>> If we get a stale warning and then, if no one cares, another >>>> notification >>>>>>>> when auto-closing, no one can say they were not warned. And old >>>> closed PRs >>>>>>>> can always be re-opened, but at that point there will be so many >> merge >>>>>>>> conflicts so who’d want to anyway? 😉 >>>>>>>> >>>>>>>> Jan Høydahl >>>>>>>> >>>>>>>>>> On 19 Sep 2024, at 20:07, David Smiley <dsmi...@apache.org> >> wrote: >>>>>>>>> >>>>>>>>> I don't see in the dev list here a discussion on auto-closing >> old >>>> PRs >>>>>>>> but >>>>>>>>> FWIW I'm in favor of that provided we could somehow choose to >> keep a >>>> PR >>>>>>>>> open that we're still passionate about, that we don't want to be >>>>>>>>> forgotten. This was discussed in the meetup yesterday. >>>>>>>>> >>>>>>>>>> On Fri, Jan 26, 2024 at 10:56 AM Eric Pugh < >>>>>>>> ep...@opensourceconnections.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> When I picked up https://github.com/apache/solr/pull/2225 it >> was >>>> cool >>>>>>>> to >>>>>>>>>> see the “start-script” label! Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On Jan 26, 2024, at 10:33 AM, Jan Høydahl < >> jan....@cominvent.com> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> The StaleBot is now active, running once a day at midnight. >>>>>>>>>>> I started in a conservative way, only labeling 10 PRs a day, >> and >>>>>>>> setting >>>>>>>>>> the threshold at 60 days. >>>>>>>>>>> This gives us some time to evaluate without labeling the entire >>>>>>>> backlog. >>>>>>>>>>> Will be interesting to see whether the Bot results in some >>>> fogotten PRs >>>>>>>>>> being completed. >>>>>>>>>>> >>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>>>>> 8. jan. 2024 kl. 23:10 skrev Jan Høydahl < >> jan....@cominvent.com>: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Got some initial (positive) feedback on the >> auto-categorization >>>> PR and >>>>>>>>>> plan to merge on Thursday, giving you some more time to review. >> I >>>> feel I >>>>>>>>>> have not 100% nailed perfect labels. Obviously we can't auto >> label >>>>>>>> things >>>>>>>>>> like feature/bug, or versions, so this is only a "category". >> Ideally >>>>>>>> there >>>>>>>>>> would be a a 1:1 between these "category" labels and the >>>> "Components" >>>>>>>>>> defined in JIRA. But here are 96 different "Components" there, >> most >>>> of >>>>>>>> them >>>>>>>>>> are old/irrelevant and not always very good IMO. So I'd rather >>>> attempt >>>>>>>> to >>>>>>>>>> align JIRA components with whatever we come up with here... >>>>>>>>>>>> >>>>>>>>>>>> Lucene has just put their StaleBot to work, and I created >>>>>>>>>> https://github.com/apache/solr/pull/2184 to do the same for >> Solr. >>>> Have >>>>>>>> a >>>>>>>>>> look. >>>>>>>>>>>> >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>>>> 6. jan. 2024 kl. 01:21 skrev Jan Høydahl < >> jan....@cominvent.com >>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> We tend to not use the GitHub's PR labels we have defined. >>>>>>>>>>>>> So I whipped up https://github.com/apache/solr/pull/2180 >> which >>>> is >>>>>>>>>> configured to auto-label PRs based on what files are changed. >>>> Feedback >>>>>>>>>> welcome. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, I hope we can implement StaleBot for labeling PRs as >> stale. >>>>>>>>>> Lucene is going to test it, see >>>>>>>>>> https://github.com/apache/lucene/pull/12813. If that goes well, >>>> let's >>>>>>>>>> copy their config :) >>>>>>>>>>>>> >>>>>>>>>>>>> - Jan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________ >>>>>>>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | >>>> 434.466.1467 | >>>>>>>>>> http://www.opensourceconnections.com < >>>>>>>>>> http://www.opensourceconnections.com/> | My Free/Busy < >>>>>>>>>> http://tinyurl.com/eric-cal> >>>>>>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >>>>>>>>>> >>>>>>>> >>>> >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>>>>>>>> >>>>>>>>>> >>>>>>>>>> This e-mail and all contents, including attachments, is >> considered >>>> to be >>>>>>>>>> Company Confidential unless explicitly stated otherwise, >> regardless >>>> of >>>>>>>>>> whether attachments are marked as such. >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>>> >>>>>>>> >>>>>> >>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
