On Mon, May 2, 2011 at 2:41 AM, Tim Starling tstarling@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