User:NeilK/Worklog/2011-03-22 to 2011-03-28
Projects: Upload Wizard v1, Commons Strategy Status: seared in for flavor (Maillard FTW w:en:Maillard_reaction)
Last week:
- Thwacking UploadWizard bugs (w/Kaldari) for 1.0 release
- Doing some amateur recruiting
This week:
- Preparing patches, getting some crucial code reviews
- UploadWizard blog post, release to proto 3/22 (today), then release to production 3/30 w/Roan
- Recruiting again
- Look into Parul's research, see if can add any questions re: multimedia
- Try to push more on the Geolocation/Jeroen DeDauw thing
March 22
edit- Recruiting for web analytics
- Arranged 3/30 deploy w/Roan
- Asked Roan for his opinion on security review, bug 26063
- updated commons.prototype from SVN
- techblog post
- tried to figure out what was wrong with TitleBlacklist, Reedy updates didn't seem to solve my issue
- got annoyed with the stupid log div popping up on commons.prototype and resolved to check in my change which adds logging levels. Had a brief powwow with Trevor & mdale, following design:
- use mw.log.prepend for magically prepending to log -- mdale uses this pattern a lot for iframes
- no logging levels -- show logging only if in debug mode, obtain debug mode from RL.
- the "getLogger" closure concept isn't that important, although a nice to have
- 1:1 Alolita
March 23
edit- Got some recon on my web analytics potential hire, passed it on, arranged informal meeting
- read through mdale's bugs he found in UW prototype (thanks, Michael)
- conferred with Roan on 3/30 deploy, possible core changes. He thinks it's okay if they're in by Monday. I am feature freezing friday, so np. He shows this CR as an example of how to do a table update: Special:Code/MediaWiki/83812
meeting with Kaldari 1:30pmKaldari in meetings most of afternoon ;( Helped him get started on the sanitization bug / missing feature...- immigration stuffs
- Can't reproduce this IE6 bug on my system. And yet, everyone else can.... Tried working on new virtual machines Peter installed. yak shaving to get admin rights, install Wireshark, disable gzip-encoding on commons.prototype (otherwise the TCP stream follows are indecipherable). BTW DID YOU KNOW?!! MediaWiki is capable of doing its own gzip encoding; it wasn't even in apache config.
added my own local server & pseudo hostname into windows' hosts file, then finally figure out what's going wrong. Happened to do this with IE7 but whatever, I was getting inexplicable errors, might as well solve them here too.
- AHA. Think I know what it is. Commons.prototype has instantcommons + a mistake I've made in error handling. This:
upload: { result: 'Warning', warnings: { exists: 'yourfilename.jpg' } }
means the filename is in use. Which we can safely discard at this stage because of how we are handling uploads, except we might want to pre-mark the title field on the details page as having an error. But this:
upload: { result: 'Warning', warnings: { duplicate: [ 'Filename1.jpg', 'someothername.jpg' ] } }
Means duplicate content. I had these backwards for some reason. Also not parsing the list in duplicate properly.
Almost totally fixed this, but need to now handle some warnings like 'exists' a little more like 'success'. However, the duplicate warning, in our world, we are promoting to a fatal error (you just can't do it).
March 24
editIn late; worked late last night + rotten weather
Reviewing feedback etc. commons:Commons:Prototype upload wizard feedback#Uploading a file with the same name.3F
reviewed remaining bugs - added notes on RTL
got ticket on RT so I can place my own tickets... will help with Sitemaps
going to polish off the config bug
1:1 alolita, she is dubious I can get concurrency patch in, as it involves dealing with database... in any case we need to address fundamental errors in upload path first
Checked in an omnibus change to how success / warnings are parsed. Seems to solve most of the issues
Closing various bugs
It's 11:00pm again
March 25
editworked with Bryan Tong Minh on upgrading the api and upload system to fix bug 26076