On Tue, May 31, 2011 at 3:20 PM, MZMcBride <z(a)mzmcbride.com> wrote:
Yes, it's incredibly frustrating to the point that
volunteer developers
have
walked away from MediaWiki code development. This is the "wiki project";
things are supposed to be fast! When someone makes a patch or a commit and
the best we can say is "it might get looked at this year with a fifty
percent confidence interval," that's not okay.
Code deployments to the live sites need to happen more often than
quarterly.
There are almost no benefits to such a long gap between deployments and the
detriments are clear.
Is there a problem with saying hell or high water, we won't go more than a
month without a deployment? I realize Wikimedia is a bit different, but
taking a page out of the rest of the business world's book, you set a
deadline and then it just fucking gets met. No excuses, no questions. The
problem seems to be finding anyone to lay down the damn law.
Sing it, brother! We're getting *some* stuff through quicker within the
deployment branches, but not nearly as much as we ought to.
Whatever the overall release branching frequency, there's also an update
cycle within that in getting fixes & independent features (usually
extensions) pushed out to the wild, and that's the cycle that's often most
important to users (because that's where their most immediate problems get
fixed) & developers (because users are where we get feedback).
Fixes need to be hitting production within days at longest, and more
features than just UploadWizard and ArticleFeedback should be able to make
it out on their own schedule without being forced to wait for a total
infrastructure update.
-- brion