I think there is value in commenting because after Reading the responses last night I was swayed to -1. Perhaps others might be as well.
On Tue, Aug 23, 2016 at 8:56 AM, <dlmar...@comcast.net> wrote: > Agreed - this thread should be left to votes only. Let it pass or fail. > > ----- Original Message ----- > > From: "Josh Elser" <josh.el...@gmail.com> > To: dev@accumulo.apache.org > Sent: Tuesday, August 23, 2016 8:15:01 AM > Subject: Re: [VOTE] Plan for next release > > If we really need to keep arguing about this, then this vote is premature. > Responses inline. > > On Aug 23, 2016 00:18, "Christopher" <ctubb...@apache.org> wrote: > > > > 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. The master branch is as much ready > for > > a release as the 1.8 branch, and the only reason to do 1.8 instead is if > > these new features are in high-demand for a Java7-only environment. I do > > not think that demand has been demonstrated to exist... only > > hypothesized. However, there *has* been a demand for using Java 8 > features: > > some maven plugins are no longer being patched with support for Java 7 > and > > we can't update to get bug fixes, some libraries contributors have wanted > > to use for their patches require Java 8 and we need a release which they > > can contribute such changes to, libraries like Jetty getting security > > updates and requiring Java 8, etc. > > To clarify, I can think of only one case where a contributor wanted to use > jdk 8. The rest sound like things that you wanted to do (maven plugins and > jetty) > > > 2. Nobody has been giving "I wanna us new shiny APIs!" as a reason. That > is > > a straw man. There are rational reasons for requiring Java 8, which are > > more substantive than thinking it "shiny". Remember that we actually > > branched 1.8 so we could bump master and provide users with an area to > > contribute code which requires Java 8. We're not exactly encouraging > > contributions if it doesn't look like that branch is ever moving towards > a > > release. > > Similarly, claiming that 2.0 is not moving towards a release is a fallacy. > There is nothing blocking a release of 2.0 whenever someone steps up as I > suggested in the discussion tread. > > > 3. The master branch has the same API as the 1.8 branch. Client code > > developed for the current 1.8 branch, even if it's compiled on Java 7, > > should still work against the master branch. There's nothing in the APIs > > that force client code written against older releases, or 1.8 development > > snapshots, to be rebuilt with Java 8. > > Ok? I don't think this was stated as a concern. > > > 4. Regarding kicking the can down the road. After releasing master as > 2.0, > > I expect we'd proceed with our usual release cadence, bugfixes on 1.7 and > > 2.0, while working on new features for 2.1. I would, however, propose a > > change in our dev workflow... no more routine merging to master... leave > > that equal to the latest tag... "future" versions like 2.1, 3.0, etc. > > should be worked in a properly labeled dev branch. However, we can deal > > with that suggestion later. Regardless of the workflow change, I'd expect > > bugfixes for 1.7 and 2.0, while working on 2.1. > > > 5. I agree we need to make sure users have a good upgrade path to safely > > move off of previous releases. Both 1.8 and 2.0 branches currently > support > > upgrades from 1.6. Regardless of what we do for this release, users will > > have a safe path. What additional plans must be made, and how is that > > related to this? Sorry, I didn't follow your reasoning there. > > We have no upgrade instructions and do not have formalized upgrade testing. > There is no organization that would feel comfortable doing production > upgrades of this software given this unless they employ as mass of > committers of Accumulo. > > It is related because moving people off of old releases requires > instructions to do such a move and the expectation through engineering > rigor that everything will go smoothly. > > > 6. The testing burden everybody's talking about assumes we'd release 2.0 > > shortly after a 1.8. If we're willing to EOL 1.7 that soon, then much of > > this burden is relieved. But, I think a rapid EOL of 1.7 would be a > greater > > harm than skipping 1.8 would cause harm to hypothetical users who want > the > > 1.8 feature set on Java 7. > > This seems to be purely based on feelings. My point was that we have been > discussing 1.8 publicly for months if not years. It is not unreasonable to > assume users have been expecting a 1.8 to actually be released in its > current state. > > > 7. Regarding "release early, release often"... we wouldn't need to wait > > another month. We already have a 2.0 branch (master) ready to go with > Java > > 8 added in.. a 2.0.0-rc1 is as easy as a 1.8.0-rc3. This proposal is > simply > > suggesting that those extra commits should be included in the release, > too. > > > > On Mon, Aug 22, 2016 at 8:49 PM Dylan Hutchison < > dhutc...@cs.washington.edu> > > wrote: > > > > > -1, primarily with the spirit of "Release Early, Release Often > > > <https://incubator.apache.org/guides/graduation.html#releases>". 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 incredible difference Java 8 could make in a release *right now*. > > > > > > I don't see enough immediate benefit in releasing a Java 8 branch. Not > > > much Java 8 dependent has changed since introducing Java 8 into > master. We > > > can do Java 8 development with master. > > > > > > I agree with Josh that the maintenance burden does not seem very > different > > > with the proposed plan. Then again I have not been actively developing > new > > > features recently; perhaps someone who is working on a grand change for > 2.0 > > > could comment on how accelerated-release 2.0 would be helpful for > > > development on 3.0. > > > > > > On Mon, Aug 22, 2016 at 5:34 PM, Josh Elser <josh.el...@gmail.com> > wrote: > > > > > > > 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 kicking the can down the road to me. Let's me > describe > > > > the scenario I see: > > > > > > > > Assume we drop 1.8 and do the reverts to make the current master > branch > > > > 2.0.0-SNAPSHOT sans everything but the JDK8 change (as per > Christopher's > > > > original VOTE msg). We will release from master (or some 2.0 branch) > and > > > > then, I believe, the plan laid out states we would try to use the > master > > > > branch for the primary development actions. The current API removals > > > which > > > > are presently slated for 2.0.0 now land in 3.0.0-SNAPSHOT. I would > assume > > > > that this means master would become 3.0.0-SNAPSHOT. However, the next > > > > release we'd be doing is likely a 2.1.0-SNAPSHOT (historically > speaking). > > > > > > > > So, given the above, whether this vote passes with +1's or -1's, I > don't > > > > see any change in what we actually have to support (just in the > naming): > > > > either [1.6, 1.7, 1.8] with 2.0 on deck, or [1.6, 1.7, 2.0] with 2.1 > on > > > > deck (and maybe 3.0?). As such, I think coming up with a plan to > *enable* > > > > users to *safely* and *confidently* move off of older releases > > > > (specifically, EOL both 1.6 *and* 1.7, regardless of this vote) is > the > > > > appropriate solution to a concern about increased maintenance burden. > > > > > > > > To play devil's advocate: I am also making the assumption that we > would > > > > have a normal cadence of 2.x releases (as we have historically have > > > done). > > > > This hasn't been explicitly stated, so I may be misinterpreting > things. > > > > Please do correct me if I'm wrong. > > > > > > > > Josh Elser wrote: > > > > > > > >> 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" <josh.el...@gmail.com > > > >> <mailto:josh.el...@gmail.com>> wrote: > > > >> > > > >> (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 shiny APIs!" without concrete justification). > > > >> > > > >> Christopher has so previously shared his concerns with me about > > > >> obtaining jdk7 packages from the internet. I do not think these > are > > > >> valid concerns to present as justification for the change. > > > >> > > > >> > > > >> On Aug 22, 2016 18:35, "Josh Elser" <josh.el...@gmail.com > > > >> <mailto:josh.el...@gmail.com>> wrote: > > > >> > > > >> 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 releasing > > > >> with "why not fix the packaging issues from rc2 and just make > > > >> the release?" > > > >> > > > >> With the amount of chatter on this vote thread, I am also now > > > >> worried that calling this vote was premature. These are > > > >> discussions that should have been hashed out already.. > > > >> > > > >> > > > >> On Aug 22, 2016 18:23, <dlmar...@comcast.net > > > >> <mailto:dlmar...@comcast.net>> wrote: > > > >> > > > >> 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 update 102, Java 8 seems pretty stable. Plus, > you > > > >> can run your Java 7 binaries with the Java 8 JRE. > > > >> > > > >> Having said that, is there a reason that we can't tag > 1.8.0 > > > >> but not release it and let other downstream providers > create > > > >> their own supported release? > > > >> > > > >> > -----Original Message----- > > > >> > From: josh.el...@gmail.com <mailto: > josh.el...@gmail.com> > > > >> [mailto:josh.el...@gmail.com <mailto:josh.el...@gmail.com > >] > > > >> On Behalf Of > > > >> > Josh Elser > > > >> > Sent: Monday, August 22, 2016 6:17 PM > > > >> > To: dev@accumulo.apache.org <mailto: > > > d...@accumulo.apache.or > > > >> g> > > > >> > Subject: 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 babysitting tests. This change feels no different > > > >> than someone shoe- > > > >> > horning in a big feature at the last minute. > > > >> > > > > >> > 2. I think this is a slap in the face to anyone that > was > > > >> waiting on a 1.8.0 to be > > > >> > released as slap in the face. The release that was > about > > > >> to happen now has > > > >> > an even longer cycle. > > > >> > > > > >> > 3. Assuming that min jdk 8 also implies use of jdk 8 > only > > > >> features (as was > > > >> > mentioned), my experience with customer bases is that > > > >> people are not yet > > > >> > there. Often, these groups do have migration plans in > > > >> place, but I haven't > > > >> > seen one that has a quicker than one year turnaround. > I > > > >> cannot back any of > > > >> > this up with fact, it is merely observations from my > day > > > >> job. > > > >> > > > > >> > I do not find the provided reasons to make this last > > > >> minute change > > > >> > justification enough to do it. I am very much against > it. > > > >> > > > > >> > On Aug 22, 2016 17:58, "Josh Elser" <els...@apache.org > > > >> <mailto:els...@apache.org>> wrote: > > > >> > > > > >> > > -1 > > > >> > > > > > >> > > On Aug 22, 2016 17:22, "Christopher" > > > >> <ctubb...@apache.org <mailto:ctubb...@apache.org>> 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 resolving > differences > > > >> of opinion > > > >> > >> about our upcoming release plans. > > > >> > >> > > > >> > >> The action to vote on is the following: > > > >> > >> > > > >> > >> (+1): Drop 1.8 branch, stabilize the master > > > >> branch, and release > > > >> > >> 2.0.0 from master > > > >> > >> > > > >> > >> If the vote fails to pass, the default action > (which > > > >> is implied by a > > > >> > >> -1) is the following: > > > >> > >> > > > >> > >> (-1): Release 1.8.0, supporting a 1.8.x release > > > >> series; 2.0.0 and > > > >> > >> the master branch will be addressed at some > > > >> unspecified future time > > > >> > >> > > > >> > >> This is a majority vote regarding release plans, > so we > > > >> can make > > > >> > >> progress on a reasonable release timeline. Specific > > > >> changes in a > > > >> > >> branch can still be veto'd while we work towards > the > > > >> release, as > > > >> > >> normal, regardless of the outcome of this vote. > > > >> > >> > > > >> > >> Here's some main points to consider for this vote: > > > >> > >> > > > >> > >> * Everything in the 1.8 branch is included in the > > > >> Master branch. > > > >> > >> * Master branch requires Java 8. > > > >> > >> * Releasing from master will allow us to work from > > > >> master again for > > > >> > >> routine development, instead of reserving master > for > > > >> unstable > > > >> > >> development (which is how it currently has been > > > >> treated). > > > >> > >> * Master branch aggressively removes deprecated > > > >> stuffs; I'm actively > > > >> > >> working on reverting these in master regardless of > the > > > >> vote, because > > > >> > >> they introduced some destabilization. > > > >> > >> * The one deprecation removal which I intend to > keep > > > >> in Master is the > > > >> > >> removal of the trace library (not the tracer > server, > > > >> which will > > > >> > >> stay). We don't need the trace library, because we > now > > > >> use HTrace. If > > > >> > >> people need the deprecated HTrace wrappers for > their > > > >> own code in that > > > >> > >> trace library, they should still be able to use the > > > >> wrappers in the > > > >> > >> 1.7 version of accumulo-trace. They won't need it > for > > > >> Accumulo, > > > >> > >> though, because Accumulo doesn't use it, not even > in > > > >> the 1.7 branch. > > > >> > >> This would be added to the release notes if this > vote > > > >> passes. > > > >> > >> * After reverting the deprecation removals, the > master > > > >> branch is > > > >> > >> *very* similar to the 1.8 branch right now. It > > > >> contains only a few > > > >> > >> extra commits, mostly for Java 8-related cleanups > and > > > >> README > > > >> > >> improvements. (git log origin/1.8..origin/master > > > >> --no-merges > > > >> > >> --oneline) > > > >> > >> * If this vote passes, it will be 100%, or nearly > > > 100%, > > > >> > >> backwards-compatible with 1.7.x, just as 1.8 > branch is > > > >> today. This is > > > >> > >> because there haven't been much changes in the > master > > > >> branch which > > > >> > >> aren't coming from merges from 1.8. This will mean > > > >> that the entire > > > >> > >> 2.x line will be just as backwards-compatible as > this > > > >> next release > > > >> > >> and there will be no significant deprecation > removals > > > >> from [1.7.0, 3.0). > > > >> > >> > > > >> > >> This vote will end on Thu Aug 25 21:30:00 UTC 2016 > > > >> (Thu Aug 25 > > > >> > >> 17:30:00 EDT 2016 / Thu Aug 25 14:30:00 PDT 2016) > > > >> > >> > > > >> > > > > > >> > > > >> > > > >> > > > > >
