cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh McKenzie <jmcken...@apache.org>
Subject Re: Per blockng release on dtest
Date Tue, 10 Jan 2017 16:56:08 GMT
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 w/out fixVersion is pretty daunting:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20labels%20in%20(test%2C%20test-failure%2C%20dtest%2C%20unittest)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixversion%20%3D%20null%20and%20labels%20!%3D%20windows%20ORDER%20BY%20created%20asc

On Tue, Jan 10, 2017 at 11:49 AM, Nate McCall <zznate.m@gmail.com> 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/c612cd8d7dbd24888c216ad53f9746
> 86b88dd601
>
> 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message