OpenStack Core Infrastructure

Bug #917593
Comment #7

Comment 7 for bug 917593

Revision history for this message

James E. Blair (corvus) wrote on 2012-01-18:

Your approach is technically sound. There's nothing stopping us from testing changes together as well, so we can even go one step further and say "This change requires pending devstack change FOO" and that would even allow the change to be merged after being tested with the change in devstack. But neither of these satisfies one of the goals of this project which is to ensure that trunk is always tested automatically and never broken. To have a system where a developer can opt-out of testing puts the rest of the development community at risk of developing on top of a broken trunk or having their changes erroneously rejected.

Until cross-project dependencies are codified in gerrit, we don't have a way of ensuring that two or more related changes are actually merged together. Even if we test them together in devstack, one of them could still fail other tests (eg, unit tests) and not be merged. When we merge a change without a corresponding change, the trunk is broken until that change is merged. It's possible there could be a flaw in the second change preventing it from being merged in a timely manner. There may not be anyone with approval authority for the second change (necessarily in a different project) to merge it in a reasonable time. An unrelated change in a third project may be merged before even the first change we're considering is merged that could cause the pending second change to fail to merge. In all these cases, and surely many more, one developer has broken the tree for all other developers for an undefined length of time.

I would rather this not be complicated. I'm looking forward to CPD support in gerrit. And I understand that what we have may not actually be tenable and that we have to implement something like your suggestion (or my enhancement of it). But so far, we've seen two problems, and they are very similar. In both cases we've (hopefully) been able to solve them by moving the closely related bits into a single project. By having a sample config file in nova that's actually _used_ by devstack in testing is an improvement to the documentation of the nova project itself. Moving duplicate information out of devstack in turn makes it simpler. We may yet see a class of change that would cause us to do what you suggest, but so far, the obstacles we've encountered have actually led to improvements, so I'd like to continue to see how the system works as-is.

Your approach is technically sound.  There's nothing stopping us from testing changes together as well, so we can even go one step further and say "This change requires pending devstack change FOO" and that would even allow the change to be merged after being tested with the change in devstack.  But neither of these satisfies one of the goals of this project which is to ensure that trunk is always tested automatically and never broken.  To have a system where a developer can opt-out of testing puts the rest of the development community at risk of developing on top of a broken trunk or having their changes erroneously rejected.

Until cross-project dependencies are codified in gerrit, we don't have a way of ensuring that two or more related changes are actually merged together.  Even if we test them together in devstack, one of them could still fail other tests (eg, unit tests) and not be merged.  When we merge a change without a corresponding change, the trunk is broken until that change is merged.  It's possible there could be a flaw in the second change preventing it from being merged in a timely manner.  There may not be anyone with approval authority for the second change (necessarily in a different project) to merge it in a reasonable time.  An unrelated change in a third project may be merged before even the first change we're considering is merged that could cause the pending second change to fail to merge.  In all these cases, and surely many more, one developer has broken the tree for all other developers for an undefined length of time.

I would rather this not be complicated.  I'm looking forward to CPD support in gerrit.  And I understand that what we have may not actually be tenable and that we have to implement something like your suggestion (or my enhancement of it).  But so far, we've seen two problems, and they are very similar.  In both cases we've (hopefully) been able to solve them by moving the closely related bits into a single project.  By having a sample config file in nova that's actually _used_ by devstack in testing is an improvement to the documentation of the nova project itself.  Moving duplicate information out of devstack in turn makes it simpler.  We may yet see a class of change that would cause us to do what you suggest, but so far, the obstacles we've encountered have actually led to improvements, so I'd like to continue to see how the system works as-is.