Thank you all. Since I dug through the thread, I count 3 binding +1, 4 binding -1, and 2 non-binding +1 votes :)
brandon +1 pmc jake +1 pmc changed: -1 josh +1 alexsey +1 pmc changed: -1 pavel +1 pmc robert +1 dave +1 pmc sylvain -1 pmc jonathan -1 pmc -- Kind regards, Michael On 07/28/2016 01:47 PM, Aleksey Yeschenko wrote: > 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 >> >