[Wikitech-l] ICINGA Monitoring Plugin for Wikidata
Hi, Wikidata needs to monitor dispatch statistics per Bug 65291 ( https://bugzilla.wikimedia.org/show_bug.cgi?id=65291). We would like to use ICINGA to send an IRC alert if the dispatch lag exceeds a critical threshold. A nagios plugin for this (check_dispatch) has been written in Perl and we would like to have this reviewed and tested. Where and by whom could this script be reviewed? Christopher Johnson ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Unclear Meaning of $baseRevId in WikiPage::doEditContent
Hi all. We (the Wikidata team) ran into an issue recently with the value that gets passed as $baseRevId to Content::prepareSave(), see Bug 67831 [1]. This comes from WikiPage::doEditContent(), and, for core, is nearly always set to false (e.g. by EditPage). We interpreted this rev ID to be the revision that is the nominal base revision of the edit, and implemented an edit conflict check based on it. Which works with the way we use doEditContent() for wikibase on wikidata, and with most stuff in core (which generally has $baseRevId = false). But as it turns out, it does not work with rollbacks: WikiPage::commitRollback sets $baseRevId to the ID of the revision we revert *to*. Now, is that correct, or is it a bug? What does base revision mean? The documentation of WikiPage::doEditContent() is unclear about this (yes, I wrote this method when introducing the Content class - but I copied the interface WikiPage::doEdit(), and mostly kept the code as it was). And in the code, $baseRevId is not used at all except for passing it to hooks and to Content::prepareSave - which doesn't do anything with it for any of the Content implementations in core - only in Wikibase we tried to implement a conflict check here, which should really be in WikiPage, I think. So, what *does* $baseRevId mean? If you happen to know when and why $baseRevId was introduced, please enlighten me. I can think of three possibilities: 1) It's the edit's reference revision, used to detect edit conflicts (this is how we use this in Wikibase). That is, an edit is done with respect to a specific revision, and that revision is passed back to WikiPage when saving, so a check for edit conflicts can be done as close to the actual edit as possible (ideally, in the same DB transaction). Compare bug 56849 [2]. 2) The edit's physical parent: that would be the same as (1), unless there is a conflict that was detected early and automatic resolved by rebasing the edit. E.g. if an edit is performed based on revision 11, but revision 12 was added since, and the edit was successfully rebased, the parent would be 12, not 11. This is what WikiPage::doEditContent() calls $oldid, and what gets saved in rev_parent_id. Since WikiPage::doEditContent() makes the distinction between $oldid and $baseRevId, this is probably not what $baseRevId was intended to be. 3) It could be the logical parent: this would be identical to (2), except for a rollback: if I revert revision 15 and 14 back to revision 13, the new revision's logical parent would be rev 13's parent. The idea is that you are restoring rev 13 as it was, with the same parent rev 13 had. Something like this seems to be the intention of what commitRollback() currently does, but the way it is now, the new revision would have rev 13 as its logical parent (which, for a rollback, would have identical content). So at present, what commitRollback currently does is none of the above, and I can't see how what it does makes sense. I suggest we fix it, define $baseRevId to mean what I explained under (1), and implement a late conflict check right in the DB transaction that updates the revision (or page) table. This might confuse some extensions though, we should double check AbuseFilter, if nothing else. Is that a good approach? Please let me know. -- daniel [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=65831 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=56849 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Adding external libraries to core (SwiftMailer)
Yes. we will have the third party code kept in a separate repo though. Currently, mw users have to run : sudo apt-get install php-pear sudo pear install mail sudo pear install Net_SMTP to install the pear and mail package to get mail working. After this patch, and composer loded with the swiftmailer configs as per (https://gerrit.wikimedia.org/r/#/c/135290/10/composer.json), the user just have to give php composer.phar install from core. and Swift gets auto loaded. Thanks, Tony Thomas FOSS@Amrita where there is a wifi, there is a way On Wed, May 28, 2014 at 10:43 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 05/27/2014 11:57 AM, Bryan Davis wrote: I think we should create a new repository in gerrit (mediawiki/core/contrib? Bikeshed as needed) where composer is used to manage importing specific versions of external libraries that are needed for the wiki[mp]edia cluster deployments. Is the idea that third-party users would use Composer to install these libraries? Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On Wed, May 28, 2014 at 02:00:36PM +0200, Stephan Gambke wrote: You are late. ;-) A type mediawiki-skin exists. Oh, fantastic :) Thanks for letting me know. It would probably be good to add this info to the Manual:Skinning/Tutorial page. I'll do that when I've made it work for Erudite, if someone doesn't beat me to it. Nick ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unclear Meaning of $baseRevId in WikiPage::doEditContent
On Wed, May 28, 2014 at 7:25 AM, Daniel Kinzler dan...@brightbyte.dewrote: If you happen to know when and why $baseRevId was introduced, please enlighten me. When is easy enough: http://mediawiki.org/wiki/Special:Code/MediaWiki/34987 If I had to guess at the why, I'd guess it was probably for FlaggedRevs and auto-reviewing. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ICINGA Monitoring Plugin for Wikidata
On 05/28/2014 07:11 AM, Christopher Johnson wrote: Hi, Wikidata needs to monitor dispatch statistics per Bug 65291 ( https://bugzilla.wikimedia.org/show_bug.cgi?id=65291). We would like to use ICINGA to send an IRC alert if the dispatch lag exceeds a critical threshold. A nagios plugin for this (check_dispatch) has been written in Perl and we would like to have this reviewed and tested. Where and by whom could this script be reviewed? You can consider putting it in operations/puppet (https://git.wikimedia.org/tree/operations%2Fpuppet) if it makes sense to deploy and run it with Puppet. It looks like there is already a Nagios plugin in Puppet for the job queue. Please also specify a license for the script. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SVG linking of external images/bitmaps - xlink:href should support http(s) resources
On Tue, May 27, 2014 at 10:10 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote: On 05/27/2014 10:52 PM, Brian Wolff wrote: I specifically said bits.wikimedia.org and upload.wikimedia.org (and not commons.wikimedia.org), neither of which host user JavaScript. Matt Flaschen Gadgets are on bits and they are user controlled. Ditto for mediawiki:common.js et al. (Unless you mean users as in non admins). I see no usecase from allowing from bits. If someone wants an extension asset they can upload it. You're right, I was completely wrong about the user JavaScript. Actually, user scripts are on bits too. Conceivably, it could limit it to directories starting with static-..., but that starts getting complicated. It's probably safer to limit it to user-uploaded Commons files as you said. It *should* be difficult to get javascript to run inside an image-- you would have to find an element that we allow that interprets javascript source. If anyone comes up with a way, I'd be very interested in hearing about it. If the javascript is already in an svg, then it's much easier to get it to execute. But overall it's much safer to just not allow it, which is why we currently don't. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On Tue, 27 May 2014 05:28:41 +0200, Dan Garry dga...@wikimedia.org wrote: I am not a developer and therefore I cannot speak for them, but from a product perspective I have no insurmountable issues with either the /skins/ or the /extensions/ solution. It seems that there's pros and cons for each solution, so as long as it's handled appropriately (and it certainly seems to me like you're doing that), then you've got my support. So, I'm proposing an experiment: We can evaluate this almost painlessly by converting the current Nostalgia extension-skin to a skin in my proposed format, deploying it on nostalgia.wikimedia.org (after doing whatever changes are necessary to deployment things first) and seeing what happens. Well, you've got my endorsement! How can I help you make this happen? It just so happened that Chad has recently merged a parallel set of changes that moved two skins out of core – Modern and Cologne Blue (https://gerrit.wikimedia.org/r/#/c/118345/ and linked patches) – and today he submitted patches that would make it possible to deploy the two new repositories in the skins/ directory. (Thanks Chad!) See https://bugzilla.wikimedia.org/show_bug.cgi?id=65868 about the progress. This is going to roll out with tomorrow's deployment and should be unnoticeable for users. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
