Thanks Joel. The status table is useful.
On Mon, Feb 9, 2015 at 8:25 PM, Joe Stein wrote:
> I did https://cwiki.apache.org/confluence/display/KAFKA/drafts
>
> ~ Joestein
>
> On Mon, Feb 9, 2015 at 11:01 PM, Jay Kreps wrote:
>
> > Yeah no pressure. I think you added a holding area for incomplete
I did https://cwiki.apache.org/confluence/display/KAFKA/drafts
~ Joestein
On Mon, Feb 9, 2015 at 11:01 PM, Jay Kreps wrote:
> Yeah no pressure. I think you added a holding area for incomplete KIPs,
> right? I think that is a good idea. We definitely need a place to stash
> these while they are
Yeah no pressure. I think you added a holding area for incomplete KIPs,
right? I think that is a good idea. We definitely need a place to stash
these while they are getting built out...
-Jay
On Mon, Feb 9, 2015 at 6:10 PM, Joe Stein wrote:
> I like the round-up, looks good, thanks Joel.
>
> I s
I like the round-up, looks good, thanks Joel.
I should be able to get KIP-5 and KIP-6 to have more detail in the coming
days.
~ Joestein
On Mon, Feb 9, 2015 at 9:01 PM, Joel Koshy wrote:
> I'm looking through a couple of the KIP threads today and had the same
> issue; and thought it would be u
I'm looking through a couple of the KIP threads today and had the same
issue; and thought it would be useful to do a status round-up of KIPs.
We could incorporate status in the title itself (so we can quickly see
it in the child-page list) but I just added a table to the top-level
wiki. Hopefully t
A problem I am having is actually understanding which KIPs are intended to
be complete proposals and which are works in progress. Joe you seem to have
a bunch of these. Can you move them elsewhere until they are really fully
done and ready for review and discussion?
-Jay
On Fri, Feb 6, 2015 at 12
I think we are focused on making committing new changes easier, but what we
have seen is actually that isn't the bulk of the work (especially with this
kind of "public interface" change where it generally has a big user
impact). I think we actually really need the core committers and any other
inte
Guozhang's idea is interesting. It does promote collaboration.
Not all KIPs are created equally and anyone (including the person reviewing
it) would be able to call out and request a stronger vote for it to go in.
I think that having 3 x +1 is good (sometimes) because it reduces the risk
of thing
Here are my cents:
We could use "lazy" as the default policy for KIP, i.e. :
1. Once a KIP is created at least one committer should engage and provide
feedbacks within a few days;
2. If the committer(s) think it may be a bigger issue / change and requires
broader discussion, she(they) may call ou
Just wanted to add a few more comments on this: KIPs were suggested as
a process to help reach early consensus on a major change or not so
major (but tricky or backward incompatible) change in order to reduce
the likelihood of multiple iterations and complete rewrites during
code reviews (which is
I'm just thinking aloud - I don't know what a good number would be, and it
is just one possibility to streamline how KIPs are processed. It largely
depends on how complex the proposals are. What would be concerning is if
there are 10 different threads all dealing with large KIPs and no one has
the
Joel,
Having only 2 or 3 KIPS under active discussion is concerning.
This will slow down development process as well.
Having a turn-around time for a KIP is a good idea but what will happen
if it didn't received required votes within that time frame.
Its probably more helpful for cont
I¹m having an impression that KIP is mostly for new features but not for
bug fixes. But I agree with Joel that it might make sense to have some big
patches, even if they are bug fixes, to follow the KIP like process which
is more strict.
Jiangjie (Becket) Qin
On 2/5/15, 4:57 PM, "Gwen Shapira" w
> This is exactly my concern.
> Even now important patches and features have very long development and
> review cycles due to Kafka's small and very busy committer community. I
> feel that this change takes things in the wrong direction
I agree that we should improve on this. I think the only con
>
>
> Yes there are KIPs that are currently blocked on feedback/votes, but I
> don't think it is an issue of not caring to comment vs having so many
> KIPs and other code reviews in flight that people are just swamped.
>
>
This is exactly my concern.
Even now important patches and features have ver
Yes - I realized that afterward. It is back to plain lazy majority.
On Thu, Feb 05, 2015 at 04:33:48PM -0800, Jay Kreps wrote:
> Hey Joel,
>
> The problem with lazy consensus is that some people are too lazy. :-) I
> think the whole point of this is that you need to actively ensure people
> have
The original requirement was lazy majority of PMC which definitely
seems overly restrictive.
> Why not go with usual definition: "lazy" = "No strong objections for few
> days"?
> This means contributors will not be blocked on issues where no one cares to
> comment (and we had few of those).
I thi
Hey Joel,
The problem with lazy consensus is that some people are too lazy. :-) I
think the whole point of this is that you need to actively ensure people
have read and understand the change before you proceed. I basically think
all of us should be reading these proposals and giving feedback.
-Ja
Isn't requiring 3 binding votes a bit overly strict here? We are talking
about patches which in can be fixed, reverted, etc. Not releases, which
have legal implications.
Why not go with usual definition: "lazy" = "No strong objections for few
days"?
This means contributors will not be blocked on i
Sorry about this - I actually meant to suggest lazy consensus (which
is a stronger requirement): "3 binding +1 votes and no binding
vetoes."
I have updated the wiki to lazy consensus - but can change it back if
there is a reasonable objection.
On Thu, Feb 05, 2015 at 06:17:44PM -0500, Joe Stein w
+1
On Thu, Feb 5, 2015 at 6:16 PM, Neha Narkhede wrote:
> Sounds good.
>
> On Thu, Feb 5, 2015 at 2:35 PM, Jay Kreps wrote:
>
> > None on my part.
> >
> > -Jay
> >
> > On Thu, Feb 5, 2015 at 11:50 AM, Joel Koshy wrote:
> >
> > > One amendment I would like to bring up for consideration wrt the
Sounds good.
On Thu, Feb 5, 2015 at 2:35 PM, Jay Kreps wrote:
> None on my part.
>
> -Jay
>
> On Thu, Feb 5, 2015 at 11:50 AM, Joel Koshy wrote:
>
> > One amendment I would like to bring up for consideration wrt the KIP
> > process (before we formally include it in our by-laws) is to not
> > re
None on my part.
-Jay
On Thu, Feb 5, 2015 at 11:50 AM, Joel Koshy wrote:
> One amendment I would like to bring up for consideration wrt the KIP
> process (before we formally include it in our by-laws) is to not
> restrict the votes to be a lazy majority of the PMC, and to instead
> make it a la
One amendment I would like to bring up for consideration wrt the KIP
process (before we formally include it in our by-laws) is to not
restrict the votes to be a lazy majority of the PMC, and to instead
make it a lazy majority of committers.
Our current requirement for code changes per our by-laws
Sorry for late response, Magnus. See my comments inline:
On Fri, Jan 23, 2015 at 7:31 AM, Magnus Edenhill wrote:
> Wouldn't it make sense to move away from these rich binary broker
> descriptors ({ host, port, proto })
> (which require protocol churning on change), and simply use URIs instead?
W
Wouldn't it make sense to move away from these rich binary broker
descriptors ({ host, port, proto })
(which require protocol churning on change), and simply use URIs instead?
E.g.:
kafka://[:port]/ <-- cleantext proto on standard port 9092
kafkas://[:port] <-- SSL enveloped proto on s
Reviewed the latest patch in KAFKA-1809 :).
Thanks,
Jun
On Thu, Jan 22, 2015 at 12:38 PM, Gwen Shapira
wrote:
> Thanks for validating our ideas. Updated the KIP with the workflow.
>
> Now if you can nudge Jun to review the latest patch... ;)
>
>
> On Thu, Jan 22, 2015 at 11:44 AM, Jay Kreps w
Thanks for validating our ideas. Updated the KIP with the workflow.
Now if you can nudge Jun to review the latest patch... ;)
On Thu, Jan 22, 2015 at 11:44 AM, Jay Kreps wrote:
> Oh yeah I think that is better, I hadn't thought of that approach! Any way
> you could describe the usage in the KIP
Oh yeah I think that is better, I hadn't thought of that approach! Any way
you could describe the usage in the KIP, just for completeness?
-Jay
On Thu, Jan 22, 2015 at 10:23 AM, Gwen Shapira
wrote:
> I think what you described was the original design, so no wonder you
> are confused :)
>
> Foll
I think what you described was the original design, so no wonder you
are confused :)
Following suggestions from Jun, I changed it a bit. The current model is:
- Clients (producers and consumers) need to know about the broker
ports in advance. They don't need to know about all brokers, but they
ne
I think I am still confused. In addition to the UpdateMetadataRequest don't
we have to change the MetadataResponse so that it's possible for clients to
discover the new ports? Or is that a second phase? I was imagining it
worked by basically allowing the brokers to advertise multiple ports, one
per
Good point :)
I added the specifics of the new UpdateMetadataRequest, which is the
only protocol bump in this change.
Highlighted the broker and producer/consumer configuration changes,
added some example values and added the new zookeeper json.
Hope this makes things clearer.
On Wed, Jan 21,
Hey Gwen,
Could we get the actual changes in that KIP? I.e. changes to metadata
request, changes to UpdateMetadataRequest, new configs and what will their
valid values be, etc. This kind of says that those things will change but
doesn't say what they will change to...
-Jay
On Mon, Jan 19, 2015 a
I created a KIP for the multi-port broker change.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-2+-+Refactor+brokers+to+allow+listening+on+multiple+ports+and+IPs
I'm not re-opening the discussion, since it was agreed on over a month
ago and implementation is close to complete (I hope!). Le
Great! Sounds like everyone is on the same page
- I created a template page to make things easier. If you do Tools->Copy
on this page you can just fill in the italic portions with your details.
- I retrofitted KIP-1 to match this formatting
- I added the metadata section people asked f
+1
Will be happy to provide a KIP for the multiple-listeners patch.
Gwen
On Sat, Jan 17, 2015 at 8:10 AM, Joe Stein wrote:
> +1 to everything we have been saying and where this (has settled to)/(is
> settling to).
>
> I am sure other folks have some more feedback and think we should try to
> ke
+1 to everything we have been saying and where this (has settled to)/(is
settling to).
I am sure other folks have some more feedback and think we should try to
keep this discussion going if need be. I am also a firm believer of form
following function so kicking the tires some to flesh out the det
+1 on the idea, and we could mutually link the KIP wiki page with the the
created JIRA ticket (i.e. include the JIRA number on the page and the KIP
url on the ticket description).
Regarding the KIP process, probably we do not need two phase communication
of a [DISCUSS] followed by [VOTE], as Jay s
+1 to Ewen's suggestions: Deprecation, status and version.
Perhaps add the JIRA where the KIP was implemented to the metadata.
This will help tie things together.
On Fri, Jan 16, 2015 at 9:35 AM, Ewen Cheslack-Postava
wrote:
> I think adding a section about deprecation would be helpful. A good
>
I think adding a section about deprecation would be helpful. A good
fraction of the time I would expect the goal of a KIP is to fix or replace
older functionality that needs continued support for compatibility, but
should eventually be phased out. This helps Kafka devs understand how long
they'll e
I'm definitely +1 on the KIP concept. As Joe mentioned, we are already
doing this in one form or the other. However, IMO it is fairly ad hoc
- i.e., a combination of DISCUSS threads, jira comments, RB and code
comments, wikis and html documentation. In the past I have had to dig
into a bunch of the
Hey Joe,
Yeah I guess the question is what is the definition of major? I agree we
definitely don't want to generate a bunch of paperwork. We have enough
problems just getting all the contributions reviewed and checked in in a
timely fashion...
So obviously bug fixes would not apply here.
I think
Thanks Jay for kicking this off! I think the confluence page you wrote up
is a great start.
The KIP makes sense to me (at a minimum) if there is going to be any
"breaking change". This way Kafka can continue to grow and blossom and we
have a process in place if we are going to release a thorn ...
The idea of KIPs came up in a previous discussion but there was no real
crisp definition of what they were. Here is an attempt at defining a
process:
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
The trick here is to have something light-weight enough that it isn't
44 matches
Mail list logo
