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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
