-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
