On Mon, May 2, 2011 at 2:41 AM, Tim Starling <tstarling(a)wikimedia.org> wrote:
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.
I understand, respect, and value the contributions of people who want to
add new features. Features are what moves the product forward, and at
no point do we want to be hostile to people willing to put in their time and
effort to add functionality.
Given that our patch review process isn't fantastic, I really don't think it
would affect the majority of bugs anyway. Mainly affected would be
people with core access who write a new feature without putting it
through BZ first. Given that our core group is relatively small, I figured
we could come to some sort of consensus, if we do indeed move forward
with this.
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.
I don't know what our development community wants. I just happened to
think it was a good idea and so brought it up for discussion. If we
collectively decide I'm nuts, we can toss this proposal, I won't be upset.
I know we'd need to keep development on a very strict timeframe, which
is why I outlined a more strict branching and timeline to stick to. As Roan
and others pointed out, 6 months is a little long. I don't think we couldn't
decide on a branch point and stick to it, especially if we're not holding up
a branch for someone to finish sorting out a rewrite or major feature they
didn't quite resolve.
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.
I agree it's not our strength, but I don't think we can't do it. I
think sticking
to a firm branch date would largely alleviate this issue. I remain convinced
that a stability-focused release would be a good idea at some point, whether
we do it now or in a year.
-Chad