[Pulp-dev] PUP-3: Proposal to change our git workflow
ipanova at redhat.com
Fri Jun 2 14:21:09 UTC 2017
That's correct, we need not to forget to set the new branch as protected.
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 <daviddavis at 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.
> On Thu, Jun 1, 2017 at 4:36 PM, Michael Hrivnak <mhrivnak at redhat.com>
>> 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
>> On Thu, Jun 1, 2017 at 3:36 PM, David Davis <daviddavis at redhat.com>
>>> Regarding improving our current git workflow, I do have a proposal on
>>> the PUP-3 as an alternative:
>>> 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?
>>> On Thu, Jun 1, 2017 at 2:34 PM, Patrick Creech <pcreech at redhat.com>
>>>> 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 at redhat.com
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>> Michael Hrivnak
>> Principal Software Engineer, RHCE
>> Red Hat
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev