David Gerard wrote:
On 7 July 2011 20:55, MZMcBride z@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