Re: ACCUMULO-2145 fixVersion

I was hoping to make it a contrib. I have tests I run pre and post upgrade to verify correctness and currently it spans versions. They don't currently mix well with the rig from ACCUMULO-2145, but my plan was to work that out after 1.6 gets out. I could instead put up the original versions that we

Re: [DISCUSS] Are governance pages part of the bylaws?

+1 Release requirements should definitely be a part of our bylaws On Mon, Apr 7, 2014 at 7:54 PM, Mike Drob wrote: > Agree with this. The release requirements should be part of the bylaws, the > ancillary documentation can be passed over. > On Apr 7, 2014 12:00 PM, "Bill Havanki" wrote: > > >

Re: 1.6.0 RCs release manager?

Okay. No problem John. I can do it. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Apr 7, 2014 at 10:44 PM, John Vines wrote: > I am going to be unable to, at least for the next two weeks, due to > personal issues. > > Sent from my phone, please pardon the typos and brevity. > O

Re: [DISCUSS] Are governance pages part of the bylaws?

Agree with this. The release requirements should be part of the bylaws, the ancillary documentation can be passed over. On Apr 7, 2014 12:00 PM, "Bill Havanki" wrote: > +1 on the first three. We should keep that distinction for future revisions > - if something sounds more like a rule, it should

Re: 1.6.0 RCs release manager?

I am going to be unable to, at least for the next two weeks, due to personal issues. Sent from my phone, please pardon the typos and brevity. On Apr 7, 2014 7:15 PM, "Christopher" wrote: > Who is the volunteer for creating 1.6.0 RCs? > > I'm willing to build them and start the vote, but I had th

Re: 1.6.0 RCs release manager?

I was under the impression that John "Heard It Through The Grape" Vines was the release manager. On Mon, Apr 7, 2014 at 7:15 PM, Christopher wrote: > Who is the volunteer for creating 1.6.0 RCs? > > I'm willing to build them and start the vote, but I had thought that > somebody else (maybe John

Re: [DISCUSS] Accumulo blog

Looks like the consensus last November[1] was that people were in favor of such a site, but the implementation details were undecided. I imagine if you or someone else wants to spearhead it, there wouldn't be any objection. [1] http://mail-archives.apache.org/mod_mbox/accumulo-dev/201311.mbox

1.6.0 RCs release manager?

Who is the volunteer for creating 1.6.0 RCs? I'm willing to build them and start the vote, but I had thought that somebody else (maybe John Vines?) had volunteered to be the release manager for 1.6.0, though I can't find the thread at the moment (if there was one). -- Christopher L Tubbs II http:

[DISCUSS] Accumulo blog

Devs, I'm wondering if there is interest in creating/maintaining a blog for the community. Apache has infrastructure for this[1] and some instructions for setting one up[2]. I have seen other projects use a different service, so we could go that route too. I'm not a big fan of the Apache blog

Re: Review Request 20087: Move shell into a separate module

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20087/ --- (Updated April 7, 2014, 8:36 p.m.) Review request for accumulo and Christopher

Re: Review Request 19732: ACCUMULO-2558 - unit tests for server/gc

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19732/#review39725 --- Ship it! Ship It! - Mike Drob On March 31, 2014, 11:36 p.m., Bil

Review Request 20101: ACCUMULO-2212 - ZooReaderWriterFactory

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20101/ --- Review request for accumulo. Bugs: ACCUMULO-2212 https://issues.apache.org/

Re: Review Request 20087: Move shell into a separate module

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20087/ --- (Updated April 7, 2014, 5:33 p.m.) Review request for accumulo and Christopher

Re: Review Request 20087: Move shell into a separate module

> On April 7, 2014, 12:25 p.m., Christopher Tubbs wrote: > > shell/pom.xml, line 67 > > > > > > Drop all provided tags. > > Mike Drob wrote: > I thought "provided" prevented transitive dependencies from getting >

Re: Review Request 20087: Move shell into a separate module

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20087/ --- (Updated April 7, 2014, 4:59 p.m.) Review request for accumulo and Christopher

Re: Review Request 20087: Move shell into a separate module

> On April 7, 2014, 4:25 p.m., Christopher Tubbs wrote: > > core/src/main/java/org/apache/accumulo/core/util/shell/commands/TraceCommand.java, > > line 56 > > > > > > Change seems out of scope of the issue, but not a b

Re: Review Request 20087: Move shell into a separate module

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20087/#review39686 --- core/src/main/java/org/apache/accumulo/core/util/shell/commands/Tra

Re: Review Request 20087: Move shell into a separate module

> On April 7, 2014, 4:07 p.m., Billie Rinaldi wrote: > > Other modules depend on the shell, so the new module will have to be added > > to their dependencies. Yep. On page 6 of the diff: https://reviews.apache.org/r/20087/diff/?page=6#110 - Mike -

Re: Review Request 20087: Move shell into a separate module

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20087/#review39683 --- Other modules depend on the shell, so the new module will have to be

Re: Which is stable?

With the "stable" tag, I think there is a perception that we might do experimental or dev releases like many other open source projects do. Since we don't do that, maybe we should drop the tags to reduce our web page maintenance and avoid confusion. I think latest is always stable for us unless spe

Re: Which is stable?

> > b. mark 1.5.1 as "latest, stable", 1.4.5 as "legacy" or "previous > supported release". > +1

Re: [DISCUSS] Are governance pages part of the bylaws?

+1 on the first three. We should keep that distinction for future revisions - if something sounds more like a rule, it should go into a bylaw-ish doc instead. The release guide has a lot of how-to stuff which I think isn't bylaw-worthy. Some elements, like the required tests for releases, probably

Re: Which is stable?

On 4/7/14, 11:59 AM, Eric Newton wrote: b. mark 1.5.1 as "latest, stable", 1.4.5 as "legacy" or "previous supported release". +1 +1

Which is stable?

1.4.5 is marked as "(STABLE)" on the Downloads page. I think there's maybe a few issues with this. 1. "STABLE" vs. "LATEST", seems to imply "use 1.4.5, as 1.5.1 is risky". I'm not sure that's the implication we want to be making, as it will discourage users from using 1.5.x when it's the latest su

Review Request 20087: Move shell into a separate module

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20087/ --- Review request for accumulo and Christopher Tubbs. Bugs: ACCUMULO-1879 http

Re: JIRA usage: Bug vs. Improvement vs. New Feature

The JIRA default issue type, in my browser, actually appear to be the last one I selected (probably saved in a cookie). "Bug" might be the default if no previous issue type had been selected, though. Personally, I'd prefer this field be blank, but required, for new issues, regardless of previous i

Re: A defense for ACCUMULO-1395 in 1.6.0

On Mon, Apr 7, 2014 at 11:34 AM, Christopher wrote: > Okay, so it sounds like all those who objected to this for 1.6.0 are > okay with the compromise of leaving the examples in place for 1.6.0. > So, I'll proceed with that. Thanks, all! > > (Mike, I'm not sure it how to mark it as experimental, o

Re: A defense for ACCUMULO-1395 in 1.6.0

Okay, so it sounds like all those who objected to this for 1.6.0 are okay with the compromise of leaving the examples in place for 1.6.0. So, I'll proceed with that. Thanks, all! (Mike, I'm not sure it how to mark it as experimental, or that it is experimental in the first place, but from what you

Re: Backwards compatibility of traces

On 4/7/14, 10:54 AM, John Vines wrote: Given our support of backwards compatibility, does anyone have a preference for how traces are stored? I ask because I have noticed some places where our internal trace hooks are named with collisions so that you get multiple events with the same identifier

Re: Backwards compatibility of traces

3457+0 shell@john-P15xEMx shell:root 9+1603 shell@john-P15xEMx close 9+1603 sh...@john-p15xemxorg.apache.accumulo.core.client.impl.TabletServerBatchWriter$MutationWriter 1 8+1604 sh...@john-p15xemxorg.apache.accumulo.core.client.impl.TabletServerBatchWriter$MutationWriter 1

[DISCUSS] Are governance pages part of the bylaws?

We have the following pages in the governance section of our website: http://accumulo.apache.org/governance/voting.html http://accumulo.apache.org/governance/consensusBuilding.html http://accumulo.apache.org/governance/lazyConsensus.html http://accumulo.apache.org/governance/releasing.html In my

Re: [VOTE] Define CTR in Bylaws

+1 Adam On Mon, Apr 7, 2014 at 10:11 AM, Billie Rinaldi wrote: > Please vote on applying the following changes to the Accumulo bylaws ( > http://accumulo.apache.org/bylaws.html). If the "Code Change" action has > been removed, it will be reintroduced along with these changes. > > This vote wi

Re: Backwards compatibility of traces

Can you give an example of where this happens? On Mon, Apr 7, 2014 at 10:54 AM, John Vines wrote: > Given our support of backwards compatibility, does anyone have a preference > for how traces are stored? > > I ask because I have noticed some places where our internal trace hooks are > named wi

Re: JIRA usage: Bug vs. Improvement vs. New Feature

I think a tangible improvement to come out of this would be to tweak our "report an issue" page. Our current JIRA defaults are for each issue to be a "Major" priority "Bug." This seems to cause a lot of noise for determining which issues are actually bugs or improvements, and which issues are real

Re: [DISCUSS] Bugs-only strictness for bugfix releases

On 4/7/14, 10:53 AM, Keith Turner wrote: On Mon, Apr 7, 2014 at 10:43 AM, Josh Elser wrote: >I agree that our release "model" doesn't fully allow for a proper breadth >of "changes" to the codebase. > >My view of the current model is as Christopher described (long-term >support and bugfix); how

JIRA usage: Bug vs. Improvement vs. New Feature

In the '[DISCUSS] Bugs-only strictness for bugfix releases' thread, Mike Drob brought up the concern that the definitions of "bugs", "improvements" and "new features" may be ill-defined. I provided one explanation for how I was interpreting those in that thread, which I won't duplicate here, for b

Re: [DISCUSS] Bugs-only strictness for bugfix releases

Forking is a good idea. On Mon, Apr 7, 2014 at 10:48 AM, Christopher wrote: > Mike, > > Bug would be non-conformance to intended/designed behavior, such that > it causes failures in the application, regardless of who reported it. > For instance, returning a null, when code that receives that re

Backwards compatibility of traces

Given our support of backwards compatibility, does anyone have a preference for how traces are stored? I ask because I have noticed some places where our internal trace hooks are named with collisions so that you get multiple events with the same identifier which are actually different events. I w

Re: [DISCUSS] Bugs-only strictness for bugfix releases

On Mon, Apr 7, 2014 at 10:43 AM, Josh Elser wrote: > I agree that our release "model" doesn't fully allow for a proper breadth > of "changes" to the codebase. > > My view of the current model is as Christopher described (long-term > support and bugfix); however, how it was also described by a few

Re: [DISCUSS] Bugs-only strictness for bugfix releases

Mike, Bug would be non-conformance to intended/designed behavior, such that it causes failures in the application, regardless of who reported it. For instance, returning a null, when code that receives that returned value expects only non-null values, and the null value causes breakage in some way

Re: [VOTE] Define CTR in Bylaws

+1 On Mon, Apr 7, 2014 at 10:11 AM, Billie Rinaldi wrote: > Please vote on applying the following changes to the Accumulo bylaws ( > http://accumulo.apache.org/bylaws.html). If the "Code Change" action has > been removed, it will be reintroduced along with these changes. > > This vote will re

Re: [DISCUSS] Bugs-only strictness for bugfix releases

I agree that our release "model" doesn't fully allow for a proper breadth of "changes" to the codebase. My view of the current model is as Christopher described (long-term support and bugfix); however, how it was also described by a few others, the community wants "more" than this model provid

Re: [DISCUSS] Bugs-only strictness for bugfix releases

On Thu, Apr 3, 2014 at 3:44 PM, Christopher wrote: > I don't think that's it's quite true to say '1.major.minor' is our de > facto scheme. Once again, I think many of us have always viewed it as > '1.long-term-support.bugfix'. > Thats how I have thought of it. It the major version that was a me

Re: [VOTE] Define CTR in Bylaws

+1 -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Apr 7, 2014 at 10:11 AM, Billie Rinaldi wrote: > Please vote on applying the following changes to the Accumulo bylaws ( > http://accumulo.apache.org/bylaws.html). If the "Code Change" action has > been removed, it will be reintr

Re: [VOTE] Define CTR in Bylaws

Are the voting pages and lazy consensus pages considered part of the bylaws? Or can they be changed on a whim?

Re: [VOTE] Define CTR in Bylaws

+1 On 4/7/14, 10:11 AM, Billie Rinaldi wrote: Please vote on applying the following changes to the Accumulo bylaws ( http://accumulo.apache.org/bylaws.html). If the "Code Change" action has been removed, it will be reintroduced along with these changes. This vote will remain open for 7 days an

Re: [VOTE] Define CTR in Bylaws

+1 On Mon, Apr 7, 2014 at 10:11 AM, Billie Rinaldi wrote: > Please vote on applying the following changes to the Accumulo bylaws ( > http://accumulo.apache.org/bylaws.html). If the "Code Change" action has > been removed, it will be reintroduced along with these changes. > > This vote will rem

Re: [VOTE] Define CTR in Bylaws

+1 Sent from my phone, please pardon the typos and brevity. On Apr 7, 2014 10:11 AM, "Billie Rinaldi" wrote: > Please vote on applying the following changes to the Accumulo bylaws ( > http://accumulo.apache.org/bylaws.html). If the "Code Change" action has > been removed, it will be reintroduce

[VOTE] Define CTR in Bylaws

Please vote on applying the following changes to the Accumulo bylaws ( http://accumulo.apache.org/bylaws.html). If the "Code Change" action has been removed, it will be reintroduced along with these changes. This vote will remain open for 7 days and requires majority approval to pass. [ ] +1 - "

Re: [DISCUSS] Bugs-only strictness for bugfix releases

A bug would be something that's an actual issue outside of the expected behavior of the program-- for instance, if we're getting a NullPointerException while running a scan of a table that worked in a previous state of the source code. An improvement would be something that makes us better off, bu

Re: A defense for ACCUMULO-1395 in 1.6.0

If there is a way to mark the changes as experimental in 1.6.0 I would be most happy with that, otherwise just applying them and leaving the examples is fine. Removing the examples from 1.7 is the way to go, in my opinion. My main issue was that this change would be very surprising for downstream

Re: [DISCUSS] Bugs-only strictness for bugfix releases

Christopher, Can you provide a delineation between bug fix and improvement? I've noticed that you recategorized several issues, including ACCUMULO-2638 and ACCUMULO-2639 and was wondering what your criteria was for such. Is a bug-fix only something that has been reported by a user? Mike On Fri