[Pulp-dev] Cherry pick processor

[David Davis]

I'm not hearing any strong preference either way and if RPM finds it
useful, I'd propose we keep the cherry pick processor for now and
reevaluate again later. Thank you all for the feedback.

David


On Tue, Jul 14, 2020 at 10:18 AM Tatiana Tereshchenko <ttereshc at redhat.com>
wrote:

> In RPM plugin we use it quite happily.
> I guess it depends on the scale and the amount of PRs which might be
> problematic and create conflicts.
>
> I'm ok to cherry-pick manually, if it's decided for the cherry-pick
> processor to be retired. The load is not high at the moment.
>
> Tanya
>
> On Fri, Jul 10, 2020 at 9:24 PM Robin Chan <rchan at redhat.com> wrote:
>
>> I can't speak to the work delta between the existing processor and doing
>> them manually, but maybe we can initiate a conversation about this and
>> other challenges with cherry picking and building with the build team?
>>
>> Robin Chan
>>
>> She/Her/Hers
>>
>> Satellite Software Engineering Manager - Pulp
>>
>> Red Hat <https://www.redhat.com>
>>
>> IRC: rchan
>>
>> Red Hat respects your work life balance. Therefore there is no need to
>> answer this email out of your office hours.
>> <https://www.redhat.com>
>>
>>
>>
>> On Fri, Jul 10, 2020 at 2:48 PM Brian Bouterse <bmbouter at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Jul 10, 2020 at 1:34 PM David Davis <daviddavis at redhat.com>
>>> wrote:
>>>
>>>> As creator of the cherry pick processor, I'd like to propose we ditch
>>>> it. It requires a lot of upkeep which doesn't really save us time over just
>>>> doing the cherry picks ourselves. Also, it often fails because it cannot
>>>> make intelligent decisions when there are merge conflicts.
>>>>
>>>> Instead what I'd propose is that we do cherry picks at release time. We
>>>> do z-releases infrequently and they are usually for a particular
>>>> stakeholder so we usually know which issues the stakeholder needs and can
>>>> cherry pick these changes ourselves before we do a release. We can also
>>>> continue using the "Needs Cherry Pick" labels to help us remember issues we
>>>> want to include in a z-release later on.
>>>>
>>>> Overall, I think disabling it is the best path forward but I'm also
>>>> interested in any feedback people may have to improve the cherry pick
>>>> processor.
>>>>
>>> I agree with you. Also if we do keep something like this we probably
>>> should use one that is already made, e.g. gerritt.
>>> https://www.gerritcodereview.com/ +1 to for now retiring it.
>>>
>>>
>>>> David
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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/20200717/6b2ddaa3/attachment.htm>