Everybody, Ceph is popular! The global community of developers is growing quickly, and that’s leading to some challenges for our leads and core development team as we try to absorb incoming pull requests. Over the past few weeks our leads have discussed (internally and with a few external contributors) how to improve things, and we wanted to share some conclusions.
It has been a long-standing requirement that all code be tested by teuthology before being merged to master. In the past leads have shouldered a lot of this burden through integration and testing branches, but it’s become unsustainable in present form: some PRs which are intended as RFCs are being mistakenly identified as final; some PRs are submitted which pass cursory sniff tests but fail under recovery conditions that the teuthology suites cover. To prevent that, please comment on exactly what testing you’ve performed when submitting a PR and a justification why that is sufficient to promote it to integration testing. Be prepared for us to request more specific testing before doing a careful review if we think it’s warranted: in general, a run through the applicable regression suite (with new tests added in a branch if applicable) will be required. Individual teams and leads will develop specific regression testing requirements in the near future. For our most frequent and prolific contributors, we are going to start expecting that you perform the above testing on your own before we move on to a serious review or our own integration tests — this should be much easier thanks to Loic’s work on teuthology-openstack! It has also been policy that new features and bug fixes are accompanied by tests which 1) demonstrate functionality and 2) check failure cases. In this arena some of us have been lax, but nightly stability has suffered. Some of us have also written tests for external contributions, but this simply doesn’t scale and we are cutting back. If you believe that a patch you’ve submitted is already covered by tests, please point them out. If it’s not covered by existing testing, write new ones! Specifically, the new feature (or bug) should be covered by the area’s regression suite. In most cases, this will involve an addition to the ceph-qa-suite. You should link the branch with the change in the main ceph PR. Your PR’s testing should be performed with that ceph-qa-suite branch (since the existing ceph-qa-suite coverage is presumably insufficient). If you need guidance on how best to automate testing, ask! If you submit a PR without these, it will just get bounced back to you and slow everybody down. We believe that these adjustments to our merge habits and the workload distribution will increase code quality, increase throughput, allow faster merges, and prevent the frequent “lost” PRs requiring rebases that have been appearing over the last year. That will make Ceph better for all of us. Thanks! -Greg -Sam -Yehuda -Sage -Josh -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
