{"thread":{"id":"38579","subject":"'make test' fails in pu","startedAt":"2015-02-17T08:39:17Z","lastAt":"2015-02-17T19:44:35Z","messageCount":4,"participants":["Dennis Kaarsemaker","Jeff King","Michael Blume","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256187","messageId":"1424162357.30155.14.camel@kaarsemaker.net","threadId":"38579","inReplyTo":null,"subject":"'make test' fails in pu","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2015-02-17T08:39:17Z","receivedAt":"2015-02-17T08:39:17Z","isPatch":false,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"Make test has been failing for 'pu' yesterday for and today at\nt4016-diff-quote.sh. Full log:\nhttp://ci.kaarsemaker.net/git/refs/heads/pu/1df29c71a731c679de9055ae5e407f3a4e18740a/artefact/test/log\n\nI noticed this a few times before and it tends to get fixed again\nrelatively quickly. So I'm wondering:\n\n- Should I even mention that it's failing, or is that just useless\n  noise?\n- If I should report this, I could also make my testing thing send \n  mails. Would that be useful?\n\n-- \nDennis Kaarsemaker\nhttp://www.kaarsemaker.net\n"},{"id":"256189","messageId":"20150217085509.GC17174@peff.net","threadId":"38579","inReplyTo":"1424162357.30155.14.camel@kaarsemaker.net","subject":"Re: 'make test' fails in pu","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-17T08:55:10Z","receivedAt":"2015-02-17T08:55:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote:\n\n> Make test has been failing for 'pu' yesterday for and today at\n> t4016-diff-quote.sh. Full log:\n> http://ci.kaarsemaker.net/git/refs/heads/pu/1df29c71a731c679de9055ae5e407f3a4e18740a/artefact/test/log\n> \n> I noticed this a few times before and it tends to get fixed again\n> relatively quickly. So I'm wondering:\n> \n> - Should I even mention that it's failing, or is that just useless\n>   noise?\n> - If I should report this, I could also make my testing thing send \n>   mails. Would that be useful?\n\nIf you bisect this, it turns up commit 30cd8f94f, which says:\n\n    WIP: diff-b-m\n\n    [...]\n\n    This update is still broken and breaks a handful of tests:\n    \n         4016 4023 4047 4130 6022 6031 6032 9300 9200 9300 9350\n\nSometimes a breakage in pu is surprising (e.g., it breaks only on a\nplatform that the maintainer does not run \"make test\" on) and we would\nwant to know about it. But sometimes it is merely that there is a\nwork-in-progress. And it probably requires a human to tell the\ndifference.\n\nSo no, I do not think automatically mailing on test failures in pu is a\ngood idea. Manually peeking at them and sending fixes before the series\nis merged to next _is_ very much encouraged, though. :)\n\nUnlike \"pu\", \"next\" and \"master\" should never fail tests (I think that\nJunio will not push them out if the tests have failed on his system). So\nfailures there are much more likely to be interesting platform bugs (but\nof course, testing \"pu\" is still encouraged, as we may catch problems).\n\nBut even for \"next\", I would say blind automated emails are not nearly\nas useful as a human who has looked at the problem (and especially\nbisected).\n\n-Peff\n"},{"id":"256227","messageId":"CAO2U3Qju6+vua8hXHi49hOOnzXb-MDJ6yjmPPx-V=zp8hMGJ=A@mail.gmail.com","threadId":"38579","inReplyTo":"20150217085509.GC17174@peff.net","subject":"Re: 'make test' fails in pu","fromName":"Michael Blume","fromEmail":"blume.mike@gmail.com","sentAt":"2015-02-17T19:07:09Z","receivedAt":"2015-02-17T19:07:09Z","isPatch":false,"sender":{"key":"blume.mike@gmail.com","avatar":"https://gravatar.com/avatar/1a7b440e1d942425ff4098ac7fc15b86b30cecaa56e1692a7ef8b5939ba25ea7?d=mp&s=160"},"body":"For the record, that commit also sporadically breaks test 3910 on my\nsystem (mentioning since it's not on the list)\n\nOn Tue, Feb 17, 2015 at 12:55 AM, Jeff King <peff@peff.net> wrote:\n> On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote:\n>\n>> Make test has been failing for 'pu' yesterday for and today at\n>> t4016-diff-quote.sh. Full log:\n>> http://ci.kaarsemaker.net/git/refs/heads/pu/1df29c71a731c679de9055ae5e407f3a4e18740a/artefact/test/log\n>>\n>> I noticed this a few times before and it tends to get fixed again\n>> relatively quickly. So I'm wondering:\n>>\n>> - Should I even mention that it's failing, or is that just useless\n>>   noise?\n>> - If I should report this, I could also make my testing thing send\n>>   mails. Would that be useful?\n>\n> If you bisect this, it turns up commit 30cd8f94f, which says:\n>\n>     WIP: diff-b-m\n>\n>     [...]\n>\n>     This update is still broken and breaks a handful of tests:\n>\n>          4016 4023 4047 4130 6022 6031 6032 9300 9200 9300 9350\n>\n> Sometimes a breakage in pu is surprising (e.g., it breaks only on a\n> platform that the maintainer does not run \"make test\" on) and we would\n> want to know about it. But sometimes it is merely that there is a\n> work-in-progress. And it probably requires a human to tell the\n> difference.\n>\n> So no, I do not think automatically mailing on test failures in pu is a\n> good idea. Manually peeking at them and sending fixes before the series\n> is merged to next _is_ very much encouraged, though. :)\n>\n> Unlike \"pu\", \"next\" and \"master\" should never fail tests (I think that\n> Junio will not push them out if the tests have failed on his system). So\n> failures there are much more likely to be interesting platform bugs (but\n> of course, testing \"pu\" is still encouraged, as we may catch problems).\n>\n> But even for \"next\", I would say blind automated emails are not nearly\n> as useful as a human who has looked at the problem (and especially\n> bisected).\n>\n> -Peff\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"256229","messageId":"xmqq7fvg2uho.fsf@gitster.dls.corp.google.com","threadId":"38579","inReplyTo":"20150217085509.GC17174@peff.net","subject":"Re: 'make test' fails in pu","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-17T19:44:35Z","receivedAt":"2015-02-17T19:44:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Sometimes a breakage in pu is surprising (e.g., it breaks only on a\n> platform that the maintainer does not run \"make test\" on) and we would\n> want to know about it. But sometimes it is merely that there is a\n> work-in-progress. And it probably requires a human to tell the\n> difference.\n>\n> So no, I do not think automatically mailing on test failures in pu is a\n> good idea. Manually peeking at them and sending fixes before the series\n> is merged to next _is_ very much encouraged, though. :)\n\nThanks, that is exactly what people saw.  From time to time, I queue\na topic that does not pass the tests on 'pu', hoping that somebody\nsufficiently interested would step in to collaborate with the author\nof the topic to move things forward when the breakage looks simple\nenough, and sometimes that original author happens to be me.\n\nThis case, it turns out that the breakage is not so simple, though.\nInside the rename detection logic, I want to peek the rename source\narray to decide which deletion filepair to keep, but rename source\narray itself has pointers to the original filepairs the loop wants\nto free, so the WIP code was peeking into a freed piece memory X-<.\n\n> Unlike \"pu\", \"next\" and \"master\" should never fail tests (I think that\n> Junio will not push them out if the tests have failed on his system). So\n> failures there are much more likely to be interesting platform bugs (but\n> of course, testing \"pu\" is still encouraged, as we may catch problems).\n\nTrue.  I do not mind automated tests on 'next', and testing 'pu' and\nhelping the topic to move forward is very much encouraged, but\nsending test results on 'pu' blindly is often more noise than it is\nworth.\n"}]}