hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: Thinking about 0.98
Date Thu, 22 Aug 2013 04:14:08 GMT
HBASE-9247.  (will post when I've cleaned it up moe)  Has to do with the
full comparator classnames being included in HFile's trailer and Bloom
block meta data.  I have a kludgy workaround for it now but if we are
updating file versions, it could be nice to unkludge it.


On Wed, Aug 21, 2013 at 7:18 PM, Andrew Purtell <apurtell@apache.org> wrote:

> >
> I'm working on some API clean up currently which oddly will also affect the
> HFile format.
>
> Can you point to a jira?
>
> > I'd also like to do some API culling and simplification -- where would
> this
> go?
>
> Since 0.98 is to come quickly after 0.96 and test our compatibility story,
> we should take this case by case. My feeling is if after the changes a 0.96
> client can still talk to a 0.98 server, and a mixed 0.96 and 0.98 server
> environment is still possible, then it could go into 0.98 even if it breaks
> Java binary compatibility for client applications, we're not at 1.0 yet.
> Any objections?
>
> >
> Would 0.98 be branched off of trunk or 0.96 then?
>
> I was thinking of branching 0.98 from trunk "soon" after 0.96 is released.
>
>
>
> On Wed, Aug 21, 2013 at 6:42 PM, Jonathan Hsieh <jon@cloudera.com> wrote:
>
> > A few questions:
> >
> >
> > On Thu, Aug 15, 2013 at 5:57 PM, Andrew Purtell <apurtell@apache.org>
> > 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 <jon@cloudera.com>
> > wrote:
> > >
> > > > On Thu, Aug 15, 2013 at 12:21 PM, Andrew Purtell <
> apurtell@apache.org
> > > > >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 <
> apurtell@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > On Wed, Aug 14, 2013 at 12:57 PM, Stack <stack@duboce.net>
> 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
> > > > // jon@cloudera.com
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // Software Engineer, Cloudera
> > // jon@cloudera.com
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message