[Pulp-dev] PUP-3: Proposal to change our git workflow

Fri Jun 2 13:52:30 UTC 2017

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 <mhrivnak at 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 <daviddavis at 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 <pcreech at 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 at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
>
> --
>
> Michael Hrivnak
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170602/691015d1/attachment.htm>