Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Brandon Williams]

Also I believe Pavel may have switched tacitly to -1 with his "I agree with
Sylvain" email?

On Thu, Jul 28, 2016 at 3:08 PM, Brandon Williams  wrote:

> I change my vote to -1.
>
> On Thu, Jul 28, 2016 at 3:04 PM, Jonathan Ellis  wrote:
>
>> On Thu, Jul 28, 2016 at 1:19 PM, Aleksey Yeschenko 
>> wrote:
>>
>> > 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.
>> >
>>
>> I can live with either but as a -1 voter I would prefer #2.
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder, http://www.datastax.com
>> @spyced
>>
>
>

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Brandon Williams]

I change my vote to -1.

On Thu, Jul 28, 2016 at 3:04 PM, Jonathan Ellis  wrote:

> On Thu, Jul 28, 2016 at 1:19 PM, Aleksey Yeschenko 
> wrote:
>
> > 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.
> >
>
> I can live with either but as a -1 voter I would prefer #2.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Jonathan Ellis]

On Thu, Jul 28, 2016 at 1:19 PM, Aleksey Yeschenko 
wrote:

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

I can live with either but as a -1 voter I would prefer #2.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Jake Luciani]

-1

On Thu, Jul 28, 2016 at 2:19 PM, Aleksey Yeschenko 
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
> >  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 

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

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

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Michael Shuler]

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

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Jonathan Ellis]

You can count me as -1.

On Tue, Jul 26, 2016 at 5:42 PM, Aleksey Yeschenko 
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).
>
> --
> 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 
> > 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 
> 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  >
> >>> 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 

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

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   
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   
> > 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   
> 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  >  
> >>> wrote:  
> >>>  
>  I still think the issue is minor 

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Pavel Yaskevich]

I concur with Sylvain.

On Wed, Jul 27, 2016 at 1:59 AM, Sylvain Lebresne 
wrote:

> On Wed, Jul 27, 2016 at 12:42 AM, Aleksey Yeschenko 
> 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  >
> > > 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 
> > 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,

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Sylvain Lebresne]

On Wed, Jul 27, 2016 at 12:42 AM, Aleksey Yeschenko 
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 
> > 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 
> 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  >
> >>> 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 

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Brandon Williams]

For completeness, Jake and Pavel are the other two.

On Tue, Jul 26, 2016 at 5:50 PM, Aleksey Yeschenko 
wrote:

> Sorry (: Only see yours, Dave’s, and mine in my client. Apparently I’ve
> trashed the email chain at some point.
>
> --
> AY
>
> On 26 July 2016 at 23:48:49, Brandon Williams (dri...@gmail.com) wrote:
>
> Small nit: there are currently 5 binding +1 and 1 binding -1, (or 2, with
> Jonathan.)
>
> On Tue, Jul 26, 2016 at 5:42 PM, Aleksey Yeschenko 
> 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).
> >
> > --
> > 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  >
> > > 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 
> > 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 

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

Sorry (: Only see yours, Dave’s, and mine in my client. Apparently I’ve trashed 
the email chain at some point.

-- 
AY

On 26 July 2016 at 23:48:49, Brandon Williams (dri...@gmail.com) wrote:

Small nit: there are currently 5 binding +1 and 1 binding -1, (or 2, with  
Jonathan.)  

On Tue, Jul 26, 2016 at 5:42 PM, Aleksey Yeschenko   
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).  
>  
> --  
> 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   
> > 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   
> 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  >  
> >>> 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 

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Brandon Williams]

Small nit: there are currently 5 binding +1 and 1 binding -1, (or 2, with
Jonathan.)

On Tue, Jul 26, 2016 at 5:42 PM, Aleksey Yeschenko 
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).
>
> --
> 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 
> > 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 
> 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  >
> >>> 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 

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

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

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