<div dir="ltr"><div><div>The ability for us to change the PR branch does eliminate some of the back and forth with the contributor so that is addressed and good. I hadn't thought of that.<br><br></div>The reason I'm still +1 is because I have two main concerns with the current processes: conflict resolution and avoiding the epic merge forward issues we've had in the past. When merging other people's code I can't be resolving conflicts. When we didn't get many community PRs I was resolving my conflicts on my own code and that was just part of it. As we get more community PRs, we need a frictionless merging experience that doesn't involve conflict resolution ever. The second reason we should pass this is so we never have another merge forward fail like the three we've had before, each which took several people hours and days to resolve.<br><br></div><div>I like all the discussion on this. It shows how thoughtfully people are considering this important change. Thank you for all the discussion and opinions.<br></div><div><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 11:37 AM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">To address your concern about how to handle community contributions (1), in GitHub, you can change the base branch of any PR if you have commit access to the repo. So contributors could open PRs against master and then we could switch it to the correct x.y-dev branch if needed, Github will automatically check for merge conflicts, and the test suite gets run again automatically.<div><br></div><div>For item (2), I would expect the person reviewing/merging the code to have enough familiarity with the code to be able to merge that code forward. No?</div><div class="gmail_extra"><span class="m_-1526926656710748908HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div></font></span><div><div class="m_-1526926656710748908h5">
<br><div class="gmail_quote">On Thu, May 25, 2017 at 11:41 AM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>+1 from me<br><br>I read the article, but does it really apply to us? The issues it describes stemsfrom "when a change is cherry-picked into a branch and there is a 
conflict a new commitid is created". In our case when a cherry pick back
 creates a conflict we are recommending to abandon the cherry pick [1] 
which should avoid the situation.<span><br><br></span></div>If we're unable to pass this vote, I'm left with two practical problems. Mainly in terms of PRs from the community. We're getting more PRs from the community.<br><br></div>1) For almost all bugfix PRs that are opened from non core devs they target master. With the current process we need to ask them to rebase their code and then close+reopen the PR against the current x.y-dev branch.<br><br></div>2) After a community PR is merged, I need to merge it forward. If there are any conflicts at that point I (the merger) needs to fix up code I didn't write. That is not a good position for the person merging to be in.<br><br></div>I'm not able to facilitate these things anymore. If we can't pass the vote who will handle ^ situations?<br><br>[1]: <a href="https://github.com/pulp/pups/pull/3/files#diff-18a9b677be3c8c4434ac32097da7fa58R86" target="_blank">https://github.com/pulp/pups/p<wbr>ull/3/files#diff-18a9b677be3c8<wbr>c4434ac32097da7fa58R86</a><span class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184HOEnZb"><font color="#888888"><div><br></div>-Brian<br></font></span></div><div class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184HOEnZb"><div class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 10:30 AM, Patrick Creech <span dir="ltr"><<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-1<br>
<br>
I've come late to this topic, and wanted to wait till voting time to form an opinion, so I apologize<br>
if some of the reasons I'm voting -1 have already been discussed and brought up.<br>
<br>
While trying to come up with a decision on this topic, I googled "git merge vs cherry-pick".  The<br>
overwhelming ammount of search results were basically 'don't cherry-pick!'.  The page that I favored<br>
is [0].  It brings up some good points about loosing git's internal tracking of commits.  It seems<br>
cherry-picks do get new commit id's instead of using the same ones.  While this site is basically a<br>
'Don't cherry pick' opinion piece, it did make me think about our motivations for moving away.<br>
<br>
One of my concerns is we are talking about adding more procedure and complexity, and I'm personally<br>
questionable of the benefit.  Based on what i've read, people are using this strategy successfully,<br>
so maybe I'm wrong on this assumption.<br>
<br>
The main reason that I've noticed for peoples motivations for cherry-picking is 'Our merge workflow<br>
has bit us repeatedly in the past, let's not do that anymore!'.  The second to last paragraph under<br>
'Motivation' spells this out spectacularly.  The reasons for +1's with people I've spoken too have<br>
seemed more of a vote -against- our current merge forward process than -for- cherry-picking.<br>
<br>
I'm more in favor of us re-evaluating when and how we manage the merge forwards (as it does appear<br>
our current automation has been a big source of pain at least once), and believe that just adding<br>
better process and diligence around our current way of doing things will probably be better than<br>
inventing a new process and figuring out the pain points as we go there.  <br>
<br>
<br>
[0] <a href="https://dan.bravender.net/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html" rel="noreferrer" target="_blank">https://dan.bravender.net/2011<wbr>/10/20/Why_cherry-picking_shou<wbr>ld_not_be_part_of_a_normal_git<wbr>_workf<br>
low.html</a><br>
<div class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184m_-4529377306040047761HOEnZb"><div class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184m_-4529377306040047761h5"><br>
<br>
On Wed, 2017-05-24 at 16:00 -0400, David Davis wrote:<br>
> I’d like to kick off the voting on PUP-3 which is the proposal to change our git workflow by using<br>
> cherry-picks instead of merging changes forward. The proposal can be viewed here:<br>
><br>
> <a href="https://github.com/daviddavis/pups/blob/pup3/pup-0003.md" rel="noreferrer" target="_blank">https://github.com/daviddavis/<wbr>pups/blob/pup3/pup-0003.md</a><br>
><br>
> Feel free to submit any comments/nitpicks/etc on the PR[0]. <br>
><br>
> PUP-1 outlines our voting system:<br>
><br>
> <a href="https://github.com/pulp/pups/blob/master/pup-0001.md" rel="noreferrer" target="_blank">https://github.com/pulp/pups/b<wbr>lob/master/pup-0001.md</a><br>
><br>
> But to sum it up:<br>
><br>
> +1: "Will benefit the project and should definitely be adopted."<br>
> +0: "Might benefit the project and is acceptable."<br>
> -0: "Might not be the right choice but is acceptable."<br>
> -1: "Not the right choice and should definitely not be adopted."<br>
><br>
> I’ll set the initial deadline for the voting to be June 5th 9pm UTC.<br>
><br>
> [0] <a href="https://github.com/pulp/pups/pull/3" rel="noreferrer" target="_blank">https://github.com/pulp/pu<wbr>ps/pull/3</a><br>
><br>
> David<br>
</div></div><div class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184m_-4529377306040047761HOEnZb"><div class="m_-1526926656710748908m_-3013680334913892403m_7254318370196002184m_-4529377306040047761h5">> ______________________________<wbr>_________________<br>
> Pulp-dev mailing list<br>
> <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a></div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>