[llvm-dev] Enable Contributions Through Pull-request For LLVM
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 8 08:15:16 PST 2019
On Fri, Nov 8, 2019 at 8:08 AM Philip Reames <listmail at philipreames.com>
> Very strong -1 at the moment. I think we need to let some of the other
> efforts (e.g. issues vs bugzilla) settle out first.
Sorry I really don’t see a relationship with issues, this seems entirely
independent to me. I even actually see this as easier than issues.
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 am not sure what « headache » your referring to at the moment.
I particular dislike the assumed fork model; I work in patches, so that's
> a ton of overhead process wise.
Sorry but pull request and forks are strictly less overhead process wise,
especially compared to working with patches.
What you’re writing comes across to me as « not having switched to git yet
This is also the reason why we need months of trial for everyone who hasn’t
used it extensively before to be able to give it a complete and honest try.
Again I’d be perfectly happy to be ginea pig in our sub-project as well to
begin with: it may even bring people to contribute just for trying
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.
> On 11/6/19 9:32 PM, Mehdi AMINI via llvm-dev wrote:
> Hi all,
> Now that we're on GitHub, we can discuss about pull-requests.
> I'd like to propose to enable pull-request on GitHub, as a first step as
> an experimental channel alongside the existing methods for contributing to
> This would allow to find workflow issues and address them, and also LLVM
> contributors in general to start getting familiar with pull-requests
> without committing to switching to pull-requests immediately. The community
> should evaluate after a few months what would the next steps be.
> GitHub pull-requests is the natural way to contribute to project hosted on
> GitHub: this feature is so core to GitHub that there is no option to
> disable it!
> The current proposal is to allow to integrate contributions to the LLVM
> project directly from pull-requests. In particular the exact setup would be
> the following:
> - Contributors should use their own fork and push a branch in their fork.
> - Reviews can be performed on GitHub. The canonical tools are still the
> mailing-list and Phabricator: a reviewer can request the review to move to
> - The only option available will be to “squash and merge”. This mode of
> review matches the closest our current workflow (both phabricator and
> mailing-list): conceptually independent contributions belongs to separate
> review threads, and thus separate pull-requests.
> This also allow the round of reviews to not force-push the original branch
> and accumulate commits: this keeps the contextual history of comments and
> allow to visualize the incremental diff across revision of the
> - Upon “merge” of a pull-request: *history is linear* and a single
> commit lands in master after review is completed.
> As an alternative staging proposal: we could enable pull-requests only for
> a small subset of sub-projects in LLVM (i.e. not LLVM/clang to begin with
> for example) in the repo. In this case, we would propose to begin with the
> MLIR project (as soon as it gets integrated in the monorepo). This would be
> a good candidate to be the guinea pig for this process since it does not
> yet have a wide established community of contributors, and the current
> contributors are already exclusively using pull-requests
> Here is a more complete doc on the topic:
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev