[05:45:38] 10MediaWiki-Core-Team, 10Librarization, 10MediaWiki-Installer, 7Composer, and 2 others: composer.json should be useable by WMF, core and extensions - https://phabricator.wikimedia.org/T67188#1509715 (10JeroenDeDauw) Not sure this is fully resolved given my concerns in https://lists.wikimedia.org/pipermail/... [19:41:40] bd808, legoktm: this sucks monkey balls: http://i.imgur.com/HqKsCFB.png [19:42:00] first, even though it may technically be an error, it is a user's first impression, so don't call it that. just say the user needs to do something first. [19:42:18] second, wth is "also" referring to? [19:42:59] third, the "e.g." in "e.g. via composer" tells the user: "you are in for an indeterminate amount of additional work; composer is one of several things you potentially need to do" [19:43:17] ori: git + web installer? [19:43:20] yeah [19:43:29] also, the first message about external dependencies precedes the heading "external dependencies" [19:43:32] so don't do that? ;) [19:43:47] I agree that the messages are lame [19:44:01] but have only had people like you yelling at me about them [19:44:06] and no real help [19:44:09] so ... [19:44:42] tarball install *should* just work [19:45:01] as legoktm did a bunch of work there to get the composer libs bootstrapped [19:45:29] tarball + web installer will work without needing composer [19:46:04] git + web installer works fine if you follow the instructions on https://www.mediawiki.org/wiki/Download_from_Git [19:47:44] As I recall that error output is shared with all entry points and not tailored for the installer [19:47:50] ori: submit a patch improving the wording? :) [19:47:50] (or at least file a bug please) [19:47:51] (which should die in a fire) [19:47:59] i'll submit a patch [19:48:06] awesome [19:48:07] it's good that other workflows are smoother [19:48:51] but "clone from git, point web browser at localhost" is kind of the norm, we shouldn't neglect that [19:49:43] defining the "norm" of installing MW is dangerous [19:50:01] as we have no empirical measurements at all [19:50:55] if that's the norm, let's stop doing tarball releases [19:51:27] I'd still like to see a whole team dedicated to this stuff honestly [19:51:43] packaging, 3rd party support issues, etc [19:52:18] I lost interest in pursuing it with mgmt after the reorg slap in the face though [19:52:23] maybe we should join TODO Group [19:52:30] :P [19:52:45] and the PSR group too [19:53:04] and probably lots of other things, IF the WMF is going to invest in FLOSS [19:53:09] bug ass if [19:53:14] *big [20:04:20] bd808, legoktm: https://people.wikimedia.org/~ori/mw/ [20:05:18] legoktm: and before you say anything: the omission of "--no-dev" is deliberate; better to have a few extra libraries installed than complicate things. [20:05:18] +1 [20:05:56] it was dumb that composer made dev mode default [20:06:15] that was a fairly recent change [20:07:58] Heh [20:08:25] Looks nice :D [20:09:41] I don't have the presence of mind right now to carefully merge the text into our code / HTML so I'll file a bug for now [20:16:17] legoktm: bd808: You're probably aware... the exception logs on tin aren't really human readable any more [20:16:39] hoo: yes. I need to find a bit of time to look into that more [20:16:47] it's monolog fallout [20:16:58] at least you have traces again now ;) [20:34:26] SMalyshev: Followup from SoS-- I think I'm waiting on you to resolve the deleted entity issue in WQDS before the security review is closed [20:34:43] But let me see where that was at... [20:35:38] csteipp: deleted entity may take quite some time, since it may require mediawiki and/or wikidata code patches... I don't think we should hold everything for that, given such deletes are extremely rare and can be easily fixed manually [20:35:54] and there are about 2 people that can do it anyway [20:36:47] we pay put a note on Wikidata suppression page saying 1) don't do it 2) if you still do it, tell Discovery team [20:37:58] There are definitely more than 2 users with suppress rights... so it does need some mitigation before we go into production. [20:38:17] Mostly stewards [20:39:18] I see one item suppression this year and two last year [20:40:05] That seems manually manageable, but you have to be aware that in case Wikidata becomes a target for some long term abuse that can rise significantly [20:41:09] hoo: Yeah, exactly. Do you think the problem has been communicated enough to the stewards that if we're hit with a bunch of abuse, they're going to do the right process for wqds? [20:41:38] No, not at all, they have no idea [20:41:59] We will need a warning on the page AND a mail to stewards-l [20:42:59] SMalyshev: So with ^, I think we can resolve that part of the issue, as long the teams committed to working out a way to handle it automatically. [20:43:34] yes, we definitely need to put a note there. [20:43:51] and we're not abandoning fixing it, just because it takes time I don't want to block on it [20:44:01] If it's easy to manually fix, you can also post the steps to ops-l so that everyone with cluster access can run the queries [20:44:27] AFAIR it only needs a tunnel from the bastion to some host to be able to post queries [20:45:03] yeah it's literally one line: https://www.mediawiki.org/wiki/Wikidata_query_service/Implementation#Updating_specific_ID [20:45:34] ok, so that needs shell on the server [20:45:37] but all ops have that [20:45:42] ah, yes, that it does [20:45:53] you can't modify the DB from the outside [20:46:04] nice [20:46:14] I though only hte nginx(?) proxying was preventing that [20:46:37] well, it listens only to localhost, so you can go either from shell or from nginx proxy [20:46:52] since nginx proxy won't let you do POST, your only option is to go to shell [20:47:04] "it" being blazegraph in that case [20:49:28] hoo: well, strictly speaking you don't need shell as such, you need local login and tunnel :) but if you can do that you probably have shell too [20:49:47] Yeah, we don't hand out that kind of access [20:53:04] and afaik all ops have access to prod machines [20:53:14] so where wikidata keeps its official oversight policy? [20:53:52] I found this: https://www.wikidata.org/wiki/Wikidata:Oversight but that's describes who oversighters are, not rules for applying suppressions and such [20:58:13] SMalyshev: That would be https://meta.wikimedia.org/wiki/Oversight_policy [20:58:46] hoo: that's wikimedia policy, doesn't wikidata have separate one? [20:59:04] no, such things are usually not locally governed [20:59:16] at least not as much as other things [20:59:41] Suppression is a very serious matter [21:00:25] hoo: so maybe put a note on https://www.wikidata.org/wiki/Wikidata:Oversight and also send something to stewards at wikimedia.org and oversight at wikidata.org? [21:01:09] Yes for the note, but you should post to the stewards mailing list, not the OTRS one [21:01:16] and contacting oversighters is hard, I guess [21:02:29] so: select count(*) from logging where log_type='suppress' and log_timestamp > '20150000000000'; [21:02:38] 13 [21:02:49] not so many, not so few [21:04:08] you could expect that requests to manually delete crap would create some hassle, and that at least a couple of time the oversighting person will foget about it [21:05:05] MaxSem: We only care for full item suppressions here [21:05:34] or properties, but that will never happen, I guess (only a small group of people can create these) [21:06:50] i.e. log_action='delete'? [21:07:10] yeah, I think so [21:07:25] most suppression are just user names or old revisions and such [21:07:50] I already looked through the log, see above [21:08:01] but I did it by scanning the page on wiki [21:08:04] yeah the only problem is delete suppression [21:08:19] delete suppression of item/property even [21:13:19] hoo: So something like this: https://www.wikidata.org/wiki/User:Smalyshev_(WMF)/Oversight_note [21:13:46] csteipp: ^ does it look ok? [21:14:30] I doubt they all know about ops... and I doubt all ops know about Blazegraph [21:14:37] Maybe clarify that? [21:14:44] Name the IRC channel or so? [21:14:52] ok [22:21:57] SMalyshev: Yeah, that's probably good enough [22:25:44] csteipp: ok, I'll try to see how to add it to the policy page [22:28:14] tgr: on the statsd patch, the MediaWiki prefix would still exist too, this would just keep our stuff separate from any other MW install that happened to point at labmon1001.eqiad.wmnet [22:28:40] So stats would become beta-cluster.MediaWiki.foo.bar.baz [22:29:20] If we don't do that then the data *might* get pollution from other traffic sources that can hit that server (all of Labs) [23:37:38] Krinkle, "neccecary"? :P [23:38:11] https://gerrit.wikimedia.org/r/#/q/owner:Krinkle+message:neccecary,n,z [23:38:32] The word necessary is unnecessarily complicated for me. [23:38:47] https://gerrit.wikimedia.org/r/#/c/227627/21/includes/OutputPage.php [23:39:44] Krinkle: Also 'specifity' ;-)