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, the situation would never have occured in the first place. Having a time-to-live is pragmatic, not perfect, but pragmatic. As Jonathan mentioned, if ideas or changes linger too long, they often are superceded or replaced with more applicable alternatives or might not have been that important in the first place. It's a shame because each languishing PR represents some amount of work from someone (sometimes a non-trivial amount) but there really isn't a more practical alternative IMO. On Wed, Dec 15, 2021 at 5:05 PM Jonathan Ellis <jbel...@gmail.com> wrote: > 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 > haven't gotten around to closing out. > > For this, declaring PR bankruptcy isn't as good as somehow having the > capacity to review and respond to everything, but it's still better than > the status quo. And since no large-scale OSS project that I'm aware of has > figured out how to review and respond to everything sustainably, I'd settle > for an imperfect solution over a perfect one that probably doesn't exist. > > > On Wed, Dec 15, 2021 at 3:12 PM Matteo Merli <matteo.me...@gmail.com> > 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 do that. > > > > What would actually be helpful, is help in reviewing these old PRs to > > identify what is either already rejected or superseded by other > > changes and what just needs some help to get completed. > > > > Just declaring PR bankrupticity alone won't solve the problem of why > > more PRs are created than reviewers can review. > > > > > > Matteo > > > > -- > > Matteo Merli > > <matteo.me...@gmail.com> > > > > On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall <mmarsh...@apache.org> > > wrote: > > > > > > 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 <jbel...@gmail.com> > wrote: > > > > > > > > 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 <w...@apache.org> wrote: > > > > > > > > > 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 > > > > > and email dev@pulsar.apache.org to discuss the PR. > > > > > > > > > > All the Best, > > > > > Dave > > > > > . > > > > > > On Dec 3, 2021, at 9:17 AM, tison <wander4...@gmail.com> wrote: > > > > > > > > > > > > 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 corner (bad) cases. > > > > > > > > > > > > Best, > > > > > > tison. > > > > > > > > > > > > > > > > > > Michael Marshall <mmarsh...@apache.org> 于2021年12月4日周六 00:57写道： > > > > > > > > > > > >> 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 clutter our repo with open PRs that won't > > get > > > > > merged. > > > > > >> > > > > > >> For example, I reviewed this PR [0] about 3 months ago. The > > > > > >> contributor has not yet responded to my feedback and it doesn't > > seem > > > > > >> to fix an actual bug, so I think it is a candidate for closure. > > Here > > > > > >> is another example [1]. I closed this one because it had merge > > > > > >> conflicts with a commit that fixed the same underlying issue. > > > > > >> > > > > > >> Note that our committer guidelines [2] do not provide guidance > on > > this > > > > > >> subject. > > > > > >> > > > > > >> [0] - https://github.com/apache/pulsar/pull/11237 > > > > > >> [1] - https://github.com/apache/pulsar/pull/11162 > > > > > >> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide > > > > > >> > > > > > >> Thanks, > > > > > >> Michael > > > > > >> > > > > > > > > > > > > > > > > > > -- > > > > Jonathan Ellis > > > > co-founder, http://www.datastax.com > > > > @spyced > > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced > -- Chris Herzog Messaging Team | O 630 300 7718 | M 815 263 3764 | www.tibco.com <http://www.tibco.com/>
