Re: [Wikitech-l] Deletion schema
Hi, There's another discussion happening at enwiki at the moment about the stalled rollout of RevisionDelete for admins; which is backed up in the chain of bugs which boils down to our deletion mechanism is borked. Indeed. Basically, we have two deletion schemas in parallel at the moment, one of which is only half-complete, the other one sucks in many ways. I don't know if others share that view, but imho the long-term goal is to make RevisionDelete powerful enough to eventually replace the old deletion schema. See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=21279#c7 Reviewing the whole deletion mechanism was on the topic list for the last dev meetup, but AFAIK despite that event running for three times as long as it was expected to, it never got raised? I think this would be as good a time as any to do so. Do we have any clear idea or overall plan for page and revision deletion, the archive table, a page_deleted field, a deleted_page table, etc etc?? I don't know why you think the meetup was three times as long as expected. Just because some devs were stuck in Berlin doesn't mean the conference magically continued on these days. IIRC we didn't talk about RevisionDelete, because there were some other urgent issues (GSoC and general organization). I'd really love to talk about RevisionDelete at Wikimania and would encourage anyone submitting a proposal for a workshop on that. Regards, Church of emacs signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] js2 extensions / Update ( add-media-wizard, uploadWizard, timed media player )
On 05/18/2010 08:53 AM, Michael Dale wrote: But in general its probably better / easier for end users to just identify their platform and whats not working, since its all code to them anyway. If they are a developer or are going to do something productive with what they are seeking they likely have the code checked out locally and use the debug mode. The problem here is Wikimedia sites. If you leave the debug mode off and serve fully minified scripts on WMF sites, the hundreds if not thousands of people who develop user/site scripts for them will have a very hard time debugging anything that involves interactions with the minified code. If you turn debug mode on permanently, you lose most of the benefit of having a minifier to begin with (Wikimedia being the single biggest user of MediaWiki). Then there's also the problem that the MediaWiki environment on Wikimedia sites can be quite different from a stock install, and duplicating enough of it on a test wiki to be able to reproduce a Wikimedia-specific bug may be quite difficult -- particularly so if you have to do this before you even know where the bug occurs, because you couldn't do any useful debugging due to the code being minified. I'd like to second Aryeh's suggestion to at least tweak the minifier to leave newlines intact (although collapsing multiple consecutive newlines to one would be OK, I guess). That way users could at least set up useful breakpoints and receive error messages that tell more than which file the problem occurred in. (Part of the blame here goes to the debuggers, of course. If common JavaScript debugging tools like Firebug could do things like expand minified code and set up breakpoints on individual statements rather than just lines, minification would be much less of a problem for debugging. But currently, as far as I know, they don't.) -- Ilmari Karonen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deletion schema
church.of.emacs.ml church.of.emacs...@googlemail.com wrote in message news:4bf2632f.8000...@googlemail.com... Hi, There's another discussion happening at enwiki at the moment about the stalled rollout of RevisionDelete for admins; which is backed up in the chain of bugs which boils down to our deletion mechanism is borked. Indeed. Basically, we have two deletion schemas in parallel at the moment, one of which is only half-complete, the other one sucks in many ways. I don't know if others share that view, but imho the long-term goal is to make RevisionDelete powerful enough to eventually replace the old deletion schema. See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=21279#c7 Reviewing the whole deletion mechanism was on the topic list for the last dev meetup, but AFAIK despite that event running for three times as long as it was expected to, it never got raised? I think this would be as good a time as any to do so. Do we have any clear idea or overall plan for page and revision deletion, the archive table, a page_deleted field, a deleted_page table, etc etc?? I don't know why you think the meetup was three times as long as expected. Just because some devs were stuck in Berlin doesn't mean the conference magically continued on these days. That *was* a joke... :-P I think fundamentally this is an area where a solution which is super-efficient at *everything* is technically impossible, and we have various methods, implemented or proposed, which resolve some issues at the expense of others. It's mainly a question of working out what we definitely need to achieve, and what we can afford to be expensive/slow actions (for instance, one out of reading deleted revisions, and *restoring* deleted revisions, pretty much has to be expensive). Right now everyone who has ideas for *an* implementation isn't working on it because they don't know if it's *the* implementation we want. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deletion schema
It is a generic problem, but it has particularly nasty interactions with RevisionDelete: fundamentally, it can become impossible to tell when, why or by whom a RevDel'd revision was deleted. The other manifestations of the lunacy of identifying deleted revisions by timestamp rather than revision id are not so serious, but these definitely are. Identifying deleted revisions by id rather than timestamp is a lot of work in itself; not least of which is writing and running a script to fill in all the null values for old deleted revisions on WMF wikis. There's no point in doing that if the 'grand plan' is to move away from having an archive table altogether. But equally this is an issue which does badly need work done. Hence the question, what *is* the grand plan? --HM -- From: Andrew Garrett and...@werdn.us Sent: Tuesday, May 18, 2010 3:05 PM To: Happy-melon happy-me...@live.com; Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Deletion schema On Tue, May 18, 2010 at 8:24 AM, Happy-melon happy-me...@live.com wrote: There's another discussion happening at enwiki at the moment about the stalled rollout of RevisionDelete for admins; which is backed up in the chain of bugs which boils down to our deletion mechanism is borked. Reviewing the whole deletion mechanism was on the topic list for the last dev meetup, but AFAIK despite that event running for three times as long as it was expected to, it never got raised? I think this would be as good a time as any to do so. Do we have any clear idea or overall plan for page and revision deletion, the archive table, a page_deleted field, a deleted_page table, etc etc?? I promised to activate single-revision deletion for admins months ago, and then again after the last software update. I finally got to it tonight. Church of Emacs points out this bug, but it looked as though it was a generic problem with our previous deletion system, and not an additional problem caused by single-revision deletion (indeed, it appears to be mitigated by the use of single-revision deletion instead of the old delete/undelete method). https://bugzilla.wikimedia.org/show_bug.cgi?id=21279 -- Andrew Garrett http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deletion schema
On Tue, May 18, 2010 at 9:21 AM, Happy-melon happy-me...@live.com wrote: It is a generic problem, but it has particularly nasty interactions with RevisionDelete: fundamentally, it can become impossible to tell when, why or by whom a RevDel'd revision was deleted. The other manifestations of the lunacy of identifying deleted revisions by timestamp rather than revision id are not so serious, but these definitely are. Identifying deleted revisions by id rather than timestamp is a lot of work in itself; not least of which is writing and running a script to fill in all the null values for old deleted revisions on WMF wikis. There's no point in doing that if the 'grand plan' is to move away from having an archive table altogether. But equally this is an issue which does badly need work done. Hence the question, what *is* the grand plan? --HM Or we could just ignore[1] them. 1 - http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29diff=101684983oldid=101671249 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium testing framework
On Tue, 18 May 2010 01:04:01 +0200, Markus Glaser wrote: Hi Dan, the test fails at checking the prerequisites. It tries to load the image page and looks for a specific div element which is not present if the image was not uploaded correctly (id=filetoc). This might have changed across the versions of MediaWiki. Did you install the PagedTiffHandler extension? It depends on ImageMagick, so it might have rejected the upload. Although then it should have produced an error message ;) So the other question is, which MediaWiki version do you run the tests on? Regards, Markus Hi Markus, Some further information. I originally uploaded Multipage.tiff before the extension was installed. I thought this might be the problem, so I uploaded it again after the extension was available. However, this did not solve the problem. Also, I am getting the following error from the selenium-server: 08:41:10.344 INFO - Got result: ERROR Server Exception: sessionId led to start new browser session: org.openqa.selenium.server.browserlaunchers.InvalidBrowserExecutableException: The specified path to the browser executable is invalid. doesn't exist; perhaps this session was already stopped? on session led to start new browser session: org.openqa.selenium.server.browserlaunchers.InvalidBrowserExecutableException: The specified path to the browser executable is invalid. 08:41:10.347 INFO - Command request: testComplete[, ] on session led to start new browser session: org.openqa.selenium.server.browserlaunchers.InvalidBrowserExecutableException: The specified path to the browser executable is invalid. 08:41:10.347 INFO - Got result: OK on session led to start new browser session: org.openqa.selenium.server.browserlaunchers.InvalidBrowserExecutableException: The specified path to the browser executable is invalid. I am using a LocalSeleniumSettings.php with the following parameters: // Hostname of selenium server $wgSeleniumTestsSeleniumHost = 'http://localhost'; // URL of the wiki to be tested. $wgSeleniumTestsWikiUrl = 'http://localhost'; // Wiki login. Used by Selenium to log onto the wiki $wgSeleniumTestsWikiUser = 'Wikiadmin'; $wgSeleniumTestsWikiPassword = 'Wikiadminpw'; // Use the *chrome handler in order to be able to test file uploads $wgSeleniumTestsBrowsers['firefox'] = '*firefox /usr/bin/firefox'; $wgSeleniumTestsBrowsers['ff-chrome'] = '*chrome /usr/bin/firefox'; // Actually, use this browser $wgSeleniumTestsUseBrowser = 'ff-chrome'; Regards, -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] js2 extensions / Update ( add-media-wizard, uploadWizard, timed media player )
2010/5/18 Ilmari Karonen nos...@vyznev.net: The problem here is Wikimedia sites. If you leave the debug mode off and serve fully minified scripts on WMF sites, the hundreds if not thousands of people who develop user/site scripts for them will have a very hard time debugging anything that involves interactions with the minified code. If you turn debug mode on permanently, you lose most of the benefit of having a minifier to begin with (Wikimedia being the single biggest user of MediaWiki). I have recently configured test.wikipedia.org to pull all of its JS/CSS locally rather than from bits.wikimedia.org (for better isolation) and serve all UsabilityInitiative JS/CSS in raw, multi-file format (rather than combined and minified, which we use on 'real' wikis); all of this is to aid testing. The script loader could also be configured to serve its JS minified on normal wikis and unminified on testwiki. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] js2 extensions / Update ( add-media-wizard, uploadWizard, timed media player )
On Tue, May 18, 2010 at 08:39, Ilmari Karonen nos...@vyznev.net wrote: On 05/18/2010 08:53 AM, Michael Dale wrote: But in general its probably better / easier for end users to just identify their platform and whats not working, since its all code to them anyway. If they are a developer or are going to do something productive with what they are seeking they likely have the code checked out locally and use the debug mode. The problem here is Wikimedia sites. If you leave the debug mode off and serve fully minified scripts on WMF sites, the hundreds if not thousands of people who develop user/site scripts for them will have a very hard time debugging anything that involves interactions with the minified code. If you turn debug mode on permanently, you lose most of the benefit of having a minifier to begin with (Wikimedia being the single biggest user of MediaWiki). Then there's also the problem that the MediaWiki environment on Wikimedia sites can be quite different from a stock install, and duplicating enough of it on a test wiki to be able to reproduce a Wikimedia-specific bug may be quite difficult -- particularly so if you have to do this before you even know where the bug occurs, because you couldn't do any useful debugging due to the code being minified. I'd like to second Aryeh's suggestion to at least tweak the minifier to leave newlines intact (although collapsing multiple consecutive newlines to one would be OK, I guess). That way users could at least set up useful breakpoints and receive error messages that tell more than which file the problem occurred in. I would support a url flag to avoid minification and or avoid script-grouping, as suggested by Michael Dale, or even to have a user preference for enable/disable minification in a more permanent way (so we don't need to change the url on each test: we just disable minification, debug the code and then enable it again) Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deletion schema
OQ wrote: Or we could just ignore[1] them. 1 - http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29diff=101684983oldid=101671249 I strongly disagree with brion and I hope that everyone realizes just deleting the archive table is not an option. While the archive table might have been originally designed as a temporary space to store deleted revisions, this differs greatly from the current use. Deleting 'deleted' edits would cause a major disruption on Wikimedia wikis. That being said, I appreciate Happy-melon's initiative to carefully plan a system before implementing single features without a general concept where this is going. IMHO we should discuss this at a Wikimania workshop. Anyone interested? In order to integrate those who can't make it to Wikimania, I suggest we create an onwiki schematic on the proposed deletion system. I'm still not sure whether RevisionDelete is aimed at replacing the old deletion schema completely, including the archive table. Could anyone comment on that please? Regards, Church of emacs Ps.: BTW, a question that came to my mind: Do we wish to retain our bijective Pagename -- Page relationship? (As opposed to a model, where a new page data set is created when a user creates a wiki page. Our current model has the flaw, that we can't differentiate between two completely different articles that have the same page title (e.g. if article A is deleted and someone else writes article B with the same page title – they are treated exactly the same, even though they are logically two different sets of revisions)) I'm not suggesting we drift away from our current approach, just wanted to note it has some flaws imho. signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visual impairment
Conrad Irwin wrote: Just as with image captchas, you'd need to introduce noise into it. If you are working from known constituents, you can use cross-correlation to ignore noise pretty effectively (I believe it's what humans do). The choice then is either to make the noise sound like the captcha's numbers (google's approach), which is very hard to solve (at least I find it so), or to use ReCAPTCHAs Funny. It turns out that now Recaptcha belong to Google. vast database of unknown sound files (with noise added to obscure the phonemes). The human brain is capable of filling in completely obscured phonemes in order to make the sentence make sense I wonder if we could abuse Wikimania presentations audio asking to write each word from it. (assuming they speak the language in question - another usability problem with these), Certainly. That's a very big drawback on adding audio captchas to WMF prjects. It's likely to be much easier to improve the request an account from a human process - which has inbuilt rate-limiting, a little bit of turing test, and a nice splash of common sense that is so hard to instill in an automated system. That would be removing the Completely Automated part :) It's not a bad idea, but what should we ask them? A too open textarea leads to Plz make an account reasons which have very little Turing entropy. Please summarise the Main Page featured article so we know that you have a decent brain would be more secure, but our users wouldn't be too happy with that. I have been trying flite, and didn't find the synthesized text too understable by itself. :( In which case a computer could probably solve them better than you :). Surely. I suspect that would be quite easy to crack by comparing with each phonema. :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium testing framework
Hi Dan, I had these error messages once when I used Firefox 3.6 for testing. Until recently, Selenium did not support this browser. Apparently now they do, but I did not have a chance to test this yet. So the solution for me was to point Selenium to a Firefox 3.5. Cheers, Markus ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deletion schema
We should start a page at mediawiki.org listing the Pros and Cons of each option. Church of Emacs: I'm still not sure whether RevisionDelete is aimed at replacing the old deletion schema completely, including the archive table. Could anyone comment on that please? It's the logical evolution IMHO. Ps.: BTW, a question that came to my mind: Do we wish to retain our bijective Pagename -- Page relationship? (As opposed to a model, where a new page data set is created when a user creates a wiki page. Our current model has the flaw, that we can't differentiate between two completely different articles that have the same page title (e.g. if article A is deleted and someone else writes article B with the same page title – they are treated exactly the same, even though they are logically two different sets of revisions)) I'm not suggesting we drift away from our current approach, just wanted to note it has some flaws imho. They may be the same (eg. the same article recreated, page merges...) or completely different. That could be 'solved' if the parent_revs were exposed somewhere. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium testing framework
On Tue, 18 May 2010 19:27:38 +0200, Markus Glaser wrote: Hi Dan, I had these error messages once when I used Firefox 3.6 for testing. Until recently, Selenium did not support this browser. Apparently now they do, but I did not have a chance to test this yet. So the solution for me was to point Selenium to a Firefox 3.5. Cheers, Markus My OS is Ubuntu 8.04. The version of Firefox is 3.0.19. Since Ubuntu automatically updates versions of its software, I assume this is the most up-to-date. Is there a list of browser versions compatible with selenium? -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium testing framework
On Tue, 18 May 2010 19:27:38 +0200, Markus Glaser wrote: Hi Dan, I had these error messages once when I used Firefox 3.6 for testing. Until recently, Selenium did not support this browser. Apparently now they do, but I did not have a chance to test this yet. So the solution for me was to point Selenium to a Firefox 3.5. Cheers, Markus Hi Markus, I thought it might be best to move this discussion off-line for a bit until we get the problems sorted out and then post the solution(s) to wikitech-l. This thread is getting fairly long and is getting into fairly complex issues. I tried emailing you at the address shown in your posts, but the email was returned as undeliverable. My email address is dness...@yahoo.com. If you think taking the issue off-line while we sort it out is a good thing to do, then email me from some address that I can use and I will update you on the status of my attempts to get PagedTiffHandler_tests.php to work. As a teaser, it appears there is a problem with the sequence of processing vis-a-vis LocalSettings and LocalSeleniumSettings Cheers, Dan -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deletion schema
On Tue, May 18, 2010 at 1:39 PM, Platonides platoni...@gmail.com wrote: We should start a page at mediawiki.org listing the Pros and Cons of each option. Put it as a subpage of [[RFC]]. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deletion schema
Chad wrote: On Tue, May 18, 2010 at 1:39 PM, Platonides wrote: We should start a page at mediawiki.org listing the Pros and Cons of each option. Put it as a subpage of [[RFC]]. -Chad I started it at http://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion Please, collaborate to fullfill it. *Then*, comment. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
