Jake was just swapping his vote +1 to -1. Swapping mine to -1 too, so that we have a binding -1 majority now.
Let’s get #12236 in and then decide what to do. -- AY On 28 July 2016 at 19:46:56, Benedict Elliott Smith (bened...@apache.org) wrote: I think -1 lacks a little clarity when responding to a block of prose with multiple clauses, suggestions and no single proposition requiring a yes/no answer. As fun as it is to type -1. On Thursday, 28 July 2016, Jake Luciani <jak...@gmail.com <javascript:_e(%7B%7D,'cvml','jak...@gmail.com');>> wrote: > -1 > > On Thu, Jul 28, 2016 at 2:19 PM, Aleksey Yeschenko <alek...@apache.org> > wrote: > > > Let me sum up my thoughts so far. > > > > Some of the most important goals of tick-tock were 1) predictable, > regular > > releases with manageable changesets and > > 2)individual releases that are more stable than in our previous process. > > > > Now, we’ve already slipped a few times. Most recently with 3.6, and now > > with 3.8. If we push 3.9 as well, then the delay > > will cascade: 3.10, 3.11, and 3.12 will all be late according to the > > original plan. > > > > In other words, if we delay 3.9, then 6 out of 12 tick-tock releases will > > be off-schedule. > > > > Worse, so will be 3.0.9, 3.0.10, 3.0.11, and 3.0.12. > > > > Now, #12236 is indeed an issue, but it really is a minor annoyance, and > > goes away quickly after upgrading. And let’s not > > kid ourselves that just by fixing #12236 alone 3.8 will somehow become a > > stable release. No amount of passive aggressive > > remarks is going to change that, either. So the choices as I see them > > were: a) release 3.8 with a known minor annoyance now, > > so that we can at least save 3.9 to 3.12 schedule or b) delay 3.9-3.12 > and > > 3.0.9-3.0.12 by a month, each, without that minor annoyance, > > but ultimately have just as stable/unstable 3.8. The pragmatic choice in > > my opinion is clearly (a): we at least maintain some regularity that way. > > > > That said, after having though about it more, I realised that it’s the > odd > > 3.9, not the even 3.8 that’s already late, that I really care about. > > So here are the two options I suggest - and I’m fine with either: > > > > 1. Release 3.8 as is now. It’s an even preview release that can live fine > > with one minor annoyance on upgrade. Have 3.9 released on schedule. > > Since the vote technically passed, we can just do it, now. > > > > 2. Wait until #12236 is in, and release 3.8 then, doesn’t matter when. > > Have 3.9+ released on schedule. Even though the delta between 3.8 and 3.9 > > would > > be tiny, it’s still IMO less confusing than skipping a whole version, and > > a lot more preferable than failing the schedule for 4 upcoming 3.x and > > 3.0.x releases. > > > > 3.9, after all, *does* have a month of bugfix only stabilisation changes > > in it. So does 3.0.9. The sooner we can get those into people’s hands, > the > > better. > > 3.8 is ultimately unimportant. Even if we release 3.8 and 3.9 on the same > > date, it’s not a huge deal. > > > > > > P.S. I feel like 1 week freeze is insufficient given a monthly cadence. > If > > we are to keep the monthly cycle, we should probably extend the freeze to > > two weeks, > > so that we have time to fix problems uncovered by regular and, more > > importantly, upgrade tests. > > > > -- > > AY > > > > On 27 July 2016 at 22:04:31, Michael Shuler (mshu...@apache.org) wrote: > > > > I apologize for messing this vote up. > > > > So, what should happen now? Drop RESULT from the subject and continue > > discussion of alternatives and voting? > > > > -- > > Kind regards, > > Michael > > > > On 07/27/2016 06:33 AM, Aleksey Yeschenko wrote: > > > The difference is that those -1s were based on new information > > > discovered after the vote was started, while this one wasn’t. > > > > > > In addition to that, the discussion was still ongoing, and a decision > > > on the alternative has not been made. As such closing the vote was > > > definitely premature. > > > > > > FWIW I intended to swap my +1 with a -1, but was not given a chance > > > to do so. As for what alternative I prefer, I’m not sure yet. > > > > > > -- AY > > > > > > On 27 July 2016 at 09:59:50, Sylvain Lebresne (sylv...@datastax.com) > > > wrote: > > > > > > On Wed, Jul 27, 2016 at 12:42 AM, Aleksey Yeschenko > > > <alek...@apache.org> wrote: > > > > > >> Sorry, but I’m counting 3 binding +1s and 1 binding -1 (2, if you > > >> interpret Jonathan’s emails as such). > > >> > > >> Thus, if you were to do close the vote now, the vote is passing > > >> with the binding majority, and the required minimum # of +1s > > >> gained. > > >> > > >> I also don’t see the PMC consensus on ‘August 3.8 release target’. > > >> > > >> > > >> As such, the vote is now reopened for further discussion, and to > > >> allow PMC to change their votes if they feel like it (I, for one, > > >> have just returned, and need to reevaluate 12236 in light of new > > >> comments). > > >> > > > > > > It has been my understanding that we took a more human approach to > > > release decisions than strictly and blindly adhering to the Apache > > > written voting rules. There has been many votes that has been > > > re-rolled even though they had had more than 3 binding vote already > > > when a problem was detected, and it never took an official PMC vote > > > to do so, nor did we ever officially waited on the cast votes to be > > > officially reverted. > > > > > > I'm also sad that knowing that there is a bug that breaks in-flight > > > queries during upgrade *and* the fact the vast majority of our > > > upgrade tests are failing is not _obviously_ enough to hold a > > > release, without the need for further considerations. This speaks imo > > > poorly of the PMC attachment to release quality. > > > > > > But you are correct on the technicality of vote counting and their > > > official consequences according to the written rules ... > > > > > > > > >> > > >> -- AY > > >> > > >> On 25 July 2016 at 15:46:40, Michael Shuler (mshu...@apache.org) > > >> wrote: > > >> > > >> Thanks for the clarity, Jonathan. I agree that an August 3.8 > > >> release target sounds like the most reasonable option, at this > > >> point in time. > > >> > > >> With Sylvain's binding -1, this vote has failed. > > >> > > >> -- Kind regards, Michael Shuler > > >> > > >> On 07/21/2016 05:33 PM, Jonathan Ellis wrote: > > >>> I feel like the calendar is relevant though because if we delay > > >>> 3.8 more we're looking at a week, maybe 10 days before 3.9 is > > >>> scheduled. Which doesn't give us much time for the stabilizing > > >>> we're supposed to do in > > >> 3.9. > > >>> > > >>> All in all I think I agree that releasing 3.8 in August is less > > >>> confusing than skipping it entirely. And I don't like the idea of > > >>> ignoring a whole bunch of test failures and hoping they don't > > >>> mean anything, because we > > >> just > > >>> had that thread about getting more rigorous about tests, not > > >>> less. > > >>> > > >>> So I would recommend we go ahead and fix this before releasing, > > >>> and to avoid a super compressed 3.9 window either retarget 3.8 > > >>> for August, or > > >> 3.9 > > >>> for September. > > >>> > > >>> On Thu, Jul 21, 2016 at 9:58 AM, Aleksey Yeschenko > > >>> <alek...@apache.org> wrote: > > >>> > > >>>> What we’d usually do is revert the offending ticket and push it > > >>>> to the next release, if this indeed were significant enough. > > >>>> > > >>>> So option 4 would be to revert CDC fast (painful) and ship. > > >>>> Option 5 would be to quickly fix the issue, retag, and revote, > > >>>> with 3.9 still following up on schedule. Option 6 would be to > > >>>> ignore the calendar entirely. Fix or revert the > > >> issue > > >>>> eventually, and release 3.8 then. Have 3.9 and 3.0.9 out at > > >>>> whatever > > >> time > > >>>> we decide to, and go back to monthly cycles from there on. > > >>>> > > >>>> TBH I don’t think anybody is even going to notice, or care. So > > >>>> I’m fine with 1, 4, 5, 6, but not reverting my +1 so far. > > >>>> > > >>>> -- AY > > >>>> > > >>>> On 21 July 2016 at 14:46:17, Sylvain Lebresne > > >>>> (sylv...@datastax.com) wrote: > > >>>> > > >>>> On Thu, Jul 21, 2016 at 3:21 PM, Jonathan Ellis > > >>>> <jbel...@gmail.com> > > >> wrote: > > >>>> > > >>>>> I see the alternatives as: > > >>>>> > > >>>>> 1. Release this as 3.8 2. Skip 3.8 and release 3.9 next month > > >>>>> on schedule 3. Skip this month and release 3.8 next month > > >>>>> instead > > >>>>> > > >>>> > > >>>> I've hopefully made it clear I don't really like 1. I'm totally > > >>>> fine > > >> with > > >>>> either 2 or 3 though (with a very very small preference for 3. > > >>>> because I suspect skipping a release might confuse a few users, > > >>>> but also knowing > > >> that > > >>>> 2. has the small advantage of keeping the 3.0.x and 3.x > > >>>> versions > > >> released > > >>>> more or less in lockstep). > > >>>> > > >>>> > > >>>> > > >>>>> > > >>>>> On Thu, Jul 21, 2016 at 8:19 AM, Aleksey Yeschenko > > >>>>> <alek...@apache.org > > >>> > > >>>>> wrote: > > >>>>> > > >>>>>> I still think the issue is minor enough, and with 3.8 being > > >>>>>> extremely delayed, and being a non-odd release, at that, > > >>>>>> we’d be better off just pushing it. > > >>>>>> > > >>>>>> Also, I know we’ve been easy on -1s when voting on > > >>>>>> releases, but I > > >> want > > >>>>> to > > >>>>>> remind people in general that release votes can not be > > >>>>>> vetoed and only require a majority of binding votes, > > >>>>>> http://www.apache.org/foundation/voting.html#ReleaseVotes > > >>>>>> > > >>>>>> > > >>>>>> -- AY > > >>>>>> > > >>>>>> On 21 July 2016 at 08:57:22, Sylvain Lebresne > > >>>>>> (sylv...@datastax.com) wrote: > > >>>>>> > > >>>>>> Sorry but I'm (binding) -1 on this because of > > >>>>>> https://issues.apache.org/jira/browse/CASSANDRA-12236. > > >>>>>> > > >>>>>> I disagree that knowingly releasing a version that will > > >>>>>> temporarily > > >>>> break > > >>>>>> in-flight queries during upgrade, even if it's for a very > > >>>>>> short > > >>>>> time-frame > > >>>>>> until re-connection, is ok. I'll note in particular that in > > >>>>>> the test report, there is 74! failures in the upgrade tests > > >>>>>> (for reference the > > >>>> 3.7 > > >>>>>> test report had only 2 upgrade tests failure both with open > > >>>>>> tickets). > > >>>>> Given > > >>>>>> that we have a known problem during upgrade, I don't really > > >>>>>> buy the > > >> "We > > >>>>> are > > >>>>>> assuming these are due to a recent downsize in instance > > >>>>>> size that > > >> these > > >>>>>> tests run on" and that suggest to me the problem is not too > > >>>>>> minor. > > >>>>>> > > >>>>>> > > >>>>>> On Thu, Jul 21, 2016 at 6:18 AM, Dave Brosius < > > >>>> dbros...@mebigfatguy.com> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> +1 > > >>>>>>> > > >>>>>>> > > >>>>>>> On 07/20/2016 05:48 PM, Michael Shuler wrote: > > >>>>>>> > > >>>>>>>> I propose the following artifacts for release as 3.8. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> sha1: c3ded0551f538f7845602b27d53240cd8129265c Git: > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative > > > >> > > >>>>>>>> Artifacts: > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > > https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/ > > > >> > > >>>>>>>> Staging repository: > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > > https://repository.apache.org/content/repositories/orgapachecassandra-1123/ > > >> > > >>>>>>>> > > >>>>>>>> The debian packages are available here: > > >>>>>>>> http://people.apache.org/~mshuler/ > > >>>>>>>> > > >>>>>>>> The vote will be open for 72 hours (longer if needed). > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> [1]: http://goo.gl/oGNH0i (CHANGES.txt) [2]: > > >>>>>>>> http://goo.gl/KjMtUn (NEWS.txt) [3]: > > >>>>>>>> https://goo.gl/TxVLKo (3.8 Test Summary) > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, > > >>>>> http://www.datastax.com @spyced > > >>>>> > > >>>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > -- > http://twitter.com/tjake >
