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

[Philip Reames via llvm-dev]

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.

Philip

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
> 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 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:
> https://docs.google.com/document/d/1DSHQrfydSjoqU9zEnj3rIcds6YN59Jxc37MdiggOyaI
>
> Cheers,
>
> -- 
> Mehdi
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191108/afb106a1/attachment.html>