Roan Kattouw wrote:
2010/10/16 Alex <mrzmanwiki(a)gmail.com>om>:
Why does this need some elaborate plan that will
take multiple months to
implement? The infrastructure for actually doing code review is already
there; it just needs someone to actually do it.
I didn't mean to suggest an elaborate plan needs to be concocted, nor
that /implementing/ it would take months. Executing it most probably
would, though. By way of example, my "plan" is give below. It's mostly
obvious stuff, but I see how people might disagree on the order or
timing of things, which is why I think there should be (some)
discussion before settling down on something. I didn't really want to
put this in this thread because I think that discussion deserves its
own, but here it is anyway:
1. Catch up with the code review backlog (about 1,200 revs currently).
I expect this to be entirely uncontroversial, and this can be (and is
being) done while we argue about the rest
2. When trunk is fully reviewed and we feel it's probably stable,
release 1.17.0beta1 and deploy it on Wikimedia
3. Fix the numerous bugs that will inevitably rear their ugly heads
when 8 months' (or more) worth of code is deployed
4. Once deployment stabilizes, rebranch from trunk (picking up trunk
changes since the last deployment that weren't specifically aimed at
fixing the site), release and deploy that.
5. Repeat 2-4 until we feel comfortable releasing the currently
deployed code as 1.17.0
6. From there on out, do weekly deployments of trunk
This sounds fine. I don't think anyone would have a problem with this.
The question becomes: how is this plan going to be implemented? Right now,
from my perspective, there's a huge single point of failure in code
deployment. Namely, that only one person is able to do it for regular,
general code updates (that is, others have the technical ability to do
updates, but only for specific revisions and under specific circumstances).
Having a plan is great and it sounds like a completely reasonable plan, but
currently only Tim is able to do general code updates and he's not really
around, from what I understand. And even when he is around, there's more
code than there is time and other resources. This makes backlogs like the
current one completely inevitable. There are a few solutions to this
problem; can one of them be implemented?
MZMcBride
P.S. Congrats on your blog fame, or something. :-)