> On 13 Apr 2016, at 18:27, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. I am not sure what you mean by "fail to hit 'pu'". Maybe we talk at cross purposes. Here is what I think you do, please correct me: 1.) You pick the topics from the mailing list and create feature branches for each one of them. E.g. one of my recent topics is "ls/config-origin". 2.) At some point you create a new pu branch based on the latest next branch. You merge all the new topics into the new pu. If you push the topics to github.com/gitster after step 1 then Travis CI could tell you if the individual topic builds clean and passes all tests. Then you could merge only clean topics in step 2 which would result in a pu that is much more likely to build clean. Could that process avoid wasting your time with bad patches? > 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