[Pulp-dev] Cherry pick processor
rchan at redhat.com
Fri Jul 10 19:21:04 UTC 2020
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?
Satellite Software Engineering Manager - Pulp
Red Hat <https://www.redhat.com>
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> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev