[08:13:08] <siebrand>	thedj: can we discuss the "chrome crash bug"? I want to ask you to report it if possible in the right forum.
[15:02:35] <RoanKattouw>	^demon: Do you have any objections against me adding WikimediaMaintenance to 1.18wmf1 so I can use the script I added in r106656 for Nagios?
[15:02:58] <^demon>	Like I can stop you? :p
[15:03:12] <^demon>	Go ahead :)
[15:03:19] <RoanKattouw>	heh
[15:03:21] <RoanKattouw>	Thanks
[16:43:42] <Nikerabbit>	hi brion
[16:46:23] <brion>	yo
[16:46:55] <Nikerabbit>	brion: yo! I've got some git problems again
[16:47:07] <brion>	ok
[16:47:13] <brion>	we moved the repo so that might break somethin :)
[16:48:53] <Nikerabbit>	brion: yeah - I was supposed to have push access there
[16:50:23] <brion>	ok so a) did you re-check out the repo from git@github.com:wikimedia/WikipediaMobile.git ?
[16:50:31] <brion>	b) lemme double-check permissions
[16:51:28] <brion>	i find github's admin interface slightly baffling
[16:52:40] <brion>	ok i may or may not have fixed your permission
[16:52:59] <Nikerabbit>	okay
[16:53:30] <Nikerabbit>	brion: seems to work now
[16:54:23] <brion>	yay!
[16:55:12] <Nikerabbit>	now I can fix the usage of word article in the messages
[16:56:18] <brion>	:D
[16:57:47] <Nemo_bis>	oh, nice
[17:02:28] <^demon>	Hi everyone :)
[17:02:31] <Danny_B|backup>	github?
[17:02:42] *Danny_B|backup 	thought we'll have our own git server
[17:03:02] <RoanKattouw>	This is about the mobile app
[17:03:10] <RoanKattouw>	The MW git meeting hasn't started yet
[17:03:29] <jeremyb>	meetings collide
[17:03:33] <siebrand>	hola
[17:03:37] <neilk_>	um ok should we start it?
[17:03:39] <^demon>	This is about the MW git meeting.
[17:03:44] <apergos>	yay
[17:03:49] <aude>	git! :)
[17:03:54] <apergos>	let's git to it!
[17:04:02] *jeremyb 	stabs apergos
[17:04:03] <neilk_>	I'm not totally sure what I can contribute, although I've been evangelizing git-svn
[17:04:03] *^demon 	whacks apergos for the pun
[17:04:16] *apergos 	snickers and bleeds all over everyone else's keyboards
[17:04:34] <jeremyb>	neilk_: blood
[17:04:36] <^demon>	According to Tim git-svn destroys mergeinfo and is partially to blame for our fun revision graph :)
[17:04:54] *Nikerabbit 	pings siebrand
[17:04:59] <apergos>	git-svn is a hacky perl script... you look at it ever?
[17:05:05] <siebrand>	hmm?
[17:05:09] <^demon>	The etherpad (also in the /topic) is http://etherpad.wikimedia.org/Git
[17:05:38] <neilk_>	^demon: mergeinfo seems like more of an obstacle than anything helpful for the average commit. Sorry if it makes life hard when switching the entire repo.
[17:05:39] <^demon>	First item of business: let's make sure we're pretty much settled on the layout we'd like to use. I've been proposing something like this:
[17:05:54] <^demon>	It makes life hard when you want a sane history.
[17:06:03] <^demon>	So yes, the layout...
[17:06:07] <^demon>	mediawiki/core.git
[17:06:11] <^demon>	mediawiki/extensions/foo.git
[17:06:14] <^demon>	Etc.
[17:06:21] <^demon>	Does that sound sane to everyone?
[17:06:28] <RoanKattouw>	There was a master extension repo somewhere, right?
[17:06:35] <^demon>	Yes.
[17:06:36] <RoanKattouw>	** Should probably make mediawiki/extensions-meta.git (or something) that has *all* extensions as submodules
[17:06:46] <^demon>	mediawiki/extensions-all.git or something
[17:06:46] <MaxSem>	heh. Git developers about our situation: "why don'y you just put all the extensions into the same module?"
[17:06:49] <^demon>	I'm open to the name.
[17:07:07] <RoanKattouw>	Well, so, yeah
[17:07:09] <MaxSem>	(I met 'em @GSOC summit)
[17:07:17] <brion>	heh
[17:07:26] <RoanKattouw>	Maybe this has been covered a zillion times before, but just what are the reasons for not putting all extensions in one repo?
[17:07:35] <RoanKattouw>	I've heard size, but I don't find that very convincing
[17:07:37] <brion>	1) permissions
[17:07:46] <brion>	2) import/export / self-determination
[17:07:52] <brion>	3) cleanliness :)
[17:07:53] <RoanKattouw>	Hmm, fair
[17:07:58] *RoanKattouw 	is convinced and shuts up
[17:07:59] <^demon>	Permissions is a big one.
[17:08:20] <neilk_>	Roan: It's very slow, too. Consider that git sucks down and stores way more info than svn
[17:08:25] <^demon>	Exts deployed to WMF will probably have a gated trunk model like we will do with core and currently do with puppet.
[17:08:26] <MaxSem>	why do we want to restrict access to specific extensions?
[17:08:34] <brion>	i *really* want people to be able to start their extensions on their own, then move them into our infrastructure, and also be able to move back out again if they wish
[17:08:48] <neilk_>	brion: yes!
[17:08:51] <^demon>	It's not about preventing access, it's about having the development model for each extension that works best.
[17:08:57] <apergos>	perms is a good one yes
[17:09:02] <RoanKattouw>	Because of the gated trunk model
[17:09:07] <^demon>	Permissions in gerrit inherit, so mediawiki/extensions/ would be very open by default.
[17:09:13] <MaxSem>	hmm
[17:09:17] <brion>	i still don't like gerrit myself though
[17:09:18] <^demon>	And then extensions we want to add review+etc to, we can do explicitly.
[17:09:23] <brion>	i find it ???. awful
[17:09:27] <neilk_>	there's only one thing that sucks if you divide exts -- refactoring across exts. But that seems very rare.
[17:09:30] <RoanKattouw>	Then I guess for WMF-deployed extensions, the master or deployment branch would be restricted?
[17:09:34] <RoanKattouw>	brion: Gerrit UI sucks
[17:09:34] <apergos>	I'm not really enthusiastic about gerrit either
[17:09:37] *siebrand 	mumbles something about LU and git.
[17:09:40] <RoanKattouw>	The core of gerrit is awesome
[17:09:47] <neilk_>	I have found moving stuff between exts and core to be annoying
[17:09:49] <RoanKattouw>	Its usability is crap
[17:09:51] <sumanah>	wasn't gerrit a Google product?
[17:09:51] <apergos>	it's not the ui I have a problem with
[17:09:54] <^demon>	siebrand: People pushing commits can be given permission to push without review.
[17:09:54] <MaxSem>	RoanKattouw, did you get any further with hacking it?
[17:09:57] <RoanKattouw>	No
[17:09:58] <robla>	RoanKattouw: so it's like git then?  :)
[17:10:03] <apergos>	it's the way it restricts one's use of git
[17:10:05] <RoanKattouw>	It's worse than giy
[17:10:07] <^demon>	siebrand: Pushing commits for i18n
[17:10:09] <brion>	siebrand: in principle there shouldn't be much difference between svn and git for localizationupdate
[17:10:17] <RoanKattouw>	apergos: No I don't actually mind /that/ . I hate the UI
[17:10:20] <brion>	have we tested anything?
[17:10:24] <siebrand>	^demon: LU as in LocalisationUpdate, not the push. we'll work that out somehow.
[17:10:29] <RoanKattouw>	We haven't tested LU with git
[17:10:38] <RoanKattouw>	But that's fine
[17:10:52] <RoanKattouw>	The way we have deployed LU on WMF is VCS-independent
[17:10:59] <brion>	oh good
[17:11:02] <Danny_B|backup>	i think we are going quite wild now, i would prefer if this could be moderated/facilitated, but if you like this unstructured discussion, i'll try to follow it
[17:11:05] <siebrand>	RoanKattouw: is it fine for WMF or fine for all users of LU?
[17:11:09] <RoanKattouw>	Fine for WMF
[17:11:16] <RoanKattouw>	Not fine for LU's default modus operandi
[17:11:21] <RoanKattouw>	OTOH
[17:11:22] <neilk_>	I would prefer if someone has an agenda
[17:11:22] <^demon>	Danny_B|backup: Yeah we're fracturing quite quickly.
[17:11:31] <neilk_>	is there a wiki / etherpad page
[17:11:36] <Danny_B|backup>	neilk_: /topic
[17:11:41] <siebrand>	ok, stop question. Are we talking WMF needs to be fine here, or MediaWiki users need to be fine? Also: ExtensionDistributor
[17:11:45] <RoanKattouw>	If anyone else runs LU and moves from SVN to git, they have to change config *anyway*, so they should just migrate to the WMF modus operandi and they'll be fine
[17:11:50] <siebrand>	stop = scope
[17:11:54] <siebrand>	damn autocorrect.
[17:12:04] <apergos>	rats, temporarily unavailable
[17:12:18] <Danny_B|backup>	anybody is logging as well?
[17:12:20] <^demon>	Ok everyone halt. Let's cover one question at a time.
[17:12:21] <sumanah>	neilk_: yup, http://etherpad.wikimedia.org/Git
[17:12:24] <^demon>	Danny_B|backup: Channel is logged.
[17:12:35] <RoanKattouw>	siebrand: With a bit of documentation, 3rd party installs can migrate easily
[17:12:35] <neilk_>	ok, thanks
[17:12:49] <RoanKattouw>	Yeah, let's get organized here
[17:12:56] <sumanah>	Danny_B|backup: http://ur1.ca/1e8l0
[17:12:59] <RoanKattouw>	So, Siebrand asked what the situation is with LocalisationUpdate
[17:13:31] <RoanKattouw>	The WMF side of the answer is that we'll have to change a script (that lives in puppet, not in the extension) to pull from git instead of svn and that's it
[17:13:56] <jeremyb>	and commit back to git not svn?
[17:13:57] <RoanKattouw>	For 3rd party installs, LU doesn't support git directly the way it supports SVN, but 3rd parties wishing to migrate from SVN to git can simply adopt the WMF setup
[17:14:10] <RoanKattouw>	jeremyb: LocalisationUpdate doesn't commit anything back to anywhere
[17:14:22] <jeremyb>	err, huh
[17:14:30] <RoanKattouw>	The WMF setup would be documented on the extension page so it can easily be duplicated. But it's pretty simple anyway
[17:14:47] <RoanKattouw>	jeremyb: LU is an extension that's pull-only. The push side of the equation is on TranslateWiki's side
[17:14:49] <RoanKattouw>	So
[17:14:51] <RoanKattouw>	Next question?
[17:15:07] <^demon>	Are there any more questions relating to the proposed layout?
[17:15:23] <^demon>	If there aren't any more objections to it, I'd like to set that down in stone.
[17:15:42] <RoanKattouw>	I am fine with the layout
[17:15:47] <brion>	layout+1
[17:15:49] <RoanKattouw>	siebrand: Any other concerns from the TWN side re layout?
[17:15:50] *robla 	gets chisel
[17:15:59] <Nikerabbit>	so one repo per extension?
[17:16:10] <RoanKattouw>	Yes
[17:16:11] <jeremyb>	robla: i prefer laser cutter
[17:16:52] <robla>	^demon: looks settled to me.  what's next?
[17:17:10] <^demon>	One minor bit of bikeshedding on a similar topic.
[17:17:18] <robla>	teal
[17:17:20] <^demon>	mediawiki/extensions-all.git for the meta-repo?
[17:17:28] <^demon>	Open to name suggestions there.
[17:17:29] <brion>	me like
[17:17:35] <RoanKattouw>	extensions-all sounds better than extensions-meta
[17:17:39] <Nikerabbit>	all-extension.git?
[17:17:43] <Nikerabbit>	+s
[17:17:46] <sumanah>	I like "extensions-all"
[17:17:46] <MaxSem>	al--extensions.git ?
[17:17:50] <RoanKattouw>	I guess we'll want extensions-wmf too?
[17:18:00] <MaxSem>	*all-extensions
[17:18:03] <robla>	extensions-all + extensions-wmf
[17:18:04] <Nikerabbit>	sounds yoda like
[17:18:13] <^demon>	extensions-all and extensions-wmf would be good.
[17:18:25] <robla>	it's all about sort order
[17:18:30] <^demon>	These packages would just bit submodules pointing to the mediawiki/extensions/foo repos
[17:18:41] <^demon>	s/bit/be/
[17:18:43] <Nikerabbit>	what there is to sort with those?
[17:18:50] <Danny_B|backup>	is extensions-wmf (considered as) subset of extensions-all?
[17:18:51] <RoanKattouw>	^demon: Can we talk about branch naming / conventions lateR?
[17:19:08] <siebrand>	RoanKattouw: no concerns.
[17:19:20] <RoanKattouw>	Danny_B|backup: Extensions that are in -wmf would always be in -all , although I suppose -wmf could refer to older versions
[17:19:38] <^demon>	I think that's the last of my naming bikeshedding.
[17:19:48] <robla>	^demon: what's next?
[17:19:48] <RoanKattouw>	Nikerabbit: You don't want the list of repos to look like "all-extensions , core, extensions, wmf-extensions"
[17:20:09] <^demon>	Next item someone put on etherpad is "* Some SVN properties such as svn:externals to a 3rd-party project"
[17:20:13] <^demon>	Does anyone want to clarify?
[17:20:43] <Danny_B|backup>	i assume this involves geshi, fckedit etc.
[17:20:48] <RoanKattouw>	I guess that's a concern re porting stuff like geshi?
[17:21:14] <^demon>	Presumably. Does someone know how git can do externals like that?
[17:21:22] <^demon>	If it even can?
[17:21:24] <brion>	^demon: submodules are similar but are git-to-git only
[17:21:31] <brion>	i think we'd just need to bite the bullet and import the files
[17:21:36] <sumanah>	liangent added that question
[17:22:14] <RoanKattouw>	I guess we'd want to look for existing git repos for those projects first
[17:22:15] <RoanKattouw>	?
[17:22:16] <jeremyb>	have a cron somewhere importing svn to git and then do git submodule?
[17:22:42] <robla>	^demon: submodules work differently with git than svn submodules.  they're pegged to a specific versoin.  there's no way to say "latest"
[17:22:45] <RoanKattouw>	I met a GeSHi dev and I got the impression those folks like religiously love git :)
[17:22:54] <^demon>	robla: You can do latest or pegged with SVN
[17:23:15] <jeremyb>	robla: that's the reason for the commit hook i thought?
[17:23:45] *robla 	looks up git feature request for floating revs
[17:23:47] <^demon>	Well the post-commit hook was for updating the extensions-all meta repo.
[17:24:01] <RoanKattouw>	Yeah but obviously that doesn't work for foreign-hosted stuff
[17:24:08] <^demon>	*nod*
[17:24:27] <brion>	all our svn externsl are also pegged
[17:24:29] <brion>	or they should be :)
[17:24:43] <^demon>	How many externals do we have across all extensions?
[17:25:05] <siebrand>	^demon: answering that question in a few mins.
[17:25:13] <^demon>	Thank you.
[17:25:38] <robla>	floating submodules rfc/patch for git: http://comments.gmane.org/gmane.comp.version-control.git/185164
[17:25:50] <RoanKattouw>	They're not technically all pegged, but the non-pegged ones are probably tags
[17:26:06] <^demon>	I think we're going to have to do it on a case-by-case basis with externals. Some will be easier to just import like brion suggested.
[17:26:11] <RoanKattouw>	There are 9 externals
[17:26:21] <^demon>	Larger libraries or ones that are updated more often might be annoying :)
[17:26:30] <siebrand>	^demon: 14 across trunk/
[17:26:51] <neilk_>	I believe we have postcommit or precommit hooks in SVN that need to be ported -- add these to the doc?
[17:27:04] <jeremyb>	what's the current fallback for externals where the foreign svn server is down? or disappeared for that matter?
[17:27:21] <brion>	jeremyb: error message and it doesn't check out
[17:27:24] <^demon>	neilk_: The current post-commit hooks are about pinging CR and the mailing list.
[17:27:33] <jeremyb>	brion: someone has a backup?
[17:27:43] <brion>	one hopes ;)
[17:27:50] <brion>	so that's another benefit to actually importing the files: safety
[17:27:57] <brion>	also more git-friendly in general
[17:28:07] <^demon>	This is true.
[17:28:23] <siebrand>	^demon: list of paths with externals: http://p.defau.lt/?mdH9cRwLTJt6rnplnd9ePw
[17:28:36] <jeremyb>	you get the same safety from cronjob import (assuming updates do fast forward only) i think
[17:29:21] <robla>	brion: does that effectively make extensions-all read only?  How does a patch make it from the meta repo back into the subrepo?
[17:29:24] <Danny_B|backup>	imported parts of extensions should be always in the same named folder - that should become a part of extension development guidelines
[17:29:27] <^demon>	siebrand: Thank you. That's not that bad.
[17:29:28] <jeremyb>	or since you have change the pegging anyway to get any new stuff you could just make it a manual update
[17:29:46] <brion>	robla: extensions-all would exist as a handy way to check everything out
[17:29:52] <Danny_B|backup>	so it's easily distinguishable for the first sight
[17:29:53] <neilk_>	^demon: oh, I see. So the real thing to do is to make Gerrit do all the things CR used to do. I don't know how things end up in IRC, I assume a similar process, RSS and some bot?
[17:29:53] <brion>	you'd make commits against the individual repos
[17:30:06] <brion>	which i think you could do by just cd'ing in and doing git stuff there
[17:30:13] <jeremyb>	robla: extensions-all is just submodules and no actual code i thought?
[17:31:02] <RoanKattouw>	neilk_: Have you hung out in #wikimedia-operations or #wikimedia-labs recently? Gerrit already reports puppet changes there
[17:31:03] <Nikerabbit>	has anybody compared the features of CR tool and gerrit? Can it filter by path, author and status?
[17:31:10] <robla>	jeremyb: I *think* brion is proposing something different
[17:31:16] <neilk_>	RoanKattouw: not only not recently but not ever.
[17:31:17] <RoanKattouw>	heh, Nikerabbit's question is almost comical
[17:31:22] <RoanKattouw>	Gerrit sucks
[17:31:28] <^demon>	neilk_: Right now codurr's a bot watching from TS.
[17:31:36] <RoanKattouw>	I mean, its core is great, but the UI and everything around it sucks
[17:31:42] <brion>	jeremyb: robla no, extensions-all is git submodules only as we've discussed so far
[17:31:47] <Nikerabbit>	so if gerrit sucks, are we going to force it for everyone?
[17:32:01] *^demon 	disagrees that gerrit sucks.
[17:32:11] <^demon>	The UI isn't intuitive, but it's not a bad tool.
[17:32:14] <RoanKattouw>	OK maybe that was too harsh
[17:32:26] <RoanKattouw>	Gerrit's UI is not nice to say the least
[17:32:43] <Nikerabbit>	it looks very messy to me
[17:32:45] <neilk_>	Well, if I can't filter by path and author, then something else about review workflow needs to change.
[17:32:47] <^demon>	And really, gerrit will only apply for gated repos (trunk, wmf-deployed extensions)
[17:32:56] <RoanKattouw>	Gerrit can filter by author
[17:33:01] <RoanKattouw>	I don't believe it can filter by path
[17:33:06] <neilk_>	ok
[17:33:07] <^demon>	If the code isn't in a gated model, you just push and can skip gerrit entirely.
[17:33:08] <RoanKattouw>	But it can filter by branch
[17:33:21] <RoanKattouw>	And, remember, most of the things we use path filtering for now will be separate repos by then
[17:33:24] <MaxSem>	can it at least show a list of all authors?
[17:33:36] <robla>	^demon: were there any unresolved issues that you're trying to settle with Gerrit, or is this disucssion just about whether we should use Gerrit?
[17:33:41] <neilk_>	RoanKattouw: ok, so that probably solves things for extensions, but for core it will be a huge mess...
[17:33:46] <Nikerabbit>	RoanKattouw: for good and bad I assume?
[17:34:03] <^demon>	robla: Some backend issues, but nothing show-stopping from where I sit.
[17:34:04] <RoanKattouw>	Nikerabbit: ?
[17:34:19] <RoanKattouw>	There are a lot of things we could do to make Gerrit nicer to use
[17:34:36] <Nikerabbit>	is it worth it?
[17:34:47] <robla>	Nikerabbit: what's the alternative?
[17:35:36] <RoanKattouw>	Yeah that's a good point
[17:35:40] <MaxSem>	hack CR to support Git?
[17:35:45] <RoanKattouw>	heh
[17:35:56] <RoanKattouw>	It's probably easier to make Gerrit nice
[17:36:18] <^demon>	I could go list a bunch of reasons CR sucks too.
[17:36:25] <brion>	does gerrit have an api? we could replace its entire frontend
[17:36:44] <robla>	let's replace ours first  :)
[17:36:44] <jeremyb>	heh
[17:36:49] <sumanah>	is there, like, a spec with a list of the functionality that we need in a CR tool?
[17:36:56] <neilk_>	wait who here has actually used gerrit apart from roan and demon
[17:37:00] <jeremyb>	CORS, oauth :P
[17:37:01] <RoanKattouw>	There is a wiki page where we wanted to track this
[17:37:04] <brion>	i seriously find gerrit completely unusable, every time i touch it i'm baffled
[17:37:18] <RoanKattouw>	But it only lists one thing
[17:37:21] <sumanah>	"replicate Extension:CodeReview" is kind of vague and I predict a bunch of things would fall through the cracks
[17:37:28] <jeremyb>	neilk_: apergos
[17:37:31] <^demon>	brion: Not like you're used to, but the whole thing is ajaxy using JSON-RPC so it could be possible, in theory.
[17:37:44] <RoanKattouw>	brion: A little bit of documentation would go a long way there I guess
[17:37:45] <brion>	*shudder* oh this is going to be fun :)
[17:38:09] <MaxSem>	I haven't actively used it, just browsed and my impression is that it's inteface will be even more frustrating with our commit rate, no?
[17:38:19] <RoanKattouw>	How does commit rate matter here?
[17:38:43] <MaxSem>	currently, the number of commits under review is relatively low
[17:38:50] <neilk_>	"unusable" needs to be clarified. Like, is it seriously conceptually flawed or just doesn't explain things well in its UI.
[17:38:55] <MaxSem>	dashboard is useful
[17:39:00] <RoanKattouw>	neilk_: IMO it's the latter
[17:39:11] <RoanKattouw>	I don't believe Gerrit is conceptually flawed. Actually, I think it's conceptually great
[17:39:17] <brion>	neilk_: at a minimum it doesn't explain things well in its UI. as such, i haven't fully divined its conceptual structure
[17:39:26] <MaxSem>	will it continue being useful with 1000 commits to review?
[17:39:29] <RoanKattouw>	It's one of those things where the concept is brilliant, the backend implementation is OK, and the frontend is badly done
[17:39:32] <^demon>	MaxSem: That dashboard is supposed to be your primary view. It'll show you things you're signed up for reviewing.
[17:39:46] <neilk_>	ok so it might fundamentally suck or be fundamentally okay... but its superficial design flaws are hiding that for now :)
[17:40:13] <RoanKattouw>	neilk_: I actually understand Gerrit, as do ^demon and Ryan, and I think we all agree it's fundamentally solid
[17:40:21] <robla>	MaxSem: Google is using it for some pretty large projects.  whether or not it will work for ours is another story, but there is at least some evidence it can be coerced to work
[17:40:28] <brion>	another thing is that, in principle with better use of git and personal work branches there'll be fewer commits actually going through final gerrit review -- because we'll be able to do more work collaboratively on a branch before pushing it together as a chunk
[17:40:32] <brion>	this is imo good :D
[17:40:51] <brion>	right now we have to commit to trunk just to share our code -- that's bad
[17:40:53] <MaxSem>	heh, internally Google used Mondrian last time I heard
[17:40:56] <^demon>	Also, remember like I said earlier that gerrit only matters for gated extensions.
[17:40:58] <RoanKattouw>	Also, the ops people have been using it for puppet for a while
[17:41:00] <brion>	it clutters the code review system with crap that's not actually ready yet
[17:41:06] <^demon>	If you're writing your extension and you don't care if anyone ever reviews it.
[17:41:10] <^demon>	You can push without review
[17:41:12] <^demon>	And never touch gerrit
[17:41:24] <apergos>	(sorry, I am unavailable right now)
[17:42:17] <brion>	(are there two git workflow irc meeting scheduled today? or did i just have the wrong one on my calendar for this afternoon pst?)
[17:42:24] <sumanah>	there are 2, brion
[17:42:27] <brion>	confusing!
[17:42:29] <^demon>	brion: Yes, so we can grab more timezones.
[17:42:30] <sumanah>	the second one is in about 6 hours
[17:42:34] <sumanah>	covering the same material
[17:42:37] <brion>	ok that explains that anyway :D
[17:42:41] <^demon>	So I could grab Tim + anyone who missed it in SF.
[17:42:46] <brion>	perfect
[17:42:54] <brion>	ok i gotta run into the office, catch y'all later
[17:43:06] <RoanKattouw>	Hmm, 1am, no I'm not going to that one
[17:43:28] <RoanKattouw>	Sooo
[17:43:32] <RoanKattouw>	Any other items / questions
[17:43:38] <RoanKattouw>	I had a thing about branch naming
[17:43:41] *sumanah 	looks at http://etherpad.wikimedia.org/Git
[17:43:52] <RoanKattouw>	But that's kind of bikeshed-y
[17:43:55] <sumanah>	random tip I just heard: "it's basically a terminal gui interface w/ color, so it defaults to showing info similar to git-log, but you can drill down. similar to gitweb in browser.  very useful, very fast. http://jonas.nitro.dk/tig/screenshots/ "
[17:44:10] <sumanah>	the software's called "tig"
[17:44:15] <siebrand>	Mondrian: http://video.google.com/videoplay?docid=-8502904076440714866 (Google Tech Talk)
[17:44:37] <neilk_>	were we supposed to assign any tasks now? I see we've gathered a few more...
[17:44:43] *RoanKattouw 	sees ASCII art revision graph and groans
[17:44:57] <^demon>	neilk_: Most of those tasks will fall to me :)
[17:45:05] <^demon>	I may delegate if someone's volunteering.
[17:45:15] <robla>	I've used tig.  keystrokes are kinda unintuitive...it's nice but classic unixy ui
[17:45:15] <sumanah>	neilk_:  https://www.mediawiki.org/wiki/Git_migration_issues and https://www.mediawiki.org/wiki/Git_conversion
[17:46:11] <sumanah>	neilk_: one of the TODOs from a platform engineering meeting last week: Chad will write the "how we are doing this" primer before the switchover.
[17:46:36] <neilk_>	ok, I'm just far out of the loop here I guess
[17:46:41] <neilk_>	sumanah: thanks
[17:46:43] <sumanah>	neilk_: but fortunately instead of writing our own "how to use git at all" primer we can use, like, http://openhatch.org/missions/git and similar tutorials
[17:47:19] <Danny_B|backup>	sumanah: pls put it in etherpad under the todo/documentation, thx
[17:47:28] <sumanah>	neilk_: well, IIRC ^demon has been saying that he needs to update those pages on mediawiki.org
[17:47:50] <sumanah>	Danny_B|backup: just a moment....
[17:49:13] <sumanah>	Danny_B|backup: done.
[17:49:20] <Danny_B|backup>	thank you
[17:50:26] *sumanah 	looks at http://etherpad.wikimedia.org/Git
[17:51:27] <sumanah>	so RoanKattouw & ^demon -- where should I look to see the spec of exactly how we need to mod/improve Gerrit?
[17:51:36] <^demon>	Any other questions/things we want to cover? We're almost at an hour now (and I'm wanting some lunch)
[17:51:44] <RoanKattouw>	sumanah: In our minds
[17:51:55] <RoanKattouw>	https://labsconsole.wikimedia.org/wiki/Gerrit_bugs_that_matter
[17:51:59] <RoanKattouw>	Incomplete ---^^
[17:52:06] <^demon>	All the improvements I want are backend things. I've gotten used to the UI already
[17:52:12] <^demon>	But yeah, that link.
[17:52:28] <RoanKattouw>	What backend improvements do you want then?
[17:52:34] <sumanah>	If we want to improve the number of people who feel comfortable doing code review, maybe we should reach out to a few specific people & ask them to beta test
[17:52:36] <MaxSem>	one thing I hate about Gerrit is that upon clicking on "diff all" ot opens a bunch of windows
[17:52:37] <RoanKattouw>	(Apart from the LDAP issue)
[17:52:52] <RoanKattouw>	Yes
[17:52:55] <RoanKattouw>	MaxSem: I have filed a bug for that
[17:53:02] <RoanKattouw>	I want the full diff displayed inline
[17:53:07] <RoanKattouw>	I was *gonna* code that up in NOLA
[17:53:17] <RoanKattouw>	But spent most of the weekend trying and failing to set up Gerrit on my machine in the first place
[17:53:26] <sumanah>	GrafZahl_: have you taken a look at the test git repository? the sandbox?
[17:53:47] <MaxSem>	and it doesn't support Opera!
[17:54:09] <GrafZahl_>	sumanah: Nope, my repo is on GitHub
[17:54:20] <GrafZahl_>	sumanah: Up to now I didn't know of a test repo
[17:54:41] <Danny_B|backup>	are we going to keep old svn in read only mode?
[17:54:50] <^demon>	Danny_B|backup: Yes
[17:55:01] <sumanah>	GrafZahl_: let me dig up the link -- I know ^demon sent it out to wikitech-l, the developers' list
[17:55:02] <^demon>	I plan to keep the old svn repo up in read only mode for practically forever.
[17:55:08] <sumanah>	Platonides, thedj,   have you played with the test repo at all?
[17:55:19] <^demon>	Platonides has, and he pushed changes to it :)
[17:55:23] <^demon>	He's been super helpful
[17:55:25] <Danny_B|backup>	^demon: so all [[rev:1234]] as well as r1234 will work, right?
[17:55:51] <^demon>	Well [[rev:]] links point to CR, not viewvc/svn.
[17:55:59] <^demon>	I imagine we could just set CR as read-only too.
[17:56:07] <sumanah>	GrafZahl_: `git clone https://gerrit.wikimedia.org/r/p/test/mediawiki/core.git`
[17:57:01] <Danny_B|backup>	^demon: [[rev:1234]] *used to* point to viewvc
[17:57:35] <GrafZahl_>	sumanah: thanks
[17:57:54] <Danny_B|backup>	so we can switch it back if necessary
[17:58:19] <Krinkle>	Can anyone remind me why literal protocol-relative don't result in links where any other protocol would ?
[17:58:22] <^demon>	Perhaps. But leaving the links stable as they are now wouldn't be bad. We don't want to trash our current CR history.
[17:58:44] <Krinkle>	like <span ??? >//foo.org/bar</span>
[17:58:55] <^demon>	I think there's an open bug for that.
[17:59:11] <^demon>	Anyway, we've come up on about an hour. Any last questions?
[17:59:13] <Danny_B|backup>	Krinkle: // can be comment
[17:59:17] <sumanah>	ok, thanks ^demon
[17:59:22] <RoanKattouw>	Krinkle: Because it's got way too much potential for accidental links
[17:59:25] <RoanKattouw>	Yeah, I think we're done
[17:59:33] <Danny_B|backup>	so i assume it's not resolving now by designe
[17:59:43] <Krinkle>	Danny_B|backup: In wiki markup ?
[17:59:51] <^demon>	Alrighty. Thanks everyone for your input.
[18:00:10] <Danny_B|backup>	Krinkle: you can have a demo chunk of code on site
[18:00:15] <^demon>	Also one last thing on gerrit: it *is* under active development, so if you find things about it that particularly bug you, I encourage you to file bugs about it.
[18:00:17] <Danny_B|backup>	s/site/page/
[18:01:04] <Krinkle>	Danny_B|backup: So if someone doesn't use <nowiki> or <pre> or <source> and pastes code with only a space indentation, there can be random links
[18:01:15] <Krinkle>	Danny_B|backup: Well, only if there is no space between // and the text, which usually isn't the case.
[18:01:55] <^demon|away>	Lunchtime!
[18:01:57] <Danny_B|backup>	sure, but as RoanKattouw said - it would trigger lots of false positives atm
[18:02:25] <sumanah>	I added a few items to http://etherpad.wikimedia.org/Git around recruiting testers for the test repo, documentation of the CR tool/Gerrit todos, and so on
[18:02:42] <Nikerabbit>	meeh
[18:02:51] <RoanKattouw>	Krinkle: The standard regex requires a \b (word break) before the start of a protocol, but / is a word-breaking character, so that fails
[18:02:51] <Nikerabbit>	what exactly does "mine" and "their" mean when doing svn merge
[18:03:00] <RoanKattouw>	Nikerabbit: "mine" is what you have locally
[18:03:07] <RoanKattouw>	"their" is what's coming in from the repository
[18:03:40] <Krinkle>	RoanKattouw: okay, so currently it is not deliberately excluded from anything in the Parser, it just happens to be the way it is.
[18:03:51] <Krinkle>	as usual :P
[18:03:58] <RoanKattouw>	No
[18:04:07] <RoanKattouw>	It is deliberately excluded from the autolink protocols
[18:04:21] <RoanKattouw>	Because otherwise foo//bar would be rendered as foo<a href="//bar">//bar</a>
[18:04:43] <RoanKattouw>	The fact that / is a word-breaking character makes the regex overly wide rather than overly narrow
[18:06:19] <Krinkle>	Hm??? I don't know regex very well, but if the regex states that it must be word-broken (which makes perfect sense here) in order to become a link, shouldn't // only become a link if text is like foo///bar (three slashes) ?
[18:06:31] <Krinkle>	the \b is inside the protocol-match ?
[18:07:14] <Krinkle>	foo/http://bar does become a link
[18:07:19] <Krinkle>	which makes sense
[18:07:23] <sumanah>	later
[18:07:23] <RoanKattouw>	The \b matches the space between a word char and a non-word char
[18:07:35] <RoanKattouw>	So foo//bar matches \b\/\/[a-z]+
[18:07:36] <Danny_B|backup>	RoanKattouw: not the _space_
[18:07:40] <RoanKattouw>	No, not the space
[18:07:42] <Danny_B|backup>	but the word boundary
[18:07:43] <RoanKattouw>	The .... void?
[18:07:47] <RoanKattouw>	Yeah
[18:07:56] <RoanKattouw>	There is an imaginary "place" between those two characters
[18:07:57] <hashar>	RoanKattouw: \b  match a change from \w to \s  iirc
[18:08:01] <RoanKattouw>	And that's what \b matches
[18:08:06] <RoanKattouw>	No, not to \s
[18:08:10] <RoanKattouw>	From \w to \W
[18:08:19] <RoanKattouw>	Because, as I said, \b matches at the position between '/' and 'b'
[18:08:53] <Krinkle>	understood. so why would \b + (protocols) match // ? It's not a word break + protocol, it's either a word break with a slash or just two slashes.
[18:10:42] <RoanKattouw>	The thing is, the regex is essentially this
[18:10:52] <RoanKattouw>	'\b' . preg_quote( $protocol )
[18:11:02] <RoanKattouw>	So for $protocol == 'http://' that's fine
[18:11:18] <RoanKattouw>	'h' is a word char, so it forces the preceding char to be a non-word char
[18:11:25] <RoanKattouw>	But for $protocol == '//' it's the other way around
[18:12:38] <apergos>	unfortunate timing.... skype call that I could not put off
[18:12:43] <apergos>	now let me do the backread
[18:13:10] <Krinkle>	Okay, so in case of foo/http://bar \b is between '/' and 'h'+ and for foo//bar, it's between 'o' and '/' ?
[18:13:20] <Krinkle>	nasty
[18:14:22] <RoanKattouw>	I believe that's how it works, yes
[18:17:24] <hashar>	Krinkle: not that nasty :)
[18:17:31] <apergos>	back
[18:17:43] <hashar>	Krinkle: the nasty thing is with word having a dash
[18:18:41] <hashar>	for example human-computer
[18:18:46] <hashar>	you will only match "human"
[18:18:52] <hashar>	cause \b is between n and -
[18:19:21] <hashar>	the result is that on http://www.mediawiki.org/wiki/Special:VisualEditorSandbox you can not select "human-computer" with a double click
[18:19:35] <hashar>	(cause it uses \b \B to find word boundaries)
[18:20:03] <hashar>	and I am pretty sure Javascript does not let us redefine \w \W \b \B etc..
[18:26:10] <enhydra>	seems I???m a bit late with this topic, but??? what about [[commit:]]?
[18:29:32] <Krinkle>	hashar: thx
[18:30:09] <hashar>	Krinkle: http://www.regular-expressions.info/ is a good source of informations
[18:30:31] <hashar>	Krinkle: they have some links to Windows tools that will let you visually play with regex
[18:30:55] <hashar>	http://www.regular-expressions.info/regexbuddy.html  http://www.regular-expressions.info/regexmagic.html
[18:31:02] <hashar>	there are similar tools under kde / gnome IIRC
[18:31:15] <Krinkle>	well, if we would really want, one could reproduce \b with a more advanced regex and keep that part out.
[18:31:29] <Krinkle>	but I think not matching foo-bar as one word is perfectly fine
[18:31:33] <Krinkle>	most text editors do it too
[18:31:38] <Krinkle>	when double-clicking words
[18:31:46] <Krinkle>	so not just javascript surfaces
[18:32:13] <Krinkle>	I'd say it's the expected behavior, or at least, has become it over the years.
[18:32:24] <Krinkle>	from a UX perspective that is.
[18:36:34] <hashar>	Krinkle: most probably. I don't have an opinion on dashed words, just took that as an example of \b usage :)
[18:36:44] <Krinkle>	sure, cool :)
[18:37:00] <Krinkle>	hashar: Arr, so while here. What's stat on the testy testy ?
[18:37:20] <hashar>	I fixed some bugs friday and today
[18:37:38] <hashar>	the VM is running fine. Aka the mediawiki installation is actually usable
[18:37:59] <hashar>	so now I need to have an op to build the package, upload it on apt.wm.org and then unleash that on galliu
[18:38:05] <hashar>	will most probably do that tomorrow :)
[18:38:25] <Krinkle>	apt.wm.org ?
[18:38:31] <Krinkle>	never heard of that
[18:38:35] <Krinkle>	but I can guess what it is
[18:38:36] <Krinkle>	:)
[18:39:11] <hashar>	that one http://wikitech.wikimedia.org/view/Apt.wikimedia.org  :-)))))
[18:39:41] <hashar>	currently figuring out why X forwarding does not work :D
[18:40:00] <hashar>	will have to choose between:  50/50, calling a friend or a joker
[18:40:11] <hashar>	dinner time, baby bath. See you later this evening
[19:05:20] <Wikinaut>	hi, I added some of my "cents" to the pad
[19:58:34] <RoanKattouw>	rsterbin: So, what's the api.php URL for that clicktracking-won't-take-absolute-URLs bug?
[19:59:47] <rsterbin>	RoanKattouw / DarTar: when i click on the "Learn More" button, I go to a page with this: "<?xml version="1.0"?> <api>   <error code="badurl" info="The URL to redirect to must be domain-relative, i.e. start with a /" xml:space="preserve"> " at the top
[20:00:08] <RoanKattouw>	OK, thanks
[20:00:50] <rsterbin>	i'm doing this locally -- url is api.php?action=clicktracking&eventid=ext.articleFeedbackv5%400-option1-cta_learn_more-button_click-bottom&namespacenumber=0&token=b67YHdNap0Tr6OFu2d16u5AzgOOB4smGU&redirectto=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FWikipedia%3AArticle_Feedback_Tool%2FTutorial
[20:04:04] <RoanKattouw>	I've found it
[20:04:10] <RoanKattouw>	It's some validation code that I put in that we don't really need
[20:10:54] <RoanKattouw>	rsterbin: 	catrope * <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106679> /trunk/extensions/ClickTracking/ApiClickTracking.php: Remove server-side "validation" of redirect URLs, not needed and getting in the way for AFTv5
[20:11:21] <rsterbin>	awesome
[20:11:41] <RoanKattouw>	Also just deployed that to the site
[20:12:07] <rsterbin>	fabriceflorin: option 4 being broken on prototype was due to a bug i fixed on friday -- i've updated prototype, so you should be able to see it there.
[20:13:52] <rsterbin>	RoanKattouw - works great now (locally); shall i test on labs?
[20:13:59] <RoanKattouw>	Please do
[20:14:05] <RoanKattouw>	I am in the process of updating labs to SVN
[20:14:11] <RoanKattouw>	*from SVN
[20:14:12] <RoanKattouw>	to HEAD
[20:14:35] <rsterbin>	ok
[20:16:50] <rsterbin>	RoanKattouw: just ran into a bug on prototype on edit -- "Fatal error: Call to undefined method  EditPage::getTitle() in  /srv/org/wikimedia/prototype/wikis/rc/extensions/ArticleFeedbackv5/ArticleFeedbackv5.hooks.php  on line 310"
[20:17:00] <RoanKattouw>	Rawr
[20:17:07] <rsterbin>	looking into that now
[20:17:10] <RoanKattouw>	Thanks for saying that right before I press Enter :)
[20:17:14] <RoanKattouw>	Oh, I know what that is
[20:18:03] <rsterbin>	oh good
[20:18:31] <rsterbin>	i'm looking at docs, but perhaps it's quicker if you fix it
[20:20:13] <RoanKattouw>	I'm committing it now
[20:20:31] <RoanKattouw>		catrope * <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106685> /trunk/extensions/ArticleFeedbackv5/ArticleFeedbackv5.hooks.php: For 1.18wmf1 compat, don't use EditPage::getTitle()
[20:21:08] <rsterbin>	word
[20:25:27] <fabriceflorin>	Thank you guys! I have started a new Etherpad here: http://etherpad.wikimedia.org/AFT5
[20:25:49] <fabriceflorin>	Please add your notes in the appropriate section.
[20:26:05] <RoanKattouw>	OK I've updated AFTv5 on labs
[20:26:13] <RoanKattouw>	Thanks to Reha for catching a last-minute issue there
[20:26:50] <fabriceflorin>	Roan, is MediaWiki r106685 something we need to be concerned about?
[20:27:09] <RoanKattouw>	That's my fix for the issue Reha ran into
[20:27:37] <fabriceflorin>	Thanks, Reha and Roan! Do you need us to test this on labs? Is this related to 'Edit this page' CTA?
[20:28:04] <RoanKattouw>	It was for the thing where it passes something through to the edit page
[20:28:25] <RoanKattouw>	The other issue Reha was talking about on Skype, I don't know if that's in the deployed code or not (the clicktracking absolute URL thing)
[20:28:46] <fabriceflorin>	Got it, I will test the edit pass-through on labs now.
[20:28:58] <fabriceflorin>	Reha, thanks for updating Option 4 on prototype. Will check it later on, once we launch.
[20:31:50] <rsterbin>	ok
[20:32:29] <Ironholds>	fabriceflorin: just in case you're working hard and don't see my email - can you send me links to the most up-to-date AFT5 form screenshots/wireframes so I can shove them in the tutorial?
[20:32:47] <RoanKattouw>	Let me know when I'm good to go to production
[20:32:52] <fabriceflorin>	Seems to be working on en.labs, I am able to make an edit without any issues. However, I no longer get all the info about my set-up in the URL, which I used to get.
[20:32:59] <rsterbin>	RoanKattouw: the fix you just did for click tracking solves the issue i was talking about on skype
[20:33:00] <fabriceflorin>	Will do, Ironholds.
[20:33:08] <Ironholds>	fabriceflorin: thankee :). We all still on for 2pm?
[20:33:09] <RoanKattouw>	Yay
[20:33:14] <rsterbin>	good to go as far as i can see here
[20:34:09] <fabriceflorin>	Oliver, let's connect at 2pm PT. Please wait for my go-ahead before announcing, though. We need to test on production for about an hour before we can pronounce this ready to announce.
[20:34:58] <fabriceflorin>	Thanks, Roan. Are there any final tests we should do before you can deploy to production?
[20:35:38] <Ironholds>	fabriceflorin: of course :)
[20:35:42] <RoanKattouw>	Nah we'll be fine
[20:35:54] <Ironholds>	In the meantime I'll just be prepping; final help-page checks, drafting up announcements, clearing them, that sort of thing.
[20:37:38] <RoanKattouw>	Alright, deploying now
[20:37:46] <rsterbin>	*crosses fingers*
[20:38:06] <fabriceflorin>	Sounds great, Ironholds.
[20:38:09] <RoanKattouw>	oh crap
[20:38:10] <RoanKattouw>	103 Warning:  Missing argument 12 for ArticleFeedbackv5Hooks::trackEditSuccess() in /usr/local/apache/common-local/php-1.18/extensions/ArticleFeedbackv5/ArticleFeedbackv5.hooks.php on line
[20:38:12] <Ironholds>	hahaha
[20:38:12] <RoanKattouw>	 321
[20:38:16] <rsterbin>	ack
[20:38:18] <RoanKattouw>	Fixing
[20:38:19] <Ironholds>	<RoanKattouw> Alright, deploying now
[20:38:19] <Ironholds>	<RoanKattouw> oh crap
[20:38:23] <Ironholds>	WE'RE PROFESSIONALS, HONEST
[20:38:50] <RoanKattouw>	Oooh
[20:38:52] <apergos>	this is the dirty secret about professionals
[20:38:53] <RoanKattouw>	Hook incompat I guess
[20:39:18] <fabriceflorin>	Reha, should I be concerned that the URL on en.labs no longer includes the coordinates we used to have after editing? Right now, it only says: '&stable=0' ... as so:  http://en.labs.wikimedia.org/w/index.php?title=Golden-crowned_Sparrow&stable=0
[20:39:30] <rsterbin>	RoanKattouw: why would that not show up on a local checkout?
[20:39:49] <RoanKattouw>	Probably an incompatibility between trunk and deployment
[20:39:54] <RoanKattouw>	Hook signature probably change
[20:39:55] <RoanKattouw>	d
[20:39:58] <rsterbin>	fabriceflorin: not sure what you're talking about
[20:41:38] <fabriceflorin>	Reha, after I clicked 'Edit this page', then 'Save Edit', there used to be a string of parameters in the URL last week, identifying which bucket you used, which CTA you used, etc. Don't know if that was a bug or not, but I am reporting a change in behavior.
[20:42:03] <RoanKattouw>	fabriceflorin: That's because of that error message probably
[20:42:33] <fabriceflorin>	OK, as long as that data is being saved through some other means, I'm fine.
[20:43:31] <howief>	hey Ironholds
[20:48:49] <RoanKattouw>	Alright, we are live on enwiki
[20:48:58] <RoanKattouw>	And this time it's not spewing PHP warnings :)
[20:49:20] <AaronSchulz>	it's always an accomplishment to have code that doesn't spew errors
[20:50:56] <fabriceflorin>	Cool! We're starting to test now!
[20:51:00] <RoanKattouw>	fabriceflorin: Alright so you and whoever else, please test AFTv5 on enwiki now :)
[20:51:03] <RoanKattouw>	jinx
[20:51:36] <fabriceflorin>	Thanks Aaron, if you are referring to AFT5, we appreciate the compliment ;o)
[20:51:54] <AaronSchulz>	the re-re-re-re rewrite of AFT :)
[20:52:18] <fabriceflorin>	OK, please post any immediate issues on this Etherpad page: http://etherpad.wikimedia.org/AFT5
[20:54:06] <Jarry1250>	Roan: so on 	https://en.wikipedia.org/wiki/1935_Ohio_State_Buckeyes_football_team, what am I looking for?
[20:54:10] <Jarry1250>	I can't see anything.
[20:54:30] <RoanKattouw>	A widget right below the red table, I think
[20:54:34] <RoanKattouw>	Or that's what I'm seeing
[20:54:38] <RoanKattouw>	You may be in a different bucket I guess
[20:54:42] <Jarry1250>	Ah, got it now.
[20:55:05] <AaronSchulz>	I see '&lt;articlefeedbackv5-bucket2-function arrayPrototypeUniq() { var result = []; for (var i = 0; i &lt; ...'
[20:55:21] <RoanKattouw>	wtf
[20:55:29] <AaronSchulz>	clickable JS code ftw
[20:55:35] <RoanKattouw>	That ain't supposed to happen
[20:55:39] <RoanKattouw>	I don't get that, not even with ?bucket=2
[20:55:44] <Jarry1250>	Oh, I don't think it shows on https *investigates by himself so as to lessen the workload on devs*
[20:55:53] <RoanKattouw>	Jarry1250: It shows on https or me
[20:56:02] <RoanKattouw>	oooh
[20:56:07] <RoanKattouw>	AaronSchulz: I think I might know why that is
[20:56:16] <Jarry1250>	Oh, got it now. *ponders more*
[20:56:17] <RoanKattouw>	Someone's been naughty and used a for .. in loop on an array
[20:57:46] <Jarry1250>	And I''m supposed to see it whilst logged in or not?
[20:57:49] <RoanKattouw>	I've found one instance, going through more code
[20:57:53] <RoanKattouw>	I'm seeing it while loggedi n
[20:59:53] <awjr>	RoanKattouw: i take it you're still working on the AFT deployment?
[20:59:58] <RoanKattouw>	Yes
[21:00:16] <awjr>	do you have any idea how much longer you'll need?
[21:00:20] <Jarry1250>	Logged out and immediately saw it...
[21:00:40] <Jarry1250>	Logged in and gone again (same article, same browser).
[21:01:24] <RoanKattouw>	awjr: Not long
[21:01:43] <Jarry1250>	Aha, got a relevant JS error.
[21:01:54] <RoanKattouw>	Oh!
[21:02:19] <RoanKattouw>	Jarry1250: Let's hear it :)
[21:02:28] <Jarry1250>	categories.current[cat].replace is not a function
[21:02:34] <RoanKattouw>	Aha
[21:02:36] <RoanKattouw>	OK
[21:02:46] <RoanKattouw>	Your issue and Aaron's issue are probably the same issue
[21:02:49] <RoanKattouw>	This next commit will fix it
[21:03:00] <awjr>	RoanKattouw: cool - can you let me know when yer done?
[21:03:37] <RoanKattouw>	Sure
[21:04:06] <Krinkle>	RoanKattouw: That's due to Twinkle probably, or a fix wasn't deployed yet..
[21:04:12] <Krinkle>	(clickable js)
[21:04:23] <RoanKattouw>	Krinkle: No, it's a classic for-in-loop-on-an-array thing
[21:04:27] <Krinkle>	I know
[21:04:31] <fabriceflorin>	Working fine on my tests so far. Tried bucketing and protected pages, no problems yet.
[21:04:37] <Krinkle>	That caused a fatal error last week in AFT
[21:04:44] <RoanKattouw>	?
[21:04:47] <Krinkle>	which I fixed by adding a hasOwn check
[21:04:49] <fabriceflorin>	Also working on uploading the latest images for Oliver.
[21:04:51] <RoanKattouw>	Oh
[21:04:52] <RoanKattouw>	OK
[21:05:08] <Krinkle>	(it was looping over an object and calling something on it which ended up calling undefined of undefined)
[21:05:10] <RoanKattouw>	Well ideally if you're looping over an *array*, you just use i=0; i < a.length; i++
[21:05:14] <Krinkle>	that was fixed bt this is very alike
[21:05:15] <RoanKattouw>	That's how I fixed it
[21:05:18] <RoanKattouw>	Yeah well
[21:05:23] <RoanKattouw>	Object.prototype isn't extended very often
[21:05:29] <RoanKattouw>	Not as often as Array.prototype
[21:05:49] <Jarry1250>	Still getting errors (purged, cache reloaded)
[21:06:07] <RoanKattouw>	They should be going away within the next 5 minutes
[21:06:17] <Krinkle>	RoanKattouw: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106398
[21:06:20] <Krinkle>	ah, that's WebFonts
[21:06:23] <Krinkle>	see that bug
[21:06:29] <Krinkle>	(the bugzilla link)
[21:06:37] <RoanKattouw>	Right
[21:06:48] <Krinkle>	that shows a report by me about how twinkle happily adds 2 methods to array.proto
[21:06:50] <RoanKattouw>	We generally don't protect against Object prototype additions in MW code
[21:06:57] <Krinkle>	indeed
[21:07:00] <Krinkle>	Twinkle should be fixed
[21:07:06] <RoanKattouw>	Or is config an array?
[21:07:14] <RoanKattouw>	It's an object, right?
[21:07:31] <Krinkle>	this one fixes it in WebFonts, confirmed
[21:07:44] <Krinkle>	does AFT have a var by the same name ?
[21:07:54] <RoanKattouw>	No
[21:08:01] <RoanKattouw>	I was just wondering
[21:08:06] <RoanKattouw>	Anyway
[21:08:07] <Krinkle>	config in Webfonts is indeed an array now that you mention it
[21:08:08] <Krinkle>	I traced it
[21:08:11] <RoanKattouw>	Right
[21:08:16] <Krinkle>	https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/WebFonts/resources/ext.webfonts.js?view=markup&pathrev=106398#l182
[21:08:20] <RoanKattouw>	So then the appropriate fix is to use an i=0 loop
[21:08:24] <Krinkle>	yep
[21:08:27] <RoanKattouw>	Anyway
[21:08:43] <howief>	congrats on getting AFT5 out!
[21:08:43] <RoanKattouw>	Jarry1250: You should see the fix if you Ctrl+F5 at any point 5 minutes after I deployed the fix
[21:09:04] <howief>	for folks that want to help with post-deployment testing, here's an ether pad we're using:
[21:09:05] <howief>	http://etherpad.wikimedia.org/AFT5LaunchTests
[21:09:07] <RoanKattouw>	I think it's been 5 mins already
[21:09:24] <Jarry1250>	Cool, will let you know.
[21:09:33] <Jarry1250>	Yup, working :)
[21:09:35] <RoanKattouw>	yay
[21:09:37] <RoanKattouw>	awjr: I'm dnoe
[21:09:50] <Krinkle>	RoanKattouw: by the way, I watched a Google Tech Talk yesterday on JS performance. Not a typical one, I actually didn't know most of these. Among them was an interesting way to optimize a for loop or a while loop. Use the second statement of the for loop (or the statement to the while keyword) as a boolean returning. So instead of i < len; i++, use i--
[21:09:53] <awjr>	RoanKattouw: awesome thanks
[21:10:04] <awjr>	congrats on AFT v5 :)
[21:10:09] <Krinkle>	had especially nice results in javascript
[21:10:19] <RoanKattouw>	Ah, right
[21:10:26] <Krinkle>	although it's not huge, and one could argue readability wins over performance here
[21:10:31] <RoanKattouw>	for ( i = n; i--; )
[21:10:33] <Krinkle>	yep :)
[21:10:39] <RoanKattouw>	Yeah I tend to go for readability > performance
[21:10:46] <RoanKattouw>	Now if n is like a million, then maybe
[21:11:04] <RoanKattouw>	But generally for loops with ten iterations are not gonna dominate your running time
[21:11:12] <Krinkle>	RoanKattouw: Anyway, if you're interested, I added a couple of links here: http://www.mediawiki.org/wiki/JSPERF#See_also
[21:11:21] <Krinkle>	New are "Nicholas C. Zakas - Speed Up Your JavaScript" and "Douglas Crockford - JavaScript: The Good Parts (Google Tech Talk)" to this list.
[21:11:32] <Krinkle>	The latter you probably have already seen in various forms.
[21:11:56] <Krinkle>	recommend it :)
[21:14:04] <RoanKattouw>	I have never actually read The Good Parts
[21:14:06] <Platonides>	which was the CR tag for 'need improvement'?
[21:14:07] <RoanKattouw>	I should read it some time
[21:14:11] <RoanKattouw>	Platonides: todo
[21:14:21] <RoanKattouw>	You know, that mythical time where I have time to actually read stuff
[21:14:29] <Jarry1250>	howief / Roan / anyone who knows: Will this 11k deployment be used to analyse the usefulness of the extension or just its tecchnical integrity ahead of a wider rollout?
[21:14:41] <Ironholds>	Jarry1250: the former, to a certain extent
[21:14:48] <AaronSchulz>	RoanKattouw: you read train routes instead?
[21:14:49] *RoanKattouw 	defers to Howie or Ironholds
[21:15:07] <howief>	Jarry1250:
[21:15:08] <howief>	both
[21:15:17] <Ironholds>	things like "testing if it makes a positive impact on editing activity" will wait a bit - the initial testing is just to see which version works best - but this phase is as much for research as it is for making sure nothing melts :)
[21:15:28] <RoanKattouw>	AaronSchulz: Haha. Nah, web sites about taxes and insurance and stuff actually
[21:15:39] <RoanKattouw>	(International moves are hairy)
[21:15:39] <AaronSchulz>	oh, my mistake then :)
[21:15:39] <howief>	this initial 11k deployment is more for technical integrity, but Ironholds will be working with the community in selecting a few hundred high trafficked articles to test the tool on
[21:15:45] <Jarry1250>	Oh, sorry about forgetting you Ironholds :) nothing personal.
[21:15:50] <Ironholds>	Jarry1250: that's fine!
[21:15:56] <howief>	the data from tis expanded set will be used to determine the usefulness of the extension
[21:16:21] <Ironholds>	the 11k deployment will be used for things like a/b testing data so we can work out a final version, but more complex tests on usefulness have to wait until we are sure we have the "Best" AFT version
[21:18:45] <Ironholds>	Jarry1250: would you like a link to the full research and testing plan?
[21:18:54] <Ironholds>	it's a wee bit opaque, to me at least, but it might help :)
[21:19:04] <fabriceflorin>	Hi Oliver, I just sent you the links to the new AFTv5 screenshots via email. The links are also posted on our Etherpad: http://etherpad.wikimedia.org/AFT5
[21:19:21] <Platonides>	RoanKattouw, do msg_resource, msg_resource_links, module_deps tables contain useful data for the future? Or do they get automatically regenerated?
[21:19:26] <Ironholds>	fabriceflorin: yup, saw them, replied :)
[21:19:33] <Ironholds>	Jarry1250: http://meta.wikimedia.org/wiki/Research:Article_feedback/Data_and_metrics if you're interested
[21:19:37] <Jarry1250>	Ironholds: Sure, hit me :) (See! I do research my Technology reports, honest.)
[21:19:42] <fabriceflorin>	Thanks, Ironholds!
[21:19:43] <Jarry1250>	Thaanks.
[21:19:58] <RoanKattouw>	Platonides: They're caches, they can be safely purged and will be regenerated
[21:19:58] <Ironholds>	Jarry1250: that's more than I do! I mean, uh, I'm a professional, honest! (please don't quote me, I like my job)
[21:20:20] <Platonides>	thanks
[21:20:24] <Platonides>	I thought so, but wanted to confirm
[21:20:40] <fabriceflorin>	Jarry1250, here is a general link about this AFTv5 project, FYI: http://www.mediawiki.org/wiki/Article_feedback/Version_5
[21:21:04] <RoanKattouw>	I think if you purge one of msg_resource and msg_resource_links you need to purge the other too, but that's it
[21:21:09] <Jarry1250>	fabrice: I have indeed seen that page, probably around a week  ago.
[21:22:26] <Platonides>	it was just for skipping them altoghether from backups
[21:22:57] <fabriceflorin>	Sounds great, thanks Jarry. Please let Ironholds or I know if you have any more questions.
[21:24:14] <Platonides>	I'm looking on how to rewrite the table comments to imply that
[21:24:36] <Platonides>	"Table for administering which message is contained in which resource" is a bit ugly for "do not include it in the backup"
[21:25:16] <Jarry1250>	fabrice: Sure. I'm just doing a simple In brief this week but I do like to get them right :) I also appreciate all updates I can get on these kinds of things.
[21:25:20] <Ironholds>	fabriceflorin: in other news, we still on for the 2pm PST checkin?
[21:26:51] <Jarry1250>	btw if any of the VE team want to check I've got my facts right, they are more than welcome to ( https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2011-12-19/Technology_report ) -- we haven't published yet.
[21:29:47] <fabriceflorin>	Hi Ironholds, yes we are still on for 2pm PT check in. Want me to call you over Skype?
[21:30:12] <Ironholds>	fabriceflorin: that'll work :)
[21:30:38] <fabriceflorin>	Reha, Greg, Sean or other OmniTI team members, are you finding any issues with the AFTv5 code on production?
[21:30:50] <rsterbin>	nothing so far
[21:31:07] <fabriceflorin>	Thanks, Reha! Roan, any issues on your end?
[21:31:19] <RoanKattouw>	Nope, all is quiet on the Eastern front
[21:34:09] <fabriceflorin>	Cool. That's the way we like it ;o)
[21:39:29] <awjr>	can you specify multiple wikis at the same time with mwsript? eg mwscript sql.php --wiki=metawiki,foundationwiki?
[21:40:48] <RoanKattouw>	Mo
[21:40:50] <RoanKattouw>	*No
[21:40:59] <RoanKattouw>	You'll have to do for wiki in foo bar; do mwscript $wiki blah; doe
[21:41:00] <RoanKattouw>	*done
[21:41:10] <RoanKattouw>	Or foreachwiki sql.php blah
[21:41:15] <awjr>	k, yeah didnt look like it from the code but wanted to be sure
[21:41:16] <RoanKattouw>	(but that does all wikis)
[21:41:17] <awjr>	thanks
[21:54:52] <alolita>	RoanKattouw: thanks for rolling out aftv5
[21:55:41] <Ironholds>	amen!
[21:55:50] <Ironholds>	now, lets pray that the community hates it
[21:55:55] <Ironholds>	I get paid by the hour and want to stay employed
[21:56:02] <Ironholds>	I mean, uh, I'm sure the software will be fine!
[22:03:16] <Ironholds>	fabriceflorin: call still on? :)
[22:04:28] <fabriceflorin>	Yes, Oliver, will call you in about 5 mins., OK?
[22:05:05] <Ironholds>	yeah, that rocks :)
[22:10:34] <RoanKattouw>	Jarry1250: Reading your VE coverage now
[22:10:36] <RoanKattouw>	"Nonetheless, it seems likely that hand-constructed pages will be subject to a one-off simplification program for overly complex wikitext structures, with their reintroduction prevented using a series of technical restrictions."
[22:10:42] <RoanKattouw>	That statement sounds slightly misleading to me
[22:10:57] <Jarry1250>	Probably. What would you prefer?
[22:11:53] <RoanKattouw>	I'm sorry
[22:11:54] <Jarry1250>	I was thinking of those {{medal table begin}} templates, incidentally.
[22:12:07] <RoanKattouw>	I was gonna explain but I choked on a glass of water and had to run off to the kitchen :(
[22:12:08] <RoanKattouw>	Yeah
[22:12:19] <RoanKattouw>	So most likely (and I am only half plugged into this), two things will happen
[22:12:36] <RoanKattouw>	First, we will forbid stuff like {{medal table begin}}, and pages using that will have to be fixed before they can start using VE
[22:12:40] <RoanKattouw>	But that's a manual step
[22:12:41] <fabriceflorin>	Hi guys. Dario is reporting that no comments are being stored right now, according to his first check.
[22:12:51] <RoanKattouw>	Second, we will probably enforce a "normalized" version of wikitext
[22:12:57] <DarTar>	I am checking the data coming in on the slave DB and I only see feedback metadata, not feedback contents
[22:13:19] <DarTar>	aft_article_feedback is getting correctly populated
[22:13:30] <DarTar>	13 rows so far
[22:13:36] <RoanKattouw>	For instance, we'll always use [[Foo]] and never [[Foo|Foo]], we'll use == Foo == instead of ==Foo== or vice versa, etc etc etc. Essentially we'll do this for every syntactical ambiguity
[22:13:53] <Ironholds>	DarTar: NICE!
[22:14:03] <Ironholds>	wait, that means it's broken. crap.
[22:14:04] <DarTar>	but aft_article_answer is empty
[22:14:12] *Ironholds 	needs to learn not to read from the bottom up
[22:14:19] <DarTar>	Ironholds: indeed
[22:15:17] <RoanKattouw>	Jarry1250: So we set rules for resolving each of those ambiguities by determining what the WikiDOM->wikitext renderer will output. Then you can normalize wikitext by running it through the parser (wikitext->WikiDOM) then through the renderer (WikiDOM->wikitext)
[22:15:35] <RoanKattouw>	Jarry1250: So before enabling VE on a page, we'll make a normalization edit that will be clearly marked as such
[22:15:38] <Jarry1250>	Will manual edits be silently normalised then?
[22:15:45] <Jarry1250>	I assume so.
[22:15:47] <RoanKattouw>	Jarry1250: And then after VE is enabled, we will silently normalize your edit pre-save
[22:15:56] <RoanKattouw>	Just like ~~~~ is silently expanded to a signature
[22:16:01] <RoanKattouw>	It's in the subst: phase, essentially
[22:16:15] <DarTar>	I have to leave, will be back in an hour or so
[22:17:19] <RoanKattouw>	Jarry1250: Note, all this normalization business is speculation at this point. It's an approach that's been discussed and I think it's the one the rest of the VE team is behind but I'm not sure. I know I support it :) but I don't know about the others
[22:17:41] <Jarry1250>	Oh, sure. :)
[22:18:33] <RoanKattouw>	Anyway hopefully that clears things up
[22:18:45] <fabriceflorin>	Ironholds, I think we need to make sure this is not broken before we can promote it. So that means we need to hold off our call until we have addressed these issues.
[22:18:48] <RoanKattouw>	You seemed to imply the conversion of disallowed syntax to allowed syntax would be automatic
[22:19:05] <Jarry1250>	Yes.
[22:19:09] <RoanKattouw>	So that's not the case; there is disallowed syntax and there is automatic conversion but they're not directly related
[22:19:39] <Ironholds>	fabriceflorin: the problem with the tables?
[22:19:44] <RoanKattouw>	"It also seems likely that once the editor is live, edits made in manual mode may be automatically tweaked for compliance before saving."
[22:19:45] <Ironholds>	cool :)
[22:19:49] <RoanKattouw>	That one is spot on
[22:19:58] <RoanKattouw>	Including the "seems likely" part :)
[22:20:12] <Ironholds>	RoanKattouw: and is that just the edit that gets tweaked, or would it normalise the rest of the page too?
[22:20:42] <Jarry1250>	Ironholds: AFAIK it's a one off run to normalise the full page followed by silent normalisations of the page post-edit.
[22:21:27] <Ironholds>	ahh, awesome
[22:21:37] *Ironholds 	is not working on the VE at all, so knows nothing about it
[22:21:49] <fabriceflorin>	Roan, can you reproduce the problem reported by Dario? He cannot see any comments in the AFTv5 data he just checked on production.
[22:22:49] <RoanKattouw>	Ironholds: Yeah, essentially when a page is put into VE-supporting mode, we make an automatic normalization edit, then after that we silently normalize each edit so the page never becomes denormalized
[22:24:41] <Ironholds>	RoanKattouw: thank you for making me feel like I do a worthless job :P
[22:25:03] *RoanKattouw 	doesn't get it
[22:25:43] <RoanKattouw>	Do you frequently do syntax normalization gnoming then?
[22:26:46] <Ironholds>	no, I more meant "I am surrounded by awesome people doing stuff more useful and incredible than my work"
[22:26:50] <RoanKattouw>	Oh, heh
[22:26:58] <RoanKattouw>	My involvement with VE has been very tangential
[22:27:04] <Ironholds>	you normalise syntax. I, uh. tell people you're normalising syntax. Big whoop.
[22:27:25] <RoanKattouw>	But I was involved in the "Trevor dumps his brain in front of three other people to eliminate bus factor" meeting a while back
[22:27:33] <Ironholds>	heh
[22:27:38] <RoanKattouw>	It took an hour and a half to go through the VE backend design
[22:27:43] <RoanKattouw>	That shit is compelx
[22:27:49] *Ironholds 	nods
[22:27:56] <Ironholds>	I'd say "I can imagine" but I really can't
[22:28:12] <RoanKattouw>	I imagine I'll be more involved once VE picks up steam again
[22:28:37] <RoanKattouw>	Right now it's kind of dormant because Trevor is the driving force behind the whole thing and his Christmas vacation started today
[22:29:39] <Ironholds>	it still looks incredible
[22:30:25] <Jarry1250>	Ironholds: heh, or you can tell me and I can tell people that the WMF is normalising syntax :P
[22:30:32] <RoanKattouw>	I would tell you to buy the VE team a beer, but I'm not the only one on that team that doesn't drink
[22:30:43] <Ironholds>	Jarry1250: subcontracting out my job? Iiiinteresting.
[22:30:47] <RoanKattouw>	Jarry1250: 2 degrees of separation, yay
[22:30:54] <Ironholds>	RoanKattouw: plus, I am kinda 13,000 miles away from most of them
[22:31:01] <RoanKattouw>	Well aren't I?
[22:31:10] <RoanKattouw>	(OK not for much longer but still)
[22:31:13] <Ironholds>	yes, but you'll probably be nearer sooner than I will be ;p
[22:31:39] <RoanKattouw>	Just organize a London hackathon already ;)
[22:31:47] <RoanKattouw>	Or, you know, get WM13
[22:32:39] <Krinkle>	RoanKattouw: Regarding RL2, got a minute ?
[22:32:50] <Jarry1250>	Anyone got any last minute tips for the Signpost btw?
[22:32:52] <RoanKattouw>	Sure
[22:32:57] <Jarry1250>	Or I'll sign off.
[22:32:59] <Krinkle>	RoanKattouw: So you added support for skins in the backend, right ?
[22:33:03] <RoanKattouw>	No?
[22:33:06] <RoanKattouw>	I'm planning to
[22:33:09] <RoanKattouw>	Probably this week
[22:33:15] <Krinkle>	Hm..
[22:33:26] <Krinkle>	I would've bet I saw you port that to RL2 ?
[22:33:33] <RoanKattouw>	I commented about it
[22:33:35] <Krinkle>	ok
[22:33:39] <RoanKattouw>	But I don't believe I actually did it
[22:33:54] <Krinkle>	anyway, regarding that. We need to think about optional things in validatoin.
[22:34:17] <Krinkle>	because in contrary to the old syntax, the JSON string doesn't' only contain non-empty properties
[22:34:29] <RoanKattouw>	Hmm, right
[22:34:32] <Krinkle>	but it should say functional and need no migratoin-script when we add a property
[22:34:40] <RoanKattouw>	Are you saying you want stuff to be optional
[22:34:41] <RoanKattouw>	Ah, right
[22:34:43] <RoanKattouw>	Good point
[22:34:45] <Krinkle>	so I was thinking of either normalizing them in, or normalizing them out.
[22:34:47] <Krinkle>	What do you prefer >?
[22:35:02] <RoanKattouw>	I don't think either is necessary
[22:35:13] <RoanKattouw>	What if we just tolerate missing properties and assume a default value for them
[22:35:24] <Krinkle>	Or third, make most optional
[22:35:25] <RoanKattouw>	And ignore unknown properties silently
[22:35:29] <Krinkle>	yeah
[22:35:36] <Krinkle>	okay, great :)
[22:35:47] <RoanKattouw>	I'll put that in as a task
[22:36:01] <RoanKattouw>	This will also simplify my unit test code
[22:36:29] <Krinkle>	RoanKattouw: yeah, that's what reminded me to this point. Going through CR backlog currently
[22:36:42] <Krinkle>	skipping some revs, but just making sure I know what's been happening
[22:37:14] <Krinkle>	RoanKattouw: Could you also look at applying normalization ? (order or properties, and stripping whitespace for db, and adding it for wikipage)
[22:37:22] <RoanKattouw>	Yes, that's also on my list
[22:37:35] <Krinkle>	ah, I see
[22:39:37] <Krinkle>	RoanKattouw: btw, ack-grep'ing for todos in our branch, I come across a todo that I solved partly but not sure how to properly do the other half.
[22:39:43] <Krinkle>	Exporting of mw-message pages
[22:39:56] <Krinkle>	how to get the translations as well?
[22:39:59] <RoanKattouw>	?
[22:40:28] <Krinkle>	http://svn.wikimedia.org/viewvc/mediawiki/branches/RL2/extensions/Gadgets/SpecialGadgets.php?revision=100001&view=markup#l340
[22:40:57] <RoanKattouw>	 // Translation subpages of title message349 	// @todo
[22:40:59] <RoanKattouw>	aha
[22:41:09] <RoanKattouw>	There's Title::getSubpages(), it's not too hard
[22:41:18] <RoanKattouw>	I did something similar in the migration script already
[22:41:24] <Krinkle>	filter out non-language codes or ignore that ?
[22:41:36] <RoanKattouw>	Just export all subpages? Can't hurt
[22:41:43] <Krinkle>	k
[22:42:21] <Krinkle>	interesting, I didn't know Title had that.
[22:42:30] <RoanKattouw>	Anyway, I'm off to bed
[22:42:43] <Krinkle>	k, thx
[22:42:58] <RoanKattouw>	Are you still doing RL2 frontend stuff?
[22:43:03] <Krinkle>	yep
[22:43:06] <Krinkle>	among other thigns
[22:43:17] <RoanKattouw>	What and how much are you doing these days anyway? I've seen you get involved with the Harvard thing
[22:43:54] <Krinkle>	yeah, Dario needed that fairly quick and got priority approval from alolita to get it done fast, so had to pause RL2 for a few weeks.
[22:44:19] <Krinkle>	That's done know, although it's going to get a second phase, I don't have workable details on that yet though.
[22:44:25] <Krinkle>	actionable*
[22:44:59] <Krinkle>	and there's two new project alolita wants me on, I don't remember their names right now but that's also going to happen.
[22:45:20] <Krinkle>	alolita: on that, you wanted to e-mail me about those ?
[22:45:50] <Krinkle>	and October code challenge, code review for that, needs to be done this week.
[22:46:00] <Krinkle>	that's it currently.
[22:46:10] <RoanKattouw>	OK well
[22:46:23] <RoanKattouw>	I'm trying to put in some hours the next few days, I'm working on RL2 unit tests
[22:46:29] <Jarry1250>	(Krinkle, btw, if you get a sec, is it possible to resolve de->Deutsch within JavaScript?)
[22:46:34] <RoanKattouw>	But I will soon be reassigned to painting walls probably
[22:46:40] <RoanKattouw>	My parents decided to move weeks before I do
[22:47:07] <Krinkle>	Jarry1250: Hm.. not that I know of, no.
[22:47:12] <Krinkle>	Where do you need that ?
[22:47:50] <Krinkle>	Jarry1250: "within JavaScript" as in, native in the programming language or native browser API, no. But it's certainly possible in JavaScript using something from a MediaWiki server.
[22:48:23] <Jarry1250>	Or even validate "de", "fr", etc? It's my TranslateSVG extension. I just wondered if there's a function for it within MediaWiki.
[22:49:45] <Jarry1250>	(In the PHP equivalent I validate them by trying to resolve them into native-language names.)
[22:50:10] <bawolff>	There's one in the language class i think
[22:50:39] <bawolff>	oh sorry, you said js above
[22:51:44] <Jarry1250>	Yup. I mean, I could just go and dump the current PHP language names into a massive JavaScript switch()-based function, but that hardly seems a nice way of doing it.
[22:52:56] <RoanKattouw>	You'd have a map like var languages = { 'de': 'Deutsch', 'en': 'English', ... };
[22:53:07] <RoanKattouw>	Supposedly, MW would export that map to JS
[22:55:13] <Krinkle>	RoanKattouw: It can do that already
[22:55:21] <Krinkle>	we use that on Commons for the AnonymousI18N drop down menu
[22:55:31] <Krinkle>	which is inspired by the language preference <select> on Special:Preferences
[22:56:06] <fabriceflorin>	Hi Roan and AFT team members, I just spoke to Yoni at OmniTI about the problem with not storing feedback data. He's calling Greg now to see what can be done on their end.
[22:56:31] <Krinkle>	RoanKattouw: Jarry1250 http://toolserver.org/~krinkle/wpAvailableLanguages.js.php
[22:56:40] <Krinkle>	Lemme see how I generate that, it gets it from the API and re-forms it
[22:57:09] <Krinkle>	that's periodically dumped on MediaWiki:Common.js at commonswiki
[22:57:16] <fabriceflorin>	Roan, most likely we will need you and Greg to work out this AFTv5 data issue together first thing tomorrow. OmniTI is on the East Coast, so you guys can start before we do, which is a good thing ;o)
[22:57:39] <Krinkle>	Jarry1250: Do you need a list or a single check ?
[22:58:01] <Jarry1250>	One or more single checks.
[22:58:05] <Krinkle>	ok
[22:58:09] <Jarry1250>	Something I can AJAX would work fine I think?
[22:58:13] <Krinkle>	yeah
[22:58:38] <Jarry1250>	Well, maybe synchronous but you know what I mean L)
[22:58:39] <Krinkle>	http://commons.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=languages&format=jsonfm
[22:58:40] <Jarry1250>	* :)
[22:59:03] <Jarry1250>	Interesting, wonder if I can whittle that down.
[22:59:12] <Krinkle>	IN PHP I do this,
[22:59:27] <Krinkle>	$result = $result['query']['languages'];// [0] => array('code' => 'af', '*' => 'Afrikaans')
[22:59:28] <Krinkle>	key_val_pair = array();
[22:59:28] <Krinkle>	foreach ( $result as $lang ) {
[22:59:28] <Krinkle>		$key_val_pair[$lang['code']] = $lang['*'];
[22:59:28] <Krinkle>	}
[22:59:47] <Krinkle>	so that I end up with an object that has langCode as key and langName as value
[22:59:57] <Krinkle>	as seen on http://toolserver.org/~krinkle/wpAvailableLanguages.js.php
[22:59:59] <Jarry1250>	Yes.
[23:00:13] <Krinkle>	so do that in JavaScript, and then simply if ( languages[code] !== undefined ) { .. }
[23:00:54] <Krinkle>	I'd recommend making a cross-domain JSONP request though, asynchronously
[23:00:54] <Krinkle>	/commons.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=languages&format=json&callback=?
[23:00:55] <Jarry1250>	Yeah, I'll have a play, thanks.
[23:10:23] <kaldari>	Does the action=edit API still rely on EditPage.php?
[23:11:22] <TimStarling>	yes
[23:12:50] <kaldari>	:(
[23:13:28] <kaldari>	Any idea if there's a bug for that? If not, I'll file a new one.
[23:13:28] <TimStarling>	and don't even think about refactoring it before the 1.19 branch point
[23:13:43] <TimStarling>	robla will revert you himself
[23:13:52] <kaldari>	no doubt
[23:13:55] <TimStarling>	I haven't seen a bug for it
[23:13:55] <^demon>	I'd be surprised if there's not a bug already begging for that
[23:14:13] <TimStarling>	I don't mind it depending on EditPage
[23:14:39] <^demon>	Bug 18654: EditPage.php needs rewrite.
[23:14:43] <TimStarling>	but I do object to it actually pretending to post a form to index.php?action=edit
[23:15:07] <TimStarling>	it used to be FauxRequest, now it is DerivativeRequest
[23:15:24] <TimStarling>	same thing really
[23:15:41] <kaldari>	if edit page accepts a few more parameters, it would probably be OK
[23:16:55] <TimStarling>	like what?
[23:17:24] <kaldari>	like being able to set a summary separately from a section title
[23:17:35] <TimStarling>	yeah, you can add that
[23:17:51] <TimStarling>	you know I argued with Erik about that when he implemented it
[23:17:57] <TimStarling>	I thought it should have been separate in the UI
[23:18:25] <TimStarling>	well, maybe not argued, I raised my point of view at least
[23:19:05] <kaldari>	yeah, especially if the API is going to be limited by that
[23:23:14] *robla 	catches up on conversation, preemptively reverts kaldari
[23:23:23] <kaldari>	:P
[23:25:21] <Jarry1250>	Krinkle: upon reflection, cross-domain requests from a special page? People won't like it.
[23:25:34] <Krinkle>	from a special page ? You didn't say that
[23:25:37] <Krinkle>	I thought this was a toolserver tool
[23:25:56] <Jarry1250>	Oh, yeah, probably should have done. It's the next gen of my Toolserver tool for SVG translations.
[23:26:04] <sumanah>	neilk_: hi, got a moment?
[23:26:19] <Krinkle>	Jarry1250: If you're inside MediaWiki context, it would obviously not be cross-domain, you'd point to the api.php of the current wiki not of another one ;P
[23:26:30] <neilk_>	sumanah: sure, what's up
[23:26:40] <Jarry1250>	Krinkle: excellent point well made :P
[23:26:47] <Krinkle>	np
[23:27:04] <Krinkle>	( Jarry1250 mw.util.wikiScript('api') )
[23:27:18] <Jarry1250>	Oh, ta. Didn't know that existed.
[23:27:26] <sumanah>	neilk_: re ArchiveLinks - is this status appropriate? https://www.mediawiki.org/wiki/Summer_of_Code_Past_Projects#Archival_for_Web_References.2FCitations
[23:27:40] <sumanah>	neilk_: I mean, is that what's up, as far as you know
[23:27:42] <Krinkle>	Jarry1250: if you know MediaWiki's wfScript() in PHP, this is like that
[23:28:11] <neilk_>	sumanah: we're a bit past that. We got the feed working.
[23:28:12] <Krinkle>	https://www.mediawiki.org/wiki/ResourceLoader/Default_modules#wikiScript
[23:28:29] <neilk_>	sumanah: oh no, actually it is right.
[23:28:34] <sumanah>	neilk_: Oh!  that's great!  Where is it? .... oh.
[23:28:36] <neilk_>	sumanah: we got the feed working on prototype.
[23:28:44] <neilk_>	sumanah: we didn't get one working on TS
[23:29:05] <sumanah>	neilk_: do you think it would be easier for him to do it on Toolserver, or to get started using Wikimedia Labs?
[23:29:55] <neilk_>	edited the page a bit
[23:30:45] <neilk_>	Toolserver is still more appropriate for this because we need access to a stream of edits that is sort of like the live site. I don't think there's a standard way to do this in Labs.
[23:31:00] <neilk_>	But perhaps we should ask.
[23:31:21] <neilk_>	sumanah: in any case I don't think Kevin will be back unless maybe next summer, and even then...
[23:31:33] <sumanah>	understood, neilk_
[23:33:14] <sumanah>	neilk_: sorry for disappearing -- damn wrong-focusing UI
[23:34:44] <sumanah>	neilk_: so, do you think I ought to contact Matthew Becker per his interest in moving forward with this? just forwarded you a relevant email
[23:36:05] <neilk_>	sumanah: I already replied to these guys, some weeks ago. They are focusing on kind of a pie-in-the-sky system to SOLVE EVERYTHING
[23:36:11] <sumanah>	oh ok
[23:36:26] <neilk_>	sumanah: I don't know if they are interested in picking up the more modest work we did (which is also more useful)
[23:36:40] <neilk_>	sumanah: basically they wanted to do Coral Cache
[23:36:46] <sumanah>	my
[23:36:47] <neilk_>	sumanah: I pointed out that already existed
[23:37:09] <neilk_>	Still, I would lurve it if we could convince them otherwise....
[23:38:39] <Ironholds>	kaldari, reply to your damn emails :P
[23:39:15] <kaldari>	I will....
[23:39:27] <neilk_>	sumanah: You may not know but we visited the Internet Archive recently and they are also visiting us today
[23:39:39] <neilk_>	sumanah: basically ball's in our court to get that TS thing up.
[23:39:39] <sumanah>	neilk_: I did hear, which is why I asked
[23:40:00] <neilk_>	yeah, I already briefed sue & erik. I'll send you a copy
[23:40:17] <sumanah>	neilk_: ok.  If I wanted to open this up to the community at large and say "please help finish this" is there a list of next steps I could point them to?
[23:40:48] <neilk_>	not as such
[23:40:54] <neilk_>	well here's another thing
[23:40:57] <Nemo_bis>	oh, neilk_, so could you ask them about their OCR system? :)
[23:41:17] <neilk_>	sumanah: the other day I was thinking about it and I realized there was a way to do the extension that was like 10x simpler
[23:42:17] <neilk_>	sumanah: which would disrupt wikipedia less, require no new tables, etc.
[23:42:39] <Nemo_bis>	(if you want to ask them you can ask sumanah what I'm talking about, she follows the lists where the OCR issue was discussed; or I can forward you)
[23:42:41] <sumanah>	Well that is cool! wanna talk it out and then I'll turn it into a light spec?
[23:42:47] <kaldari>	TimStarling: It looks like the dual use of wpSummary is also a problem for some JavaScript tools (https://bugzilla.wikimedia.org/show_bug.cgi?id=26312)
[23:43:07] <^demon>	neilk_: New tables is 0 disruption :)
[23:43:34] <sumanah>	Nemo_bis: neilk_ - you mean this? https://www.mediawiki.org/wiki/CAPTCHA (see the last section I think)
[23:43:38] <neilk_>	sumanah: well it's just an idea now. The thing is we made a whole new table to store links, so we would know when they were added. I realized that was totally irrelevant, if we put link-added date into the wikitext.
[23:44:01] <neilk_>	Nemo_bis, this meeting is happening right now
[23:44:07] <Nemo_bis>	sumanah, no, I mean the discussion about ABBYY vs. tesseract and how to get a license from ABBYY for the TS
[23:44:26] <neilk_>	Nemo_bis, I dunno, tweet to sue gardner or find some presence of Erik's online :)
[23:44:54] <Nemo_bis>	looks like the other way we're following are easier :)
[23:44:59] <neilk_>	^demon: yeah but these tables would grow at the same rate as the external link table and be mostly redundant. It was lame
[23:45:08] <Nemo_bis>	neilk_, thanks
[23:45:13] <^demon>	neilk_: Putting that sort of data *in* the wikitext rubs me the wrong way.
[23:46:06] <neilk_>	^demon: yeah but it's actually What We Want. For instance, if you cite something on a page, and then someone else, years later, uses the same link in a citation on the same page, we can't distinguish those.
[23:46:17] <neilk_>	if the link-added date was in wikitext, we could.
[23:46:29] <neilk_>	and we don't care about the link-added date until we link to the archive anyway
[23:46:34] <TimStarling>	kaldari: I think you could add a new parameter to EditPage, which doesn't correspond to any form field
[23:46:36] <neilk_>	so there's zero impact on the db.
[23:46:36] <sumanah>	Nemo_bis: I read that thing about ABBYY etc. but it's not on my priorities/TODO list.  Should it be?
[23:46:54] <TimStarling>	if it's present, it's used as the summary in preference to the section heading
[23:47:01] <TimStarling>	otherwise the section heading is used
[23:47:12] <^demon>	neilk_: At the cost of putting it in the page text, which again rubs me the wrong way.
[23:47:12] <kaldari>	TimStarling: As long as robla won't revert me :P
[23:47:21] <neilk_>	^demon: why?
[23:47:22] <^demon>	You shouldn't store that kind of metadata in the page text.
[23:47:24] <TimStarling>	nobody will revert you for that
[23:47:29] <Nemo_bis>	sumanah, I don't know, it's mostly a legal/philosophical issue right now, no implementations needed in the very near future and possibly none at all
[23:47:34] <TimStarling>	as long as you don't also refactor the whole of EditPage.php
[23:47:44] <kaldari>	it's a deal
[23:47:56] <neilk_>	^demon: there is no easy way of storing it otherwise, since there is no blame view in MediaWiki.
[23:48:00] <sumanah>	in that case Nemo_bis I will continue to basically ignore it until & unless I find out my Volunteer Development Coordination powers are needed. :)
[23:48:01] <robla>	I suppose I could make an exception  :)
[23:48:27] <neilk_>	^demon: so we had a kinda hacky system whereby we track when a link was first added to a page -- like i said redundant with ext links
[23:48:37] <^demon>	You say you're basically just tracking externallinks, but with timestamps?
[23:48:46] <neilk_>	external link + timestamp + page
[23:49:01] <^demon>	You could add the columns to the externallinks tables via the extension
[23:49:05] <^demon>	Since core wouldn't need them.
[23:49:13] <^demon>	Make them nullable, so core shouldn't care.
[23:49:15] <Nemo_bis>	sumanah, a good OCR service for Wikisource is certainly needed, but I think we first need to understand how to get ABBYY software
[23:49:17] <neilk_>	^demon: is that guaranteed safe with our sql abstraction?
[23:49:38] <neilk_>	^demon: and also, note that it creates dupe rows.
[23:49:49] <^demon>	I'm not sure what you mean by "safe"
[23:50:00] <neilk_>	^demon: won't break existing queries.
[23:50:15] <^demon>	I can't see any reason why it would.
[23:50:16] <neilk_>	^demon: and anyway the point is, there are many rows per external link, not just one.
[23:50:23] *^demon 	shrugs.
[23:50:28] <^demon>	I'm just throwing ideas out there.
[23:50:55] <neilk_>	^demon: sure... but this is the process we went through when designing it too :) Lots of annoying choices, nothing super easy.
[23:51:02] <^demon>	I have no particular vested interest. I'm just saying that storing metadata in page text *feels* wrong and sounds like it could be done another way.
[23:51:04] <sumanah>	Nemo_bis: it seems like the wikisource community can probably take care of that without me, then
[23:51:29] <neilk_>	^demon: ok thanks. At least that makes me think about the downsides of the new idea. Maybe the old (existing) way ought to just be deployed.
[23:51:51] <Nemo_bis>	sumanah, no idea, actually... and previous implementations with tesseract on Toolserver are broken with nobody working on them, so...
[23:52:31] <sumanah>	Nemo_bis: maybe you should just email wikitech-l a summary of the current situation ... sounds like it's more complicated than I thought and could use more attention?
[23:55:17] <Nemo_bis>	sumanah, it's surely complicated :)
[23:55:26] <Nemo_bis>	I'll ask some more info.
[23:58:25] <sumanah>	thx Nemo_bis
[23:59:37] <Nemo_bis>	no, thank you sumanah :)