Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAOeJiJh6Vkkca85bWYgkeOZ8rC6+KDh7zzq8vMKECL_7PNExTA@mail.gmail.com>
References: 
 <CAOeJiJh6Vkkca85bWYgkeOZ8rC6+KDh7zzq8vMKECL_7PNExTA@mail.gmail.com>
Date: Thu, 15 Jan 2015 15:18:42 -0500
Message-ID: 
 <CAA7ooCAE5E2cOGrGEjR1uXjWLxn13mQYjCrr5wXb-nNrQ7J+MA@mail.gmail.com>
Subject: Re: [DISCUSS] KIPs
From: Joe Stein <joe.stein@stealth.ly>
To: "dev@kafka.apache.org" <dev@kafka.apache.org>
Content-Type: multipart/alternative; boundary=001a113d108ef11458050cb68f47

--001a113d108ef11458050cb68f47
Content-Type: text/plain; charset=UTF-8

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.kreps@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
>

--001a113d108ef11458050cb68f47--