-----Original Message----- From: Jeremy Stanley [mailto:fungi@yuggoth.org] Sent: Monday, February 25, 2019 1:26 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
On 2019-02-25 18:10:38 +0000 (+0000), Penney, Don wrote: [...]
I read the "procedural -2", as well, but it didn't seem applicable here. This section seems to describe a "code freeze", which is not the case here.
The description of a "workflow -1" seems to align more with what it sounds like the intent of the -2s were. https://docs.openstack.org/project-team-guide/review-the-openstack- way .html#workflow-1
The description of a procedural -2 there fails to convey that they're used for a lot more in OpenStack besides just deferring changes until after a code freeze. They tend to get used for any sort of "not now" deferrals which the core reviewers want to remain "sticky" in the face of new patch uploads on the same change. For example, they're commonly applied to block approval of changes are associated with a spec which has been postponed to a subsequent development cycle.
Workflow -1 does certainly have some similar connotations, but is more ephemeral and also (primarily) used to simply indicate that a change is a work in progress and so the current patch in it is not yet ready to be reviewed. It gets cleared when a new patch is pushed for the change, since the most common case is that the author expects the next patch to be ready for review. Workflow -1 is also capable of being applied by the change author, whereas a Code-Review -2 can only be applied by a core reviewer on the project. -- Jeremy Stanley
Ok, thanks for the clarification. Is there some other documentation of voting guidelines/implications that describe this, or is this an unwritten convention?