|Summary:||need option 'cherry-pick to release-x.y' in reviews|
|Product:||[Community] GlusterFS||Reporter:||Amar Tumballi <atumball>|
|Component:||project-infrastructure||Assignee:||Deepshikha khandelwal <dkhandel>|
|Status:||CLOSED UPSTREAM||QA Contact:|
|Version:||mainline||CC:||amukherj, bugs, dkhandel, gluster-infra, jeff, srangana|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2020-03-12 12:54:57 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Amar Tumballi 2018-04-05 12:35:51 UTC
# Description of problem: Today, below is the process to send a patch to release branch: * clone the bug in relevant branch * author has to submit the patches once they land in master, with this new bug id (or same issue, if its RFE), * Make sure 'Change-Id:' is same. * Push the patch to release branch. This is not so simple for someone who is not so regular contributor to gluster project, and also a waste of time for everyone as all-most all of it can be automated. Idea is to have a review command called 'cherry-pick to $branch-name', which triggers a job, which clones the bug from the patchset, and takes the new bug, and will make sure the new bug is updated in release branch after applying the patch on top of release branch. There are possibilities of failure. It is OK for failure in case of merge conflict, but still it will save time for user because the bug can be automatically cloned. Expectation is that, (if possible) new bug id gets posted to patchset as result of the command. On success the URL of new patch.
Comment 1 Nigel Babu 2018-10-08 02:55:59 UTC
Comment 3 Amar Tumballi 2019-07-16 04:59:33 UTC
I remember seeing some efforts on this. Is this done?
Comment 4 Deepshikha khandelwal 2019-07-16 05:59:00 UTC
No. Jenkins part of automation is pending. I'll pick this up next week.
Comment 5 Worker Ant 2020-03-12 12:54:57 UTC
This bug is moved to https://github.com/gluster/project-infrastructure/issues/37, and will be tracked there from now on. Visit GitHub issues URL for further details