[jira] [Resolved] (HBASE-15203) Reduce garbage created by path.toString() during Checksum verification

[ https://issues.apache.org/jira/browse/HBASE-15203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan resolved HBASE-15203. Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.3.0

Fwd: Google Summer of Code 2016 is coming

Does anyone have an interest in participating this year? We had a fruitful summer last year over on Phoenix. -- Forwarded message -- From: Ulrich Stärk Date: Wed, Feb 10, 2016 at 12:16 PM Subject: Google Summer of Code 2016 is coming To:

Re: Backporting to active branches

I appreciate Elliot's voice for conservatism on released branches. However I don't think we're getting minor releases out the door fast enough, especially when we have nice "improvements" that apply cleanly. Users deserve to get as many of the improvements as are compatible for patch releases,

Re: Backporting to active branches

Users also deserve to get as few new surprises as possible. Being on the supporting side of this, I've come to prefer preserving minor known issues to having new unknown issues caused of small improvements. I prefer the conservative approach with "improvements", and prefer that maint/point

[jira] [Created] (HBASE-15259) WALEdits under replay will also be replicated

ramkrishna.s.vasudevan created HBASE-15259: -- Summary: WALEdits under replay will also be replicated Key: HBASE-15259 URL: https://issues.apache.org/jira/browse/HBASE-15259 Project: HBase

Re: [VOTE] HBase 1.2.0 RC2

-1 The dataloss issue was just discovered. I think now we know of it, even though the incidence is rare, would be best to respin the RC. You the man Sean, St.Ack On Thu, Feb 11, 2016 at 8:59 PM, Stack wrote: > On Thu, Feb 11, 2016 at 5:04 PM, Sean Busbey

Re: Backporting to active branches

The criteria we use for branches >= 1.0 I think addresses this concern. Remember: For 0.98, each 0.98.x is a new _minor_ release. For each 1.1.x each new release is a _patch_ release. So it's likely that features make it in to 0.98, because - new minors; but unlikely features make it into 1.1.x,

Re: Backporting to active branches

On Thu, Feb 11, 2016 at 9:03 AM, Nick Dimiduk wrote: > ... > Let's change our relationship slightly, dev community. If you're working on > a fix, please also post a patch for branch-1.1. It is a bit tough. That'd be a patch for four branches (at least), three of which have

Re: Backporting to active branches

On Thu, Feb 11, 2016 at 11:10 AM, Andrew Purtell wrote: > later versions of 0.98 are more stable I would assert that to be because less and less things are applying now. Every time we have tried a new patch version of 1.0 ( We haven't really tried any 1.1 since we've been

Re: Backporting to active branches

I would also quibble about this: > The number of patches that we backport makes the "stable" branches less stable. At least in our production settings, later versions of 0.98 are more stable and perform better than earlier ones as a rule. My experience refutes the above claim, but YMMV On Thu,

Re: Backporting to active branches

> I would assert that to be because less and less things are applying now. ​I'm sure that's true as well (smile) ​ On Thu, Feb 11, 2016 at 11:32 AM, Elliott Clark wrote: > On Thu, Feb 11, 2016 at 11:10 AM, Andrew Purtell > wrote: > > > later versions

Successful: HBase Generate Website

Build status: Successful If successful, the website and docs have been generated. If failed, skip to the bottom of this email. Use the following commands to download the patch and apply it to a clean branch based on origin/asf-site. If you prefer to keep the hbase-site repo around

Re: Backporting to active branches

Stack wrote: ... > Let's change our relationship slightly, dev community. If you're working on > a fix, please also post a patch for branch-1.1. It is a bit tough. That'd be a patch for four branches (at least), three of which have diverged in key areas (master, branch-1 and branch-1.2, and

Re: Backporting to active branches

That one's on the edge for me. It's trying to work around a bug somewhere that has caused data loss in prod. So I would lean towards it being a bug fix. However pulling from my last few filed jiras I would say these are all improvements: HBASE-15166 HBASE-15146 HBASE-15137 HBASE-15083 Some of

[jira] [Created] (HBASE-15257) Clean up findbugs warnings on 0.98 branch

Andrew Purtell created HBASE-15257: -- Summary: Clean up findbugs warnings on 0.98 branch Key: HBASE-15257 URL: https://issues.apache.org/jira/browse/HBASE-15257 Project: HBase Issue Type:

[jira] [Created] (HBASE-15258) Clean up javadoc warnings and errors on 0.98 branch

Andrew Purtell created HBASE-15258: -- Summary: Clean up javadoc warnings and errors on 0.98 branch Key: HBASE-15258 URL: https://issues.apache.org/jira/browse/HBASE-15258 Project: HBase

Re: Backporting to active branches

I'd also encourage RMs to make occasional (I try monthly) sweeps of upstream branch history to get a lay of the land and identify changes you think should be in your RC but didn't get there by commit - and pick those back if so. Allow an extra few days when scheduling time to work on that next

Re: [VOTE] HBase 1.2.0 RC2

+1 Been running something close to RC in production for a while now. Checked the layout everything looks good Running ITBLL in a loop and there's no data loss. ( Sometimes the master still gets stuck but that's not new ). On Thu, Feb 11, 2016 at 3:22 PM, Stack wrote: > +1 >

[jira] [Resolved] (HBASE-15255) Add pointer to linkedin blog on putting jvm logs on fast disk

[ https://issues.apache.org/jira/browse/HBASE-15255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-15255. --- Resolution: Fixed > Add pointer to linkedin blog on putting jvm logs on fast disk >

Re: [VOTE] HBase 1.2.0 RC2

On Thu, Feb 11, 2016 at 1:15 PM, Elliott Clark wrote: > Should we kill this since Stack just removed the narrow increment ? I'm > worried about adding a feature and removing it. > > The increment 'fast path' is not needed in 1.2. Subsequent work found that increment

Re: Backporting to active branches

The majority of changes in branch-1 that I see are bug fixes. Only committer attention and bandwidth prevents application to all places. A few are new features or bug fixes that break APIs or change behavior in a manner unsuitable for a patch release. Spotting those isn't hard. Finally, it's

Re: Backporting to active branches

On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell wrote: > The majority of changes in branch-1 that I see are bug fixes. I think that's the point that you and I differ. For me I would classify most things on branch-1 as improvements and there are very few bug fixes.

Re: Backporting to active branches

Ok, in fairness there could be more debatable (or even not debatable) changes on branch-1 as you say. Also, a difference of perspective. Would you for example consider HBASE-15211 a bug fix or improvement? On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark wrote: > On Thu, Feb

Re: [VOTE] HBase 1.2.0 RC2

On Thu, Feb 11, 2016 at 5:04 PM, Sean Busbey wrote: > On Feb 11, 2016 18:33, "张铎" wrote: > > > > Should we include HBASE-15252? It is a data loss issue. > > > > It's marked major (though perhaps that's off since it's dataloss, even if > rare). More

[jira] [Reopened] (HBASE-11927) Use Native Hadoop Library for HFile checksum (And flip default from CRC32 to CRC32C)

[ https://issues.apache.org/jira/browse/HBASE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk reopened HBASE-11927: -- reopening for 1.1 backport. > Use Native Hadoop Library for HFile checksum (And flip default from

Re: Backporting to active branches

Thanks Nick. Since you've asked I'll give 1.1 the same treatment. About once or twice a month I sweep branch-1 for changes suitable for picking back further. You have asked for patches for branch-1.1 to be posted to respective issues. I can stop with that or do the same with 1.1 that I've done

Backporting to active branches

Heya folks, I'm sorry to say branch-1.1 is falling behind in terms of backporting fixes and performance improvements. Anything that's not a new feature and that doesn't break our compatibility guidelines is explicitly acceptable and *should* be backported to the active release branches, 0.98 and

Re: Backporting to active branches

I disagree. We should encourage people to keep up with releases otherwise things will become un-tenable. I would vote that we should push back critical and blocker bug fixes to 1.1 but small fixes should go in the active 1.X branch. The number of patches that we backport makes the "stable"