Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: <CAOyNEs57rawkfXNEvxba1hbuYrXrJnTqnK-zZRwbT62dy3C1Wg@mail.gmail.com>
References: <CAL5zq9bjFUirOZyruoh9H1DggkxmWo7+nPvTbcdwc8dVfT54uw@mail.gmail.com>
 <CAOyNEs59HaPjxr+oX3QcuzgwENdUVL7JLjjj3=MGT9-b5-aujw@mail.gmail.com>
 <CAOyNEs7=zLXbMYup99yBAjKeJC8eDyQjKCe27cFqcQjU+M=row@mail.gmail.com>
 <00a201d1fcc3$d6eacf30$84c06d90$@comcast.net> <CAOyNEs6t-YrWusCBPtyDRcNYnnmXqvuLpQ2o0tavZFXKEGbg7Q@mail.gmail.com>
 <CAOyNEs5YHEwGCiCdFe33RZrqMT2V8a_K3zi0DOqBC0XuCSOPfQ@mail.gmail.com>
 <CAOyNEs44Ai9z8XMGN1Y9OAzc9iQtKvGh0TtCdbU3pcj4gvHTSw@mail.gmail.com> <CAOyNEs57rawkfXNEvxba1hbuYrXrJnTqnK-zZRwbT62dy3C1Wg@mail.gmail.com>
From: Josh Elser <josh.elser@gmail.com>
Date: Mon, 22 Aug 2016 18:58:29 -0400
Message-ID: <CAOyNEs4GiN8aTcho5PjAszx13EcPoT-MZ3k24_Gt=HViKomHzw@mail.gmail.com>
Subject: RE: [VOTE] Plan for next release
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=001a114e56249ff95e053ab0fcdc
archived-at: Mon, 22 Aug 2016 22:58:43 -0000

--001a114e56249ff95e053ab0fcdc
Content-Type: text/plain; charset=UTF-8

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> 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> 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> 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] On Behalf Of
>> > Josh Elser
>> > Sent: Monday, August 22, 2016 6:17 PM
>> > To: dev@accumulo.apache.org
>> > 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> wrote:
>> >
>> > > -1
>> > >
>> > > On Aug 22, 2016 17:22, "Christopher" <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)
>> > >>
>> > >
>>
>>
>>

--001a114e56249ff95e053ab0fcdc--