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

[Daniel Sanders via llvm-dev]

> > On Fri, Jul 22, 2016 at 3:40 PM, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
> > Do you have an example in mind? I'd expect them to rely on each 'master' being
> > an improvement on 'master^'. I wouldn't expect them to be interested in how
> > 'master^' became 'master'.
>
> 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.
>
> 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.

I'd like to see this too. I'd prefer not to make it a requirement for _all_ buildbots to pass before commit though. I'm thinking that we could make passing 'fast' buildbots mandatory before commit but leave 'slow' buildbots in the current post-commit testing scheme. That way targets that can provide fast buildbots will win additional stability guarantees but the community isn't held back by the slowest buildbot. We'd have to discuss where we'd draw the line between 'fast' and 'slow'.

From: bruce.hoult at gmail.com [mailto:bruce.hoult at gmail.com] On Behalf Of Bruce Hoult
Sent: 22 July 2016 14:33
To: Daniel Sanders
Cc: Renato Golin; LLVM Developers
Subject: Re: [llvm-dev] [RFC] One or many git repositories?

On Fri, Jul 22, 2016 at 3:40 PM, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Do you have an example in mind? I'd expect them to rely on each 'master' being
an improvement on 'master^'. I wouldn't expect them to be interested in how
'master^' became 'master'.

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.

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.

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.

If a "proposed master" fails and it has more than one pull request in it, then you can bisect it to find the bad pull request, throw it out, and try again without it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/8ed0a98d/attachment.html>