[Starlingx-discuss] Python Based VBox Installer

[Penney, Don]

> -----Original Message-----
> From: Jeremy Stanley [mailto:fungi at yuggoth.org]
> Sent: Monday, February 25, 2019 1:26 PM
> To: starlingx-discuss at 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?