[Pulp-dev] Merging forward commits

[Brian Bouterse]

Thanks for putting this together. I put several comments on the PR, but I
want to share some thoughts via the mailing list:

Who will do the cherry pick and when? We should consider that rather than
having each developer perform the cherry picks, having one person do them
say on a weekly basis. This can be a rotating role. I think this would be
good for several reasons. (1) It's less overhead when merging fixes; once
its merged to master the developer is done. (2) Less will fall through the
cracks by having them all done at one time. (3) More consistency by having
them done in batches because when you do something a few times you get
better at it. I think this approach would address some of the items in the
Drawbacks section of the PUP.

How will we track cherry picks? For this we want something that will work
for release engineers releasing Pulp, something that works for all of the
redmine automation we have, and something that works for QE which has
pulp-smash skip issues by version. If we could do something that would work
with the existing processes that would be ideal. To that end, when a cherry
pick from master to the previous devel branch (e.g. 2.13-dev) occurs the
'Platform Release' field could be set to 2.13.next which is basically our
current process. In terms of tracking the cherry pick commit I think using
the `-x` option while cherry picking and adding a `cherry-pick #1234` to
the cherry picked issue number would cause the commit to be associated with
the redmine issue and make it clear that it is a cherry pick. If we do all
^ I think the cherry picks would be adequately tracked.

Lastly, I think if a cherry pick does not apply cleanly we should not
cherry pick it unless there is an exceptional reason that the previous
z-stream we are cherry picking into must have that bugfix. In other words,
if it picks cleanly do it, otherwise don't worry about it. Users will
receive the fix in the next y stream anyway. Generally I think releasing a
bugfix in a z-stream is not worth reimplementing or modifying the fix given
that it is available in the very next y release which releases roughly
every 12 weeks.

Other ideas/thoughts/suggestions/questions welcome!

Thanks @daviddavis for putting this effort together.

-Brian


On Tue, Apr 11, 2017 at 4:38 PM, David Davis <daviddavis at redhat.com> wrote:

> I’ve been working on the PUP for cherry-picking changes across our
> branches and I’ve opened a PR. Feedback would be much appreciated.
>
> https://github.com/pulp/pups/pull/3
>
> Also, I wanted to mention that it might be worth discussing how we can
> improve our merge forward process even if we don’t want to use
> cherry-picking instead. We’ve seen a couple accidental merges and I was
> wondering if there might be some way to prevent that? Two options I can
> think of. First maybe we could merge forward less often? I’m not sure how
> to time this. Secondly, perhaps we could use code reviews/PRs to confirm
> merges?
>
> Thanks.
>
> David
>
> On Tue, Mar 21, 2017 at 4:08 PM, Brian Bouterse <bbouters at redhat.com>
> wrote:
>
>> I would really like to collaborate on this. First one to start it; let
>> the other know.
>>
>> On Tue, Mar 21, 2017 at 3:18 PM, David Davis <daviddavis at redhat.com>
>> wrote:
>>
>>> So I was planning on doing that actually. Although, if you have the
>>> spare cycles, go for it.
>>>
>>>
>>> David
>>>
>>> On Tue, Mar 21, 2017 at 2:49 PM, Brian Bouterse <bbouters at redhat.com>
>>> wrote:
>>>
>>>>  I plan to turn this thread into a formal RFC once that process has
>>>> been ratified.
>>>>
>>>> On Tue, Mar 21, 2017 at 11:13 AM, Sean Myers <sean.myers at redhat.com>
>>>> wrote:
>>>>
>>>>> On 02/06/2017 12:09 PM, Ina Panova wrote:
>>>>> > Seems like we are trying to choose/figure out what's more important -
>>>>> > linear commit history which is readable or confidence and ability to
>>>>> track
>>>>> > where exactly change had been applied?
>>>>> >
>>>>> > I agree with Mike and think that merging forward is so super simple,
>>>>> i must
>>>>> > admit i had issues to understand this strategy from the beginning
>>>>> but now i
>>>>> > could do that even with closed eyes.
>>>>>
>>>>> The problem, as has become very clear in the past few days, is that
>>>>> merging
>>>>> forward does not give us the confidence (or ability) to track where
>>>>> exactly
>>>>> a change has been applied. All it tells us is what commit hashes exist
>>>>> on a
>>>>> branch, which is not the same thing. You can record a commit hash as
>>>>> merged
>>>>> without bringing its changes forward, which is a necessary step in
>>>>> fixing
>>>>> merge-forward mistakes. The best way to see if a specific change
>>>>> exists on
>>>>> a given branch, whether we're cherry-picking or we're merging forward,
>>>>> as I
>>>>> understand it, is to use 'git cherry'.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170414/87dc33e5/attachment.htm>