On Mon, Jun 13, 2011 at 4:19 PM, Brion Vibber <brion(a)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