> We do not have a separate list of PRs that need pre-reviews. Ok. What should I do if PR need to be to closed found? Who can I tag to do actual close?
> 7 февр. 2022 г., в 13:53, Bruno Cadonna <cado...@apache.org> написал(а): > > Hi, > > Thank you David for bringing this up! > > I am in favour of automatically closing stale PRs. I agree with Guozhang that > notifications of staleness to authors would be better than silently closing > them. I assume the notification happens automatically when the label "Stale" > is added to the PR. > > +1 for Matthias' proposal of non-committers doing a pre-review. That would > definitely save some time for committer reviews. > > Nikolay, great that you are willing to do reviews. We do not have a separate > list of PRs that need pre-reviews. You can consult the list of PRs of Apache > Kafka (https://github.com/apache/kafka/pulls) and choose from there. I think > that is the simplest way to start reviewing. Maybe Luke has some tips here > since he does an excellent job in reviewing as a non-committer. > > Best, > Bruno > > On 07.02.22 08:24, Nikolay Izhikov wrote: >> Hello, Matthias, Luke. >>> I agree with Matthias that contributors could and should help do more >>> "pre-review" PRs. >> I, personally, ready to do the initial review of PRs. Do we have some recipe >> to filter PRs that has potential to land in trunk? >> Can, you, please, send me list of PRs that need to be pre-reviewed? >>> I might be useful thought to just do a better job to update KIP status more >>> frequently >> First, I thought it’s an author job to keep KIP status up to date. >> But, it can be tricky to determine actual KIP status because of lack of >> feedback from committers :) >> Second - the other issue is determine - what KIP just wait for a hero to >> implement it, and what just wrong idea or something similar. >> All of this kind of KIPs has status «Under discussion». >> Actually, if someone has a list of potentially useful KIPS - please, send it. >> I’m ready to work on one of those. >>> 7 февр. 2022 г., в 05:28, Luke Chen <show...@gmail.com> написал(а): >>> >>> I agree with Matthias that contributors could and should help do more >>> "pre-review" PRs. >>> Otherwise, we're not fixing the root cause of the issue, and still keeping >>> piling up the PRs (and auto closing them after stale) >>> >>> And I also agree with Guozhang that we should try to notify at least the >>> committers about the closed PRs (maybe PR participants + committers if >>> possible). >>> Although the PRs are stale, there might be some good PRs just got ignored. >>> >>> Thank you. >>> Luke >>> >>> >>> On Mon, Feb 7, 2022 at 6:50 AM Guozhang Wang <wangg...@gmail.com> wrote: >>> >>>> Thanks for bringing this up David. I'm in favor of some automatic ways to >>>> clean up stale PRs. More specifically: >>>> >>>> * I think there are indeed many root causes why we have so many stale PRs >>>> that we should consider, and admittedly the reviewing manpower cannot keep >>>> up with the contributing pace is a big one of them. But in this discussion >>>> I'd personally like to keep this out of the scope and maybe keep it as a >>>> separate discussion (I think we are having some discussions on some of >>>> these root causes in parallel at the moment). >>>> >>>> * As for just how to handle the existing stale PRs, I think having an >>>> automatic way would be possibly the most effective manner, as I suspect how >>>> maintainable it would be to do that manually. The question though would be: >>>> do we just automatically close those PRs silently or should we also send >>>> notifications along with it. It seems https://github.com/actions/stale can >>>> definitely do the first, but not sure if it could the second? Plus let's >>>> say if we want notifications and it's doable via Action, could we configure >>>> just the committers list (as sending notifications to all community >>>> subscribers may be too spammy)? Personally I feel setting 6 months for >>>> closing and notifying committers on a per-week basis seems sufficient. >>>> >>>> >>>> Guozhang >>>> >>>> >>>> On Sun, Feb 6, 2022 at 9:58 AM Matthias J. Sax <mj...@apache.org> wrote: >>>> >>>>> I am +1 to close stale PRs -- not sure to what extend we want to >>>>> automate it, or just leave it up to the committers to do the cleanup >>>>> manually. I am happy both ways. >>>>> >>>>> However, I also want to point out, that one reason why we have so many >>>>> stale PRs is the committer overload to actually review PRs. It's a pity >>>>> that committer cannot keep up with the load (guilty as charged myself). >>>>> Not sure if it would help if more contributors could help doing reviews, >>>>> such that PRs are "pre-reviewed" and already in good shape before a >>>>> committer reviews it? >>>>> >>>>> >>>>> >>>>> >>>>> For KIPs, there is actually two more categories: >>>>> >>>>> - "Dormant/Inactive" >>>>> - "Discarded: >>>>> >>>>> >>>> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals#KafkaImprovementProposals-DiscardedKIPs >>>>> >>>>> For Kafka Streams in particular, we also try to make the status of KIP >>>>> clear in the corresponding sub-page: >>>>> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams >>>>> >>>>> I might be useful thought to just do a better job to update KIP status >>>>> more frequently -- we could also re-organize the main KIP wiki page -- I >>>>> think it contains too much information and is hard to read. >>>>> >>>>> For the Kafka Streams sub-page, we use it for all "active" KIPs, while >>>>> we maintain a second page for adopted KIPs grouped by release: >>>>> >>>>> >>>> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+KIP+Overview >>>>> >>>>> I find this much more digestible compared to the main KIP page. >>>>> >>>>> Might also be good to have a sub-page for Connect KIPs? >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> On 2/5/22 05:57, Luke Chen wrote: >>>>>> Hi Nikolay, >>>>>> >>>>>> That's a good question! >>>>>> But I think for stale KIP, we should have another discussion thread. >>>>>> >>>>>> In my opinion, I agree we should also have similar mechanism for KIP. >>>>>> Currently, the state of KIP has "under discussion", "voting", and >>>>>> "accepted". >>>>>> The KIP might stay in "discussion" or "voting" state forever. >>>>>> We might be able to have a new state called "close" for KIP. >>>>>> And we can review those inactive KIPs for a long time like PR did, to >>>> see >>>>>> if these KIPs need to close or re-start the discussion again. >>>>>> >>>>>> Thank you. >>>>>> Luke >>>>>> >>>>>> On Sat, Feb 5, 2022 at 9:23 PM Nikolay Izhikov <nizhi...@apache.org> >>>>> wrote: >>>>>> >>>>>>> Hello, David, Luke. >>>>>>> >>>>>>> What about KIPs? >>>>>>> Should we have some special state on KIPs that was rejected or can’t >>>> be >>>>>>> implemented due to lack of design or when Kafka goes in another >>>>> direction? >>>>>>> Right now those kind of KIPs just have no feedback. >>>>>>> For me as a contributor it’s not clear - what is wrong with the KIP. >>>>>>> >>>>>>> Is it wrong? Is there are no contributor to do the implementation? >>>>>>> >>>>>>>> 5 февр. 2022 г., в 15:49, Luke Chen <show...@gmail.com> написал(а): >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I agree with it! This is also a good way to let both parties (code >>>>> author >>>>>>>> and reviewers) know there's a PR is not active anymore. Should we >>>>>>> continue >>>>>>>> it or close it directly? >>>>>>>> >>>>>>>> In my opinion, 1 year is too long, half a year should be long enough. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> Luke >>>>>>>> >>>>>>>> On Sat, Feb 5, 2022 at 8:17 PM Sagar <sagarmeansoc...@gmail.com> >>>>> wrote: >>>>>>>> >>>>>>>>> Hey David, >>>>>>>>> >>>>>>>>> That's a great idea.. Just to stress your point, this keeps both >>>>> parties >>>>>>>>> informed if a PR has become stale. So, the reviewer would know that >>>>>>> there >>>>>>>>> was some PR which was being reviewed but due to inactivity it got >>>>>>> closed so >>>>>>>>> maybe time to relook and similarly the submitter. >>>>>>>>> >>>>>>>>> And yeah, any stale/unused PRs can be closed straight away thereby >>>>>>> reducing >>>>>>>>> the load on reviewers. I have done some work on kubernetes open >>>> source >>>>>>> and >>>>>>>>> they follow a similar paradigm which is useful. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Sagar. >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> -- Guozhang >>>>
