---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21072/
---
Review request for accumulo.
Bugs: ACCUMULO-2635
The BatchDeleter pulls all data through the client, so it does not scale.
If this is a problem for you, then other options to be aware of are
* Write a Filter or RowFilter and compact the table. These filters will
run on the server side in parallel when you compact the table.
* Write map
I need help updating the release notes. If there is something you think is
relevant please add it. If not a commiter, I can add it for you. Just let
me know.
* test ran.
* known issues found while evaluating the RCs
On Tue, Apr 29, 2014 at 5:33 PM, Christopher ctubb...@apache.org wrote:
On 5/5/14, 11:16 AM, Keith Turner wrote:
I need help updating the release notes. If there is something you think is
relevant please add it. If not a commiter, I can add it for you. Just let
me know.
* test ran.
* known issues found while evaluating the RCs
Do you want issues found and
Might be best to link to a JQL query for 1.6 issues for the known
issues section.
project = ACCUMULO AND affectedVersion = 1.6.0
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, May 5, 2014 at 11:16 AM, Keith Turner ke...@deenlo.com wrote:
I need help updating the release notes.
If the intent is to treat the tagging as a separate action from this
plan, then my vote changes to +1 for this plan.
I have no objection to just dropping the branch (and mentioning the
HEAD commit in the mailing list, in case the branch needs to be
resurrected for some reason). My -1 comes from
On Mon, May 5, 2014 at 11:32 AM, Josh Elser josh.el...@gmail.com wrote:
On 5/5/14, 11:16 AM, Keith Turner wrote:
I need help updating the release notes. If there is something you think
is
relevant please add it. If not a commiter, I can add it for you. Just
let
me know.
* test ran.
I like 1.4-eol or maybe 1.4-closed. --
Joey Echeverria
Chief Architect
Cloudera Government Solutions
On Mon, May 5, 2014 at 11:59 AM, Keith Turner ke...@deenlo.com wrote:
I also think the -eol tag is confusing.
Have to be careful w/ deleting the 1.4.6-SNAPSHOT branch and storing the
commit
On Mon, May 5, 2014 at 11:33 AM, Christopher ctubb...@apache.org wrote:
Might be best to link to a JQL query for 1.6 issues for the known
issues section.
project = ACCUMULO AND affectedVersion = 1.6.0
That would be best for the list of known issues, as long as we properly
organize things in
I agree. Having a final 1.4.6 release and not creating a 1.4.7-SNAPSHOT
branch seems like the path of least confusion.
On Mon, May 5, 2014 at 11:04 AM, Bill Havanki bhava...@clouderagovt.comwrote:
+1
Having a plain 1.4.6 release would be nice (I don't like the -eol tag),
but I'm fine with
Bill, Keith,
What already committed development in the 1.4.6 line do you find compelling
for a release?
Is there a different tag name we can use as a place holder for look here
if you want to work with the last of the 1.4.x development that you think
will be clearer for users? (and presumably
Christopher,
I think the initial tag that's included in the vote would have to occur
(presuming the vote passes), but any follow up action based on that tag
(deletion, rename, etc) would just be a code change, so we could quickly
correct things.
While this is practically the same as handling the
On Mon, May 5, 2014 at 10:59 AM, Keith Turner ke...@deenlo.com wrote:
Have to be careful w/ deleting the 1.4.6-SNAPSHOT branch and storing the
commit hash externally to git. If nothing refs (no other commit, tag,
branch, etc) that commit hash, then it could be gc'ed by git.
Just a quick
Nevermind! I was worried for no reason. Apparently my browser had done
some weird partial caching.
On Mon, May 5, 2014 at 9:55 AM, Billie Rinaldi billie.rina...@gmail.comwrote:
The website is in a bad state and does not match the beautiful site
generated by Bill (actually I've never been
That's not an issue here, because this commit has been merged to other
branches (up through master) and will always be referenced.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, May 5, 2014 at 11:59 AM, Keith Turner ke...@deenlo.com wrote:
I also think the -eol tag is
That would be very problematic. Pushing a tag to git is a more or less
permanent action. If it shows up in mirrors, it can still cause the
same confusion to end users that I was worried about.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, May 5, 2014 at 12:39 PM, Sean Busbey
You can also push a tag removal to a remote git, which should also get
picked up by mirrors, no?
-Sean
On Mon, May 5, 2014 at 12:26 PM, Christopher ctubb...@apache.org wrote:
That would be very problematic. Pushing a tag to git is a more or less
permanent action. If it shows up in mirrors, it
Removing a tag will not necessarily remove it from mirrors, but it
depends on how it is being mirrored. A git remote prune, for instance,
will not remove tags.
Further, if removing a tag can be done as a code change, which
requires consensus (lazy, but still consensus), not majority, then
On Mon, May 5, 2014 at 12:36 PM, Sean Busbey bus...@cloudera.com wrote:
Bill, Keith,
What already committed development in the 1.4.6 line do you find compelling
for a release?
Good point. I just took a quick look in Jira and I do not see anything
that I think is compelling ATM. Would not
Ok. I did not check if another commit referenced it. My main concern is
if this becomes SOP for EOL, then we should be careful to ensure the commit
hash is referenced.
On Mon, May 5, 2014 at 1:24 PM, Christopher ctubb...@apache.org wrote:
That's not an issue here, because this commit has
-1
I am opposed to the tag, because I think what it communicates to users is
confusing. I'm in favor of what Christopher suggested.
I was undecided about the general concept of 1.4 EOL, I am still working
w/ some users who are still using 1.4 in the short term. Should they run
into a serious
The tag tells users where development on the branch ended. Can you elaborate on
what is confusing about that?--
Joey Echeverria
Chief Architect
Cloudera Government Solutions
On Mon, May 5, 2014 at 3:01 PM, Keith Turner ke...@deenlo.com wrote:
-1
I am opposed to the tag, because I think what
Hey Keith,
Some questions in-line
On Mon, May 5, 2014 at 2:01 PM, Keith Turner ke...@deenlo.com wrote:
-1
I am opposed to the tag, because I think what it communicates to users is
confusing. I'm in favor of what Christopher suggested.
Specifically, this would be just dropping the HEAD
On Mon, May 5, 2014 at 2:26 PM, Christopher ctubb...@apache.org wrote:
Removing a tag will not necessarily remove it from mirrors, but it
depends on how it is being mirrored. A git remote prune, for instance,
will not remove tags.
Further, if removing a tag can be done as a code change,
I elaborated above, but in short, all previous tags have indicated
releases. This is standard to publish tags in SCM to denote a release.
it's confusing to have a tag that does not denote a release. Further,
having a version that is greater than the greatest approved release
may mislead people who
I suppose this will be a problem we will encounter with every major/minor
revision as they age, so we have a good chance to hash out a general policy
for this.
I see two categories of actions proposed here:
1) Content Changes (e.g: website)
2) SCM Changes (e.g: git repo)
As far as 1 is
No, the veto on tag creation would not halt a release. A release is
the source artifact. I can't imagine anybody would veto creation of a
tag to denote the branch from which that artifact was made, though. In
any case, I agree it's not a code change... it's a procedural step. I
was questioning it
On Mon, May 5, 2014 at 3:23 PM, Sean Busbey bus...@cloudera.com wrote:
Hey Keith,
Some questions in-line
On Mon, May 5, 2014 at 2:01 PM, Keith Turner ke...@deenlo.com wrote:
-1
I am opposed to the tag, because I think what it communicates to users is
confusing. I'm in favor of what
How about the tag name
1.4-development-closed
This clearly indicates
* that it's the major version 1.4 (which should limit our ratio of
closed-branches to total tags)
* that it's not a release
* reasonably well that it's the end of a development branch without an
explanation on the website
On Mon, May 5, 2014 at 3:40 PM, Drew Farris drew.far...@gmail.com wrote:
I suppose this will be a problem we will encounter with every major/minor
revision as they age, so we have a good chance to hash out a general policy
for this.
I see two categories of actions proposed here:
1) Content
I created PODLINGNAMESEARCH-47 to track our investigation into whether
Apache Slider is a suitable name. I marked unfinished items as TODO, in
case anyone is interested in helping out with the research. There are
instructions and examples here:
http://www.apache.org/foundation/marks/naming.html
Oops, sorry Accumulo devs, I'm having trouble with my mailing list
autocomplete. I'll try to be more careful.
On Mon, May 5, 2014 at 3:55 PM, Billie Rinaldi billie.rina...@gmail.comwrote:
I created PODLINGNAMESEARCH-47 to track our investigation into whether
Apache Slider is a suitable name.
I've noticed lately that my builds of at least the core module always
compile all the hundreds of classes in core, even if I didn't make any
edits. I seem to have been encountering this problem:
Personally, I prefer to recompile everything, but your suggestion seems
like a good workaround.
You should file a bug with MPOM to bump the plugin version in the next
release, but, for what it's worth, I don't consider it worth overriding the
plugin version in our POM.
On May 5, 2014 7:54 PM,
Yeah, I clean more often than not as well.
It appears that even the latest version of the compiler plugin, 3.1, has
the problem, so we may be stuck waiting ...
On Mon, May 5, 2014 at 8:29 PM, Christopher ctubb...@apache.org wrote:
Personally, I prefer to recompile everything, but your
For the record, m2e doesn't use that plugin and Eclipse does do the
incremental compilation if you use that.
On May 5, 2014 8:38 PM, Bill Havanki bhava...@clouderagovt.com wrote:
Yeah, I clean more often than not as well.
It appears that even the latest version of the compiler plugin, 3.1, has
Jerry O'Connell and his merry band from 1995 would like to have a word with
you.
On Mon, May 5, 2014 at 7:23 PM, Billie Rinaldi billie.rina...@gmail.comwrote:
Oops, sorry Accumulo devs, I'm having trouble with my mailing list
autocomplete. I'll try to be more careful.
On Mon, May 5, 2014
37 matches
Mail list logo
