[00:54:58] JeroenDeDauw, still having vote issues on Special:Contestant [00:55:06] Fine on dev installs, not on the cluster [00:55:32] Reedy: what kind of vote issues? [00:55:56] When the page reloads, it doesn't have the new comment, updated votes etc [00:56:21] sometimes a refresh or 3 is needed [00:56:25] othertimes, resubmitting scores [00:56:46] It's also possible for it to update what it's telling you is your current vote on it, but not reflect that in the actual rating [00:58:59] the data doesn't get updated in the db [00:59:03] but the queries do return success [01:02:23] TimStarling: if you'd like to chat about the extension more synchronously, I'm around [01:12:34] pgehres: I think running the parameters through a restrictive regex would prevent security issues [01:13:02] but it would limit what you can do with the extension [01:13:25] if you tried to put text in there for display, it wouldn't be long before you started missing your punctuation [01:13:59] TimStarling: yes, but I think we will generally be loading other templates for the appeal text since it will need to be localized [01:14:17] I am willing to sacrifice some flexible for security [01:14:50] if you just made 400 pages, and didn't use the extension at all, it would be pretty secure [01:15:24] That is definitely true, but we would need to make many times that many [01:15:32] Its about 400 per appeal [01:15:57] fair enough [01:16:31] obviously page creation can be automated, but that won't make sense as a solution above a few thousand pages [01:19:00] we did think about bots as well, but we are already passing country and language in the query string and it seemed more natural to do this and do even more switches in wiki-markup (as well as less fragile during the fundraiser) [01:19:43] I will go ahead and implement the regex if you think that's a reasonable solution [01:20:13] yes, I think it will work, barring some really unlikely template constructions [01:20:47] okay, thank you very much for looking at this [01:20:51] [01:20:58] no problem [01:21:59] rotfl, I promise not to do that :-) [01:24:17] TimStarling, any opinion about doing https://bugzilla.wikimedia.org/show_bug.cgi?id=28026 (ie everything but the large wikis, having said that, Commons has it enabled) [01:25:04] we should do it for all wikis, if the master databases can handle the load [01:25:07] Reedy: wtf... it does not get updated in the db, but does appear after a few refreshs? Or are these 2 distinct issues? [01:26:35] Cool. So just schedule some time when we've got some ops/yourself about incase it goes wrong? [01:27:02] After 1 refresh it can... [01:27:08] JeroenDeDauw, you can test it on testwiki [01:27:41] as long as $wgShowUpdatedMarker [01:27:43] is off [01:28:09] actually it looks like it's on [01:28:45] maybe we can turn it off for the initial deployment and then turn it on at some later date [01:28:57] if ( $wgEnotifWatchlist ) { [01:28:57] $wgEnotifUserTalk = true; [01:28:57] } else { [01:28:57] $wgShowUpdatedMarker = false; // not working right ? [01:28:57] } [01:29:19] JeroenDeDauw, http://test.wikipedia.org/wiki/Special:Contestant/4 [01:29:32] yeah, and the request is for $wgEnotifWatchlist = true [01:30:04] And $wgShowUpdatedMarker is true by default [01:30:39] I'll add a note to the bug report [01:30:56] Reedy: right. I added a comment, but it did not show and the comment count did not go up until I refreshed [01:31:03] Reedy: rep lag? [01:31:05] indeed [01:31:50] Well, it could read from the master db here, but I don't know if that's appropriate [01:32:59] replag would be an obvious explanation why it's not replicable locally [01:33:00] Reedy: come across such issues before? (I never tested on a master-slave setup, so don't know how to deal w/ this) [01:33:27] Using the master for all reads is bad... But sometimes it will be necessary [01:33:43] Let me point all at db_master for testwiki [01:33:48] see if that solves the issue [01:35:09] Or we could write to the slave instead [01:35:09] /me hides [01:35:40] I would hope it doesn't let you do that.. [01:36:08] The docs state the world will explode when you do that somewhere :p [01:36:43] ... [01:37:24] Yup [01:37:31] Reading directly from the master fixes the submission issue [01:39:02] Though, if we could flag it to read from the slaves, unless told otherwise (so cases where we're loading it again quickly after insert/update) that would probably be the best solution [01:39:37] Reedy: so what do you say? Read from master on this page? Might even make it conditional based on submitted or not [01:39:39] Yeah [01:39:57] Reedy: I'll see if I can easily change it [01:40:11] Find and replace works quite well ;) [01:42:43] Reedy: yeah, but obviously we do not want all queries to use the master db [01:43:06] cost wise, the queries affected are likely below 1% of the total [01:43:37] meh, I never anticipated needing to specify this when designing this code [01:45:28] I could think of a couple of ways to do it [01:48:26] JeroenDeDauw, flag in the DB object readFromMaster, default false, set it to true for the duration we need to [01:48:52] Reedy: that's what I'm doing already :p [01:48:57] heh [01:48:58] Glad you agree [01:49:23] it seems the simplest way, rather than introducing 101 parameters [01:54:10] Reedy: yeah, adding the arg in every read function is a no go [01:54:15] Reedy: should be fixed [01:54:19] can you confirm? [01:55:16] Looks fine to me [01:55:54] yay [01:56:21] Does 100399 want pushing also? [01:57:13] Reedy: yeah, erik asked for that change [02:00:11] Reedy: are you in SF? [02:00:23] yup [02:01:00] cool [02:02:22] there is still something wrong with the rating thing... meh [02:05:17] ? [02:05:31] it's not finished pushing to site [02:10:50] TimStarling, so would I just be ok to disable $wgShowUpdatedMarker and enable $wgEnotifUserTalk now ish then? [02:11:55] Reedy: nvm, I did not run the db update on this machine yet, hence the incorrect result [02:12:09] N0000b [02:12:13] Reedy: should have recognized the 255 in 2.55 though :p [02:12:15] yeah [02:12:19] heh [02:12:26] I was seeing that on testwiki earlier [02:12:28] forgot to do it at hte same time [03:02:18] Reedy: it still would need a deployment window and an "ok" from ops [03:02:43] Right [16:40:13] hi [16:40:35] hur [18:35:33] <^demon> brion: To follow up on your question of TestSwarm. [18:35:47] \o/ [18:35:53] <^demon> My first priority was getting jenkins up and running. I know Krinkle was trying to get some patches upstreamed first. [18:36:04] <^demon> I need to check with him on the status of that, then start getting it in puppet. [18:36:10] excellent [18:36:14] thx dude [18:36:19] <^demon> No problem. [18:36:38] Reedy: you done with the deletion disabling stuff? [18:36:39] <^demon> Also you may be interested, we put the jenkins jobs conf in a separate git repo. [18:36:48] <^demon> So it doesn't have to go through the puppet process. [18:36:50] ooh nice [18:36:55] JeroenDeDauw, just looking where to disable challenge deletion [18:37:55] <^demon> brion: It's called integration/jenkins. I put a git-setup in it too so people can push-review for the master. [18:38:07] <^demon> hashar and I have review privileges on it. [18:39:05] How do I get a $wg into JS? [18:41:19] brion, is there a simple way to get the value of a wg in JS? [18:41:25] Reedy: see addContestJS in SpecialContestWelcome [18:41:42] Then you can get it w/ mw.config.get [18:42:04] Skin::makeVariablesScript( etc? [18:42:55] Reedy, export it through the makevariables script above [18:43:01] i think it'd be nice to have an easier way though [18:43:11] raindrift: hey [18:44:36] Reedy: yeah [18:45:09] Reedy: please poke me when you're done, I want to make some follow up commit, but will create svn conflict if I do it now [18:54:09] *Reedy pokes JeroenDeDauw [18:55:10] :0 [18:56:13] Ryan_Lane, fyi there's some general agreement that the 'change id' commit hook for gerrit is problematic and fragile [18:56:37] do we actually need it? apparently it's causing all sorts of fun trouble when you try to do anything normalish like some rebasing on a local copy [19:06:10] Reedy: I removed the globals and put them in the settings array; so if you already put the gloabl in the settings file on mw.org, it'll need to be updated [19:06:41] I had done the email ones [19:08:03] How are we supposed to change the settings? [19:10:50] Reedy: look at the top of the page, it has docs [19:10:59] Same way as you do with UploadWizard [19:12:54] Reedy: can you up Contest on testwiki? [19:13:14] needs mergning first [19:22:19] brion: yes. it's needed [19:22:40] brion: without that it's basically impossible to submit a new patchset to an existing change [19:22:53] hmmmm [19:22:56] and how does it fuck up a local copy? [19:23:08] not sure exactly what ben was doing... [19:23:21] but apparently something ended up without a magic change id added, and gerrit didn't like it? [19:23:56] aren't branches generally for adding new patchsets to existing changes? [19:24:36] yes, but if you code review something and need to fix your change, you need to push something to the same change-id [19:24:58] err, if someone marks something as needing to be fixed. you need to submit a patchset to the same change [19:25:04] which is where the change-ids come in [19:25:15] ben had issues because we was doing local commits, and also doing pulls [19:25:22] so his commits were all mixed up [19:25:29] so on github i'd do this by pushing more commits onto my branch, then updating the pull request [19:25:49] yes. that's exactly what this is doing. [19:25:57] does gerrit handle that sort of id by embedding things directly into your commit messages instead? [19:26:13] yes. that's what the change-id is for [19:26:18] that seems like it would destroy the ability to merge in existing changes and then submit them for review [19:26:36] eg, making anybody who doesn't work in the preferred way unable to submit any code [19:26:47] how so? [19:26:56] no change ids in your commit -> won't take it? [19:27:03] correct [19:27:14] so what am i supposed to do if i merge in a lovely branch from some nice fellow's repo [19:27:16] i'm just fucked? [19:27:18] no [19:27:22] you amend the commit [19:27:25] do i have to go rebase it to modify every commit? [19:27:32] it'll add the commit-id for you [19:27:45] that's what the hook is for [19:27:45] on every commit? [19:27:57] there might be dozens/hundreds [19:28:04] no. when you commit, it'll automatically add the change-id for you [19:28:06] amending them will also change the commit ids [19:28:07] do a squash [19:28:11] ........ [19:28:22] that's generally something we wouldn't want to do when merging, surely [19:28:53] I don't see why not. [19:29:01] their branch has the full history [19:29:02] then we've lost the commit history, diminishing the purpose of using git [19:29:11] trunk contest is on test [19:30:23] we *can* disable requiring change-id [19:30:35] and if you'd like to in the mediawiki repo, that's fine [19:30:59] it's going to make shit real confusing real quick, I'm sure [19:31:08] we didn't have it enabled at first either [19:31:44] we should at least have the hook enabled [19:32:50] I'm not turning it off on the puppet repo though :) [19:33:09] brion: there's also the consideration of whether we want to let extension owners skip review as well [19:33:20] I'd imagine yes, but these are all tweakable options [19:33:47] skip review? maybe not. review their own? certainly :) [19:33:53] I agree [19:34:00] i'll have to poke some more at gerrit and see if i can wrap my head around the change-id stuff :D [19:34:10] brion: want me to make a repo for you? [19:34:11] it may well make a lot more sense in context [19:34:19] Ryan_Lane, sure [19:34:22] I can make you the owner so that you can tweak its settings however you'd like [19:34:25] mediawiki/core? [19:34:40] as long as that won't interfere with the real one :) [19:35:13] well, that would be the real one, at some point ;) [19:45:20] brion: so, you want a fake one, or for me to just make the real one? [19:48:31] Ryan_Lane, gimme a fake one for now [19:48:38] ok [19:48:43] i'll see if i can explode it and not worry about it taking anything with me ;) [19:48:48] heh [19:51:23] brion: did you get a labs account yet? [19:51:31] you need to log into gerrit for me to give you access :) [19:52:11] I remember giving you an account. I'm not sure if you ever logged into gerrit though [19:54:36] let's try it eh [19:54:44] Firefox can't find the server at controller.labs.wikimedia.org. [19:54:47] did... that get moved? [19:55:39] yeah [19:55:42] labsconsole.wikimedia.org [19:55:55] double subdomains are bad for * certs ;) [19:56:09] there we go [19:56:27] so, if you can log in there, you'll also be able to log into gerrit.wikimedia.org [19:56:29] ok off the top of my head...... no idea the name or password of any accounts attached to this thing [19:56:37] and... there's no email-new-password link on the login page [19:56:39] https://labsconsole.wikimedia.org/w/index.php?title=Special:UserLogin&returnto=Main_Page [19:56:43] should be Brion VIBBER [19:56:45] yeah [19:56:51] you'll need to click "Log in" [19:56:52] to make it fail [19:56:58] ugh [19:57:01] why mediawiki does this, I'll never know [19:57:04] is that reported in bugzilla? [19:57:19] no. I'm running 1.18, and it probably needs an svn up [19:57:19] ok let's try this [19:57:26] I'll svn up in a min [19:57:31] after you get in :) [19:58:11] then I'll probably break everything and spend a day fixing mediawiki. heh [19:58:19] ok i'm in Ryan_Lane [19:58:21] hehe [19:58:27] ok. log into gerrit.wikimedia.org [19:58:38] at some point I'm going to do some form of web SSO [19:58:45] but for now, no dice [19:58:47] \o/ [19:59:02] you logged in? [19:59:09] hmm. I wonder why I can't add you to a group [19:59:22] ah. there we go [19:59:26] negative cache, most likely [19:59:27] i'm in [19:59:50] ok. you own test/mediawiki [20:00:09] in the interface, you can edit the rights at Admin->Projects [20:00:22] and other project related things for it [20:00:33] so, you can play around with it, and figure out the settings you guys want to use [20:00:46] the permissions are kind of confusing at first [20:01:10] hmm [20:01:25] ? [20:01:30] Reedy: thnx for up'ing test wiki, refresh issue appears to be fully fixed now :) [20:01:38] Ryan_Lane, ok this is the worst UI ever :) [20:01:39] it's possible you'll need to log out and back in for your group settings to take effect [20:01:42] yes [20:01:43] yes it is [20:01:54] http://gerrit.googlecode.com/svn/documentation/2.2.1/access-control.html [20:02:07] and 2.2.1's documentation isn't 100% up to date [20:02:16] welcome to the wonderful world of open source :D [20:02:18] ok dumbass question time: how the hell do I find the master repo so I can check it out? [20:03:09] git clone ssh://brion@gerrit.wikimedia.org:29418/test/mediawiki [20:03:19] git clone ssh://brion@gerrit.wikimedia.org:29418/test/mediawiki.git [20:03:27] am i expected to divine this URL on my own, or is there someplace i could find it other than asking you? :) [20:03:27] I think the first implies the second, though [20:03:42] divine :) [20:03:51] it's in the docs, somewhere [20:04:02] but, all repos are from the root [20:04:12] ok i'm just gonna say right out that this isn't an acceptable UI to make our developers deal with. we need that..... completely redone long before a migration of mediawiki code [20:04:47] how do people know how to checkout the svn repo right now? [20:05:10] there's a documentation page telling them what the urls are and giving sample checkout lines [20:05:12] wassup? [20:05:19] yeah. we have the same for the puppet repo [20:05:33] compare with gitorious & github's git management UIs, which produce those directions straight on the repo's overview page in the web ui [20:07:04] **** [20:07:11] Broken code made it onto mw.org [20:07:28] brion: I don't disagree that the interface sucks [20:08:45] it works fairly well for code review, though [20:09:17] though I'd like to see a unified diff view like we have on mediawiki.org [20:09:33] and free-form tags, like we have [20:09:33] brion: Ryan_Lane: I need someone to push r100442 to mw.org ASAP [20:09:40] Reedy just left :? [20:09:43] :/ [20:09:47] you're talking to the wrong person here [20:09:56] Well, who do I poke [20:09:56] same with brion [20:10:09] who deployed it? [20:10:13] Reedy [20:10:18] and he left? [20:10:22] Yeah [20:10:26] that's completely unacceptable [20:11:19] I'm going to text him [20:12:10] anyone else with deploy access around? [20:12:37] *^demon is [20:12:42] though I have access, I don't really know what I'm doing [20:12:45] <^demon> Merge + deploy 100442? [20:13:05] I only actually ever deploy config files, and occasionally deploy small code tweeks [20:13:16] JeroenDeDauw: ? [20:13:18] ^^ [20:13:46] ^demon: yeah [20:14:36] <^demon> On it. [20:15:18] brion: I could integrate gerrit into mediawiki, via an extension [20:15:24] and create repo pages when repos are created [20:15:36] and have the documentation controlled via templates [20:15:45] Ryan_Lane, ok so I managed to push a commit to HEAD:refs/for/master and it gave me back a link: https://gerrit.wikimedia.org/r/429 [20:15:52] which takes me to a nice empty list [20:15:53] yep [20:16:00] which seems odd [20:16:05] it isn't empty to me [20:16:07] where's my change? do i have to jump through more hoops? [20:16:17] I see your change [20:16:21] i don't [20:16:26] which is highly disturbing [20:16:31] lemme look at the permissions on your project [20:16:39] heh [20:16:52] your project has no rights :) [20:16:57] do the perms default to "completely fucked and useless"? [20:16:58] nice [20:17:09] mostly, yes [20:17:16] that's on purpose [20:17:21] we have some repos that need to be private [20:17:40] however.... [20:17:56] for extensions and such, we can make an extensions repo, and make all extensions children of that [20:18:07] so i'm a bit baffled [20:18:09] so proper permissions are there on creation [20:18:13] it says Owner [ALLOW] mediawiki [20:18:17] which sounds.... okish? [20:18:20] or is that totally deceiptive? [20:18:27] yes. [20:18:33] owner means you can change the project properties [20:18:59] ^demon: can you also grant me bureaucrat on mw.org, so I can have a look at the contest stuff myself? [20:20:48] brion: go to the change now [20:20:51] brion: I added permissions [20:21:07] the All-Projects permissions may be a little wonky for owners [20:21:15] which is why you were able to push, but not see the change [20:21:24] I'm still working things out, slightly [20:22:21] if it makes you feel any better, gitorious doesn't seem to have any documentation for configuration at all [20:22:24] christ that's a lot of settings [20:22:29] do we have to manually set that on every repo? [20:22:33] no [20:22:37] that's what I was saying :) [20:22:42] we can make a parent repo [20:22:58] and all children will automatically get the parent's access settings [20:23:17] ok so is "Owner" a permission, rather than a reference to who gets the permission? [20:23:19] all repos get the "All-Projects" settings [20:23:39] gitorious doesn't need any such settings to be set, so i wouldn't expect to see documentation for it :) [20:23:56] to host your own, I'm sure there is ;) [20:24:13] long as they don't have to be added all the time for no apparent reason [20:24:31] nah. no need for all that [20:24:41] parent repo ftw [20:25:01] All-Projects is set up to be fairly restrictive so that we can have private repos [20:25:03] ok now i can see my own change [20:25:18] you can also code review and merge your own change too [20:26:27] is there documentation explaining what "review", "submit patch set 1", and "abandon change" will do exactly? [20:27:03] in gerrit's documentation, yes [20:27:13] https://gerrit.wikimedia.org/r/Documentation/index.html <- can you point me to which part of this has it? [20:27:17] cause i'm looking and i'm fucking lost [20:27:46] *Ryan_Lane groans [20:27:47] maybe not [20:28:23] http://source.android.com/source/submit-patches.html [20:28:23] ^demon: did the code get deployed? [20:29:12] but in brief, it does what you'd expect. review lets you review. submit submits it, and abandon makes it go away [20:29:21] you must review before submitting [20:29:31] i'm looking at that url and.... i see nothing about those buttons [20:29:34] it'll tell you so if you click it before a review is done [20:30:14] if i hit 'submit patch set 1' the screen goes semi-dark and shows 'Application Error - Server Error - Requires Verified - [Continue]' [20:30:19] so.... i guess i can't do that [20:30:19] yes [20:30:27] you need to review it first [20:30:41] why the hell doesn't it gray the button out then? [20:30:42] verified would get set automatically by the tests [20:30:48] that would be nice [20:30:52] jeebus [20:30:54] I'd prefer it didn't even have the button there [20:31:01] because you can submit on review [20:32:07] the +2 "looks good to me, approved" and +1 "Looks good to me, but someone else must approve" under "Code Review" -- is "approval" a specific state in gerrit jargon? or is that just some vague description? [20:32:31] gerrit jargon. I think that text is modifiable [20:32:53] same with verified [20:33:02] hmm [20:33:08] we can also add or remove fields there, I believe [20:33:08] so how can i tell if somehting's approved or not? [20:33:18] is that distinct from verified? [20:33:23] https://gerrit.wikimedia.org/r/#change,428 [20:33:24] see that [20:33:43] notice it has a reviewer that marked code reviewed and verified [20:33:51] it also shows the level at which they did it [20:34:14] verified is distinct [20:34:26] we use it for whether something passes or fails a test [20:34:31] if two people give a +1 is that the same as a +2? [20:34:48] is approved just 'hit at least +2 total'? [20:34:58] or is it a 'you give approved or you don't' thing? [20:35:10] that's a good question. I should check. it doesn't matter much the way we do things in the ops repo [20:35:21] let's see :) [20:35:38] doesn't add together [20:36:06] I'm pretty sure that's an open feature request [20:36:48] http://code.google.com/p/gerrit/issues/detail?id=757&q=code%20review&colspec=ID%20Type%20Stars%20Milestone%20Status%20Priority%20Owner%20Summary [20:36:58] openstack people are asking for that as well [20:37:24] hmmm ok i've bumped it up through approval and did 'submit patchset 1' [20:37:40] now that button turned into 'revert change', otherwise nothing else obvious happened on the page [20:38:00] Change has been successfully merged into the git repository. [20:38:11] ah there it is [20:38:19] aha! the comments section is backwards from what i thought ;) [20:38:22] status also changed to merged [20:38:26] +1 [20:38:31] ok that at least mostly makes sense ;) [20:38:34] heh [20:38:35] yeah [20:38:40] Ryan_Lane, thx for the walk-through :DD [20:38:43] the review process isn't bad when you get used to it [20:38:52] unified diffs would be nice though [20:38:55] *nod* [20:39:01] i'll ponder on some ways to make it mucho nicer ;) [20:39:01] one nice feature is inline comments [20:39:32] nom nom [20:39:38] look at the change now [20:39:52] specifically the unified diff of readme [20:40:18] or the side-by-side, really [20:40:27] nice [20:40:36] the workflow for adding those is very non-intuitive [20:40:43] but once you know it is easy enough [20:40:47] yeah [20:40:59] double-click the line, add the comment, save the comment, review the change [20:41:08] part of me is saying 'does this have a rest api so we can just replace the entire front-end?' ;) [20:41:10]