<div dir="ltr">I’ve been working on the PUP for cherry-picking changes across our branches and I’ve opened a PR. Feedback would be much appreciated.<div><br></div><div><a href="https://github.com/pulp/pups/pull/3" target="_blank">https://github.com/pulp/pups/p<wbr>ull/3</a><br></div><div><br></div><div>Also, I wanted to mention that it might be worth discussing how we can improve our merge forward process even if we don’t want to use cherry-picking instead. We’ve seen a couple accidental merges and I was wondering if there might be some way to prevent that? Two options I can think of. First maybe we could merge forward less often? I’m not sure how to time this. Secondly, perhaps we could use code reviews/PRs to confirm merges?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks.<br clear="all"><div><div class="m_8458281304547527575m_-2183137898138994587gmail_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>
<br><div class="gmail_quote">On Tue, Mar 21, 2017 at 4:08 PM, 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">I would really like to collaborate on this. First one to start it; let the other know.<br></div><div class="m_8458281304547527575m_-2183137898138994587HOEnZb"><div class="m_8458281304547527575m_-2183137898138994587h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 3:18 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">So I was planning on doing that actually. Although, if you have the spare cycles, go for it.</div><div class="gmail_extra"><span class="m_8458281304547527575m_-2183137898138994587m_-8088442529168775270HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_8458281304547527575m_-2183137898138994587m_-8088442529168775270m_-1138659361696289394gmail_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_8458281304547527575m_-2183137898138994587m_-8088442529168775270h5">
<br><div class="gmail_quote">On Tue, Mar 21, 2017 at 2:49 PM, 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> I plan to turn this thread into a formal RFC once that process has been ratified.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_8458281304547527575m_-2183137898138994587m_-8088442529168775270m_-1138659361696289394h5">On Tue, Mar 21, 2017 at 11:13 AM, Sean Myers <span dir="ltr"><<a href="mailto:sean.myers@redhat.com" target="_blank">sean.myers@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_8458281304547527575m_-2183137898138994587m_-8088442529168775270m_-1138659361696289394h5"><span>On 02/06/2017 12:09 PM, Ina Panova wrote:<br>
> Seems like we are trying to choose/figure out what's more important -<br>
> linear commit history which is readable or confidence and ability to track<br>
> where exactly change had been applied?<br>
><br>
> I agree with Mike and think that merging forward is so super simple, i must<br>
> admit i had issues to understand this strategy from the beginning but now i<br>
> could do that even with closed eyes.<br>
<br>
</span>The problem, as has become very clear in the past few days, is that merging<br>
forward does not give us the confidence (or ability) to track where exactly<br>
a change has been applied. All it tells us is what commit hashes exist on a<br>
branch, which is not the same thing. You can record a commit hash as merged<br>
without bringing its changes forward, which is a necessary step in fixing<br>
merge-forward mistakes. The best way to see if a specific change exists on<br>
a given branch, whether we're cherry-picking or we're merging forward, as I<br>
understand it, is to use 'git cherry'.<br>
<br>
<br></div></div><span>______________________________<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></span></blockquote></div><br></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>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>