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

Fri Nov 8 08:29:15 PST 2019

On 11/8/19 8:15 AM, Mehdi AMINI wrote:
>
>
> On Fri, Nov 8, 2019 at 8:08 AM Philip Reames
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     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.
We're making major changes to workflow and process.  The impact on
contributors and downstream workflows is substantial.  Spreading them
out in time a bit gives folks time to react, plan, and object if desired.
>
>     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.
Any change in tooling of this magnitude is a headache.  There's a period
of lost productivity no matter what the end result is.  The new tool can
be the perfect solution, and there's still a substantial switching
cost.  There's always a period where there's a net loss in productivity,
the only question is how long it is until the new tool's benefit pays it
back. 
>
>       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 ».
I have used git successfully for several years to manage internal
repositories.  We'll have to agree to disagree on your first sentence. 
>
> 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 pull-requests :)
>
>
> — 
> Mehdi
>
>
>     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 <mailto: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/16ad5732/attachment.html>