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> > > > ********************************************/ > > > > > >