[Pulp-dev] Cherry pick processor
ttereshc at redhat.com
Tue Jul 14 14:17:27 UTC 2020
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.
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
> 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.
> On Fri, Jul 10, 2020 at 2:48 PM Brian Bouterse <bmbouter at redhat.com>
>> On Fri, Jul 10, 2020 at 1:34 PM David Davis <daviddavis at redhat.com>
>>> 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
>> 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.
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev