On 30/04/11 11:05, Chad wrote: > On Wed, Apr 27, 2011 at 12:43 PM, Chad <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
