Re: [LSF/MM TOPIC] : blktests: status, an expansion plan for the storage stack test framework

On 2/13/19 10:11 AM, Bart Van Assche wrote:

On Wed, 2019-02-06 at 05:21 +0000, Chaitanya Kulkarni wrote:

quoted

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.

Thanks Bart for the suggestions, it will be great to have these topics 
for the overall discussion, it can help us to have a concrete plan 
moving forward.