Open Stack

On 2013-11-25 09:55:03 -0800 (-0800), Clint Byrum wrote:
> Excerpts from Monty Taylor's message of 2013-11-25 06:52:02 -0800:
[...]
> > recheck no bug still has a host of valid use cases. Often times
> > I use it when I upload a patch, it fails because of a thing
> > somewhere else, we fix that, and I need to recheck the patch
> > because it should work now.
> > 
> > It's also not nearly as dangerous as reverify no bug.
> > 
> 
> "...somewhere else, we fix that..." -- Would it be useful to track
> that in a bug? Would that help elastic-recheck work better if all
> the problems caused by a bug elsewhere were reported as bugs?

Most of these are just working around the current inability to
mechanically express change interdependencies between projects in
our tooling. You push related changes to multiple projects right now
and there may be only one sequence in which they can be successfully
applied but the result is that all changes besides the next one in
series are going to have negative check results until their turns
come. There's nothing stopping us from using an informational "bug"
to key them on, but creating one every time it's needed might also
come across as makework (or maybe we recheck them all on bug
1021879, but then I worry that would skew our statistics gathering).
-- 
Jeremy Stanley