Le 02/11/2015 03:41, Scott Kostyshak a écrit :
Thanks to all of those participating in the discussions about tests. I have learned a lot the last couple of weeks. Thank you also to those who have tried to run the tests. This to me is a great step forward. I know that the export tests are sloppy cheap tests, but I appreciate that some of you agree that they do have use, at least until we have unit testing. The question now is, how can we get the most use out of them and how can we maximize their signal to noise ratio?
Thank you for taking time to make a summary message. The messages about tests were too many, so I could not follow the discussions. If you could write another summary once the situation with tests is resolved it would be very useful.
Ideally, I would like for commits that break tests to be on a separate git branch. Once the bugs exposed by a commit are fixed or the tests are fixed, or the .lyx files are fixed, then the branch could be merged to master. This allows us to presere a "0 failing tests" situation on the master branch so it is extremely easy to catch regressions. So my preferred policy would be: if a commit is found to have broken a test, either the situation is resolved within a day (i.e. the bug is fixed or the test is fixed) or the commit is reverted (and perhaps pushed to a separate remote branch).
A small remark: imposing a 1-day rule seems ad hoc to me. Do we even have such rules for compilation warnings? For compilation failures? For the latter, I imagine that people want it solved ASAP, but this arises more out of social pressure, not an ad hoc rule. However I like the idea of having a "candidate" remote branch, which would open up possibilities. If that's really needed.
Guillaume
