> I'm going to apply this series quickly and will start running 'make > check-quick' as part a sniff test before pushing patches. > > I'd like to request that all maintainers/submaintainers do the same and > that everyone contributes unit tests to this target. > > The general rules for 'make check-quick': > > 1) It must complete in less than 10 minutes start to finish (the entire > rule). We can re-examine this over time but for now, it seems like a > reasonable limit.
No objection in principle, though I'm a bit unclear on the guidelines. In particular: - 10 minutes on what hardware? 10 minutes on one of my fat build machines is an hour on an average year-old laptop/desktop, and I guess 6+ hours on the netbook I use when travelling. Maybe relating this to the time taken to do a clean build would make more sense? - What level of testing is appropriate? As a maintainer when can/should I bounce a patch due to lack of tests? e.g should new device emulation come with unit tests? New infrastructure? What about fixes to both of the above, should these include regression tests? Given the size of the test surface for many components (in particular emulated CPUs), I'm guessing we're looking at extremely basic smoke-tests. Consistent regression tests or any sort of architecture conformance tests are going to completely blow your time budget. Obviously level of testing is always a bit of a judgement call - anyone who claims of have complete test coverage is either lying or writing trivially uninteresting code. However given qemu has historically had zero active test coverage I'd appreciate some guidance (as both maintainers and contrubutor). Paul
