I don't understand the question on my -1. My intention doesn't matter. We have bylaws as a project and the foundation has bylaws where there are gaps; this combination makes clear what the rules are for any vote. AFAICT this vote should be a majority vote.
Two things that we could have done better here: 1) VOTEs should be a formality of expressing what we already know the position of the community to be. That folks are so surprised and blocked up on me following up is a sign that there should have been an appropriately labeled DISCUSS thread. Please do that in the future. 2) To make things clearer for folks, expressly state what the voting rules are when announcing the vote. If you can't work out what they should be from the bylaws, then ask before calling a vote. On Tue, Nov 5, 2019 at 9:55 AM Sean Busbey <bus...@cloudera.com> wrote: > > Yeah I'm reading messages now. > > On Tue, Nov 5, 2019 at 6:32 AM Christopher <ctubb...@apache.org> wrote: > > > > Sean, can you please reply to this and answer the question regarding > > your -1? Thanks. > > > > On Fri, Nov 1, 2019 at 2:40 PM Christopher <ctubb...@apache.org> wrote: > > > > > > I'm not actually sure if this would be considered a veto, or just a -1 > > > on a majority vote. Vetos are used for code changes and are > > > accompanied by technical justifications. This isn't vetoing a code > > > change based on a technical justification. We're merely deciding on a > > > release plan, and the justification appears less technical than social > > > (managing user expectations and upgrade requirements) although I > > > suppose these lines can be blurred, because everything we do is about > > > both people and technology. My assumption is that votes like this are > > > typically majority voting, but the fact that this isn't 100% clear is > > > something that has always bugged me in the ASF. > > > > > > I guess the best thing to do is ask Sean: are you intending your -1 as > > > a veto against any change that would move us in the direction of the > > > proposed plan, or are you willing to permit the majority decision to > > > stand here, whichever way it ends up going? > > > > > > On Fri, Nov 1, 2019 at 2:10 PM Michael Wall <mjw...@apache.org> wrote: > > > > > > > > I am +1 on moving 1.10 to Java 8. > > > > > > > > However Sean's -1 vote is a veto [1] and we can not proceed down this > > > > path > > > > unless it is withdrawn. I can only take the veto to mean there are > > > > customers who would upgrade to Accumulo 1.10 but would not upgrade to > > > > Java > > > > 1.8. Is there anything that would change your mind Sean? > > > > > > > > Thanks > > > > > > > > Mike > > > > > > > > 1 - https://www.apache.org/foundation/voting.html#Veto > > > > > > > > > > > > On Fri, Nov 1, 2019 at 12:46 PM Sean Busbey > > > > <bus...@cloudera.com.invalid> > > > > wrote: > > > > > > > > > Correct, it is up to every user of SemVer to define the public API and > > > > > AFAIK we have chosen not to include things like the Java version > > > > > needed to run Accumulo in ours[1]. > > > > > > > > > > That doesn't mean it's not crappy to our downstream users to do things > > > > > that have a major operational impact upon minor releases. Updating a > > > > > JDK version is a major undertaking. It takes a long time to do in an > > > > > environment with strict change control policies and it sucks. There > > > > > are still shops that run JDK7. There are multiple options for > > > > > purchasing commercial support with security updates for it still. Just > > > > > picking two vendors out of the air[2], Oracle will still provide > > > > > support for almost 2 more years and Azul for almost 3. > > > > > > > > > > That doesn't mean we have to keep supporting JDK7, but be aware that > > > > > we are trading for a gain in developer convenience at the expense of > > > > > operator difficulty. We will probably drive folks into the arms of > > > > > forks that bother to maintain JDK compatibility for these release > > > > > lines. It does inhibit our ability to draw new folks into the > > > > > community, but that's not a fundamental problem I guess. > > > > > > > > > > As an aside, this comment from your cited FAQ is inaccurate on its > > > > > face for practical considerations in the Java ecosystem as cause for > > > > > not needing to worry about the downstream impact of changing a > > > > > dependency. > > > > > > > > > > > Software that explicitly depends on the same dependencies as your > > > > > package should have their own dependency specifications and the > > > > > author will > > > > > notice any conflicts. > > > > > > > > > > We've discussed this a bunch of times. We clearly have disagreement in > > > > > the community about the priority on the tradeoff between developer > > > > > work and operational work. That's okay. > > > > > > > > > > [1]: https://accumulo.apache.org/api/ > > > > > [2]: https://www.azul.com/products/azul-support-roadmap/ > > > > > > > > > > On Fri, Nov 1, 2019 at 7:16 AM Ed Coleman <d...@etcoleman.com> wrote: > > > > > > > > > > > > If I am reading semver correctly ( > > > > > https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api) > > > > > this proposal has no changes to the Accumulo public API, it is an > > > > > update to > > > > > our dependencies - and would not require a major version change. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Sean Busbey [mailto:bus...@cloudera.com.INVALID] > > > > > > Sent: Friday, November 01, 2019 3:52 AM > > > > > > To: dev@accumulo apache. org <dev@accumulo.apache.org> > > > > > > Subject: Re: [VOTE] Proposal to release version 1.10 > > > > > > > > > > > > -1 no dropping supported java versions in a minor release. if we > > > > > > want > > > > > folks to move to java 8 then we should make it easier to upgrade to > > > > > Accumulo 2.y > > > > > > > > > > > > On Thu, Oct 31, 2019 at 7:37 PM Ed Coleman <edcole...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > As suggested in the LTS discussion ([LAZY][VOTE] A basic, but > > > > > > > concrete, LTS proposal), I'm breaking this out to as a separate > > > > > > > thread > > > > > > > to keep the topic distinct. > > > > > > > > > > > > > > > > > > > > > The proposal - I would like to start the formal release process > > > > > > > for a > > > > > > > 1.10 version that would change the java language level to java 8. > > > > > > > The > > > > > > > release would be based on the current 1.9 branch and would be > > > > > > > released > > > > > > > instead of a 1.9.4. The 1.10 release would not contain additional > > > > > > > feature changes that are not present in the current 1.9 branch. > > > > > > > Currently, this would be based on the commit SHA: > > > > > > > > > > > > > > > > > > > > > 328ffa0849981e0f113dfbf539c832b447e06902 - committed Thu Oct 10. > > > > > > > > > > > > > > > > > > > > > (I am unaware of any bug-fixes or issues in the pipe line that > > > > > > > would / > > > > > > > should be included - but hopefully this makes the intention > > > > > > > clear.) > > > > > > > > > > > > > > > > > > > > > The goal is to provide a candidate for LTS nomination that is > > > > > > > based on > > > > > > > the current 1.9.x code, but unifies our currently supported > > > > > > > branches > > > > > > > to all use java 8 as the supported language level. While this had > > > > > > > been > > > > > > > discussed in the past, enough time has passed that a java 8 > > > > > > > requirement now, seems to me, to be unlikely to impact any > > > > > > > customers > > > > > > > that would look to upgrade Accumulo past a 1.9.3 version and have > > > > > > > them > > > > > not running at least java 8. > > > > > > > Having our code base with a modern, unified java language support > > > > > > > level would greatly benefit our development and reduce the burden > > > > > > > to > > > > > > > support our multiple branches. > > > > > > > > > > > > > > > > > > > > > This vote will be held open for at least the standard 72 hours. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > busbey > > > > > > > > > > > > > > > > > > > > > -- > > > > > busbey > > > > > > > > > -- > busbey -- busbey
