Chad wrote:
On Tue, Nov 2, 2010 at 7:39 PM, MZMcBride
<z(a)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.