[Pulp-dev] Merging forward commits

Wed May 3 17:54:19 UTC 2017

If there’s no major feedback on the PUP #3, I am going to tentatively
schedule a vote for it on Monday, May 8th.

Again, feel free to review the PUP and submit feedback before then. If it
warrants a major change to the PUP, I’ll postpone the vote.

Thanks again to everyone who has contributed.

David

On Mon, May 1, 2017 at 3:05 PM, David Davis <daviddavis at redhat.com> wrote:

> 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/20170503/0bce8974/attachment.htm>