Re: [Wikitech-l] editing channels - How was this edit made?
On Mon, Nov 19, 2012 at 7:43 PM, jida...@jidanni.org wrote: You n*rds are 100 years behind Facebook, who already shows Yesterday via email About an hour ago via mobile 59 minutes ago near Tsoying, Kao-hsiung 24 minutes ago via POCO Beautycamera Throw in the towel. Another excellent post by jidanni -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving MediaWikiWidgets.org to Wikimedia
On Tue, Sep 4, 2012 at 9:26 AM, Mr. Gregory Varnum gregory.var...@gmail.com wrote: I use and like this extension. I know many others do as well. This debate over its value to some and security is interesting (well - not really) but aside from the point of this thread. Should the widgets be housed on MW.org rather than an outside site? Given their wide usage and the preference towards all things MW being on MW.org, I think they absolutely should and fully support that idea. Don't like the extension? Don't use it. For those of us that do, this move would be very helpful. Arguing about the merits of the extension vs the value of moving its components seems irrelevant. It's widely used enough and arguing about it is unlikely to change that. Unless we're suddenly worried about storage space on MW.org this seems like it should be more about how than why. I would propose subpages to the main extension page. -Greg aka varnent Sent from my iPhone. Apologies for any typos. A more detailed response may be sent later. On Sep 4, 2012, at 8:11 AM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, The essential problem is that people can't get stuff through the gatekeepers, so they come up with a workaround. Noting that the workaround is insecure and saying just don't do that doesn't solve the original need and won't help security. It's not clear to me what will, but the gatekeeping is an obvious start. I don't think this extension really affects this. It is the same as having widgets implemented as extensions in that: * They can only be enabled by administrative people * They can be obtained from verified sources or from non-trusted ones Widgets are inferior in that: * An attacker compromising an admin account can put in arbitrary JS code Widgets are superior in that: * They cannot create PHP vulnerabilities * Changes can be kept track of on-wiki * The source is clearly visible to wiki users, increasing the scrutiny of the code * They are easier to deploy for most people * They encourage more collaboration compared to the tons of low qualify and unmaintained single widget extensions It seems to me that this extension does not lose on security compared to regular extensions at all, and that it offers quite a few benefits for the kind of functionality it is intended to be used for. The problem with creating a new system that has no gatekeepers is that it encourages people who have no business writing code to end up doing so. This system has as much gatekeeping as regular extensions do. I think several people are making assumptions here without having had a decent look at the extension. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ 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 Does MediaWikiWiki really need any more shitty/insecure addons that no one is going to maintain? I think we have enough already. Pick out the best of the bunch and nuke the rest. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving MediaWikiWidgets.org to Wikimedia
On Tue, Sep 4, 2012 at 2:06 PM, [[w:en:User:Madman]] madman.enw...@gmail.com wrote: On Tue, Sep 4, 2012 at 1:39 PM, John Du Hart compwhi...@gmail.com wrote: Does MediaWikiWiki really need any more shitty/insecure addons that no one is going to maintain? I think we have enough already. Does MediaWiki's development community really need any more people discouraging volunteers by calling their good-faith contributions shitty? I think we have enough already. Maybe we should stick to constructive criticism. Thanks, -Madman ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hey if you want to make mediawiki.org a dumping ground for anything mediawiki related, have fun with that. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project Update (ConventionExtension)
Thanks the explain in-depth about why storing configuration in articles is a good thing. Keep up the good work. On Aug 26, 2012 2:11 PM, akshay chugh chughaksha...@gmail.com wrote: -1 On Sun, Aug 26, 2012 at 11:34 PM, John Du Hart compwhi...@gmail.com wrote: On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh chughaksha...@gmail.com wrote: 6. Parser tags, Magic Words (Variables) and a parser function parser tags -- conference, page, account, registration,passport,author,submission,event,organizer and location This is a disgusting way to store data. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Thanks, Akshay Chugh skype- chughakshay16 irc - chughakshay16(#mediawiki) [[User:Chughakshay16]] on mediawiki.org ___ 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] GSoC Project Update (ConventionExtension)
On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh chughaksha...@gmail.com wrote: 6. Parser tags, Magic Words (Variables) and a parser function parser tags -- conference, page, account, registration,passport,author,submission,event,organizer and location This is a disgusting way to store data. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
So you've found and instance of where a user has poor design skills and you immediate response to that is to start a discussion on killing inline styles? Give me a break. On Jul 2, 2012 10:43 AM, Jon Robson jdlrob...@gmail.com wrote: Yes, please, because fixing things such as (put your sunglasses first) https://pt.wikipedia.org/?oldid=30926886action=editsection=3preview=yesuselang=en is a PITA and will take years! (there are tons of it!) Wow! This is exactly why I think inline styles might be a bad thing :-) - this really draws attention of the user away from the content. I've started a wiki page for this discussion - it seems like a better place to do this from now on since this thread has already been confused and gained a lot of length! I've given it the generic heading 'Deprecating Inline Styles' and when I get time will add a mobile specific section: http://www.mediawiki.org/wiki/Deprecating_Inline_Styles ___ 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] bot activity in #mediawiki on freenode
On Thu, Jun 21, 2012 at 12:25 PM, Krenair kren...@gmail.com wrote: If you're moving all bots, including wikibugs, then you can't use -codereview because wikibugs isn't a code review bot. It's for bugs. Krenair Will the world end if we do this? No. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IE7 tax
On Thu, Jun 14, 2012 at 9:57 AM, Chris McMahon cmcma...@wikimedia.org wrote: On Thu, Jun 14, 2012 at 5:21 AM, Arun Ganesh arun.plane...@gmail.comwrote: 6% of wikimedia project page views are from IE6/7 - because of the following: - IE6 ships default with XP - Legal users with SP2+ can upgrade to IE8 - If you have 90s era hardware, no SP for you. Can only be solved by buying some new hardware (or switching to linux) - IT admins who dont know much about IT and have kept the workforce hostage through their ignorance. Can be solved if the workforce and boss demands it. I'd like to reframe these examples. First, as I understand it, most IE6/IE7 users globally are running pirated versions of Windows. For financial or political reasons, they will not or can not acquire legal versions and thus can't upgrade their browsers. No, I'm pretty sure that's not true at all. Even if they are running a pirated version they can still update their browsers. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Changing the MediaWiki logo?
I support that fully. On Jun 12, 2012 5:48 PM, Chad innocentkil...@gmail.com wrote: Hi, Little bit of a different thread today--but something's been kind of biting at me over the last couple of weeks and I thought it'd be best to get it out there :) What support would there be for changing the MediaWiki logo and being consistent with it? I'm not suggesting a drastic change, like substituting puppies for the flower. I'm looking at a more subtle change, as in moving from our current logo to something like[0]. Originally, I didn't like the SVG version but over time it's managed to grow on me quite a bit. Although, I stil think the text could use tweaking, something closer to the current color would be nice. There's a couple of pretty big reasons I think we should switch to this (or something like it): 1) It scales much nicer. The current version looks absolutely awful at higher resolutions, and at lower ends becomes rather featureless. A version natively designed as an SVG (but keeping the original design ideas) takes care of that. 2) It fits much nicer with the other WMF logos (other than the puzzle globe, which will never match :) 3) We've already started selling stickers based on the SVG version[1], so it might be good to update it on MediaWiki.org to match. So...thoughts? Should we do this more formal-like in an RfC or something? Other colors you'd like to paint the bikeshed? -Chad [0] http://commons.wikimedia.org/wiki/File:Mediawiki_logo_reworked_2.svg [1] http://shop.wikimedia.org/products/wikimedia-project-stickers-pack-of-12 ___ 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] Facebook grabs the Mediawiki logo instead of the site logo
Yeah I remember that. On Jun 4, 2012 7:45 PM, Chad innocentkil...@gmail.com wrote: On Mon, Jun 4, 2012 at 7:35 PM, jida...@jidanni.org wrote: Here Facebook grabs the Mediawiki logo instead of the site logo. http://www.facebook.com/groups/tg.taiwan/permalink/374509135949001/?comment_id=374537129279535offset=0total_comments=1 Doing the same experiment with e.g., http://en.wikipedia.org/wiki/1st_clan_chief , a page also without any user embedded images, oddly does not cause the mediawiki logo to be chosen. Though it does not choose the site logo, at least it doesn't choose the mediawiki logo. Didn't we discuss this almost a year ago? Indeed, we did: http://lists.wikimedia.org/pipermail/mediawiki-l/2011-July/037710.html -Chad ___ 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] some people complained already about my recent security alerts for PHP, OpenOffice, LibreOffice...
How dare they complain about you posting off topic material! On May 21, 2012 4:39 PM, Thomas Gries m...@tgries.de wrote: ... in consequence, you will _/not /_receive further major security alerts. ___ 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] Daring to consider replacing gerrit (help write gareth)
So what happened to considering Phabricator in the future?
On Sun, Apr 8, 2012 at 5:29 PM, Platonides platoni...@gmail.com wrote:
On 08/04/12 22:49, Daniel Friesen wrote:
- The project needs a good database system. I copied our database
classes in but never got to using them. I'm isolating all database stuff
into some model classes so different database handing can be swapped in.
Anyone who feels up to it can adapt our database code to work as a
framework for the review system.
I think it would be easier with our classes. Too much fetch()s in
ProjectModel.php
Someone would need to adapt the classes to work outside MW.
I started using Mysqli and prepared statements since it's an easy way to
get the database stuff out of the way right away.
I think they work. You do:
$conf = array( 'host' = ..., 'user' = ..., 'pass'= ..., 'dbname'
=..., 'tableprefix'= ... )
$db = Database::factory( 'mysql', $conf );
And you have a perfectly working Database object.
Or if you prefer something much more lightweight,
https://fisheye.toolserver.org/browse/erfgoed/api/includes/Database.php?hb=true
is a Database class which aims to provide a similar interface to ours.
- Right now I'm implementing git handling using proc_open to interact
with git's porcelain and plumbing commands. Anyone who feels up to the
task is free to implement a PHP extension for interfacing with git we
can swap over to using.
Please, remove the usage of __call() there. Make a different function
for each one, even if they're going to be dummy ones right now.
This way we can easily replace them with real implementations instead of
wondering which ones are called by the magic.
Drop ShellGit entirely and make Git the only class?
No, I mean:
function diff() {
return call_user_func_array( array( $this-git, __METHOD__ ),
get_func_args() );
}
function show() {
return call_user_func_array( array( $this-git, __METHOD__ ),
get_func_args() );
}
etc.
(still, I think ShellGit misses a __call and won't work right now)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
John
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)
On Sun, Apr 8, 2012 at 4:18 PM, Antoine Musso hashar+...@free.fr wrote: Meanwhile, dont waste your time coding something we are most certainly never going to use. Statements like that from WMF staff are hurtful towards volunteer developers. Don't turn this into another MobileFrontend situation. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Federated Login to Wikipedia. Re: OAuth
On Wed, Mar 21, 2012 at 10:01 AM, Andreas Åkre Solberg andreas.solb...@uninett.no wrote: If you are interested in doing a pilot with connecting wikipedia to Feide, we may provide you with further details to proceed with that. Yeah, I'd rather not tie down the 6 largest website in the world to an educational login service. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] integrating who's been awsome to MediaWiki
You do realize you've been making posts on a public mailing list right? On Mar 15, 2012 1:06 PM, Eranga Mapa erangam...@gmail.com wrote: Hi Sumanah Still I did not hear from James Can you look into this matter. When can I get a space to host my extension in Git?? ___ 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] OAuth
This isn't something that can be implemented as an extension, it needs to be in core. This goes way beyond just allowing a user to log in to a site with their MediaWiki account, it needs full integration with our permissions and API to be of any use. On Tue, Mar 13, 2012 at 8:50 AM, Petr Bena benap...@gmail.com wrote: Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis. Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki. Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database dump of Bugzilla
On Sat, Mar 3, 2012 at 7:46 AM, Merlijn van Deen valhall...@arctus.nl wrote: However, wouldn't adapting Bugzilla to be less annoying be a more sensible option? Converting bugs always is somewhat annoying. I agree however there's only so much that can be done to improve Bugzilla. BZ itself is only built to be a bugtracker, however it seems that we are starting to need more features such as scrum (since teams using that now use a different piece of software). -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database dump of Bugzilla
On Sat, Mar 3, 2012 at 3:17 PM, Merlijn van Deen valhall...@arctus.nl wrote: On 3 March 2012 20:20, Antoine Musso hashar+...@free.fr wrote: Anyway, I would dismiss it just because that is a proprietary software. I never quite understand this argument. What is wrong with using proprietary software if it's the best software you can use? Or, to turn it around: Why force your developers to work with suboptimal software /just because/ it's open source? Best, Merlijn ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I agree with that, just because it's proprietary doesn't mean we can't consider it. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database dump of Bugzilla
On Mar 3, 2012 2:20 PM, Antoine Musso hashar hashar%2b...@free.fr+hashar%2b...@free.fr wmf hashar%2b...@free.fr@ hashar%2b...@free.frfree.frhashar%2b...@free.fr wrote: Le 03/03/12 02:11, John Du Hart a écrit : I'm currently investigating alternative bug tracker and project management software for MediaWiki. To do that I'll be installing some different software on the Labs and importing existing bugs for evaluation by the development team and users. Hello John, I beg you to first establish a list of requirements and features we are looking after. You do not want to invest any time installing a software we could dismiss right away just by looking at its specs (see at the bottom of this mail for examples). Fair enough. I think what I'm looking for is a bug tracker that is more easier to use for both developers and users. I would also like tools that allow us to better visualize progress on bugs and what's fixed or needed for a released. Finally an API that doesn't suck would be nice Let me ask you a question, why do you feel we should move to another bug tracker? Do you think that Bugzilla is missing features we could use? For example, maybe some bug tracker also assist in planning release management. I know Mantis has a nice interface for that. Is that because other tools have a nicer interface? We could probably enhance the Bugzilla one. I am not a huge fan of Bugzilla. It is certainly lagging in terms of neat features lack reporting and ease of navigation between components. But so far, Bugzilla seems to fit our needs nicely. But I'm sure we could do better! As for testing there is probably no point in loading our existing bugs since close to nobody, beside hexmode, know our bugs well enough to take advantage of it. Instead we can use some demo accounts or just install a version for sandboxing purposes. Both way would be easier than investing time in migrating bugs to some other tracker. I disagree. I think that if the software supports an importer it wouldn't hurt to use it for the demo. If you want some bugs, you can try out Bugzilla JSON interface which is used to generate the release reports. Entry point is: https:// https://bugzilla.wikimedia.org/jsonrpc.cgi bugzilla.wikimedia.org https://bugzilla.wikimedia.org/jsonrpc.cgi/https://bugzilla.wikimedia.org/jsonrpc.cgi jsonrpc.cgi https://bugzilla.wikimedia.org/jsonrpc.cgi Again most of the software supports an import via a database dump so I'd rather use that. Guillaume wrote a blog post about bug tracker, you might want to have a look at it: http://http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/ www.gpaumier.orghttp://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/ /blog/520_scaling-up-software-development-for-http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/ wikimediahttp://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/ -websites-tools/http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/ Interesting. Again, it seems we're in agreement for the need of a better project management tool. Find below my comments about the proposed softwares: The following software is planned for test: - JIRAhttp:// http://www.atlassian.com/software/jira/overview www.atlassian.com http://www.atlassian.com/software/jira/overview /software/ http://www.atlassian.com/software/jira/overviewjirahttp://www.atlassian.com/software/jira/overview /overview http://www.atlassian.com/software/jira/overview + Greenhopper + Bonfire I guess it was installed on Toolserver just because it was written in Java, a language that River Tarnell like. Anyway, I would dismiss it just because that is a proprietary software. - YouTrackhttp:// http://www.jetbrains.com/youtrack/ www.jetbrains.com http://www.jetbrains.com/youtrack//http://www.jetbrains.com/youtrack/ youtrack http://www.jetbrains.com/youtrack//http://www.jetbrains.com/youtrack/ Proprietary software as well. Like I replied earlier, this is not a major concern. - Redminehttp:// http://www.redmine.org/www.redmine.org/http://www.redmine.org/ - ChiliProjecthttps:// https://www.chiliproject.org/ www.chiliproject.org/ https://www.chiliproject.org/ The later being a fork of the former. Both are written in ruby which, as far as I know, our operation team do not want to hear about on our production cluster. Fair enough. - The Bug Geniehttp:// http://www.thebuggenie.com/index.php www.thebuggenie.com http://www.thebuggenie.com/index.php/http://www.thebuggenie.com/index.php index.php http://www.thebuggenie.com/index.php Demo: http:// http://www.opensourcecms.com/demo/1/259/The+Bug+Genie www.opensourcecms.comhttp://www.opensourcecms.com/demo/1/259/The+Bug+Genie /demo/1/259/The+Bug+Geniehttp://www.opensourcecms.com/demo/1/259/The+Bug+Genie If you
Re: [Wikitech-l] Database dump of Bugzilla
On Sat, Mar 3, 2012 at 5:38 PM, David Gerard dger...@gmail.com wrote: On 3 March 2012 20:23, John Du Hart compwhi...@gmail.com wrote: I agree with that, just because it's proprietary doesn't mean we can't consider it. It's a seriously strong point in its disfavour. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I really don't understand why we'd rather suffer than use a superior proprietary product. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database dump of Bugzilla
On Sat, Mar 3, 2012 at 5:25 PM, Chad innocentkil...@gmail.com wrote: Then again, I'm fine with the status quo so I'm not volunteering to test anyway. Oops too late, already had you down ;) -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database dump of Bugzilla
It's a bug tracker. It's not critical to the operation of a clone and can be replaced. In fact, some teams are using mingle which is a proprietary agile project manager. On Mar 3, 2012 6:26 PM, David Gerard dger...@gmail.com wrote: On 3 March 2012 22:44, John Du Hart compwhi...@gmail.com wrote: I really don't understand why we'd rather suffer than use a superior proprietary product. https://wikimediafoundation.org/wiki/Values Duplicability down to the infrastructure is considered extremely important, or the free content isn't free. Open core fails this test. - d. ___ 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] Database dump of Bugzilla
I know you don't think that currently however I would like the opportunity to convince you otherwise. On Mar 3, 2012 6:35 PM, Antoine Musso hashar+...@free.fr wrote: Le 03/03/12 23:37, David Gerard a écrit : snip Have you ever fixed it when it's broken? Anything looks good when it's working, but I've found the experience of trying to bugfix a broken Mantis horrible. Luckily, I had people fixing my bug reports :-) If Bugzilla mostly works and its breakages have so far been fixable in-house, that's a *powerful* advantage right there, and it would take really quite strong reasons to move. My point. I do not think there is anything better for us than Bugzilla. -- Antoine hashar Musso __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Database dump of Bugzilla
I don't understand the question. Are you implying that I have some sort of relationship with one of these vendors? If that's the case then I'd like to inform you that's not the case. My motive here is giving developers and users access to better tools so that we can make a better product. On Mar 3, 2012 7:08 PM, David Gerard dger...@gmail.com wrote: On 3 March 2012 23:52, John Du Hart compwhi...@gmail.com wrote: On Mar 3, 2012 6:35 PM, Antoine Musso hashar+...@free.fr wrote: My point. I do not think there is anything better for us than Bugzilla. I know you don't think that currently however I would like the opportunity to convince you otherwise. Which one are you involved with? - d. ___ 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] install php-fss on php 5.3
I've never heard of it and do not believe it's in use in production. On Mar 2, 2012 10:01 AM, Yury Katkov katkov.ju...@gmail.com wrote: Hi everyone! I want to install php module php-fss on php5.3 since I heard that it boosts MediaWiki performance a lot. Is it possible to do that? Is it installed on wikipedias? - Yury Katkov ___ 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
[Wikitech-l] Database dump of Bugzilla
I'm currently investigating alternative bug tracker and project management software for MediaWiki. To do that I'll be installing some different software on the Labs and importing existing bugs for evaluation by the development team and users. The following software is planned for test: - JIRA http://www.atlassian.com/software/jira/overview + Greenhopper + Bonfire - YouTrack http://www.jetbrains.com/youtrack/ - The Bug Genie http://www.thebuggenie.com/index.php - Redmine http://www.redmine.org/ - ChiliProject https://www.chiliproject.org/ If you have any suggestions for this list I'd be glad to hear it. Of course, this goes back to the original request. To do this I need a dump of the current Bugzilla install. Is it possible for me to get this and under what conditions? Thank you. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [ANN] MediaWiki Short URL Builder configuration tool
On Feb 27, 2012 9:57 PM, jida...@jidanni.org wrote: Actually if you put it in the installer you are making a commitment to handhold them through thick and thin, though better and worse, till the death of their wiki do we part. I do (NOT!). What. C == Chad innocentkil...@gmail.com writes: Plus, I might know how to maintain them now, but five years later will I still know? I'm not getting any younger. C I can't speak for nginx or IIS or lighttpd, but I know that Apache's C mod_rewrite has been functioning the same way for a long time, so I can't C imagine that configuration for that will change. On the MediaWiki side--we C haven't changed the behavior of $wgArticlePath, $wgScriptPath and the C rest in a very very long time (and I can't imagine we'd break it either). I'm talking about me. I can't even understand the comments I myself wrote in code six months ago. Sounds like you need to write better comments then. C The process is different for each webserver, which is why there's C no one-size-fits-all answer to how to do this. Anyways, I'll stick with my Big Ten Inch, http://www.youtube.com/watch?v=b_VqNuLdrGolist=PL648DE656FFB7A7A7 ___ 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] [ANN] MediaWiki Short URL Builder configuration tool
Thanks jidanni, I'm glad that we can always count on you for fair and balanced opinion. On Feb 24, 2012 8:48 PM, jida...@jidanni.org wrote: http://shorturls.redwerks.org/ should link to http://www.mediawiki.org/wiki/Manual:Short_URL#Advantages_.26_disadvantages. for a balanced view. I'll stick with my long URLs. ___ 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] [GSoC 2012] Proposal - Realtime Collaboration on Visual Editor
No, that's not the answer. On Feb 19, 2012 8:22 AM, Thomas Gries m...@tgries.de wrote: Am 19.02.2012 14:20, schrieb Ashish Dubey: Hi Everyone The idea of realtime collaboration, use Etherpad Lite See https://www.mediawiki.org/wiki/Extension:EtherpadLite ___ 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] MediaWiki Skinning Tutorial
This is amazing Daniel, the depth of it is astounding. Thank you so much. On Mon, Feb 13, 2012 at 5:27 PM, Daniel Friesen li...@nadir-seen-fire.com wrote: I finally have a tutorial on MediaWiki Skinning for 1.18+ online on Redwerks' Blog. http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/ The tutorial covers the general conceptual areas of a skin, laying out the files for a skin, all the small boilerplate pieces used to output types of content, an overview of things you should test for in your skin when implemented, a bit on i18n and related info on variants and rtl, and a touch on accessibility. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator
On Fri, Feb 10, 2012 at 9:59 PM, Rob Lanphier ro...@wikimedia.org wrote: On Fri, Feb 10, 2012 at 12:01 PM, John Du Hart compwhi...@gmail.com wrote: Just want to check in to see how everyone's doing. I see a lot of account creations however no posts to differential. Is there a problem I'm not aware of? Documentation problems? Software issues? Do we see something we don't like? What's up? Hi John, Just mulling it over, mainly. I love having a test instance to play with, and agree with you that it looks way easier to use than Gerrit on the surface. I don't want that to be taken as an endorsement of the system just yet, because I don't know enough about either system (Gerrit or Phabricator) to have a valid opinion about which is better for us. What Chad, Sumana and I spoke about earlier today was the tough reality we're in. In order to get moved to Git in the very short term, we're going to have to stay the course on Gerrit. That said, one beautiful thing about Git is that Git repos are far more portable than SVN repos. We could decide we're going to use Gerrit on a probationary basis, and have a serious reevaluation in three months. Sumana and I would like to go in that direction, and we twisted Chad's arm hard enough on this point that he might just say he agrees with us, even if he's secretly blowing us off ;-) There's at least one feature we would need to use this system, which is LDAP integration. I don't think we can seriously consider a system that doesn't have some sort of sensible plan for how it's going to work with our LDAP server. I do, however, love the idea of using OAuth for filling in credentials from other services like Github. It would be ridiculously cool if people could use their Wikimedia SUL logins to access this system. It's also nice that this is written in PHP. Since we have an abundance of PHP developers, that means it's far more likely that customization we need would actually happen. In general, it's good to have options. Like I said, I don't want to put the brakes on our immediate plans, but I think it's worth consideration after we've given Gerrit a try. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I compeletely agree with that. It would be a complete waste to have chad and others' work from the past 5 months thrown away at the last minute for a solution brought up this late. We can initially use git for the migration however if we decide to later, Phabricator is still available. :-) -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MobileFrontend John Du Hart's rewrite
Thanks to everybody for talking through this and clarifying the issues. So I'd like to move forward and figure out how we all should proceed. I'm completely fine with renaming MobileFrontEnd2 to help avoid confusion. :-) I'll look at the suggestions and pick one. My ideal scenario would be me continuing this rewrite while the mobile team continues with feature development on MobileFrontend. I really believe that there are several issues with the current MobileFrontend that are better resolved with a full rewrite instead of a slow refactoring of the existing extension. But I'm also happy to work with Arthur to refactor and rewrite the current MobileFrontend more gradually to resolve the issues raised. I could work with the mobile team to come up with a checklist of goals to complete in the refactoring and rewriting before we can write off the need for a replacement for MobileFrontend. Functionaility wise, MobileFrontend2 is a clone of the original with very minimal UI changes. Maybe we could write Selenium tests for this? Maybe I could work with Chris McMahon to learn what tests need writing for this extension and write them. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome David Schoonover - Systems Engineer - Data Analytics
On Mon, Feb 13, 2012 at 12:07 PM, Rob Lanphier ro...@wikimedia.org wrote: I've also found David will immediately will draw a dinosaur[2] on a whiteboard in whatever room he is in. So, those of you in our SF office, if you see a plesiosaur on the whiteboard near you, that probably means he's been there recently. Or maybe it's been there a while but now won't erase. Either way, he probably drew it. Hey I like dinosaurs! Welcome David! -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC Complete Rewrite of Mobile Frontend Rename MobileFrontend2
Just as a note I've made a reply to the other thread, MobileFrontend John Du Hart's rewrite On Sun, Feb 12, 2012 at 5:39 PM, Ryan Lane rlan...@gmail.com wrote: We already have SubPageList, SubPageList2, and SubPageList3 sitting around (SubPageList and SubPageList3 are in SVN, SubPageList is supposed to be the one more up to date then either the 2 or 3) inside MW.org and SVN. Heck it's hard to have as much of a naming mess as we've had with Dynamic Page List. So I see no reason for MobileFrontend2 to be forced to be renamed. Can we just let John DuHart get on with writing the code so that we can have a working 1:1 replacement, put it through all the testing we need to make it the mobile code used on WMF's cluster, and then replace MobileFrontend/ with MobileFrontend2/'s code. And for ages there was confusion about which one was actually up to date and usable. At some point everything just said Use SubPageList, it's the up to date version. Same thing with DynamicPageList. People expect things with what appear to be version numbers. It's unfriendly, at least, to name an extension to look like a newer version. Is it really too much to ask for it to be named something else? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator
Good idea, I've done just that. https://www.mediawiki.org/wiki/Phabricator/todo On Feb 13, 2012 1:33 PM, Ryan Lane rlan...@gmail.com wrote: I compeletely agree with that. It would be a complete waste to have chad and others' work from the past 5 months thrown away at the last minute for a solution brought up this late. We can initially use git for the migration however if we decide to later, Phabricator is still available. :-) Indeed. We should continue to evaluate phabricator, and see if it fits our model better than Gerrit in the long run. Also, we should start keeping a list of things phabricator needs to be usable (like we are doing with Gerrit). - Ryan ___ 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] RFC Complete Rewrite of Mobile Frontend Rename MobileFrontend2
On Feb 12, 2012 5:15 AM, Arthur Richards aricha...@wikimedia.org wrote: On Sun, Feb 12, 2012 at 2:48 PM, K. Peachey p858sn...@gmail.com wrote: I think it's actually better completely out from the current extension for a few reasons, * MF1 is currently a cluster extension so all the code needs to be reviewed before deployed * MF1 is already regularly deployed (close to weekly iirc) * John is working on having it [MF2] operate in a completely different method than current [MF1] so it would avoid possible breakage and compatibility issues I think you make good points here - we definitely understand the logic. A lot of the things I think John is planning to address in his new extension are things that we also would like to see in the existing MobileFrontend extension, so hopefully we will be able to still coordinate and work together to minimize duplicated work. However, we feel that naming the rewrite 'MobileFrontend2' is problematic as users have already started to confuse it with the current extension. Whom? It's not like it's really advertised anywhere apart from CR and SVN so it shouldn't be causing that many issues at the current stage. Place a '2' after an existing extension name implies that it is an improved, and newer, version of an existing extension. Assuming John will be building his extension as something completely different from the existing MobileFrontend (like you outlined above), it is inappropriate to name it 'MobileFrontend2'. We should work to find an acceptable alternative that makes its functionality clear, and clearly differentiates it from the existing MobileFrontend extension. If it wasn't a rewrite I wouldn't of placed a two after. Functionality wise, this will be a 1:1 replacement, with back end changes only. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ 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] Phabricator
On Sat, Feb 11, 2012 at 4:46 PM, Ryan Lane rlan...@gmail.com wrote: On Fri, Feb 10, 2012 at 5:08 AM, John Du Hart compwhi...@gmail.com wrote: Unless you've been living under a rock (If you have, how's the wifi under there?) we're moving to git soon. Along with this will come a change in how we do code review. However, some people have expressed concerns over the usability of gerrit. Therefore I'd like to propose an alternative. Phabricator is a code review tool written by and for Facebook that has been open sourced. For an introduction, see this: http://phabricator.com/docs/phabricator/article/Introduction.html I've written up some documentation about Phabricator for our uses here: https://www.mediawiki.org/wiki/Phabricator I would really like for some of our developers and reviewers to try this out as an alternative to gerrit. Personally I've found it much more pleasurable to work with than gerrit. If we think this might be a viable solution for us then I'd be willing to work on adding more integration (LDAP support and Unit testing integration). Let me know if you have any questions or feedback. Thanks! I forgot. There's one other thing I wanted to point out about phabricator. To properly use it, you must have php installed wherever you are working from. I like that it uses PHP on the server side, but despise that it uses it on the client side. I also have a few questions: * Who's going to get stuck with maintaining the LDAP support? * Does it already integrate with Jenkins? * Does it use the system SSH, or a separate SSH daemon? * What permissions model does it have? * Does it manage the repositories and branches? * How are repos created? * Does it support server side branches? * Does it handle merges automatically? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l * Me * Why would it need to, it runs unit and lint tests before the diff is posted The rest of the questions are irrelevant because, unlike gerrit, Phabricator does not manage git repositories. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MobileFrontend John Du Hart's rewrite
On Fri, Feb 10, 2012 at 12:53 PM, Sumana Harihareswara suma...@wikimedia.org wrote: John, Patrick, and anyone else who is interested in the MobileFrontend extension: John Du Hart is working on a rewrite, aiming to make it less Wikimedia Foundation-centric, and there is disagreement regarding whether his rewrite is desired. Please read and comment: https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend#Issues_with_MobileFrontend_and_possible_rewrite_11940 (Can someone please forward this to mobile-l as well? Thanks.) -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I've replied on the talkpage. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator
Just want to check in to see how everyone's doing. I see a lot of account creations however no posts to differential. Is there a problem I'm not aware of? Documentation problems? Software issues? Do we see something we don't like? What's up? -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Phabricator
Unless you've been living under a rock (If you have, how's the wifi under there?) we're moving to git soon. Along with this will come a change in how we do code review. However, some people have expressed concerns over the usability of gerrit. Therefore I'd like to propose an alternative. Phabricator is a code review tool written by and for Facebook that has been open sourced. For an introduction, see this: http://phabricator.com/docs/phabricator/article/Introduction.html I've written up some documentation about Phabricator for our uses here: https://www.mediawiki.org/wiki/Phabricator I would really like for some of our developers and reviewers to try this out as an alternative to gerrit. Personally I've found it much more pleasurable to work with than gerrit. If we think this might be a viable solution for us then I'd be willing to work on adding more integration (LDAP support and Unit testing integration). Let me know if you have any questions or feedback. Thanks! -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Picture of the Year contest extension
On Sat, Feb 4, 2012 at 6:32 PM, Mono monom...@gmail.com wrote: Hi, It's likely many of you have heard of or even participated in the Picture of the Year contest. Every year, the Wikimedia community votes for a picture of the year from the pool of images promoted to featured picture status in the previous year on the Wikimedia Commons. This typically occurs in late spring; last year's contest took place in May and was a huge success. This year, we're looking to improve the operation of the contest. In the past, with the notable exception of a community-developed JavaScript interface, the galleries, voting, and counting has been done manually. This hurts the efficiency of the contest significantly, as these somewhat tedious tasks will be repeated year after year. It would be really wonderful if we could get a couple of developers to put an extension together. I've searched fairly extensively for something that would be sufficient for our needs and I've come to the conclusion that building such an extension would be the most future-proof and efficient way to accomplish the task. I considered using a Toolserver-based system, but authenticating users in a SecurePoll-like way on a large scale would be difficult. (It's possible that some parts of the SecurePoll code could be used for this.) The functionality needs for the extension include: *a front-end voting gallery where users can vote while logged in with a SUL account on Commons *an administration panel to manage the front-end galleries, including account verification requirements, dates, and statistics *a user right for committee members to access the interface This is certainly a project, but it could be used for every POTY contest, perhaps some other contests, and it doesn't have to be elaborate. However, as I said, it would be really great if we could get just a couple people who have some experience developing MediaWiki extensions to help program this in time for this year's contest. If anyone is interested in helping out or would like some more information, please contact me as soon as possible - anything helps! Thanks, User:Mono -- Sent from my iPad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l For someone who is not fimilar with the commons PoTY voting process, could you share with us some dates so we have an idea of when the delivery date would be? -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how did spammers spam only some pretty links?
On Mon, Jan 23, 2012 at 6:16 AM, jida...@jidanni.org wrote: How did the spammers manage to spam only the third file? 17097 http://mapki.com/wiki/Main_Page 17097 http://mapki.com/mediawiki/index.php?title=Main_Page 11985 http://mapki.com/wiki/Google_Map_Parameters 39100 http://mapki.com/mediawiki/index.php?title=Google_Map_Parameters I have almost given up on that site. http://mapki.com/wiki/Sitesupport-url is useless, and as usual there is no way to contact the Sysop. I think the config scripts should drive home how important it is to make sure users can contact the owner, with plenty of fields for such information, etc. and a Special Page called Contact where that stuff gets stored. Important things not to forget for non WMF sites! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Probably poorly written bot scripts that only work off of pretty URLs. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Foundation-l] COMPLETED: Mailing lists server migration today
On Sun, Jan 22, 2012 at 11:51 PM, John Vandenberg jay...@gmail.com wrote: Hi Mark, There are a lot of http links to mail.wiki[pm]edia.org, where mailman and pipermail used to work. They are in email footers headers and in Wikipedia. https://google.com/search?q=%22mail.wikipedia.org%22+-site:lists.wikimedia.org Thanks, John Vandenberg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Confirming this, they still point to the older IP. Probably should be set to CNAME the new sub-domain. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wednesday wikipedia shut down does not get through
On Thu, Jan 19, 2012 at 5:56 AM, Thomas Dalton thomas.dal...@gmail.comwrote: On 19 January 2012 02:48, Daniel Friesen li...@nadir-seen-fire.com wrote: You do realize that going by what you are saying. If 503's weren't cached for that reason, then EVERY single request would be forwarded to the apaches. I'm talking about external caches, as I assumed everyone else was. The internal caches are entirely under the WMF's control so they can be made to do whatever the WMF wants them to do. There's no problem there. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l The operations team can indeed do whatever they want, however they do not have infinite amount of time to determine how to do it and test it -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help needed getting rid of the last bits of hook LanguageGetMagic
I'll take of of those last 3 usages. On Thu, Jan 19, 2012 at 9:12 AM, Siebrand Mazeland s.mazel...@xs4all.nlwrote: Dear all, Over the past days I've been trying to get rid of the deprecated hook LanguageGetMagic in the repo[1]. I've updated about 60 extensions, I estimate, to use $magicWords imported through $wgExtensionMessagesFiles, instead of the hook. As you may know, I'm not much of a developer, so when it gets harder, I throw the towel in the ring... There are three extensions that make a more esotheric use of LanguageGetMagic, that I'm not able to convert to use $magicWords. These are: * FlaggedRevs/FlaggedRevs.setup.php: $wgHooks['LanguageGetMagic'][] = 'FlaggedRevsHooks::onLanguageGetMagic'; * LabeledSectionTransclusion/lst.php:$wgHooks['LanguageGetMagic'][] = 'LabeledSectionTransclusion::setupMagic'; * MetavidWiki/includes/MV_GlobalFunctions.php:$wgHooks['LanguageGetMagic'][] = 'mvMagicParserFunction_Magic'; If you can help out here, please do so. It would be much appreciated. Next, in my opinion, would be to start throwing warnings using wfDeprecated on use of the hook LanguageGetMagic, but I haven't really been able to find where that could be done for a hook. If you can be of help there, please let me know. There may also be some other deprecated hooks that could get more attention if they would throw warnings on use. [1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/languagegetmagic Cheers! Siebrand ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help needed getting rid of the last bits of hook LanguageGetMagic
FlaggedRevs and MetavidWiki done https://www.mediawiki.org/wiki/Special:Code/MediaWiki/109571 For LST there's already hardcoded translations and I'm not sure how to do those. Is it right to include the english ones in the translations? On Thu, Jan 19, 2012 at 9:43 AM, John Du Hart compwhi...@gmail.com wrote: I'll take of of those last 3 usages. On Thu, Jan 19, 2012 at 9:12 AM, Siebrand Mazeland s.mazel...@xs4all.nlwrote: Dear all, Over the past days I've been trying to get rid of the deprecated hook LanguageGetMagic in the repo[1]. I've updated about 60 extensions, I estimate, to use $magicWords imported through $wgExtensionMessagesFiles, instead of the hook. As you may know, I'm not much of a developer, so when it gets harder, I throw the towel in the ring... There are three extensions that make a more esotheric use of LanguageGetMagic, that I'm not able to convert to use $magicWords. These are: * FlaggedRevs/FlaggedRevs.setup.php: $wgHooks['LanguageGetMagic'][] = 'FlaggedRevsHooks::onLanguageGetMagic'; * LabeledSectionTransclusion/lst.php:$wgHooks['LanguageGetMagic'][] = 'LabeledSectionTransclusion::setupMagic'; * MetavidWiki/includes/MV_GlobalFunctions.php:$wgHooks['LanguageGetMagic'][] = 'mvMagicParserFunction_Magic'; If you can help out here, please do so. It would be much appreciated. Next, in my opinion, would be to start throwing warnings using wfDeprecated on use of the hook LanguageGetMagic, but I haven't really been able to find where that could be done for a hook. If you can be of help there, please let me know. There may also be some other deprecated hooks that could get more attention if they would throw warnings on use. [1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/languagegetmagic Cheers! Siebrand ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Change request please: Congress Lookup page text
Fixed: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/109359 On Wed, Jan 18, 2012 at 8:19 AM, Sue Gardner sgard...@wikimedia.org wrote: Hey folks, I'm not sure where to send this, so I'll send it here. Could someone please change the Congress Lookup page text, as per the note below? Essentially, it is changing two instances of will to would and adding one new would -- that's all. No formatting changes, just the three words. Thanks, Sue http://en.wikipedia.org/wiki/Special:CongressLookup This page -- Call your elected officials. Tell them you are their constituent, and you oppose SOPA and PIPA. Why? SOPA and PIPA put the burden on website owners to police user-contributed material and call for the unnecessary blocking of entire sites. Small sites won't have sufficient resources to defend themselves. Big media companies may seek to cut off funding sources for their foreign competitors, even if copyright isn't being infringed. Foreign sites will be blacklisted, which means they won't show up in major search engines. SOPA and PIPA build a framework for future restrictions and suppression. In a world in which politicians regulate the Internet based on the influence of big money, Wikipedia — and sites like it — cannot survive. Congress says it's trying to protect the rights of copyright owners, but the cure that SOPA and PIPA represent is worse than the disease. SOPA and PIPA are not the answer: they will fatally damage the free and open Internet. CHANGE TO THIS Call your elected officials. Tell them you are their constituent, and you oppose SOPA and PIPA. Why? SOPA and PIPA would put the burden on website owners to police user-contributed material and call for the unnecessary blocking of entire sites. Small sites won't have sufficient resources to defend themselves. Big media companies may seek to cut off funding sources for their foreign competitors, even if copyright isn't being infringed. Foreign sites will be blacklisted, which means they won't show up in major search engines. SOPA and PIPA would build a framework for future restrictions and suppression. In a world in which politicians regulate the Internet based on the influence of big money, Wikipedia — and sites like it — cannot survive. Congress says it's trying to protect the rights of copyright owners, but the cure that SOPA and PIPA represent is worse than the disease. SOPA and PIPA are not the answer: they would fatally damage the free and open Internet. -- In other words. SOPA and PIPA put the burden SOPA and PIPA would put the burden SOPA and PIPA build a framework SOPA and PIPA would build a framework they will fatally damage they would fatally damage -- Sue Gardner Executive Director Wikimedia Foundation 415 839 6885 office 415 816 9967 cell Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us make it a reality! http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wednesday wikipedia shut down does not get through
Cache pollution. On Wed, Jan 18, 2012 at 12:57 PM, OQ overlo...@gmail.com wrote: On Wed, Jan 18, 2012 at 11:49 AM, Chad innocentkil...@gmail.com wrote: On Wed, Jan 18, 2012 at 12:31 PM, Thomas Gries m...@tgries.de wrote: You should do a straightforward real shutdown instead, and deliver a fake 404 with explanation link. And for several more days. +1 Doing it via 404s would mess up search engines. -Chad Do it via 503's then. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] PHP 5.3.9 released (page says All users are strongly encouraged to upgrade to PHP 5.3.9.)
On Wed, Jan 11, 2012 at 1:58 PM, Thomas Gries m...@tgries.de wrote: Am 11.01.2012 19:42, schrieb Chad: A new PHP version 5.3.9 has been released, see http://www.php.net/archive/2012.php#id2012-01-11-1 The page says All users are strongly encouraged to upgrade to PHP 5.3.9. They said almost the same thing for 5.3.1 too[0], and look how well that turned out ;-) Security Enhancements and Fixes in PHP 5.3.9: * Added max_input_vars directive to prevent attacks based on hash collisions. (CVE-2011-4885) * Fixed bug #60150 (Integer overflow during the parsing of invalid exif header). (CVE-2011-4566) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Which can be easily backported -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] enable setting language preference without requiring login
On Wed, Jan 11, 2012 at 7:57 PM, jida...@jidanni.org wrote: Why can't MediaWiki do like all major sites' software, and allow setting the interface language without requiring the user to establish an account? Observe the bottom of e.g., http://www.facebook.com/ http://www.flickr.com/ http://www.youtube.com/ Each has a language selector that doesn't require login. http://www.couchsurfing.org/ even puts it right at top. Yes, patient users can set their language preference in Preferences. But what about read-only sites? I.e., What should one suggest on http://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_account_creation to say to users who wish to view in a different language? Painfully suffix ?uselang=... to the end of each URL they browse? One might argue users will confuse MediaWiki uselang= with XX.wikipedia.org languages ... well they haven't yet with the language choice in Preferences. I'm not saying rip it out of Preferences. I'm saying add an additional way to set it for even non-logged in users, just like the aforementioned real websites do. Also consider the current accessibility up until the point the user has managed to register an account and finally set his/her language preference... all of which has to be somehow accomplished in the dark of the default language, unless he/she knows to add the magic uselang=... to MediaWiki URLs every step of the way. Please don't suggest an add-on for such basic functionality. OK, I filed https://bugzilla.wikimedia.org/show_bug.cgi?id=33677 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Just wondering, is there a reason why you think it's necessary to make a maliinglist post every time you file a bug that complains about MediaWiki missing a feature? -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Minor enhancements should not be tagged highest priority.
So instead of bug fixes or security patches operations should spend time deploying an extension so you know who has the most edits? Not a great idea. On Jan 3, 2012 8:06 AM, Strainu strain...@gmail.com wrote: 2011/12/30 Dan Collins en.wp.s...@gmail.com: There are also numerous highest priority extension installations. Site request should be treated with the highest priority. Strainu ___ 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] Mass changes to bugs by Jan Kucera (Kozuch)
Revert it. Just like enwiki, you can't do stuff like this without discussion. On Fri, Dec 30, 2011 at 11:48 AM, Chad innocentkil...@gmail.com wrote: On Fri, Dec 30, 2011 at 11:42 AM, Jeremy Baron jer...@tuxmachine.com wrote: On Fri, Dec 30, 2011 at 11:38, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: As long as it's there, people will think that we do. This mass change should have been discussed somewhere first, but then i never understood why voting is bad. Mozilla haven't disabled it in their Bugzilla and Google use it in Google code (as stars), although i don't whether either of them actually prioritize bugs according to it. I thought stars were the only way to subscribe to future updates? and hence they're not necessarily votes. CC list? But yes, we've just never used the voting--it's mainly just there as a favorites type list. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mass changes to bugs by Jan Kucera (Kozuch)
Left him a note about this thread. https://en.wikipedia.org/wiki/User_talk:Kozuch#Discussion_about_your_actions_in_Wikitech-l On Fri, Dec 30, 2011 at 1:04 PM, John Du Hart compwhi...@gmail.com wrote: Revert it. Just like enwiki, you can't do stuff like this without discussion. On Fri, Dec 30, 2011 at 11:48 AM, Chad innocentkil...@gmail.com wrote: On Fri, Dec 30, 2011 at 11:42 AM, Jeremy Baron jer...@tuxmachine.com wrote: On Fri, Dec 30, 2011 at 11:38, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: As long as it's there, people will think that we do. This mass change should have been discussed somewhere first, but then i never understood why voting is bad. Mozilla haven't disabled it in their Bugzilla and Google use it in Google code (as stars), although i don't whether either of them actually prioritize bugs according to it. I thought stars were the only way to subscribe to future updates? and hence they're not necessarily votes. CC list? But yes, we've just never used the voting--it's mainly just there as a favorites type list. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] irc bot
On Thu, Dec 15, 2011 at 5:33 AM, Petr Bena benap...@gmail.com wrote: Hi all, I would like to notice that I am now working on rewrite of mw-bot, called wm-bot (wikimedia bot - it's supposed to serve in various wikimedia chans), the bot now is supporting exactly same functions as mw bot + some more, and I think it would be good if we replaced current mw-bot in future at some point. The reasons are: - Old bot is written in java and nearly no one has access to source code, neither is managing it, the bot is still running without problems rather thanks to original creator who did a great work and made a very stable code, extending the bot with more features could be problem. - New bot is in svn (tools/wmib) so that anyone can participate on development and even on operation of the bot - New bot is running on wmf labs so that it should be running on more stable server with better connectivity and also is better accessible for others, because apart of toolsever it's no problem to give acess to service user account to more devs (anyone with svn account can get access there) so that more people can operate the bot and patch it. I converted current database and it's running in #mediawiki-move so that you can try various commands like (!mediawiki !b id), any feedback on this whole idea and bot is welcome also please before you start commiting changes to source code, keep in mind that I now work on splitting it to more files so that we avoid conflicts when commiting changes, it should be done by today. Thanks ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l - Old bot is written in java And C# is an improvement? -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Compiling Debian Packages (was Re: 1.18 PHP version requirement)
So instead of having a script that just has to run basic unix commands in order to manage vhosts you now need something to parse an http.conf file. I'm pretty sure I know what I'd choose. On Nov 20, 2011 1:25 AM, Dmitriy Sintsov ques...@rambler.ru wrote: On 19.11.2011 22:59, Happy Melon wrote: Better here is clearly in the eye of the beholder. The ... My method does not require creation of symlinks and numeric prefixes, that's why it's better. Ancient languages used numeric labels for lines of code. Cut / paste of single text line is faster than renaming symlinks. Commenting line with # is better as well. These points are objective, not subjective. I would stop talking about that yesterday if you weren't insisting that it's a personal preference (it's not). Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Coding Convention: Method chaining
Right now our coding conventions manual never touches on method chaining, nor have I personally seen this practice in core. So I'm interested in what the rest of the community feels about adapting this practice more, and if there are trade offs I'm not aware of. Let's make an example, take this code from Abuse Filter: $out = $this-getOutput(); $out-setPageTitle( wfMsg( 'abusefilter-examine' ) ); $out-addWikiMsg( 'abusefilter-examine-intro' ); So, instead of writing it like that, it could be written $this-getOutput() -setPageTitle( wfMsg( 'abusefilter-examine' ) ) -addWikiMsg( 'abusefilter-examine-intro' ); It's just another style I've encountered on other projects and I personally like. -- John Du Hart ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ticket#2011091710005702] SVN Extension Access
One of the access-granting developers looked at the code sample, Extension:Realnames, and had some criticisms, as it tries to find and replace all username links in the page output HTML, and the User::newFromName( $m['username'] ); query in the callback for each match is not batched. We're really being that nitpicky? I've seen some really shit-quality code committed to extensions, batch calling the User class is really minor thing that (imo) shouldn't halt this process. It's extensions access, not core, he's asking for. That's what I have to say right now, I might some up with something else tomorrow. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
No, maybe stewards but not admins. On Oct 26, 2011 9:40 AM, Olivier Beaton olivier.bea...@gmail.com wrote: Admins should be required (At least at wmf) to use an authenticator, no? On Wed, Oct 26, 2011 at 9:24 AM, Helder helder.w...@gmail.com wrote: On Wed, Oct 26, 2011 at 11:13, Neil Harris n...@tonal.clara.co.uk wrote: If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to set strong passwords, perhaps initially by Javascript-based warnings, and later by locking out those accounts completely, after a warning period of perhaps one year. +1 ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bootstrapping Music (was Re: Bug 189)
On Sun, Oct 23, 2011 at 5:34 PM, John Vandenberg jay...@gmail.com wrote: Does the lilypond '-safe' mode not resolve the security problems? According to the other thread, nope. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] migration to git: available and suggested Web viewers ?
On Sun, Oct 23, 2011 at 6:45 AM, Daniel Friesen li...@nadir-seen-fire.com wrote: On Sun, 23 Oct 2011 02:09:29 -0700, Thomas Gries m...@tgries.de wrote: RE: http://www.mediawiki.org/wiki/Git_conversion For Subversion SVN, ViewVC is a nice repository browser, which we also use on http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/ I searched for similar browsers for git, but could not find similar ones. My starting point was http://stackoverflow.com/questions/438163/whats-the-best-web-interface-for-git-repositories found: gitalist http://www.gitalist.com/ gitweb http://git.or.cz/gitwiki/Gitweb cgit http://hjemli.net/git/cgit/ FishEye (Atlassian, not free) Perhaps, ViewVC can be patched to work with git ? This page http://www.mediawiki.org/wiki/Git_Graphical_User_Interfaces is (currently) only dedicated to Git GUIs, not to Git Viewers: perhaps a page for Git Viewers should be started, too? The general standard is GitWeb, it's even bundled with Gerrit so it will be the default available when git is setup: https://gerrit.wikimedia.org/r/gitweb?p=operations%2Fpuppet.git 'patching' ViewVC to work with git will be impossible. git is fundamentally different from svn so there are so many differences you'll have to rewrite it completely. Besides the ones you list there is one built into Gitorious: https://gitorious.org/mediawiki/mediawiki-trunk-phase3/trees/master When I talked with Ryan Lane about our git setup one of the things he mentioned was how with Labs it would be possible for me to setup Gitorious on Labs, puppetize it, and later have it pushed out to production. Since git is distributed there isn't much to setting up a new git ui. So later on it should be possible for anye of us to setup whatever other git ui we like and have it pushed out to production... heck, we could have as many as we want. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I'll throw GitLab into the ring, http://gitlabhq.com/ It's ruby though, so I don't know if ops will care for that. It does look pretty sweet though. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikipedia lacks a share' button
Why. Why does an encyclopedia need a share button? I can see the purpose on Commons, but for an article? I just don't see the justification. What do you really need to share with your friends from an reference source. What does a button do that copypaste can't? There's also the technical problems this would incur. Each of these buttons require yet another HTTP request each, which would make the hard work by RL team moot. It just doesn't make sense. On Oct 20, 2011 11:54 PM, jida...@jidanni.org wrote: Gentlemen, where is the Share button? All other sites have them by now, but on Wikipedia one cannot even find its definition in http://en.wikipedia.org/wiki/Share . At least on ones account preferences there should be a way to activate sharing with the following websites ... causing a share button to appear in the navigation menu. If there is an extension, then wikipedia should install it and not depend on browser plugins, etc. OK, I made https://bugzilla.wikimedia.org/show_bug.cgi?id=31853 ___ 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] wikipedia lacks a share' button
I agree with this, it's really not a technical issue at this point so it doesn't have a place on wikitech-l On Fri, Oct 21, 2011 at 10:06 AM, Russell Nelson russnel...@gmail.comwrote: This sounds like something non-technical, like you would discuss at a village pump. Maybe you should do that and then get back to us with a greater variety of user opinions? If you're right and this is a dumb idea, then you'll save us a lot of time by canvassing users. -russ On Fri, Oct 21, 2011 at 9:27 AM, John Du Hart compwhi...@gmail.com wrote: Why. Why does an encyclopedia need a share button? I can see the purpose on Commons, but for an article? I just don't see the justification. What do you really need to share with your friends from an reference source. What does a button do that copypaste can't? There's also the technical problems this would incur. Each of these buttons require yet another HTTP request each, which would make the hard work by RL team moot. It just doesn't make sense. On Oct 20, 2011 11:54 PM, jida...@jidanni.org wrote: Gentlemen, where is the Share button? All other sites have them by now, but on Wikipedia one cannot even find its definition in http://en.wikipedia.org/wiki/Share . At least on ones account preferences there should be a way to activate sharing with the following websites ... causing a share button to appear in the navigation menu. If there is an extension, then wikipedia should install it and not depend on browser plugins, etc. OK, I made https://bugzilla.wikimedia.org/show_bug.cgi?id=31853 ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed Authentication Schema for Wikimedia projects
Looks like an interesting idea. The MediaWiki extension needs some work though so I'll fork that and work on it today. On Mon, Oct 17, 2011 at 10:51 PM, packs-24...@mypacks.net wrote: I originally posted this idea on G+ and Arthur Richards suggested I cross-post it here. My friend, Isaac Potoczny-Jones is a computer security professional. He developed a new authentication schema that layers on top of existing technologies and leverages a user's smartphone and QRCodes to improve authentication usability, eliminate human-generated passwords, and further improve security by separating the authentication channel from the login session. He's calling this capability Animate Login and as part of the proof of concept, he developed a MediaWiki implementation. I believe the Wikimedia foundation should pursue adding this technique as part of the primary login options for it's projects. I would personally love to be able to just point my phone at the login screen and have the system log me in to Wikipedia without having to type anything or remember complex passwords. Wikimedia has worked hard to consolidate logins across the many projects over the last couple years and this would be a great way of providing seamless login. It should be very low overhead and relatively easy to implement. Isaac is very interested in seeing his tool put to use on Wikipedia. Wikimedia could lead the way to improved authentication that also vastly improves the user experience! Isaac explains the project in some detail on this Google Plus post: https://plus.google.com/u/0/112702172838704084335/posts/B9UR2zzDY3f?hl=en His landing page for the project is here: http://animate-innovations.com/content/animate-login The website has videos, links to a MediaWiki instance where its in use and more. From the conversations I've had with him, I know that he has thought long and hard about this application and has sought to address/understand all of the potential attack vectors. Compared to human-generated passwords, this would be vastly more secure and dramatically improve the user experience of logging in. It might even entice new or old editors to login and give it a try and thus re-engage them in editing. I'm also certain it could generate a fair bit of buzz as people learn they can use their smartphone to login to Wikipedia. I hope you'll consider working with Isaac. I'll point him to this thread so he knows it is here. I know he'd love to see this implemented in Wikipedia. Don ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Giving up on LiquidThreads
Wow. I'm in a state of complete shock for the lack of care here, #1 for the fact that you (or apparently the whole swedish Wikipedia community which I find very hard to believe) can't put in the 5 minutes needed entering a bug report for something that may effect many others, and (#2) you instead go the route of discussion to end up at a resolution to abandon the system in whole. LiquidThreads has again crashed after the upgrade to MediaWiki 1.18. Something will always break. There are no guarantees that stuff will always work, expect it to be wonky right after deployment (it *IS* pre-release software) We don't see how LiquidThreads could ever become a reliable system It's in the midst being rewritten http://www.mediawiki.org/wiki/LiquidThreads_3.0 Honestly I'm completely blown away by the fact that the remote thought of letting this go unreported for over a *WEEK* without being reported to the technical staff was at any point an acceptable decision, and your response one week later being nah we're just not going to use this anymore. Honestly, how do you all decide not to report an issue as bad sounding as crashed (I'm assuming a DB error of some sort). I'm pretty sure if you reported this when it happened it would most likely be resolved by now. Above all, you have the right to decide that you don't want LQT, but to do so saying that there's some bug and refusing to report it because have no interest in this bug getting fixed is absolutely infuriating to me and probably other developers. (Note: I speak for myself and my own opinions) On Tue, Oct 11, 2011 at 7:38 PM, Lars Aronsson l...@aronsson.se wrote: On 10/12/2011 01:18 AM, K. Peachey wrote: On Wed, Oct 12, 2011 at 9:13 AM, Lars Aronssonl...@aronsson.se wrote: The Swedish Wikisource community has decided not to file any bug report for the fact that LiquidThreads has again crashed after the upgrade to MediaWiki 1.18. So you aren't going to file a bug so everyone else has to suffer and possibly find this bug themselves when it could be fixed if someone filed it? Correct. We have no interest in this bug getting fixed. The matter doesn't exist anymore. It is a non-topic. This is the difference from last time this happened. Thanks for understanding. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Puppet repository published in a public git repository
Wooo, thanks Ryan On Sep 19, 2011 5:09 PM, Ryan Lane rlan...@gmail.com wrote: We've just released our puppet repository into a public git repository. For more information, see the blog post about this: http://blog.wikimedia.org/2011/09/19/ever-wondered-how-the-wikimedia-servers-are-configured/ As noted in the blog post, we are releasing this to treat operations like a software development project. Users with Labs access can push changes to the repository. We aren't currently ready to start giving out Labs access en masse, but will hopefully have a process ready by the New Orleans hack-a-thon. More info to come about Labs later. - Ryan ___ 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] Taking suggestions for a template language syntax for our skin system
It's over complicated for our needs, and we really don't need another full featured language to learn and parse. It's like saying everyone should learn ruby so we can do skins in it. On Sun, Sep 11, 2011 at 12:05 PM, Russell N. Nelson - rnnelson rnnel...@clarkson.edu wrote: Geez, I didn't mean to squash the discussion! TRAC isn't *that* weird a language, is it? From: wikitech-l-boun...@lists.wikimedia.org [ wikitech-l-boun...@lists.wikimedia.org] on behalf of Russell N. Nelson - rnnelson [rnnel...@clarkson.edu] Sent: Thursday, September 08, 2011 2:18 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Taking suggestions for a template language syntax for our skin system How about http://en.wikipedia.org/wiki/TRAC_%28programming_language%29 ? It has the benefit that simple things are simple, but you can create complicated things because it's a full programming language. ___ 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 -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] sep11.wikipedia.org
http://en.wikipedia.org/wiki/September_11_attacks 2011/9/11 Краснов Кирилл krasnovfo...@gmail.com Sorry, what is sep11.wikipedia.org? Is it project Wikipedia Org? Why not domain jan01.wikipedia.org, mar08.wikipedia.org, etc? 2011/9/10 MZMcBride z...@mzmcbride.com: Benjamin Lees wrote: On Fri, Sep 9, 2011 at 1:44 PM, Platonides platoni...@gmail.com wrote: Looks fixed to me (redirects to archive.org) sep11.wikipedia.org redirects to archive.org, but sep11.wikipedia.org/wiki/ still redirects to sep11memories.org. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90092 -- pls. can someone CR and set a status other than new
Why is this so urgent that you cannot wait for someone to get around to doing code review? If you think it should be back ported add a 1.18 tag to the revision. On Thu, Sep 1, 2011 at 2:40 PM, Thomas Gries m...@tgries.de wrote: Re:http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90092 Hi, can someone pls. set this revision to resolved or ok ? My commit r90092 was the basis of several follow-ups, and the latest fix by Brion (*), I then submitted a large suite of testcases http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/tests/qunit/suites/resources/jquery/jquery.highlightText.test.js?view=log for many languages including RTL for Brion's fix (passes all tests, see http://localhost/phase3/tests/qunit/ ) Moreover I think, that his patch http://svn.wikimedia.org/viewvc/mediawiki?view=revisionrevision=94702 (*) should also put back-ported into the 1.17wmf or 1.18 branch. However, I do not know how to request this formally - or informally. Tom ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia architecture overview in #wikimedia-tech
I'll try my best to be there but can we make sure there's a log of this for everyone afterwards? Thanks! On Aug 18, 2011 11:27 AM, Sumana Harihareswara suma...@wikimedia.org wrote: On Mon, Aug 15, 2011 at 8:45 PM, K. Peachey p858sn...@gmail.com wrote: On Tue, Aug 16, 2011 at 10:23 AM, Ryan Lane rlan...@gmail.com wrote: The Ubuntu Ensemble community is going to be working on replicating our environment using Ensemble, inside of the Labs infrastructure. To aid them in this project, I'll be giving them an overview of our architecture in IRC at #wikimedia-tech on Monday, Aug 22, at 17:00 UTC. I'm sure this would also be useful to our own community, so if you are interested, please attend. Come armed with questions. - Ryan Using http://www.worldtimebuddy.com/ I have divined that 17:00UTC is 1pm in New York, 10am in San Francisco, 7pm in Leipzig, and 8pm in Haifa. Mark your calendar! http://www.worldtimebuddy.com/meeting?lid=5128581,2147714,1850147,0,2879139,294801h=5128581sts=21899760sl=13-13 Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ 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
[Wikitech-l] mysql_* functions and MediaWiki
Earlier this month, the PHP developer team moved to start soft deprecating the mysql.so extension via documentation, with a intent to fully E_DEPRECATED in a later release. [1] Therefore, I thought it would be appropriate to start a small discussion as to how this should be handled. At the current moment, MediaWiki is still using these functions in its DatabaseMysql class. Being a new contributor to MW this came across as odd as to why no MySQLi implementation was available, so I went ahead and created one [2] (Patch [3]). Right now it's just another $wgDBtype, how it should really be integrated is what I want to discuss. Should any implementation (not necessarily mine) using MySQLi just be another DBType in the installer perhaps? (Most software I've seen goes this route) Also, at what point (time or event) do we do away with mysql function support? Also, are there any performance regressions with MySQLi that we should be aware about? [1]: http://marc.info/?l=php-internalsm=131031747409271w=http://marc.info/?l=php-internalsm=131031747409271w=2 2 http://marc.info/?l=php-internalsm=131031747409271w=2 [2]: https://github.com/johnduhart/mediawiki-trunk-phase3/commit/552a90f5142bb108cb268e1e47da10351b4f873f [3]: https://gist.github.com/1115789 -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About LQT - on hold?
There won't be anything to test until the rewrite is done since it's still undergoing major changes. There's no point in deploying code and testing for it if that code will change drastically in a few months. On Sun, May 29, 2011 at 12:27 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: 2011/5/29 MZMcBride z...@mzmcbride.com: HW wrote: As of a member of Chinese Wikipedia community, we have submitted a bug https://bugzilla.wikimedia.org/show_bug.cgi?id=29114 on requestion for adding LQT to Chinese Wikipedia. However, it seems that it is on hold. Due to a large amount of comment on Chinese Wikipedia Village Pump, we need it as soon as possible. When will it be enable? Or, need to wait for central action? http://www.mediawiki.org/wiki/Extension:LiquidThreads/Status Thank you for the link. This page says in the end: Production deployment of LiquidThreads with its improved backend to all Wikimedia wikis using LiquidThreads. Timeline: Before Wikimania, August 2. Putting Wikimania as a target date is very nice, because Wikimania and the hackathon that preceeds it will happen in a country that speaks Hebrew and Arabic - right-to-left languages. If the new LQT will be deployed before Wikimania only to wikis that use LQT now, this means that until Wikimania, LQT will not be tested by right-to-left language users on right-to-left language wikis. And so this will become a missed opportunity. If a development version of LQT will be tested on an RTL wiki before Wikimania, the RTL bugs will be already known before the beginning of the hackathon and would be easily fixed during it with the help of Israeli developers that will be present in Haifa. If it won't be tested before Wikimania, fixing these RTL bugs will be much, much harder. And so i repeat my request: Please install LQT on the Hebrew Wikinews and on other wikis whose users offer their help in testing. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com We're living in pieces, I want to live in peace. - T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GitHub Mirror of the svn repository
On Wed, Mar 16, 2011 at 5:48 PM, Brion Vibber br...@pobox.com wrote: On Wed, Mar 16, 2011 at 2:42 PM, Brion Vibber br...@pobox.com wrote: On Wed, Mar 16, 2011 at 2:35 PM, Chad innocentkil...@gmail.com wrote: Could the owners of the github and gitorious mirrors update the project descriptions to indicate that they're inactive? I thought I had access to do this, but apparently not. CC'ing Ævar :) I'm not sure who runs the gitorious mirror. Appears to belong to some mysterious 'svnmirror' user who's mirrored a number of projects... and not updated anything since last summer. :( http://gitorious.org/~svnmirror (I sent a message to that user on Gitorious asking to either add us as admins for the Gitorious 'mediawiki' project or rename it away so we can add our own in that spot that can have a copy of our official mirror.) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Imho svnmirror sounds like a official account for mirroring svns, run by Gitorious. You should poke the people at Gitorious too, no one is going to log into that account anytime soon. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
