[Pulp-dev] Merging forward commits

Wed Apr 19 15:28:10 UTC 2017

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/20170419/b5093450/attachment.htm>