JB> * Dependent patch series are tested in the correct order (regardless of JB> the order in which individual patches are approved, and patches are JB> only queued for testing once all the patches ahead of them are JB> approved). This eliminated a huge amount of churn, as you can JB> imagine.
So, I'm not sure I'm seeing that exactly. I'm not entirely sure about the mechanics behind gerrit and how it interacts with my git history, but I see some patches later in the set going before the earlier ones. This looks like it might be the order in which gerrit first saw them in linear history (or something like that), but not the order in which git knows them to be dependent. If I was smart and could write everything in the right order the first time, then the orders would be the same, but since I'm not... :) I just verified this by looking at the zuul queue link you provided. I see in the check queue things in the following order: 11411, 11500, 11823, 11754, 11440, 11351, 11353, 11482 but according to git, those should be in this order: 11411, 11351, 11352, 11353, 11410, 11440, 11481, 11482 Not a huge deal, of course, but getting that ordering right is key to succeeding in the goal of not running dependent patches if their ancestors fail. Thanks! -- Dan Smith IBM Linux Technology Center -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp