hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: HBase releases...
Date Wed, 12 Oct 2011 06:59:28 GMT
> What I am thinking to nudge the 'feels right' point a bit sooner. :)


Concur.


> For example, what if we had branched right after coprocessors went in. Would
> that been useful?

From my point of view, coprocessors and security were two sides of the same coin, we just
implemented in phases to reap benefits of one independent of the other... and then coprocessors
took on a life of their own.

So I'd say 0.92 should have coprocessors AND security. But this is because of the prospect
of waiting a long time for another release after 0.92, if 0.92 were to only have coprocessors.


At this point HBASE-3025 and the RPC changes are basically there, so perhaps they can go in
and 0.92 can go out the door after one more round of pounding upon by all.


Best regards,


  - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)


----- Original Message -----
> From: lars hofhansl <lhofhansl@yahoo.com>
> To: "dev@hbase.apache.org" <dev@hbase.apache.org>
> Cc: 
> Sent: Wednesday, October 12, 2011 2:08 PM
> Subject: Re: HBase releases...
> 
>T hanks Jesse,
> 
> I think the 'it feels right' approach is a corner stone of open source 
> software.
> (Although the Linux kernel is pretty much time based now, but that's a
> different story).
> 
> So, I am not big fan of time based releases. What I am thinking to nudge the
> 'feels right' point a bit sooner. :)
> 
> Software engineers (me included) tend to want to cram as many features as 
> possible
> into a release and sometimes it is good to make this tendency conscious and to
> counter this a bit to avoid feature bloat. (not saying that is a problem in 
> HBase, just a general statement here).
> 
> As you point out there is a balance to find between few releases with lots of
> features for which users have to wait 12 or more months and releases that 
> don't add much value. We definitely want to avoid the latter.
> 
> And not all releases are the same size and we *have* to be able to integrate big
> features (such as coprocessors).
> Your formula below is good idea as it is used as a guiding post and we still
> follow the 'feels right' approach.
> 
> For example, what if we had branched right after coprocessors went in. Would
> that been useful?
> 
> -- Lars
> 
> 
> ----- Original Message -----
> From: Jesse Yates <jesse.k.yates@gmail.com>
> To: dev@hbase.apache.org
> Cc: 
> Sent: Tuesday, October 11, 2011 10:42 PM
> Subject: Re: HBase releases...
> 
> I see a couple other dimensions as well, and mostly they revolve around the
> user community.
> 
> If we can release more frequently, with truly stable releases, then more
> people will be more likely to run clusters with codebases that are closer to
> trunk. Therefore they will have more benefits like bug fixes and performance
> increases without the worry that they are running unstable/buggy code.
> However, there is a big 'if' here - if we can make sure that the builds 
> that
> go out frequently are really rock solid.
> 
> I think in the past we have had a good track record with putting out stable
> releases, especially given the amount of testing that people in dev are
> doing on real, big clusters (thanks everyone!).
> 
> This then presents the problem of maintaining a _ton_ of branches compounded
> by the difficulty of adding in a sweeping feature (coprocessor-style). That
> was a huge pain to integrate (awesome job getting it in - super excited to
> see .92 go out with it).
> 
> Lars, are you proposing that we stick to more of a time based schedule
> rather than a 'it feels right' mechanism? I worry that we can get caught 
> in
> between making some really good changes and then having essentially a
> half-baked release come out. That will hurt credibility with end users if we
> say yeah, you could you release "x", but you might as well wait till 
> "x+1"
> cause some really good stuff is coming in then. Then why did we take the
> time to release it in the first place?
> 
> As a middle ground, maybe we can look at the number of major and minor
> updates since the last branch and drop a cut a new release when it exceeds
> some threshold. For the first couple of iterations, this would be a flexible
> limit until we find what works and makes sense to maintain. Maybe this also
> means developing something like "x minor changes = 1 major change, and we
> release every Y major change" kind of formula. After that, we can use a
> community voting process to bump the limits for exceptional cases.
> 
> This ensures that we don't do pointless releases, but instead put out
> versions and still minimizes the pain involved in maintaining multiple
> branches.
> 
> What do you think?
> 
> -Jesse Yates
> 
> On Tue, Oct 11, 2011 at 10:22 PM, lars hofhansl <lhofhansl@yahoo.com> 
> wrote:
> 
>>  HBase 0.90 was released Jan 2011. By the time HBase 0.92 is released it
>>  will probably be close to
>>  a year between stable releases.
>> 
>>  Should we try to have more frequent, smaller releases? Maybe 3-4 a year.
>>  For example I would almost say that the performance enhancements from the
>>  Facebook guys would
>>  warrant a new (performance) release "shortly" after 0.92.
>> 
>>  That would hopefully reduce the time and effort needed to stabilize the
>>  releases, at the expense of having to
>>  maintain two or even three branches in addition to trunk that people would
>>  still be actively using.
>> 
>>  Thoughts?
>> 
>>  -- Lars
>> 
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message