> On 13 Apr 2016, at 18:27, Junio C Hamano <[email protected]> wrote:
>
> Lars Schneider <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
