<div dir="ltr">There are definitely additional options to improve the current process.<div><br></div><div>One way to prevent accidental merges is to just disable push to all branches except master. Merging to all other branches would happen via the "merge" button on a pull request. The normal workflow of merging to a x.y-dev branch and then to master would stay the same. For the less-common occasion when you need to merge stuff to more places, a quick PR is a small price to pay for seeing exactly what changes you're about to merge. I think we would not require review of such PRs.</div><div><br></div><div>We could also run a check before doing a push. For example, client-side push hooks could easily ensure that the changes being pushed are acceptable. When I experimented with this in the past, I focused on the idea of a "forbidden commit". When creating 2.14-dev, we would identify the next commit on master that is not part of 2.14, and that becomes the "forbidden commit" for the 2.14-dev branch. Any simple automation, hook or not, can check if an incoming push contains the forbidden commit, and reject it if so.</div><div><br class="gmail-Apple-interchange-newline">Another option is to use some other automation to do the merging and/or pushing for us, which is a common approach. That may be valuable with cherry-picking also. For example, maybe you can push a branch to your fork, but some other tool or service has to merge that into the main Pulp repo after validating it.<br></div><div><br></div><div>In any case, there are options. It's definitely in the spirit of the PUP process to explore all the options, so I'm glad we're having this discussion.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 1, 2017 at 3:36 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>Regarding improving our current git workflow, I do have a proposal on the PUP-3 as an alternative:</div><div><br></div><div><a href="https://github.com/daviddavis/pups/blob/54907337a9211671cd908327fe3ba9b7dd93e750/pup-0003.md#merge-forward-less-often" target="_blank">https://github.com/daviddavis/<wbr>pups/blob/<wbr>54907337a9211671cd908327fe3ba9<wbr>b7dd93e750/pup-0003.md#merge-<wbr>forward-less-often</a><br></div><div><br></div><div>In it, we’d merge forward less often (e.g. once a week?) and do so via PR. I think this solves one of the biggest problems we’ve seen with merging forward: mistakes. However, it has some issues:</div><div><br></div><div>1. Who will perform the merge forward and how often will they perform it?</div><div>2. The person performing the merge forward won’t have the specialized knowledge to merge forward all the commits and fix any merge conflicts. That said, they can work with the commit authors to do so and conflict resolutions can be checked in the merge forward PR.</div><div>3. Contributions (as raised by @ehelms and @bmbouter) still must go against x.y-dev branches</div><div><br></div><div>Maybe there are other alternatives as well?</div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_-9069540373633814291gmail_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></font></span><div class="gmail_quote"><div><div class="h5">On Thu, Jun 1, 2017 at 2:34 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="h5">On Thu, 2017-05-25 at 10:30 -0400, Patrick Creech wrote:<br>
> -1<br>
<br>
I'm changing my vote to -0 to better reflect my initial intention of expressing my dissent, but not<br>
blocking the passage of this outright; as I do not believe I have enough knowledge and experience in<br>
this argument to do such.  (I apologize for any frustration, I wasn't aware at the time my -1 would<br>
solely block this.  I should have RTFM'ed).<br>
<br>
To follow up, I want to re-summarize my dissent here.<br>
<br>
I don't know all the ins and outs of this argument, and decided to keep it this way to better<br>
analyze the argument with minimal prior knowledge.  This was to be able to come to this at voting<br>
time with fresh eyes, and have a layman's take.  This allowed me to take the public artifacts here<br>
at face value to understand why we are doing this, and what direction we're heading.<br>
<br>
Upon a naive initial searching of google, it appears that the general public sentiment is to not<br>
cherry-pick by default.  I don't doubt that some of these results aren't the most reliable, but the<br>
general sentiment is overwhelming.  To me, this meant that we need to have the reasons and benefits<br>
of moving to cherry-picking clearly spelled out as the obvious choice.  I didn't pick up on that<br>
sentiment from reading the e-mail chain and PUP.<br>
<br>
On the suggestion of improving our current merge forward process, that window is left open by others<br>
in the public record appearing to suggest this as a viable option.  If that is in fact an accurate<br>
representation, then to me that is the more preferable route as it sounds like improvements to our<br>
current course instead of charting a complete new one.  If this is not the case, then it probably<br>
should be stated clearly somewhere as to why it isn't a good option.<br>
<br></div></div><span class="">______________________________<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">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>