llvm dev - Jan 2019 - [cfe-dev] [Github] RFC: linear history vs merge commits

Jeremy Lakeman via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 4. Each reviewed bug / feature must be rebased onto the current "known
> good" commit, merged into a "probably good" commit, tested
by build
> bots, and only then pushed to trunk. Keeping trunk's history more
> usable, with most bad patches reworked and resubmitted instead of
> reverted.
If you mean having a submitted PR trigger builds and only allow merging
if all builds pass, that may be doable.  Of course by the time it's
merged it will be against some later commit (so it should be rebased)
and there's no guarantee it will build against *that* commit.  But it
will tend to filter out most problems.

Trying to keep a branch buildable at all times is a hard problem, but
the above is probably a 90% solution.

                                -David

> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of David
> Greene via cfe-dev
> Sent: Wednesday, January 30, 2019 3:52 PM
> To: Jeremy Lakeman
> Cc: llvm-dev; LLDB Dev; cfe-dev; openmp-dev (openmp-dev at lists.llvm.org)
> Subject: Re: [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge
> commits
> 
> Jeremy Lakeman via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 
> > 4. Each reviewed bug / feature must be rebased onto the current
"known
> > good" commit, merged into a "probably good" commit,
tested by build
> > bots, and only then pushed to trunk. Keeping trunk's history more
> > usable, with most bad patches reworked and resubmitted instead of
> > reverted.
> 
> If you mean having a submitted PR trigger builds and only allow merging
> if all builds pass, that may be doable.  Of course by the time it's
> merged it will be against some later commit (so it should be rebased)
> and there's no guarantee it will build against *that* commit.  But it
> will tend to filter out most problems.
Systems that I've seen will funnel all submitted PRs into a single queue
which *does* guarantee that the trial builds are against HEAD and there
are no "later commits" that can screw it up. If the trial build
passes,
the PR goes in and becomes the new HEAD.
By the time a PR reaches the front of the build queue, it might not apply
cleanly, in which case it gets bounced just like a failed build would.

But this would be a radical redesign of the LLVM bot system, and would
have to wait until we're done with the GitHub migration and can spend
a couple of years debating the use of PRs. :-)
--paulr

<paul.robinson at sony.com> writes:
> Systems that I've seen will funnel all submitted PRs into a single
queue
> which *does* guarantee that the trial builds are against HEAD and there
> are no "later commits" that can screw it up. If the trial build
passes,
> the PR goes in and becomes the new HEAD.
The downside of a system like this is that when changes are going in
rapidly, the queue grows very large and it takes forever to get your
change merged.  PR builds are serialized and if a "build" means
"make
sure it builds on all the Buildbots" then it takes a very long time
indeed.

There are ways to parallelize builds by speculating that PRs will build
cleanly but it gets pretty complicated quickly.
> But this would be a radical redesign of the LLVM bot system, and would
> have to wait until we're done with the GitHub migration and can spend
> a couple of years debating the use of PRs. :-)
Heh.  Fully guaranteeing buildability of a branch is not a trivial task
and will take a LOT of thought and discussion.

                              -David