Junio C Hamano [off-list ref] writes:
On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley [off-list ref] wrote:
quoted
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. Here are
the patches to fix them, and by the way, the first patch in this
series is not a fix but the configuration to tell Travis how to run
tests so that other people can enable it on _their_ own fork before
they send their own series to the mailing list." in the cover letter
of a patch series, I would appreciate such a series greatly and
would not mind carrying one extra yml file in the tree at all.
But that is not what I am seeing in this thread at all. I am tired
of hearing people telling others to help them by doing more without
doing the grunt work themselves.
On za, 2015-10-03 at 18:37 -0700, Junio C Hamano wrote:
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.
I've been maintaining a clone of git/git with a different ci system
enabled, and it hasn't really caught anything. Only the occasional test
failure in pu like the one I mailed about yesterday.
The automated testing of pull requests could be useful, but pull
requests don't seem to be used much yet.
--
Dennis Kaarsemaker
www.kaarsemaker.net
Hi Junio,
On 2015-10-04 03:37, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley [off-list ref] wrote:
quoted
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.