David Gerard wrote:
On 7 July 2011 20:55, MZMcBride
<z(a)mzmcbride.com> wrote:
Tim has outlined on this mailing list why he
believes that more infrequent
releases are better, and his arguments are not necessarily invalid, I just
don't think they have any consensus behind them. I think Wikimedia and other
MediaWiki users would like a faster release process. But that's _completely
irrelevant_ when it's one person doing the work and putting together the
final release.
Are we talking about WMF deployments or tarballs here? Speaking as a
tarball user, 2 releases a year, maybe 3, is *just fine*.
As far as I'm aware, tarball releases and Wikimedia deployments have largely
shifted to being at approximately the same (slower) pace, but they're not
synchronized. But you're absolutely right that there's no need for that to
be the case.
I'm muddying the waters a bit by discussing both releases and deployments at
once, and for that I apologize. That said, they are obviously
interconnected. Ideally you want code (Wikimedia deployments) that has been
run in the wild for a while in order to catch issues that would never be
caught in development. That makes for a better tarball release.
In this case, you also largely have the same person filling both roles
(currently? I don't know). That is, Tim was the 1.17 release manager and he
was the point-person doing the 1.17 deployment, as far as I remember, at
least. As I said in my previous post, there have been some shifts in job
titles (cf. Erik's e-mail a few weeks ago), which I think correlate to some
shifts in job responsibilities, but that's still unclear to me.
For what it's worth, I agree that two or three tarball releases per year
would be fine, that just means getting Wikimedia deployments off of the same
schedule.
MZMcBride