Just made a pass over the unresolved tickets tagged for 0.8.2, I think many of them can be pushed to 0.8.3 / 0.9.
On Wed, Sep 3, 2014 at 8:05 PM, Jonathan Weeks <jonathanbwe...@gmail.com> wrote: > > +1 on a 0.8.1.2 release as described. > > I manually applied patches to cobble together a working gradle build for > kafka for scala 2.11, but would really appreciate an official release — > i.e. 0.8.1.2, as we also have other dependent libraries we use as well > (e.g. akka-kafka) that would be much easier to migrate and support if the > build was public and official. > > There were at least several others on the “users” list that expressed > interest in scala 2.11 support, who knows how many more “lurkers” are out > there. > > Best Regards, > > -Jonathan > > > 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> > > ********************************************/ > -- -- Guozhang
