I just saw another project - https://github.com/openmessaging/benchmark uses
probot-stale https://github.com/probot/stale
This looks like it has all the features needed to close both stale issues and
PRs. It allows labels to be used to prevent closure of certain issues and PRs.
Here is their co
> On Dec 15, 2021, at 4:06 PM, Matteo Merli wrote:
>
>> Is #3267 Support set publish time on broker side one of those very valuable
>> ideas that was later rejected, likely for performance reasons?
>
> No, this was one that was superseded by other changes.
Then I’ll close it.
>
>> One pro
> Is #3267 Support set publish time on broker side one of those very valuable
> ideas that was later rejected, likely for performance reasons?
No, this was one that was superseded by other changes.
> One problem with the current state is that PRs and even higher level ideas
> have a shelf life.
It isn't even an issue related to OSS - every long lived project suffers
from this same issue. Whether it's a long lingering defect report or a fix
that never got integrated in a timely manner, time wounds all heels.
Careful considered review is perfection which can't be hit; if it could be
done,
I’d like to point out that if we label auto-closed PRs properly it is easy
enough to find them in the GitHub UI.
> On Dec 15, 2021, at 3:05 PM, Jonathan Ellis wrote:
>
> One problem with the current state is that PRs and even higher level ideas
> have a shelf life. Declaring PR bankruptcy does
One problem with the current state is that PRs and even higher level ideas
have a shelf life. Declaring PR bankruptcy does in fact solve this problem.
The other problem is that from a new contributor's perspective it's
impossible to tell which issues are relevant and which are clutter that we
hav
> On Dec 15, 2021, at 1:11 PM, Matteo Merli wrote:
>
> I'm not convinced by having a blanket policy here.
>
> In several cases, these PRs carried some very valuable ideas that
> still needed some work to get merged. By using blanket close, we'd be
> losing all that context and we should not d
I think that there should be a label added to any old PR that a contributor
wants to keep open. I think “status/hold” would be a good label name. That will
keep others who wish to review old PRs and close them from wasting their time.
I looked at the labels and I wonder about those that are “tri
> I'm not convinced by having a blanket policy here.
I'm fine with stopping short of an automated policy. However, I think
it'd be helpful to provide committers, especially new committers, with
conditions that make a PR eligible to be closed. Since committers act
on behalf of the PMC, documentatio
I'm not convinced by having a blanket policy here.
In several cases, these PRs carried some very valuable ideas that
still needed some work to get merged. By using blanket close, we'd be
losing all that context and we should not do that.
What would actually be helpful, is help in reviewing these
I am +1 for closing PRs that are over a year old.
Does anyone else in the community have thoughts on these old PRs?
Getting consensus and creating a process here could help make our
committers more efficient.
- Michael
On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis wrote:
>
> Agreed.
>
> I don'
Agreed.
I don't think I understand tison's objection to closing very stale PRs
automatically -- if it's gone that long without attention the situation
isn't likely to change. And the submitter can always reopen it if it's
still relevant.
On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote:
> I th
I think that any Pulsar committer ought to close any PR that is more than one
year old. That would clear about 75 from the backlog. The OP should be informed
and if they are still interested then they can discuss it here.
So when a stale PR is closed we should suggest that the OP subscribe to an
>From my experience, any process won't work. The only way is to inspire more
reviewers act on PRs.
Instead of talking about how to do it, reviewing one PR now can help the
case.
Also, it's reasonable to close inactive PR if there is a successor. But do
not let
a bot do it, which will create many c
Hi Pulsar Community,
I am excited to start contributing as a committer! I have a question
about our process for closing stale PRs.
We have ~300 open PRs right now. Do we have any guidelines on closing
stale PRs? Of course we don't want to ignore important bug fixes, but
we also don't want to clut
15 matches
Mail list logo
