[Pulp-dev] Merging forward commits

Mon May 1 19:05:17 UTC 2017

Thinking through this a bit, I am not sure having a roll for someone to do
cherry-picks makes sense. Features aren’t cherry-picked. Hotfixes are
generally made against release branches (unless I am mistaken) so having
someone have to hunt those changes down and get them to master seems
tedious. Seems like this should be left up to the person taking care of the
hot fix.

That leaves bug fixes and I think the person who merges the PR be
responsible to cherry-picking the commit.

Why don’t we leave out the cherry-pick role initially at least and then
decide if we need it. I also think this is less of a jarring change from
our current process and might ease the transition.

David

On Wed, Apr 19, 2017 at 11:28 AM, David Davis <daviddavis at redhat.com> wrote:

> Regarding who and when we’ll cherry-pick, that sounds good to me.
> Although, we’ll probably have to sync up schedules between when we
> cherry-pick and when we release I imagine. Or maybe the cherry-picker can
> work with whoever is doing the release to make sure the proper bug fixes
> get cherry-picked in before the release.
>
> Your proposals around how to track cherry-picks all sound good to me. I
> can update the PUP unless anyone is opposed.
>
> Regarding not cherry-picking stuff that doesn’t apply, I don’t have an
> opinion one way or the other. I think the best course of action would be to
> try it out and see if users are ok with it.
>
> One question I also wanted to bring up: when do we want to transition to
> this cherry-picking workflow? I think someone mentioned only cherry-picking
> for Pulp 3 but it seems like most of the people in the PUP PR think favor
> cherry-picking for both Pulp 2 and Pulp 3 once the proposal is accepted.
> Does anyone oppose that or have any thoughts?
>
>
> David
>
> On Fri, Apr 14, 2017 at 11:02 AM, Brian Bouterse <bbouters at redhat.com>
> wrote:
>
>> 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/20170501/5edc6993/attachment.htm>