<div dir="ltr"><div><div><div><div>Thanks for putting this together. I put several comments on the PR, but I want to share some thoughts via the mailing list:<br><br></div><div>Who will do the cherry pick and when? We should consider that rather than having each developer perform the cherry picks, having one person do them say on a weekly basis. This can be a rotating role. I think this would be good for several reasons. (1) It's less overhead when merging fixes; once its merged to master the developer is done. (2) Less will fall through the cracks by having them all done at one time. (3) More consistency by having them done in batches because when you do something a few times you get better at it. I think this approach would address some of the items in the Drawbacks section of the PUP.<br></div><div><br></div>How will we track cherry picks? For this we want something that will work for release engineers releasing Pulp, something that works for all of the redmine automation we have, and something that works for QE which has pulp-smash skip issues by version. If we could do something that would work with the existing processes that would be ideal. To that end, when a cherry pick from master to the previous devel branch (e.g. 2.13-dev) occurs the 'Platform Release' field could be set to 2.13.next which is basically our current process. In terms of tracking the cherry pick commit I think using the `-x` option while cherry picking and adding a `cherry-pick #1234` to the cherry picked issue number would cause the commit to be associated with the redmine issue and make it clear that it is a cherry pick. If we do all ^ I think the cherry picks would be adequately tracked.<br><br></div><div>Lastly, I think if a cherry pick does not apply cleanly we should not cherry pick it unless there is an exceptional reason that the previous z-stream we are cherry picking into must have that bugfix. In other words, if it picks cleanly do it, otherwise don't worry about it. Users will receive the fix in the next y stream anyway. Generally I think releasing a bugfix in a z-stream is not worth reimplementing or modifying the fix given that it is available in the very next y release which releases roughly every 12 weeks.<br></div><div><br></div>Other ideas/thoughts/suggestions/questions welcome!<br><br></div>Thanks @daviddavis for putting this effort together.<br><br></div>-Brian<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 4:38 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’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.<span class="HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_6240589329911569417m_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></font></span><div><div class="h5">
<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_6240589329911569417m_8458281304547527575m_-2183137898138994587HOEnZb"><div class="m_6240589329911569417m_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_6240589329911569417m_8458281304547527575m_-2183137898138994587m_-8088442529168775270HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_6240589329911569417m_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_6240589329911569417m_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_6240589329911569417m_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_6240589329911569417m_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></div></div>
</blockquote></div><br></div>