-0 The KIP process feels kind of heavy. I'd rather start with a lighter effort like improving JIRA submissions and pull requests (some pull requests/JIRAs, even from committers and PMC members, are woefully inadequate in terms of detail), and see how that works out.
I share Bobby's concern that doing so might raise the bar for contributions and potentially have a chilling effect. We don't want to scare away contributors. Kafka has somewhat of a reputation for setting potentially too high a bar. I'd rather not see that happen with this community. I will say that I like the idea of proposals for big features, ideally before any coding even begins -- so that others have a chance to collaborate. But I'm hesitant to impose too much process, voting, etc. That could scare people off. I think we should think carefully before going down this trail. -Taylor > On Jun 9, 2017, at 8:57 PM, Priyank Shah <[email protected]> wrote: > > +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 >>> >> >> >> >> > >
