Re: [DISCUSS] move to gitbox

How should we verify pull requests in the new workflow? I wouldn't like to force contributors to create a PR and also attach the same patch file to Jira to have it tested. In case the plan is to create PR-based precommit I'd recommend to test run it on hbase-connectors or hbase-operator tools

Re: [VOTE] The second HBase 1.4.9 release candidate (RC1) is available

YCSB workloads are not that interesting. I think it’s still useful as a “standard” tool though that indicates we aren’t doing worse. Also, there may be more difference under overload conditions. Next time. Using Phoenix and some of our internal test tools we can generate workloads that turn

Failure: hbase.apache.org HTML Checker

Failure Either the Jenkins job failed, or (more likely) HTML errors were found. Unless the Jenkins job itself failed, the HTML and link-checking report for http://hbase.apache.org is available at

Re: [VOTE] The second HBase 1.4.9 release candidate (RC1) is available

Thanks for the test runs. The diffs are miniscule. After so many releases, would have expected a tendency up or down but not constant (smile). S On Fri, Dec 7, 2018 at 5:34 PM Andrew Purtell wrote: > Today I did a comparison between 1.2.6.1 and 1.4.9RC1 with YCSB. The > results are close.

Re: [DISCUSS] move to gitbox

Yes I definitely agree. I think that'll take some committer practice and I'll want to have a decent section in the ref guide to point folks to. On the plus side, there's a step committers have to go through to link their ASF ID to their GitHub profile before they can start merging through the

Re: [DISCUSS] move to gitbox

However you want to best phrase it, squash merging for commit is a must, I think. Depending on the contributor's style there could be 1 or 10 commits comprising the PR. Even more than one commit for a change encompassed by a JIRA would make cherry picking between the branches unnecessarily

Re: [DISCUSS] move to gitbox

Once we can show a consensus position one of the PMC files an INFRA jira and then they coordinate with us (but I don't know specifically what that coordination looks like). On Fri, Dec 7, 2018 at 11:13 AM Misty Linville wrote: > > +1 What needs to happen next? > > On Fri, Dec 7, 2018, 9:03 AM

Re: [DISCUSS] move to gitbox

The move to gitbox doesn't require us to only accept github PRs. Given the current rate of contributions via patches on JIRA vs GitHub PRs, I wouldn't want to push for that now. The change does make it easier for us to start encouraging PR submissions, because committers will be able to directly

Re: [DISCUSS] EOL branch-1.3

correct, branch-1.2 was the stable release line prior to 1.4 becoming it in August. at the time I said I'd keep making monthly 1.2.z releases for ~6 months: https://s.apache.org/EYkB I wanted to give folks who heed our "this is the stable line" advice a cushion for planning migration once we

Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly

We could do that. Or we could simply renumber branch-1 to 1.6.x at that time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a tag in rel/. It is possible at any time to check out from a release tag and make a branch for an additional patch release for an old minor line. If we

Re: [DISCUSS] EOL branch-1.3

+1. But branch-1.2 is not EOL now? 张铎(Duo Zhang) 于2018年12月8日周六 上午9:28写道： > +1. > > Andrew Purtell 于2018年12月8日周六 上午5:45写道： > > > I'm good with doing one more 1.3 release. It would be my pleasure to > offer > > that service to the community. I like RM-ing. > > > > > > On Fri, Dec 7, 2018 at

Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly

If 1.5 is not the last minor release line, then how do we release 1.6? Make a branch-1.5 and then start to release 1.6 from branch-1? Andrew Purtell 于2018年12月8日周六 上午9:36写道： > Yeah, for branch-1 it is no longer a development branch. Every change is > going to be maintenance related. No, I don't

Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly

Yeah, for branch-1 it is no longer a development branch. Every change is going to be maintenance related. No, I don't expect 1.5 to be the last minor release line for 1.x. Maybe? Maybe not. In theory we could treat branch-2 the same. Master is the only development branch. That is not my proposal,

Re: [VOTE] The second HBase 1.4.9 release candidate (RC1) is available

Today I did a comparison between 1.2.6.1 and 1.4.9RC1 with YCSB. The results are close. Overall runtimes are almost the same. In the average and high percentile measures there is a general upward trend but nothing that looks like a significant regression. Still for 1.5.0 I think we should see if

Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly

So the idea is that, if we have a newer major release line, we can release the previous major releases directly from the 'developing' branch? I think for branch-1 it is fine, as we are not likely to backport any big new feature to 1.x any more. And does this mean that 1.5 is the last minor

Re: [DISCUSS] EOL branch-1.3

+1. Andrew Purtell 于2018年12月8日周六 上午5:45写道： > I'm good with doing one more 1.3 release. It would be my pleasure to offer > that service to the community. I like RM-ing. > > > On Fri, Dec 7, 2018 at 12:29 PM Stack wrote: > > > +1 > > > > (Pity you have to make a release to EOL it). > > > > S > >

[NOTICE] HBase 1.5.0-SNAPSHOT now available for testing (and updated at least weekly)

In anticipation of the first HBase 1.5 release next month, 1.5.0, I have begun publishing weekly (ish) snapshots. Artifacts are available in Apache's snapshots repository and source and binary tarballs can be downloaded from https://dist.apache.org/repos/dist/dev/hbase/hbase-1.5.0-SNAPSHOT/ .

[VOTE] First release candidate for HBase 2.1.2 is available for download

The first release candidate for HBase 2.1.2 is available for download: * https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/ * Maven artifacts are also available in a staging repository at:

Re: [DISCUSS] EOL branch-1.3

I'm good with doing one more 1.3 release. It would be my pleasure to offer that service to the community. I like RM-ing. On Fri, Dec 7, 2018 at 12:29 PM Stack wrote: > +1 > > (Pity you have to make a release to EOL it). > > S > > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell > wrote: > > >

[jira] [Created] (HBASE-21567) Allow overriding configs starting up the shell

stack created HBASE-21567: - Summary: Allow overriding configs starting up the shell Key: HBASE-21567 URL: https://issues.apache.org/jira/browse/HBASE-21567 Project: HBase Issue Type: Improvement

[jira] [Created] (HBASE-21568) Disable use of BlockCache for LoadIncrementalHFiles

Josh Elser created HBASE-21568: -- Summary: Disable use of BlockCache for LoadIncrementalHFiles Key: HBASE-21568 URL: https://issues.apache.org/jira/browse/HBASE-21568 Project: HBase Issue Type:

Re: [DISCUSS] EOL branch-1.3

+1 (Pity you have to make a release to EOL it). S On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell wrote: > We haven't had a release from branch-1.3 for a long time and do not appear > to have an active RM for it. Unless a RM for 1.3 steps forward and promises > to make a release in the very

Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly

On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell wrote: > Please be advised I plan to RM the next minor release from branch-1, 1.5.0, > in January of 2019. Once this is done we can continue making maintenance > releases from branch-1.4 as needed but expect that not to be necessary > after a couple

Re: [DISCUSS] EOL branch-1.3

big +1 from me. On Fri, Dec 7, 2018 at 1:25 PM Andrew Purtell wrote: > > We haven't had a release from branch-1.3 for a long time and do not appear > to have an active RM for it. Unless a RM for 1.3 steps forward and promises > to make a release in the very near future, I propose we make one more

Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly

yes please this would be great! I have a DISCUSS thread I've been drafting about doing the same thing for branch-2 releases. I think in general we need to get back in the habit of only making maintenance releases when someone steps forward with a specific need. I plan to keep making branch-1.2

[DISCUSS] No more release branches for 1.x, release from branch-1 directly

Please be advised I plan to RM the next minor release from branch-1, 1.5.0, in January of 2019. Once this is done we can continue making maintenance releases from branch-1.4 as needed but expect that not to be necessary after a couple of months (or perhaps even immediately). I see no need to make

[DISCUSS] EOL branch-1.3

We haven't had a release from branch-1.3 for a long time and do not appear to have an active RM for it. Unless a RM for 1.3 steps forward and promises to make a release in the very near future, I propose we make one more release of 1.3, from the head of branch-1.3, and then retire the branch. If

[VOTE] First release candidate for HBase 2.0.4 is available hbase

The first release candidate for HBase 2.0.4 is available for download: *https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/ * Maven artifacts are also available in a staging repository at:

Re: [DISCUSS] move to gitbox

On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey wrote: > Hi folks! > > Per the email from infra "[NOTICE] Mandatory relocation of Apache git > repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe ) it > looks like the future of interacting directly with PRs is coming sooner > rather

Re: [DISCUSS] move to gitbox

In the interest of helping this discussion along, let me change this from an open ended comment to a specific proposal. What if we require a PR for every commit? No cherry picking. This would mean that a change might need three or four, or possibly even five PRs, one for each affected branch. The

Re: [DISCUSS] move to gitbox

We also need to discuss and document how to target specific code lines. You can't fix a branch-1 issue where the code is different in branch-2 and up by opening a PR against master (assuming this is the default branch). It seems obvious but is not. Occasionally a fix is relevant for all

Re: [DISCUSS] move to gitbox

+1 What needs to happen next? On Fri, Dec 7, 2018, 9:03 AM Sean Busbey Hi folks! > > Per the email from infra "[NOTICE] Mandatory relocation of Apache git > repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe ) it > looks like the future of interacting directly with PRs is coming

[DISCUSS] move to gitbox

Hi folks! Per the email from infra "[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe ) it looks like the future of interacting directly with PRs is coming sooner rather than later. I think we should move to gitbox ASAP rather than

[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] Hello Apache projects, I am writing to you because you may have git repositories on the git-wip-us server, which is slated to be decommissioned in the coming