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