Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

It's true that the current situation is not so clear. Gwen, maybe we should do the initial merge of trunk to 0.10.0 soon to get them back in sync? Please let me know if you'd like some help (the first merge may not be completely straightforward although subsequent ones will). Ismael On 4 Apr 2016

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Ismael, Fair enough, I guess it doesn't matter if we're going to merge again -- then until we decide to branch we'll be back in sync. At the moment there's a pretty major diff between trunk and 0.10.0 and I'm not sure what went on only trunk and what went to 0.10.0 only. As long as the latter set

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Are there any commits that is only for 0.10.0 but not for trunk? Guozhang On Mon, Apr 4, 2016 at 4:24 AM, Ismael Juma wrote: > Hi Ewen, > > Do you mean issues related to versions (since that should be the only > difference between trunk and 0.10.0)? > > Ismael > > On Mon, Apr 4, 2016 at 4:07 AM

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Hi Ewen, Do you mean issues related to versions (since that should be the only difference between trunk and 0.10.0)? Ismael On Mon, Apr 4, 2016 at 4:07 AM, Ewen Cheslack-Postava wrote: > Just wanted to throw it out there that still double committing when the > committer remembers to do so is u

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Sad to see release got postponed. I was looking forward to rack aware replica assignment, to have HA support out of the box. It is hard to follow all the different discussions and what actually caused release to be postponed. Was rack aware feature one of the controversial features? If not would it

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Just wanted to throw it out there that still double committing when the committer remembers to do so is useful -- daily updates on unit tests (as flaky as they can be) and system tests are still useful to have. Better to catch any branch-specific issues as early as possible. -Ewen On Fri, Apr 1,

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Sounds good. On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira wrote: > I like the alternative. I'll be happy to do the weekly merges. > > Would be happy to hear other opinions. > > Gwen > > On Fri, Apr 1, 2016 at 11:55 AM, Ismael Juma wrote: > > > My concern is that this is error-prone and things

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

I like the alternative. I'll be happy to do the weekly merges. Would be happy to hear other opinions. Gwen On Fri, Apr 1, 2016 at 11:55 AM, Ismael Juma wrote: > My concern is that this is error-prone and things can be missed (it > happened during the 0.9.0.0 release for example). It's a cost w

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

My concern is that this is error-prone and things can be missed (it happened during the 0.9.0.0 release for example). It's a cost worth paying when stabilising but not so clear when accepting major new features. One alternative would be to just commit to trunk and merge trunk to 0.10.0 weekly or s

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

I prefer keeping the current branch and double-committing for three weeks. Not fun, but not end-of-world hard. Unless committers object? On Fri, Apr 1, 2016 at 11:40 AM, Guozhang Wang wrote: > Ismael, > > Shall we "delete" the 0.10.0 branch after going through its commits and > making sure all

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Ismael, Shall we "delete" the 0.10.0 branch after going through its commits and making sure all of them are already in trunk then? I think it is doable in github? Guozhang On Fri, Apr 1, 2016 at 11:24 AM, Jason Gustafson wrote: > Hey Gwen, > > KIP-52 would be nice to get in as well. It's a sma

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Sorry guys! KIP-51 is already in. I meant KIP-52! My mistake, Jason. On Fri, Apr 1, 2016 at 11:24 AM, Jason Gustafson wrote: > Hey Gwen, > > KIP-52 would be nice to get in as well. It's a small feature, but really > helpful for Connect users. A patch for the first half is already available, > t

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Hey Gwen, KIP-52 would be nice to get in as well. It's a small feature, but really helpful for Connect users. A patch for the first half is already available, though it may need adjustment depending on the discussion. Thanks, Jason On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma wrote: > Hi Gwen,

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Hi Gwen, What is the plan for the 0.10.0 branch? Double-committing seems a bit wasteful given this change. Ismael On 1 Apr 2016 18:54, "Gwen Shapira" wrote: > Hey Team Kafka, > > Per community discussion, I will not be rolling out a new candidate on > Monday. > > I will roll out the next relea

[RELEASE UPDATE] Postponing the next release candidates and canceling current vote

Hey Team Kafka, Per community discussion, I will not be rolling out a new candidate on Monday. I will roll out the next release candidate in three weeks: Friday, April 22. We can spend Kafka Summit discussing the quality of the release :) The goal is to get it the following improvements: KIP-4-m