Details
-
Bug
-
Resolution: Out of scope
-
Not Evaluated
-
None
-
2011q3
-
None
Description
looking at the history of changes 12305 and 12308, it appears that the start of the integration phase resets the staging branch to the current head of the target branch instead of picking further commits on top of the head that started integrating. this is totally counterproductive, because a commit which diff-wise depends on changes which started integrating is impossible to stage until the integration succeeds.
arguably, in times when most integrations fail, this doesn't hurt too much, but that isn't a situation to optimize for.
when this is fixed, a failing integration needs to rebase the staging branch, which can lead to merge conflicts like unstaging individual changes does (though it may imply that all changes on top need to be unstaged as well, unless we are overly optimistic and unstage only changes which have a dependency on the unstaged change).
this isn't much different from the current situation, where a successfull integration requires a rebase - question is only which case is optimized for.
Attachments
Issue Links
- is replaced by
-
QTQAINFRA-818 integration starts should be delayed
- Closed