If I am looking at the Kafka site correctly, I see that Kafka has a total of 
167 KIPs so far. 
So I assume that minor new features would not be parrt of the SIP ? 

Unlike Kafka, since Storm has a number of connectors (that keep growing), I am 
speculating the SIP process might get somewhat unwieldy if it were to track 
little changes in each of the connectors.

Also thinking that a SIP may not be needed to justify a new connector, but 
useful if we are replacing an old connector with a new one.

-roshan



On 6/9/17, 3:19 PM, "Harsha" <st...@harsha.io> wrote:

    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 <ev...@yahoo-inc.com.invalid>
    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
        <generalbas....@gmail.com> 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 <st...@harsha.io>:
    
        > 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
        >
    
    

Reply via email to