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