Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-08-02 Thread P. Taylor Goetz
> On Aug 2, 2017, at 4:31 PM, Bobby Evans wrote: > > You don't want it in the bylaws yet, Not a big deal, but I still think having > the rules formally written up are a good start, even if they are not formally > voted on and binding in the bylaws. > We can try it

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-08-02 Thread Bobby Evans
You don't want it in the bylaws yet, Not a big deal, but I still think having the rules formally written up are a good start, even if they are not formally voted on and binding in the bylaws. We can try it out see what works and what doesn't. - Bobby On Wednesday, August 2, 2017, 12:29:46 PM

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-08-02 Thread Hugo Da Cruz Louro
I am +1 with having a bit more structure in the process (SIP), but being cautious about limiting the overhead. I like the SIP idea, but I agree with Bobby’s point of - "what if you missed SIP and don’t agree with something during PR phase". For that I suggest that SIP is an iterative process -

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-08-02 Thread P. Taylor Goetz
I would advise against codifying a SIP process in our bylaws, at least not without doing an informal experiment to see how it goes, work out the kinks, etc. Once something goes into the bylaws, it can be very difficult to change, remove, etc. I prefer operating more on general consensus versus

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-08-02 Thread Bobby Evans
My only concerns are 1. It is going to add more overhead and slow down getting a feature out.  But that may not be the case if there is less overhead during the review process to offset writing up a large design, and it can be balanced with small features not needing it. 2. that I am going to

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-08-01 Thread Jungtaek Lim
Still +1 to introduce this only for non connectors. Maybe would want to skip this also for non connectors and non storm-core (storm-client/storm-server) like Flux, SQL, storm-webapp as well, but maybe still have small chance to need it. Despite that I voted to +1, I still worry about efforts on

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-08-01 Thread Harsha
Trying to bring attention this again. We currently have few big feature PRs going on and there is considerable discussion about the design and Implementation etcc. My intention of starting SIP is to add these details before someone goes and writes up a PR and everyone has to go through reading of

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-11 Thread Jungtaek Lim
I think we actually tried similar thing once: - Issue: https://issues.apache.org/jira/browse/STORM-2016 - Wiki page: https://cwiki.apache.org/confluence/display/STORM/A.+Design+doc%3A+adding+jars+and+maven+artifacts+at+submission - Discussion thread:

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Roshan Naik
Seems reasonable to have a way to make it easy for people to follow important things for people who are not glued to the mailing lists. If the desire is to keep it light weight and still achieve the above goal .. the SIP can be just a short title and description with a link to the JIRA which

[Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Harsha
Arun, For big features we did follow design doc/review. Making it formal makes everyone to follow a process. Again this process is not for bug fixes as we stated its about New Features/Config Changes/Public interface changes. I don't think it puts any extra effort for anyone

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Arun Iyer
I am for documenting and upfront design reviews, but maybe we should keep it less formal and make it part of the JIRA to start with. Do we have any upcoming features for which we would like to see a proposal? May be start with a couple of proposals and see it works out before making it formal.

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread P. Taylor Goetz
-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

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Priyank Shah
+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"

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Satish Duggana
+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

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Roshan Naik
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

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Hugo Da Cruz Louro
+1 for KIP equivalent for Storm. We should probably call them something like Storm Feature/Improvement Proposals. Well documented features could help new contributors to more quickly as they would have the context to start that feature. Unless one knows the product well, it is hard to have

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Harsha
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

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Bobby Evans
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

Re: [Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Stig Døssing
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 : > Hi All, > We’ve seen good adoption of KIP approach in Kafka community > and would

[Discussion]: Storm Improvemement Proposal (SIP) to discuss changes

2017-06-09 Thread Harsha
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