+1 to semver
+1 to 1 major release before removing deprecated items
+1 to forward compatibility between bugfix releases
What's the version # for the master branch if these rules are applied?
--
*From: *Christopher ctubb...@apache.org
*To: *Accumulo Dev List
On Tue, Dec 2, 2014 at 3:07 PM, John Vines vi...@apache.org wrote:
-1 I do not like the idea of committing to 1.7.0-1.9.9... API additions for
the 2.0 API. We have already come to the consensus that 2.0 will break the
1.x API which provides a lot of breathing room and freedom from old
Can
We are paying the penalty for not deciding on versioning rules. We started the
discussion several times and punted until 2.0. We should have it now, and apply
it.
- Original Message -
From: Brian Loss bfl...@praxiseng.com
To: dev@accumulo.apache.org
Cc: vi...@apache.org
Sent:
We are paying the penalty for not deciding on versioning rules. We started the
discussion several times and punted until 2.0. We should have it now, and apply
it.
- Original Message -
From: Brian Loss bfl...@praxiseng.com
To: dev@accumulo.apache.org
Cc: vi...@apache.org
Sent:
On Wed, Dec 3, 2014 at 9:48 AM, Sean Busbey bus...@cloudera.com wrote:
API additions matter here because when a system integrator makes an
application on top of Accumulo they often start at the latest version they
can find. Later, they may have a client with a regulatory requirement to
use an
One if the prerequisites that delayed us on adopting semver is that we
haven't defined what is covered when considering statement about
compatibility.
We'll need to come up with at least a first pass before we could vote. I'd
prefer it not just be the way we currently define the public API, since
Been having issues responding.
(I was still confused so I just chatted with John on the subject of his -1)
He was under the impression that it would not be feasible to leave the
existing 1.X APIs in place with the creation of the 2.0 APIs; whereas, I
had assumed that this wouldn't be an issue.
He brought up the issue of
On Wed, Dec 3, 2014 at 4:41 PM, Christopher ctubb...@apache.org wrote:
On Wed, Dec 3, 2014 at 10:31 AM, Keith Turner ke...@deenlo.com wrote:
On Tue, Dec 2, 2014 at 3:01 PM, Christopher ctubb...@apache.org wrote:
Following the conversation on the [VOTE] thread for ACCUMULO-3176, it
Can we bring the discussion back around? I feel like we have two
separate things going on here.
1) Can we avoid further churn in the public API for [1.7.0,2.0.0] by
avoiding any removal or additional deprecation.
2) In 2.0.0, what are we actually going to remove that is already deprecated
On Wed, Dec 3, 2014 at 5:28 PM, John Vines vi...@apache.org wrote:
I stand by my -1. This vote would guarantee a level of API compatibility
that I don't think we should be held to.
Can you give some some specific reasons for your -1?
On Wed, Dec 3, 2014 at 5:15 PM, Christopher
On Dec 4, 2014 6:55 AM, Josh Elser josh.el...@gmail.com wrote:
(I was still confused so I just chatted with John on the subject of his
-1)
He was under the impression that it would not be feasible to leave the
existing 1.X APIs in place with the creation of the 2.0 APIs; whereas, I
had assumed
On Wed, Dec 3, 2014 at 12:38 PM, Christopher ctubb...@apache.org wrote:
On Wed, Dec 3, 2014 at 10:10 AM, Keith Turner ke...@deenlo.com wrote:
On Tue, Dec 2, 2014 at 3:01 PM, Christopher ctubb...@apache.org wrote:
Following the conversation on the [VOTE] thread for ACCUMULO-3176, it
+1 to semver
+1 to 1 major release before removing deprecated items
+1 to forward compatibility between bugfix releases
What's the version # for the master branch if these rules are applied?
- Original Message -
From: Christopher ctubb...@apache.org
To: Accumulo Dev List
Bringing this out of the normal JIRA notification spam.
Your opinions are appreciated.
Original Message
Subject: [jira] [Commented] (ACCUMULO-1817) Use Hadoop Metrics2
Date: Wed, 3 Dec 2014 17:12:13 + (UTC)
From: Josh Elser (JIRA) j...@apache.org
Reply-To: j...@apache.org
Christopher, Eric, Josh, Billie, Mike, and I are meeting on Dec 9 to work
on Accumulo together for the day in Central MD. If you are interested in
joining us, email me directly. We are meeting in a small conf room, so
space is limited.
Keith
On Wed, Dec 3, 2014 at 4:06 PM, Josh Elser josh.el...@gmail.com wrote:
Can we bring the discussion back around? I feel like we have two separate
things going on here.
1) Can we avoid further churn in the public API for [1.7.0,2.0.0] by
avoiding any removal or additional deprecation.
Do you
Like I said, I think we are having this pain because we have not defined and
agreed to the meaning of our version numbering scheme. I'd rather have that
discussion and agree to something, as that will likely inform us as to what
version the master branch is currently based on the changes in
On Thu, Dec 4, 2014 at 8:15 AM, Sean Busbey bus...@cloudera.com wrote:
On Dec 4, 2014 6:55 AM, Josh Elser josh.el...@gmail.com wrote:
(I was still confused so I just chatted with John on the subject of his
-1)
He was under the impression that it would not be feasible to leave the
Can we reach a compromise here that the general idea that had been
presented will be followed and, of such an impasse is found in supporting
the old api, we will have another discussion on what to do when we actually
have a concrete problem?
I feel like we can't get around this issue otherwise
On Wed, Dec 3, 2014 at 4:06 PM, Josh Elser josh.el...@gmail.com wrote:
Can we bring the discussion back around? I feel like we have two separate
things going on here.
1) Can we avoid further churn in the public API for [1.7.0,2.0.0] by
avoiding any removal or additional deprecation.
I so
I would very much like the new API to be something that we think has the
right shape, ignoring implementation details. Otherwise we end up with
something like a mapred/uce split and that still has people confused about
which is the right one.
On Thu, Dec 4, 2014 at 8:46 AM, Josh Elser
On Wed, Dec 3, 2014 at 6:48 PM, John Vines vi...@apache.org wrote:
It's hard to track this down-
http://www.mail-archive.com/dev@accumulo.apache.org/msg07336.html has
Busbey mentioning that 2.0 was breaking, which no one reacted to, implying
this was known
Sent from my phone, please pardon the typos and brevity.
On Dec 4, 2014 11:20 AM, Keith Turner ke...@deenlo.com wrote:
On Wed, Dec 3, 2014 at 6:48 PM, John Vines vi...@apache.org wrote:
It's hard to track this down-
http://www.mail-archive.com/dev@accumulo.apache.org/msg07336.html has
I'm not trying to say that we should accept a half-baked new API, just
that, despite our best efforts, we'll likely mess up something
(interface or implementation).
We want people to use and stick to the new API (better versioning should
help us release quick fixes when we find aforementioned
On Thu, Dec 4, 2014 at 11:30 AM, John Vines vi...@apache.org wrote:
Sent from my phone, please pardon the typos and brevity.
On Dec 4, 2014 11:20 AM, Keith Turner ke...@deenlo.com wrote:
On Wed, Dec 3, 2014 at 6:48 PM, John Vines vi...@apache.org wrote:
It's hard to track this down-
On Thu, Dec 4, 2014 at 11:34 AM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:30 AM, John Vines vi...@apache.org wrote:
Sent from my phone, please pardon the typos and brevity.
On Dec 4, 2014 11:20 AM, Keith Turner ke...@deenlo.com wrote:
On Wed, Dec 3, 2014 at 6:48
John Vines wrote:
Though I feel the biggest reasoning is our switch to semantic
versioning. And from semver.org,
1. MAJOR version when you make incompatible API changes
Right and dropping deprecated APIs is an incompatible change. Do you think
the following two
On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser josh.el...@gmail.com wrote:
John Vines wrote:
Though I feel the biggest reasoning is our switch to semantic
versioning. And from semver.org,
1. MAJOR version when you make incompatible API changes
Right and
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser josh.el...@gmail.com wrote:
John Vines wrote:
Though I feel the biggest reasoning is our switch to semantic
versioning. And from semver.org,
1. MAJOR
John Vines wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh Elserjosh.el...@gmail.com wrote:
John Vines wrote:
Though I feel the biggest reasoning is our switch to semantic
versioning. And from semver.org,
On Thu, Dec 4, 2014 at 11:57 AM, John Vines vi...@apache.org wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser josh.el...@gmail.com
wrote:
John Vines wrote:
Though I feel the biggest reasoning is our switch to
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser josh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh Elserjosh.el...@gmail.com
wrote:
John Vines wrote:
Though I feel the biggest reasoning
Sean Busbey wrote:
On Thu, Dec 4, 2014 at 11:11 AM, Josh Elserjosh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh Elserjosh.el...@gmail.com
wrote:
John Vines wrote:
Though I feel
John Vines wrote:
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elserjosh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh Elserjosh.el...@gmail.com
wrote:
John Vines wrote:
Though I feel
On Thu, Dec 4, 2014 at 11:11 AM, Josh Elser josh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh Elserjosh.el...@gmail.com
wrote:
John Vines wrote:
Though I feel the biggest reasoning
On Thu, Dec 4, 2014 at 12:17 PM, John Vines vi...@apache.org wrote:
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser josh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh
On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 12:17 PM, John Vines vi...@apache.org wrote:
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser josh.el...@gmail.com
wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith
Yes, you have identified the issues I perceive.
A proxy is one acceptable solution, yes. But given the statements people
have made about wanting to keep things around like the 1.x batchwriter API,
I question how acceptable running proxies will be / the cost of
implementing and maintaining a full
-1 because I don't understand what is being proposed and it sounds like a
lot of other people do not either.
It looks like we've had several proposed amendments to the original
proposal, but I am very unclear on if we are voting on any of them or if
they are simply brought up as nice discussion
On Thu, Dec 4, 2014 at 11:30 AM, John Vines vi...@apache.org wrote:
Sent from my phone, please pardon the typos and brevity.
On Dec 4, 2014 11:20 AM, Keith Turner ke...@deenlo.com wrote:
On Wed, Dec 3, 2014 at 6:48 PM, John Vines vi...@apache.org wrote:
It's hard to track this down-
On Thu, Dec 4, 2014 at 12:29 PM, Sean Busbey bus...@cloudera.com wrote:
On Thu, Dec 4, 2014 at 11:11 AM, Josh Elser josh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 11:40 AM, Josh
On Thu, Dec 4, 2014 at 12:38 PM, Christopher ctubb...@apache.org wrote:
If I understand the rest of John's concern correctly, the risk of keeping
around the old 1.x API having an impact on the form of the new 2.x API is
largely tied to involvement in the RPC layer.
I'd expect the RPC
On Thu, Dec 4, 2014 at 7:53 AM, Sean Busbey bus...@cloudera.com wrote:
One if the prerequisites that delayed us on adopting semver is that we
haven't defined what is covered when considering statement about
compatibility.
True. We can use our current definition of public API, and our wire
On Wed, Dec 3, 2014 at 1:41 PM, dlmar...@comcast.net wrote:
+1 to semver
+1 to 1 major release before removing deprecated items
+1 to forward compatibility between bugfix releases
What's the version # for the master branch if these rules are applied?
Well, I'd say 1.7 still, since it is
It seems as if API v2.0 should be its own project.
On Thu, Dec 4, 2014 at 1:32 PM, Christopher ctubb...@apache.org wrote:
On Thu, Dec 4, 2014 at 11:30 AM, John Vines vi...@apache.org wrote:
Sent from my phone, please pardon the typos and brevity.
On Dec 4, 2014 11:20 AM, Keith Turner
Christopher wrote:
On Wed, Dec 3, 2014 at 1:41 PM,dlmar...@comcast.net wrote:
+1 to semver
+1 to 1 major release before removing deprecated items
+1 to forward compatibility between bugfix releases
What's the version # for the master branch if these rules are applied?
Well, I'd
I have never said we shouldn't strive for it. I am saying having a good 2.0
api is more important than that. And by putting in requirements about how
1.x APIs appear in 2.x I feel we are leaving us unable to enforce my
preferred ordering of priorities.
On Thu, Dec 4, 2014 at 1:32 PM, Christopher
On Thu, Dec 4, 2014 at 11:35 AM, Josh Elser josh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elserjosh.el...@gmail.com wrote:
John Vines wrote:
I feel like I'm repeating myself. My concern is that the
implementation
details of maintaining the 1.x
On Thu, Dec 4, 2014 at 1:22 PM, Mike Drob mad...@cloudera.com wrote:
-1 because I don't understand what is being proposed and it sounds like a
lot of other people do not either.
It would be nice if you could outline what you don't understand about the
original proposal.
It looks like
On Thu, Dec 4, 2014 at 2:17 PM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 1:22 PM, Mike Drob mad...@cloudera.com wrote:
-1 because I don't understand what is being proposed and it sounds like a
lot of other people do not either.
It would be nice if you could outline
Mike Drob wrote:
It looks like we've had several proposed amendments to the original
proposal, but I am very unclear on if we are voting on any of them or if
they are simply brought up as nice discussion points. There's been so
much
discussion in this VOTE thread (a strange
Sean Busbey wrote:
On Thu, Dec 4, 2014 at 11:35 AM, Josh Elserjosh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elserjosh.el...@gmail.com wrote:
John Vines wrote:
I feel like I'm repeating myself. My concern is that the
implementation
details of
On Thu, Dec 4, 2014 at 3:44 PM, Josh Elser josh.el...@gmail.com wrote:
Mike Drob wrote:
It looks like we've had several proposed amendments to the original
proposal, but I am very unclear on if we are voting on any of
them or if
they are simply brought up as nice discussion points.
On Thu, Dec 4, 2014 at 12:59 PM, John Vines vi...@apache.org wrote:
On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 12:17 PM, John Vines vi...@apache.org wrote:
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser josh.el...@gmail.com
wrote:
Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
This is not something I encourage but I think this is something we should
have in our pocket just in case.
On Thu, Dec 4, 2014 at 3:56 PM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 12:59 PM, John Vines
On Thu, Dec 4, 2014 at 4:00 PM, John Vines vi...@apache.org wrote:
Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
This is not something I encourage but I think this is something we should
have in our pocket just in case.
Maybe not encourage == discourage. I think
On Thu, Dec 4, 2014 at 4:00 PM, John Vines vi...@apache.org wrote:
Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
This is not something I encourage but I think this is something we should
have in our pocket just in case.
What do you think about the following?
*
On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 4:00 PM, John Vines vi...@apache.org wrote:
Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
This is not something I encourage but I think this is something we should
have in
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26507/
---
(Updated Dec. 4, 2014, 9:54 p.m.)
Review request for accumulo.
Changes
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27096/
---
(Updated Dec. 4, 2014, 10:13 p.m.)
Review request for accumulo.
Changes
On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner ke...@deenlo.com wrote:
On Thu, Dec 4, 2014 at 4:00 PM, John Vines vi...@apache.org wrote:
Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
This is not something I encourage but I think this is something we should
have in
I would be okay with a 1.8.0 FINAL (or 1.9 or 1.10 or whatever is the last
number of 1.x line) that exists solely for transitioning. It sounds a bit
like we're gaming it, but if that makes people more comfortable removing
backwards support in 2.0.0 than I'm okay with it.
On Thu, Dec 4, 2014 at
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27096/#review63921
---
Ship it!
I think this looks good. It depends on ACCUMULO-3177, but
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26507/#review63922
---
Ship it!
This patch looks good to me. The latest patch
So I feel the opposite. I think we shouldn't remove deprecated APIs
unless they absolutely break the system. I think removing any undeprecated
APIs is a non-starter.
As a person who has to oversee hundreds of Accumulo instances with many users
writing many programs,
I really want to be able to
Looks like it's working again.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Dec 3, 2014 at 10:51 PM, dlmarion dlmar...@comcast.net wrote:
Been having issues responding.
Last update on this thread was over a week ago. Jenna was kind enough to
squash in my reviews (which were essentially provided to her as a patch on
top of her patch via GitHub). She has updated the ReviewBoard entries, and
I have commented with my +1.
--
Christopher L Tubbs II
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28739/
---
Review request for accumulo.
Bugs: ACCUMULO-3134
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28739/#review63957
---
test/src/test/java/org/apache/accumulo/test/ShellServerIT.java
70 matches
Mail list logo
