Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> [DISCUSS] More new feature backports to 0.94.


+
Jonathan Hsieh 2013-03-01, 16:31
+
lars hofhansl 2013-03-01, 19:00
+
Elliott Clark 2013-03-01, 22:43
+
Jean-Marc Spaggiari 2013-03-01, 23:12
+
Enis Söztutar 2013-03-02, 00:55
+
Jonathan Hsieh 2013-03-01, 23:11
+
lars hofhansl 2013-03-02, 02:10
+
Enis Söztutar 2013-03-02, 02:17
+
Jean-Marc Spaggiari 2013-03-02, 02:25
+
Ted Yu 2013-03-02, 02:24
+
Andrew Purtell 2013-03-03, 13:50
+
Ted 2013-03-03, 14:12
+
Andrew Purtell 2013-03-03, 14:38
+
Jean-Marc Spaggiari 2013-03-04, 13:41
+
Stack 2013-03-04, 21:27
+
Enis Söztutar 2013-03-04, 22:29
+
Andrew Purtell 2013-03-05, 01:57
+
Dave Wang 2013-03-01, 16:38
+
Lars Hofhansl 2013-03-02, 02:46
+
Enis Söztutar 2013-03-02, 02:54
+
Jean-Marc Spaggiari 2013-03-02, 03:12
+
lars hofhansl 2013-03-02, 03:24
+
Ted Yu 2013-03-02, 03:30
+
lars hofhansl 2013-03-02, 03:44
+
Nicolas Liochon 2013-03-02, 11:43
+
Ted 2013-03-02, 11:57
+
Jonathan Hsieh 2013-03-02, 15:36
+
lars hofhansl 2013-03-02, 16:47
+
Ted Yu 2013-03-02, 16:14
+
Jonathan Hsieh 2013-03-02, 16:26
+
lars hofhansl 2013-03-02, 20:46
+
Jonathan Hsieh 2013-03-02, 21:49
+
Stack 2013-03-02, 23:24
Copy link to this message
-
Re: [DISCUSS] More new feature backports to 0.94.
That is only if we do not backport stabilizing "features". There is an "opportunity cost" to be paid if we take a too rigorous approach too.

Take for example table-lock (which prompted this discussion). With that in place we can do safe online schema upgrade (that won't fail and leave the table in an undefined state when a concurrent split happens), it also allows for online merge.

Now, is that a destabilizing "feature", or will it make HBase more stable and hence an "improvement"? Depends on viewpoint, doesn't it?

-- Lars

________________________________
 From: Jean-Marc Spaggiari <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Friday, March 1, 2013 7:12 PM
Subject: Re: [DISCUSS] More new feature backports to 0.94.
 
@Lars: No, not any concern about anything already backported. Just a
preference to #2 because it seems to make things more stable and
easier to manage. New feature = new release. Given new sub-releases
are for fixes and improvements, but not new features. Also, if we
backport a feature in one or many previous releases, we will have to
backport also all the fixes each time there will be an issue. So we
will have more maintenant work on previous releases.

2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> I think the current way of risk vs rewards analysis is working well. We
> will just continue doing that on a case by case basis, discussing the
> implications on individual issues.
>
>
>
> On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]> wrote:
>
>> BTW are you concerned about any specific back port we did in the past? So
>> far we have not seen any destabilization in any of the 0.94 releases.
>>
>> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
>>
>> >Hi Lars, #2, does it mean you will stop back-porting the new features
>> >when it will become a "long-term" release? If so, I'm for option #2...
>> >
>> >JM
>> >
>> >In your option
>> >2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
>> >> Thanks Lars, I think it is a good listing of the options we have.
>> >>
>> >> I'll be +1 for #1 and #2, with #1 being a preference.
>> >>
>> >> Enis
>> >>
>> >>
>> >> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> >>
>> >>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2)
>> we
>> >>> have three options:
>> >>> 1. Backport new features to 0.94 as we see fit as long as we do not
>> >>> destabilize 0.94.
>> >>> 2. Declare a certain point release (0.94.6 looks like a good
>> candidate) as
>> >>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>> >>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>> >>> maintain a 0.94.6 branch in addition to the 0.94 branch.
>> >>> 3. Categorically do not backport new features into 0.94 and defer to
>> 0.95.
>> >>>
>> >>> I'd be +1 on option #1 and #2, and -1 on option #3.
>> >>>
>> >>> -- Lars
>> >>>
>> >>>
>> >>>
>> >>> ________________________________
>> >>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>> >>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>> >>> Sent: Friday, March 1, 2013 3:11 PM
>> >>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>> >>>
>> >>> I think we are basically agreeing -- my primary concern is bringing new
>> >>> features in vital paths introduces more risk, I'd rather not backport
>> major
>> >>> new features unless we achieve a higher level of assurance through
>> system
>> >>> and basic fault injection testing.
>> >>>
>> >>> For the three current examples -- snapshots, zk table locks, online
>> merge
>> >>> -- I actually would prefer not including any in apache 0.94.  Of the
>> bunch,
>> >>> I feel the table locks are the most risky since it affects vital paths
>> a
>> >>> user must use,  where as snapshots and online merge are features that a
>> >>> user could choose to use but does not necessarily have to use.  I'll
>> voice
>> >>> my concerns, reason for concerns, and justifications on the individual
>> >>> jiras.
>
+
Lars Hofhansl 2013-03-02, 02:45
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB