On Wed, Apr 13, 2016 at 10:09 AM, Lars Schneider <larsxschneider@xxxxxxxxx> wrote: > >> 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". and by You you mean Junio. Ideally the 0bot would have sent the message as a reply to the cover letter with the information "doesn't compile/breaks test t1234", so Junio could ignore that series (no time wasted on his part). At Git Merge Greg said (paraphrasing here): We waste developers time, because we have plenty of it. Maintainers time however is precious because maintainers are the bottleneck and a scare resource to come by. And I think Git and the kernel have the same community design here. (Except the kernel is bigger and has more than one maintainer) So the idea is help Junio make a decision to drop/ignore those patches with least amount of brain cycled spent as possible. (Not even spend 5 seconds on it). > > 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. but Junio also runs test after each(?) merge(?) of a series and once tests fail, it takes time to sort out, what caused it. (Is that the patch series alone or is that because 2 series interact badly with each other?) > > 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. IIRC Junio did not like granting travis access to the "blessed" repository as travis wants so much permissions including write permission to that repo. (We/He could have a second non advertised repo though) Also this would incur wait time on Junios side 1) collect patches (many series over the day) 2) push 3) wait 4) do the merges however a 0 bot would do 1) collect patches faster than Junio (0 bot is a computer after all, working 24/7) 2) test each patch/series individually 3) send feedback without the wait time, so the contributor from a different time zone gets feedback quickly. (round trip is just the build and test time, which the developer forgot to do any way if it fails) > > 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