Hi Todd, > It's not about Cloudera/SU/FB - it's about code that will be supported > by people who are committed to the project.
Fine, but that is not what you stated exactly, so I felt it important to -1 the language in your previous email. > If we have a few of the core people committed to running this in > production and supporting it in the future, I'm all for it (just like > I am +1 on security). I just want to avoid repeating mistakes like the > Avro server which isn't really supported despite being in our > codebase. My point of view here is that what you said is fine, but it would have been better if you stopped at "If we have a few of the core people committed". I would really like to see the isolation feature in 0.94+, so I intend to work with Jia and, if there is a successful result, support it going forward in a manner like Stargate, even though I may not run it personally (like I don't run Stargate). I take an expansive view of what open source projects should accept... > I just want to avoid repeating mistakes like the > Avro server which isn't really supported despite being in our > codebase. ... even though it may lead to situations like that. On the other hand there are users and committers of HBase for whom stability is paramount. I expect the tension :-); it will make us a healthier project. But we cannot have a new feature acceptance criteria that requires several "core users" run it in production. Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) ----- Original Message ----- > From: Todd Lipcon <t...@cloudera.com> > To: dev@hbase.apache.org; Andrew Purtell <apurt...@apache.org> > Cc: > Sent: Monday, December 12, 2011 4:55 PM > Subject: Re: Code review request for hbase-4120 table priority > > On Mon, Dec 12, 2011 at 4:36 PM, Andrew Purtell <apurt...@apache.org> > wrote: >> >> HBase as a project should not have as a criteria for inclusion of some > feature that Cloudera and SU and Facebook run it. Core managed to escape > Yahoo. > Let's not run history in reverse here in HBase land. And, actually, this > makes it worse, because the the occurrence that a number of core HBase users > (multiple) will all need something is substantially less likely than if one > might find it useful; or, maybe, only users outside of those with such > self-appointed attitude, yet perhaps a community multiples in size of "core > users". > > It's not about Cloudera/SU/FB - it's about code that will be supported > by people who are committed to the project. TrendMicro certainly fits > the bill. I of course mean no offense to Lu Jia, but neither he nor > Taobao has made continued contributions in the past - just one other > bug fix beyond the HBASE-4120 project. > > If we have a few of the core people committed to running this in > production and supporting it in the future, I'm all for it (just like > I am +1 on security). I just want to avoid repeating mistakes like the > Avro server which isn't really supported despite being in our > codebase. (You'll note this was a Cloudera contribution but from a > contributor who was doing this in his spare time rather than part of > job responsibilities, and we have never run it in production > scenarios) > > I am consistently conservative on what goes into the project because > we have to stand behind what we release. I certainly don't think _all_ > core people should find every feature useful (eg REST and Thrift are > examples of some things which are useless to many but I think make > sense). But if _no_ core people see a feature as a requirement then > I'd rather let it bake until we have many people requesting it. > Otherwise people download HBase, try out these "fringe" features, and > get a bad taste in their mouth when they've bit-rot across several > versions of little usage. > > -Todd > -- > Todd Lipcon > Software Engineer, Cloudera >
