[Wikitech-l] Codex code splitting: ResourceLoader now supports loading individual Codex components

ur plans, see the epic task <https://phabricator.wikimedia.org/T349423> on Phabricator. Roan Kattouw Software engineer on the Design Systems Team at the Wikimedia Foundation ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wi

[Wikitech-l] Announcing Codex 1.0

Today the Design Systems Team is announcing the release of Codex 1.0! What is Codex? Codex is the new design system for Wikimedia. Over the past 2 years, the Design Systems Team and contributors from the

[Wikitech-l] Soliciting input on server rendering of user interfaces discussion (includes server-side rendering)

or task where I list different server rendering methods and make a simple (probably too simple) proposal for when to use which. If you're interested in this topic, please go to https://phabricator.wikimedia.org/T322163 and participate in the discussion there. Roan Kattouw Lead engineer on the D

[Wikitech-l] MediaWiki now supports ES6

ge, and to James Forrester and Ed Sanders for code reviewing the linter changes and releasing new versions of all these packages. Roan Kattouw On behalf of the Vue migration team (Anne Tomasevich, Eric Gardner, Volker Eckl, and myself) [1] https://www.mediawiki.org/wiki/Compatibility/IE11 [2] htt

Re: [Wikitech-l] How to invalidate a ResourceLoader URL that depends on user-generated content?

Yes, it takes 5 minutes for just about everything to update in ResourceLoader. This is also true for ResourceLoaderSiteStylesModule: when you save an edit to e.g. MediaWiki:Common.css, you don't immediately see the styles change. However, previewing edits to MediaWiki:Common.css does work, because

Re: [Wikitech-l] Unbreak now! problem in this week train Watchlist

This sounds like it could have been caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/416198 ‪On Thu, Mar 14, 2019 at 10:29 AM ‫יגאל חיטרון‬‎ wrote:‬ > Hello. There is a regression problem, that started on this week deployment. > I can see it in group 1 from yesterday evening. I do not

Re: [Wikitech-l] [Ops] Changes to SWAT deployment policies, effective Monday April 30th

Will multi-file, single-directory syncs still be allowed? In other words, can I deploy a change to the Foo extension that touches many files with scap sync-dir extension/Foo ? On Thu, Apr 26, 2018, 15:15 Greg Grossmeier wrote: > Hello, > > I have made two changes to SWAT policies today. > > Firs

Re: [Wikitech-l] First step for MCR merged: Deprecate and gut the Revision class

Thanks! Context for those who don't want to read a couple hundred lines of IRC logs: I was cooped up in the house all day and noticed it was about to get dark, so I really did take a walk (relatively abruptly) after dealing with the worst of the issue. During this walk I thought things over and re

Re: [Wikitech-l] Wikis paused at 1.28.0-wmf.18 (was: Re: Upgrade of 1.28.0-wmf.19 to group 1 is on hold)

What are your plans for when you'll deploy wmf.19, branch wmf.20 and deploy wmf.20? I ask because I have a patch lined up that I wanted to merge today right after the wmf.20 branch cut, because I want it to spend the full week on beta labs before it goes to production. I can merge that patch today

Re: [Wikitech-l] [Ops] Canary Deploys for MediaWiki

On Jul 25, 2016 16:12, "Bryan Davis" wrote: > > I think Alex is "more right" here. If you are introducing a new $wmgX > var you really should always sync-file the changed InitialiseSettings > file first and then the CommonSettings that uses it. There's no really > good reason to spew a bunch of "u

Re: [Wikitech-l] [Ops] Canary Deploys for MediaWiki

Note to deployers: when syncing certain config changes (e.g. adding a new variable) that touch both InitialiseSettings and CommonSettings, you will now need to use sync-dir wmf-config, because individual sync-files will likely fail if the intermediate state throws notices/errors. (It was a good id

[Wikitech-l] Today's RFC meeting on IRC: Standardise on how to access/register JavaScript interfaces

My apologies for the short notice. Normally we announce these more than one hour in advance, but I forgot. In today's RFC meeting, we will discuss the following RFC: * Standardise on how to access/register JavaScript interfaces

Re: [Wikitech-l] i would like that i need not set standart spacing in my code

On Wed, Oct 14, 2015 at 10:23 AM, Jon Robson wrote: > All code standards are currently being enforced by jscs. > They recently closed an issue to add auto-formatting > https://github.com/jscs-dev/node-jscs/issues/516 There's also the --fix flag to jscs, which automatically fixes whitespace-only

Re: [Wikitech-l] New RFC: better JS minification

On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson wrote: > Thanks, I thought I was alone with being confused by this e-mail. As > Jérémie correctly states we'll likely to get __less__ bugs with a more > maintained library. Less than zero? No one has managed to find a single bug in JavaScriptMinifier.p

Re: [Wikitech-l] Collaboration team reprioritization

On Wed, Sep 2, 2015 at 11:20 AM, Roan Kattouw wrote: > I don't think we currently have good documentation on how you can convert > your own wiki, but AFAIK "simply" running the convertAllLqtPages.php > maintenance script on a wiki that has both LQT and Flow installed sh

Re: [Wikitech-l] Collaboration team reprioritization

On Wed, Sep 2, 2015 at 6:21 AM, David Gerard wrote: > Did the stuff to port LQT threads/pages to Flow ever make it to > production quality? > > It was used to convert all LQT pages on mediawiki.org, including [[mw:Support desk]] which is probably the largest LQT page that has ever existed. So it

Re: [Wikitech-l] Collaboration team reprioritization

On Wed, Sep 2, 2015 at 6:51 AM, Risker wrote: > I am certain once the team has a chance to refocus, they may choose to > examine workflows that are common across multiple Wikimedia projects that > would benefit from improvement. Off the top of my head, creating a > "deletion" wizard in collabora

Re: [Wikitech-l] [Wmfall] Marielle Volz joins Wikimedia as Software Developer

On Mon, Oct 27, 2014 at 11:48 AM, Tomasz Finc wrote: > I am pleased to announce Marielle Volz joining the Wikimedia > Foundation as a Software Engineer for the Editing team. > Welcome Marielle! > and started developing a node.js service Citoid[5] to > make it easy to insert citations using a URL/

Re: [Wikitech-l] RFC meeting this week

On Tue, Oct 7, 2014 at 4:08 AM, Tim Starling wrote: > * Australia AEST: Thursday 07:00 > Ironically, Tim miscalculated the time in his own timezone :D it's 08:00 AEST. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikime

Re: [Wikitech-l] Tell my favorite conference about your Wikimedia tech

On Jun 12, 2014 4:08 PM, "Luis Villa" wrote: > I got a balloon ride the year I spoke. It was trumped the next year by a > helicopter ride. Definitely an amazing trip. > Wow, when was that?! I got no such thing :) In 2012 they did take all the speakers a show (and dinner) at a staged Gold Rush tow

[Wikitech-l] Tell my favorite conference about your Wikimedia tech

The linux.conf.au conference, which I have presented to and love going to, just opened up its call for talks: http://linux.conf.au/cfp . They want talks about all kinds of open source programming stuff, not just Linux: Trevor and I presented about ResourceLoader in 2012, and James and I presented

Re: [Wikitech-l] Bot flags and human-made edits

On Mon, May 19, 2014 at 4:09 PM, Dan Garry wrote: >1. When editing via the API, allows the user to choose whether or not to >flag an edit as a bot edit using the bot parameter. I'm responsible for this part of the mess. I don't remember why it was done this way though. I think the people t

Re: [Wikitech-l] [Wmfall] Rob Moen takes on new role in Growth team

Thanks for all your work on VE, Rob, and best of luck on the growth team! Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Roadmap and deployment highlights - Week of April 14th

On Fri, Apr 11, 2014 at 4:15 PM, Greg Grossmeier wrote: > * VisualEditor fixes: > ** Adding a reference adds an empty one; editing a reference inserts a >new one > ** fix JS error on opening redirect pages > +Enable VisualEditor on French Wikinews per community request ___

Re: [Wikitech-l] Grrrit-wm down for a few hours

On Mon, Mar 17, 2014 at 10:33 AM, Yuvi Panda wrote: > Hello! > > I was a terrible maintainer, and forgot to migrate grrrit-wm to eqiad > tools before the cutoff date. As a result, it will be down for a few > hours as Coren does a batch migrate of all the things. Apologies for > the disruption > Th

Re: [Wikitech-l] Welcoming David Chan to Wikimedia Language Engineering team

On Tue, Jan 7, 2014 at 4:06 AM, Alolita Sharma wrote: > Hi everyone, > > Please join me in welcoming David Chan as software engineer in the Language > Engineering team. Most you already know David from his awesome work on the > Visual Editor (VE) team integrating language support for the VE. We en

Re: [Wikitech-l] [Wmfsf] Announcement: Kunal Mehta joins Wikimedia as Features Contractor

On Thu, Dec 12, 2013 at 5:08 PM, Terry Chay wrote: > Hello everyone, > > It’s with great pleasure that I’m announcing that Kunal Mehta[1] has joined > the Wikimedia Foundation as contractor in Features Engineering. > Sweet! Welcome, Kunal! Roan ___ Wik

Re: [Wikitech-l] Module storage is coming

On Tue, Dec 3, 2013 at 12:30 AM, Ori Livneh wrote: > We'll gradually enable module storage on all Wikimedia wikis over the > course of the next week or two. Ori deployed this to the live site earlier today :) . For reference, the original post about module storage is archived at [1]. I tweeted an

Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?

On Wed, Sep 25, 2013 at 3:46 PM, Chad wrote: > I actually like this idea a lot and it's way less confusing than my idea. > Unless anyone's got any objections I'm going to go ahead and do this > for all the 1.20 and 1.21 wmf branches. > Sounds good to me. Roan

Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?

On Wed, Sep 25, 2013 at 2:53 PM, Chad wrote: > wmf-foo -> 1.22wmf19 > wmf-bar -> 1.22wmf20 > wmf-baz -> 1.22wmf21 > wmf-foo -> 1.22wmf22 > wmf-bar -> 1.22wmf23 > This looks like it's exactly the same concept as slot0/slot1/slot2 in Ryan's git-deploy proposal. The objection that I would have to th

Re: [Wikitech-l] VE/Migration guide for gadgets developers

On Tue, Sep 24, 2013 at 11:45 AM, Sumana Harihareswara wrote: > Roan, how did that go? Any links? :-) > The code ended up being written and merged. The documentation ended up not being written before Wikimania, and then Life happened. Some Time Soon I hope to get around to actually writing this up

Re: [Wikitech-l] Git migration: complete

On Fri, Jul 26, 2013 at 2:57 PM, Chad wrote: > With the moving of pywikibot to Gerrit today, the last projects actively > using SVN have > been moved over to Git. As such, SVN is now a read-only service and the > migration is > done (of course any old SVN projects can always be migrated to Git/Ger

Re: [Wikitech-l] dirty diffs and VE

On Wed, Jul 24, 2013 at 2:49 PM, C. Scott Ananian wrote: > For what it's worth, both the DOM serialization-to-a-string and DOM > parsing-from-a-string are done with the domino package. It has a > substantial test suite of its own (originally from > http://www.w3.org/html/wg/wiki/Testing I believe

Re: [Wikitech-l] dirty diffs and VE

On Wed, Jul 24, 2013 at 3:10 AM, Marc Ordinas i Llopis wrote: > As Subbu said, I'm currently working on improving the round-trip test > server, mostly on porting it from sqlite to MySQL but also on expanding the > stats kept (with things like performance, etc.). If you think of some other > data w

Re: [Wikitech-l] VE and

On Tue, Jul 23, 2013 at 2:14 PM, John Vandenberg wrote: > There is an enhancement for that. > > https://bugzilla.wikimedia.org/show_bug.cgi?id=51897 > > IMO the current behaviour isnt correct. There are so few instances > that nowiki is desirable, that the current VE should refuse to accept > wik

Re: [Wikitech-l] VE and

Whoops, didn't realize this thread had been forked off while I was out to lunch, and so I responded to the other thread. Sorry about that :( On Tue, Jul 23, 2013 at 1:11 PM, Steve Summit wrote: > This is a likely enough mistake, and the number of times you > really want explicit double square bra

Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs

On Tue, Jul 23, 2013 at 12:44 PM, Daniel Barrett wrote: > Risker asks: >>Why do you think those tags were added by the editors? > > I can't speak for the original poster, but the last time I used VE, > it added unwanted tags by itself. > You can see an example in my most recent bug report: > htt

Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs

On Mon, Jul 22, 2013 at 11:41 AM, John wrote: > Minimal java-script load my ass, Your language and tone are inappropriate. Please keep it civil. > I guess you must be using a fiber-optic > connection. Most pages already have a lag due to the amount of JS needed to > run the site. Jumping pages ha

Re: [Wikitech-l] VE/Migration guide for gadgets developers

On Mon, Jul 22, 2013 at 9:51 AM, Eran Rosenthal wrote: > Hi, > When the ResourceLoader was deployed (or even before it) to production, > there were migration development guides for gadget/extension developers: > >- > > http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extens

Re: [Wikitech-l] Alternative editor?

On Fri, Jul 19, 2013 at 1:06 PM, Derric Atzrott wrote: > Are there any extensions that make use of this hook? Does > VisualEditor? No, VisualEditor doesn't use this hook. Instead, it uses JavaScript to insert edit links and/or modify existing ones. The editor itself is also entirely JavaScript-ba

Re: [Wikitech-l] Git config trick.

On Fri, Jul 19, 2013 at 10:40 AM, Ori Livneh wrote: > In ~/.gitconfig, add: > > [url "ssh://your_usern...@gerrit.wikimedia.org:29418/mediawiki/extensions/"] > insteadOf = "ext:" > > Now you can: > > git clone ext:UploadWizard > > ! > "!" indeed. Sweet trick, dude, thanks! Roan __

Re: [Wikitech-l] Australia (was Re: conferences, Hacker School, Code for America)

On Fri, Jul 19, 2013 at 5:54 AM, Quim Gil wrote: >> CFP Extension Announced linux.conf.au 2014 - linux.conf.au !!! >> Now it's July 20. >> http://linux.conf.au/media/news/27 > > > ... and this is tomorrow. > Beware that because of Australia's far-east timezone, it's already tomorrow there :) Roan

Re: [Wikitech-l] [Mediawiki-api] Blacklisted?

There was an API outage yesterday (Sunday July 14th) between roughly 12:00 and 14:00 UTC (5am-7am Pacific Time). As part of our firefighting we blocked the IPs that were hitting the API the hardest at the time. We didn't have time to do outreach because things were on fire and falling over; I'm ver

Re: [Wikitech-l] [Wmfall] Announcement: C. Scott Ananian joins Wikimedia as Senior Features Engineer

On Thu, Jul 11, 2013 at 3:24 PM, Terry Chay wrote: > Hello everyone, > > It’s with great pleasure that I’m announcing that C. Scott Ananian[1] has > joined the Wikimedia Foundation as a Features Engineer. > Welcome! I'm excited to hear you're officially with us now. Roan

Re: [Wikitech-l] [SOLVED] Re: ResourceLoader support question: how to construct a value in CSS from PHP

On Wed, Jul 3, 2013 at 3:27 PM, Thomas Gries wrote: > I found the solution ( $wgExtensionAssetsPath ) Why do you need this? You shouldn't need this. Paths relative to the CSS file should be remapped automatically and should Just Work. Roan ___ Wikitech

Re: [Wikitech-l] Australia (was Re: conferences, Hacker School, Code for America)

On Sat, Jul 6, 2013 at 7:30 AM, Quim Gil wrote: > I also think that linux.conf.au could be a good chance to spread our word in > Australia. You are encouraged to apply. > I went to (and presented at) linux.conf.au in 2012, and I had an awesome time. The quality of the talks and the number of high-

Re: [Wikitech-l] PHPUnit tests fail from Jenkins but work fine locally

On Fri, Jun 28, 2013 at 10:50 AM, Arthur Richards wrote: > Mobile web is trying to merge https://gerrit.wikimedia.org/r/#/c/69585/ but > PHPUnit tests are failing when Jenkins executes them. > > What's weird is that we've executed PHPUnit tests on our various local > machines - with no failures. W

Re: [Wikitech-l] Brian Wolff's summer gig, with Wikimedia!

On Mon, Jun 3, 2013 at 12:50 PM, Rob Lanphier wrote: > Hi everyone, > > Many of you already know Brian Wolff, who has been a steady > contributor to MediaWiki in the the past several years (User:Bawolff), > having gotten a start during Google Summer of Code 2010[1]. > > Brian is back for another s

[Wikitech-l] VisualEditor on wikitech.wikimedia.org

Because Faidon idly suggested that we should install VisualEditor on wikitech as a way of dogfooding, I went ahead and did it. https://wikitech.wikimedia.org/w/index.php?title=PowerDNS&diff=68284&oldid=14633 is the first VE edit :) Inside baseball note: this uses the Tampa Parsoid cluster, not the

Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias

On Mon, Apr 29, 2013 at 4:36 AM, David Gerard wrote: > Cool, thank you :-) Every time I've used it lately, it's messing with > the tags. Just now I literally moved a comma and it decided > messing with the tags would be just the thing to do ... > Yeah, sorry about that :( . There was a bug where

Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias

On Fri, Apr 26, 2013 at 3:05 PM, Lukas Benedix wrote: > I'm not a non-tech-user, but I don't like using bugzilla. > here is the new bug: https://bugzilla.wikimedia.org/47755 > Per my earlier post, I've closed that bug as INVALID (as feedback collection does actually work), with a reference to the

Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias

On Fri, Apr 26, 2013 at 11:37 AM, Claudia Müller-Birn wrote: > Hi James, > > Thanks for clarifying. > > I am just wondering why the two feedback mechanisms send to different targets > which I personally find a bit confusing. What has been the decision behind it? > They are different feedback mech

Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias

On Fri, Apr 26, 2013 at 9:42 AM, James Forrester wrote: > The "report a problem" link sends the report privately to a Parsoid > server. From your video, it appears that the API call to do so failed > - could you file a Bugzilla item with more details so we can > investigate? > It's sending informa

Re: [Wikitech-l] Temporarily disabling l10n update

On Wed, Apr 10, 2013 at 1:14 PM, Max Semenik wrote: > Does that mean that scap is also prohibited? > Scap runs the same script to clear blobs. We can sabotage that script, but that will cause all i18n updates to JS to propagate more slowly, regardless of whether they came from a code deployment or

[Wikitech-l] New git-review version revives year-old bug

About a year ago, we were struggling with a git-review bug that caused lots of bogus warnings to appear. When running "git review", you'd get a warning saying you're about to submit multiple commits, followed by a list of lots of other people's commits that have already been merged. I fixed this in

Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia

On Wed, Dec 12, 2012 at 12:14 PM, Matthew Flaschen wrote: > I would definitely be willing to serve as a guinea pig, working to > integrate ProveIt (http://en.wikipedia.org/wiki/User:ProveIt_GT). > Awesome! Roan ___ Wikitech-l mailing list Wikitech-l@li

Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia

On Wed, Dec 12, 2012 at 11:32 AM, Daniel Barrett wrote: > Will the method for hooking into VE be the same as for WikiEditor? Or will > extension > developers need to support both editors in two different ways? > It won't be the same as for WikiEditors, because the two are very fundamentally diff

Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia

On Tue, Dec 11, 2012 at 10:55 PM, Lee Worden wrote: > Very exciting - congratulations! > > I know these are early days for the VisualEditor, but is there a plan for > extension developers to be able to hook in to provide editing for the things > their extensions support? Yes, absolutely! We've bee

Re: [Wikitech-l] "Nobody" & "Wikidata bugs": notify when you start working on a bug

On Thu, Dec 6, 2012 at 10:07 AM, Quim Gil wrote: > Hi, thanks to the metrics reports now we know that the top bug fixers in > November were Nobody (228) and Wikidata bugs (83)... followed by Michael > Dale (28), Roan Kattouw (23), etc. > > http://www.mediawiki.org/wiki/Co

Re: [Wikitech-l] problems merging changes from master -> remote branch

On Fri, Nov 30, 2012 at 2:12 PM, Arthur Richards wrote: > ! [remote rejected] HEAD -> refs/publish/esisupport/bug/41286 (change > 32896 closed) It looks like https://gerrit.wikimedia.org/r/#/c/32896/ is a commit that you submitted to esisupport at some point, then abandoned, and are now trying to

Re: [Wikitech-l] WMF's webpage

On Wed, Nov 28, 2012 at 4:21 PM, Chad wrote: > On Wed, Nov 28, 2012 at 6:48 PM, Luke Welling > wrote: > > Is there a reason not to use the Yahoo championed approach of embedding a > > version number in all static file names so you can set a very long cache > > expires time and just add new versi

Re: [Wikitech-l] Creating custom skin based on Vector in MediaWiki 1.20

On Tue, Nov 13, 2012 at 12:33 AM, Dmitriy Sintsov wrote: > However, 'skin.vector' module includes both styles and scripts. And > setupSkinUserCss() adds styles only. So 'dependencies' did not help, vector > styles are loaded later, anyway. What can I do with that? > Unfortunately, addModuleStyles(

Re: [Wikitech-l] jQuery 1.9 will remove $.browser (deprecated since jQuery 1.3 - January 2009)

On Thu, Nov 8, 2012 at 5:17 PM, Tim Starling wrote: > I can understand the rationale behind removing jQuery.browser: > apparently most developers are too stupid to be trusted with it. Maybe > the idea is to use per-project reimplementation of jQuery.browser as > an intelligence test. The trouble i

Re: [Wikitech-l] Off-and-on CSS and rendering issues, Bits related?

On Fri, Nov 16, 2012 at 12:34 PM, Andre Klapper wrote: > * Missing Gadgets tab (also with Vector skin): > > https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Missing_Gadgets_Tab This was fixed last night. It has nothing to do with bits, it was caused by memcached corruption.

Re: [Wikitech-l] Content handler feature merge (Wikidata branch) scheduled early next week

On Sep 25, 2012 12:15 PM, "IAlex" wrote: > Would it be possible to have the whole changes as an changeset on Gerrit? > This would make review and comments much easier than having to do this on this list. > Yes and no. The person that merges the branch can create a merge commit and submit that for

Re: [Wikitech-l] Code review meeting notes

On Thu, Sep 20, 2012 at 2:08 PM, Mark Holmquist wrote: > Hm. Will this be file-level whitelisting (i.e., "this file changed from the > master branch in this patchset, so we'll show the changes") or is it > line-level? If the latter, how? Because I'm not sure it's trivial > I believe it's file-

Re: [Wikitech-l] Gerrit server issues

On Wed, Sep 12, 2012 at 3:51 PM, Platonides wrote: > Doesn't formey have core.logAllRefUpdates set to true? > Wouldn't that have prevented git gc from removing commits referenced in > the reflog? (at least until two weeks without the references passed, it > should probably have been run with --no-

Re: [Wikitech-l] Gerrit server issues

On Fri, Sep 7, 2012 at 2:12 PM, Chad wrote: > All of these have been fixed other than Nonlinear (more heavily > broken). TranslationNotifications' master is intact, but some of > the changes are still in a bad state and I need to finish cleaning > it up. > TranslationNotifications has now been fix

Re: [Wikitech-l] scaled media (thumbs) as *temporary* files, not stored forever

On Wed, Sep 5, 2012 at 12:35 PM, Asher Feldman wrote: > Browser scaling is also at least worth > experimenting with. Instances where browser scaling would be bad are > likely instances where the image is already subpar if viewed on a high-dpi > / retina display. Other instances where browser scal

Re: [Wikitech-l] scaled media (thumbs) as *temporary* files, not stored forever

On Sun, Sep 2, 2012 at 5:59 PM, Tim Starling wrote: > The other reason for the existence of the backend thumbnail store is > to transport images from the thumbnail scalers to the 404 handler. For > that purpose, the image only needs to exist in the backend for a few > seconds. It could be replaced

Re: [Wikitech-l] scaled media (thumbs) as *temporary* files, not stored forever

On Fri, Aug 31, 2012 at 1:22 PM, Jeremy Baron wrote: > On Fri, Aug 31, 2012 at 1:48 PM, Derric Atzrott > wrote: >> Perhaps generate the standard thumbnail sizes at upload time > > I believe the status quo is no thumbs (of any size) are generated at > upload time. They are all just done on demand.

Re: [Wikitech-l] Work offer inside

On Fri, Aug 31, 2012 at 1:07 PM, Derric Atzrott wrote: > Forgive me for not knowing, but what is OIT? A quick Google gives me Oregon > Institute of Technology, but I that is it given the context. > Wikimedia's Office IT department. Roan ___ Wikitech-l

Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins

On Thu, Aug 30, 2012 at 1:11 AM, Oren Bochman wrote: > I've tried to do this for translate ext last week - so here are a couple of > questions: > 1. is successfully runnig the test a requirement to successfully score on > gerrit? (i.e. how is gerrit integrated) Jenkins sets a Verified +1 or -1 on

Re: [Wikitech-l] Disabling direct pushing to master for extensions

On Wed, Aug 29, 2012 at 1:55 PM, Jeroen De Dauw wrote: > Forgive my git ignorance here, but will merging this "merge commit" result > into all original commits being in the version history, or will it just > show as one huge change? In case of the later, I don't think this is an > acceptable appro

Re: [Wikitech-l] Disabling direct pushing to master for extensions

On Wed, Aug 29, 2012 at 12:58 PM, Chad wrote: > Before I make the change though, I > wanted to ask about it publicly to make sure there's no major blockers > to me doing so. > As long as people that were previously able to push are still able to +2 (which is probably true, unless the ACLs are real

Re: [Wikitech-l] Appreciation thread

On Thu, Aug 23, 2012 at 7:50 PM, Erik Moeller wrote: > Completely random appreciation for whoever implemented the "undo" > feature in MediaWiki, one of its many hidden gems. :-) > Looks like the main contributors to this were Andrew Garrett in July 2006 [1] and December 2006 [2], Aaron Schulz in M

Re: [Wikitech-l] Appreciation thread

On Thu, Aug 23, 2012 at 2:30 AM, Niklas Laxström wrote: > * Sumana for this idea. +1 Also: * Inez for writing code I intended to write, exactly the way I intended to write it, while I was busy with something else yesterday * Timo (Krinkle) for announcing he's back from vacation via the gerrit-wm

Re: [Wikitech-l] Can we make an acceptable behavior policy? (was: Re: Mailman archives broken?)

On Fri, Aug 17, 2012 at 11:20 AM, Ryan Lane wrote: > 1. Adjust our procedures for thread deletion so that this situation > doesn't occur again. > 2. Fix the links, if the effort level isn't insane. > I said this on IRC in some form, but I'll repeat it here on the (hopefully permalinked ;) ) record

Re: [Wikitech-l] Status::getXML usage?

On Wed, Aug 15, 2012 at 10:04 AM, Tyler Romeo wrote: > Hey, > > So a quick grep search cannot tell me where the method Status::getXML is > used. It doesn't seem to exist anywhere in the core. Maybe some extensions > use it? I'm asking primarily because if it's not used then it should > probably be

Re: [Wikitech-l] Criteria for "serious alternative"

On Fri, Jul 27, 2012 at 3:29 PM, Chad wrote: > On Fri, Jul 27, 2012 at 6:27 PM, Terry Chay wrote: >> Gerrit has templating support so basic CSS changes are not difficult >> and require no pushes to upstream Gerrit. Delta one strange thing in that >> the load order of the cascade in Gerr

Re: [Wikitech-l] Criteria for "serious alternative"

On Jul 27, 2012 1:11 AM, "Antoine Musso" > We have disallowed branch creation and merging for now, that can > definitely be opened up. Chad recently opened the sandbox reference and > we have a few of them: > > remotes/gerrit/sandbox/apramana/gsoc > remotes/gerrit/sandbox/demon/foo-bar > remo

Re: [Wikitech-l] Criteria for "serious alternative"

On Jul 27, 2012 7:17 AM, "Faidon Liambotis" wrote: > I think GitLab looks promising but I'm unable to judge it against all of > our requirements just from the online demo and without spending some > amount of time on it. I just put some pros and cons as I see them to the > Wiki page and hope it ca

Re: [Wikitech-l] Criteria for "serious alternative"

On Jul 27, 2012 6:58 AM, "Chad" wrote: > 1) Personal dashboards will now be private -- the proper way to query > someone's work is the "owner:" query in the search box. As MZ and I found out last night, this is not the case. An owner: search only finds changes that person *started*, so it doesn't

Re: [Wikitech-l] Serious alternatives to Gerrit

On Wed, Jul 25, 2012 at 3:31 PM, Chad wrote: > I haven't actually tried doing custom Javascript yet, but it should be > completely doable via the GerritSite.html header that you can > customize (in fact, I've got some other non-JS customizations I > want to roll out there soon). I've done this, st

Re: [Wikitech-l] Serious alternatives to Gerrit

On Wed, Jul 25, 2012 at 12:39 AM, Ryan Lane wrote: > 1. It would be worrisome from a security point of view to host the > operations repos on Github. I think it's very likely that those repos > would stay in Gerrit if the devs decided to move to Github. This would > mean that we'd have split workf

Re: [Wikitech-l] Serious alternatives to Gerrit

On Tue, Jul 24, 2012 at 10:46 PM, Alolita Sharma wrote: > Cool, Priestley is awesome. If he comes to visit we should prevent him from > leaving :) > > +1. We should definitely think about adopting Phabricator as a project if > we're going to invest in its core developer. > I think this should be r

Re: [Wikitech-l] How to tell MW that I want to use the HTTPS version?

On Fri, Jul 20, 2012 at 6:10 AM, Chad wrote: > It's because the URLs are based on who was using the wiki at the > time and caused the e-mail to be generated. If I'm using HTTP, > you'll get an HTTP e-mail. > This is no longer true, I fixed this about a year ago. E-mail notifications now use the ca

Re: [Wikitech-l] Serious alternatives to Gerrit

On Thu, Jul 19, 2012 at 11:52 PM, Antoine Musso wrote: > How are the blind spot? You can diff each patchset with its previous one > (though a rebase kind of screw it up). > > Whenever I send a new patchset, I try to add a cover message introducing > what was done in the new patchset so people rece

Re: [Wikitech-l] Serious alternatives to Gerrit

On Thu, Jul 19, 2012 at 6:29 PM, Roan Kattouw wrote: > gitlab is an open source clone of GitHub (which means you can > self-host it) Forgot to say: thanks to Timo for bringing gitlab to my attention. Roan ___ Wikitech-l mailing list Wiki

Re: [Wikitech-l] Serious alternatives to Gerrit

On Thu, Jul 19, 2012 at 11:58 AM, Erik Moeller wrote: > What are people's experiences with Gitorious? Does it seem > sufficiently hackable to perhaps meet our needs, or does it have too > many architectural flaws to be worthwhile? > > Here are a few things I've been able to find out from poking at

Re: [Wikitech-l] Serious alternatives to Gerrit

On Thu, Jul 19, 2012 at 4:40 PM, Platonides wrote: > It should be possible to only bisect on the left-branch of merges. If > git doesn't have such feature, it should be added. In fact, it's very > likely that it's what it uses when start and end are in the same line, > but as the merged commits ca

Re: [Wikitech-l] Serious alternatives to Gerrit

On Wed, Jul 18, 2012 at 9:30 PM, Subramanya Sastry wrote: > (b) Commit amends hide evolution of an idea and the tradeoffs and > considerations that went into development of something -- the reviews are > all separate from git commit history. All that is seen is the final > amended commit -- the

Re: [Wikitech-l] Linux.conf.au CfP deadline about to close

On Thu, Jul 5, 2012 at 6:17 AM, Sumana Harihareswara wrote: > http://linux.conf.au/cfp > > Closes in about 24 hours. This was extended by 2 weeks https://twitter.com/linuxconfau/status/221225678127894528 Roan ___ Wikitech-l mailing list Wikitech-l@list

Re: [Wikitech-l] getting Jenkins to run basic automated tests on commits to extensions

On Thu, Jul 5, 2012 at 2:11 PM, Chad wrote: > Yes, but we can't even get people to type `php -l` before pushing, > which is why having Jenkins do this for us is crucial. > Yes, I don't disagree that jshint should be run by Jenkins. AIUI Timo's work to make jshint work on the command line is prep w

Re: [Wikitech-l] getting Jenkins to run basic automated tests on commits to extensions

On Thu, Jul 5, 2012 at 1:37 PM, Jon Robson wrote: > If we do this running jslint on JavaScript would also be great. I have a > git hook I stole from Yuvi that I'm currently using. Would be great to have > Jenkins do this check for me as well... I believe Timo is already working on getting jshint w

Re: [Wikitech-l] git commit history

On Sun, Jul 1, 2012 at 5:30 PM, Subramanya Sastry wrote: > > One thing I just noticed when looking at the git history via gitk (on > Ubuntu) is that the history looks totally spaghetti and it is hard to make > sense of the history. This seems to have happened since the switch to git > and post-co

Re: [Wikitech-l] Barkeep code review tool

On Sat, Jun 30, 2012 at 11:53 PM, Antoine Musso wrote: > Roan Kattouw wrote: >> Yes, ops essentially uses a post-commit workflow right now, and that >> makes sense for them. > > ops also uses pre-commit review for non-ops people :-] > Yeah, that's right. What I me

Re: [Wikitech-l] Barkeep code review tool

On Sat, Jun 30, 2012 at 4:23 PM, Faidon Liambotis wrote: > Well, in the ops puppet repo though, we very often +2 commits ourselves > and push them, instead of waiting for someone else to review/approve > them. You could argue that it's our workflow that it's wrong, but I just > think the needs for

Re: [Wikitech-l] Barkeep code review tool

On Fri, Jun 29, 2012 at 2:20 PM, Marcin Cieslak wrote: > As seen on IRC: > > https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools > The most prominent feature of Barkeep mentioned on this page is that it was built for a post-commit review workflow. Given that the rea

Re: [Wikitech-l] Registering JavaScript vars for only a certain resource loader module in php

On Fri, Jun 22, 2012 at 12:19 PM, Daniel Werner wrote: > I was wondering whether it is possible somehow to register a javascript var > for a certain resource loader module in php? This is a feature I've been wanting to have in ResourceLoader for a while, but I haven't gotten around to implementing

  1   2   3   4   5   6   7   8   9   >