Thanks Jun! I created 0.8.3 in JIRA too just now. - Joestein
On Tue, Sep 30, 2014 at 11:15 AM, Jun Rao <jun...@gmail.com> wrote: > I just created the 0.8.2 branch and bumped up the version in trunk to > 0.8.3. > > Thanks, > > Jun > > On Mon, Sep 29, 2014 at 11:43 AM, Sriram Subramanian < > srsubraman...@linkedin.com.invalid> wrote: > > > +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> > > >> > > > ********************************************/ > > >> > > > > > >> > > > > >> > > > >> > > > > >
