Ashish Singhi created HBASE-13246:
-
Summary: Correct the assertion for namespace permissions in
tearDown method of TestAccessController
Key: HBASE-13246
URL: https://issues.apache.org/jira/browse/HBASE-13246
Lars George created HBASE-13247:
---
Summary: Change BufferedMutatorExample to use addColumn() since
add() is deprecated
Key: HBASE-13247
URL: https://issues.apache.org/jira/browse/HBASE-13247
Project: HBa
Mikhail Antonov created HBASE-13248:
---
Summary: Make HConnectionImplementation top-level class
Key: HBASE-13248
URL: https://issues.apache.org/jira/browse/HBASE-13248
Project: HBase
Issue Ty
Sorry for chiming in a bit late.When I wrote up the proposal for our dependency
story I spent a lot of time thinking about this, we also discussed this at
length at a PMC meeting. Let's not break our own promise in the first ever
minor version we release.
Instead of removing that part we can cl
I should also state that the initial proposal did not "Dependency
Compatibility" in it, as it is somewhat redundant.As long as none of the other
promises we make are broken we should be able to pull in whatever we want in
terms of dependencies.
-- Lars
From: lars hofhansl
To: "dev@hbase.
Not sure what jira does about an assignee when (s)he is removed from the
contributors list (I know you have to add a person to the contributors list
order to assign a jira to them).Other than the committers, we probably have at
least one jira assigned to a contributor (otherwise why add him/her
I was advocating a more formal "Contributor" role before, so that we can
recognize folks for contributing, without making them committers right away.So
I'm in favor of this!
-- Lars
From: Andrew Purtell
To: "dev@hbase.apache.org"
Sent: Friday, March 13, 2015 9:31 AM
Subject: Re: Jira
I can make it so that issues can be assigned to non-contributors. Even if
we don't do that, I believe jira permissions are all about constraining
current actions, and are not enforced on existing ticketes.
However, the "contributor" role in jira has several other abilities
associated with it. Righ
Hmm... This is interesting. I think Jira management should be left to the
committers. One can pretty much mess up a release, and make it hard to account
for what's in and what's not when jiras are changed the around (the ultimate
truth can be reconstructed from the git commit records, but that's
