enough to just give it everything (Grade X
instead of Grade B) per a Village Pump thread requesting it.[3]
— Krinkle
[1] https://jquery.com/browser-support/
[2]
https://www.mediawiki.org/w/index.php?title=Compatibilityoldid=1119439#Browser_support_matrix
[3]
https://github.com/wikimedia
of simplicity and compatibility.
Breaking things can be good, but I haven't seen any short or long term benefits
so far that would justify it.
— Krinkle
On 28 Jul 2014, at 23:02, John phoenixoverr...@gmail.com wrote:
I use a standard git checkout. Moving these to their own separate location
is going
Support can mean either depending on the context.
Most of this is uncontroversial, but I found it useful to think through and
sum up.
From a platform perspective to support a browser means that the user
experience is considered acceptable, tested against, and we're committed to
keeping it that
On 26 Jul 2014, at 22:32, Steven Walling steven.wall...@gmail.com wrote:
This seems really reasonable.
Are we still agreed that Grade A means anything over 1% of readership? If
so, we should reconfirm what our browser share is really like, because last
time I checked, IE6 was less than 1%
to a version that
drops support for an API after we first upgrade to a version that provides
the new API.[4]
— Krinkle
[1] http://jqueryui.com/download/ and their source repository continues
to maintain jQuery UI 1.11.x, 1.10.x and 1.9.x
[2] http://blog.jqueryui.com/2013/01/jquery-ui-1-10-0/
[3] http
to throw an exception in an older browser per se,
in case of jQuery UI it's quite simple. We can only upgrade to jQuery 1.10 when
we drop IE6 support for Grade A. And when we do, IE6 will become
javascriptless[1] and jQuery UI will no longer be relevant as problem in IE6.
— Krinkle
[1] https
have a section Trusted Browsers which is slightly different in that
it lists sessions that are of the Remember me type and also lists
authenticated devices that won't ask for two-step verification again. And the
ability to revoke any of them.
— Krinkle
[1] E.g. not expectation based on previous
use
modules=my.module.nameonly=scriptsdebug=true. Like all unversioned requests,
this is only cached for 5 to 30 minutes (depending on mediawiki configuration).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
depended on any PEAR packages.
We either shipped them (Services_JSON), provided a fallback or made the feature
optional / in an extension.
-- Krinkle
[1] Easier to instal because it requires less permissions since it uses local
directory. Easier to deploy because of this. And managed with a manifest
.
-- Krinkle
[1] Would've roughly looked like this: http://i.imgur.com/fK1NV2G.png
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8 Jun 2014, at 17:22, James Forrester jforres...@wikimedia.org wrote:
— Krinkle
On Sunday, June 8, 2014, Martijn Hoekstra martijnhoeks...@gmail.com wrote:
On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra
martijnhoeks...@gmail.com javascript:;
wrote:
Flow stores the comments
://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Logdiff=113204oldid=113199
I documented the incident just now:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20140517-bits
— Krinkle
On 1 Jun 2014, at 17:22, Helder . helder.w...@gmail.com wrote:
On Sat, May 31, 2014 at 1
://commons.wikimedia.org/wiki/Commons:Commons_API
https://tools.wmflabs.org/magnus-toolserver/commonsapi.php
https://tools.wmflabs.org/magnus-toolserver/commonsapi.php?image=Van%20Gogh%20-%20Starry%20Night%20-%20Google%20Art%20Project.jpgmeta
— Krinkle
On 3 Jun 2014, at 14:11, Derk-Jan Hartman
these legacy features are
aware of this so they may patch the code accordingly (using the upgrade guide[4]
and my earlier announcement [5]). When MediaWiki 1.24 is released, we will
switch off jQuery Migrate for Wikimedia wikis.
— Krinkle
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44740
. anywhere HTML is displayed, whenever
it is used inside an message)
- Defined by msg key skinnname-{skin}
— Krinkle
On 25 May 2014, at 18:02, Bartosz Dziewoński matma@gmail.com wrote:
On Sun, 25 May 2014 00:11:28 +0200, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
However
On 23 May 2014, at 03:11, Gergo Tisza gti...@wikimedia.org wrote:
On Wed, May 7, 2014 at 9:29 AM, Krinkle krinklem...@gmail.com wrote:
A rough timeline:
* 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging
starts. This
will run for 4 weeks (until June 9).
* 19 May 2014
there are no deprecation notices being fired when using
them.
In addition, (to see if maybe you missed any) you could perform a few grep/ack
searches if you want to be extra sure (manually, so that you can mentally
exclude false positives).
— Krinkle
On 7 May 2014, at 19:27, Siebrand Mazeland siebr
().stack } );
};
}
I might set up some tracking for it at Wikimedia as well, but I'm not sure if
that'll work properly.
— Krinkle
[1]
https://github.com/wikimedia/mediawiki-core/blob/wmf/1.24wmf4/resources/src/mediawiki/mediawiki.js#L567
[2]
https://github.com/wikimedia/mediawiki-core/blob/wmf
/wiki/Wikipedia_ discusión:X
— Krinkle
On 11 May 2014, at 16:15, Matthew Flaschen mflasc...@wikimedia.org wrote:
On 05/04/2014 05:08 AM, Max Semenik wrote:
This proposal makes no sense: all these namespaces _are_ dependent on wiki
language, so even if you force Project down the throats of non
features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-
final-released/
[2] http://jquery.com/upgrade-guide/1.9/
[3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/
[4] http
The module was split out of mediawiki.util, nothing new, no need for any
special treatment here.
It should've been given the same target definition as mediawiki.util.
— Krinkle
On 27 Apr 2014, at 19:37, Jon Robson jdlrob...@gmail.com wrote:
Looks like jquery.accessKeyLabel now seems
-method-addButton
If you need a callback, I'd recommend you re-enable the WikiEditor toolbar
instead of the legacy classic toolbar, and use its API to add a button instead.
The WikiEditor API provides a wide range of features, including a callback.
— Krinkle
a dependency, but because
you don't want to trigger a load of this module (you merely want to hook into
it if the toolbar is there, you don't want to load another toolbar which is
what adding a dependency would do).
— Krinkle
On 23 Apr 2014, at 14:21, Justin Folvarcik jfolvar...@gmail.com wrote:
Am I
• https://github.com/jshint/jshint/releases
• http://jshint.com/blog/new-in-jshint-oct-2013/
• http://jshint.com/blog/new-in-jshint-dec-2013/
— Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
See also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62633
-- Krinkle
On 10 Mar 2014, at 22:04, Jon Robson jdlrob...@gmail.com wrote:
I just wondered if anyone doing MediaWiki development had any
experience in catching CSS regressions?
We have had a few issues recently in mobile land
with the MediaWiki core release they are
associated with and you can move on in the master branch to react to
changes in latest master.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
due to the slowness in debug=true, it simply didn’t provide
anything I already had.
— Krinkle
[1] http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org
to false (it is a boolean property after all) it would
look at e.returnValue.
* They are now using (jQuery v1.11.0-pre, latest upstream master):
e.defaultPrevented ( … )
e.defaultPrevented === undefined e.returnValue === false
-- Krinkle
supports this already (by using the header itself as a
custom toggle). However, depending on how your custom toggle is styled, there
should imho be a separate toggle or other kind of user interface component to
indicate collapsibility.
-- Krinkle
in Subllime the easy way using Package Control[6],
or check out the plugin page[2] for manual installation.
-- Krinkle
[1] http://www.sublimetext.com/
[2] https://github.com/spadgos/sublime-jsdocs
[3] Type /** followed by tab to insert the template, then tab trough
placeholders to fill them in
[4
, deprecation notices or other messages and try to address
them soon (or report it to the maintainers of the gadgets triggering them).
-- Krinkle
[1]
https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.log-method-deprecate
___
Wikitech-l mailing list
the covering detection. It's more like a filter to to keep
everything else out. Great :)
-- Krinkle
On 2013-10-18, at 18:38, Erik Bernhardson ebernhard...@wikimedia.org wrote:
different definitions of test ;-) code touched seems like a much less
useful metric than code specifically tested, but i
Hey all,
Last Friday, the mw.Title rewrite landed in master. Here's a brief summary of
the changes.
TL:DR;
* New static constructor mw.Title.newFromText (returns mw.Title or null).
* New internal title parser (uses wgLegalTitleChars and mirrors most of
Title::secureAndSplit).
* Bugs like
On Sep 19, 2013, at 11:19 PM, C. Scott Ananian canan...@wikimedia.org wrote:
@dan: the particular less isn't very powerful issues I'm concerned about
are the ones solved by compass. As is well-known, there is no equivalent
to compass for less, and is not likely every to be, since less can not
part of a request that also includes other
stylesheets and scripts.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.
-- Krinkle
[1] https://www.mediawiki.org/wiki/Extension:Less
[2] https://github.com/wikimedia/mediawiki-extensions-Less
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
?
--
Yuvi Panda T
http://yuvi.in/blog
https://www.mediawiki.org/wiki/Extension:InlineCategorizer
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
() to load it
from the top. That should fix the flash of unstyled content.
-- Krinkle
[1] http://www.mediawiki.org/wiki/Manual:$wgResourceModules
[2] http://www.mediawiki.org/wiki/ResourceLoader/Features
___
Wikitech-l mailing list
Wikitech-l
On May 10, 2013, at 3:22 AM, Tim Starling tstarl...@wikimedia.org wrote:
On 09/05/13 10:26, Krinkle wrote:
I'm obviously biased, but I think the same goes for require_once
(and include, require etc.). Right now this is causing quite a few
warnings in our php-checkstyle report.
include
On May 7, 2013, at 8:56 PM, Bartosz Dziewoński matma@gmail.com wrote:
On Tue, 07 May 2013 20:51:07 +0200, Krinkle krinklem...@gmail.com wrote:
It is the duty of repository co-owners to make wise decisions beyond
just code quality. About what changes go in what release (if at all
to disable the rule, thus not catching the
ones we do use.
See pending change in gerrit that does a quick pass of (most of) these
in mediawiki/core:
https://gerrit.wikimedia.org/r/62753
-- Krinkle
[1] Or whatever the reason is the author originally wrote it like
this. Perhaps PHP was different back
On May 7, 2013, at 5:52 PM, Brad Jorsch bjor...@wikimedia.org wrote:
On Mon, May 6, 2013 at 10:09 PM, Krinkle krinklem...@gmail.com wrote:
On May 3, 2013, at 9:33 PM, Anomie wrote:
Taking a recent example[1], please tell me how to compress the
following into 62 characters:
(in the New
On May 3, 2013, at 9:33 PM, Anomie wrote:
On Fri, May 3, 2013 at 1:02 PM, Krinkle wrote:
First of all, I think a lot of our commit subjects are poorly written,
even for a commit message. Having said that, a good commit subject is
also a good release note (that is, if the change itself
be able to determine exactly when and for how long an
extension was deployed.
-- Krinkle
PS: The public mediawiki-config.git only dates back to 24 Feb 2012. Before that
date the information was in a non-public svn repository inside the
wmf-production cluster
On May 2, 2013, at 7:41 PM, Brad Jorsch bjor...@wikimedia.org wrote:
I like the idea of not having to mess with RELEASE-NOTES-#.## merge
conflicts. But I'm not entirely sure about everything in the proposal.
On Thu, May 2, 2013 at 12:30 PM, Krinkle krinklem...@gmail.com wrote:
For more
this on for the near future. However I'm convinced we
have enough people who care and will filter the incoming stream on the
wiki page. Simply look at the git history of release notes files (I
expect at least Reedy and hexmode will naturally be drawn to this).
-- Krinkle
[1] Other reasons include
and always lowercase by
convention.
The footer being clickable is done independently.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
core)
If not on displayed in Gerrit, then from git-cli via a web tool (how does that
grep perform, is it fast enough?)
Ofcourse, changing would still go from cli (not w/ the web tool).
-- Krinkle
On 14 mrt. 2013, at 00:07, Christian Aistleitner christ...@quelltextlich.at
wrote:
Hi,
On Tue
the normal way?
I did a one-time import of the original history, replacing the empty
repository.
After that I merged 3 changes via Gerrit[1] and there have been no forced
pushes since.
-- Krinkle
[1] as indicated by the pink ref/changes labels:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki
and you'll see the same data in
your browser's console (e.g. Chrome Dev Tools).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
well that analogy flies,
-- Krinkle
[1]
https://upload.wikimedia.org/wikipedia/commons/thumb/e/eb/Baantjegracht_Dokkum_2010.jpg/160px-Baantjegracht_Dokkum_2010.jpg
[2]
https://upload.wikimedia.org/wikipedia/commons/e/eb/Baantjegracht_Dokkum_2010.jpg
it and
submit it to Gerrit. The only minor detail is closing the PR. When that
happens and who that does. The who is clear, someone with write access to the
Wikimedia GitHub account. The when, could be when it is taken to Gerrit, could
be when it lands in master.
-- Krinkle
[1] Squash because
the global script instead of from local preferences, which are rather
annoying to maintain imho.
if ( dbname == wikidatawiki || .. ) {
return;
}
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
for the QUnit job.
Happy testing,
-- Krinkle
[1] https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing
[2] PhantomJS:
http://phantomjs.org/
[3] node-phantomjs (npm wrapper with nom-install hook)
https://github.com/Obvious/phantomjs
[4] grunt-contrib-qunit
https://github.com/gruntjs/grunt-contrib
extensions after every release and provide
them as options in the extension distributor.
https://www.mediawiki.org/wiki/Special:ExtensionDistributor/LiquidThreads
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
On Feb 22, 2013, at 6:33 PM, Greg Grossmeier g...@wikimedia.org wrote:
Hello all,
Background and longer/more detailed discussion on this issue is in bug
44570:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44570
Summary:
As w
e delete old -wmfX branches there appears to be cached
to approve the merge instead of self-merging
right away.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
by simply clicking the username on any page where
it is mentioned.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
with having a directory?
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
explain) not
approve it.
And for the same reason, when that reviewer backports himself, he wouldn't
self-merge. Or rather, he wouldn't draft such a change in the first place.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
.
These 2 cases (and maybe more, such as i18n-bot) were the reasons that a few
weeks/months back we didn't make the change in Gerrit to make self-merging no
longer an option (e.g. reject merge attempts by the author of the change).
-- Krinkle
___
Wikitech
be confusing, decentralising and depending on the implementation,
it would encourage using multiple urls for the same thing. Might as well stick
with one canonical url.
Best,
-- Krinkle
[1] https://gerrit.wikimedia.org/r/39212
___
Wikitech-l mailing list
the extension
is disabled and also swap the front-end client for a no-op.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Jan 17, 2013, at 10:05 AM, Robert Vogel vo...@hallowelt.biz wrote:
@Krinkle: I've written a custom API module that returns categorized results.
I wanted to have a categorized output like in this demo:
http://jqueryui.com/autocomplete/#categories
My first approach was to override some
to this feature?
Most of this module is pretty trivial and only wraps around other features that
have elaborate hooks and toggles (such as PrefixIndex and the API).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
already use: REL1_20 etc.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
://gerrit.wikimedia.org/r/#/c/38258/:
where Bsitu did CR+1 and Alex no review on the final version but is in the
reviewer/CC list.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
from the cronjob on svn.wikimedia.org?).
-- Krinkle
[1] Perfectionist alert, this commit does more than just the necessary
tweaks: https://gerrit.wikimedia.org/r/42221/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
On Dec 27, 2012, at 7:18 PM, Juliusz Gonera jgon...@wikimedia.org wrote:
Hi,
I'm a bit confused when it comes to various options I have in gerrit and it
seems the docs are not up to date on that.
* What is the difference between Verified and Code Review? When would I put
+1 in one of
is Twitter card? and what this extension do?
https://www.google.com/search?q=twitter+cardsbtnI=1
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello,
We would like to clarify the reason we changed Jenkins to no longer run unit
tests on patch submission.
We had to defer code execution to after CR+2 for security reasons. If unit tests
were ran on submission that meant anyone with a labs account could effectively
get shell access on the
.
Now that everything is in place we can elaborate on this. Antoine and I sent
out a mai to wikitech-l just now:
http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065202.html
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
removed
from bugs when someone assigns a bug or otherwise ends up removing it for some
reason).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
details just open
the bug and read it.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
, wikibugs-l is configured as
globalwatcher.
The proposal Andre makes here sounds confusing, How is that different from the
current situation? What problem is it supposed to address?
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
scores. Submission in turn only has
to be restricted to CR+2.
But yeah, we need to either whitelist L10n-bot from this restriction or make
those commits auto-merge in a different way.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
that. That was the reason it was brought up, and the reason
it was subsequently reverted again. Nothing personal and not (directly) related
to the contents of the commit itself.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
are deployed globally and site-wide within 5 minutes.
Whereas the html isn't for another 2 weeks.
This is why client resources must always be backwards compatible.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
clarity instead of adding more options that represent a multiple of
values in other fields which then also need to be set separately (Commons
categories comes to mind, like Category:Blue objects made of recycled glass
hanging upside-down in Amsterdam, Netherlands).
-- Krinkle
should be set in the Assigned to field.
I'd recommend we also require a Milestone to be set for Highest
priority tickets.
That way it is clear to both the assigned developer and the community
what the expectations are.
-- Krinkle
___
Wikitech-l mailing
editors have their own (possibly outdated) copy of jshint (I know
SublimeLinter had an old version for a while). If you have node-jshint
installed, I'd recommend configuring the linter plugin of your editor to shell
out to your version of jshint (if it supports that).
-- Krinkle
to Gruntjs and have
migrated to Zuul (instead of Gerrit Trigger), we can easily create a catch-all
job for any repositories that don't have a dedicated job which would simply
execute grunt lint (aka the Universal Linter) that will run phplint,
jshint, csslint, puppetlint etc.
-- Krinkle
On Nov 21
Hey all,
For a while now we have .jshintrc rules in the repository and are able
to run node-jshint locally.
TL;DR: jshint is now running from Jenkins on mediawiki/core
(joining the linting sequence for php and puppet files).
I cleaned up the last old lint failures in the repo yesterday in
master branch should
support 1.21 and 1.22-alpha (if and until the extension maintainer
decides that compatibility needs to be broken and makes a
REL1_21 branch).
-- Krinkle
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=37946
___
Wikitech-l mailing
.
Extensions that aren't maintained, aren't maintained.
As a start, I created a REL1_20 branch for extensions that were bundled with
1.20.0.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
legal team of this infringing use.
Erik
Also, http://www.wi.ki/ violates the terms of the creative commons license:
https://commons.wikimedia.org/wiki/File:Wikipedia_mini_globe_handheld.jpg
https://creativecommons.org/licenses/by-sa/3.0/deed.en
-- Krinkle
,cyrillic,latin-ext
More about protocol-relative:
http://paulirish.com/2010/the-protocol-relative-url/
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
working outside MediaWiki and need it is good enough for you,
you'd copy and paste those dozen or so lines. Or (after jQuery 1.9 is released)
simply load the jquery-compat version on your web page.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
* https://www.mediawiki.org/wiki/Git/Workflow
* https://www.mediawiki.org/wiki/Git/Tips
* https://www.mediawiki.org/wiki/Gerrit
* https://www.mediawiki.org/wiki/Gerrit/Navigation
+ https://www.mediawiki.org/wiki/Git/Gerrit
-- Krinkle
___
Wikitech-l mailing
On Nov 6, 2012, at 2:44 PM, Andre Klapper aklap...@wikimedia.org wrote:
On Tue, 2012-11-06 at 02:24 +0100, Krinkle wrote:
We have the following indications that should be used instead:
* blockers / dependencies
* status ASSIGNED
* keyword upstream
* priority low or lowest
* severity minor
) {
el.style.filter = 'alpha(opacity=50)';
} else { .. }
Or better yet, since this is supported by jQuery core for a while now, like
this:
$(el).css('opacity', 0.5);
Which will do the right thing for newer browsers and old IE respectively.
-- Krinkle
[1] http://api.jquery.com/jQuery.browser/
[2] http
that only omits RESOLVED/**.
@AndreKlapper: What do you think?
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
/buglist.cgi?resolution=---query_format=advancedproduct=MediaWikitarget_milestone=1.20.0%20releaselist_id=157827
Zarro Boogs found.
Nice :)
-- Krinkle
[1] https://toolserver.org/~krinkle/wmfBugZillaPortal/ (version 1.20 open regr.
milestone 1.20.0 open
whenever you feel like.
-- Krinkle
[1] I intend to remove them separately, not all at once. So if support for a
few is shown, I'll still remove the rest. Please reply complete (e.g. I use X
will mean I keep X, it won't mean I leave Y and Z as well
of as a minor oddity that
should be removed as a bug.
We know now that (though it might have been a bug originally) it is a major
feature that unless replaced, must not be removed.
-- Krinkle
[1] https://bugzilla.wikimedia.org/41155
___
Wikitech-l
them in core. Because
that wouldn't be an improvement over the current situation.
If we have good ground to remove them (because they're silly options that we
don't want end-users to be thinking about), then we remove them. Don't move
them from one junkyard to another.
-- Krinkle
[1] https
/ everywhere is obvious (it should have
one or two assertions to make sure the other behaviour is also tested), no need
to duplicate the entire test suite 2 or 3 times for unimportant details.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
, and following
current conventions for front-end code with mw and jQuery).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Oct 2, 2012, at 4:25 PM, Chris McMahon cmcma...@wikimedia.org wrote:
I am pleased to announce that Željko Filipin joins WMF this week as QA
Engineer.
Welcome Željko!
For the last 1.5 year, hashar and I have set up the current integration
environment. I'm also in CET (Krinkle on freenode
a good idea, never.
The solution I'd propose (and Daniel also mentioned this various times here and
elsewhere) to output checkboxes as fallback and an interface like jQuery
Chosen
as enhancement.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
201 - 300 of 486 matches
Mail list logo
