<div dir="ltr">+1 <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 6, 2017 at 12:09 PM, Ina Panova <span dir="ltr"><<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@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>Seems like we are trying to choose/figure out what's more important - linear commit history which is readable or confidence and ability to track where exactly change had been applied?<br><br></div>I agree with Mike and think that merging forward is so super simple, i must admit i had issues to understand this strategy from the beginning but now i could do that even with closed eyes.<br></div><br></div>+1 of writing down the benefits of cherry-picking and clear our expectations.<br></div><div class="gmail_extra"><br clear="all"><div><div class="m_-6707496601120723518gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Thu, Feb 2, 2017 at 6:50 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"><div>I think the merging forward seems pretty straightforward as well (with some exceptions) but one of the my concerns is expecting community contributors to know our process, the last release branch, etc when they open a PR. Maybe this isn’t something to worry about though if we don’t have enough contributions from outside the core Pulp team.</div><div><br></div><div>Another one of my concerns is the git history being cluttered by merging forward every time we commit a bug fix or hot fix (see my original email). Thinking through this a bit though, what if we merged forward commits less often? One option might be to only merge forward when we do a release.</div><div><br></div><div>Also, I like the idea of creating a proposal and trying out cherrypicking to see what the benefits would be and if we actually meet those benefits by cherrypicking.</div></div><div class="gmail_extra"><span class="m_-6707496601120723518HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_-6707496601120723518m_5597617060877159522gmail_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_-6707496601120723518h5">
<br><div class="gmail_quote">On Thu, Feb 2, 2017 at 10:46 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">This comes up periodically, and we've had split opinions for a long time. I've been in the camp that likes merging, and finds it intuitive. But I'm open to trying cherry-picking since there is a lot of interest.<div><br></div><div>I must admit, I am always surprised when people describe merging forward as complicated. For me, it boils down to this:<div><br></div><div>- Features happen on master. No merging or cherry-picking required.</div><div>- Bug fixes happen on the last release branch. Merge your bugfix branch to master and the release branch. Simple.</div><div>- Hotfixes are a rare exception that require slightly more thought, but are still easy to reason about. If in doubt, "git merge-base [list all the places you want to merge your fix]" tells you where to branch from.</div><div><br></div><div>That's the extent of my thought process when merging forward. I am generally interested to know more about how this process causes friction.</div><div><br></div><div>But all of that said, I'm very happy to give cherry-picking a try. As Brian said, my main concern would just be tracking where a change has been applied. This is something I value a lot in the merge model.</div><div><br></div><div>If we do switch, I think we should first write down specifically what benefits we expect to get. That would help in two ways: 1) Make sure everyone is on the same page about what we expect to gain. I suspect there are differing assumptions across the group. 2) Enable us to evaluate afterward to what extent the change was successful.</div></div><div><br></div><div>Lastly, our current branching model was inspired by this classic approach:</div><div><br></div><div><a href="http://nvie.com/posts/a-successful-git-branching-model/" target="_blank">http://nvie.com/posts/a-succes<wbr>sful-git-branching-model/</a><br></div><div><br></div><div>If you're not familiar, it's worth a read for perspective. Their "develop" branch is our "master". And obviously we don't do things in quite the same way, but the general principles are the same. </div><span class="m_-6707496601120723518m_5597617060877159522HOEnZb"><font color="#888888"><div><br></div><div>Michael</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-6707496601120723518m_5597617060877159522h5">On Thu, Feb 2, 2017 at 3:34 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@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_-6707496601120723518m_5597617060877159522h5"><div dir="ltr">The main concern for me is how to track the cherry picks in Redmine. Using the rebase and merge approach, or if Github had a dedicate cherry pick feature, we still need a way in Redmine to know if any given bugfix has been applied to older release streams, i.e. the current bugfix release stream.<br></div><div class="m_-6707496601120723518m_5597617060877159522m_7969133177755932499HOEnZb"><div class="m_-6707496601120723518m_5597617060877159522m_7969133177755932499h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 12:18 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@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="m_-6707496601120723518m_5597617060877159522m_7969133177755932499m_2115378570480106751m_-8007586272740299892gmail-ajy">> <img class="m_-6707496601120723518m_5597617060877159522m_7969133177755932499m_2115378570480106751m_-8007586272740299892gmail-ajz" id="m_-6707496601120723518m_5597617060877159522m_7969133177755932499m_2115378570480106751m_-8007586272740299892gmail-:t6" src="https://mail.google.com/mail/u/1/images/cleardot.gif" alt="">Thinking out loud, it would be nice if github would support a "cherry pick" PR<br><br></div><div class="m_-6707496601120723518m_5597617060877159522m_7969133177755932499m_2115378570480106751m_-8007586272740299892gmail-ajy">I think you can. The submitter just needs to open a PR against some branch other than master, and the merger needs to select the <a href="https://github.com/blog/2243-rebase-and-merge-pull-requests" target="_blank">rebase and merge</a> GUI option.<br></div></div>
</blockquote></div><br></div>
</div></div><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>
<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">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></div>