On Mon, Jan 11, 2016 at 10:12:19PM +0100, Kornel Benko wrote: > Am Montag, 11. Januar 2016 um 21:08:17, schrieb Georg Baum > <georg.b...@post.rwth-aachen.de> > > Guenter Milde wrote: > > > > > In normal inter-release development times, I think it is too restricting > > > to insist on tested regression-free patches. > > > > I can only recommend to try to always work like that. I know it does not > > sound convincing (you really have to try it out), but I made the experience > > that I get stuff done quicker if I take the tests into account as soon as I > > think imy change might work (which it usually does not do, and the tests do > > usually show where it is broken). > > > > > IMO, a sane state of the test suite can also be maintained without > > > stifling work on the code if the test suite is cleaned up in a couple of > > > days whenever new test failures are noticed. > > > > True, but in total it will be even less work if coce and test changes are > > submitted in one go. > > > > > > Georg > > +1 to both statements. > > Kornel
+1 to Kornel's +1. I strongly agree with Georg as for the good unit tests that we have. But for our export tests and specifically our export tests known to be unreliable, I understand Günter's objection that it could be just a lot of wasted time. However, as for the statement "the test suite is cleaned up in a couple of days whenever new test failures are noticed", I want to caution that in a couple of days, sometimes there are many changes that are committed and it might not be clear which commit caused a change and why. Doing a bisect and figuring out the change and then asking the author of the commit that caused the change and then waiting for that author's response and then running the tests after applying whatever patch that author implies should be made can in the end take up 5x more time than if the author had just run the tests and incorporated the changes with explanations into his commit. Scott
signature.asc
Description: PGP signature
