2010/11/2 Trevor Parscal <tparscal(a)wikimedia.org>rg>:
An even in this case where I've reduced it to a
single tag, someone has
to actually mark revs with that tag, but the nature of the tag isn't
really based on any single revision, it's based on a resource.
I believe this is why Rob suggested using Bugzilla rather than
CodeReview for tracking this.
I agree that review and deployment are two parts of a whole and that
one doesn't make sense without the other, but I don't think that, of
the two, deployment is necessarily the defining part. Sure, it's the
ultimate goal, but the review part is where all the work is. Also,
having one person review something and another deploy it (typically
because the former is not a deployer) is a very small hurdle. The
reviewer and primary author would be expected to be around to help put
out any fires and possibly to explain how to deploy the feature, but
the latter doesn't take longer than a few minutes in most cases. So in
practice, I think it's more accurate to say that deployment is a
by-product of review than the other way around. *Conceptually*, the
latter is true, but *workload-wise*, the former is.
As to Rob's suggestion of a need-enabled tag: I don't think that makes
any sense. We don't deploy something, then leave it disabled on all
wikis, we always enable it somewhere (granted, we sometimes do dark
launches or launches on test.wp.o only, but that's always an immediate
preparation for enabling it for real). Our current procedure of
enabling a feature on a certain set of wikis (possibly all) upon
deployment and have requests to extend that set go through the shell
request procedure works just fine IMO.
Roan Kattouw (Catrope)