June 2015 retrospective

[Ariel Weisberg <ar...@datastax.com>]

Hi all,

June 2015 retrospective doc
<https://docs.google.com/document/d/1HOW8tSPkizm2uUidwKxF1n7Lg2hmE6H2Goob1fOI9Xw/edit#>

It's time for the June retrospective. It looks like there were 3 releases
in June (2.0.16, 2.1.6, 2.1.7).

There are 90 issues listed across those three releases. Hopefully
everything is annotated correctly. I want to take another shot at further
removing myself as a bottleneck for the retrospective process.

The goal at the end of each retrospective is to have transformed every
issue we had into the solution (or next action) for that issue. I think
that boils down to

   - Performance regression, add to performance harness doc
   <https://docs.google.com/document/d/1TMdJ7-y-hKQwhPRFYL0VXf0R53MsF4QmhZmwbT8wpE0/edit>
   - Correctness regression, add a JIRA or to Cassandra validation harness
   <https://docs.google.com/document/d/1kccPqxEAoYQpT0gXnp20MYQUDmjOrakAeQhf6vkqjGo/edit#heading=h.zd5nw0kl2ypi>
   doc
   - Note in retrospective what went wrong and what needed to be do
   differently at implementation/code review time

For example CASSANDRA-9592
<https://issues.apache.org/jira/browse/CASSANDRA-9592> shows a scenario
that could easily be detected by the performance harness or the C*
validation harness and one or the other should be made to produce a
scenario where this can happen and be able to detect that it does happen.
So you would pick one of the two docs and put it in there. If there is a
dtest that could also test for this you would create a JIRA instead and
link it to CASSANDRA-9012
<https://issues.apache.org/jira/browse/CASSANDRA-9012>.

By linking these issues to the solutions were are also making it easier to
see how much not having a given piece of test functionality is costing
which will increase bang for the buck post 3.0 when we go to decide what to
work on.

Thanks,
Ariel