Successful
If successful, the HTML and link-checking report for http://hbase.apache.org is
available at
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/77/artifact/link_report/index.html.
If failed, see
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/77/console.
+1
Checked sums and signatures: ok
Spot check LICENSE and NOTICE files: ok
Built from source (7u80): ok
RAT audit (7u80): ok
Unit test suite passes (8u102):
Loaded 1 million rows with LTT (8u102, 10 readers, 10 writers, 10 updaters
@ 20%): all keys verified, no unexpected or unusual messages in th
Guanghao Zhang created HBASE-17442:
--
Summary: Move most of the replication related classes to
hbase-server package
Key: HBASE-17442
URL: https://issues.apache.org/jira/browse/HBASE-17442
Project: HBa
[
https://issues.apache.org/jira/browse/HBASE-17440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved HBASE-17440.
---
Resolution: Fixed
Fix Version/s: 0.98.25
Done.
> [0.98] Make sure DelayedClosing chor
Somewhat late to the reply --
Does it make sense, for branch-1, to have the person planning to RM the
next minor release act as the RM for the major-level branch? That person
would hand responsibility to the next minor RM upon cutting the
stabilization branch.
This could be applied to master/bran
[
https://issues.apache.org/jira/browse/HBASE-14061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey reopened HBASE-14061:
-
This causes building against the Hadoop 3 profile to fail, and will cause
building against Hadoop 2.
Sean Busbey created HBASE-17441:
---
Summary: precommit test "hadoopcheck" not properly testing Hadoop
3 profile
Key: HBASE-17441
URL: https://issues.apache.org/jira/browse/HBASE-17441
Project: HBase
As branch-1 "RM" I don't need to be in the loop when a committer wants to
commit something there, and wouldn't have the bandwidth for it anyway. So
if someone wants to put something in branch-N.M, feel free to commit it to
master, then branch-N, then branch-N.M, as is our current workflow. If the
c
One question to reiterate on the commit flow..
I think we agreed, as you said, that branch-N RM won't dictate what to
backport and what not to released branches maintainers, but
at least logically I'd still treat that as an additional "line of defense"
for too big, too risky or otherwise questiona
Lars Hofhansl created HBASE-17440:
-
Summary: [0.98] Make sure DelayedClosing chore is stopped as soon
as an HConnection is closed
Key: HBASE-17440
URL: https://issues.apache.org/jira/browse/HBASE-17440
Good, I think we are on the same page regards a long term maintainer for
branch-1. I can make a multi year commitment like I did with 0.98. How that
works with respect to branching for minor releases we can figure out. My
thought is anytime someone wants to branch off to make a minor release, RM
it
[
https://issues.apache.org/jira/browse/HBASE-17394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huaxiang sun resolved HBASE-17394.
--
Resolution: Invalid
The logic is correct, the definition is [min, max], I added comments throug
Kudos to Andrew.
On Mon, Jan 9, 2017 at 11:26 AM, Enis Söztutar wrote:
> Thanks Andrew for carrying this.
>
> +1 on the EOL messaging.
>
> Enis
>
> On Mon, Jan 9, 2017 at 10:37 AM, Mikhail Antonov
> wrote:
>
> > Yeah - thank you for all hard work and time investment on reviews,
> > cherry-picki
Thanks Andrew for carrying this.
+1 on the EOL messaging.
Enis
On Mon, Jan 9, 2017 at 10:37 AM, Mikhail Antonov
wrote:
> Yeah - thank you for all hard work and time investment on reviews,
> cherry-picking, backporting and testing Andrew!
>
> +1 to retire 0.98.
>
> -Mikhail
>
> On Mon, Jan 9, 2
Yeah - thank you for all hard work and time investment on reviews,
cherry-picking, backporting and testing Andrew!
+1 to retire 0.98.
-Mikhail
On Mon, Jan 9, 2017 at 10:28 AM, Sean Busbey wrote:
> Thanks for all the hard work around 0.98 Andrew!
>
> I'm +1 on retiring 0.98, but I think we shou
I should say I was talking more about "should these things be discussed
together or separately", not any particular direction we should
or should not take, as I didn't want to accidentally steal the topic.
But speaking specifically on that.. saying that we're going to maintain
branch-1 lines until
Thanks for all the hard work around 0.98 Andrew!
I'm +1 on retiring 0.98, but I think we should solicit feedback from
user@hbase before making a decision.
On Fri, Jan 6, 2017 at 6:51 PM, Andrew Purtell wrote:
> HBasers,
>
> Happy new year!
>
> The 0.98 branch has had a great run at a fairly cons
On Fri, Jan 6, 2017 at 7:43 PM, Mikhail Antonov wrote:
> ...
>
> Speaking specifically about branch-1 and given 2.0 release
> discussions, is it proper time/thread to also discuss what
> do we want to do with branch-1? Like, say that 1.4 would be
> the last release off this line and hence branch-1
> Now the authors of every issues backport new features to branch-1 after they
> have a patch for master, and committers help them push patches to git. So
> usually master and branch-1 introduce two patches for a issue at time same
> time.
One change would be more scrutiny of the stability and
Ted Yu created HBASE-17439:
--
Summary: Make authentication Token retrieval amenable to
coprocessor
Key: HBASE-17439
URL: https://issues.apache.org/jira/browse/HBASE-17439
Project: HBase
Issue Type:
Build status: Successful
If successful, the website and docs have been generated. To update the live
site, follow the instructions below. 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 yo
+1
Built tar from the source code.
Verified some shell commands,
Ran export-import snapshot, copyTable, importtsv commands.
Verified replication, bulk loaded data replication, audit logs.
Verified proc-v2 enable table flow by killing master when table was in
ENABLING state in ZK during enable tabl
Like this idea. I think it will help us making non-releasing branches more
stable, and reduce delay from cutting releasing branch to release first
x.y.0 version which means users will meet new features earlier :)
And I have two questions :)
> Occasional sweep through master history looking for ap
23 matches
Mail list logo
