> 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 out see what works and what d
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
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 -
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
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 m
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
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
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:
http://mail-archives.apache.org/mod_mbox/storm-
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 c
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
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.
-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 tha
+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" wrote:
+1
+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 ca
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 unwiel
+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 feat
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
li
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 l
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 like to see we ad
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
20 matches
Mail list logo