On Wed, 2019-02-06 at 05:21 +0000, Chaitanya Kulkarni wrote: > For storage track, we would like to propose a session dedicated to blktests. > It is a great > opportunity for the storage developers to gather and have a discussion about:- > > 1. Current status of the blktests framework. > 2. Any new/missing features that we want to add in the blktests. > 3. Any new kernel features that could be used to make testing easier? > E.g. Implementing new features in the null_blk.c in order to have device > independent complete test coverage. (e.g. adding discard command for null_blk > or any > other specific REQ_OP). Discussion about having any new tracepoint events in > the block layer. > 4. Any new test cases/categories which are lacking in the blktests framework.
Hi Chaitanya, Thanks for having proposed this topic. I'd like to add a fifth item to the agenda, namely blktests maintainership. The following could e.g. be discussed: - How many maintainers should the blktests project have? A single maintainer or also one or more co-maintainers? - Is it acceptable that patches get accepted in the blktests repository that break the continuous integration tests? If so, why do we even have continuous integration tests? See also "[PATCH] Unbreak the continuous integration build" (https://marc.info/?l=linux-block&m=154990323618159). - How long should it take before a blktests maintainer provides feedback on blktests patches and pull requests? Is it considered acceptable that it takes more than four weeks to process a pull request that is in perfect shape? See e.g. https://github.com/osandov/blktests/pull/44. Bart.
