Code review and making it to 1.17

List overview All Threads
Download

newer

older

Improving the skinning system

Bugzilla Weekly Report

Rob Lanphier

4 Dec 2010 4 Dec '10

6:12 a.m.

Hi everyone, The code review team has been doing a fantastic job of clearing out the backlog, which you can see here: http://toolserver.org/~robla/crstats/crstats.html (uncheck "ok" on the checkboxes on the bottom to see new commits) There's some release planning issues that we have to sort out: 1. When will we branch 1.17? 2. When will we push 1.17wmf1 to production? 3. When will we release MediaWiki 1.17? Trevor and Roan believe that ResourceLoader will be ready to deploy in January. However, looking at the backlog of code reviews, and I don't think it's realistic to assume we'll have everything else ready in January. My assumption here is that we need to be through the code review backlog prior to pushing what is currently in trunk into production. Simply extrapolating from the October/November rate of code review, March is looking more like the target, and that assumes we keep up the rapid pace of review. What seems realistic without being complacent? One thing I think will help the rate of code review is for more developers to comment on commits more frequently. I know many of you already chime in on Code Review, which is great. If you can do your best job at providing a full code review (commenting rather than marking "ok"), that will hopefully catch some of the most immediate problems so that the code review team can focus on the more subtle issues and perhaps do a quicker review. Longer term, Roan has a new feature brewing to the Code Review system ("sign-offs") that will make it easier for you to provide some useful metadata for the code review team to use. With respect to MediaWiki 1.17 releases, I think we can actually release sooner after the first production deployment than we did after 1.16 if we pair our usual testing with some small amount formal QA and test automation (especially focusing on installer and a small amount of alternate DB testing [e.g. sqlite]) What seems realistic here? Longer term, everyone has stated a desire to move to more frequent deploys. I think that's a conversation worth having, but let's not have it as part of this thread. Thanks Rob

Show replies by date

K. Peachey

4 Dec 4 Dec

6:38 a.m.

On Sat, Dec 4, 2010 at 7:12 AM, Rob Lanphier <robla(a)wikimedia.org> wrote:

...

There's some release planning issues that we have to sort out: 1. When will we branch 1.17? 2. When will we push 1.17wmf1 to production? 3. When will we release MediaWiki 1.17?

I jokingly said the other day in the channel we should have it pack and release the beta package on/around Christmas (~3 weeks), so that would actually give us some thing solid to work with and the motivation to release a full non beta sometime in January.

Roan Kattouw

6:42 a.m.

2010/12/3 Rob Lanphier <robla(a)wikimedia.org>rg>:

...

There's some release planning issues that we have to sort out: 1. When will we branch 1.17?

Soon, IMO. Branching sooner means stabilizing sooner means releasing and deploying sooner. I don't think there's anything major we want to add to 1.17, right? It's a pretty big release already.

...

Trevor and Roan believe that ResourceLoader will be ready to deploy in January. However, looking at the backlog of code reviews, and I don't think it's realistic to assume we'll have everything else ready in January. My assumption here is that we need to be through the code review backlog prior to pushing what is currently in trunk into production. Simply extrapolating from the October/November rate of code review, March is looking more like the target, and that assumes we keep up the rapid pace of review. What seems realistic without being complacent?

Are you accounting for the fact that the review rate is currently being depressed by new revisions being added all the time? Branching would reduce that effect (not eliminate it, because we'd still pull fixes in for stabilization). In addition to that, if we'd have a few paid devs devoting their time to doing review and other things needed to get 1.17 into shape (WMF-employed reviewers are mostly focusing on their assigned projects now AFAICT) I think we can definitely finish before March. Roan Kattouw (Catrope)

Bryan Tong Minh

7:03 a.m.

On Fri, Dec 3, 2010 at 10:42 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:

...

2010/12/3 Rob Lanphier <robla(a)wikimedia.org>rg>:

There's some release planning issues that we have to sort out: 1. When will we branch 1.17?

Soon, IMO. Branching sooner means stabilizing sooner means releasing and deploying sooner. I don't think there's anything major we want to add to 1.17, right? It's a pretty big release already.

Branching as soon as possible would be nice. I think that there are no very large projects holding this up. But, if we branch too soon, and if we take too long at releasing, we would inevitably run again in a large review backlog on trunk. Therefore when we branch we should be certain that their are no big projects coming up in between that would draw a lot of people from working on the release. I would prefer branching as soon as possible. Is there a reason too not just branch *right now*? Anybody who wants to be bold?

...

In addition to that, if we'd have a few paid devs devoting their time to doing review and other things needed to get 1.17 into shape (WMF-employed reviewers are mostly focusing on their assigned projects now AFAICT) I think we can definitely finish before March.

I strongly second getting more paid devs into CR. It worries me a bit that I see certain other projects being developed and deployed, while general code review should be the top priority now. Bryan

Platonides

7:19 a.m.

Roan Kattouw wrote:

...

2010/12/3 Rob Lanphier <robla(a)wikimedia.org>rg>:

There's some release planning issues that we have to sort out: 1. When will we branch 1.17?

Soon, IMO. Branching sooner means stabilizing sooner means releasing and deploying sooner. I don't think there's anything major we want to add to 1.17, right?

It also means there aren't big features waiting for branching before being merged. So if we can cope with reviewing, I would wait (I think RobLa took it into account). Who will work into stabilizing the branch? A branch will have less attention (bug hunting) than trunk, and resources devoted to it will affect normal reviewing: an initial delaying for 1.18.

...

It's a pretty big release already.

Provided it doesn't ship with many bugs, it will be an awesome release :)

Roan Kattouw

7:26 a.m.

2010/12/3 Platonides <Platonides(a)gmail.com>om>:

...

So if we can cope with reviewing, I would wait (I think RobLa took it into account). Who will work into stabilizing the branch? A branch will have less attention (bug hunting) than trunk

Trevor Parscal

7:35 a.m.

Agreed - branching will not prevent bugs from getting fixed, we will be merging in a limited set of changes (fixes to bug) while ignoring new and irrelevant development. - Trevor On 12/3/10 2:26 PM, Roan Kattouw wrote:

...

2010/12/3 Platonides<Platonides(a)gmail.com>om>:

So if we can cope with reviewing, I would wait (I think RobLa took it into account). Who will work into stabilizing the branch? A branch will have less attention (bug hunting) than trunk

Well to keep review catchup manageable, I think we need to either branch or declare something like a feature freeze and freeze for minor stuff in trunk. My general opinion on this sort of thing is that trunk should not generally be subject to such freezes. Roan Kattouw (Catrope) _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Victor Vasiliev

9:39 p.m.

I do not like the idea of releasing code that was not run on Wikimedia wikis for at least a week. That may result in a rather buggy 1.17. --vvv

Chad

5 Dec 5 Dec

3:39 a.m.

On Sat, Dec 4, 2010 at 7:39 AM, Victor Vasiliev <vasilvv(a)gmail.com> wrote:

...

I do not like the idea of releasing code that was not run on Wikimedia wikis for at least a week. That may result in a rather buggy 1.17.

+1 -Chad

Platonides

8:51 a.m.

Chad wrote:

...

On Sat, Dec 4, 2010 at 7:39 AM, Victor Vasiliev <vasilvv(a)gmail.com> wrote:

I do not like the idea of releasing code that was not run on Wikimedia wikis for at least a week. That may result in a rather buggy 1.17.

+1 -Chad

A completely +1 from me, too. But I don't think Rob were suggesting that.

Aryeh Gregor

9:08 a.m.

On Sat, Dec 4, 2010 at 7:39 AM, Victor Vasiliev <vasilvv(a)gmail.com> wrote:

...

I do not like the idea of releasing code that was not run on Wikimedia wikis for at least a week. That may result in a rather buggy 1.17.

Also agree, as I've said elsewhere. Better to delay branching 1.17 an extra month or two than to release it when it hasn't been tested on Wikimedia sites.

Roan Kattouw

9:25 a.m.

2010/12/5 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>:

...

On Sat, Dec 4, 2010 at 7:39 AM, Victor Vasiliev <vasilvv(a)gmail.com> wrote:

I do not like the idea of releasing code that was not run on Wikimedia wikis for at least a week. That may result in a rather buggy 1.17.

Also agree, as I've said elsewhere. Better to delay branching 1.17 an extra month or two than to release it when it hasn't been tested on Wikimedia sites.

Possibly superfluous clarification: what we're talking about here is to branch 1.17wmf1 (i.e. WMF deployment), not an immediate 1.17 release candidate. Obviously we'd deploy first and release later, that's what we've always done AFAIK. Roan Kattouw (Catrope)

Rob Lanphier

1:07 p.m.

On Sat, Dec 4, 2010 at 4:25 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:

...

Yup. The only wrinkle here is that we may want to branch 1.17 + all extensions (the tarball branch) at the same time we branch 1.17wmf1 + deployed extensions (the deployment branch). If we don't do that, then when it comes time to put together a tarball release, it'll be difficult to sync it with what is in deployment. Rob

Aryeh Gregor

6 Dec 6 Dec

1:43 a.m.

On Sat, Dec 4, 2010 at 7:25 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:

...

Ah, okay. No specific objections from me, then -- whatever works. I was confused because historically, release numbers didn't correlate to deployments at all, so branching a new version would be unrelated to deploying a new version.

Tim Starling

11:38 a.m.

On 05/12/10 11:25, Roan Kattouw wrote:

...

2010/12/5 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>:

On Sat, Dec 4, 2010 at 7:39 AM, Victor Vasiliev <vasilvv(a)gmail.com> wrote:

I do not like the idea of releasing code that was not run on Wikimedia wikis for at least a week. That may result in a rather buggy 1.17.

Also agree, as I've said elsewhere. Better to delay branching 1.17 an extra month or two than to release it when it hasn't been tested on Wikimedia sites.

Presumably you mean that we would create REL1_17 now, as a copy from trunk, then run make-wmf-branch in January, which would copy from REL1_17 to 1.17wmf1, to be deployed shortly after. Then we would tag for release of 1.17 beta 1 some time after that. I am fine with this plan. -- Tim Starling

Roan Kattouw

8:05 p.m.

2010/12/6 Tim Starling <tstarling(a)wikimedia.org>rg>:

...

That's the correct approach indeed, thanks for correcting me or I would've done it wrong. Roan Kattouw (Catrope)

Trevor Parscal

4 Dec 4 Dec

6:44 a.m.

We need to get ResourceLoader in production in January. We can't afford to keep pushing it back, there are too many other projects that need to start using it in production. I think we should branch nearly immediately, and focus efforts on stabilizing it for January. The longer we push it back, the more revisions have to be reviewed - we must act quickly. - Trevor On 12/3/10 1:12 PM, Rob Lanphier wrote:

...

MZMcBride

9:07 a.m.

Rob Lanphier wrote:

...

There's some release planning issues that we have to sort out: 1. When will we branch 1.17? 2. When will we push 1.17wmf1 to production? 3. When will we release MediaWiki 1.17? Trevor and Roan believe that ResourceLoader will be ready to deploy in January. However, looking at the backlog of code reviews, and I don't think it's realistic to assume we'll have everything else ready in January. My assumption here is that we need to be through the code review backlog prior to pushing what is currently in trunk into production. Simply extrapolating from the October/November rate of code review, March is looking more like the target, and that assumes we keep up the rapid pace of review. What seems realistic without being complacent? [...] Longer term, everyone has stated a desire to move to more frequent deploys. I think that's a conversation worth having, but let's not have it as part of this thread.

I don't understand how you can discuss the 1.17 release / Wikimedia updating without discussing what comes next. If you branch in December and it doesn't go live on Wikimedia until March, that'll mean about 11 months since the last big site update (which was in April 2010, I think). It will also mean that there will be about four months of revisions between the branch and trunk when Wikimedia is updated. It seems like the backlog will never empty with this cycle/process. I don't want to be the only one clinging to the past (where there were much more regular updates), but I do think people should realize that the this plan forward doesn't really lend itself to returning to the days of weekly Wikimedia updates. Wikimedia is, for better or worse, shifting to a much slower code deployment process and the community, developers, and sysadmins have to accept that, I guess. (Slower, of course, unless it's "high priority" code that has money attached to it.) I think if it's going to be yearly updates for Wikimedia (and MediaWiki), everyone ought to be upfront about it. Realistic, accurate expectations lead to fewer complaints and a happier community. MZMcBride

4889

days inactive

4892

days old

wikitech-l@lists.wikimedia.org

Manage subscription

17 comments

11 participants

tags (0)

participants (11)

Aryeh Gregor
Bryan Tong Minh
Chad
K. Peachey
MZMcBride
Platonides
Roan Kattouw
Rob Lanphier
Tim Starling
Trevor Parscal
Victor Vasiliev