Hi Trevor and Roan
Comments inline (Roan, my reply to you is way below)....
On Tue, Nov 2, 2010 at 10:34 AM, Trevor Parscal <tparscal(a)wikimedia.org> wrote:
The idea of dividing deploy and enable seems strange
to me. Only in the
case of a feature-flagged bit of core code or extension which has not
been deployed yet would this even work, in all other cases deployment is
enabling because you've just updated active code.
Perhaps "deploy" is a little too ambiguous, so I'm open to changes
there. Basically, there are three distinct stages that I'm picking
a. The act of reviewing code for suitability for any purpose (e.g.
shipping with MediaWiki tarballs)
b. The act of making an extension or modification available in the
c. The act of adding the bits of LocalSettings.php
(er...InitialiseSettings.php) for enabling on a particular wiki
I've named these "review", "deploy" and "enable", but if
better names, that's fine.
These three steps all have different operational ramifications, and
can exist independently of each other. While one combination doesn't
make sense, most have a sensible interpretation. Let's step through
the full list of combinations that can exist on an open bug (since
there are only eight of them):
0. no tags - probably no code, or incomplete code. Owner: any
developer who can code to completion
1. "need-review" - implementation exists, but probably only of
interest for MediaWiki tarballs. Owner: any reviewer
2. "need-deploy" - reviewed implementation exists, but only in trunk.
Needs to be published in deployment branch and scap'd, though there
may not be a particular wiki ready for the feature yet, or there's a
separate issue filed with the "need-enable" flag which spells out the
conf for a particular wiki. Owner: WMF reviewer
3. "need-review" + "need-deploy" - implementation exists, but needs
review prior to publication in the deployment branch. Owner: any
4. "need-enable" - reviewed implementation exists, is in deployment
branch, and has already been scap'd. Just needs to a nudge in the
configuration for a particular wiki. Owner: WMF Ops
5. "need-enable" + "need-review" - this is probably nonsense.
Probably needs all three tags.
6. "need-enable" + "need-deploy" - Reviewed implementation exists,
it hasn't been deployed yet. Owner: WMF reviewer
7. "need-enable" + "need-deploy" + "need-review" -
unreviewed implementation for a feature which is being requested for
deployment on a specific wiki. Owner: any reviewer.
Additionally, the idea of having a division between
need-deploy is counter to the arguments made in D.C. which were that
essentially review is a by-product of deployment, not the other way
around. Marking something as need-deploy shows reviewers what should be
reviewed and merged into the deployment branch.
Nope, not counter at all. It's very important for the sanity of those
trying to keep track (e.g. me) that we distinguish between the
deployment-bound stuff that hasn't been reviewed, and the
deployment-bound stuff that has been reviewed. I believe the
conversation in DC centered around the difference between state 1 and
state 3 above, where we agreed that we shouldn't worry about
optimizing the process for state 1. However, I don't think anyone can
make a convincing argument that the distinction between state 2 and
state 3 isn't important.
Code-review needs a way to tag files and directories
rather than just
revisions. These resource-tags would be persistent between revisions,
allowing us to say "show me 'new' revisions that affect
files and directories" or some such. This would likely be core + some
The more work we have to do over and over (such as adding and managing
tags on revisions) the less likely we are to keep it up.
I think it would be cool to have this feature, but I think we can
handle this in Bugzilla without new tools.
On Tue, Nov 2, 2010 at 12:40 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:
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.
I'll admit that part of the reason why I added "need-enable" is
because I had forgotten about "shell", so you're probably right;
"need-enable" is probably unnecessary.
However, it looks like our current workflow involves removing that
keyword whenever something needs review (see
for an example).
It seems to me that it is *way* too easy for a request to drop off the
radar if the person who reviews it drops the "need-deploy" flag or
"need-review" flag without adding the "shell" flag back in. Is there
a reasonably robust way of mitigating against that problem?