That's correct, we need not to forget to set the new branch as protected.
-------- Regards, Ina Panova Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On Fri, Jun 2, 2017 at 3:52 PM, David Davis <davidda...@redhat.com> wrote: > 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
