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

Fri Jun 2 14:21:09 UTC 2017

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 <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.
>
>
> 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
>>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170602/d62ba505/attachment.htm>