+1 for SIPs including a new connector. The person writing SIP can provide details about the external system for which connector is being written to let others know why a certain design decision was made. This will make it easy for reviewers.
On 6/9/17, 5:24 PM, "Satish Duggana" <[email protected]> wrote: +1 for SIPs. It is so useful as mentioned by others in earlier mails. It would be very useful for new contributors and others who are looking out for a feature design and decisions taken etc. Whenever a minor feature is added to a connector it may not need a separate SIP but the existing README can be updated with details for users. It can be discussed and decided apropos whether a SIP is really required for any enhancement which is not really big. On Sat, Jun 10, 2017 at 5:13 AM, Roshan Naik <[email protected]> wrote: > 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" <[email protected]> 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 <[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 > > > > > >
