Thanks Jay for kicking this off! I think the confluence page you wrote up is a great start.
The KIP makes sense to me (at a minimum) if there is going to be any "breaking change". This way Kafka can continue to grow and blossom and we have a process in place if we are going to release a thorn ... and when we do it is *CLEAR* about what and why that is. We can easily document which KIPs where involved with this release (which I think should get committed afterwards somewhere so no chance of edit after release). This approach I had been thinking about also allows changes to occur as they do now as long as they are backwards compatible. Hopefully we never need a KIP but when we do the PMC can vote on it and folks can read the release notes with *CLEAR* understanding what is going to break their existing setup... at least that is how I have been thinking about it. Let me know what you think about this base minimum approach... I hadn't really thought of the KIP for *ANY* "major change" and I have to think more about that. I have some other comments for minor items in the confluence page I will make once I think more about how I feel having a KIP for more than what I was thinking about already. I do think we should have "major changes" go through confluence, mailing list discuss and JIRA but kind of feel we have been doing that already ... if there are cases where that isn't the case we should highlight and learn from them and formalize that more if need be. /******************************************* Joe Stein Founder, Principal Consultant Big Data Open Source Security LLC http://www.stealth.ly Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> ********************************************/ On Thu, Jan 15, 2015 at 1:42 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > The idea of KIPs came up in a previous discussion but there was no real > crisp definition of what they were. Here is an attempt at defining a > process: > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals > > The trick here is to have something light-weight enough that it isn't a > hassle for small changes, but enough so that changes get the eyeballs of > the committers and heavy users. > > Thoughts? > > -Jay >
