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 <[email protected]> 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 out: 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 production branch 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 there are 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 reviewer 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, but it hasn't been deployed yet. Owner: WMF reviewer 7. "need-enable" + "need-deploy" + "need-review" - there's an 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-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. 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 '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. 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 <[email protected]> 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 https://bugzilla.wikimedia.org/show_bug.cgi?id=20246 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? Rob _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
