As a non-core, I would like to understand the process by which core prioritizes Gerrit changes. I'd also like to know any specific criteria used for approval. If such a process was transparent and followed consistently, wouldn't that eliminate the need for "Hey core, can you review <change>?" in IRC? Specifically:
* Is a prioritized queue used such as the one found at http://status.openstack.org/reviews/? (This output comes from a project called ReviewDay<https://github.com/openstack-infra/reviewday> and it is prioritized based on the Launchpad ticket and age: http://git.io/h3QULg.) If not, how do you keep a Gerrit change from "starving?" * Is there a baking period? In other words, is there a minimum amount of time that has to elapse before even being considered for approval? * What effect do -1 code reviews have on the chances of approval (or even looking at the change)? Sometimes, -1 code reviews seem to be given in a cavalier manner. In my mind, -1 code reviewers have a duty to respond to follow-up questions by the author. Changes not tainted with a -1 simply have a greater chance of getting looked at. * To harp on this again: Isn't "Hey core, can you review <change>?" inherently unfair assuming that there is a process by which a Gerrit change would normally be prioritized and reviewed in an orderly fashion? * Are there specific actions that non-cores can take to assist in the orderly and timely approval of Gerrit changes? (e.g. don't give a -1 code review on a multiple +1'ed Gerrit change when it's a nice-to-have and don't leave a -1 and then vanish)? Any clarification of the process would be greatly appreciated. Thanks, Mat
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
