I like the first proposal of disabling pushes to all branches except master. It’s simple and effective. My only question is when we create a new branch, I’m guessing we’ll have to remember to set it to protected?
Also, I am going to extend voting for another week until June 12 9pm UTC to give us time to discuss alternatives. David On Thu, Jun 1, 2017 at 4:36 PM, Michael Hrivnak <mhriv...@redhat.com> wrote: > There are definitely additional options to improve the current process. > > 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. > > 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. > > 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. > > 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. > > On Thu, Jun 1, 2017 at 3:36 PM, David Davis <davidda...@redhat.com> wrote: > >> Regarding improving our current git workflow, I do have a proposal on the >> PUP-3 as an alternative: >> >> https://github.com/daviddavis/pups/blob/54907337a9211671cd90 >> 8327fe3ba9b7dd93e750/pup-0003.md#merge-forward-less-often >> >> 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: >> >> 1. Who will perform the merge forward and how often will they perform it? >> 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. >> 3. Contributions (as raised by @ehelms and @bmbouter) still must go >> against x.y-dev branches >> >> Maybe there are other alternatives as well? >> >> >> David >> >> On Thu, Jun 1, 2017 at 2:34 PM, Patrick Creech <pcre...@redhat.com> >> wrote: >> >>> On Thu, 2017-05-25 at 10:30 -0400, Patrick Creech wrote: >>> > -1 >>> >>> I'm changing my vote to -0 to better reflect my initial intention of >>> expressing my dissent, but not >>> blocking the passage of this outright; as I do not believe I have enough >>> knowledge and experience in >>> this argument to do such. (I apologize for any frustration, I wasn't >>> aware at the time my -1 would >>> solely block this. I should have RTFM'ed). >>> >>> To follow up, I want to re-summarize my dissent here. >>> >>> I don't know all the ins and outs of this argument, and decided to keep >>> it this way to better >>> analyze the argument with minimal prior knowledge. This was to be able >>> to come to this at voting >>> time with fresh eyes, and have a layman's take. This allowed me to take >>> the public artifacts here >>> at face value to understand why we are doing this, and what direction >>> we're heading. >>> >>> Upon a naive initial searching of google, it appears that the general >>> public sentiment is to not >>> cherry-pick by default. I don't doubt that some of these results aren't >>> the most reliable, but the >>> general sentiment is overwhelming. To me, this meant that we need to >>> have the reasons and benefits >>> of moving to cherry-picking clearly spelled out as the obvious choice. >>> I didn't pick up on that >>> sentiment from reading the e-mail chain and PUP. >>> >>> On the suggestion of improving our current merge forward process, that >>> window is left open by others >>> in the public record appearing to suggest this as a viable option. If >>> that is in fact an accurate >>> representation, then to me that is the more preferable route as it >>> sounds like improvements to our >>> current course instead of charting a complete new one. If this is not >>> the case, then it probably >>> should be stated clearly somewhere as to why it isn't a good option. >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
