A few questions:
On Thu, Aug 15, 2013 at 5:57 PM, Andrew Purtell <[email protected]> wrote: > > My suggestion is that we limit the number of major features targeting > this version. > > +1 > > > Can we say Tags the only Major feature that must get in and then all > major features are not blockers? > > Core changes, you mean? One or perhaps two significant core changes could > be doable in the available time. Is there another besides tags/HFile V3? > > Something will likely show up -- I'm working on some API clean up currently which oddly will also affect the HFile format. > What I would consider a blocker would be a usability problem, a performance > regression, or an API, wire, or data compatibility regression. > > In my opinion, a new feature should be implemented within a well defined > space for that purpose: as a coprocessor, plugin, or as a feature of HFile > V3 (which I would like to make more pluggable, therefore extensible and > maintainable). I propose HFile V3 be included, marked as experimental > through the 0.98 cycle, with a feature freeze at the .0 release. > > Sounds reasonable. > > What do you think our planned 0.96 compat story is wrt 0.98? > > 0.96 and 0.98 should be able to run in a mixed server side environment > while a rolling upgrade is in progress, without limits imposed on how long > that might take. Perhaps 0.98 is deployed only to one table placement group > as a trial. With the caveat that new features might introduce > complications, continuing the example, a new HFile feature is enabled for a > table and placement group so the table can't be placed elsewhere. Clients > should be able to run in a mixed version environment indefinitely. > > I'd also like to do some API culling and simplification -- where would this go? Would 0.98 be branched off of trunk or 0.96 then? > > On Thu, Aug 15, 2013 at 1:25 PM, Jonathan Hsieh <[email protected]> wrote: > > > On Thu, Aug 15, 2013 at 12:21 PM, Andrew Purtell <[email protected] > > >wrote: > > > > > On the thread '[UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 > > > remaining issues', Stack, our RM for 0.95/0.96 has drawn the line on a > > > feature freeze and set a course for an 0.96 release to happen soon. > > Toward > > > the end of that thread there is a bit on beyond 0.96 that I have > included > > > below for your reference. To summarize the discussion points: > > > > > > - This is a call for an 0.98 major release in early October. Let's > > discuss > > > first if that timeframe is reasonable, and then what can and should go > > into > > > a new major release in this timeframe. > > > > > > +1 > > > > My suggestion is that we limit the number of major features targeting > this > > version. Can we say Tags the only Major feature that must get in and > then > > all major features are not blockers? > > > > What do you think our planned 0.96 compat story is wrt 0.98? This would > be > > a great opportunity to try see if the protobuf evolution path is what we > > hope it is. > > > > > > > > > - I have volunteered to manage this release. Let's discuss if there are > > > concerns or objections to that. > > > > > > +1 > > > > > > > Assuming there are no objections, in a few days I will adjust target > > > versions for 0.98 in JIRA, file any new issues as needed, and then > post a > > > summary here. I suggest looking at 0.98 through the lens of being the > > last > > > release before the big 1.0 event. Therefore, what should go in are > things > > > that almost made the 0.96 cut, and "1.0 necessary" features that, > first, > > > should be in a 1.0 product, and, second, could benefit from one release > > > cycle to bake. Once there is an 0.98 major release, I also suggest a > > > regular train of minor releases like what Lars has done for 0.94. > Also, I > > > don't think it necessary to decide today if a 0.98 release should > become > > > the 1.0 release directly, we will always have that option. I suggest > > > waiting to make that call until 0.98 releases are under test and > fielded. > > > > > > >>> > > > On Wed, Aug 14, 2013 at 1:26 PM, Andrew Purtell <[email protected]> > > > wrote: > > > > > > > On Wed, Aug 14, 2013 at 12:57 PM, Stack <[email protected]> wrote: > > > > > > > > > I see no reason that 0.98 cannot come out a week or a month after > > 0.96; > > > > > > > > tags is close and justification enough for a major release. > > > > > I propose Andrew as RM for 0.98/1.0.0 if he is up for taking it on. > > > > > > > > I would be pleased to volunteer to RM 0.98. > > > > > > Sounds good to me. Would suggest announcing your taking it up in a new > > > thread rather than down here in the middle of this one -- perhaps > > > soliciting if any objection? -- and maybe as part of a message > announcing > > > our starting up the 0.98 cycle. Good on you Andrew. > > > > > > > If I were to be your RM for 0.98, then I would suggest a .0 release > in > > > the > > > > beginning of October. There are 42 open issues against 0.98 > > specifically > > > > and I would like to also provide everyone some time for post 0.96 > > release > > > > thinking. > > > > > > Be aware that issues have been moved here just to get them out of 0.96. > > > Feel > > > free to punt them on again if not being worked on or not appropriate. > > > > > > We might want to put out a call for what folks think should be in a > > > release that > > > is slated for October -- or what they are working on and think they can > > > finish inside the October constraint. > > > > > > > I am not sure we should move from 0.98 to 1.0 without another interim > > > > release, that would be a call for a later time perhaps, maybe a 1.0 > > > release > > > > at the start of January 2014. > > > > > > Ok. Something to discuss. > > > <<< > > > > > > > > > -- > > > Best regards, > > > > > > - Andy > > > > > > Problems worthy of attack prove their worth by hitting back. - Piet > Hein > > > (via Tom White) > > > > > > > > > > > -- > > // Jonathan Hsieh (shay) > > // Software Engineer, Cloudera > > // [email protected] > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > -- // Jonathan Hsieh (shay) // Software Engineer, Cloudera // [email protected]
