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 <wangg...@gmail.com> wrote: > Sounds good. > > On Fri, Apr 1, 2016 at 12:01 PM, Gwen Shapira <g...@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 <isma...@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" <g...@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 <wangg...@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 <ism...@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" <g...@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
