Hello, Knowles. I have some frustration with KIP process, also. Some features, that at glance requested by the community just can’t be done without explicit commiters approval.
KIP-729 [1], KIP-686 [2], request the same feature, can be taken as a good example. Dear Kafka committers, what kind of help do you need with abandoned KIPs? How can I help to reduce number of lost proposals? [1] https://cwiki.apache.org/confluence/display/KAFKA/KIP-729%3A+Custom+validation+of+records+on+the+broker+prior+to+log+append [2] https://cwiki.apache.org/confluence/display/KAFKA/KIP-686%3A+API+to+ensure+Records+policy+on+the+broker > 19 окт. 2021 г., в 17:42, John Roesler <vvcep...@apache.org> написал(а): > > Good morning Knowles, > > Thank you for sharing this feedback. I think your frustration is well > founded. I think most/all of the active committers carry around a sense of > guilt about KIPs that we haven’t been able to review. > > We do have a responsibility to hold auditable, public design discussions > before adopting any new features. As a volunteer organization, we are also at > the mercy of committers’ capacity outside of work and personal life. > > The main thing we do to try and stay responsive is to continue to add new > folks to the committer roster in the hopes that with more committers, we have > a better chance that someone will be able to volunteer to review each new KIP. > > Unfortunately, aside from that, we have only this loose system where > committers try to do the best we can, and new contributors try to keep > pinging their discussion threads until someone responds. > > Your email itself serves as a good wake-up call, and I’m sure that people > will take a look at that list of hanging KIPs now. Hopefully, it will also > provide a spark that leads someone to propose a process improvement. I’ll > certainly be thinking about it myself. > > Thanks again, > John > > > On Tue, Oct 19, 2021, at 09:07, Knowles Atchison Jr wrote: >> Good morning, >> >> The current process of KIPs needs to be improved. There are at least a >> handful of open KIPs with existing PRs that are in a purgatory state. I >> understand that people are busy, but if you are going to gatekeep Kafka >> with this process, then it must be responsive. Even if the community >> decides they do not want the change, the KIP should be addressed and closed >> out. >> >> The entire wiki page is a graveyard of unresponded KIPs. For some changes, >> it takes a nontrivial amount of effort to put together the wiki page and >> one has to essentially write the code implementation hoping that it will be >> pulled into the codebase. This is very frustrating as an external developer >> to have put in the work and then effectively be ignored. >> >> We have to maintain a custom build because KIPs are not debated, voted on, >> or merged in a timely manner. >> >> Knowles
