On 28 September 2015 at 19:47, Junio C Hamano <gitster@xxxxxxxxx> wrote: > I won't enable it on github.com:gitster/git anyway, so I do not > think that is a concern. I thought what people are talking about > was to add it on github.com:git/git, but have I been misreading the > thread? I do not even own the latter repository (I only can push > into it). I was momentarily surprised to hear that Junio doesn't own github.com/git/git but I had a quick look at the github.com/git organisation, and it turns out that Peff and Scott Chacon are the current owners - so at the moment I think they're the only ones who could switch on the GitHub webhook to hit Travis. For what it's worth, I'd love to see Travis CI - or any form of CI - running for the core Git project. It doesn't require giving write access to Travis, and beyond the good reasons given by Lars, I'm also personally interested because it opens up the possibility of some useful enhancements to the submitGit flow - so that you can't send email to the list without knowing you've broken tests first. Regarding Luke's concerns about excess emails coming from CI, default Travis behaviour is for emails to be sent to the committer and author, but only if they have write access to the repository the commit was pushed to: http://docs.travis-ci.com/user/notifications/#How-is-the-build-email-receiver-determined%3F If Travis emails do become problematic, you can disable them completely by adding 2 lines of config to the .travis.yml: http://docs.travis-ci.com/user/notifications/#Email-notifications Given this, enabling Travis CI for git/git seems pretty low risk, are there any strong objections to it happening? -- 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