You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Mike Drob <md...@mdrob.com> on 2021/11/29 19:45:04 UTC
Closing GitHub PRs
We currently have almost 300 open PRs against the "master" branch in the
old lucene-solr repo.
https://github.com/apache/lucene-solr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster
I think we should close all of them (possibly with a comment pointing
people to the main branch in the lucene or solr repos).
I do not know if there is an automated way to do this, or a way to do this
without spamming everybody's email lists. If there is consensus on this
clean up work then I'll take some time to investigate how to get this done
and/or chat with ASF Infra about it.
Thanks,
Mike
Re: Closing GitHub PRs
Posted by David Smiley <ds...@apache.org>.
I prefer to not auto-close anything. An issue that's open forever doesn't
seem to be harmful. That said, I don't feel strongly enough to veto
whatever the consensus is. I love the bulk-comment proposal!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Dec 8, 2021 at 11:40 AM Michael McCandless <
lucene@mikemccandless.com> wrote:
> I think the script is already proving helpful, finding PRs whose
> corresponding issues were closed. I guess it is possible that some of
> those PRs might still be relevant, but likely most of them should be
> closed? This seems helpful. I spot checked a couple of these. One of
> them indeed looked like it was merged
> <https://github.com/apache/lucene-solr/pull/1064>, so I closed it with a
> comment. But the second one I checked
> <https://github.com/apache/lucene-solr/pull/906/files> looked like the src
> changes were merged but maybe the unit test in the PR failed to be merged
> <https://github.com/apache/lucene/commit/49631ace9f1ee110d52a207377e4926baef74929>
> ?
>
> And the script can be used to bulk-add comments. I'm still +1 on that.
>
> But I really don't want to bulk-close all of the PRs. That just makes
> these artifacts harder to find in the future. Some of them are still
> relevant. I just poked around a bit and found this still-open PR from
> Simon <https://github.com/apache/lucene-solr/pull/1925> which is/was a
> nice cleanup, from ~ one year ago now, of how DocumentsWriterPerThread
> tracks its (tricky!) lifecycle. There are important changes in these
> still-open PRs, so I really don't think we should close them. Maybe Simon
> or Nhat or myself comes back and cracks the rust off of this PR.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Dec 8, 2021 at 8:57 AM Robert Muir <rc...@gmail.com> wrote:
>
>> I'm also now even -1 against bulk-comment. You guys are trying to be
>> too sneaky/passive-aggressive/bypass consensus. I'm stopping this shit
>> right now in its tracks
>>
>> On Wed, Dec 8, 2021 at 8:50 AM Robert Muir <rc...@gmail.com> wrote:
>> >
>> > I'm -1 against auto-closing issues, as I already stated on this thread.
>> >
>> > On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl <ja...@cominvent.com>
>> wrote:
>> > >
>> > > Calm down :)
>> > >
>> > > As you can read from the last comment, we can choose whether to
>> > > * Close with comment and label
>> > > * Comment and label only
>> > > * Comment only
>> > > * Do nothing
>> > >
>> > > The lucene-solr repo is not dead, it will still be used for
>> back-porting bugfixes to branch_8_11 for probably another 12 months.
>> > > Byt several branches are dead/archived, and it really makes no sense
>> to keep PRs for those alive either.
>> > >
>> > > This is a proposal for a one-time action, introducing a stale-bot for
>> the project, which I can see is more controversial and annoying for sure.
>> > >
>> > > Jan
>> > >
>> > > > 8. des. 2021 kl. 13:04 skrev Robert Muir <rc...@gmail.com>:
>> > > >
>> > > > i mean you dont even have anything close to fucking consensus about
>> > > > "bulk close" on this thread. most are against it. why be so fucking
>> > > > sneaky about it? I don't get it!
>> > > >
>> > > > On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rc...@gmail.com>
>> wrote:
>> > > >>
>> > > >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rc...@gmail.com>
>> wrote:
>> > > >>>
>> > > >>> I added my vote against bulk close functionality.
>> > > >>> it is pretty clear from this thread that several of us are
>> opposed to
>> > > >>> bulk close.
>> > > >>>
>> > > >>> somehow the discussion jumped from bulk commenting to bulk close.
>> fuck that!
>> > > >>>
>> > > >>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <ja...@cominvent.com>
>> wrote:
>> > > >>>>
>> > > >>>> I gave it a shot, and it works, so with this change to
>> githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we
>> can close all open PRs with a comment and label with a single command. The
>> script can also easily be adapted to other use cases.
>> > > >>>>
>> > > >>>> Jan
>> > > >>>>
>> > > >>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com
>> >:
>> > > >>>>>
>> > > >>>>> +1 to bulk commenting on the 274 open PRs with a standard
>> message about the need for new PRs.
>> > > >>>>> We already have a "stale-closed" label in GitHub, so if we add
>> that label to all the issues they can safely be closed without information
>> loss.
>> > > >>>>> My script
>> https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py
>> can probably be tweaked to do these actions. It uses a python GitHub
>> library and already fetches all open PRs, and allows to pass a token, so I
>> guess that the token will also allow edits on behalf of the user.
>> > > >>>>>
>> > > >>>>> Jan
>> > > >>>>>
>> > > >>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <
>> msokolov@gmail.com>:
>> > > >>>>>>
>> > > >>>>>> In this specific instance, I don't see the harm in leaving
>> these
>> > > >>>>>> issues there since the entire repo is essentially an archival
>> artifact
>> > > >>>>>> at this point. If we actually want to notify people that "hey
>> your
>> > > >>>>>> issue is in a dead zone, do you want to revive it? Here's how
>> ..." we
>> > > >>>>>> could maybe generate some emails? Although I really have no
>> idea how
>> > > >>>>>> we would accomplish that.
>> > > >>>>>>
>> > > >>>>>> In general, I'm in favor of cleaning up / closing issues that
>> are
>> > > >>>>>> clearly not going to be worked.
>> > > >>>>>>
>> > > >>>>>> For example in JIRA we have so many old issues that they can
>> clutter
>> > > >>>>>> up search results, making it much harder for new contributors
>> > > >>>>>> (especially) to find "interesting" issues that might be
>> relevant today
>> > > >>>>>> and workable. I have heard various arguments for keeping
>> these old
>> > > >>>>>> issues: they represent an historical view of the project; "you
>> never
>> > > >>>>>> know" maybe they become relevant again; and this idea of not
>> annoying
>> > > >>>>>> people by arbitrarily closing their issue. These all have some
>> > > >>>>>> validity, but I we have to strike a balance. I wonder if we can
>> > > >>>>>> address them in another way. In JIRA can we keep these old
>> issues
>> > > >>>>>> while hiding them from default searches. Can we "archive" old
>> issues
>> > > >>>>>> in some way? Maybe there is a "Status" like Archived that is
>> different
>> > > >>>>>> from Closed. Anything but Open!
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com>
>> wrote:
>> > > >>>>>>>
>> > > >>>>>>> I understand the frustrations around closing somebody’s PR as
>> stale, but I also think that there is value in informing the contributors I
>> this is never getting solved/fixed/looked at, if this is still important
>> please go over there instead.
>> > > >>>>>>>
>> > > >>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com>
>> wrote:
>> > > >>>>>>>>
>> > > >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>> > > >>>>>>>> <lu...@mikemccandless.com> wrote:
>> > > >>>>>>>>>
>> > > >>>>>>>>> Could we maybe instead bulk-add a comment explaining the
>> split and how to take the PR forwards if someone (in the future) has
>> itch/time?
>> > > >>>>>>>>>
>> > > >>>>>>>>> I know we humans love to clean things up, but I think
>> leaving such "unclean" things open serves an important purpose. They all
>> had importance to at least one person at one point in time, and likely many
>> of them are still relevant if they piqued someones curiosity to dig back
>> into them. Closing them makes them harder to find for the future developer.
>> > > >>>>>>>>>
>> > > >>>>>>>>> I'm sure some of them are already resolved/duplicates too.
>> If only we could divine which are which.
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by
>> this when
>> > > >>>>>>>> I see it in other trackers. Is there a rush to close these
>> for some
>> > > >>>>>>>> reason?
>> > > >>>>>>>>
>> > > >>>>>>>>
>> ---------------------------------------------------------------------
>> > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>>>>>>
>> > > >>>>>>
>> > > >>>>>>
>> ---------------------------------------------------------------------
>> > > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> ---------------------------------------------------------------------
>> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>>
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Closing GitHub PRs
Posted by Michael McCandless <lu...@mikemccandless.com>.
I think the script is already proving helpful, finding PRs whose
corresponding issues were closed. I guess it is possible that some of
those PRs might still be relevant, but likely most of them should be
closed? This seems helpful. I spot checked a couple of these. One of
them indeed looked like it was merged
<https://github.com/apache/lucene-solr/pull/1064>, so I closed it with a
comment. But the second one I checked
<https://github.com/apache/lucene-solr/pull/906/files> looked like the src
changes were merged but maybe the unit test in the PR failed to be merged
<https://github.com/apache/lucene/commit/49631ace9f1ee110d52a207377e4926baef74929>
?
And the script can be used to bulk-add comments. I'm still +1 on that.
But I really don't want to bulk-close all of the PRs. That just makes
these artifacts harder to find in the future. Some of them are still
relevant. I just poked around a bit and found this still-open PR from Simon
<https://github.com/apache/lucene-solr/pull/1925> which is/was a nice
cleanup, from ~ one year ago now, of how DocumentsWriterPerThread tracks
its (tricky!) lifecycle. There are important changes in these still-open
PRs, so I really don't think we should close them. Maybe Simon or Nhat or
myself comes back and cracks the rust off of this PR.
Mike McCandless
http://blog.mikemccandless.com
On Wed, Dec 8, 2021 at 8:57 AM Robert Muir <rc...@gmail.com> wrote:
> I'm also now even -1 against bulk-comment. You guys are trying to be
> too sneaky/passive-aggressive/bypass consensus. I'm stopping this shit
> right now in its tracks
>
> On Wed, Dec 8, 2021 at 8:50 AM Robert Muir <rc...@gmail.com> wrote:
> >
> > I'm -1 against auto-closing issues, as I already stated on this thread.
> >
> > On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl <ja...@cominvent.com>
> wrote:
> > >
> > > Calm down :)
> > >
> > > As you can read from the last comment, we can choose whether to
> > > * Close with comment and label
> > > * Comment and label only
> > > * Comment only
> > > * Do nothing
> > >
> > > The lucene-solr repo is not dead, it will still be used for
> back-porting bugfixes to branch_8_11 for probably another 12 months.
> > > Byt several branches are dead/archived, and it really makes no sense
> to keep PRs for those alive either.
> > >
> > > This is a proposal for a one-time action, introducing a stale-bot for
> the project, which I can see is more controversial and annoying for sure.
> > >
> > > Jan
> > >
> > > > 8. des. 2021 kl. 13:04 skrev Robert Muir <rc...@gmail.com>:
> > > >
> > > > i mean you dont even have anything close to fucking consensus about
> > > > "bulk close" on this thread. most are against it. why be so fucking
> > > > sneaky about it? I don't get it!
> > > >
> > > > On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rc...@gmail.com> wrote:
> > > >>
> > > >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rc...@gmail.com>
> wrote:
> > > >>>
> > > >>> I added my vote against bulk close functionality.
> > > >>> it is pretty clear from this thread that several of us are opposed
> to
> > > >>> bulk close.
> > > >>>
> > > >>> somehow the discussion jumped from bulk commenting to bulk close.
> fuck that!
> > > >>>
> > > >>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <ja...@cominvent.com>
> wrote:
> > > >>>>
> > > >>>> I gave it a shot, and it works, so with this change to
> githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we
> can close all open PRs with a comment and label with a single command. The
> script can also easily be adapted to other use cases.
> > > >>>>
> > > >>>> Jan
> > > >>>>
> > > >>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com
> >:
> > > >>>>>
> > > >>>>> +1 to bulk commenting on the 274 open PRs with a standard
> message about the need for new PRs.
> > > >>>>> We already have a "stale-closed" label in GitHub, so if we add
> that label to all the issues they can safely be closed without information
> loss.
> > > >>>>> My script
> https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py
> can probably be tweaked to do these actions. It uses a python GitHub
> library and already fetches all open PRs, and allows to pass a token, so I
> guess that the token will also allow edits on behalf of the user.
> > > >>>>>
> > > >>>>> Jan
> > > >>>>>
> > > >>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <
> msokolov@gmail.com>:
> > > >>>>>>
> > > >>>>>> In this specific instance, I don't see the harm in leaving these
> > > >>>>>> issues there since the entire repo is essentially an archival
> artifact
> > > >>>>>> at this point. If we actually want to notify people that "hey
> your
> > > >>>>>> issue is in a dead zone, do you want to revive it? Here's how
> ..." we
> > > >>>>>> could maybe generate some emails? Although I really have no
> idea how
> > > >>>>>> we would accomplish that.
> > > >>>>>>
> > > >>>>>> In general, I'm in favor of cleaning up / closing issues that
> are
> > > >>>>>> clearly not going to be worked.
> > > >>>>>>
> > > >>>>>> For example in JIRA we have so many old issues that they can
> clutter
> > > >>>>>> up search results, making it much harder for new contributors
> > > >>>>>> (especially) to find "interesting" issues that might be
> relevant today
> > > >>>>>> and workable. I have heard various arguments for keeping these
> old
> > > >>>>>> issues: they represent an historical view of the project; "you
> never
> > > >>>>>> know" maybe they become relevant again; and this idea of not
> annoying
> > > >>>>>> people by arbitrarily closing their issue. These all have some
> > > >>>>>> validity, but I we have to strike a balance. I wonder if we can
> > > >>>>>> address them in another way. In JIRA can we keep these old
> issues
> > > >>>>>> while hiding them from default searches. Can we "archive" old
> issues
> > > >>>>>> in some way? Maybe there is a "Status" like Archived that is
> different
> > > >>>>>> from Closed. Anything but Open!
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com>
> wrote:
> > > >>>>>>>
> > > >>>>>>> I understand the frustrations around closing somebody’s PR as
> stale, but I also think that there is value in informing the contributors I
> this is never getting solved/fixed/looked at, if this is still important
> please go over there instead.
> > > >>>>>>>
> > > >>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com>
> wrote:
> > > >>>>>>>>
> > > >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> > > >>>>>>>> <lu...@mikemccandless.com> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> Could we maybe instead bulk-add a comment explaining the
> split and how to take the PR forwards if someone (in the future) has
> itch/time?
> > > >>>>>>>>>
> > > >>>>>>>>> I know we humans love to clean things up, but I think
> leaving such "unclean" things open serves an important purpose. They all
> had importance to at least one person at one point in time, and likely many
> of them are still relevant if they piqued someones curiosity to dig back
> into them. Closing them makes them harder to find for the future developer.
> > > >>>>>>>>>
> > > >>>>>>>>> I'm sure some of them are already resolved/duplicates too.
> If only we could divine which are which.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by
> this when
> > > >>>>>>>> I see it in other trackers. Is there a rush to close these
> for some
> > > >>>>>>>> reason?
> > > >>>>>>>>
> > > >>>>>>>>
> ---------------------------------------------------------------------
> > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>>
> ---------------------------------------------------------------------
> > > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Closing GitHub PRs
Posted by Robert Muir <rc...@gmail.com>.
I'm also now even -1 against bulk-comment. You guys are trying to be
too sneaky/passive-aggressive/bypass consensus. I'm stopping this shit
right now in its tracks
On Wed, Dec 8, 2021 at 8:50 AM Robert Muir <rc...@gmail.com> wrote:
>
> I'm -1 against auto-closing issues, as I already stated on this thread.
>
> On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl <ja...@cominvent.com> wrote:
> >
> > Calm down :)
> >
> > As you can read from the last comment, we can choose whether to
> > * Close with comment and label
> > * Comment and label only
> > * Comment only
> > * Do nothing
> >
> > The lucene-solr repo is not dead, it will still be used for back-porting bugfixes to branch_8_11 for probably another 12 months.
> > Byt several branches are dead/archived, and it really makes no sense to keep PRs for those alive either.
> >
> > This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
> >
> > Jan
> >
> > > 8. des. 2021 kl. 13:04 skrev Robert Muir <rc...@gmail.com>:
> > >
> > > i mean you dont even have anything close to fucking consensus about
> > > "bulk close" on this thread. most are against it. why be so fucking
> > > sneaky about it? I don't get it!
> > >
> > > On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rc...@gmail.com> wrote:
> > >>
> > >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rc...@gmail.com> wrote:
> > >>>
> > >>> I added my vote against bulk close functionality.
> > >>> it is pretty clear from this thread that several of us are opposed to
> > >>> bulk close.
> > >>>
> > >>> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
> > >>>
> > >>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <ja...@cominvent.com> wrote:
> > >>>>
> > >>>> I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
> > >>>>
> > >>>> Jan
> > >>>>
> > >>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <ja...@cominvent.com>:
> > >>>>>
> > >>>>> +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> > >>>>> We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> > >>>>> My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> > >>>>>
> > >>>>> Jan
> > >>>>>
> > >>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <ms...@gmail.com>:
> > >>>>>>
> > >>>>>> In this specific instance, I don't see the harm in leaving these
> > >>>>>> issues there since the entire repo is essentially an archival artifact
> > >>>>>> at this point. If we actually want to notify people that "hey your
> > >>>>>> issue is in a dead zone, do you want to revive it? Here's how ..." we
> > >>>>>> could maybe generate some emails? Although I really have no idea how
> > >>>>>> we would accomplish that.
> > >>>>>>
> > >>>>>> In general, I'm in favor of cleaning up / closing issues that are
> > >>>>>> clearly not going to be worked.
> > >>>>>>
> > >>>>>> For example in JIRA we have so many old issues that they can clutter
> > >>>>>> up search results, making it much harder for new contributors
> > >>>>>> (especially) to find "interesting" issues that might be relevant today
> > >>>>>> and workable. I have heard various arguments for keeping these old
> > >>>>>> issues: they represent an historical view of the project; "you never
> > >>>>>> know" maybe they become relevant again; and this idea of not annoying
> > >>>>>> people by arbitrarily closing their issue. These all have some
> > >>>>>> validity, but I we have to strike a balance. I wonder if we can
> > >>>>>> address them in another way. In JIRA can we keep these old issues
> > >>>>>> while hiding them from default searches. Can we "archive" old issues
> > >>>>>> in some way? Maybe there is a "Status" like Archived that is different
> > >>>>>> from Closed. Anything but Open!
> > >>>>>>
> > >>>>>>
> > >>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
> > >>>>>>>
> > >>>>>>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> > >>>>>>>
> > >>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
> > >>>>>>>>
> > >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> > >>>>>>>> <lu...@mikemccandless.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> > >>>>>>>>>
> > >>>>>>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> > >>>>>>>>>
> > >>>>>>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> > >>>>>>>> I see it in other trackers. Is there a rush to close these for some
> > >>>>>>>> reason?
> > >>>>>>>>
> > >>>>>>>> ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>>>>>
> > >>>>>>
> > >>>>>> ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Robert Muir <rc...@gmail.com>.
I'm -1 against auto-closing issues, as I already stated on this thread.
On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl <ja...@cominvent.com> wrote:
>
> Calm down :)
>
> As you can read from the last comment, we can choose whether to
> * Close with comment and label
> * Comment and label only
> * Comment only
> * Do nothing
>
> The lucene-solr repo is not dead, it will still be used for back-porting bugfixes to branch_8_11 for probably another 12 months.
> Byt several branches are dead/archived, and it really makes no sense to keep PRs for those alive either.
>
> This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
>
> Jan
>
> > 8. des. 2021 kl. 13:04 skrev Robert Muir <rc...@gmail.com>:
> >
> > i mean you dont even have anything close to fucking consensus about
> > "bulk close" on this thread. most are against it. why be so fucking
> > sneaky about it? I don't get it!
> >
> > On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rc...@gmail.com> wrote:
> >>
> >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rc...@gmail.com> wrote:
> >>>
> >>> I added my vote against bulk close functionality.
> >>> it is pretty clear from this thread that several of us are opposed to
> >>> bulk close.
> >>>
> >>> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
> >>>
> >>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <ja...@cominvent.com> wrote:
> >>>>
> >>>> I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
> >>>>
> >>>> Jan
> >>>>
> >>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <ja...@cominvent.com>:
> >>>>>
> >>>>> +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> >>>>> We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> >>>>> My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> >>>>>
> >>>>> Jan
> >>>>>
> >>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <ms...@gmail.com>:
> >>>>>>
> >>>>>> In this specific instance, I don't see the harm in leaving these
> >>>>>> issues there since the entire repo is essentially an archival artifact
> >>>>>> at this point. If we actually want to notify people that "hey your
> >>>>>> issue is in a dead zone, do you want to revive it? Here's how ..." we
> >>>>>> could maybe generate some emails? Although I really have no idea how
> >>>>>> we would accomplish that.
> >>>>>>
> >>>>>> In general, I'm in favor of cleaning up / closing issues that are
> >>>>>> clearly not going to be worked.
> >>>>>>
> >>>>>> For example in JIRA we have so many old issues that they can clutter
> >>>>>> up search results, making it much harder for new contributors
> >>>>>> (especially) to find "interesting" issues that might be relevant today
> >>>>>> and workable. I have heard various arguments for keeping these old
> >>>>>> issues: they represent an historical view of the project; "you never
> >>>>>> know" maybe they become relevant again; and this idea of not annoying
> >>>>>> people by arbitrarily closing their issue. These all have some
> >>>>>> validity, but I we have to strike a balance. I wonder if we can
> >>>>>> address them in another way. In JIRA can we keep these old issues
> >>>>>> while hiding them from default searches. Can we "archive" old issues
> >>>>>> in some way? Maybe there is a "Status" like Archived that is different
> >>>>>> from Closed. Anything but Open!
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
> >>>>>>>
> >>>>>>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> >>>>>>>
> >>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> >>>>>>>> <lu...@mikemccandless.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> >>>>>>>>>
> >>>>>>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> >>>>>>>>>
> >>>>>>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> >>>>>>>> I see it in other trackers. Is there a rush to close these for some
> >>>>>>>> reason?
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Jan Høydahl <ja...@cominvent.com>.
The same script githubPRs.py also tells us which PRs are linked to an already closed JIRA, which are clear candidates for closing
Open PRs with a resolved JIRA
#182: SOLR-10415 status=Closed, resolution=Fixed, resolutiondate=2020-05-01T17:19:28.000+0000 (SOLR-10415 - improve debug logging to use parameterized logging)
#185: SOLR-10487 status=Resolved, resolution=Won't Fix, resolutiondate=2020-08-29T20:04:17.000+0000 (SOLR-10487: Support to specify connection and socket read timeout in DataImportHandler for SolrEntityProcessor.)
#210: SOLR-10814 status=Resolved, resolution=Fixed, resolutiondate=2020-07-08T15:27:13.000+0000 ([SOLR-10814] Solr RuleBasedAuthorizationPlugin works seamlessly with …)
#690: SOLR-13517 status=Resolved, resolution=Duplicate, resolutiondate=2021-08-18T21:34:14.000+0000 (SOLR-13517: [ UX improvement ] Dashboard will now store query and filter parameters on page change a…)
#740: SOLR-12550 status=Closed, resolution=Fixed, resolutiondate=2020-02-20T12:57:57.000+0000 (SOLR-12550 - distribUpdateSoTimeout for configuring socket timeouts in solrcloud doesn't take effect for updates.)
#864: SOLR-13101 status=Resolved, resolution=Won't Fix, resolutiondate=2020-12-11T03:20:31.000+0000 (SOLR-13101 : Shared storage support in SolrCloud)
#888: SOLR-13774 status=Resolved, resolution=Won't Fix, resolutiondate=2020-03-30T01:15:59.000+0000 (SOLR-13774 add lucene/solr openjdk compatibility matrix to ref guide.)
#906: LUCENE-8996 status=Closed, resolution=Fixed, resolutiondate=2019-12-09T14:59:16.000+0000 (LUCENE-8996: maxScore is sometimes missing from distributed responses)
#1060: SOLR-14024 status=Resolved, resolution=Fixed, resolutiondate=2021-03-24T18:25:12.000+0000 (SOLR-14024: Invalid html generated by changes2html.pl)
#1064: LUCENE-9084 status=Closed, resolution=Fixed, resolutiondate=2020-01-09T00:45:51.000+0000 (LUCENE-9084: circular synchronization wait (potential deadlock) in AnalyzingInfixSuggester)
#1079: SOLR-14067 status=Resolved, resolution=Fixed, resolutiondate=2021-02-04T16:32:52.000+0000 (SOLR-14067: StatelessScriptUpdateProcessor removal due to security concerns)
#1144: SOLR-13756 status=Closed, resolution=Not A Problem, resolutiondate=2021-01-18T12:36:38.000+0000 (SOLR-13756 updated restlet mvn repository url.)
#1175: SOLR-13749 status=Closed, resolution=Fixed, resolutiondate=2020-06-25T16:57:48.000+0000 (Backport SOLR-13749 Cross-collection join filter to 8.x)
#1231: SOLR-13132 status=Closed, resolution=Fixed, resolutiondate=2020-07-10T04:06:30.000+0000 (SOLR-13132: single sweep iteration over base, foreground, and backgro…)
#1383: SOLR-14367 status=Closed, resolution=Fixed, resolutiondate=2020-03-29T13:41:12.000+0000 (SOLR-14367: Updated Tika version to 1.24)
#1386: SOLR-14275 status=Resolved, resolution=Won't Fix, resolutiondate=2020-11-11T12:50:52.000+0000 (SOLR-14275 Policy calculations are very slow for large clusters and large operations)
#1622: SOLR-14603 status=Closed, resolution=Fixed, resolutiondate=2020-07-04T11:59:17.000+0000 (SOLR-14603: update Restlet version )
#1721: LUCENE-9439 status=Resolved, resolution=Duplicate, resolutiondate=2020-08-14T09:05:58.000+0000 (LUCENE-9439: match region highlighter components)
#1744: SOLR-14731 status=Closed, resolution=Fixed, resolutiondate=2020-08-18T10:55:48.000+0000 (SOLR-14731: Add SingleThreaded Annotation to Class)
#1768: LUCENE-9472 status=Resolved, resolution=Workaround, resolutiondate=2020-08-20T15:13:48.000+0000 (LUCENE-9472: Test duplication within gradle's infrastructure.)
#1784: LUCENE-9482 status=Closed, resolution=Fixed, resolutiondate=2020-09-06T15:16:45.000+0000 (LUCENE-9482: There is a problem with the description of "invalid deletion count" exception.)
#1827: SOLR-14792 status=Resolved, resolution=Fixed, resolutiondate=2021-02-15T18:22:53.000+0000 (SOLR-14792: Remove VelocityResponseWriter)
#1923: SOLR-14900 status=Resolved, resolution=Fixed, resolutiondate=2021-07-21T18:43:01.000+0000 (SOLR-14900: Reference Guide build cleanup/module upgrade)
#1957: SOLR-14918 status=Resolved, resolution=Won't Fix, resolutiondate=2020-10-13T19:08:35.000+0000 (SOLR-14918 add "failIfEmptyCores" param for healthcheck handler)
#2080: LUCENE-8947 status=Resolved, resolution=Won't Fix, resolutiondate=2021-01-16T12:14:35.000+0000 (LUCENE-8947: Skip field length accumulation when norms are disabled)
#2100: LUCENE-9047 status=Resolved, resolution=Fixed, resolutiondate=2021-05-03T05:50:21.000+0000 (LUCENE-9047: PoC of some ideas regarding transparent, efficient handling of byte order )
#2244: SOLR-15099 status=Resolved, resolution=Won't Fix, resolutiondate=2021-08-14T01:41:33.000+0000 (SOLR-15099 Add null checks to IndexSizeTrigger)
#2252: SOLR-15111 status=Resolved, resolution=Fixed, resolutiondate=2021-08-31T14:03:53.000+0000 (SOLR-15111: Use JDK8 Base64 instead of own implementation)
#2415: SOLR-15178 status=Resolved, resolution=Fixed, resolutiondate=2021-03-19T07:21:16.000+0000 (SOLR-15178 Non-existent dependency listed in solr-core)
Jan
> 8. des. 2021 kl. 13:55 skrev Jan Høydahl <ja...@cominvent.com>:
>
>> This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
>
> Correction: This is a proposal for a one-time action, NOT introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Jan Høydahl <ja...@cominvent.com>.
> This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
Correction: This is a proposal for a one-time action, NOT introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Jan Høydahl <ja...@cominvent.com>.
Calm down :)
As you can read from the last comment, we can choose whether to
* Close with comment and label
* Comment and label only
* Comment only
* Do nothing
The lucene-solr repo is not dead, it will still be used for back-porting bugfixes to branch_8_11 for probably another 12 months.
Byt several branches are dead/archived, and it really makes no sense to keep PRs for those alive either.
This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
Jan
> 8. des. 2021 kl. 13:04 skrev Robert Muir <rc...@gmail.com>:
>
> i mean you dont even have anything close to fucking consensus about
> "bulk close" on this thread. most are against it. why be so fucking
> sneaky about it? I don't get it!
>
> On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rc...@gmail.com> wrote:
>>
>> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rc...@gmail.com> wrote:
>>>
>>> I added my vote against bulk close functionality.
>>> it is pretty clear from this thread that several of us are opposed to
>>> bulk close.
>>>
>>> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
>>>
>>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <ja...@cominvent.com> wrote:
>>>>
>>>> I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
>>>>
>>>> Jan
>>>>
>>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <ja...@cominvent.com>:
>>>>>
>>>>> +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
>>>>> We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
>>>>> My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
>>>>>
>>>>> Jan
>>>>>
>>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <ms...@gmail.com>:
>>>>>>
>>>>>> In this specific instance, I don't see the harm in leaving these
>>>>>> issues there since the entire repo is essentially an archival artifact
>>>>>> at this point. If we actually want to notify people that "hey your
>>>>>> issue is in a dead zone, do you want to revive it? Here's how ..." we
>>>>>> could maybe generate some emails? Although I really have no idea how
>>>>>> we would accomplish that.
>>>>>>
>>>>>> In general, I'm in favor of cleaning up / closing issues that are
>>>>>> clearly not going to be worked.
>>>>>>
>>>>>> For example in JIRA we have so many old issues that they can clutter
>>>>>> up search results, making it much harder for new contributors
>>>>>> (especially) to find "interesting" issues that might be relevant today
>>>>>> and workable. I have heard various arguments for keeping these old
>>>>>> issues: they represent an historical view of the project; "you never
>>>>>> know" maybe they become relevant again; and this idea of not annoying
>>>>>> people by arbitrarily closing their issue. These all have some
>>>>>> validity, but I we have to strike a balance. I wonder if we can
>>>>>> address them in another way. In JIRA can we keep these old issues
>>>>>> while hiding them from default searches. Can we "archive" old issues
>>>>>> in some way? Maybe there is a "Status" like Archived that is different
>>>>>> from Closed. Anything but Open!
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
>>>>>>>
>>>>>>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
>>>>>>>
>>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>>>>>>>> <lu...@mikemccandless.com> wrote:
>>>>>>>>>
>>>>>>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>>>>>>>>>
>>>>>>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>>>>>>>>>
>>>>>>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>>>>>>>> I see it in other trackers. Is there a rush to close these for some
>>>>>>>> reason?
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Robert Muir <rc...@gmail.com>.
i mean you dont even have anything close to fucking consensus about
"bulk close" on this thread. most are against it. why be so fucking
sneaky about it? I don't get it!
On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rc...@gmail.com> wrote:
>
> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rc...@gmail.com> wrote:
> >
> > I added my vote against bulk close functionality.
> > it is pretty clear from this thread that several of us are opposed to
> > bulk close.
> >
> > somehow the discussion jumped from bulk commenting to bulk close. fuck that!
> >
> > On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <ja...@cominvent.com> wrote:
> > >
> > > I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
> > >
> > > Jan
> > >
> > > > 8. des. 2021 kl. 01:33 skrev Jan Høydahl <ja...@cominvent.com>:
> > > >
> > > > +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> > > > We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> > > > My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> > > >
> > > > Jan
> > > >
> > > >> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <ms...@gmail.com>:
> > > >>
> > > >> In this specific instance, I don't see the harm in leaving these
> > > >> issues there since the entire repo is essentially an archival artifact
> > > >> at this point. If we actually want to notify people that "hey your
> > > >> issue is in a dead zone, do you want to revive it? Here's how ..." we
> > > >> could maybe generate some emails? Although I really have no idea how
> > > >> we would accomplish that.
> > > >>
> > > >> In general, I'm in favor of cleaning up / closing issues that are
> > > >> clearly not going to be worked.
> > > >>
> > > >> For example in JIRA we have so many old issues that they can clutter
> > > >> up search results, making it much harder for new contributors
> > > >> (especially) to find "interesting" issues that might be relevant today
> > > >> and workable. I have heard various arguments for keeping these old
> > > >> issues: they represent an historical view of the project; "you never
> > > >> know" maybe they become relevant again; and this idea of not annoying
> > > >> people by arbitrarily closing their issue. These all have some
> > > >> validity, but I we have to strike a balance. I wonder if we can
> > > >> address them in another way. In JIRA can we keep these old issues
> > > >> while hiding them from default searches. Can we "archive" old issues
> > > >> in some way? Maybe there is a "Status" like Archived that is different
> > > >> from Closed. Anything but Open!
> > > >>
> > > >>
> > > >> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
> > > >>>
> > > >>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> > > >>>
> > > >>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
> > > >>>>
> > > >>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> > > >>>> <lu...@mikemccandless.com> wrote:
> > > >>>>>
> > > >>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> > > >>>>>
> > > >>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> > > >>>>>
> > > >>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> > > >>>> I see it in other trackers. Is there a rush to close these for some
> > > >>>> reason?
> > > >>>>
> > > >>>> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rc...@gmail.com> wrote:
>
> I added my vote against bulk close functionality.
> it is pretty clear from this thread that several of us are opposed to
> bulk close.
>
> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
>
> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <ja...@cominvent.com> wrote:
> >
> > I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
> >
> > Jan
> >
> > > 8. des. 2021 kl. 01:33 skrev Jan Høydahl <ja...@cominvent.com>:
> > >
> > > +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> > > We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> > > My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> > >
> > > Jan
> > >
> > >> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <ms...@gmail.com>:
> > >>
> > >> In this specific instance, I don't see the harm in leaving these
> > >> issues there since the entire repo is essentially an archival artifact
> > >> at this point. If we actually want to notify people that "hey your
> > >> issue is in a dead zone, do you want to revive it? Here's how ..." we
> > >> could maybe generate some emails? Although I really have no idea how
> > >> we would accomplish that.
> > >>
> > >> In general, I'm in favor of cleaning up / closing issues that are
> > >> clearly not going to be worked.
> > >>
> > >> For example in JIRA we have so many old issues that they can clutter
> > >> up search results, making it much harder for new contributors
> > >> (especially) to find "interesting" issues that might be relevant today
> > >> and workable. I have heard various arguments for keeping these old
> > >> issues: they represent an historical view of the project; "you never
> > >> know" maybe they become relevant again; and this idea of not annoying
> > >> people by arbitrarily closing their issue. These all have some
> > >> validity, but I we have to strike a balance. I wonder if we can
> > >> address them in another way. In JIRA can we keep these old issues
> > >> while hiding them from default searches. Can we "archive" old issues
> > >> in some way? Maybe there is a "Status" like Archived that is different
> > >> from Closed. Anything but Open!
> > >>
> > >>
> > >> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
> > >>>
> > >>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> > >>>
> > >>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
> > >>>>
> > >>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> > >>>> <lu...@mikemccandless.com> wrote:
> > >>>>>
> > >>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> > >>>>>
> > >>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> > >>>>>
> > >>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> > >>>> I see it in other trackers. Is there a rush to close these for some
> > >>>> reason?
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Robert Muir <rc...@gmail.com>.
I added my vote against bulk close functionality.
it is pretty clear from this thread that several of us are opposed to
bulk close.
somehow the discussion jumped from bulk commenting to bulk close. fuck that!
On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <ja...@cominvent.com> wrote:
>
> I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
>
> Jan
>
> > 8. des. 2021 kl. 01:33 skrev Jan Høydahl <ja...@cominvent.com>:
> >
> > +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> > We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> > My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> >
> > Jan
> >
> >> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <ms...@gmail.com>:
> >>
> >> In this specific instance, I don't see the harm in leaving these
> >> issues there since the entire repo is essentially an archival artifact
> >> at this point. If we actually want to notify people that "hey your
> >> issue is in a dead zone, do you want to revive it? Here's how ..." we
> >> could maybe generate some emails? Although I really have no idea how
> >> we would accomplish that.
> >>
> >> In general, I'm in favor of cleaning up / closing issues that are
> >> clearly not going to be worked.
> >>
> >> For example in JIRA we have so many old issues that they can clutter
> >> up search results, making it much harder for new contributors
> >> (especially) to find "interesting" issues that might be relevant today
> >> and workable. I have heard various arguments for keeping these old
> >> issues: they represent an historical view of the project; "you never
> >> know" maybe they become relevant again; and this idea of not annoying
> >> people by arbitrarily closing their issue. These all have some
> >> validity, but I we have to strike a balance. I wonder if we can
> >> address them in another way. In JIRA can we keep these old issues
> >> while hiding them from default searches. Can we "archive" old issues
> >> in some way? Maybe there is a "Status" like Archived that is different
> >> from Closed. Anything but Open!
> >>
> >>
> >> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
> >>>
> >>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> >>>
> >>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
> >>>>
> >>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> >>>> <lu...@mikemccandless.com> wrote:
> >>>>>
> >>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> >>>>>
> >>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> >>>>>
> >>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> >>>>>
> >>>>>
> >>>>
> >>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> >>>> I see it in other trackers. Is there a rush to close these for some
> >>>> reason?
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Jan Høydahl <ja...@cominvent.com>.
I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
Jan
> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <ja...@cominvent.com>:
>
> +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
>
> Jan
>
>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <ms...@gmail.com>:
>>
>> In this specific instance, I don't see the harm in leaving these
>> issues there since the entire repo is essentially an archival artifact
>> at this point. If we actually want to notify people that "hey your
>> issue is in a dead zone, do you want to revive it? Here's how ..." we
>> could maybe generate some emails? Although I really have no idea how
>> we would accomplish that.
>>
>> In general, I'm in favor of cleaning up / closing issues that are
>> clearly not going to be worked.
>>
>> For example in JIRA we have so many old issues that they can clutter
>> up search results, making it much harder for new contributors
>> (especially) to find "interesting" issues that might be relevant today
>> and workable. I have heard various arguments for keeping these old
>> issues: they represent an historical view of the project; "you never
>> know" maybe they become relevant again; and this idea of not annoying
>> people by arbitrarily closing their issue. These all have some
>> validity, but I we have to strike a balance. I wonder if we can
>> address them in another way. In JIRA can we keep these old issues
>> while hiding them from default searches. Can we "archive" old issues
>> in some way? Maybe there is a "Status" like Archived that is different
>> from Closed. Anything but Open!
>>
>>
>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
>>>
>>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
>>>
>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
>>>>
>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>>>> <lu...@mikemccandless.com> wrote:
>>>>>
>>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>>>>>
>>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>>>>>
>>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>>>>>
>>>>>
>>>>
>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>>>> I see it in other trackers. Is there a rush to close these for some
>>>> reason?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Jan Høydahl <ja...@cominvent.com>.
+1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
Jan
> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <ms...@gmail.com>:
>
> In this specific instance, I don't see the harm in leaving these
> issues there since the entire repo is essentially an archival artifact
> at this point. If we actually want to notify people that "hey your
> issue is in a dead zone, do you want to revive it? Here's how ..." we
> could maybe generate some emails? Although I really have no idea how
> we would accomplish that.
>
> In general, I'm in favor of cleaning up / closing issues that are
> clearly not going to be worked.
>
> For example in JIRA we have so many old issues that they can clutter
> up search results, making it much harder for new contributors
> (especially) to find "interesting" issues that might be relevant today
> and workable. I have heard various arguments for keeping these old
> issues: they represent an historical view of the project; "you never
> know" maybe they become relevant again; and this idea of not annoying
> people by arbitrarily closing their issue. These all have some
> validity, but I we have to strike a balance. I wonder if we can
> address them in another way. In JIRA can we keep these old issues
> while hiding them from default searches. Can we "archive" old issues
> in some way? Maybe there is a "Status" like Archived that is different
> from Closed. Anything but Open!
>
>
> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
>>
>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
>>
>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
>>>
>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>>> <lu...@mikemccandless.com> wrote:
>>>>
>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>>>>
>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>>>>
>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>>>>
>>>>
>>>
>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>>> I see it in other trackers. Is there a rush to close these for some
>>> reason?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Michael Sokolov <ms...@gmail.com>.
In this specific instance, I don't see the harm in leaving these
issues there since the entire repo is essentially an archival artifact
at this point. If we actually want to notify people that "hey your
issue is in a dead zone, do you want to revive it? Here's how ..." we
could maybe generate some emails? Although I really have no idea how
we would accomplish that.
In general, I'm in favor of cleaning up / closing issues that are
clearly not going to be worked.
For example in JIRA we have so many old issues that they can clutter
up search results, making it much harder for new contributors
(especially) to find "interesting" issues that might be relevant today
and workable. I have heard various arguments for keeping these old
issues: they represent an historical view of the project; "you never
know" maybe they become relevant again; and this idea of not annoying
people by arbitrarily closing their issue. These all have some
validity, but I we have to strike a balance. I wonder if we can
address them in another way. In JIRA can we keep these old issues
while hiding them from default searches. Can we "archive" old issues
in some way? Maybe there is a "Status" like Archived that is different
from Closed. Anything but Open!
On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote:
>
> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
>
> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
>>
>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>> <lu...@mikemccandless.com> wrote:
>> >
>> > Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>> >
>> > I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>> >
>> > I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>> >
>> >
>>
>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>> I see it in other trackers. Is there a rush to close these for some
>> reason?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Mike Drob <md...@mdrob.com>.
I understand the frustrations around closing somebody’s PR as stale, but I
also think that there is value in informing the contributors I this is
never getting solved/fixed/looked at, if this is still important please go
over there instead.
On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rc...@gmail.com> wrote:
> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> <lu...@mikemccandless.com> wrote:
> >
> > Could we maybe instead bulk-add a comment explaining the split and how
> to take the PR forwards if someone (in the future) has itch/time?
> >
> > I know we humans love to clean things up, but I think leaving such
> "unclean" things open serves an important purpose. They all had importance
> to at least one person at one point in time, and likely many of them are
> still relevant if they piqued someones curiosity to dig back into them.
> Closing them makes them harder to find for the future developer.
> >
> > I'm sure some of them are already resolved/duplicates too. If only we
> could divine which are which.
> >
> >
>
> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> I see it in other trackers. Is there a rush to close these for some
> reason?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Closing GitHub PRs
Posted by Robert Muir <rc...@gmail.com>.
On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
<lu...@mikemccandless.com> wrote:
>
> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>
> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>
> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>
>
+1, I'd rather not auto-close PRs. I'm always frustrated by this when
I see it in other trackers. Is there a rush to close these for some
reason?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs
Posted by Michael McCandless <lu...@mikemccandless.com>.
Could we maybe instead bulk-add a comment explaining the split and how to
take the PR forwards if someone (in the future) has itch/time?
I know we humans love to clean things up, but I think leaving such
"unclean" things open serves an important purpose. They all had importance
to at least one person at one point in time, and likely many of them are
still relevant if they piqued someones curiosity to dig back into them.
Closing them makes them harder to find for the future developer.
I'm sure some of them are already resolved/duplicates too. If only we
could divine which are which.
Mike McCandless
http://blog.mikemccandless.com
On Mon, Nov 29, 2021 at 2:45 PM Mike Drob <md...@mdrob.com> wrote:
> We currently have almost 300 open PRs against the "master" branch in the
> old lucene-solr repo.
>
>
> https://github.com/apache/lucene-solr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster
>
> I think we should close all of them (possibly with a comment pointing
> people to the main branch in the lucene or solr repos).
>
> I do not know if there is an automated way to do this, or a way to do this
> without spamming everybody's email lists. If there is consensus on this
> clean up work then I'll take some time to investigate how to get this done
> and/or chat with ASF Infra about it.
>
> Thanks,
> Mike
>