Currently working (mostly backwards) to fill in the Code Review holes from before 1.18 branch point:
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset...
Roadmap provisionally says July for 1.18 deployment: http://www.mediawiki.org/wiki/MediaWiki_roadmap
-- brion
On Tue, Jun 7, 2011 at 2:56 PM, Brion Vibber brion@pobox.com wrote:
Currently working (mostly backwards) to fill in the Code Review holes from before 1.18 branch point:
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset...
Roadmap provisionally says July for 1.18 deployment: http://www.mediawiki.org/wiki/MediaWiki_roadmap
I've got a meeting, but after that I'll join in. Another CR sprint will do me good after all the PHPUnit I've been mucking about with.
Anyone else? Let's congregate on IRC and try to make the graph drop today :)
-Chad
On Tue, Jun 7, 2011 at 12:57 PM, Chad innocentkiller@gmail.com wrote:
On Tue, Jun 7, 2011 at 2:56 PM, Brion Vibber brion@pobox.com wrote:
Currently working (mostly backwards) to fill in the Code Review holes
from
before 1.18 branch point:
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset...
Roadmap provisionally says July for 1.18 deployment: http://www.mediawiki.org/wiki/MediaWiki_roadmap
I've got a meeting, but after that I'll join in. Another CR sprint will do me good after all the PHPUnit I've been mucking about with.
Anyone else? Let's congregate on IRC and try to make the graph drop today :)
Cool! For those keeping score at home, here's the most important graph: http://toolserver.org/~robla/crstats/crstats.118all.html
And here's the goals I posted on Friday: 2011-Jun-03 1594 2011-Jun-10 1329 2011-Jun-17 1064 2011-Jun-24 799 2011-Jul-01 534 2011-Jul-08 269 2011-Jul-15 4
...and here's where we were at as of the last snapshot: 1528. That number is all revs (including extensions) waiting on review before r87529.
The good news here is that core got most of the love over the past week: http://toolserver.org/~robla/crstats/crstats.118phase3.html
That's a drop from 670 on June 3 to 611 on June 7 (midnight UTC). Those are the hardest ones to get through, so it's good that the progress we made was mostly there. Still, make sure the extensions are getting love too (even if it means marking "deferred" on extensions that aren't slated for WMF deployment).
Rob
On 07/06/11 23:27, Rob Lanphier wrote:
http://toolserver.org/~robla/crstats/crstats.118all.html
And here's the goals I posted on Friday: 2011-Jun-03 1594 2011-Jun-10 1329 2011-Jun-17 1064 2011-Jun-24 799 2011-Jul-01 534 2011-Jul-08 269 2011-Jul-15 4
This is a linear progression, the revision become harder and harder to review since, with time, most of the easy stuff got reviewed :-) Make it a long tail maybe ? :-)
On Tue, Jun 7, 2011 at 11:57 PM, Ashar Voultoiz hashar+wmf@free.fr wrote:
On 07/06/11 23:27, Rob Lanphier wrote:
http://toolserver.org/~robla/crstats/crstats.118all.html
And here's the goals I posted on Friday: 2011-Jun-03 1594 2011-Jun-10 1329 2011-Jun-17 1064 2011-Jun-24 799 2011-Jul-01 534 2011-Jul-08 269 2011-Jul-15 4
This is a linear progression, the revision become harder and harder to review since, with time, most of the easy stuff got reviewed :-) Make it a long tail maybe ? :-)
Well, kinda moot at this point. Unfortunately, we're not even beating a linear progression to a July 15 target: 2011-Jun-03 1594 2011-Jun-10 1435 2011-Jun-13 1427
Extrapolating from just the June 3 to June 10 review rates (two points! woohoo, it's a trend!), here's the rate: 2011-Jun-03 1594 2011-Jun-10 1435 2011-Jun-17 1276 2011-Jun-24 1117 2011-Jul-01 958 2011-Jul-08 799 2011-Jul-15 640 2011-Jul-22 481 2011-Jul-29 322 2011-Aug-05 163 2011-Aug-12 4
Not all of the news is bad. Most of the progress in the past week was in trunk, which is where the hardest review work is: 2011-Jun-03 670 2011-Jun-10 529
A linear projection there has us finishing up July 5. So, really, it's a matter of making sure we apply the same focus to extensions that we're applying to core, as well as keeping up with core reviews.
Ashar, you're point isn't lost, though. We know from past history that we don't tend to review at a linear rate when we buckle down. For example, here's the 1.17 cycle: http://toolserver.org/~robla/crstats/crstats.117all.html
We could probably figure out which flavor of curve fits the December-February portion of that graph, and probably get something with better predictive power. I'll admit to being too lazy + mathematically disinclined to work out which one it is, but I'd be happy if someone wanted to take a shot at it. The raw data: http://toolserver.org/~robla/crstats/data/1.17all/crstatsdata.js
The depressing projection that's likely to come of that is that instead of August, we're probably looking at October or later at our current rate of review.
I'm not making a big fuss about this until 1.17 is done, since I know, for example, that Tim has been doing the last bits of detail work necessary for a 1.17 tarball release, so he hasn't been able to make as much of a dent as others have been available for. Still, we're going to need to go faster than this to expect a deploy before August. Thoughts on how to accelerate?
Rob
On Mon, Jun 13, 2011 at 4:00 PM, Rob Lanphier robla@wikimedia.org wrote:
On Tue, Jun 7, 2011 at 11:57 PM, Ashar Voultoiz hashar+wmf@free.fr wrote:
This is a linear progression, the revision become harder and harder to review since, with time, most of the easy stuff got reviewed :-) Make it a long tail maybe ? :-)
Well, kinda moot at this point. Unfortunately, we're not even beating a linear progression to a July 15 target:
There's been only one data point so far (last tuesday)... so it might be tough to extrapolate yet. :)
I'm not making a big fuss about this until 1.17 is done, since I know,
for example, that Tim has been doing the last bits of detail work necessary for a 1.17 tarball release, so he hasn't been able to make as much of a dent as others have been available for. Still, we're going to need to go faster than this to expect a deploy before August. Thoughts on how to accelerate?
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.
That was several months ago... we still haven't released 1.17, there seems to be little or no commitment to a deployment or release schedule on 1.18, and what review has happened between 1.17 and 1.18 has been totally unorganized ad-hoc opt-in poking.
If we're working on the assumption that 1.17 being unreleased is slowing down 1.18 work, then what are we doing sitting around?
Get that 1.17 tarball OUT and move on. It's been "any day now" for like three months...
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.
-- brion
Brion Vibber brion@pobox.com writes:
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.
+1000 for “top priority for engineering”
On Mon, Jun 13, 2011 at 4:19 PM, Brion Vibber brion@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
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.
This is certainly the case for anything mobile and special projects (offline) related. Since its a fairly new team the majority of its members are either part time contractors or are new and operating mostly on their own; this gives us a good challenge of on boarding new engineers for code review & deployment
I'm really eager to fix the latter. We currently have good documentation from Roan and others at http://wikitech.wikimedia.org/view/How_to_deploy_code and we'll have a much better eco system when het deploy is out. For those of you that actively deploy code .. do we have enough documentation for someone new to learn the system? If not .. what key pieces are missing? Feel free to grab me on irc if you want to dive into this deeply or if your just curious.
Internally i've watched/supported our engineers becoming more familiar with our deployment system and i'm eager to have more who are comfortable with this from both staff and the volunteer community.
--tomasz
Tomasz Finc wrote:
I'm really eager to fix the latter. We currently have good documentation from Roan and others at http://wikitech.wikimedia.org/view/How_to_deploy_code and we'll have a much better eco system when het deploy is out. For those of you that actively deploy code .. do we have enough documentation for someone new to learn the system? If not .. what key pieces are missing? Feel free to grab me on irc if you want to dive into this deeply or if your just curious.
Internally i've watched/supported our engineers becoming more familiar with our deployment system and i'm eager to have more who are comfortable with this from both staff and the volunteer community.
--tomasz
I think it is as easy as knowing how to use scap and sync-file. I would consider some features that [[How_to_deploy_code]] covers, such as deployment of a new extensions as advanced.
The rest is mostly common sense: trusting the code that you are deploying, not making silly syntax errors*...
I would add a note about having to be around* after you make any changes, in case you broke something, and -for new scappers- to also have some senior developer available.
I think it is worth explaining the correct way to add a configuration setting or group. Those are changes done quite often (shell bugs), but can break the sites or expose a private wiki.
* This happens to everyone, it is probably the most common cause of breakdown (now sync-file runs php -l for you). ** For new people: that means at least being on #wikimedia-tech.
http://wikitech.wikimedia.org/view/How_to_deploy_code mentions a couple of pitfalls. Given that it is not in svn, I'm providing here a couple of simpñle snippets to fix them. Can someone apply?
PITFALL #1: The path argument has to be relative to the php-1.17 directory, not to the current directory. It's interesting to note, as it's not intuitive, but the script can easily remind you that:
SCAPROOT="/home/wikipedia/common/php" if [ ! -e "$SCAPROOT/$1" ]; then echo "$SCAPROOT/$1" does not exist exit 1 fi
PITFALL #2: The comment is only the second argument, so normal shell parameter rules apply.
if [ $# -lt 2 ]; then echo "Provide a comment for syncing $1" exit 1 fi
if [ $# -gt 2 ]; then echo sync-file only takes 2 arguments, you passed $# echo Did you forgot to quote the comment? exit 1 fi
On Wed, Jun 15, 2011 at 2:42 AM, Tomasz Finc tfinc@wikimedia.org wrote:
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.
This is certainly the case for anything mobile and special projects (offline) related. Since its a fairly new team the majority of its members are either part time contractors or are new and operating mostly on their own; this gives us a good challenge of on boarding new engineers for code review & deployment
In the Features team @WMF, we've been balancing our features development workload to ensure code reviews are consistently happening for quite a while now. Some of our team members such as Roan consistently dedicate a 20% or higher percentage of their time for code reviews. Our full-time development team is *tiny* (Trevor, NeilK being the only FT feature devs in SF). Their contribution to code review has varied. Both Roan and Trevor have helped tremendously in marathons for Release readiness (for 1.17 in recent times) where Features development went on-hold for months to support clearing the release backlog. Neil has helped on multimedia related code. The rest of features devs are part time contractors and remote but have been enormously participatory in making code review happen and getting bug quashed (Krinkle, Werdna, AaronSchulz).
We're still in conversation about how to best support a constant 20% from all foundation developers. The suggestion of 1 mandatory day a week for code review has been made. This is tough to implement since features developers are multiplexed across many projects and time zones. They have to ensure they can meet their deliverable deadlines as well as support ~20% time for code review. Trevor, Neil - please feel free to jump in and add your thoughts on this.
To support constant code-review, contributors to MW (community and foundation) have to work together long-term. I feel on-boarding of all new developers to learn best code review and deployment practices is essential to make that happen. On my request, Roan put together some excellent documentation on best practices to deploy code (http://wikitech.wikimedia.org/view/How_to_deploy_codehttp://wikitech.wikimedia.org/view/How_to_deploy_code). This has helped features developers and hopefully new community contributors to better understand the nuances of MW code deployment and develop software keeping these review guidelines in mind. If there is more knowledge that can be shared on this topic, please feel free to edit :-)
Internally i've watched/supported our engineers becoming more familiar with our deployment system and i'm eager to have more who are comfortable with this from both staff and the volunteer community.
Any and all new foundation developers (whether in features, fundraising or mobile) have been "let loose" to do code reviews after many months of practicing-by-doing peer reviews. Same for deployments.
For any community members who have suggestions or questions, please feel free to ping me. I'm always on irc. I'm looking for more community contributors who would like to get on-boarded for code review and be part of the solution :-)
HTH. Best, Alolita
On Wed, Jun 15, 2011 at 2:42 AM, Tomasz Finc tfinc@wikimedia.org wrote:
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.
This is certainly the case for anything mobile and special projects (offline) related. Since its a fairly new team the majority of its members are either part time contractors or are new and operating mostly on their own; this gives us a good challenge of on boarding new engineers for code review & deployment
I'm really eager to fix the latter. We currently have good documentation from Roan and others at http://wikitech.wikimedia.org/view/How_to_deploy_code and we'll have a much better eco system when het deploy is out. For those of you that actively deploy code .. do we have enough documentation for someone new to learn the system? If not .. what key pieces are missing? Feel free to grab me on irc if you want to dive into this deeply or if your just curious.
Internally i've watched/supported our engineers becoming more familiar with our deployment system and i'm eager to have more who are comfortable with this from both staff and the volunteer community.
--tomasz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Jun 7, 2011 at 8:56 PM, Brion Vibber brion@pobox.com wrote:
Currently working (mostly backwards) to fill in the Code Review holes from before 1.18 branch point:
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset...
Yay!
Did you see the Etherpad in which Mark Hershberger assigned certain paths to certain people?
Roan Kattouw (Catrope)
On Tue, Jun 7, 2011 at 12:58 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
On Tue, Jun 7, 2011 at 8:56 PM, Brion Vibber brion@pobox.com wrote:
Currently working (mostly backwards) to fill in the Code Review holes
from
before 1.18 branch point:
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset...
Yay!
Did you see the Etherpad in which Mark Hershberger assigned certain paths to certain people?
Etherpad's great for notes but less great as an ongoing assignment space, such as say a wiki page that can be found by searching.
-- brion
Brion Vibber wrote:
On Tue, Jun 7, 2011 at 12:58 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
On Tue, Jun 7, 2011 at 8:56 PM, Brion Vibber brion@pobox.com wrote:
Currently working (mostly backwards) to fill in the Code Review holes
from
before 1.18 branch point:
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset...
Yay!
Did you see the Etherpad in which Mark Hershberger assigned certain paths to certain people?
Etherpad's great for notes but less great as an ongoing assignment space, such as say a wiki page that can be found by searching.
-- brion
A wiki page does make sense for assignments. Anyway, here's the data etherpad Roan referred to:
http://etherpad.wikimedia.org/CodeReviewSignup
A constantly changing overview of what's on-topic and rough todo-list, (which Etherpad is more suited for) http://etherpad.wikimedia.org/CodeReviewTracker
-- Krinkle
PS: Regarding search, a somewhat complete table of contents of wmftech related pads is here: http://etherpad.wikimedia.org/WMF-TOC
On 07/06/11 20:56, Brion Vibber wrote:
Currently working (mostly backwards) to fill in the Code Review holes from before 1.18 branch point:
Since ci.tesla is almost stable since last week, I have switched to reviewing 1.18.
I might have added some bugs in the 1.17 backport queue. Is there any policy to backport a revision to 1.17?
* Brion Vibber brion@pobox.com [Tue, 7 Jun 2011 11:56:36 -0700]:
Currently working (mostly backwards) to fill in the Code Review holes from before 1.18 branch point:
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset...
Roadmap provisionally says July for 1.18 deployment: http://www.mediawiki.org/wiki/MediaWiki_roadmap
I wish there was WYSIWYG editor in the roadmap. It can be anything: Wikia RTE, Magnus Manske visual editor, or anything else - however, supporting creating content from scratch (not just editing over already existing article), working with built-in parser out of box, and no glitches like FCKeditor has. And being an WMF extension with all the advantages of continuous integration (core / extension compatibility). Dmitriy
On Wed, Jun 8, 2011 at 9:30 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
I wish there was WYSIWYG editor in the roadmap. It can be anything: Wikia RTE, Magnus Manske visual editor, or anything else - however, supporting creating content from scratch (not just editing over already existing article), working with built-in parser out of box, and no glitches like FCKeditor has. And being an WMF extension with all the advantages of continuous integration (core / extension compatibility). Dmitriy
There are people at WMF working on a visual editor. It's not on the roadmap page, but that doesn't mean it's not being worked on :)
Roan Kattouw (Catrope)
That reminds me I should merge docs to the roadmap page! For now those live at http://www.mediawiki.org/wiki/Future
-- brion On Jun 8, 2011 4:13 AM, "Roan Kattouw" roan.kattouw@gmail.com wrote:
On Wed, Jun 8, 2011 at 9:30 AM, Dmitriy Sintsov questpc@rambler.ru
wrote:
I wish there was WYSIWYG editor in the roadmap. It can be anything: Wikia RTE, Magnus Manske visual editor, or anything else - however, supporting creating content from scratch (not just editing over already existing article), working with built-in parser out of box, and no glitches like FCKeditor has. And being an WMF extension with all the advantages of continuous integration (core / extension compatibility). Dmitriy
There are people at WMF working on a visual editor. It's not on the roadmap page, but that doesn't mean it's not being worked on :)
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org