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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
