[Pulp-dev] Merging forward commits

Mon May 22 14:05:23 UTC 2017

Apologies for the delay in voting. We got in some feedback on PUP #3 that
has been addressed.

Will now be aiming for Wednesday, May 24 for voting. I’ll start a new email
thread with the guidelines on how to vote.

David

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

> 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/20170522/c0b6b4f0/attachment.htm>