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%20Reopened%2C%20%22Patch%20Available%22)%20AND%20priority%20%3D%20Blocker%20AND%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/?selectedTab=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> > > > > ********************************************/ > > > > > > > > > >
