Hi Junio, On 2015-10-04 03:37, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley <roberto.tyley@xxxxxxxxx> wrote: >>> >>> Given this, enabling Travis CI for git/git seems pretty low risk, >>> are there any strong objections to it happening? >> >> I still don't see a reason why git/git needs to be the one that is >> used, when somebody >> so interested (and I seem to see very many of them in the thread) can >> sacrifice his or >> her own fork and enable it him or herself. > > To state it a bit differently. > > If somebody says "I've been maintaining a clone of git/git with > Travis webhooks enabled and as the result caught this many glitches > during the past two months without any ill side effect. Heh... given that Travis CI requires that .travis.yml file, nobody can really say that they have been using Travis CI *before* you add that file to `master`. If you make successful testing with Travis a *precondition* before adding that file, it is kinda asking for the impossible. Now, I like Travis, even if I have used Jenkins previously (came as part of my previous day-job). And my experience with Jenkins (in the form of BuildHive) was pretty positive: it *did* catch a couple of breakages. Even with my Git fork. But I agree with basically everybody who chimed in and said that the biggest bang for the buck would be made by enabling it on https://github.com/git/git. The only cost I see is for that `.travis.yml` file to live in Git's source code. Small price to pay, if you ask me. If you do not want to use it yourself, that is fine. But I would like to ask for it to be included so that those of us who do want to benefit from Travis' testing are not precluded from doing so [*1*]. As far as I can tell, the patch is fine as-is. Although I would put the `before_script` commands into some file inside `contrib/`. Thanks, Dscho Footnote *1*: of course it would be possible to manually rebase the patch, or to set up a scripted version of that. That is very cumbersome, though, and the benefit would obviously be substantially diminished. -- 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