It was both great and sad to see a bunch of PR's closed. I looked through, and there looked to be some nice fixes to various tests that are a shame to not get to done. On the other hand being open means they didn't get to done either! I like the "close-stale" label, this could let someone splunk around looking for some PR's that may be close but never quite ready to merge that could be completed.
I think this is a good step. On 2024/09/29 21:43:32 Jan Høydahl wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
