cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From François Deliège <franc...@instagram.com>
Subject Code quality, principles and rules
Date Thu, 16 Mar 2017 17:32:23 GMT
Hi Dev,

What principles do we have? How do we implement them?

Our team has been evaluating 3.0.x and 3.x for a large production deployment.  We have noticed
broken tests and have been working on several patches.  However, large parts of the code base
are wildly untested, which makes new contributions more delicate.

All of this ultimately reduces our confidence in the new releases and slows down our adoption
of the 3.0 / 3.x and future 4.0 releases.

So, I'd like to have a constructive discussion around 2 questions:

1. What principles should the community have in place about code quality and ensuring its
long term productivity?
2. What are good implementationg (as in rules) of these principles?

To get this started, here is an initial proposal:

Principles:

1. Tests always pass.  This is the starting point. If we don't care about test failures, then
we should stop writing tests. A recurring failing test carries no signal and is better deleted.
2. The code is tested.

Assuming we can align on these principles, here is a proposal for their implementation.

Rules:

1. Each new release passes all tests (no flakinesss).
2. If a patch has a failing test (test touching the same code path), the code or test should
be fixed prior to being accepted.
3. Bugs fixes should have one test that fails prior to the fix and passes after fix.
4. New code should have at least 90% test coverage.

Looking forward to reading your feedback,

@fdeliege

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