2010/11/2 Trevor Parscal tparscal@wikimedia.org:
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)