[llvm-dev] Enable Contributions Through Pull-request For LLVM
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 8 08:08:17 PST 2019
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.
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.
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 LLVM.
> 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
> - 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 Phabricator.
> - 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 pull-request.
> - 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 <https://github.com/tensorflow/mlir/pulls>.
> Here is a more complete doc on the topic:
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev