I don't think we need a KIP/vote here, this is just an internal
refactoring. We had said previously and noted in the document that the KIPs
were just for big new features or public api changes.
I am a big +1 on the idea. We'll have to be careful in the code review
since it would really easy to
I think the new tickets can be done in parallel, and are not an actual
dependency for KAFKA-1845. Is that correct?
On Sat, Feb 7, 2015 at 1:44 PM, Jay Kreps jay.kr...@gmail.com wrote:
I don't think we need a KIP/vote here, this is just an internal
refactoring. We had said previously and noted
Yeah totally, all the cleanups should be independent, this thread just
reminded me to file tickets for them.
-jay
On Sunday, February 8, 2015, Gwen Shapira gshap...@cloudera.com wrote:
I think the new tickets can be done in parallel, and are not an actual
dependency for KAFKA-1845. Is that
I created KIP-12
https://cwiki.apache.org/confluence/display/KAFKA/KIP-12+change+broker+configuration+properties+to+be+consistent+with+the+rest+of+the+code
and linked it to this thread and the JIRA with the v1 patch. The rebased
version with updates for the current review should be ready to review
I think this is a good change. Is there general agreement that we are
moving forward with this approach? It would be nice to start using this for
future work.
Thanks
Jeff
On Tue, Feb 3, 2015 at 9:34 AM, Joe Stein joe.st...@stealth.ly wrote:
I updated the RB changing some of the HIGH to MEDIUM
I updated the RB changing some of the HIGH to MEDIUM and LOW.
There might be other or different opinions and they may change over time so
I don't really see h/m/l as a blocker to the patch going in.
It would be great to take all the rb feedback from today and then tomorrow
rebase and include
It'd be great to have it on trunk.
As I mentioned under jira ticket (KAFKA-1845) current implementation lacks
correct Importance settings.
I'd be grateful if somebody could help me with it (a simple mapping between
config setting and importance or comments right in the review board would
suffice).
Hey, I wanted to start a quick convo around some changes on trunk. Not sure
this requires a KIP since it is kind of internal and shouldn't affect users
but we can decide if so and link this thread to that KIP if so (and keep
the discussion going on the thread if makes sense).
Before making any
Strong +1 from me (obviously). Lots of good reasons to do it:
consistency, code reuse, better validations, etc, etc.
I had one comment on the patch in RB, but it can also be refactored as
follow up JIRA to avoid blocking everyone who is waiting on this.
Gwen
On Mon, Feb 2, 2015 at 1:31 PM, Joe
