Chad wrote: > On Tue, Nov 2, 2010 at 7:39 PM, MZMcBride <z...@mzmcbride.com> wrote: >> Rob Lanphier wrote: >>> 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 >> >> I have a few comments. >> >> You're chomping at the edges again, but not focusing on the larger issue. >> It's still about _WHO_ is going to be deploying these extensions (or doing >> general code updates). That question is still unresolved and it's at the >> heart of the problem. By focusing on the periphery, you're simply needlessly >> adding paperwork (like the new "Deployment queue") without actually >> accomplishing anything. Read on for a specific example of why deployment is >> sometimes the sole issue, not review. >> > > +1. I feel like we're trying to change a workflow when we should be > trying to get rid of a backlog. Instead of trying to discuss ways to > improve the workflow, we should Just Do It.
Maybe have some kind of queue so that the change is an accept click? (That could be done inside subversion or in a completely different way) Currently, there's no way to make the requests easier, even if knowing the exact line to change (eg. a wiki logo, a boolean...) We could provide a patch, but applying it is a bigger hassle than the shell user doing the change himself. > Likewise, I think we should first focus on enabling more people to > do merge+scap (maybe the same group who review code?) and > get it going on a more often basis. > > Having a good workflow is great, but I think we should look at the > bigger issue first. We can design the best workflow ever, but like > code review if only one person does it it all falls apart. Maybe. Having more scappers in general would be good. Most configuration changes could be resolved pretty much by anyone. However note that whoever does that also needs the resources to identify when a change has produced a big load and should be reverted. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
