[Pulp-dev] Cherry pick processor

[Tatiana Tereshchenko]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200714/e1226661/attachment.htm>