Open Stack

On 2014-03-24 09:31, 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.

I should point out that Jenkins can't apply the next patch in sequence
just to get tests passing.  What happens if the next patch never merges
or has to be reverted?  Each commit needs to be able to pass tests using
only the previous commits in the sequence.  If it relies on a subsequent
commit then either the commits need to be reordered or, if there's a
circular dependency, maybe those commits aren't logically separate and
should just be squashed together.

> 
> 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.