+1 on 0.8.3-SNAPSHOT. On 9/29/14 11:40 AM, "Neha Narkhede" <neha.narkh...@gmail.com> wrote:
>2) change trunk to be 0.9-SNAPSHOT (or 0.8.3-SNAPSHOT or whatever). > >I'd vote for changing trunk to 0.8.3-SNAPSHOT. I imagine it will be useful >to have 0.8.3 released with some features and bug fixes that we are >pushing >out of 0.8.2. It will be a while before we get to a point where we can >release 0.9 with the new consumer. > >Thanks, >Neha > >On Mon, Sep 29, 2014 at 8:13 AM, Joe Stein <joe.st...@stealth.ly> wrote: > >> Agreed, I am +1 on creating the branch. >> >> Three thoughts on the branching >> 1) we should change the version to be 0.8.2.0 (from 0.8.2-SNAPSHOT) on >>the >> 0.8.2 branch after the branch is created. >> 2) change trunk to be 0.9-SNAPSHOT (or 0.8.3-SNAPSHOT or whatever). >> 3) after we branch I will prepare a build and stage to maven for a "none >> official release candidate" so folks can start to play with it for real >> (and make sure all the release steps work) and see whatever other issues >> come up before we get to a release candidate and get the other blockers >> done. >> >> /******************************************* >> Joe Stein >> Founder, Principal Consultant >> Big Data Open Source Security LLC >> http://www.stealth.ly >> Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> >> ********************************************/ >> >> On Mon, Sep 29, 2014 at 11:00 AM, Neha Narkhede >><neha.narkh...@gmail.com> >> wrote: >> >> > Thanks for making a pass of the open issues, Jun. I agree that it's >>not >> > worth blocking 0.8.2 more and we can push auto preferred replica >>election >> > to 0.8.3. I'm a +1 on cutting the branch. >> > >> > On Sun, Sep 28, 2014 at 6:03 PM, Jun Rao <jun...@gmail.com> wrote: >> > >> > > Hi, everyone, >> > > >> > > I made another pass of the blockers for 0.8.2. >> > > >> > > >> > > >> > >> >>https://issues.apache.org/jira/browse/KAFKA-1634?filter=-4&jql=project%20 >>%3D%20KAFKA%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reo >>pened%2C%20%22Patch%20Available%22)%20AND%20priority%20%3D%20Blocker%20AN >>D%20fixVersion%20%3D%200.8.2%20ORDER%20BY%20createdDate%20DESC >> > > >> > > There are currently 7 blockers. >> > > >> > > kafka-1558 and kafka-1600 are both related to deleting topics. Since >> most >> > > tests seem to work, they may not be real blockers. >> > > kafka-1493 (lz4 compression) and kafka-1305 (auto preferred leader >> > > balancing) likely won't be fixed on time. We can just disable the >> > features >> > > in 0.8.2. >> > > kafka-1577 and kafka-1618 should be easy to fix. >> > > kafka-1634 may need a bit more discussion. >> > > >> > > Just so that we don't delay 0.8.2 release for too long and also >>open up >> > > trunk for major development, I suggest that we cut the 0.8.2 branch >>by >> > end >> > > of this Monday. After that, we will do double commit for any patch >>that >> > > needs to go into both 0.8.2 and trunk. Any objection? >> > > >> > > Thanks, >> > > >> > > Jun >> > > >> > > >> > > On Wed, Sep 3, 2014 at 6:34 PM, Joe Stein <joe.st...@stealth.ly> >> wrote: >> > > >> > > > Hey, I wanted to take a quick pulse to see if we are getting >>closer >> to >> > a >> > > > branch for 0.8.2. >> > > > >> > > > 1) There still seems to be a lot of open issues >> > > > >> > > > >> > > >> > >> >>https://issues.apache.org/jira/browse/KAFKA/fixforversion/12326167/?selec >>tedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >> > > > and our 30 day summary is showing issues: 51 created and *34* >> resolved >> > > and >> > > > not >> > > > sure how much of that we could really just decide to push off to >> 0.8.3 >> > or >> > > > 0.9.0 vs working on 0.8.2 as stable for release. There is >>already so >> > > much >> > > > goodness on trunk. I appreciate the double commit pain >>especially as >> > > trunk >> > > > and branch drift (ugh). >> > > > >> > > > 2) Also, I wanted to float the idea of after making the 0.8.2 >>branch >> > > that I >> > > > would do some unofficial release candidates for folks to test >>prior >> to >> > > > release and vote. What I was thinking was I would build, upload >>and >> > > stage >> > > > like I was preparing artifacts for vote but let the community >>know to >> > go >> > > in >> > > > and "have at it" well prior to the vote release. We don't get a >>lot >> of >> > > > community votes during a release but issues after (which is >>natural >> > > because >> > > > of how things are done). I have seen four Apache projects doing >>this >> > > very >> > > > successfully not only have they had less iterations of RC votes >> > > (sensitive >> > > > to that myself) but the community kicked back issues they saw by >> giving >> > > > them some "pre release" time to go through their own test and >>staging >> > > > environments as the release are coming about. >> > > > >> > > > 3) Checking again on "should we have a 0.8.1.2" release if folks >>in >> the >> > > > community find important features (this might be best asked on the >> user >> > > > list maybe not sure) they don't want/can't wait for which >>wouldn't be >> > too >> > > > much pain/dangerous to back port. Two things that spring to the >>top >> of >> > my >> > > > head are 2.11 Scala support and fixing the source jars. Both of >> these >> > > are >> > > > easy to patch personally I don't mind but want to gauge more from >>the >> > > > community on this too. I have heard gripes ad hoc from folks in >> direct >> > > > communication but no complains really in the public forum and >>wanted >> to >> > > > open the floor if folks had a need. >> > > > >> > > > 4) 0.9 work I feel is being held up some (or at least resourcing >>it >> > from >> > > my >> > > > perspective). We decided to hold up including SSL (even though we >> > have a >> > > > path for it). Jay did a nice update recently to the Security wiki >> > which I >> > > > think we should move forward with. I have some more to >> > add/change/update >> > > > and want to start getting down to more details and getting >>specific >> > > people >> > > > working on specific tasks but without knowing what we are doing >>when >> it >> > > is >> > > > hard to manage. >> > > > >> > > > 5) I just updated >>https://issues.apache.org/jira/browse/KAFKA-1555 I >> > > think >> > > > it is a really important feature update doesn't have to be in >>0.8.2 >> but >> > > we >> > > > need consensus (no pun intended). It fundamentally allows for >>data in >> > min >> > > > two rack requirement which A LOT of data requires for successful >>save >> > to >> > > > occur. >> > > > >> > > > /******************************************* >> > > > Joe Stein >> > > > Founder, Principal Consultant >> > > > Big Data Open Source Security LLC >> > > > http://www.stealth.ly >> > > > Twitter: @allthingshadoop >><http://www.twitter.com/allthingshadoop> >> > > > ********************************************/ >> > > > >> > > >> > >>
