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  
>>  
> 

Reply via email to