Re: [Wikitech-l] All Hands On Deck!
- Original Message - From: Mark A. Hershberger m...@nichework.com Can we get a simple English version of the poetry there? As others have pointed out poetry doesn't translate well, but I've managed to come up with an interpretation that I hope is easy for a non-native speaker to understand. (I admit feeling safer doing this since I wasn't at the all staff and have no clue what this is about. Burn me at the stake later.) --- begin --- In the end, we'll probably just end up doing our job like we have been. --- end --- Hope that is helpful, So I was right: it was a scoff. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] All Hands On Deck!
- Original Message - From: Antoine Musso hashar+...@free.fr Le 23/01/2015 09:11, littlewmfb...@yandex.com a écrit : Oh what a day! Which began when perforce a visitor from afar began to exhort snip https://lists.wikimedia.org/pipermail/wikitech-l/2015-January/080300.html Hello, Can we get a simple English version of the poetry there? Seems it is related to last week Wikimedia all hands meeting, but I have hard time understand the text, the point of it or what should be done :-] Poetry doesn't lend itself to translation well, but I read it as a scoff, myself. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I haven't looked lately...
- Original Message - From: Daniel Friesen dan...@nadir-seen-fire.com On 2015-01-18 5:29 PM, Jay Ashworth wrote: - Original Message - From: James Forrester jforres...@wikimedia.org Three quick examples of things on the horizon (I'm not particularly saying we'd actually do these for Wikimedia's use, but if you're going to ask for straw man arguments… :-)): - Get rid of wikitext on the server-side. Are we still litigating should we piss off the power user editors* in the service of making things easier for notional new ones? Or have I misunderstood the suggestion? Parsoid can do Parsoid DOM to WikiText conversions. So I believe the suggestion is that storage be switched entirely to the Parsoid DOM and WikiText in classic editing just becomes a method of editing the content that is stored as Parsoid DOM in the backend. Aha! Sorry; I was behind on Parsoid, was the problem. Yeah, if there's a way to edit in MWtext, both for humans and programs, then that serves the use cases I would be concerned about. Thanks for the prompt clarification, Daniel. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: No more Architecture Committee?
- Original Message - From: Chad innocentkil...@gmail.com I've been saying for over a year now we should just drop the 1. from the 1.x.y release versions. So the next release would be 25.0, 26.0, etc etc. Oh dear ghod, no. I already want to massacre the entire release management staff at Mozilla for being this foolish. Just because we shouldn't *plan* for a 2.0 does not mean there never *will* be one. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] I haven't looked lately...
- Original Message - From: James Forrester jforres...@wikimedia.org Three quick examples of things on the horizon (I'm not particularly saying we'd actually do these for Wikimedia's use, but if you're going to ask for straw man arguments… :-)): - Get rid of wikitext on the server-side. Are we still litigating should we piss off the power user editors* in the service of making things easier for notional new ones? Or have I misunderstood the suggestion? Cheers, -- jra [* understanding that that's not the *only* thing which killing off wikitext breaks, merely the one that came first to mind ] -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: No more Architecture Committee?
- Original Message - From: Rob Lanphier ro...@wikimedia.org On the leadership front, let me throw out a hypothetical: should we have MediaWiki 2.0, where we start with an empty repository and build up? If so, who makes that decision? If not, what is our alternative vision? Who is going to define it? Is what we have good enough? shrug/ :-) Seriously: Oh ghod, please, no. I'm not a real big fan of Joel Spolsky, as some people are, but I do in general agree with his assertion that throwing everything out and starting from scratch is nearly always an unconscionable approach to anything, especially something as sizable as MediaWiki. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Stance on Social Media
- Original Message - From: Tim Starling tstarl...@wikimedia.org *contradicting the serious tone In my experiance, some wikipedians (esp. On enwiki) feel the wiki should have a very formal tone, and that share this links are out of place. Ive always wondered if thats partially in response to all the wikipedia is unreliable talk from academics when 'pedia first became popular causing people to want wikipedia to have a dry academic feel associated with reliability. Surely this is an untenable argument now that the websites of so many scientific journals have share links? e.g. http://ajcn.nutrition.org/content/65/6/1721.abstract I personally attribute that to we're so small, we have to cave on this point or no one will know we're here, a problem a small journal might have, but which Wikipedia certainly does not. I'm on the don't bother side, for nearly all the reasons previously enumerated. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Our CAPTCHA is very unfriendly
- Original Message - From: Ryan Kaldari rkald...@wikimedia.org spambots. We just have to jump out of the existing captcha design band-wagon. Here are some ideas: Surely we can come up with a creative idea that is: * Easy for humans to solve * Can't be solved by out-of-the-box captcha breakers * Isn't trivial for programmers to solve I would like to suggest a slight variant on something google's doing now, that I don't think they got quite right. Pick half a dozen animals of which there are many specie variants, say, dog, cat, snake, bird, etc. Show the user one such animal, and a 3x3 grid with 4 animals from that species, and 5 which are from the others, 64x64px ought to be plenty. Ask them to click on all the animals of the same species. Assuming we can word that in a way that doesn't fail for people who don't know species are. Without losing the advantages of using pictures by *saying* cat, that is. The key here is to make the evaluation criteria sufficiently clear; the google implementation seems to require too much introspection into which characteristics of the pictured object they want you to match. Once you've captcha'd then, you could, I would expect, put a cookie on the browser good for some amount of time and hashed against, say, the browser ID string or something so it's not portable? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshedding a good name for the api.php API
- Original Message - From: Quim Gil q...@wikimedia.org On Thu, Aug 7, 2014 at 1:42 PM, Legoktm legoktm.wikipe...@gmail.com wrote: I like api.php too, given that we refer to the old one as query.php. You are in a keynote session at OSCON introducing... which API? Please think on a name that is meaningful for the 3rd party developers out there, not just for you. api.php alone won't work. We aren't calling such things the Classic API these days? :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki now supports PBKDF2 and Bcrypt
- Original Message - From: Tyler Romeo tylerro...@gmail.com It is a matter of stability in PHP. Bcrypt has built-in support in PHP, as does PBKDF2, whereas scrypt requires an extension. It should be noted, however, that the patch that was merged implements an extensible password API, so it would be trivial to implement scrypt support if we wanted to. Yup: figure out what general case your particular problem is a special case of, and then implement the general case. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Offline-l] The Whole Wikipedia in English with pictures in one 40GB big file
- Original Message - From: Emmanuel Engelhart kel...@kiwix.org PS: We really want to make a post @blog.wikimedia.org (so in English). If someone is volunteer to write this, I would really appreciate his help. If you write such a blog post in what English you have handy, I'd be happy to English it up for you; you know what points you want to make better than I would. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Non-Violent Communication
- Original Message - From: Derric Atzrott datzr...@alizeepathology.com Have any of you ever heard of Non-Violent Communication (NVC). No, but I don't think it's an optimal choice of name. In my view, it's accusing of a malevolent motivation people who are not you, who may not *hold* such a motivation... and whether they did or not, they won't be all that thrilled with having you call it that. One of the alternative names you suggest might end up being a better long-term strategic choice. For the record, I rewrote that at least 3 times. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] !ask
- Original Message - From: MZMcBride z...@mzmcbride.com I've used '!ask' a lot before but I'm going to stop. I hope others do the same. So really you're going for !!ask. !ask used to be more direct (some would say meaner) and I'm a little sad to see it go away, but I suppose snotty replies can always be made manually. ;-) Well, perhaps if it expanded as IRC is a worldwide network, and many users are logged into it while doing other things. Ask your question, supplying as much detail as possible, and one of them may reply, even if it takes a while. In other words: don't ask to ask, just ask? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] HTML Storage for Wikidata (was Re: Revamping interwiki prefixes)
- Original Message - From: Gabriel Wicke gwi...@wikimedia.org Currently Flow is the only project using HTML storage. We are working on preparing this for MediaWiki proper though, so in the longer term the interwiki conflict issue should disappear. Where, by HTML storage I hope you actually mean something that isn't HTML storage, since HTML is a *presentation* markup manguage, not a semantic one, and thus singularly unsuited to use for the sort of semantic storage a wiki engine requires... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] L3 outage reports at Equinix Ashburn
That's where we are, right? Some people on outages are reporting no-light on on-campus fibers*; if we see an uptick in problem reports this morning, that might be why. Cheers, -- jra * specifically DC2 to DC5 -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] OT: Happy Birthday, Wikipedia!
The Paley Center for Media notes on Twitter that Wikipedia is 13 years old today. Thanks to Jimmy and He Who Shall Not Be Named, and to Brion, Tim, Mark and all the hundreds of other dev, ops, admin and outreach people who brought us to this point; each of you has made it possible for the tens of thousands of editors of Wikipedia to change the world, one edit at a time. Nowhere special. I've always wanted to go there. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
- Original Message - From: Ken Snider ksni...@wikimedia.org After working through the specifics internally, we now have a public RFP posted[1] and ready for proposals. We invite any organization meeting the requirements outlined to submit a proposal for review. My snap reaction, Ken, is that the RFP seems fairly thin on relevant details; how many passes did it go through before you posted it? How much input came from the Ashburn project? Equinix Tampa? Or was it left loose on purpose, to see what people would come up with? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
Well, perhaps I'm unfairly comparing the RFP's density to that of the last two colo contracts I saw, but I'm not sure I have a copy of those; I will take a look, and abide until them. Cheers, -- jra - Original Message - From: Leslie Carr lc...@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Sent: Monday, October 21, 2013 10:52:36 AM Subject: Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions I'm curious which details you would like to see? On Mon, Oct 21, 2013 at 5:22 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Ken Snider ksni...@wikimedia.org After working through the specifics internally, we now have a public RFP posted[1] and ready for proposals. We invite any organization meeting the requirements outlined to submit a proposal for review. My snap reaction, Ken, is that the RFP seems fairly thin on relevant details; how many passes did it go through before you posted it? How much input came from the Ashburn project? Equinix Tampa? Or was it left loose on purpose, to see what people would come up with? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Officially supported MediaWiki hosting service?
- Original Message - From: Ryan Lane rlan...@gmail.com On Wed, Oct 2, 2013 at 12:48 PM, C. Scott Ananian canan...@wikimedia.orgwrote: One intermediate position might be for WMF to distribute virtual machine images I'd rather provide cloud-init scripts with instructions on how to use them. The cloud init script could pull and run a puppet module, or a salt module, or etc. etc.. Providing images kind of sucks. Ok, time for me to throw an oar in the water, as an ops and support guy. My perception of Brion's use of officially supported was, roughly, whomever is providing support to these hosting customers has a direct, *formal* line of communication to the development staff. The reason you build images, and version the images, is that it provides a clear solid baseline for people providing such support to know (and, preferably, be able to put their fingers on) exactly the release you're running, so they can give you clear and correct answers -- it's not just going to be the Mediawiki release number that's the issue there. That's impossible to do reliably if you pull the code down and build it sui generis on each customer's machine... which is what I understand Ryan to be suggesting. It's a little more work to build images, but you're not throwing it away; you get it back in reduced support costs. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Improving anti-vandalism tools (twinkle, huggle etc) - suspicious edits queue
- Original Message - From: MZMcBride z...@mzmcbride.com Much of the content on Wikipedia and other Wikimedia wikis comes from non-vested contributors. That is, many, many helpful additions and corrections come from people who will make only a few edits in their lifetime. While I can't disagree with the suggestion that reverting is easier than fact-checking, I very much doubt that assuming bad faith helps build a better project or a better community. And this is to say nothing of the fact that the seemingly simple act of providing a reference is often painful and unintuitive, particularly in established articles that employ complicated markup (infoboxes, citation templates, and ref tags). My first 2 edits at TV Tropes had this property: not only were they reverted, they were both reverted with snotty comments about procedure, and *the second one was me doing what the first one had yelled at me for not doing*. And I got yelled at the second time for following instructions. I gave up. It's fun to read, but not worth my time to contribute to. I concur with MZM: We don't want to become that. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] In case you missed this:
How many printers would it take to keep up with updates to Wikipedia? http://what-if.xkcd.com/59/ Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [RFC]: Clean URLs- dropping /wiki/ and /w/index.php?title=..
- Original Message - From: MZMcBride z...@mzmcbride.com The RFC currently seems to gloss over what problem is attempting to be solved here and what benefits a new URL structure might bring. I'd like to see a clearer statement of a problem and benefits to a switch, taking into account, for example, the overarching goal of making URLs fully localized. Concur, especially in light of the face that *this does not permit you to break the old URLs*. They are everywhere, *and they must continue to work forever*. I hope I don't even have to justify why. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [RFC]: Clean URLs- dropping /wiki/ and /w/index.php?title=..
- Original Message - From: Steven Walling steven.wall...@gmail.com How about the following? Our current URL structure is extremely obtuse for non-technical users, and generally defies their expectations. To most people, en.wikipedia.org/Dogor even wikipedia.org/Dog should work just fine, not produce a 404. Any collection of most people large enough to justify a change like this is, I assert, too technically unsophisticated to be attempting to construct URLs by hand (rather than by copy/pasta). Do you propose to fix also the capitalization and spacing and URLescaping rules, which are much more complicated than that? My considered reaction, now after several hours, is that this is fixing a problem which is not really broken for *anyone* except those who are OCD about hiding the tech-y look in the Location box. No offense. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] editsection styling
- Original Message - From: Lee Worden worden@gmail.com I ask because I've been producing editsection-like links for a long time in our extension project, with commas in between - for example a LaTeX document will come with a list of links like [log, pdf, dvi]. Maybe I should switch to using pipes instead of commas. I'm not sure if there's a *policy* answer, but I would say that my opinion is that a pipe is a better separator than a comma for two reasons: 1) Commas have a left-affinity (which pipes don't) and 2) Commas expect a following space (whereas you can do pipes with or without as long as you make the same choice on both sides). Therefore, for this category of separator, I think pipes would be less jarring to readers -- at least English readers. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] You know, we really should shift to Windows
- Original Message - From: David Gerard dger...@gmail.com http://www.rightscale.com/blog/cloud-cost-analysis/cloud-cost-analysis-how-much-could-wikipedia-save-cloud How many machines do we have right now? Couple hundred? What's a Win2008 server license going for? What percentage of our budget is that, anyway? 50? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia's anti-surveillance plans: site hardening
- Original Message - From: Zack Weinberg za...@cmu.edu The first step really must be to enable HTTPS unconditionally for everyone (whether or not logged in). I see on the roadmap that there is concern that this will lock out large groups of users, e.g. from China; a workaround simply *must* be found for this. Everything else that is worth doing is rendered ineffective if *any* application layer data is *ever* transmitted over an insecure channel. There is no point worrying about traffic analysis when an active man-in-the-middle can inject malicious JavaScript into unsecured pages, or a passive one can steal session cookies as they fly by in cleartext. I understand your goal, and your argument, but I've just this week been reminded that It Isn't Always China. I found myself stuck on a non-rooted Android phone, and having to use a demo version of a tethering app ... which wouldn't pass HTTPS on purpose. Ironically, that's why it was the demo: I couldn't get through it to PayPal to buy it from them. My point here, of course, is that you have to decide whether you're forcing HTTPS *for the user's good* or *for the greater good*... and if you think it's the former, remember that the user sometimes knows better than you do. If it's the latter, well, you have to decide what percentage of false positives you're willing to let get away: are there any large populations of WP users *who cannot use HTTPS*? EMEA users on cheap non-smart phones that have a browser, but it's too old -- or the phone too slow -- to do HTTPS? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia's anti-surveillance plans: site hardening
- Original Message - From: Brian Wolff bawo...@gmail.com Thanks for taking the time to write these two emails. You raise an interesting point about having everything on one domain. I really don't think that's practical for political reasons (not to mention technical disruption), but it would allow people to be more lost in the crowd, especially for small languages. Some of the discussion about this stuff has taken place on bugzilla. Have you read through https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 ? I should think we might be able to run a proxy that would handle such hiding, no? Personally I think we need to make a more formal list of who all the potential threats we could face are, and then expand that list to include what we would need to do to protect ourselves from the different types of threats (or which threats we chose not to care about). Some kid who downloads a firesheep-type program is very different type of threat then that of a state agent, and a state agent that is just trying to do broad spying is different from a state agent targeting a specific user. Lots of these discussion seem to end up being: lets do everything to try to protect against everything, which I don't think is the right mindset, as you can't protect against everything, and if you don't know what specifically you are trying to protect against, you end up missing things. Definitely: the potential attack surfaces need to be explicitly itemized. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [outages] www.wikipedia.com from Level3 via IPv6 not working
- Original Message - From: Mark Bergsma m...@wikimedia.org We had the same result in the Level3 looking glass, but while we were debugging it and trying to gather more info or hosts/networks affected, it started working again in the L3 LG as well. So it appears that the problem was resolved. Problems reported on NANOG or Outages often 'magically fix themselves'. :-) Cheers, - jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] python vs php
I will pass your approbation on to ESR :_) Cheers, -- jra - Original Message - From: Yuvi Panda yuvipa...@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Sent: Saturday, July 27, 2013 2:55:46 PM Subject: Re: [Wikitech-l] python vs php Can we all just agree that haskell, clojurescript and INTERCAL are the best ever, and move on? -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Have production server access? Please read this document
- Original Message - From: Leslie Carr lc...@wikimedia.org The Ops team has been working on a document about best practices with regards to production machines. If you have access to a production machine, please read this document https://wikitech.wikimedia.org/wiki/Server_access_responsibilities Very nicely done. Noting the license, I'll probably steal it in turn. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: [ PRIVACY Forum ] French homeland intelligence threatens a volunteer sysop to delete a Wikipedia Article
In case y'all missed this: - Forwarded Message - From: PRIVACY Forum mailing list priv...@vortex.com To: privacy-l...@vortex.com Sent: Saturday, April 6, 2013 3:10:01 PM Subject: [ PRIVACY Forum ] French homeland intelligence threatens a volunteer sysop to delete a Wikipedia Article French homeland intelligence threatens a volunteer sysop to delete a Wikipedia Article http://j.mp/16C8Cxn (Wikimedia France) Unhappy with the Foundation's answer, the DCRI summoned a Wikipedia volunteer in their offices on April 4th. This volunteer, which was one of those having access to the tools that allow the deletion of pages, was forced to delete the article while in the DCRI offices, on the understanding that he would have been held in custody and prosecuted if he did not comply. Under pressure, he had no other choice than to delete the article, despite explaining to the DCRI this is not how Wikipedia works. He warned the other sysops that trying to undelete the article would engage their responsability before the law. This volunteer had no link with that article, having never edited it and not even knowing of its existence before entering the DCRI offices. He was chosen and summoned because he was easily identifiable, given his regular promotional actions of Wikipedia and Wikimedia projects in France. - - - The return of Vichy France mentalities, apparently. --Lauren-- Lauren Weinstein (lau...@vortex.com): http://www.vortex.com/lauren Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info Founder: - Network Neutrality Squad: http://www.nnsquad.org - PRIVACY Forum: http://www.vortex.com/privacy-info - Data Wisdom Explorers League: http://www.dwel.org - Global Coalition for Transparent Internet Performance: http://www.gctip.org Member: ACM Committee on Computers and Public Policy Lauren's Blog: http://lauren.vortex.com Google+: http://vortex.com/g+lauren / Twitter: http://vortex.com/t-lauren Tel: +1 (818) 225-2800 / Skype: vortex.com ___ privacy mailing list http://lists.vortex.com/mailman/listinfo/privacy -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: New unified SSL certificate deployed
- Original Message - From: Ryan Lane rlan...@gmail.com On Wed, Mar 13, 2013 at 9:24 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Ryan Lane rlan...@gmail.com Hey, Ryan; did you see, perhaps on outages-discussion, the after action report from Microsoft about how their Azure SSL cert expiration screwup happened? What's the relevance here? Does ops have a procedure for avoiding unexpected SSL cert expirations, and does this affect it in any way other than making it easier to implement?, I would think... We didn't have a certificate expiration. We replaced all individual certificates, delivered by different top level domains, with a single unified certificate. This change was to fix certificate errors being shown on all non-wikipedia domains for HTTPS mobile users, who were being delivered the *.wikipedia.org certificate for all domains. The unified certificate was missing 6 Subject Alternative Names: mediawiki.org, *.mediawiki.org, m.mediawiki.org, *.m.mediawiki.org, m.wikipedia.org and *.m.wikipedia.org. Shortly after deploying the certificate we noticed it was bad and reverted the affected services ( mediawiki.org and mobile) back to their individual certificates. The change only affected a small portion of users for a short period of time. If you notice, I've already mentioned how we'll avoid and more quickly detect problems like this in the future: Needless to say I'll be writing a script that can be run against a cert to ensure it's not missing anything. We'll also be adding monitoring to check for invalid certificates for any top level domain. I don't really think it was necessary to be this defensive, do you? Well, clearly, you do. My apologies for trying to be helpful in making sure you saw an analysis with useful information in it. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate deployed
- Original Message - From: Ryan Lane rlan...@gmail.com We just finished deploying a new SSL certificate to the sites. Now all *.m and *. certificates are included in a single certificate, except mediawiki.org. Unfortunately we somehow forgot mediawiki.org when we ordered the updated cert. We'll be replacing this soon with another cert that had mediawiki.org included. This should fix any certificate errors that folks have been seeing on non-wikipedia m. domains. Hey, Ryan; did you see, perhaps on outages-discussion, the after action report from Microsoft about how their Azure SSL cert expiration screwup happened? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate deployed
- Original Message - From: Ryan Lane rlan...@gmail.com Hey, Ryan; did you see, perhaps on outages-discussion, the after action report from Microsoft about how their Azure SSL cert expiration screwup happened? What's the relevance here? Does ops have a procedure for avoiding unexpected SSL cert expirations, and does this affect it in any way other than making it easier to implement?, I would think... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate deployed
- Original Message - From: Jeremy Baron jer...@tuxmachine.com Can you just link to the discussion archive? Was a posting: http://blogs.msdn.com/b/windowsazure/archive/2013/03/01/details-of-the-february-22nd-2013-windows-azure-storage-disruption.aspx Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: Brian Wolff bawo...@gmail.com Minification is a WMF cluster issue, not a MW software issue, is it not? Mediawiki minifies things regardless of if its being run by the WMF or somebody else. Ah; thanks. Have not looked at internals lately. Since minification to me as a netadmin is a strategic size of pipe issue, I assumed it was something deployed on WMF sites, not something baked into the base package. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: David Gerard dger...@gmail.com People will say any spurious bollocks What's the license on that observation, David? :-) Cheers, -- jr 'I wanna steal that' a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: MZMcBride z...@mzmcbride.com The Open Source Initiative doesn't seem to really like the idea: http://opensource.org/faq#cc-zero. A number of former and current contributors (notably Lee Daniel Crocker) have released their creative works and inventions into the public domain: https://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker. I've always found CC-Zero and its surrounding arguments to be pretty stupid. I release most of the code I write into the public domain (though most of it lacks sufficient creativity in any case). My understanding is that CC-Zero exists *because the public domain does not exist in the IP law of many countries*. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: Chris Grant chrisgrantm...@gmail.com This is based on a flawed reading of the GPL. The GPL covers the distribution of program code. The license specifically states that “The act of running the Program is not restricted”. (Furthermore: “Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.”) The terms you are all referring to relate to the distribution of the software, not the running of the software. Wikipedia.org, does not distribute the software, that is MediaWiki.org's job. If Wikipedia wanted to, we could remove all licensing information from the software and it would still be completely legal. The GPL *only* comes into effect once you start distributing the software. The problem here, Chris, is what constitutes 'distributing the software'? WP is *sending a copy of the JS from its servers to a client PC, there to be executed*. *We* consider that incidental, but a court might not; decisions I'm aware of have gone both ways. So that might *be* the distribution step, legally, and trigger the license requirement. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: Platonides platoni...@gmail.com Regarding GPL requisites, it seems clear that minified javascript is “object code” [1], which we can convey per section 6d [2], which is already possible if you know how the RL works, although we should probably provide those “clear directions”. Most problematic would be that you should also obey sections 4 and 5 (although I see a bit of contradiction there, how are you supposed to “keep intact all notices” where most notices are present in comments, designed to be stripped when compiled?) But are we conveying it? To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. As javascript is executed in the client, it probably is. Perhaps. But HTML is also executed in the client, and some legal decisions have gone each way on whether the mere viewing of a page constitutes copying in violation of copyright (the trend is towards no, thankfully. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: Jack Phoenix j...@countervandalism.net Let me just state this for the record: I find copyright paranoia and associated acts, such as this very thread with 59 (and counting!) messages absurd, ridiculous and a complete waste of time. We note that you have spoken. Alas, the other 153 people who own copyright in the code in question haven't and, no offense, Jack, assuming they will have the same outlook you do -- when it's on the record that developers' opinions on this range to both ends -- is probably not a safe enough bet for the foundation. :-} Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: Chad innocentkil...@gmail.com Jack is not alone. The amount of bikeshedding on this list has reached truly epic proportions in the last couple of weeks...to the point where I've started ignoring the vast majority of the list (and I've always been an advocate for the usefulness of this list). While I disagree as to whether minified code needs a human readable embedded license, I don't think it's reasonable to characterize the discussion as bikeshedding, Chad. I care about the licensing on my code. I'm not alone. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: Mark Holmquist mtrac...@member.fsf.org The minification process, however, does *not* cause a problem. We can simply add the comments to the file(s) after the minification. It does mean we'll need to include, potentially, multiple license headers in one HTTP response, but that shouldn't cause much issue. I am neither an engineer, nor a WMF staffer, but I want to throw a flag here anyway. Yes, it will cause an issue. If that extra data is going in every reply, multiply its size by our replies per day count, won't you? I don't know what that number is, but I'm quite certain it's substantial. *Every single byte* that goes in a place where it will be included in every reply directly affects our 95%ile data transfer, I should think, and thus our budget. Bytes are not always free. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: Tyler Romeo tylerro...@gmail.com Yes, it will cause an issue. If that extra data is going in every reply, multiply its size by our replies per day count, won't you? I don't know what that number is, but I'm quite certain it's substantial. *Every single byte* that goes in a place where it will be included in every reply directly affects our 95%ile data transfer, I should think, and thus our budget. Bytes are not always free. True, but if it's legally required it's not like we have an option. Certainly. But I see no reason to think it's legally required. And while I, too, only play one on the Internet, I've been doing it since 1983. And I haven't been surprised all that often. Mr Villa will come up with a more researched decision, certainly, but I am relatively certain that a defensible case can be made that minifying is equivalent to compiling, for the purposes of the license. And in the unlikely event that's not good enough, the Foundation may well be able to get a codicil license on the relevant libraries, acknowledging that it needn't include the license text in on-the-wire minified copies. My personal opinion, though, is that the proper approach is that the license be officially interpreted by its issuer to exempt this sort of minification-caused potential violation, as otherwise, minification will negatively affect everyone who uses it, many of whom haven't WMF's budget. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Seemingly proprietary Javascript
- Original Message - From: Tyler Romeo tylerro...@gmail.com But WMF getting a license doesn't help everybody else who uses MW. Minification is a WMF cluster issue, not a MW software issue, is it not? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OpenID as a provider project page
- Original Message - From: Ryan Lane rlan...@gmail.com I wrote up some quick documentation on OpenID as a provider. Feel free to modify it, especially for inaccurately used terminology. It's also likely a good time to start bikeshed discussions on the urls, as I think it'll end up taking a while to lock that down. I supposed if I take issue with calling URL choice a bikeshed, that would constitute bikeshedding, right? :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] switching to something better than irc.wikimedia.org
- Original Message - From: Tyler Romeo tylerro...@gmail.com I think a very light weight proxy that only passes subscribe commands to redis would work. A read only redis slave could be provided but I don't think it includes a way to limit what commands clients can run, including administrative ones. I think we'd want a thin proxy layer in front anyways, to track and if necessary, selectively limit access. It could be very simple though. Mhm, in that case this might be a viable solution. Dumb question: is the work ESR recently did on irker on-topic for this conversation, and did anyone know it existed? :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
- Original Message - From: Leslie Carr lc...@wikimedia.org Can you try with https now ? I had forgotten to reload apache when pushing out a change to the https config (to allow https without login). You can also use http. https://icinga.wikimedia.com is now confirmed accessible, yes. One issue, possibly specific to me: I'm old, my laptop has a 12 screen. So I am prone to put Firefox in Zoom Text Only mode, and run the zoom up to read stuff. Icinga handles that pretty well, in our implementation, with one exception: that tab, top right, that has the icinga logo in it also appears to contain some summary data, and that part blows off the right edge of the screen (though it impinges on the Icinga text logo even at normal size). Not sure that's fixable, but I thought I'd mention it. Thanks for getting this up, regardless. And that service that's running status. is very spiffy; is that commercial? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] cleaning database of spam
- Original Message - From: Platonides platoni...@gmail.com What is exact procedure of properly removing page from database so that it doesn't break anything? What needs to be deleted and in which order? maintenance/deleteArchivedRevisions.php permanently removes the content of deleted pages from the db. For removing those users, see http://www.mediawiki.org/wiki/Extension:User_Merge_and_Delete Also remember that due to the way mysql works, it may not release those 20GB back to the filesystem. In particular, to get anything for your trouble, you will probably need to dump the database, drop it, shut down MySQL and switch it to innodb tablespace-per-file, turn it back on, and then reload the dump, as I recently had to. This way, at least, once you clean it up, you can do the same dump and reload procedure on only one table, not the whole shootin' match. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] cleaning database of spam
- Original Message - From: Petr Bena benap...@gmail.com You meant innodb_file_per_table Yes; I forgot the exact name, and tried (apparently unsuccessfully) to make that look as little like an exact parameter as possible. Happily, the OP runs that way anyway. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] DevOps/Continuous Deployment discussion?
- Original Message - From: Juliusz Gonera jgon...@wikimedia.org On 02/20/2013 12:04 PM, Luke Welling WMF wrote: I am strongly of the opinion that within broad ranges deployment frequency does not matter. It really does not matter if you deploy twice an hour or every second day. What teams deploy every second day? The ones who accidentally shipped a brown-paper-bag bug 2 days ago. ;-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
- Original Message - From: Ryan Lane rlan...@gmail.com On Tue, Feb 26, 2013 at 5:32 PM, Leslie Carr lc...@wikimedia.org wrote: As some may have noticed, we are phasing out nagios in favor of icinga ( https://www.icinga.org/ ) nagios.wikimedia.org now redirects to icinga.wikimedia.org ! Please let us know if you notice anything that has broken or is inconsistent. Awesome work Leslie! And thanks for the pointer, too; didn't realize the fork had happened. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
- Original Message - From: Liangent liang...@gmail.com nagios.wikimedia.org now redirects to icinga.wikimedia.org ! Please let us know if you notice anything that has broken or is inconsistent. So now there's no public view of server monitoring info? http://status.wikimedia.org/ always shows nagios as disrupted now. No, having done this sort of thing before, I would speculate that it just slipped off their checklist, and they thank you for reminding them. I thank you for reminding *me* that was there in the first place, though I see that I once knew, for it is already listed here: http://wiki.outages.org/index.php/Dashboard Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
- Original Message - From: Leslie Carr lc...@wikimedia.org Icinga is public. It may be, but that URL goes to an HTTPS Auth dialog, with nothing behind it if one cancels. Perhaps something was missed? -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
- Original Message - From: Jeremy Baron jer...@tuxmachine.com On Feb 26, 2013 11:25 PM, Matthew Bowker matthewrbowker.w...@me.com wrote: I hate to be that guy, but is it supposed to be password protected? Is there somewhere non-ops people can look for server status, or is http://status.wikimedia.org it? try HTTP instead of HTTPS. (I don't know anything about why they're not the same or how long they've been like that.) Noted. Understand that for people who have HTTPS-anywhere installed (which should be approximately everyone by now), that will be a common question. Cheers, - jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
- Original Message - From: Ryan Lane rlan...@gmail.com I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects. I, too, want to clarify: you're proposing centralizing WMF identity to whatever extent it is not already centralized, and then using OpenID *within MWF*: so that all WMF sites and installed extensions can auth users against our own user database? Not authenticating users against external OID providers (which, as nearly as I can tell, largely amount to I am whom I say I am), or allowing external non-WMF sites to authenticate against our user database. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
- Original Message - From: Ryan Lane rlan...@gmail.com Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider. So, then, all OpenID guarantees is this provider says it's the same person it was last time? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
- Original Message - From: Ryan Lane rlan...@gmail.com I see no reason in doing so. If third parties want to allow Wikimedia as a provider, I don't see why we'd object. There is no potential liability there? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
- Original Message - From: Marc A. Pelletier m...@uberbox.org On 02/22/2013 10:44 PM, Jay Ashworth wrote: There is no potential liability there? IANAL, but I can't think of a scenario where allowing a user to prove I am user X on Wikimedia projects can create liability; if the client is pleased with the (proven) assertion for their purposes, they can use it. If not, they won't. If those are the accepted semantics of the reply, then I retract the concern. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
Original Message - From: Marc A. Pelletier m...@uberbox.org On 02/22/2013 10:43 PM, Jay Ashworth wrote: So, then, all OpenID guarantees is this provider says it's the same person it was last time? The exact semantics is, IIRC, that person has presented credential to us we accept as identifying them as our user $IDENTIFIER. Whether the client trusts that $IDENTIFIER is reasonably stable for their purposes, or that they trust our word, is their call. I'm translating that as yes. :-) I've always looked with rather a jaundiced eye at OpenID, as it was sold as you can run your own authenticator service, and that always struck me as I am who I say I am, which is, obviously, pretty useless, in the general case. (Early examples showed login boxes where you *provided the URL of a random OID provider*; clearly, if the site doesn't trust said provider, the transaction is useless.) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
- Original Message - From: Daniel Barrett d...@vistaprint.com 1. A desire for a department to have their own space on the wiki. I'm not talking about access control, but (1) customized look feel, and (2) ability to narrow searches to find articles only within that space. The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax NamespaceName:SearchString. However, this is not a pleasant solution, because it's cumbersome to precede every article title with NamespaceName: when you create, link, and search. If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level). I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc. Some way to search within categories reliably would also be a huge win. Lucene provides incategory: but it misses all articles with transcluded category tags. 2. Hierarchy. Departments want not only their own space, they want subspaces beneath it. For example, Human Resources wiki area with sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet. MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it goes since the main namespace is flat. I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it? What you want, I think, is what Zope2 called acquisition. It's like OO subclass inheritance, but it's *geographic* depending on where you were in the tree; the old Mac Frontier system did something like it too. You want links to have a Search Path, that starts with whatever part/ subpart of the tree the current page is in, and then climbs the tree, ending in the unadorned Main namespace, whenever a user clicks them. That breaks the semantics of wikilinks some, but that's probably ok for your use. It *might* be generally useful; I'm trying to figure out if there are any obvious common use cases that it breaks, and how you tell where in the tree a page lives when it's created (and how you would show that to users). Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Integrating MediaWiki into MS SBS
- Original Message - From: Dan Andreescu dandree...@wikimedia.org The following manual seems to be the most actively maintained guide for getting MediaWiki installed on Windows: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows If you run into any problems, I'd suggest adding them to the manual along with any resolutions you or others come up with. Good luck! I'm not sure he actually wants to run it on Windows. He may just need SSO with Active Directory. https://encrypted.google.com/search?q=mediawiki+active+directory Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New 1.20.2 install didn't prompt for license or private mode
Is that stuff supposed to go after one chooses no, ask me more questions? Cause I was not asked *any* more questions. On a related story: if I give the installer a table prefix for which the tables already exist, what will it do? I have 3 wikis in the same DB, and I therefore cannot simply drop the DB... and you apparently can't use wildcards in DROP TABLE. Cheers, -- jr 'Bobby; where are ya'? a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages
- Original Message - From: . oscar.vi...@gmail.com It could be interesting (but I have no idea if is feasible), if git recognize automatically elements in a commit text, and colorize it on the terminal screen (or maybe bold it if the screen renders using truetype fonts). This way, if you have written wikidata many times, you will quickly spot a problem if the commit renders to you with fixed wkidata bug by reversing the polarity and wikidata is not bolded/colored different. A alternate would be for this script/program, to extract keywords and present to you, so if you notice the commit lack the label wikidata, theres something wrong. Talk to the people over on the derivative wikitext list, spun off to contain discussions relevant to creating a replacement MWText parser (there are, I think 5 or 6 projects in varying degrees of activity; though the list itself is pretty quiet). Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update on Ashburn data center switchover / migration – target date is week of 1/22/13
- Original Message - From: Guillaume Paumier gpaum...@wikimedia.org On Fri, Jan 11, 2013 at 10:48 PM, Jay Ashworth j...@baylink.com wrote: I have forwarded this to the Outages mailing list, so that people who want to know/get complaints about such things have advance warning. Thank you :) For those, like me, who upon reading that message wondered if there was an outages-l among the gazillion Wikimedia mailing lists, Jay is referring to a third-party mailing list: https://puck.nether.net/mailman/listinfo/outages Yeah; nerdview is even bad among nerds. Outages is a collection of 3 mailing lists, a wiki, and a social media report tracker run by Virendra Rode with some help from Frank Bulk and I; Jared Mauch supplies the list reflectors. Our wiki has, among other things, a page that collects useful network testing and diagnostic tools, which I really need to groom again -- if you look at it, and find something missing or broken, let me know. :-) It runs, of course, Mediawiki. (Is there anything else?) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update on Ashburn data center switchover / migration – target date is week of 1/22/13
I have forwarded this to the Outages mailing list, so that people who want to know/get complaints about such things have advance warning. Cheers, -- jra - Original Message - From: Ct Woo ct...@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org, Development and Operations Engineers engineer...@lists.wikimedia.org Sent: Friday, January 11, 2013 3:07:15 PM Subject: [Wikitech-l] Update on Ashburn data center switchover / migration – target date is week of 1/22/13 All, The Migration team is in the last lap on completing the remaining tasks to ready our software stack and Ashburn infrastructure for the big switchover day. Per my last update,http://lists.wikimedia.org/pipermail/wikitech-l/2012-October/063668.html with the Fundraising activity behind us now, the team has scheduled the *week of 22nd January*, 2013 to perform the switchover. We are going to block a 8-hour migration window on the *22nd, 23rd and 24**th*. During those periods, *17:00 UTC to 01:00 UTC hours (9am to 5pm PST*), there will be intermittent blackouts and they will be treated as 'planned' outages. You can follow the migration on irc.freenode.org in the #wikimedia-operations channel. The team is putting the finishing touches to the last few tasks and we will make the final Go/No decision on 18th Jan, 2013. An update will send out then. For those interested in tracking the progress, the meeting notes are captured on this wikitech pagehttp://wikitech.wikimedia.org/view/Eqiad_Migration_Planning#Improving_Switchover . *Please note that we will be restricting code deployment during that week, allowing only emergency and critical ones only.* Thanks. CT Woo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] What's our Bus Factor?
It's the new year, and in light of the recent poll about which devs are working on what, let me make another, albeit vaguely macabre, suggestion: If you're a developer, or other staffer, can the people around you pick up the pieces if you get hit by a bus? How badly will it impact delivery and delivery scheduling of what you're working on? Is the institutional knowledge about our architecture and plans sufficiently well documented and spread out that we don't have anyone with an unreasonably high bus factor? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
- Original Message - From: Asher Feldman afeld...@wikimedia.org If lock timeout throws an exception that closes the connection to mysql, at least that will result in a rollback. If the connection is pooled and reused, it can likely result in a commit. I would assert that if that's true, than connection pooling is unacceptably Broken As Designed. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Url Shortner Service
- Original Message - From: Petr Bena benap...@gmail.com That doesn't allow you to type wi.ki/en/Donut in order to open article, shortened url is also hard to remember Well, there's nothing for that. wi.ki/en/Donut is not a shortened URL... cause what if the article you were interested in was List of episodes of Buffy The Vampire Slayer? base36 shortnames, all lower case, please. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Images in wikipedia
- Original Message -
From: nischay nahata nischay...@gmail.com
When using wikipedia and clicking on an image it opens up on a new
page.
Wouldn't it be nice if it just scaled-up on the same page using JS. Is
there an extension there for this? and if yes why not implemented on
wikipedia?
I'm not sure how well that would work in Opera Mobile on my Evo.
Cheers,
-- jr 'all the world is not {the www,a PC,running Windows,etc}' a
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS load order, or: how to load a gadget before all others.
- Original Message - From: Thomas Schmidt schm...@netaction.de As you said, the preferred implementation would be something that's close to the parser and puts extra annotations (like span tags) in the parser-generated HTML You talk about up to several megabytes per page. It was my snap reaction as well that putting span markers in the HTML at blame edges wasn't gonna scale very well... and could be pathological. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Email notification sender
Original Message -
From: Strainu strain...@gmail.com
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Sent: Tuesday, January 3, 2012 3:32:09 PM
Subject: Re: [Wikitech-l] Email notification sender
2012/1/3 Erik Moeller e...@wikimedia.org:
On Sat, Dec 31, 2011 at 10:09 AM, Thomas Dalton
thomas.dal...@gmail.com wrote:
Why do email notifications from Wikipedia have the sender as
MediaWiki Mail? Most Wikipedia users probably don't know what
MediaWiki is. I suggest it be changed to Wikipedia or
Wikipedia
notifications or something like that.
I agree with the {{SITENAME}} suggestion, and would prefer to omit
Mail. (The fact that it's an email is self-evident.)
I wouldn't be so fast in leaving only the sitename as sender name - a
mail from Wikipedia would raise my (manual) spam alarms, just like
emails from the Federal Bureau of Investigations or from [X] Bank.
For my part, I believe that Mediawiki Mail is proper, as it's mail *generated
by the named program* (note: not site).
If you reverse it to Wikipedia/media, though, it's from the site, not the
program, and the expected usage indeed changes not to include Mail.
Cheers,
-- jra
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Based Open Source Project - Help On Licencing
- Original Message - From: Tim Starling tstarl...@wikimedia.org On 30/12/11 08:30, Dan Collins wrote: On Thu, Dec 29, 2011 at 4:24 PM, Huib Laurens sterke...@gmail.com wrote: It doesn't need to be compatible or open-source right? GPL 2.0 section 2 b: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. You can modify GPL software for private use. That clause only kicks in when you distribute or publish the work, so you're generally OK if you're just using it within a single company. Maybe that's what Huib meant by closed source. And since we're not under the *Affero* GPL, you can modify it, *and make it publicly available*, and still not be constrained by the licence (I don't think I've got that backwards, do I?) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ 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.
- Original Message - From: Dan Collins en.wp.s...@gmail.com On Bugzilla, bugs which are minor enhancements should not be tagged highest priority unless the priority is truly highest. This should certainly not be done en masse without personally reviewing the bug itself. Technological fact is not subject to democracy. On my Bugzilla installations, the Severity is owned by the reporter, but the Priority by the assignee; this seems the best approach to me... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making the Lua/Javascript decision (Re: Performance roadmap update)
- Original Message - From: Victor Vasiliev vasi...@gmail.com Lua is great, however, it's a bit strange to use two interpreters (PHP+Lua) together. That limits hosting possibilities and it's something like using two similar screwdrivers for the same screw. Not really. Lua was designed as a sandboxable language, and PHP was not. This is a really critical point: if you're going to provide an interpreted language to end-users from within a program that is, itself, written in an interpreted language, *you cannot use the underlying interpreter* to run the end-users' programs, unless that interpreter has sandboxing built-in. If you try, you will almost certainly be exposing yourself to critical security vulnerabilities. You're almost *better* off picking a different language, so that you're not tempted to try. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making the Lua/Javascript decision (Re: Performance roadmap update)
- Original Message - From: Peter Kaminski kamin...@istori.com I don't have anything particular against Lua and no particular love for JavaScript, but JS seems more web-native; plus code and skills developed can accrue to both client- and server-side of the web. Just so I'm clear: this is a server-side question? Cause if it's client side, JS is already in the browser seems pretty compelling to me... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Diff colors - a disaster waiting to happen
- Original Message - From: Brandon Harris bhar...@wikimedia.org It's the exact same yellow as before, guys. The *exact* shade. This is the exact definition of a bikeshed argument. Feel free to move along. I don't see, Brandon, that Erwin suggested that it is not. But no, colorization of elements of a user interface is in fact *not* a bikeshed argument: these colors actually matter to people, because they have culturally ingrained expectations about what they mean -- though those cultures may be geopolitical or they may be intentional (programmers, geeks, etc). Additionally, of course, there are best practices for how far apart colors should be to be easily distinguishable, what luminance and saturation work best, and what color combinations are bad for colorblind people. So please, stop taking this stuff personally, and address the issue? You're a designer; you know know better than to have ego tied up in the results... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Diff colors - a disaster waiting to happen
- Original Message -
From: Chad innocentkil...@gmail.com
As they say on enwiki, [citation needed].
Well, we probably say {{citation-needed}}, but... :-)
Cheers,
-- jra
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Diff colors - a disaster waiting to happen
- Original Message - From: Brandon Harris bhar...@wikimedia.org The yellow is *unchanged* Is this not what Erwin's on about? So. What was *supposed* to be a 15 minute task has now turned into a drama - over something I don't really care that much about anyways. Well, that's a sort of intemperate attitude to have over an accessibility issue, isn't it? :-) I'm much more attuned to this stuff myself since I turned 45, and became unable to focus on stuff closer than 2 feet from my face. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Diff colors - a disaster waiting to happen
- Original Message - From: Ryan Lane rlan...@gmail.com Green has a meaning of Go or of this is ok in many cultures. Making either side green gives a bias to the diff. Similarly with red. Red means Stop or this is not ok. Many people associate red with blood, and green with nature. And in some cultures, yellow signifies death or cowardice. It's almost impossible to completely disambiguate cultural cues for something the size and spread of Wikipedia, except possible on a wiki by wiki basis; I mentioned it only for completeness. That said, the original complainer's original complaint was that the yellow in question *was not changed* to complement the chosen blue, in his estimation. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Diff colors - a disaster waiting to happen
- Original Message - From: Steven Walling steven.wall...@gmail.com On Thu, Dec 22, 2011 at 1:58 PM, Brion Vibber br...@pobox.com wrote: * the only important thing about the colors is that the text is legible We could save this debate by just making them the same color. ;-) /trolling Oh; we're inaugurating Whacky Weekend on this list too? Cool! Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Performance roadmap update
- Original Message - From: Tim Starling tstarl...@wikimedia.org So we've decided to defer our HipHop deployment until hhvm is at a suitable level of maturity. We don't know exactly when that will be, but Jason Evans says in the note linked above that the first 90% is done; now we're on to the second 90% as we make it really shine. It's good to hear that Jason understands the realities of tool development, isn't it? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deployment process clarification?
I nominate this posting for should be posted on meta. - Original Message - From: Tim Starling tstarl...@wikimedia.org To: wikitech-l@lists.wikimedia.org Sent: Thursday, December 15, 2011 1:57:42 AM Subject: Re: [Wikitech-l] Deployment process clarification? On 15/12/11 12:05, Ian Baker wrote: Hi, everyone. I'm looking for some clarification about the process whereby code gets deployed on the Wikimedia cluster. Not so much the technical side of things, and in fact, I'd love to keep this conversation VCS-agnostic. We'll be moving to git soon and things will change, but these questions apply regardless. I've been working to review a new extension that Petr Bena wrote, InteractiveBlockMessage. It's a simple little extension that adds some template magic for blocked users, to facilitate the creation of less confusing talk page templates. This bug has links to the relevant code and on-wiki discussions: https://bugzilla.wikimedia.org/show_bug.cgi?id=32819 Usually an experienced developer, most often with shell access, needs to champion a contributed extension if it's going to be deployed. Championing can be a long and complex process. There is no written policy that says this, and maybe it's not ideal, but in my experience, it's how things work. A champion associates their name with an extension. They become a maintainer and point of contact for any problems with the extension after deployment, especially if the volunteer is not available every day. So championing usually begins with an initial cycle of code review and improvement, to get the extension to a suitable level of quality so that maintenance requests after deployment won't be excessive, and so that the champion's reputation won't be at risk. A champion is usually a WMF staff member, so the champion will need to convince their manager that spending time on the extension is a good idea, and that the extension will be useful to deploy. Staff member or not, the champion needs to convince relevant stakeholders, such as senior developers and the ops team, that the deployment should go ahead. The champion is ultimately responsible for community consensus-gathering (if necessary) and announcements, but they may be able to delegate these tasks to the extension creator. That done, the champion will perform the actual work of deployment, such as scheduling, merging to the deployment branch, and configuration. After deployment, the champion's role as a maintainer begins, which may include deploying any urgent updates provided by the extension creator, and discussing bug reports. It's a lot of work, and it's undervalued, maybe because we've never discussed this process openly. We like to think that there is some queue that extensions go into, and that the extension will slowly make its way to the front of the queue and be deployed. In practice, an extension will only get to the front of the queue if there is a champion in front of it elbowing people out of the way (figuratively speaking). It sounds like you want to be the champion for InteractiveBlockMessage. I think it's excellent that you want to get into that line of work. I'd be happy to give you advice and to help you with the process. It's not a problem that you don't have shell access at the moment, you can just apply for it. Process B is what I'm used to, but it seems that for this extension, it's process A. When do we pick one or the other? Is process A for community-contributed code, whereas B is for stuff from WMF? Do things change when we're deploying a whole new extension? I understand that this process is informal, and I'm not necessarily pushing to formalize it, but maybe a few general guidelines or a minimum standard would help make things more clear. I have been hearing a lot of resentment from community members about the features team deploying extensions without properly consulting the community, let alone building consensus. My recommendation is that if you want to deploy an extension which is likely to be even slightly controversial, you should seek community consensus, regardless of who you work for. Running a well-publicised straw poll is a useful and rewarding experience. You'll get a huge amount of design input. The step where Someone Who's Been Around A While reviews the code makes sense, but it seems to be applied inconsistently, or perhaps the conditions for that just aren't clear. When does code need to be run past one of these very busy people, and when is it okay to push it without? Is there a way to indicate which code needs this review, and when it's done aside from the existing 'OK' status in CR? Secondly, who *are* these people? I've heard Roan and Tim so far, but I bet there are more. It depends on the nature of the extension. Some extensions need special skills to review, such as performance analysis,
Re: [Wikitech-l] LocalWiki released
- Original Message - From: Philip Neustrom phi...@localwiki.org http://localwiki.org We just did our first general-public software release. * Everything is stored as HTML5. We threw out wiki markup. I hope that works out well for you. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help us test the VisualEditor prototype
- Original Message - From: Neil Harris n...@tonal.clara.co.uk On 13/12/11 21:27, Neil Kandalgaonkar wrote: That is really cool; at long last, the WYSIWYG editor is not just on its way, but looking really good! Once the wikitext parser (which is, of course, the hard part) is ready to be bolted in, that should give a big improvement in Wikipedia's accessibility for new editors -- almost everyone knows how to use a word processor. Yup. And they use them to write email. pessimist Which is just as bad an idea as using them to write wikitext. /pessimist Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
Is this custom code? Or does BZ4 include it, and I simply haven't found it yet? Cheers, -- jra - Original Message - From: reporter repor...@kaulen.wikimedia.org To: wikitech-l@lists.wikimedia.org Sent: Sunday, December 11, 2011 10:00:01 PM Subject: [Wikitech-l] Bugzilla Weekly Report MediaWiki Bugzilla Report for December 05, 2011 - December 12, 2011 Status changes this week Bugs NEW : 296 Bugs ASSIGNED : 12 Bugs REOPENED : 33 Bugs RESOLVED : 149 Total bugs still open: 6701 Resolutions for the week: Bugs marked FIXED : 114 Bugs marked REMIND : 0 Bugs marked INVALID : 6 Bugs marked DUPLICATE : 14 Bugs marked WONTFIX : 11 Bugs marked WORKSFORME : 4 Bugs marked LATER : 2 Bugs marked MOVED : 0 Specific Product/Component Resolutions User Metrics New Bugs Per Component android 21 ArticleFeedbackv5 15 General/Unknown 7 Parser 3 Site requests 3 New Bugs Per Product MediaWiki 28 Wikimedia 7 MediaWiki extensions 46 Wikimedia Mobile 21 Security 1 Top 5 Bug Resolvers sam [AT] reedyboy.net 27 yoni [AT] omniti.com 16 jeroen_dedauw [AT] yahoo.com 14 hashar [AT] free.fr 10 yaron57 [AT] gmail.com 9 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki 2.0
- Original Message - From: Tim Starling tstarl...@wikimedia.org I think MediaWiki 2.0 should just be a renumbering, like Linux 2.6 - 3.0, rather than any kind of backwards compatibility break. I disagree. (You knew that was coming, right? :-) A major version number change *necessarily implies* an API compatibility break of some type, or a major rewrite. In the case of 2.6 to 3.0 of the kernel, as someone pointed out to me, the change was *in the numbering protocol itself*; prior to 3.0, odd numbers were dev; that's no longer true, which makes it a suitable break to bump the major version number. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki 2.0
- Original Message -
From: Erik Moeller e...@wikimedia.org
IMO a switch to a visual editor as the default editing environment
would be sufficient to merit the 2.0 moniker. Heck, it'd be sufficient
to get rid of the double square brackets in the logo. ;-)
And either of those would be a good thing... why?
Cheers,
-- jr '{{get-offa-my-lawn}}' a
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dropping the 'LATER' resolution in Bugzilla
- Original Message - From: Diederik van Liere dvanli...@gmail.com The question is, when is LATER? Technically, these bugs are not open and so nobody will ever see them again and that's how they will be forgotten. I would assume that LATER is, in a release after this one... and that the proper solution is to do as you suggest (stripe them back to NEW) *after the next release is cut*. Anyone think that's a bad idea? Do we have a Target release in our BZ? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who actually reads @wikimediatech ?
- Original Message - From: Guillaume Paumier gpaum...@wikimedia.org I'm wondering if there are actually people reading all the stuff that's pushed through these channels. Now that I know it's there, I'll certainly be reading it; thanks for the headsup. ;-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who actually reads @wikimediatech ?
- Original Message - From: Guillaume Paumier gpaum...@wikimedia.org Meanwhile, we don't really have social media channels dedicated to Wikimedia tech stuff, i.e. channels where we can actually post stuff, links, blog posts, outage info, etc and engage with a larger community of people interested in our tech operations. I feel that the accounts would be much more useful if we reduced the amount of semi-random information we post there. So, I'm basically proposing to repurpose the @wikimediatech accounts for this. I think I concur with whomever suggested stripping logmsgbot's postings out of that to a separate feed, as well, now that I've looked at it. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who actually reads @wikimediatech ?
- Original Message - From: Guillaume Paumier gpaum...@wikimedia.org Not silly at all. As a matter of fact, while you were writing that, I was registering @wikitechlog on both services, which I think is a better alternative for automated notifications. What you said. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dropping the 'LATER' resolution in Bugzilla
- Original Message - From: Dan Collins en.wp.s...@gmail.com Do we want that second category to be resolved later? If so, we're going to be waiting a long time for people to come back with more details. Should bugs that are resolved later because the original requester or someone else needs to provide more info instead be closed invalid, or something else? Isn't there a CLOSED MOREINFO? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dropping the 'LATER' resolution in Bugzilla
- Original Message - From: Mark A. Hershberger mhershber...@wikimedia.org Jay Ashworth j...@baylink.com writes: Do we have a Target release in our BZ? We've begun using Milestones in Bugzilla for this. One of the milestones is Mysterious Future. I think you should feel free to use that instead of LATER. I love this, and am promptly stealing it for my own. -- j -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Torrus down?
torrus.wikimedia.org/torrus is 500 tonight; is that expected? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Mediawiki-l] MediaWiki 1.18.0 released
- Original Message - From: Brion Vibber br...@pobox.com Allow me to extend my personal thanks to everybody who helped out on development, testing, review, testing, deployment, testing, breaking, fixing, and releasing of MediaWiki 1.18. It's a big process but by golly we're still rolling those things out! :) And, amazingly, no one felt the need to call this release... MediaWiki 18! Cheers, -- jr 'mumble,grumble,java,SCO,Firefox,Asterisk,bitch,piss,moan' a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla vandalism
- Original Message - From: Platonides platoni...@gmail.com On 23/11/11 06:46, trouble daemon wrote: On Tue, Nov 22, 2011 at 4:11 PM, Platonides platoni...@gmail.com wrote: After fixing one bug, going to close another as a duplicate less than a minute after the previous save, doesn't seem strange. There can even be a few of them. But from Tor? Sure, walking into a bank and asking for lots of money is common too, unless you are wearing a mask ;) According to http://xkcd.com/980, Batman has a fortune of $6,500,000,000 I was just pointing out a common case (probably more for hexmode or sumanah). You can then tune it to not hit false positives. Or you can just put in a manual override if it *thinks* it has a positive, whether a captcha (of increasing frequency), or go to IRC and get a cookie from a human that's good for an hour. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla vandalism
- Original Message - From: Tim Starling tstarl...@wikimedia.org Reverting hundreds of bug property changes was labour intensive. It points to the need for better tools to deal with malicious behaviour in Bugzilla. I looked into the possibility of writing an automated revert tool as a command-line perl script integrated with Bugzilla, but it looked like it would be fairly complicated: Might there be some relatively easy way to hack rate limiting into the code? In general, except for triage WONTFIX runs, I shouldn't think any given user would need to comment on or status-change a bug more than about every minute or two, possibly with an exponential backoff. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla vandalism
- Original Message - From: Platonides platoni...@gmail.com Might there be some relatively easy way to hack rate limiting into the code? In general, except for triage WONTFIX runs, I shouldn't think any given user would need to comment on or status-change a bug more than about every minute or two, possibly with an exponential backoff. After fixing one bug, going to close another as a duplicate less than a minute after the previous save, doesn't seem strange. There can even be a few of them. Fair point. I don't have any non-vandalism clickstream stats, so I can't tell you whether that invalidates the suggestion, or merely means you have to tune it better. Allow 5 changes in 3 minutes, and then require a 30 second delay that doubles after every three additional changes? You see what I mean. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please preload a space in the page for the banner
- Original Message - From: jida...@jidanni.org S == Strainu strain...@gmail.com writes: S Otherwise they will just go on the AdBlockPlus list. No wonder Wikipedia ads are so irritating (besides making babies cry), they are the only ads on the net one still sees these days, http://www.google.com/search?q=wikipedia+banner+fundraiser+adblockplus Wow the sense of (unwarranted) entitlement among most of those comments complaining about this policy is just... breathtaking. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
