Add job to auto-rebase patches that are ready to be merged
Description
relates to
Activity

Tal Nisan June 3, 2018 at 1:44 PM
How can I elaborate on the need? I never asked for it nor though it's needed
Most of the time a rebase is not needed at all and we're good the way it is, you can close the ticket.

Eyal Edri June 3, 2018 at 12:53 PM
is this still needed? I didn't see any issues during 4.2 development which required an additional flow other than existing change queue.
If so, can you elaborate more on the need, maybe as a user story so we'll understand the problem at hand.

Barak Korren April 4, 2017 at 10:47 AM
To run OST, you need to automatically come up with a proper merging order, and then emulate the sequence of merges. Then you need to also build the artifacts, and only then you can start considering running OST. And you need to do all this for engine, vdsm, and probably other projects as well.
And when OST fails, you also want to narrow down the failure to the specific patch that caused it.
This is what we call "gating" or "patch-queueing" our currently ongoing "package gating" or "change queue" work () is a necessary predecessor to that.

Yaniv Kaul April 4, 2017 at 9:34 AM
I think we need to see how many of those we have - and how many have CR+1 and V+1 and can go through the same process as well - on lower priority (say, on 3AM in the morning).
What about running o-s-t on the first batch?
Details
Assignee
infrainfraReporter
Eyal EdriEyal EdriPriority
Low
Details
Details
Assignee

Reporter

We want to help stable branch maintainers to minimize the time needed for merging approved changes ( i.e CR +2 and VERIFY +1 ) and also to reduce the chance of merge conflicts.
A suggestion was made to create a job which will detect patches ready to be merged with the flags CR +2 and V +1 set and will auto rebase them, so when a maintainer is ready to submit a patch, hopefully the patch won't need a rebase and can be merged without further waiting for rebase or CI.
This approach might introduce challenges when working on patches that are dependent on other patches and a specific logic might be required to handle special cases.
I hope this conveys the need and requirement, please comment or add thoughts if I missed anything.
Initially we'll try enabling it for ovirt-engine on 4.1 branch.