[openstack-dev] Multiple patches in one review
rbryant at redhat.com
Mon Mar 24 14:49:14 UTC 2014
On 03/24/2014 10:31 AM, John Dennis wrote:
> When a change is complex good practice is to break the change into a
> series of smaller individual patches that show the individual
> incremental steps needed to get to the final goal. When partitioned into
> small steps each change is easier to review and hopefully illustrates
> the progression.
> In most cases such a series of patches are interdependent and order
> dependent, jenkins cannot run tests on any patch unless the previous
> patch has been applied.
> I was under the impression gerrit review supported multiple commits. In
> fact you can submit multiple commits with a single "git review" command.
> But from that point forward it appears as if each commit is handled
> independently rather than being an ordered list of commits that are
> grouped together sharing a single review where their relationship is
> explicit. Also the jenkins tests either needs to apply all the commits
> in sequence and run the test or it needs to run the test after applying
> the next commit in the sequence.
> Can someone provide some explanation on how to handle this situation?
> Or perhaps I'm just not understanding how the tools work when multiple
> commits are submitted.
Gerrit support for a patch series could certainly be better.
When you push a series of dependent changes, each commit has its own
review, but the dependencies between them are still tracked.
As an example, take a look at this series of patches:
Take a look at this patch from the middle:
There is a "Dependencies" section above the list of patch versions.
That's where you see the patches linked together. Our other tools that
do testing and merging of changes respect these dependencies. Changes
will only be tested with the other changes they depend on. They will
also only be merged once all changes they depend on have been merged.
More information about the OpenStack-dev