I agree that a beta for 0.8.2 would be useful. It would also be good to get it in production at LinkedIn before the final version.
Sorry about stalling on the security stuff. Things have been a little busy on our side. Let's get 0.8.2 out and then get that broken up into individual JIRAs that people can take on. -Jay On Wed, Sep 10, 2014 at 5:11 PM, Jun Rao <jun...@gmail.com> wrote: > Joe, > > Thanks for starting the discussion. > > (1) I made a pass of the open jiras for 0.8.2 and marked a few of them as > blockers for now. There are currently 6 blockers. Ideally, we want to get > all those fixed before cutting the 0.8.2 branch. The rest of the jiras > don't really have to be fixed in 0.8.2. So, if anyone wants to help on > fixing those blocker jiras, that would be great. Perhaps we can circle back > in a couple of weeks and see how much progress we make on those blocker > jiras. > > (2) A beta 0.8.2 may not be a bad idea. > > (3) We can do 0.8.1.2. However, I'd prefer only trivial and critical > patches to back port. The scala 2.11 patch seems ok. > > (4) Yes, we should start updating the wiki once 0.8.2 is cut. > > (5) Yes, we can include kafka-1555 if it can be fixed in time. > > 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> >> ********************************************/ >>
