[llvm-dev] [RFC] One or many git repositories?

[Renato Golin via llvm-dev]

On 22 July 2016 at 14:33, Bruce Hoult <bruce at hoult.org> wrote:
> I would love it if each master commit was an improvement on the previous
> commit, or at last was virtually guaranteed to be not broken. It's most
> annoying that the existing LLVM history has a lot of examples of commits
> being reversed by a later commit.

Historically, we use buildbots like we do as a way to work around the
fact that SVN doesn't have pull requests.


> The ease in git of branching -- and more importantly rebasing the branch on
> a later state of master -- means that you can run buildbots for all the
> different platforms on each pull request BEFORE merging it to master.

Indeed, this would be a *great* improvement.


> If buildbots are not fast enough to test every change (let alone repeatedly)
> then you can keep a pristine "master" head and a "proposed master" head that
> might have several pull requests added onto it sequentially. Then have the
> buildbots test the "proposed master" and if it passes then fast-forward
> advance the "master" head to the current "proposed master" head. Then merge
> the next batch of pull requests onto "proposed master", rinse and repeat.

We don't need to turn off the current post-commit bots, though. We
don't even need to use buildbots for pre-commits.

The current bots are good at covering the basics, like a last line of
defence. For pull requests we could have a simplified *additional*
testing that would pick the majority of the breakages.

That could be Jenkins or something else, that can drive configurable
builds through a large shared pool of resources, which is much more
suitable to pre-commit testing.

These would have to be *only* fast builders (~30min or less) and
should cover different targets. We should aim to have at least one per
supported target.

cheers,
--renato