Dan Prince <dpri...@redhat.com> writes: > ----- Original Message ----- >> From: "Michael Still" <mi...@stillhq.com> >> - commenting "recheck .*" >> - commenting "recheck migrations" > > With the growing interest in 3rd party testing systems would using 'recheck > turbo-hipster' make more sense here? > > I'm fine with 'recheck migrations' in addition for turbo-hipster but it would > make sense to align the recheck naming scheme with the title of the reviewer > for the 3rd party testing system.
This is the can of worms I was hoping we would not open. Or try to get them all back into the can and close it again is perhaps the better metaphor. I do not think that system-specific recheck commands will be actually that useful or important. As I mentioned, I understand the theoretical usefulness of being able to say "oops, I can tell this one system messed up, let's ask it to try again". But given that case is covered by asking all systems to recheck, it seems harmless to say "all systems to recheck". I just don't think that asking developers to learn a micro-language of commands left in gerrit comments is the best use of time. Maybe I'm wrong about that, but I was hoping we could try not creating it first to see if there's really a need. Dealing with the expected errors of a system first coming online doesn't, in my mind, demonstrate that need. If it turns out that asking programmers not to create a new language is futile, yes, I'd rather we have some predictability. Most third party CI systems have descriptive names, so rather than saying "recheck turbo-hipster", perhaps we should change turbo-hipster's display name to something related to "migrations". So _if_ we want to have system-specific recheck commands, then I think we should ask operators to make them in the form "recheck <systemname>", and that they output a brief sentence of help text to remind people of that in the report message in Gerrit. -Jim _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev