On 30/04/11 11:05, Chad wrote:
On Wed, Apr 27, 2011 at 12:43 PM, Chad
<innocentkiller(a)gmail.com> wrote:
Getting the merges reviewed [0] and making sure
we have a good set of
release notes. That's what I know of, and Reedy's been working on the
latter.
I've been thinking about this over the past few days, and I've got a proposed
release schedule and development roadmap to carry us through the rest of the
year.
As we all know, 1.17 is due to drop Real Soon Now. To summarize for those who
don't know the status: it's pretty much done. In talking with Roan, Tim and Sam
earlier this week, we discussed that we're pretty much ready to drop a
1.17beta1.
Maybe we can talk about this again tonight my time, if you're around.
Tim was concerned about the release notes, but as I
pointed out in my previous
e-mail, Sam's tidied this up (and it's low-hanging fruit if someone wants to
check behind us for sanity).
It would be nice if someone could write a user-oriented summary of the
major changes in the branch, like I did for 1.16. The 1.16 one was
used for the RELEASE-NOTES file, the mediawiki-announce email and the
blog post. The 1.17 one would probably be used in the same places.
Looking ahead to 1.19, I'd like to do the same and
branch soon after 1.18 has
been dropped. Since 1.19's a little further out and hasn't started taking shape
yet, I'd like to go ahead and propose what sort of release we should aim for.
Going back over the past couple of releases, we've had quite a few
"rewrites"
of major portions of code. While these are a necessary part of the process of
developing MW, they are difficult to review due to their complexity. This
complexity also makes it more likely for things to break. If I may be so bold,
I would like to ask that 1.19 not contain any of these rewrites. Let's focus on
making it a bugfix/cleanup release. Personally I think it would make for a very
clean and polished release, as well as reducing the time for us to review and
ship it.
The usual situation is that some developers are interested in features
and others are interested in bug fixes. If you declare that you only
want bug fixes, you risk losing the feature developers.
I think that the best way to retain feature developers is to treat
them with respect and to value their contributions. That is why I
haven't proposed a "feature freeze" in the past.
It would be possible to do a stability-oriented release if that's
really what the community wants, but it would have to be carefully
managed. We would have to increase our mentoring and review activity
in the development branches, and keep the schedule very tight indeed.
Given our past record, I'm not really confident that we can pull that
off. There's a risk of screwing it up badly and offending a lot of
people. Release management isn't exactly an organisational strength.
-- Tim Starling