<div dir="ltr"><div>Yes, it's more of a guide than an absolute rule. If a merging developer wants to cherry-pick and resolve conflicts, we should not disallow that. To capture that aspect, the current language could be reverted back to the "we should consider..." language that would allow the merger to have discretion and choice.<br><br></div><div>I'm +1 still in both cases.<br><br></div><div>As an aside, reviewing a merge conflict resolution is not easy in git. I'm stating this hoping I just don't understand it and that someone can show me how it's done some other time. After spending a good amount of time in #git one day on this topic w/ @asmacdo I'm convinced this isn't a use case git handles well. If that is true then having a review process for conflict resolution is something git and github won't allow us to facilitate. I hope I'm wrong about this.<br><br></div><div>-Brian<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 10:01 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">Regarding your concern about not cherry-picking if there are conflicts, the PUP originally said “we should consider …”. I think we went with stronger language though to dissuade developers from cherry-picking (by default) if there are conflicts. That said, as in the use case you mention, I think that’s a perfectly fine example of when it’s ok to cherry-pick even though there’s a conflict. I think of this as more of a guideline than an absolute rule.</div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_295442359367187838gmail_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="h5">
<br><div class="gmail_quote">On Mon, Jun 12, 2017 at 9:23 AM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@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">-0 for similar reasons to those already discussed.<div><br></div><div>We've identified alternatives that would address many of the concerns listed in the Motivation section. To re-cap:</div><div><br></div><div>Merge mistakes: we have multiple options we could implement with the merge-forward option.</div><div><br></div><div>Community PR rebasing: we can either use the new github feature to auto-rebase, or take the same approach as the PUP (let the PR stay on master) and just accept that some of those changes won't make it into a Z release. </div><div><br></div><div>Merge conflict resolution: the PUP says this can lead to mistakes that go unreviewed, but we've also heard feedback in this discussion that merging forward is almost never a problem. My view is that on rare occasions a merge conflict can get resolved incorrectly, but it's not a substantial problem for us, and those cases should be easily caught with automated testing. We will make mistakes that break master for lots of reasons, some that even go unnoticed in review. We should strive to make those rare, but also should have confidence that our testing will catch such problems and enable us to quickly correct them. Our current guidelines do encourage review for merge conflicts that are substantial:</div><div><br></div><div><a href="http://docs.pulpproject.org/dev-guide/contributing/merging.html#merging-your-changes" target="_blank">http://docs.pulpproject.org/de<wbr>v-guide/contributing/merging.<wbr>html#merging-your-changes</a><br></div><div><br></div><div>We could make the language around that stronger, or even require review for such cases.</div><div><br></div><div>All of that said, while I think we have ways to address nearly all the PUP's concerns without changing to a cherry-pick model, I'm certainly willing to try such a model. My preference would be to try some less-drastic changes to our process first, and see how that goes. But I am sure that we could be successful with a cherry-pick model, and given broad interest am willing to try it.</div><div><br></div><div>I have only one big concern: "If the cherry-pick has conflicts, we should abandon the cherry-pick and encourage users to upgrade to the next Y release." I worry that this will have a big impact on our ability to deliver bug fixes. As long as we retain some discretion to employ a small amount of conflict resolution when reasonable, I think this could be a fine guideline. But if we were to apply it as an absolute rule, it may affect many more changes, and substantially slow down our ability to release fixes early and often. For example, often when we see a conflict, it is with import statements. It would be a shame to omit a fix from a Z release over that.</div></div><div class="m_295442359367187838HOEnZb"><div class="m_295442359367187838h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 9, 2017 at 9:09 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">Just wanted to send out a reminder that voting is ending on Monday, June 12 at 9pm UTC. I haven’t seen much of a response around trying to adopt an alternative to PUP-3 that doesn’t involve cherry-picking so I am going to assume there isn’t much interest in doing so. Again, please respond with any thoughts or feel free to change your vote if that’s not the case. Thanks.<div class="gmail_extra"><span class="m_295442359367187838m_7026915712336948125HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985gmail_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_295442359367187838m_7026915712336948125h5">
<br><div class="gmail_quote">On Tue, Jun 6, 2017 at 4:59 PM, 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">Talking with @bmbouter a little more about the PUP process and looking back at PUP-1, I think that the only way for PUP-3 to not be accepted is if a core developer were to cast/recast a -1 vote. I know there has been talk about alternatives but looking at the votes, there is a consensus around adopting PUP-3:<div><br></div><div>+1 - 5 votes</div><div>+0 - 1 vote</div><div>-0 - 2 votes</div><div>-1 - 0 votes</div><div><br></div><div>If anyone feels strongly about trying out an alternative or discussing alternatives further, please recast your vote or respond with your concerns. Otherwise, I think we'll proceed with approving/rejecting the PUP based on the votes on the deadline of June 12th.</div></div><div class="gmail_extra"><span class="m_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985m_-2855313112784594632gmail_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_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985h5">
<br><div class="gmail_quote">On Tue, Jun 6, 2017 at 4:27 PM, 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">I have updated the proposal’s motivation section. Note that the actual change/workflow hasn’t changed at all.</div><div class="gmail_extra"><span class="m_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985m_-2855313112784594632HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985m_-2855313112784594632m_-1091745213126209744gmail_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_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985m_-2855313112784594632h5">
<br><div class="gmail_quote">On Tue, Jun 6, 2017 at 4:08 PM, 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">Looks like @bmbouter made a comment to include this but I forgot to include it:<div><br></div><div><a href="https://github.com/pulp/pups/pull/3#discussion_r111498031" target="_blank">https://github.com/pulp/pups/p<wbr>ull/3#discussion_r111498031</a><br></div><div><br></div><div>Will update the PUP.</div></div><div class="gmail_extra"><span class="m_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985m_-2855313112784594632m_-1091745213126209744HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985m_-2855313112784594632m_-1091745213126209744m_8997443759860390861gmail_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_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985m_-2855313112784594632m_-1091745213126209744h5">
<br><div class="gmail_quote">On Tue, Jun 6, 2017 at 3:48 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@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 class="gmail_extra"><span><br><div class="gmail_quote">On Tue, Jun 6, 2017 at 9:58 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">I think we need to redo the git workflow because we can't continue to resolve conflicts during merge forward as we did before. I see that as the central issue the PUP is resolving.</blockquote></div><br></span>The PUP likely needs additional revision in that case; it does not mention conflict resolution at all as a motivation. It would be valuable to spell that out and discuss it.<span><br><br clear="all"><div><br></div>-- <br><div class="m_295442359367187838m_7026915712336948125m_6873724207402769684m_4873287454888712985m_-2855313112784594632m_-1091745213126209744m_8997443759860390861m_2844729414093854752gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</span></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_295442359367187838m_7026915712336948125gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>