llvm dev - Nov 2019 - Enable Contributions Through Pull-request For LLVM

On Fri, Nov 8, 2019 at 8:08 AM Philip Reames <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.

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
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 listllvm-dev at
lists.llvm.orghttps://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/e7405c6c/attachment.html>

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>

On Fri, 8 Nov 2019 at 16:15, Mehdi AMINI via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Sorry but pull request and forks are strictly less overhead process wise,
especially compared to working with patches.
I agree with this, and in general am definitely in favour of pull
requests. Wrangling patch files manually is just so clunky compared to
everything else I do in LLVM.

Cheers.

Tim.

Is there a reason to not just use arcanist instead of dealing with patch files
manually? The PHP requirement is a bit annoying, sure, but that should be
available via package manager, and then it's just a matter of cloning two
git repositories, modifying your PATH/setting up an alias, and then you're
good to go (and all of that is just a one-time setup and not something you
should need to worry about ever again). Some package managers even package
arcanist directly; I know Nix does.

On 11/9/19, 12:47 AM, "llvm-dev on behalf of Tim Northover via
llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at
lists.llvm.org> wrote:

    On Fri, 8 Nov 2019 at 16:15, Mehdi AMINI via llvm-dev
    <llvm-dev at lists.llvm.org> wrote:
    > Sorry but pull request and forks are strictly less overhead process
wise, especially compared to working with patches.
    
    I agree with this, and in general am definitely in favour of pull
    requests. Wrangling patch files manually is just so clunky compared to
    everything else I do in LLVM.
    
    Cheers.
    
    Tim.
    _______________________________________________
    LLVM Developers mailing list
    llvm-dev at lists.llvm.org
   
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RnEAn0fj7ME-imuOBNpKWa-RRucvB5NfcIaiaFvt36I&s=bnD5rqSbVY2zMvewfkC5Oyk4yIV52CUQRbFFH8sE3_g&e=