Thanks for that list, Nikolay, I've just closed them all.
And thanks to you all for working to keep Kafka development healthy! -John On Wed, 2022-02-09 at 14:19 +0300, Nikolay Izhikov wrote: > Hello, guys. > > I made a quick search throw oldest PRs. > Looks like the following list can be safely closed. > > Committers, can you, please, push the actual «close» button for this list of > PRs? > > https://github.com/apache/kafka/pull/560 > https://github.com/apache/kafka/pull/200 > https://github.com/apache/kafka/pull/62 > https://github.com/apache/kafka/pull/719 > https://github.com/apache/kafka/pull/735 > https://github.com/apache/kafka/pull/757 > https://github.com/apache/kafka/pull/824 > https://github.com/apache/kafka/pull/880 > https://github.com/apache/kafka/pull/907 > https://github.com/apache/kafka/pull/983 > https://github.com/apache/kafka/pull/1035 > https://github.com/apache/kafka/pull/1078 > https://github.com/apache/kafka/pull/1111 > https://github.com/apache/kafka/pull/1135 > https://github.com/apache/kafka/pull/1147 > https://github.com/apache/kafka/pull/1150 > https://github.com/apache/kafka/pull/1244 > https://github.com/apache/kafka/pull/1269 > https://github.com/apache/kafka/pull/1415 > https://github.com/apache/kafka/pull/1468 > > > 7 февр. 2022 г., в 20:04, Mickael Maison <mickael.mai...@gmail.com> > > написал(а): > > > > Hi David, > > > > I agree with you, I think we should close stale PRs. > > > > Overall, I think we should also see if there are other Github actions > > that may ease the work for reviewers and/or give more visibility of > > the process to PR authors. > > I'm thinking things like: > > - code coverage changes > > - better view on results from the build, for example if it's failing > > checkstyle, the author could be notified first > > - check whether public API are touched and it requires a KIP > > > > For example, see some actions/integration used by other Apache projects: > > - Flink: https://github.com/apache/flink/pull/18638#issuecomment-1030709579 > > - Beam: https://github.com/apache/beam/pull/16746#issue-1124656975 > > - Pinot: https://github.com/apache/pinot/pull/8139#issuecomment-1030701265 > > > > Finally, as several people have mentioned already, what can we do to > > increase the impact of contributors that are not (yet?) committers? > > Currently, our long delays in reviewing PRs and KIPs is hurting the > > project and we're for sure missing out some fixes and potential > > contributors. I think Josep's idea is interesting and finding ways to > > engage more people and share some responsibilities better will improve > > the project. Currently the investment to become a committer is pretty > > high. This could provide a stepping stone (or an intermediary role) > > for some people in the community. > > > > Thanks, > > Mickael > > > > > > On Mon, Feb 7, 2022 at 12:51 PM Josep Prat <josep.p...@aiven.io.invalid> > > wrote: > > > > > > Hi, > > > > > > It seems like a great idea. I agree with you that we should use this as a > > > means to notify contributors and reviewers that there is some work to be > > > done. > > > > > > Regarding labels, a couple of things, first one is that PR participants > > > won't get notified when a label is applied. So probably it would be best > > > to > > > apply a label and add a comment. > > > Secondly, GitHub offers better fine-grained roles for contributors: read, > > > triage, write, maintain, admin (further reading here: > > > https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role). > > > One thing that might make sense to do maybe is to add frequent > > > contributors > > > with the "triage" role, so they could label PRs they reviewed and they can > > > be taken by committers for a further review and potential merge. What do > > > you think? > > > > > > Best, > > > > > > On Mon, Feb 7, 2022 at 12:16 PM Nikolay Izhikov <nizhi...@apache.org> > > > wrote: > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Josep Prat > > > > > > *Aiven Deutschland GmbH* > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > *m:* +491715557497 > > > > > > *w:* aiven.io > > > > > > *e:* josep.p...@aiven.io >
