[
https://ovirt-jira.atlassian.net/browse/OVIRT-1295?page=com.atlassian.jir...
]
Barak Korren commented on OVIRT-1295:
-------------------------------------
[~ykaul] 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 (OVIRT-1077) is a
necessary predecessor to that.
Add job to auto-rebase patches that are ready to be merged
-----------------------------------------------------------
Key: OVIRT-1295
URL:
https://ovirt-jira.atlassian.net/browse/OVIRT-1295
Project: oVirt - virtualization made easy
Issue Type: Improvement
Reporter: eyal edri [Administrator]
Assignee: infra
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.
[~tnisan(a)redhat.com][~ykaul][~dfediuck] 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.
--
This message was sent by Atlassian JIRA
(v1000.870.5#100039)