Hi Bobby,
In general, a KIP is required for adding New features, config
changes or backward-incompatible changes. Don't require
adding a KIP for bug-fixes. Devs who wants to add any
features will write up a wiki which has JIRA link, mailing
list discussion link and outline the Motivation, Public
interface changes and protocol changes etc ..a good example
here is
https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka.
They can start the discussion thread once its ready and once everyone
agrees its in a good shape, a Vote thread starts . Once there are
required votes are in one can start the PR process and get it merged in.
Each release we can collect what features/fixes especially to
public interfaces that went in and roll it out in release
notes. This will give a better idea for the users on what
changed and added from previous version.
We can only enforce this to new feature/config/backward
incompatible change. Having this go through the discussion
phase will give us the early feedback and potentially caught
any issues before the implementation.
Thanks,
Harsha
On Fri, Jun 9, 2017 at 2:24 PM Bobby Evans <[email protected]>
wrote:
Can you please explain how KIP currently works and how you would
like to see something similar in storm?
If we make the process more formal we will probably have less people
contributing, but we will probably have better overall patches. It
is a balancing act and having never used KIP I would like to
understand it better before going all in on it.
- Bobby
On Friday, June 9, 2017, 4:09:38 PM CDT, Stig Døssing
<[email protected]> wrote:
This sounds like a good idea. KIPs seem to work well for Kafka. It's
easy
for discussions to get lost or just not seen on the mailing list.
2017-06-09 21:36 GMT+02:00 Harsha <[email protected]>:
> Hi All,
> We’ve seen good adoption of KIP approach in Kafka community
> and would like to see we adopt the similar approach for storm
> as well.
> Its hard to keep track of proposed changes and mailing list threads to
> know what all changes that are coming into and what design/backward
> incompatible changes being approved. It will be good to have this
> documented and go through discussion then Vote phase to get them
> approved before we merge the PRs. This will keep everyone informed of
> what changes happened even if they are not following the mailing list
> they can go to wiki to see the list of changes went into a release.
> Community overall will be well informed of the changes as well. Would
> like to hear your thoughts.
>
> Thanks,
> Harsha
>
