accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [VOTE] Plan for next release
Date Tue, 23 Aug 2016 13:51:35 GMT
Err, not where I was going with that comment, Dave. If we have this much
discussion on a vote, it implies that this vote should be scraped and the
discussion continued. Granted, this turned into another discuss already.
I'm not calling for this to be scraped, just stating how this is intended
to work (and does work) elsewhere.

On Aug 23, 2016 08:56, <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