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 < [email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]>: >> > > > >> > > > 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 <[email protected]> >> wrote: >> > > >> >> > > >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <[email protected]> >> 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 <[email protected]> >> 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 <[email protected] >> >: >> > > >>>>> >> > > >>>>> +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 < >> [email protected]>: >> > > >>>>>> >> > > >>>>>> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >> > > >>>>>>>> >> > > >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless >> > > >>>>>>>> <[email protected]> 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: [email protected] >> > > >>>>>>>> For additional commands, e-mail: [email protected] >> > > >>>>>>>> >> > > >>>>>> >> > > >>>>>> >> --------------------------------------------------------------------- >> > > >>>>>> To unsubscribe, e-mail: [email protected] >> > > >>>>>> For additional commands, e-mail: [email protected] >> > > >>>>>> >> > > >>>>> >> > > >>>> >> > > >>>> >> > > >>>> >> --------------------------------------------------------------------- >> > > >>>> To unsubscribe, e-mail: [email protected] >> > > >>>> For additional commands, e-mail: [email protected] >> > > >>>> >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: [email protected] >> > > > For additional commands, e-mail: [email protected] >> > > > >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: [email protected] >> > > For additional commands, e-mail: [email protected] >> > > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
