llvm dev - Jul 2016 - [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> 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/20160722/f828d23e/attachment.html>

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

> > 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>

On 25 July 2016 at 11:19, Daniel Sanders <Daniel.Sanders at imgtec.com>
wrote:
> 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'.
I think targets that want the additional stability should provide
*additional* pre-commit bots. Not all commits will be pull requests,
and skipping fast bots on non-pull requests wouldn't be wise.

They also have a different requirement and will take on more patches
than the post-commit bots and potentially a lot more *broken* patches.
We should not have them in the same infrastructure or at least not
with the same configuration, scale, etc. as the post commit ones.

--renato

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>