I agree with Andy. Maintaining a patch that cleanly applies to TRUNK is a lot easier.
Cheers On Wed, Dec 14, 2011 at 11:41 AM, Andrew Purtell <apurt...@apache.org>wrote: > We have discussed feature branches in the past, and even attempted it once > or twice (if I recall correctly, both with coprocessors and security), but > Subversion merge support is lacking. I assert ASF tooling is suboptimal for > managing a long lived feature branch. I'm happy to be properly educated if > you disagree. > > Otherwise, this leads the discussion to external hosting of feature > branches under development, where there is more appropriate tooling, such > as up on GitHub. > > Trend put up our security work on a public GitHub repository. I routinely > advertised it in any security related discussion. However, it was ignored > by the community: As far as I know, nobody ever checked it out and tried > it. Only code in the ASF repo seemed to matter. > > Best regards, > > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > > > ----- Original Message ----- > > From: Jonathan Hsieh <j...@cloudera.com> > > To: dev@hbase.apache.org > > Cc: Andrew Purtell <apurt...@apache.org> > > Sent: Tuesday, December 13, 2011 11:57 AM > > Subject: Re: Code review request for hbase-4120 table priority > > > > Note: I've only done a quick look at the jira and the code. The high > level > > design document/approach seems reasonable and I think most agree that > this > > is a useful feature and that a lot of effort has gone into it. > > > > The feature is off by default -- I can see one main difference in this > > situation compared to other major newish generally-considered > experimental > > or incomplete features (replication, off-heap slab cache, online schema > > changes). This feature doesn't have one of the current HBase committers > > using/testing it in their production environments or in their test > > environment. > > > > This seems perfect for *a feature branch* as we talked briefly about at > the > > Pow-wow. There seem to be some problems identified that will result in > > follow on issues (races mentioned). Using a branch would: > > * make it available at apache allows devs to test it > > * allows a committer who is championing this to test it by using it more > > and to iron out glaring problems in environment, > > * encourages and shepards the contributor allowing them to justify > > continued effort, > > * allows all of us to defer the decision to fold the feature into 0.94 > (or > > 0.96, or later) when more folks are familiar or comfortable with it. > > > > Who knows, maybe some of the TaoBao folks will eventually become > committers. > > > > Jon. > > > > On Tue, Dec 13, 2011 at 12:42 AM, <yuzhih...@gmail.com> wrote: > > > >> Thanks for the suggestion, Lars. > >> The original scope for 4120 is bigger than the latest patch which only > >> covers table priorities. > >> > >> Let's perform more reviews for the current patch. We can create more > >> subtasks for the umbrella feature. > >> > >> Cheers > >> > >> > >> > >> On Dec 12, 2011, at 11:23 PM, lars hofhansl <lhofha...@yahoo.com> > > wrote: > >> > >> > While I haven't looked (in depth) at the patch, yet, this is > > definitely > >> a feature that will be extremely helpful > >> > for Salesforce's multitenant architecture to isolate tenants and > >> services from each other. > >> > > >> > While we don't have HBase in our production data centers, yet > > (working > >> on it), I am certain that we will use this feature > >> > eventually. > >> > > >> > Would it help to break the patch into multiple smaller patches? > >> > > >> > Off the bat I think of: > >> > 1. the grouping logic > >> > 2. regionserver configuration (caching, etc) per group > >> > 3. table priorities > >> > 4. etc... (folks who have actually looked at the patch can probably > >> identify better demarcations between the aspects of this change.) > >> > > >> > That would certainly make it more manageable for me - personally - to > >> review the code. > >> > > >> > -- Lars > >> > > >> > > >> > ----- 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 > >> > > >> > > > > > > > > -- > > // Jonathan Hsieh (shay) > > // Software Engineer, Cloudera > > // j...@cloudera.com > > >
