Rob Lanphier wrote:
As noted, the biggest area for improvement is around the timing and release process. It wasn't all bad; we did (just barely) manage to keep the release cycle under one year. Still, that's much longer than our aspiration of quarterly releases, or even the previous historic norm of 2-3 releases per year. Moreover, it has been a long time since branching 1.17, so we already have seven months worth of work backed up for future releases. 1.18 was branched in early May, so in addition to the five months of changes we have backed up for that release, we already have two more months of changes backed up for 1.19.
[...]
The first issue is purely one of scoping. Right now, we're not terribly deliberate about what goes in and what is out. Part of the problem we have here is that opinions vary as to what a reasonable release interval is. The range of opinion seems to be anywhere from "multiple times a day" to "every six months". It's difficult to plan this without getting consensus on this point, and it's difficult to get consensus without first proving that we can get on top of the code review backlog and stay on top of it. If we go with a longer cycle, we can consider adopting a process similar to GNOME<ref>Example of GNOME release timeline: http://live.gnome.org/ThreePointOne</ref> or Ubuntu or other project that has a good track record for sticking with a regular releases. The most interesting practices there involve having clear deadlines for proposing new features, deadlines for features being done or pulled, and other date-risk mitigation strategies.
Thank you for writing all of this up. It looks like it probably took quite a bit of time, and I appreciate it.
I pulled out two paragraphs that seem to be the nuggets. Without having this thread devolve into another chase-your-tail thread, I'd say that the main issue is that the release manager for 1.17 has a much more conservative approach, and when looking at it from that lens, 1.17 was right on time.
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.
That, in a nutshell, seems to be the point of contention. The release (and deployment!) timelines are perfectly aligned with a conservative approach, but a lot of others (Brion, Neil, Chad, Roan, and in some ways Erik, among others) have recommended a less conservative approach ("perfect is the enemy of the done") that I believe would keep end-users and developers much happier.
There's been a recent change-up in Wikimedia staffing, so I don't know who will be managing the 1.18 release, but if it's the same person, my bet is that it's going to take the same amount of time. In my view, a few people (one?) see the longer release/deployment period as a feature, while the majority of people see it as a bug. :-)
MZMcBride