+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
