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.
Additionally, the idea of having a division between need-review and
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.
So essentially all we need is a single queue or tag, which indicates
this is a revision that affects deployed/to-be-deployed software.
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.
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 'deployment'
files and directories" or some such. This would likely be core + some
extensions.
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.
- Trevor
On 11/2/10 9:51 AM, Rob Lanphier wrote:
Hi everyone,
One discussion we had at the Hack-a-ton was about the continued
frustration of getting features deployed to the WMF-operated sites.
Prior to Hack-a-ton, one short-term solution we started work on was
consolidating the review queue into a single place:
http://www.mediawiki.org/wiki/Review_queue
That page still needs some organization and a process around it to
make sure that we're actually looking at the page. However, our
discussion at Hack-a-ton made it clear that even if we have a
well-tuned process there, we still have features rolling off the end
of that conveyor belt onto the floor.
After review, some (but not all) of the features in the review queue
then need to be reviewed for checking into the deployment branch. Our
short term answer to that was the deployment queue:
http://www.mediawiki.org/wiki/Deployment_queue
Even then, we're still not done. We have one more step, which is
launching the feature on one or more wikis. We could also create
another queue page for that. However, given the complicated workflow
here, it seems that a wiki is the wrong tool to keep track of this.
My inclination at this point is to augment the list of keywords on
Bugzilla, and use
mediawiki.org to document the process, and as a
place to stash the magical queries to pull up the right lists.
We already have the "need-review" keyword. I suggest we add two more
keywords: "need-deploy" and "need-enabled". Then we add all three
keywords to feature requests that need to go through the whole process
before being deployed. For example, we'd add all three to this issue:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25454
We'd then pick off the keywords as we step through the process (e.g.
once it's reviewed, remove the "need-review" keyword). We could then
generate three queries to get us the three queues I alluded to above:
1. Issues with all three keywords. These are features that someone
would like to see deployed and launched, but needs to be reviewed
first.
2. Issues with "need-deploy" and "need-enabled". These are
extensions that have been reviewed, but need to be checked into the
production branch
3. Issues with "need-enabled" only. These are extensions/features
that just need action from ops.
Does this make sense? If so, I'll add the keywords and start
documenting the process and retrofitting existing feature requests
into this system.
Rob
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l