+1 (non-binding) Ismael
On Mon, Mar 7, 2016 at 7:27 PM, Neha Narkhede <n...@confluent.io> wrote: > +1 (binding) > > On Mon, Mar 7, 2016 at 11:26 AM, Gwen Shapira <g...@confluent.io> wrote: > > > Hi Joe, > > > > The branch cutting means that new features will go into trunk, bug > > fixes will go into either trunk and branch or just trunk - depending > > on committer decision. Committers should take into consideration the > > importance of the fix vs the stability of the planned release. I don't > > have specific rules in mind - our committers have excellent judgement > > :) > > > > I hope this clarifies? > > > > Gwen > > > > > > > > On Mon, Mar 7, 2016 at 9:42 AM, Joe Stein <joe.st...@stealth.ly> wrote: > > > +1 > > > > > > quick question/definition for the release cut (assuming vote passes) > your > > > proposing please. > > > > > > Critical bug fixes for new features and regression or just regression > and > > > new feature can get pulled if not working right if less impactful to-do > > so? > > > Understandably that is dependent on the feature and/or fix but we have > a > > > bunch on the plan for > > > https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan > > and > > > is that the hard freeze? I think the producer and consumer interceptors > > are > > > part of streams so maybe just an update on that? > > > > > > +1 the timeline seems manageable and adjusting for what is released or > > not > > > doesn't affect the approach so g2g lots to get out > > > > > > for 0.11 I would like to suggest trying to nominate or if volunteer > > always > > > good a release manager along with what is being worked on and > collaborate > > > around for different KIP so folks know where to contribute and work > > > downstream too operational. > > > > > > ~ Joe Stein > > > > > > On Mon, Mar 7, 2016 at 12:27 PM, Gwen Shapira <g...@confluent.io> > wrote: > > > > > >> Greetings Kafka Developer Community, > > >> > > >> As you all know, we have few big features that are almost complete > > >> (Timestamps! Interceptors! Streams!). It is time to start planning our > > >> next release. > > >> > > >> I suggest the following: > > >> * Cut branches on March 21st > > >> * Publish the first release candidate the next day > > >> * Start testing, finding important issues, fixing them, rolling out > new > > >> releases > > >> * And eventually get a release candidate that we all agree is awesome > > >> enough to release. Hopefully this won't take too many iterations :) > > >> > > >> Note that this is a 2 weeks heads-up on branch cutting. After we cut > > >> branches, we will try to minimize cherrypicks to just critical bugs > > >> (because last major release was a bit insane). > > >> Therefore, if you have a feature that you really want to see in > > >> 0.10.0 - you'll need to have it committed by March 21st. As a curtesy > > >> to the release manager, if you have features that you are not planning > > >> on getting in for 0.10.0, please change the "fix version" field in > > >> JIRA accordingly. > > >> > > >> I will send a heads-up few days before cutting branches, to give > > >> everyone a chance to get stragglers in. > > >> > > >> The vote will be open for 72 hours. > > >> All in favor, please reply with +1. > > >> > > >> Gwen Shapira > > >> > > > > > > -- > Thanks, > Neha >
