Luke Diamand <luke@xxxxxxxxxxx> writes: > It would be less intrusive for the CI system to have a fork. Otherwise > other people using git with the same CI system will get annoying merge > conflicts, What conflicts are you talking about? The ones in .travis.yml? The point is to share this file so that people using the same system do not have to change anything. And, we're talking about a straightforward 28-lines long file, set up essentially once and for all. Even if people ever modify it, I don't forsee conflict resolution in such a simple file as a real problem. > and we'll also end up with a repo littered with the control files from > past CI systems if the CI system is ever changed. Again, we're talking about a short and simple configuration file. Sure, when we change something, we either get old files lying around or have to remove the old files. But would we say "Git shouldn't have a Makefile, because having a Makefile would mean we'd end up with a repo littered with Makefiles the day we migrate to another build system"? > From past experience, if it's configured to email people when things > break, sooner or later it will email the wrong people, probably once > every few seconds over a weekend. Are you talking about your experience with Travis-CI in particular, or with CI systems in general? Is the scenario where Travis-CI sends email based on actual facts, or only speculation? My experience with Travis-CI is that it just works (my experience is limited, but I'm using it for git-multimail, and it's a really convenient tool). It does send emails by default, but with a very reasonable policy: http://docs.travis-ci.com/user/notifications/ "By default, email notifications are sent to the committer and the commit author, if they are members of the repository (that is, they have push or admin permissions for public repositories, or if they have pull, push or admin permissions for private repositories)." In short: * If the tests always pass, nobody ever get any email from Travis-CI. * When someone sends a pull-request that fails tests, that someone gets an automatic email about the failure. This saves one email round-trip "X sends a patch series, Junio notices the failure, Junio sends an email about the failure", and shortcuts this as "X sends a PR, and gets an email, possibly even before Junio notices". > Automated testing is a Good Thing, but it's still software, so needs > maintenance or it will break. The point of using Travis-CI is precisely to use an externally maintained system. It's not just software, it's a service (based on software, obviously). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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