On 12 Apr 2016, at 22:49, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > >> But my point wasn't to say "we already have everything we need", but >> rather "we already have part of the solution, so an ideal complete >> solution could integrate with it". > > Yes. That is a good direction to go. > > They may already have part of the solution, and their half may be > better than what we have, in which case we may want to switch, but > if what we have already works well there is no need to. > >> I don't know how 0 bot solves this, but the obvious issue with this >> approach is to allow dealing with someone sending a patch like >> >> +++ Makefile >> --- Makefile >> +all: >> + rm -fr $(HOME); sudo rm -fr / >> >> to the list. One thing that Travis gives us for free is isolation: >> malicious code in the build cannot break the bot, only the build >> itself. > > True, presumably the Travis integration already solves that part, so > I suspect it is just the matter of setting up: > > - a fork of git.git and have Travis monitor any and all new > branches; > > - a bot that scans the list traffic, applies each series it sees to > a branch dedicated for that series and pushes to the above fork. > > isn't it? Mailing list users can already use Travis CI to check their patches prior to sending them. I just posted a patch with setup instructions (see $gmane/291371). @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 talked to Josh Kalderimis from Travis CI and he told me the load wouldn't be a problem for Travis CI at all. - Lars -- 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