+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
