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 <rcm...@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 <jan....@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 <rcm...@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 <rcm...@gmail.com> wrote: > > >> > > >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rcm...@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 <jan....@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....@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 <msoko...@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 <rcm...@gmail.com> > > >>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless > > >>>>>>>> <luc...@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-unsubscr...@lucene.apache.org > > >>>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org > > >>>>>>>> > > >>>>>> > > >>>>>> --------------------------------------------------------------------- > > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > >>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org > > >>>>>> > > >>>>> > > >>>> > > >>>> > > >>>> --------------------------------------------------------------------- > > >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > >>>> For additional commands, e-mail: dev-h...@lucene.apache.org > > >>>> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
