On 9 February 2018 at 13:07, Olivier Goffart <oliv...@woboq.com> wrote:
> Anyway, here is some example of models which works:
> In LLVM, devs commit directly. buildbots build the trunk continuously. In case
> of failure, the buildbot maintainer quickly find out which commit likely broke
> the test and reverts the commit imediatly (or commit a fix if the fix is
> This works because there are buildbot maintainers taking care of the build
> status, and they are not afraid to revert. Also the build and test time is
> reasonable (while still being big), and individual developer can easily run
> all the tests on their machine before submitting patches. (Very few platform
> specific tests).
Well, it really can't hurt much to give another example. When I
contribute to GCC, I write
my patch, ssh into a compile farm, pull the repo, apply my patch and
run the testsuite.
After that I submit it for review. There are people running CI-like
build runs, but those don't
block commits. Once a patch has been accepted, I just push it. If
something breaks despite
testing, that's very rare and can be dealt with after-the-fact.
> In Summary: The CI should be a tool helping the development, and not slowing
> it down. And having a way to override the CI for important patches should be
> an easy and quick way to improve things a bit.
Fully agreed, but we already can do such overrides in emergency
situations, and we probably don't
want to enable just everybody to do so. Having said all this, there's
ongoing active work to fix
the CI problems.
Development mailing list