Re: [Wikitech-l] Merge Vector extension into core
Vector is a weird mess of extensions to the skin, extensions to general functionality, and unused broken scripts. Merging it properly would require some work and some deleting. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Merge Vector extension into core
On Wed, 06 Feb 2013 04:31:13 +0100, Tim Starling tstarl...@wikimedia.org wrote: On 06/02/13 00:12, Matma Rex wrote: Vector is a weird mess of extensions to the skin, extensions to general functionality, and unused broken scripts. Merging it properly would require some work and some deleting. That sounds like a good reason to merge it. I'm not saying I'm against that, not at all. I'm just noting that Vector is... weird, and it might be harder than it looks. For example, the new editing interface cleanup now live on en.wiki is for some bizarre reason part of Vector, and it's completely not compatible with other wikis at all right now. On Wed, 06 Feb 2013 06:49:56 +0100, K. Peachey p858sn...@gmail.com wrote: Well now would probably be a good time to start working on the list of the features, and discuss what people want (weather its certain parts in core or whatnot), what is broken and what is undesired and go from there. and look at the best solution for the outcome from there. Now this is simple, I think; we take everything that is enabled by default right now and move it to core (that would be collapsible tabs and collapsible nav), and completely kill the rest (that would be some weird features which you can't even opt-in to on WMF wikis and edit warning functionality which basically breaks stuff all over in my experience). -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Extending the action=options API with storing arbitrary preferences
Yesterday, per the extended discussion on bug 40124, gerrit change I5f9ba5b0 has been merged. It extends the action=options API, essentially allowing user scripts, gadgets, and external editors to store arbitrary persistent private data in user preferences. [ https://bugzilla.wikimedia.org/40124 / https://gerrit.wikimedia.org/r/#q,I5f9ba5b0,n,z ] This officially reenables the feature that was present, but undocumented and defective in MW 1.20 (saving preferences using Special:Preferences cleared any additional fields) and which has been disabled in 1.20.1 as a part of a security fix (bug 42202 / gerrit I98df55f2). [ https://bugzilla.wikimedia.org/42202 / https://gerrit.wikimedia.org/r/#q,I98df55f2,n,z ] These semi-arbitrary options have only three limitations imposed on them: * the key must start with userjs- prefix (to avoid conflicting with new options being added in core or in extensions) * the length of the key must not exceed 255 bytes (this is a database schema limitation) * the key must consist only of ASCII letters, numbers, hyphens and underscores (a-z, A-Z, 0-9, _, -; for sanity) There are currently no hard limits on the length nor contents of the value, as well as on the number of additional preferences. The contents of these preferences are not escaped, sanitized nor validated in any way; script authors are expected to sanitize them themselves to prevent XSS attacks and other security vulnerabilities. Similar care should be taken if they are ever shown anywhere in the Special:Preferences interface. Two low-severity sister issues are left to be solved right now: * bug 43959 - action=options API should allow resetting of chosen preferences (instead of the all-or-nothing approach) * bug 43960 - Arbitrary userjs- preferences should be shown in the GUI, with the possibility of clearing them one-by-one [ https://bugzilla.wikimedia.org/43959 / https://bugzilla.wikimedia.org/43960 ] Overall, this could be a replacement for the current system of storing settings as global variables set in user's skin.js file, or in a separate .js file with gadget configuration, or in cookies / localStorage, which all have their drawbacks (clumsy, non-private, force an edit on-wiki to change prefs, volatile, possibly size-limited...). I'm quite looking forward to this happening :) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extending the action=options API with storing arbitrary preferences
On Mon, 14 Jan 2013 15:42:35 +0100, Tyler Romeo tylerro...@gmail.com wrote: About the two sister issues that are still open (bug 43959 and 43960), unless somebody beats me to it, I will work on resolving those sometime tonight or tomorrow night. Thanks! Additionally, one thing we might want to change is at the very least doing a quick length check on userjs- options just to make sure they fit in the database, although it shouldn't really be an issue. Well, these fields are BLOBs, so any length should work as long as you have enough disk space. ;) The length of the key (which is a VARBINARY(255)) is checked. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extending the action=options API with storing arbitrary preferences
On Mon, 14 Jan 2013 17:48:32 +0100, Brad Jorsch bjor...@wikimedia.org wrote: On Mon, Jan 14, 2013 at 9:49 AM, Matma Rex matma@gmail.com wrote: Well, these fields are BLOBs, so any length should work as long as you have enough disk space. ;) The length of the key (which is a VARBINARY(255)) is checked. Not true, a BLOB can hold 65535 bytes maximum. That's short enough that it probably is worth adding a length check to the API. Huh. I guess I was under the mistaken impression that MySQL is reasonable. Thanks for the clarification. (I just checked the default size limits for similar fields on SQLite and Postresql: 1 gigabyte for both. Yay for MySQL.) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problems uploading word 2007 .doc files
On Mon, 07 Jan 2013 23:47:58 +0100, Aran Dunkley a...@organicdesign.co.nz wrote: Hello, can someone please help me with this .doc upload problem? I've tried everything and even setting $wgVerifyMimeType to false fails to solve it. No matter what I do I keep getting the following error when I upload *some* word 2007 .doc files: The file is a corrupt or otherwise unreadable ZIP file. It cannot be properly checked for security. I don't know how that check can even be happening with $wgVerifyMimeType disabled, but still the error occurs?! Word 2007 uses a .docx format as far as I know, not .doc. Which one were you using in your configuration? Also, .docx files are essentially ZIP files with magic data inside. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] monitoring / control system for bots
On Sat, 05 Jan 2013 10:03:13 +0100, Matthew Flaschen mflasc...@wikimedia.org wrote: For example, on pl.wiki, there are basically only two kinds of bots: interwiki-only and multipurpose. As long as you're not breaking anything using the bot and not doing anycontroversial changes, if you've gotten the flag, you can do any task you deem necessary. A bot control in this case simply wouldn't work. Bots could still tell the dashboard what they're working on, even if they don't need permission to add a new task. In this case, when you're saying bots, you actually mean users, as for one-time runs it would end up being the user's job. This simply seems impractical. And if we try to make a compromise by making the bots automatically report edit summaries somewhere, then well, what's the improvement over simply looking at recent changes? You could make a summary of last edits by bots using two lines of code and one API call, no need for a control systems. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] monitoring / control system for bots
On Fri, 04 Jan 2013 05:42:45 +0100, Lars Aronsson l...@aronsson.se wrote: On 01/02/2013 06:11 PM, Matthew Flaschen wrote: Every wiki has a different approach to bots. But for English Wikipedia, that is not how the approval process (https://en.wikipedia.org/wiki/Wikipedia:BOTAPPROVAL) works: Small changes, for example to fix problems or improve the operation of a particular task, are unlikely to be an issue, but larger changes should not be implemented without some discussion. Completely new tasks usually require a separate approval request. Bot operators may wish to create a separate bot account for each task. That is what the rules say, but do you have any science to back up that this is also how it works in practice? How many bot accounts are revoked each month because their owners were naughty and used their bots in a different manner from what they applied for? The idea with a bot account, after all, is that nobody bothers to watch your edits in the Recent Changes. I think you can go forward if you accept that there are some bots that run like a machinery, according to the rules, and other bot accounts that are used like a more advanced browser for a creative and spontaneous user. You are both assuming that there are no other wikis except for the English Wikipedia. For example, on pl.wiki, there are basically only two kinds of bots: interwiki-only and multipurpose. As long as you're not breaking anything using the bot and not doing anycontroversial changes, if you've gotten the flag, you can do any task you deem necessary. A bot control in this case simply wouldn't work. Not to mention that I think *most* of the bots n pl.wiki are ran from users' home computers, most often on AWB or a local pywikipedia install, but there are at least three people who use their own libraries, including myself. And if this is an en.wiki-only matter, this isn't really the right list to discuss it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Full name in Gerrit
There's a bug for everything, and they're all waiting... https://bugzilla.wikimedia.org/show_bug.cgi?id=40061 (It should only take half a day to make this happen, but apparently nobody took any action since September last year.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit code review guidelines
On Fri, 28 Dec 2012 22:27:36 +0100, Matthew Flaschen mflasc...@wikimedia.org wrote: My understanding is you *should* use it. Jenkins only does V+1, which is Checked. V+2 is required for some/all repos (e.g. extensions). Normally, the original developer at least should provide Verified (since they should have tested their own code). Jenkins does both: V+1 is for lint check, V+2 is for unit tests. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit code review guidelines
I think that nobody bothered with documenting because the process itself is greatly in flux now. People are e.g. working on sandboxing the unit tests, so they can be safely run on patchset submission, so jenkins could just use one Verified level after running all tests. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Distinguishing disambiguation pages
On Mon, 24 Dec 2012 11:00:36 +0100, Jon Robson jdlrob...@gmail.com wrote: Last week I was working on a feature that I didn't want to surface on a disambiguation page. I was surprised to find there was no way I could distinguish between a normal article and a disambiguation page. The disambiguation pages have no clearly marked templates I can use and they are in the same namespace as normal articles. What about [[MediaWiki:Disambiguationspage]]? -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to speed up the review in gerrit?
On Thu, 20 Dec 2012 14:20:07 +0100, Merlijn van Deen valhall...@arctus.nl wrote: It's possible to do it the other way around - people can /subscribe/ to a project via https://gerrit.wikimedia.org/r/#/settings/projects and receive e-mails when new patchsets are uploaded. I don't think this adds people to the reviewers list, but at least people get notified. It sends you a mail and adds the change to the Watched Changes tab on your dashboard. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to speed up the review in gerrit?
You could add people as reviewers, or personally ask someone to review, prefereably someone who worked on the extension in the past. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to speed up the review in gerrit?
On Wed, 19 Dec 2012 22:55:24 +0100, Matthew Flaschen mflasc...@wikimedia.org wrote: On a simpler note, why does it have your name as Parent5446? https://gerrit.wikimedia.org/r/#/dashboard/278 Can someone fix this? There's a bug for that: https://bugzilla.wikimedia.org/show_bug.cgi?id=40061 I've been wanting to fix my name for ages as well... -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
