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

[Michael Hrivnak]

-0 for similar reasons to those already discussed.

We've identified alternatives that would address many of the concerns
listed in the Motivation section. To re-cap:

Merge mistakes: we have multiple options we could implement with the
merge-forward option.

Community PR rebasing: we can either use the new github feature to
auto-rebase, or take the same approach as the PUP (let the PR stay on
master) and just accept that some of those changes won't make it into a Z
release.

Merge conflict resolution: the PUP says this can lead to mistakes that go
unreviewed, but we've also heard feedback in this discussion that merging
forward is almost never a problem. My view is that on rare occasions a
merge conflict can get resolved incorrectly, but it's not a substantial
problem for us, and those cases should be easily caught with automated
testing. We will make mistakes that break master for lots of reasons, some
that even go unnoticed in review. We should strive to make those rare, but
also should have confidence that our testing will catch such problems and
enable us to quickly correct them. Our current guidelines do encourage
review for merge conflicts that are substantial:

http://docs.pulpproject.org/dev-guide/contributing/merging.html#merging-your-changes

We could make the language around that stronger, or even require review for
such cases.

All of that said, while I think we have ways to address nearly all the
PUP's concerns without changing to a cherry-pick model, I'm certainly
willing to try such a model. My preference would be to try some
less-drastic changes to our process first, and see how that goes. But I am
sure that we could be successful with a cherry-pick model, and given broad
interest am willing to try it.

I have only one big concern: "If the cherry-pick has conflicts, we should
abandon the cherry-pick and encourage users to upgrade to the next Y
release." I worry that this will have a big impact on our ability to
deliver bug fixes. As long as we retain some discretion to employ a small
amount of conflict resolution when reasonable, I think this could be a fine
guideline. But if we were to apply it as an absolute rule, it may affect
many more changes, and substantially slow down our ability to release fixes
early and often. For example, often when we see a conflict, it is with
import statements. It would be a shame to omit a fix from a Z release over
that.

On Fri, Jun 9, 2017 at 9:09 AM, David Davis <daviddavis at redhat.com> wrote:

> Just wanted to send out a reminder that voting is ending on Monday, June
> 12 at 9pm UTC. I haven’t seen much of a response around trying to adopt an
> alternative to PUP-3 that doesn’t involve cherry-picking so I am going to
> assume there isn’t much interest in doing so. Again, please respond with
> any thoughts or feel free to change your vote if that’s not the case.
> Thanks.
>
>
> David
>
> On Tue, Jun 6, 2017 at 4:59 PM, David Davis <daviddavis at redhat.com> wrote:
>
>> Talking with @bmbouter a little more about the PUP process and looking
>> back at PUP-1, I think that the only way for PUP-3 to not be accepted is if
>> a core developer were to cast/recast a -1 vote. I know there has been talk
>> about alternatives but looking at the votes, there is a consensus around
>> adopting PUP-3:
>>
>> +1 - 5 votes
>> +0 - 1 vote
>> -0 - 2 votes
>> -1 - 0 votes
>>
>> If anyone feels strongly about trying out an alternative or discussing
>> alternatives further, please recast your vote or respond with your
>> concerns. Otherwise, I think we'll proceed with approving/rejecting the PUP
>> based on the votes on the deadline of June 12th.
>>
>>
>> David
>>
>> On Tue, Jun 6, 2017 at 4:27 PM, David Davis <daviddavis at redhat.com>
>> wrote:
>>
>>> I have updated the proposal’s motivation section. Note that the actual
>>> change/workflow hasn’t changed at all.
>>>
>>>
>>> David
>>>
>>> On Tue, Jun 6, 2017 at 4:08 PM, David Davis <daviddavis at redhat.com>
>>> wrote:
>>>
>>>> Looks like @bmbouter made a comment to include this but I forgot to
>>>> include it:
>>>>
>>>> https://github.com/pulp/pups/pull/3#discussion_r111498031
>>>>
>>>> Will update the PUP.
>>>>
>>>>
>>>> David
>>>>
>>>> On Tue, Jun 6, 2017 at 3:48 PM, Michael Hrivnak <mhrivnak at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Tue, Jun 6, 2017 at 9:58 AM, Brian Bouterse <bbouters at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I think we need to redo the git workflow because we can't continue to
>>>>>> resolve conflicts during merge forward as we did before. I see that as the
>>>>>> central issue the PUP is resolving.
>>>>>
>>>>>
>>>>> The PUP likely needs additional revision in that case; it does not
>>>>> mention conflict resolution at all as a motivation. It would be valuable to
>>>>> spell that out and discuss it.
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Michael Hrivnak
>>>>>
>>>>> Principal Software Engineer, RHCE
>>>>>
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>
>>
>


-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170612/a98879ad/attachment.htm>