+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
