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 <rc...@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 <bmbou...@redhat.com> > wrote: > >> >> >> On Fri, Jul 10, 2020 at 1:34 PM David Davis <davidda...@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@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev