Agreed, option #2 is my preference as well. On Thu, Jul 28, 2016 at 2:04 PM, Dave Brosius <dbros...@mebigfatguy.com> wrote:
> Option Two seems reasonable to me > > > --- > <br type="_moz" /> > > > On 2016-07-28 14:47, 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 >>> >>> -- Tyler Hobbs DataStax <http://datastax.com/>
