Lars Schneider <larsxschneider@xxxxxxxxx> writes: > @Junio: > If you setup Travis CI for your https://github.com/gitster/git fork > then Travis CI would build all your topic branches and you (and > everyone who is interested) could check > https://travis-ci.org/gitster/git/branches to see which branches > will break pu if you integrate them. I would not say such an arrangement is worthless, but it targets a wrong point in the patch flow. The patches that result in the most wastage of my time (i.e. a shared bottleneck resource the community should strive to optimize for) are the ones that fail to hit 'pu'. Ones that do not even build in isolation, ones that may build but fail even the new tests they bring in, ones that break existing tests, and ones that are OK in isolation but do not play well with topics already in flight. Automated testing of what is already on 'pu' does not help reduce the above cost, as the culling must be done by me _without_ help from automated test you propose to run on topics in 'pu'. Ever heard of chicken and egg? Your "You can setup your own CI" update to SubmittingPatches may encourage people to test before sending. The "Travis CI sends failure notice as a response to a crappy patch" discussed by Matthieu in the other subthread will be of great help. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html