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

[David Chisnall via llvm-dev]

On 25 Jul 2016, at 11:19, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> > > On Fri, Jul 22, 2016 at 3:40 PM, Daniel Sanders via llvm-dev <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'.

How difficult would it be with GitHub to set up something to automatically merge pull requests if they keep the buildbots happy?  The workflow would then be to send a pull request annotated by a committer as ready to merge (i.e. reviewed / due for post-commit review).  If it passed, then no more human interaction would be required - once the buildbots had finished testing it, it would be the new master (effectively, we’d merge to a speculative-master and then perform a simple fast-forward push from there to the real master if the tests passed).  If they failed, then drop it from the queue and add a note on the pull request indicating what failed.

The workflow would be exactly the same for committers and non-committers, except that committers would be able to tag their own pull requests as ready to merge.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/08834bed/attachment.bin>