RE: [VOTE] Plan for next release

+1 Sending anyway - I don't care that Christopher can type faster (and probably more coherently) and sorry if this is long, trying to layout my thoughts. tl;dr We would likely skip any 1.8 versions and jump to 2.x. Eol-ing 1.7.x "soon" would likely force us to take additional risk and move fast

Re: [VOTE] Plan for next release

-1 I would like to see the current feature set we've been building towards in 1.8 released with support for JDK7, both because that's what I see customers use and because that was the expectation as folks have contributed work towards this release in the little over 10 months since 1.7.0. we just

Re: [VOTE] Plan for next release

Just want to respond to a few points so far: 1. With my revert of the previously destabilizing changes I introduced in master, the master branch and 1.8 branches are *nearly* identical in functionality, backwards-compatibility and suitability for release, with only a few substantive differences. T

Re: [VOTE] Plan for next release

-1, primarily with the spirit of "Release Early, Release Often ". Let's get our changes out there, rather than wait another month to add in Java 8. My vote is not religious, however, and it could change if someone argues for some incre

Re: [VOTE] Plan for next release

Again, sorry for the spam from me. I should've just turned off my phone instead of trying to catch up while doing other things. It still seems to me that the predominant concern proposed here is an increased burden on maintenance. However, avoiding 1.8 and calling it 2.0 instead feels like kic

RE: [VOTE] Plan for next release

Ok, I need to step back. I see that minJdk 8 was suggested but maybe not using any new APIs for this proposed 2.0 release? This isn't 100% clear to me at present. I will have to reread everything later tonight. On Aug 22, 2016 18:49, "Josh Elser" wrote: > (sorry posting from phone) > > I missed

RE: [VOTE] Plan for next release

(sorry posting from phone) I missed the run jdk7 artifacts on jdk8 comment: I am not concerned about this case (Oracle worries about it for me). I am worried about jdk8 features being introduced in this hypothetical 2.0 which preclude users from using jdk7 (for a primary reason of "I wanna us new

RE: [VOTE] Plan for next release

2.0 is not released, so there is no burden. Why do we need to maintain 1.6 or 1.7 as active? Why not eol and provide actual testing and migration strategies to actually *deal* with the maintenance burden instead of pushing it onto the users? I would counter your question about tagging but not rel

RE: [VOTE] Plan for next release

I share your concerns and have proposed releasing a 1.8.0 as-is, followed by a 2.0 with much the same artifacts plus Java 8 source. In talking with Christopher about this though, that means that the community would be supporting 1.6 (until 1.6.6 is released), 1.7.x, 1.8.x, and 2.0.x. Being on u

Re: [VOTE] Plan for next release

Mike Wall asked if I could expand. I realized that my objections were probably only in IRC with Christopher and didn't get cross-posted. I had thought that they were already present in the discussion thread. 1. 1.8.0 is practically released already as-is. I spent a good chunk of the last week baby

Re: [VOTE] Plan for next release

-1 On Aug 22, 2016 17:22, "Christopher" wrote: > After our lengthy (sorry for that) discussions about Java 8, 1.8.0, and > 2.0.0, I wanted to bring us to a vote, just so we can have a concrete plan > of action, without any ambiguity or uncertainty. A vote is the best option > available for resol

Re: [VOTE] Plan for next release

On Mon, Aug 22, 2016 at 5:38 PM Michael Wall wrote: > The only negative I can see is that the work we did for the 1.8 RCs is > wasted. The advantages listed above far outweigh that for me. > Not entirely wasted. The testing was informative and produced a few issues to address. It also gave me s

RE: [VOTE] Plan for next release

+1 Additionally, I'm also +1 for removing deprecated items. Leaving them in will cause more code to be modified as bugs are fixed and features added. Let's rip the band-aid off and move forward. > -Original Message- > From: Christopher [mailto:ctubb...@apache.org] > Sent: Monday, August

Re: [VOTE] Plan for next release

+1 After talking this over with Christopher and others since Fri, I really like the following: - easing the testing burden by removing the 1.8 branch that needed to be tested against both Java 1.7 and 1.8 - simplifying development by getting back to developing in master - finally getting to use Ja

Re: [VOTE] Plan for next release

+1 to move to 2.0 unless you plan on naming the release after me. On Mon, Aug 22, 2016 at 5:24 PM, Christopher wrote: > My vote is +1, because I don't think we *need* an extra release line named > 1.8, when a 2.0 release from master will suffice, and in particular because > of the backwards-comp

Re: [VOTE] Plan for next release

My vote is +1, because I don't think we *need* an extra release line named 1.8, when a 2.0 release from master will suffice, and in particular because of the backwards-compatibilities it will have with 1.7/1.6. On Mon, Aug 22, 2016 at 5:21 PM Christopher wrote: > After our lengthy (sorry for tha

[VOTE] Plan for next release

After our lengthy (sorry for that) discussions about Java 8, 1.8.0, and 2.0.0, I wanted to bring us to a vote, just so we can have a concrete plan of action, without any ambiguity or uncertainty. A vote is the best option available for resolving differences of opinion about our upcoming release pla

[GitHub] accumulo issue #140: ACCUMULO-4419: Change how compression delegation works

Github user phrocker commented on the issue: https://github.com/apache/accumulo/pull/140 I didn't build the java doc. there are errors. I'm going to correct and re-submit. In the mean time please send along any comments. --- If your project is set up for it, you can reply to this em

[GitHub] accumulo pull request #140: ACCUMULO-4419: Change how compression delegation...

Github user phrocker commented on a diff in the pull request: https://github.com/apache/accumulo/pull/140#discussion_r75718866 --- Diff: core/src/main/java/org/apache/accumulo/core/file/rfile/bcfile/codec/CompressionUpdater.java --- @@ -0,0 +1,84 @@ +/* + * Licensed to the

[GitHub] accumulo pull request #140: ACCUMULO-4419: Change how compression delegation...

Github user joshelser commented on a diff in the pull request: https://github.com/apache/accumulo/pull/140#discussion_r75715831 --- Diff: core/src/main/java/org/apache/accumulo/core/file/rfile/bcfile/codec/CompressionUpdater.java --- @@ -0,0 +1,84 @@ +/* + * Licensed to th

[GitHub] accumulo pull request #140: ACCUMULO-4419: Change how compression delegation...

Github user phrocker commented on a diff in the pull request: https://github.com/apache/accumulo/pull/140#discussion_r75715837 --- Diff: core/src/main/java/org/apache/accumulo/core/file/rfile/bcfile/Compression.java --- @@ -420,7 +439,7 @@ public InputStream createDecompressionSt

[GitHub] accumulo pull request #140: ACCUMULO-4419: Change how compression delegation...

Github user phrocker commented on a diff in the pull request: https://github.com/apache/accumulo/pull/140#discussion_r75715696 --- Diff: core/src/main/java/org/apache/accumulo/core/conf/Property.java --- @@ -349,7 +349,18 @@ "Memory to provide to batchwriter to replay mut

[GitHub] accumulo pull request #140: ACCUMULO-4419: Change how compression delegation...

GitHub user phrocker opened a pull request: https://github.com/apache/accumulo/pull/140 ACCUMULO-4419: Change how compression delegation works This commit includes A compression pool not based on CodecPool, a default factory that does no pooling. Changes are also in place tha