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 close. http://cassci.datastax.com/view/cassandra-3.11/ -- Michael On 01/10/2017 10:49 AM, Nate McCall wrote: >> >> 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: > https://issues.apache.org/jira/browse/CASSANDRA-12617?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%203.10%20AND%20resolution%20%3D%20Unresolved > > Are we good for 3.10 after we get those cleaned up? > > Ariel, you made reference to: > https://github.com/apache/cassandra/commit/c612cd8d7dbd24888c216ad53f974686b88dd601 > > Do we need to re-open an issue to have this applied to 3.10 and add it > to the above list? > >> >> On Tue, Jan 10, 2017, at 11:17 AM, Josh McKenzie wrote: >>> >>> Sankalp's proposal of us progressively tightening up our standards allows >>> us to get code out the door and regain some lost momentum on the 3.10 >>> release failures and blocking, and gives us time as a community to adjust >>> our behavior without the burden of an ever-later slipped release hanging >>> over our heads. There's plenty of bugfixes in the 3.X line; the more time >>> people can have to kick the tires on that code, the more things we can >>> find >>> and the better future releases will be. > > > +1 On gradually moving to this. Dropping releases with huge change > lists has never gone well for us in the past. >
