[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits
David Greene via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 1 08:01:40 PST 2019
Oh, I'm completely in favor of making bad commits much less likely. I
simply think there is a decent solution between "let everything in" and
"don't let everything in unless its proven to work everywhere" that gets
90% of the improvement. The complexity of guaranteeing a buildable
branch is high. If someone wants to take that on, great! I just don't
think we should reasonably expect a group of volunteers to do it. :)
Jeremy Lakeman <Jeremy.Lakeman at gmail.com> writes:
> I realise that llvm trunk can move fairly quickly.
> So my original, but brief, suggestion was to merge the current set of
> approved patches together rather than attempting them one at a time.
> Build on a set of fast smoke test bots. If something breaks, it should
> be possible to bisect it to reject a PR and make forward progress.
> Occasionally bisecting a large set of PR's should still be less bot
> time than attempting to build each of them individually.
> Blocking the PR's due to target specific and or slow bot failures
> would be a different question.
> You could probably do this with a linear history, so long as the final
> tree is the same as the merge commit, it should still build.
> I'm just fond of the idea of trying to prevent bad commits from ever
> being merged. Since they sometimes waste everyone's time.
> On Fri, 1 Feb 2019 at 04:02, David Greene <dag at cray.com> wrote:
> <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
> > the PR goes in and becomes the new HEAD.
> The downside of a system like this is that when changes are going
> rapidly, the queue grows very large and it takes forever to get
> change merged. PR builds are serialized and if a "build" means
> sure it builds on all the Buildbots" then it takes a very long
> There are ways to parallelize builds by speculating that PRs will
> cleanly but it gets pretty complicated quickly.
> > But this would be a radical redesign of the LLVM bot system, and
> > have to wait until we're done with the GitHub migration and can
> > a couple of years debating the use of PRs. :-)
> Heh. Fully guaranteeing buildability of a branch is not a trivial
> and will take a LOT of thought and discussion.
More information about the llvm-dev