+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 > >
