[llvm-dev] Enable Contributions Through Pull-request For LLVM

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Sun Nov 10 08:25:58 PST 2019

On 11/8/19 9:29 AM, David Greene wrote:
> Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> Weak -1 in general.  I'm not strongly opposed, but I see very little
>> value in this migration and a lot of headache.  Others have explained
>> this well, so I'll mostly skip that.  I particular dislike the assumed
>> fork model; I work in patches, so that's a ton of overhead process wise. 
> Can you explain this a bit more?  The way I anticipate doing this:
> 1. Create fork once for all time
> 2. Set a remote for the fork in my local clone once for all time
> while ((I am employed or financially independent) and working on LLVM)
>   1. Make a commit
>   2. Push to fork remote
>   3. Open PR (probably right in emacs using Magit)
>   4. Respond to comments, push further commits, squash as needed, etc.
>   5. Declare done and request CI/merge
> elihw
> I would never delete the fork or the fork remote.

In my experience, it isn't the simple workflow you've sketched where
problems arise, it's all of the cornercases. 

Let's say I post a patch, and the (warranted) reviewer comment is that
it should be split.  I push a couple new PRs, they get approved, and
landed.  (All as new branches off master.)  Then, I have a stale branch
(say it contains 2 commits) which needs rewritten.  I can of course do
an interactive rebase, and a force push, but a) I've found interactive
rebases to be very error prone, and b) I *strongly* prefer to never be
in the habit of doing a force push.  The alternative is to close the
original PR, and simply post a new one - which looses history of review. 

To be clear, my point is not that I can't do all that.  My point is
there's a lot of conceptual overhead and room for error, which doesn't
exists with the patch model.  My experience is pull requests work *very
well* for simple things, and somewhat poorly for more complicates ones. 

(Again, the above is entirely personal opinion based on my own experience.)

>> One exception for me would be docs.  If we could open pull requests -
>> and possibly the web-edit tool for folks with commit access? - for the
>> docs subtree I could see a lot of advantage in making those easy for new
>> contributors to update.  It might also be a good proving ground for the
>> workflow as a whole.
> That's a really great idea!
>                   -David

More information about the llvm-dev mailing list