On Mon, Jun 13, 2011 at 4:19 PM, Brion Vibber <br...@pobox.com> wrote: > When we were prepping 1.17 for deployment the theory seemed to be that it'd > be out the door and *done* within a couple weeks and we'd be able to > concentrate on 1.18 from there out and keep up with everything.
Part of the problem was that we weren't doing a good job of minding this list: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.17 That was my fault for not specifically tracking that, but it was something that all of us who wanted to get 1.17 could have done. By "tracking", I mean looking out for superfluous additions to that list, and nixing them. Also, making sure that anything on that list was truly ready to go (e.g. proper release notes already written, reviews done, etc). We also found that people would attach bugs to the 1.17 release blocker just to get our attention. Even bugs that were clearly deployment-only got attached from time to time. For 1.18, I've at least added a new "pre-release preparation" section to this doc: http://www.mediawiki.org/wiki/Release_checklist#Pre-release_preparation Anyone interested in helping the 1.18 release process go faster can make sure that that list is correct, and by pitching in on anything necessary to get through that list more quickly. There's a number of things that I'll be talking to folks on my team about in order to make go smoother for 1.18, and there's a number of things that I'm planning to do differently myself. However, there's a wider commitment that's needed to make the 1.18 cycle significantly different from the 1.17 cycle. > Give us a deployment date for 1.18 and make it a top priority for > engineering. > > Give us a release date for 1.18 and make it a top priority for engineering. If releasing "1.18" becomes a top priority over anything that actually goes into it, then committing to a date is easy. We'll just rename "1.17" to "1.18" and call it good. :-) If, however, people care about the actual features that go in, and actually care about getting through the review queue and all of that, we need to establish how quickly we can do that in the first place. The 1.17 deployment only provides us with so much historical guidance. Trevor and Roan were pretty motivated to get Resource Loader out the door, and busted tail to get through the review queue much more quickly than we might have otherwise done. They sprinted through a big backlog, and when they were done, they were ready to move on to other stuff (and there was plenty more the org wanted them to do). We probably won't have the same level of dedication to the problem that they had last go around. We also need to figure out which things can afford to wait while we retool. My understanding of the Features team work is that the 20% tax is unaccounted for in the current model. I'll let Alolita speak to it, but I don't believe we've agreed to change any dates yet as a result of adding 20% time to the devs schedules. Even when we get 20% of everyone's time, that will help, but we're going to have to use that time more effectively than we have. I think it's more than just telling everyone to work harder. I think there's a fundamental problem with the way we accept and review code. Brion, you and I have spoken about this, but I don't think we've gotten to the heart of the matter. It's pretty clear that for most reviewers, they just haven't hit the sweet spot of speed necessary to deal with the velocity of commits we're getting, and completeness necessary for reviewers to feel good having their names associated with an "ok" mark (or comfortable reverting, or whatever). That may be a matter of training, it may be other things, but we've gotta figure that problem, too. We've proven we can sprint fast enough to make a dent in the backlog (e.g. late 2010), but we can't sustain that pace. Also, "releasing 1.18" isn't my top priority. Het Deploy[1] is higher on the list. I'm not willing to cut Het Deploy from this release just to make a date. We are going to have a more sane way of doing deployments before we deploy another major version of MediaWiki. I'm not budging on that one. We can set a goal, but in my experience, setting a date that engineers don't actually believe in is counterproductive. I'm personally not willing to set a date until we establish that we can go *a week* at the pace necessary to achieve anything like the goals we set out (e.g. July). At this point, I can set a date, but you probably won't like it (probably September-ish). I'd rather we show better results on the code review process first, and only then would I venture a more optimistic target. I wouldn't set the date without at least making sure that it passes the smell test with some key people here. Anyway, I don't want to be down on the idea that we should release more often. It should be possible for us to get the queue down, and keep it down with a concerted effort, and I think the concerted effort will be worth it. Rob [1] http://www.mediawiki.org/wiki/Heterogeneous_deployment _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
