<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 11/8/19 8:15 AM, Mehdi AMINI wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANF-O=Zs5RSgm-bfLDH5SP4QCke0=FjUP8zRp3S5E+0od9J40w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2019 at 8:08
AM Philip Reames <<a
href="mailto:listmail@philipreames.com"
moz-do-not-send="true">listmail@philipreames.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
</div>
</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid:CANF-O=Zs5RSgm-bfLDH5SP4QCke0=FjUP8zRp3S5E+0od9J40w@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto"><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
</div>
</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">I am not sure what « headache » your referring
to at the moment.</div>
</div>
</div>
</blockquote>
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. <br>
<blockquote type="cite"
cite="mid:CANF-O=Zs5RSgm-bfLDH5SP4QCke0=FjUP8zRp3S5E+0od9J40w@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto"><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> I particular dislike the assumed fork model; I work
in patches, so that's a ton of overhead process wise. <br>
</p>
</div>
</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">Sorry but pull request and forks are strictly
less overhead process wise, especially compared to working
with patches.</div>
<div dir="auto">What you’re writing comes across to me as «
not having switched to git yet ».</div>
</div>
</div>
</blockquote>
I have used git successfully for several years to manage internal
repositories. We'll have to agree to disagree on your first
sentence. <br>
<blockquote type="cite"
cite="mid:CANF-O=Zs5RSgm-bfLDH5SP4QCke0=FjUP8zRp3S5E+0od9J40w@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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 :)</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">— </div>
<div dir="auto">Mehdi</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<p>Philip<br>
</p>
<div>On 11/6/19 9:32 PM, Mehdi AMINI via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi all,<br>
<div><br>
</div>
<div>Now that we're on GitHub, we can discuss
about pull-requests.</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>
<div>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! </div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div> - Contributors should use their own
fork and push a branch in their fork.</div>
<div> - 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.</div>
<div> - 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. </div>
<div>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. </div>
<div> - Upon “merge” of a pull-request: <b>history
is linear</b> and a single commit lands
in master after review is completed.</div>
<div><br>
</div>
<div>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 <a
href="https://github.com/tensorflow/mlir/pulls"
target="_blank" moz-do-not-send="true">already
exclusively using pull-requests</a>.</div>
</div>
<div><br>
</div>
<div>Here is a more complete doc on the topic:
<a
href="https://docs.google.com/document/d/1DSHQrfydSjoqU9zEnj3rIcds6YN59Jxc37MdiggOyaI"
target="_blank" moz-do-not-send="true">https://docs.google.com/document/d/1DSHQrfydSjoqU9zEnj3rIcds6YN59Jxc37MdiggOyaI</a></div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>-- </div>
<div>Mehdi</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>