<div dir="ltr">+1</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 29, 2017 at 10:08 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">+1<br><br>I believe the cherry picking approach will avoid merge-forward problems we've experienced, allow for less friction during community contribution, and create a more stable project overall.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 29, 2017 at 9:53 AM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@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">+1<br></div><div class="m_2809581961373163418HOEnZb"><div class="m_2809581961373163418h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 29, 2017 at 9:17 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">I went back and looked at PUP-3 and it does lay out some of the items @pcreech mentions although at a higher, more general level. I’ll leave the document as is unless someone disagrees. <div><br></div><div>With that in mind, let's go ahead and vote on PUP-3. We’ll end the voting on October 8th which is about 10 days away.</div><div><br></div><div>To refresh everyone’s memory, voting is outlined in PUP-1:</div><div><br></div><div><a href="https://github.com/pulp/pups/blob/master/pup-0001.md#voting" target="_blank">https://github.com/pulp/pups/b<wbr>lob/master/pup-0001.md#voting</a></div><div><br></div><div>And here’s the PUP in question:</div><div><br></div><div><a href="https://github.com/daviddavis/pups/blob/pup3/pup-0003.md" target="_blank">https://github.com/daviddavis/<wbr>pups/blob/pup3/pup-0003.md</a><br></div><div><br></div><div>Please respond to this thread with your vote or any comments/questions.</div></div><div class="gmail_extra"><span class="m_2809581961373163418m_8656971973996600873HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_2809581961373163418m_8656971973996600873m_1581227902940791321gmail_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_2809581961373163418m_8656971973996600873h5">
<br><div class="gmail_quote">On Thu, Sep 28, 2017 at 12:15 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><div><div><div>Thanks @pcreech for all the comments. I also believe that switching to a cherry-picking model will provide many benefits.<br><br>As a general FYI, the way PUP-3 is written, it allows us to adopt it (assuming it passes at vote) and then figure out how to roll it out later in coordination w/ release engineering.<br></div><br></div>@daviddavis, should we start casting votes or should we wait for you to declare it open after maybe pushing an update?<br><br></div>Thanks!<span class="m_2809581961373163418m_8656971973996600873m_1581227902940791321HOEnZb"><font color="#888888"><br></font></span></div><span class="m_2809581961373163418m_8656971973996600873m_1581227902940791321HOEnZb"><font color="#888888">Brian<br></font></span></div><div class="m_2809581961373163418m_8656971973996600873m_1581227902940791321HOEnZb"><div class="m_2809581961373163418m_8656971973996600873m_1581227902940791321h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 25, 2017 at 1: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">Patrick,<div><br></div><div>Thanks for the feedback. I’d like to update PUP-3 in the next couple days with the pain points you mention.</div><div><br></div><div>Also, I’d love the idea of having some tooling that tells us exactly which commits to cherry pick into which release branch. I think we should have this in place before we switch to cherry-picking if we decide to go that route.</div></div><div class="gmail_extra"><br clear="all"><div><div class="m_2809581961373163418m_8656971973996600873m_1581227902940791321m_-7488821757063697881m_-7304994264169025735gmail_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"><div><div class="m_2809581961373163418m_8656971973996600873m_1581227902940791321m_-7488821757063697881h5">On Fri, Sep 22, 2017 at 1:56 PM, Patrick Creech <span dir="ltr"><<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@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_2809581961373163418m_8656971973996600873m_1581227902940791321m_-7488821757063697881h5">Since I was one of the early voices against cherrypicking during the initial vote, I figured I'd send this e-mail along with some points that have helped me be in favor of cherry picking before voting<br>
starts.<br>
<br>
In taking over the release engineering process, I have gained some perspective on our current situation and have found Cherrypicking to be an enticing concept for pulp.  Most notably, these are the<br>
things I ran into during the release process for 2.13.4 that caused some headaches and frustrations.<br>
<br>
Firstly, we had an issue come up with the Pulp Docker 2 line that does not exist with the new Pulp Docker 3 line.  Dockerhub V2 Schema2 has some manifest issues that cause syncs in the Pulp Docker 2<br>
line to fail.  A change specific to this issue was created and merged to the 2.4-dev branch.  It's only application is the 2 line, but to satisfy our current tooling and policy, this change had to be<br>
merged forward through 3.0-dev and to Master, where it no longer applies and the code no longer exists in this form.  I took great care to verify that no code changes happened on 3.0-dev and master,<br>
but there is the window open for issues here.<br>
<br>
Another issue that happened is when issues that are merged from a -dev branch aren't merged forward.  In this case, two issues that landed on the most recent -dev branch weren't merged forward along<br>
to master before a helper script was ran.  When this helper script ran, it was ran with the merge strategy of "ours" to ensure it's changes don't persist forward.  When "ours" is used, conflicting<br>
changes are automatically dropped from the source branch to the destination branch.  This caused the code for these two changes to dissapear on the master branch, while their commit hashes were there<br>
in the history.  I had to cherry-pick these changes forward to master from the branch they landed on to ensure the modified code exists.<br>
<br>
And lastly, since 2.13.4 was a 2.13.z release that was done after 2.14.0 went out, changes had to be cherry-picked back from 2.14-dev to 2.13-dev.  Since the hash changed, these changes yet again had<br>
to be merged forward to 2.14-dev and then Master, even though they already existed in these branches, thus helping to pollute the repo history further with more duplication.<br>
<br>
While a large portion of these issues can be attributed to the merge forward everything policy, I have been in talks with other teams that follow a cherrypicking strategy about their workflow since<br>
I'm in the process of revamping pulp's release engineering process.  Something that caught my attention as beneficial is a team's strategy that everything goes on master, and with some automated<br>
tooling and bookeeping in their issue tracker they can identify what cherrypicks need to be pulled back to the release branch and spit out a command for the release engineer to run to do the<br>
cherrypicks.  The release engineer resolves any conflicts, and then puts up a PR to merge into the release branch so the work goes through the normal testing + review process.<br>
<br>
<br>
In short, at this point I have come to believe that switching to a cherry-pick model will allow us greater flexibility and accuracy in ensuring our releases contain what we want them to contain, and<br>
don't contain what we don't want.  With tooling, it should also help simplify ensuring the right things get put in the right places.<br></div></div>______________________________<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>
<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>
<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><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_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>