accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc P." <marc.par...@gmail.com>
Subject Re: [VOTE] Plan for next release
Date Tue, 23 Aug 2016 13:03:38 GMT
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, <dlmarion@comcast.net> wrote:

> Agreed - this thread should be left to votes only. Let it pass or fail.
>
> ----- Original Message -----
>
> From: "Josh Elser" <josh.elser@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" <ctubbsii@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 <
> dhutchis@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.elser@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.elser@gmail.com
> > > >> <mailto:josh.elser@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.elser@gmail.com
> > > >> <mailto:josh.elser@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, <dlmarion@comcast.net
> > > >> <mailto:dlmarion@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.elser@gmail.com <mailto:
> josh.elser@gmail.com>
> > > >> [mailto:josh.elser@gmail.com <mailto:josh.elser@gmail.com
> >]
> > > >> On Behalf Of
> > > >> > Josh Elser
> > > >> > Sent: Monday, August 22, 2016 6:17 PM
> > > >> > To: dev@accumulo.apache.org <mailto:
> > > dev@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" <elserj@apache.org
> > > >> <mailto:elserj@apache.org>> wrote:
> > > >> >
> > > >> > > -1
> > > >> > >
> > > >> > > On Aug 22, 2016 17:22, "Christopher"
> > > >> <ctubbsii@apache.org <mailto:ctubbsii@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)
> > > >> > >>
> > > >> > >
> > > >>
> > > >>
> > > >>
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message