You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Gwen Shapira <gw...@confluent.io> on 2016/04/01 19:54:06 UTC
[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-metadata-update
KIP-35 (version protocol)
KIP-33 (time-based indexes)
KIP-43 (flexible SASL)
KIP-50 (Tiny ACL API change)
KIP-51 (small KafkaConnect API change)
Committers and contributors: Please stay on top of reviews and discussions.
Lets keep the awesome forward momentum we have going!
Yours,
Gwen Shapira
Temporary Release Manager
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Gwen Shapira <gw...@confluent.io>.
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 <ja...@confluent.io> 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,
> though it may need adjustment depending on the discussion.
>
> Thanks,
> Jason
>
> On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > 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" <gw...@confluent.io> wrote:
> >
> > > 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-metadata-update
> > > KIP-35 (version protocol)
> > > KIP-33 (time-based indexes)
> > > KIP-43 (flexible SASL)
> > > KIP-50 (Tiny ACL API change)
> > > KIP-51 (small KafkaConnect API change)
> > >
> > > Committers and contributors: Please stay on top of reviews and
> > discussions.
> > > Lets keep the awesome forward momentum we have going!
> > >
> > > Yours,
> > >
> > > Gwen Shapira
> > > Temporary Release Manager
> > >
> >
>
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Stevo Slavić <ss...@gmail.com>.
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 be possible to get it and other non-controversial new features and
fixes shipped sooner?
Kind regards,
Stevo Slavic.
On Mon, Apr 4, 2016 at 5:07 AM, Ewen Cheslack-Postava <ew...@confluent.io>
wrote:
> 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, 2016 at 1:06 PM, Guozhang Wang <wa...@gmail.com> wrote:
>
> > Sounds good.
> >
> > On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira <gw...@confluent.io> 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 <is...@gmail.com>
> 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 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 something along those lines.
> > > >
> > > > Guozhang, we could delete the branch, but users could be relying on
> it
> > > and
> > > > hence I am not sure we should do that.
> > > >
> > > > Ismael
> > > > On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
> > > >
> > > > > 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 <wangguoz@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > 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 <
> > jason@confluent.io
> > > >
> > > > > > 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,
> > > > > > > though it may need adjustment depending on the discussion.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Jason
> > > > > > >
> > > > > > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <
> ismael@juma.me.uk>
> > > > > wrote:
> > > > > > >
> > > > > > > > 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" <gw...@confluent.io>
> wrote:
> > > > > > > >
> > > > > > > > > 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-metadata-update
> > > > > > > > > KIP-35 (version protocol)
> > > > > > > > > KIP-33 (time-based indexes)
> > > > > > > > > KIP-43 (flexible SASL)
> > > > > > > > > KIP-50 (Tiny ACL API change)
> > > > > > > > > KIP-51 (small KafkaConnect API change)
> > > > > > > > >
> > > > > > > > > Committers and contributors: Please stay on top of reviews
> > and
> > > > > > > > discussions.
> > > > > > > > > Lets keep the awesome forward momentum we have going!
> > > > > > > > >
> > > > > > > > > Yours,
> > > > > > > > >
> > > > > > > > > Gwen Shapira
> > > > > > > > > Temporary Release Manager
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > -- Guozhang
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>
>
>
> --
> Thanks,
> Ewen
>
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Ismael Juma <is...@gmail.com>.
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 21:26, "Ewen Cheslack-Postava" <ew...@confluent.io> wrote:
> 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 is
> empty, then I guess we're ok not testing both for the moment.
>
> -Ewen
>
> On Mon, Apr 4, 2016 at 10:08 AM, Guozhang Wang <wa...@gmail.com> wrote:
>
> > 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 <is...@juma.me.uk> 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, Ewen Cheslack-Postava <
> ewen@confluent.io
> > >
> > > wrote:
> > >
> > > > 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, 2016 at 1:06 PM, Guozhang Wang <wa...@gmail.com>
> > > wrote:
> > > >
> > > > > Sounds good.
> > > > >
> > > > > On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira <gw...@confluent.io>
> > > 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 <is...@gmail.com>
> > > > 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
> > 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 something along those lines.
> > > > > > >
> > > > > > > Guozhang, we could delete the branch, but users could be
> relying
> > on
> > > > it
> > > > > > and
> > > > > > > hence I am not sure we should do that.
> > > > > > >
> > > > > > > Ismael
> > > > > > > On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
> > > > > > >
> > > > > > > > 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 <
> > > wangguoz@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > jason@confluent.io
> > > > > > >
> > > > > > > > > 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,
> > > > > > > > > > though it may need adjustment depending on the
> discussion.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Jason
> > > > > > > > > >
> > > > > > > > > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <
> > > > ismael@juma.me.uk>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > 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" <gwen@confluent.io
> >
> > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > 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-metadata-update
> > > > > > > > > > > > KIP-35 (version protocol)
> > > > > > > > > > > > KIP-33 (time-based indexes)
> > > > > > > > > > > > KIP-43 (flexible SASL)
> > > > > > > > > > > > KIP-50 (Tiny ACL API change)
> > > > > > > > > > > > KIP-51 (small KafkaConnect API change)
> > > > > > > > > > > >
> > > > > > > > > > > > Committers and contributors: Please stay on top of
> > > reviews
> > > > > and
> > > > > > > > > > > discussions.
> > > > > > > > > > > > Lets keep the awesome forward momentum we have going!
> > > > > > > > > > > >
> > > > > > > > > > > > Yours,
> > > > > > > > > > > >
> > > > > > > > > > > > Gwen Shapira
> > > > > > > > > > > > Temporary Release Manager
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > -- Guozhang
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -- Guozhang
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks,
> > > > Ewen
> > > >
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>
>
>
> --
> Thanks,
> Ewen
>
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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 is
empty, then I guess we're ok not testing both for the moment.
-Ewen
On Mon, Apr 4, 2016 at 10:08 AM, Guozhang Wang <wa...@gmail.com> wrote:
> 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 <is...@juma.me.uk> 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, Ewen Cheslack-Postava <ewen@confluent.io
> >
> > wrote:
> >
> > > 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, 2016 at 1:06 PM, Guozhang Wang <wa...@gmail.com>
> > wrote:
> > >
> > > > Sounds good.
> > > >
> > > > On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira <gw...@confluent.io>
> > 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 <is...@gmail.com>
> > > 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
> 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 something along those lines.
> > > > > >
> > > > > > Guozhang, we could delete the branch, but users could be relying
> on
> > > it
> > > > > and
> > > > > > hence I am not sure we should do that.
> > > > > >
> > > > > > Ismael
> > > > > > On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
> > > > > >
> > > > > > > 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 <
> > wangguoz@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > 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 <
> > > > jason@confluent.io
> > > > > >
> > > > > > > > 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,
> > > > > > > > > though it may need adjustment depending on the discussion.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Jason
> > > > > > > > >
> > > > > > > > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <
> > > ismael@juma.me.uk>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > 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" <gw...@confluent.io>
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > > 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-metadata-update
> > > > > > > > > > > KIP-35 (version protocol)
> > > > > > > > > > > KIP-33 (time-based indexes)
> > > > > > > > > > > KIP-43 (flexible SASL)
> > > > > > > > > > > KIP-50 (Tiny ACL API change)
> > > > > > > > > > > KIP-51 (small KafkaConnect API change)
> > > > > > > > > > >
> > > > > > > > > > > Committers and contributors: Please stay on top of
> > reviews
> > > > and
> > > > > > > > > > discussions.
> > > > > > > > > > > Lets keep the awesome forward momentum we have going!
> > > > > > > > > > >
> > > > > > > > > > > Yours,
> > > > > > > > > > >
> > > > > > > > > > > Gwen Shapira
> > > > > > > > > > > Temporary Release Manager
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > -- Guozhang
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > -- Guozhang
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Ewen
> > >
> >
>
>
>
> --
> -- Guozhang
>
--
Thanks,
Ewen
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Guozhang Wang <wa...@gmail.com>.
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 <is...@juma.me.uk> 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, Ewen Cheslack-Postava <ew...@confluent.io>
> wrote:
>
> > 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, 2016 at 1:06 PM, Guozhang Wang <wa...@gmail.com>
> wrote:
> >
> > > Sounds good.
> > >
> > > On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira <gw...@confluent.io>
> 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 <is...@gmail.com>
> > 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 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 something along those lines.
> > > > >
> > > > > Guozhang, we could delete the branch, but users could be relying on
> > it
> > > > and
> > > > > hence I am not sure we should do that.
> > > > >
> > > > > Ismael
> > > > > On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
> > > > >
> > > > > > 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 <
> wangguoz@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > 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 <
> > > jason@confluent.io
> > > > >
> > > > > > > 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,
> > > > > > > > though it may need adjustment depending on the discussion.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jason
> > > > > > > >
> > > > > > > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <
> > ismael@juma.me.uk>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > 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" <gw...@confluent.io>
> > wrote:
> > > > > > > > >
> > > > > > > > > > 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-metadata-update
> > > > > > > > > > KIP-35 (version protocol)
> > > > > > > > > > KIP-33 (time-based indexes)
> > > > > > > > > > KIP-43 (flexible SASL)
> > > > > > > > > > KIP-50 (Tiny ACL API change)
> > > > > > > > > > KIP-51 (small KafkaConnect API change)
> > > > > > > > > >
> > > > > > > > > > Committers and contributors: Please stay on top of
> reviews
> > > and
> > > > > > > > > discussions.
> > > > > > > > > > Lets keep the awesome forward momentum we have going!
> > > > > > > > > >
> > > > > > > > > > Yours,
> > > > > > > > > >
> > > > > > > > > > Gwen Shapira
> > > > > > > > > > Temporary Release Manager
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > -- Guozhang
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -- Guozhang
> > >
> >
> >
> >
> > --
> > Thanks,
> > Ewen
> >
>
--
-- Guozhang
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Ismael Juma <is...@juma.me.uk>.
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 <ew...@confluent.io>
wrote:
> 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, 2016 at 1:06 PM, Guozhang Wang <wa...@gmail.com> wrote:
>
> > Sounds good.
> >
> > On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira <gw...@confluent.io> 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 <is...@gmail.com>
> 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 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 something along those lines.
> > > >
> > > > Guozhang, we could delete the branch, but users could be relying on
> it
> > > and
> > > > hence I am not sure we should do that.
> > > >
> > > > Ismael
> > > > On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
> > > >
> > > > > 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 <wangguoz@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > 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 <
> > jason@confluent.io
> > > >
> > > > > > 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,
> > > > > > > though it may need adjustment depending on the discussion.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Jason
> > > > > > >
> > > > > > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <
> ismael@juma.me.uk>
> > > > > wrote:
> > > > > > >
> > > > > > > > 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" <gw...@confluent.io>
> wrote:
> > > > > > > >
> > > > > > > > > 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-metadata-update
> > > > > > > > > KIP-35 (version protocol)
> > > > > > > > > KIP-33 (time-based indexes)
> > > > > > > > > KIP-43 (flexible SASL)
> > > > > > > > > KIP-50 (Tiny ACL API change)
> > > > > > > > > KIP-51 (small KafkaConnect API change)
> > > > > > > > >
> > > > > > > > > Committers and contributors: Please stay on top of reviews
> > and
> > > > > > > > discussions.
> > > > > > > > > Lets keep the awesome forward momentum we have going!
> > > > > > > > >
> > > > > > > > > Yours,
> > > > > > > > >
> > > > > > > > > Gwen Shapira
> > > > > > > > > Temporary Release Manager
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > -- Guozhang
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>
>
>
> --
> Thanks,
> Ewen
>
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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, 2016 at 1:06 PM, Guozhang Wang <wa...@gmail.com> wrote:
> Sounds good.
>
> On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira <gw...@confluent.io> 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 <is...@gmail.com> 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 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 something along those lines.
> > >
> > > Guozhang, we could delete the branch, but users could be relying on it
> > and
> > > hence I am not sure we should do that.
> > >
> > > Ismael
> > > On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
> > >
> > > > 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 <wa...@gmail.com>
> > > wrote:
> > > >
> > > > > 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 <
> jason@confluent.io
> > >
> > > > > 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,
> > > > > > though it may need adjustment depending on the discussion.
> > > > > >
> > > > > > Thanks,
> > > > > > Jason
> > > > > >
> > > > > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <is...@juma.me.uk>
> > > > wrote:
> > > > > >
> > > > > > > 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" <gw...@confluent.io> wrote:
> > > > > > >
> > > > > > > > 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-metadata-update
> > > > > > > > KIP-35 (version protocol)
> > > > > > > > KIP-33 (time-based indexes)
> > > > > > > > KIP-43 (flexible SASL)
> > > > > > > > KIP-50 (Tiny ACL API change)
> > > > > > > > KIP-51 (small KafkaConnect API change)
> > > > > > > >
> > > > > > > > Committers and contributors: Please stay on top of reviews
> and
> > > > > > > discussions.
> > > > > > > > Lets keep the awesome forward momentum we have going!
> > > > > > > >
> > > > > > > > Yours,
> > > > > > > >
> > > > > > > > Gwen Shapira
> > > > > > > > Temporary Release Manager
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -- Guozhang
> > > > >
> > > >
> > >
> >
>
>
>
> --
> -- Guozhang
>
--
Thanks,
Ewen
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Guozhang Wang <wa...@gmail.com>.
Sounds good.
On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira <gw...@confluent.io> 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 <is...@gmail.com> 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 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 something along those lines.
> >
> > Guozhang, we could delete the branch, but users could be relying on it
> and
> > hence I am not sure we should do that.
> >
> > Ismael
> > On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
> >
> > > 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 <wa...@gmail.com>
> > wrote:
> > >
> > > > 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 <jason@confluent.io
> >
> > > > 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,
> > > > > though it may need adjustment depending on the discussion.
> > > > >
> > > > > Thanks,
> > > > > Jason
> > > > >
> > > > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <is...@juma.me.uk>
> > > wrote:
> > > > >
> > > > > > 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" <gw...@confluent.io> wrote:
> > > > > >
> > > > > > > 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-metadata-update
> > > > > > > KIP-35 (version protocol)
> > > > > > > KIP-33 (time-based indexes)
> > > > > > > KIP-43 (flexible SASL)
> > > > > > > KIP-50 (Tiny ACL API change)
> > > > > > > KIP-51 (small KafkaConnect API change)
> > > > > > >
> > > > > > > Committers and contributors: Please stay on top of reviews and
> > > > > > discussions.
> > > > > > > Lets keep the awesome forward momentum we have going!
> > > > > > >
> > > > > > > Yours,
> > > > > > >
> > > > > > > Gwen Shapira
> > > > > > > Temporary Release Manager
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > -- Guozhang
> > > >
> > >
> >
>
--
-- Guozhang
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Gwen Shapira <gw...@confluent.io>.
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 <is...@gmail.com> 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 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 something along those lines.
>
> Guozhang, we could delete the branch, but users could be relying on it and
> hence I am not sure we should do that.
>
> Ismael
> On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
>
> > 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 <wa...@gmail.com>
> wrote:
> >
> > > 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 <ja...@confluent.io>
> > > 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,
> > > > though it may need adjustment depending on the discussion.
> > > >
> > > > Thanks,
> > > > Jason
> > > >
> > > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <is...@juma.me.uk>
> > wrote:
> > > >
> > > > > 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" <gw...@confluent.io> wrote:
> > > > >
> > > > > > 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-metadata-update
> > > > > > KIP-35 (version protocol)
> > > > > > KIP-33 (time-based indexes)
> > > > > > KIP-43 (flexible SASL)
> > > > > > KIP-50 (Tiny ACL API change)
> > > > > > KIP-51 (small KafkaConnect API change)
> > > > > >
> > > > > > Committers and contributors: Please stay on top of reviews and
> > > > > discussions.
> > > > > > Lets keep the awesome forward momentum we have going!
> > > > > >
> > > > > > Yours,
> > > > > >
> > > > > > Gwen Shapira
> > > > > > Temporary Release Manager
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -- Guozhang
> > >
> >
>
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Ismael Juma <is...@gmail.com>.
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 something along those lines.
Guozhang, we could delete the branch, but users could be relying on it and
hence I am not sure we should do that.
Ismael
On 1 Apr 2016 19:44, "Gwen Shapira" <gw...@confluent.io> wrote:
> 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 <wa...@gmail.com> wrote:
>
> > 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 <ja...@confluent.io>
> > 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,
> > > though it may need adjustment depending on the discussion.
> > >
> > > Thanks,
> > > Jason
> > >
> > > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <is...@juma.me.uk>
> wrote:
> > >
> > > > 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" <gw...@confluent.io> wrote:
> > > >
> > > > > 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-metadata-update
> > > > > KIP-35 (version protocol)
> > > > > KIP-33 (time-based indexes)
> > > > > KIP-43 (flexible SASL)
> > > > > KIP-50 (Tiny ACL API change)
> > > > > KIP-51 (small KafkaConnect API change)
> > > > >
> > > > > Committers and contributors: Please stay on top of reviews and
> > > > discussions.
> > > > > Lets keep the awesome forward momentum we have going!
> > > > >
> > > > > Yours,
> > > > >
> > > > > Gwen Shapira
> > > > > Temporary Release Manager
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Gwen Shapira <gw...@confluent.io>.
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 <wa...@gmail.com> wrote:
> 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 <ja...@confluent.io>
> 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,
> > though it may need adjustment depending on the discussion.
> >
> > Thanks,
> > Jason
> >
> > On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > 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" <gw...@confluent.io> wrote:
> > >
> > > > 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-metadata-update
> > > > KIP-35 (version protocol)
> > > > KIP-33 (time-based indexes)
> > > > KIP-43 (flexible SASL)
> > > > KIP-50 (Tiny ACL API change)
> > > > KIP-51 (small KafkaConnect API change)
> > > >
> > > > Committers and contributors: Please stay on top of reviews and
> > > discussions.
> > > > Lets keep the awesome forward momentum we have going!
> > > >
> > > > Yours,
> > > >
> > > > Gwen Shapira
> > > > Temporary Release Manager
> > > >
> > >
> >
>
>
>
> --
> -- Guozhang
>
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Guozhang Wang <wa...@gmail.com>.
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 <ja...@confluent.io> 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,
> though it may need adjustment depending on the discussion.
>
> Thanks,
> Jason
>
> On Fri, Apr 1, 2016 at 11:09 AM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > 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" <gw...@confluent.io> wrote:
> >
> > > 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-metadata-update
> > > KIP-35 (version protocol)
> > > KIP-33 (time-based indexes)
> > > KIP-43 (flexible SASL)
> > > KIP-50 (Tiny ACL API change)
> > > KIP-51 (small KafkaConnect API change)
> > >
> > > Committers and contributors: Please stay on top of reviews and
> > discussions.
> > > Lets keep the awesome forward momentum we have going!
> > >
> > > Yours,
> > >
> > > Gwen Shapira
> > > Temporary Release Manager
> > >
> >
>
--
-- Guozhang
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Jason Gustafson <ja...@confluent.io>.
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 <is...@juma.me.uk> wrote:
> 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" <gw...@confluent.io> wrote:
>
> > 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-metadata-update
> > KIP-35 (version protocol)
> > KIP-33 (time-based indexes)
> > KIP-43 (flexible SASL)
> > KIP-50 (Tiny ACL API change)
> > KIP-51 (small KafkaConnect API change)
> >
> > Committers and contributors: Please stay on top of reviews and
> discussions.
> > Lets keep the awesome forward momentum we have going!
> >
> > Yours,
> >
> > Gwen Shapira
> > Temporary Release Manager
> >
>
Re: [RELEASE UPDATE] Postponing the next release candidates and
canceling current vote
Posted by Ismael Juma <is...@juma.me.uk>.
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" <gw...@confluent.io> wrote:
> 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-metadata-update
> KIP-35 (version protocol)
> KIP-33 (time-based indexes)
> KIP-43 (flexible SASL)
> KIP-50 (Tiny ACL API change)
> KIP-51 (small KafkaConnect API change)
>
> Committers and contributors: Please stay on top of reviews and discussions.
> Lets keep the awesome forward momentum we have going!
>
> Yours,
>
> Gwen Shapira
> Temporary Release Manager
>