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]

Reply via email to