Re: Per blockng release on dtest

Regarding CASSANDRA-12620, it has been committed in the 3.0 branch at c612cd8d7dbd24888c216ad53f974686b88dd601 and merged into 3.11. As, if I am not mistaken, 3.11 should become the new 3.10 release, I do not think that there is a problem. Did I miss something Ariel? On Tue, Jan 10, 2017 at 6:45

Re: Per blockng release on dtest

+1 On Tue, Jan 10, 2017 at 9:23 AM, Aleksey Yeschenko wrote: > That’s a good point. > > So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? > > +1 to that. > > -- > AY > > On 10 January 2017 at 17:22:09, Michael Shuler (mich...@pbandjelly.org) > wrote: > >

Re: Per blockng release on dtest

> > So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? > +1

Re: Per blockng release on dtest

+1 On Tue, Jan 10, 2017 at 11:23 AM, Aleksey Yeschenko wrote: > That’s a good point. > > So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? > > +1 to that. > > -- > AY > > On 10 January 2017 at 17:22:09, Michael Shuler (mich...@pbandjelly.org) > wrote: > >

Re: Per blockng release on dtest

> So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? +1 On Tue, Jan 10, 2017 at 12:23 PM, Aleksey Yeschenko wrote: > That’s a good point. > > So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? > > +1 to that. > > -- > AY > > On 10 January

Re: Per blockng release on dtest

That’s a good point. So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? +1 to that. --  AY On 10 January 2017 at 17:22:09, Michael Shuler (mich...@pbandjelly.org) wrote: I had the same thought. 3.10 is the tick, so a 3.11 bugfix tock follows the intended final fix release

Re: Per blockng release on dtest

I had the same thought. 3.10 is the tick, so a 3.11 bugfix tock follows the intended final fix release for closing out tick-tock. Throwing a 3.10.1 out there would add more user confusion and would be the exact same contents as a 3.11 release versioned package set anyway. -- Michael On

Re: Per blockng release on dtest

> Seems like we'd just release that as 3.10.1 (instead of 3.11) and just > tell people "you can upgrade to 4.0 w/latest version of 3.10". This > does violate the "even releases features, odd releases bugfix", so > maybe a 3.11 as final 3.X line would help keep that consistent? This feels like a

Re: Per blockng release on dtest

| If someone tries to upgrade 3.10 to whatever 4.0 ends up being I think they will hit the wrong answer bug. So I would advocate for having the fix brought into 3.10, but it was broken in 3.9 as well. Seems like we'd just release that as 3.10.1 (instead of 3.11) and just tell people "you can

Re: Per blockng release on dtest

Hi, The upgrade tests are tricky because they upgrade from an existing release to a current release. The bug is in 3.9 and won't be fixed until 3.11 because the test checks out and builds 3.9 right now. 3.10 doesn't include the commit that fixes the issue so it will fail after 3.10 is released

Re: Per blockng release on dtest

I would personally favour pushing 3.10 out without waiting for the pretty innocent #13113 resolution. With the amount of bug fixes accumulated in the 3.X branch it’s borderline irresponsible to not release them out to the users. --  AY On 10 January 2017 at 17:05:57, Michael Shuler

Re: Per blockng release on dtest

Generally, fixver has only been set during commits - I only marked 3.10 and blocker status to highlight the few that failed votes, in order to sort of cheerlead "fix me so we can release!" JIRA tickets. The full test-failure list is probably the more "realistic" view, since any of those may occur.

Re: Per blockng release on dtest

Latest cassandra-3.11_dtest run failed on one test, system_auth_ks_is_alterable_test: https://issues.apache.org/jira/browse/CASSANDRA-13113 The dtest variations (novnode, offheap, upgrade, large) have other failures, but if the green light for release is unit tests and the default dtest, we're

Re: Per blockng release on dtest

I assume you meant the query w/out 12617 embedded? https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%203.10%20AND%20resolution%20%3D%20Unresolved Do we have confidence that all test failures have fixVersion attached correctly? The list of test failures

Re: Per blockng release on dtest

> > I concede it would be fine to do it gradually. Once the pace of issues > introduced by new development is beaten by the pace at which they are > addressed I think things will go well. So from Michael's JIRA query:

Re: Per blockng release on dtest

Hi, I concede it would be fine to do it gradually. Once the pace of issues introduced by new development is beaten by the pace at which they are addressed I think things will go well. Ariel On Tue, Jan 10, 2017, at 11:17 AM, Josh McKenzie wrote: > @ariel: you're letting the perfect be the enemy

Re: Per blockng release on dtest

If they aren’t regressions from 3.9, we should still push 3.10 out. The branch has accumulated a lot of fixes, for problems that *are* real. Just have a look at CHANGES.txt. By holding 3.10 you are denying those (arguably few, but still) users fixes for bugs that we know are in. It’s been more

Re: Per blockng release on dtest

@ariel: you're letting the perfect be the enemy of the good here. We (as a project) have been releasing with a smattering of test failures and upgrade edge-cases back into perpetuity. While that doesn't make it ideal or justify continuing the behavior, getting a green testall + dtest for 3.10 is a

Re: Per blockng release on dtest

Hi, At least some of those failures are real. I don't think we should release 3.10 until the real failures are addressed. As I said earlier one of them is a wrong answer bug that is not going to be fixed in 3.10. Can we just ignore failures because we think they don't mean anything? Who is going

Re: Per blockng release on dtest

I think we should start with blocking 3.10 releases on testall + Dtest. After 3.10, we can start blocking it on other jobs for each release after that. This will make sure we make progress and dont cause 3.10 to sit for a long time. Thoughts? On Tue, Jan 10, 2017 at 5:13 AM, Josh McKenzie

Re: Per blockng release on dtest

First, I think we need to clarify if we're blocking on just testall + dtest or blocking on *all test jobs*. If the latter, upgrade tests are the elephant in the room: http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest_upgrade/lastCompletedBuild/testReport/ Do we have