common way to categorize bot edits in analytics (unless only
covering recent data).
There is an open bug to store the bot flag in the revision table, thus making it
permanently available[2].
-- Krinkle
[1] For example on Commons, where I am a sysop, there is a bot I ran that edits
sysop
for it.
+1 :-)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
proven itself by being used over a long period of time by other extensions.
I mean, things don't have to be in core to be usable. Let it be an extension,
let it grow. Extensions can perfectly depend on other extensions, there is no
need to have it be in core, make your own decisions.
-- Krinkle
On Sep 26, 2012, at 8:01 PM, Niklas Laxström niklas.laxst...@gmail.com wrote:
On 26 September 2012 10:08, Krinkle krinklem...@gmail.com wrote:
Another problem I found in the current setup is that its a bit
counter-intuitive how to manage the directory structure for developers. I
mean, most
On Sep 23, 2012, at 8:03 PM, Mark A. Hershberger m...@everybody.org wrote:
On 09/23/2012 12:54 PM, Krinkle wrote:
Also, this bugzilla query should be empty before release as well (either by
fixing bugs,
or reviewing/merging pending commits that claim to fix stuff, or deferring
the bug
On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger m...@everybody.org wrote:
On 09/22/2012 02:50 PM, Krinkle wrote:
On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger m...@everybody.org wrote:
That commit is not included. I can merge it in or make a second RC with
1.20wmf12.
What do you
whether fixes for those issues are
already included or not? Most important is
https://gerrit.wikimedia.org/r/#/c/23900/
That commit is not included. I can merge it in or make a second RC with
1.20wmf12.
What do you think is the better way to go?
I'd say re-branch from master.
-- Krinkle
On Sep 22, 2012, at 9:31 AM, Daniel Friesen dan...@nadir-seen-fire.com wrote:
On Sat, 22 Sep 2012 00:10:11 -0700, Isarra Yos zhoris...@gmail.com wrote:
On 21/09/2012 11:46, Rob Moen wrote:
On Sep 20, 2012, at 3:48 PM, Krinkle wrote:
If they happened as a direct
consequence of a user
, the standard will include a natural fallback by
storing the 1-0 ratio image in the src attribute. Which is what we'd want on
older browsers/devices anyway.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
it should appear inside the interface where
it was performed?
Anyway, just my 2 cents :)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
are very specific and targeted at their purpose.
By replacing a single align attribute with all kinds of inline styles the
original intention of that align attribute will be lost at the cost of a lot of
bloat in the output that we don't really need anyway.
-- Krinkle
that this message is not wiki-content, it doesn't make sense to
truncate it. It simply needs to be shortened at the source. The interface
messages in question are (from ApiWatch.php):
* addedwatchtext [1]
* removedwatchtext [2]
removedwatchtext is short and to the point.
-- Krinkle
[1] https
another problem: Resizing the window. The spreading of
messages over multiple columns would have to either be re-build after resizing
the window.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
: true
});
};
/code
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Indeed, this is by design on GitHub.
These kind of rules need to be socially applied and controlled.
There is no way to prevent it mechanically through GitHub.
Common agreement between developers, prior to granting access, of course.
-- Krinkle
there is a preference is set for
gadget- + gadgetId.
It may be useful to require a server side registry, for Gadgets this wouldn't
be an issue since
all gadget Ids are known. For backwards compatibility array_keys of
wgDefaultOptions could
be registered automatically / implicitly.
-- Krinkle
accurate and
explains the full change (not just the first version of the patch, nor just the
last amendment to the patch).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Okay, sorry for being away for 30 minutes while I enjoyed dinner.
Someone[1] pointed me to this thread and suggested I chime in, so here I go.
On Aug 28, 2012, at 2:50 AM, Daniel Friesen dan...@nadir-seen-fire.com wrote:
Either way $( 'div' ) is NOT something officially supported by jQuery
that. And if in
doing so we saving revision space, that's nice.
Other examples:
* https://commons.wikimedia.org/wiki/Commons:Database_reports (and subpages)
* https://commons.wikimedia.org/wiki/Commons:Auto-protected_files (and subpages)
-- Krinkle
/show_bug.cgi?id=39158
Would be awesome if someone that is familiar with this stuff can have a
look at it :)
Cheers
This is part of the Vector extension.
Use option useeditwarning.
-- Krinkle
[1] https://www.mediawiki.org/wiki/Extension:Vector
Regarding how to calculate the line-width (for the 80-100 convention), the
way my old editor used to do it made the most sense to me: Consider a tab 1
character (because it is).
That also gives the most flexibility in indenting/outdenting blocks without
having to worry frequently about it being
.
Are JavaScript/CCS are really updated so often?
Eugene.
Can you elaborate a bit? (urls, timestamps, http headers, ..)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
:
Didn't we solve this already by being able to pass a version to
wfDeprecation() and allowing users to set $wgDeprecationReleaseLimit to
hide/show from whatever cut-off point they desire?
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
and will (at least for a long while to come) support both. Even more
because the default set up out of the box is /w/index.php/Page_name, and
the only way we can make sure existing wikis don't break is by supporting
this.
-- Krinkle
___
Wikitech-l mailing
We already have hourly snapshots of the stable master though:
https://toolserver.org/~krinkle/mwSnapshots/#!/mediawiki-core/master
(and it includes release branches, feature branches and wmf branches).
That could be expanded to keep old version (right now it only keeps the
latest one
be generated on demand.
-Chad
That's why I created mwSnapshots are a replacement for vvv's mw-nightly
(which, before it was taken down, afaik still only worked with SVN).
https://toolserver.org/~krinkle/mwSnapshots/#!/mediawiki-core/master
And it does cache :)
-- Krinkle
simple ways for improving Gerrit
The 7--+1 simple ways for improving Gerrit.
After 5 comes 6, you know ;-)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
amendment will be in the master's history (which is just as much a squash,
except that that squash is the result if re-ammending over and over again,
instead of subsequent commits being squashed afterwards).
-- Krinkle
[1] branch-review model, as in, a model where a review is about a
topic-branch
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
it.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
by default,
that could be a very useful feature. I'll leave that up to someone else more
involved to comment about.
[1] https://en.wikipedia.org/wiki/Template:Persondata
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
best to always work in a topic branch, keep master clean, and do simple
pulls from gerrit/master.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Have you looked at the example extensions?
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/examples.git;a=tree
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
, just curious. I'm not vouching for or against it.
Thank you!
-greg aka varnent
Thank you!
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
it is for. When we are planning to deploy something
that requires wikis to change something, we'd reach out through those
ambassadors who translate it into their own wiki (if needed) and do or make
sure is done, whatever needs doing.
-- Krinkle
___
Wikitech-l
if this sounds crazy, but you could do git review -d 1234
and test it that way.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
to
be checked out.
I agree with Chad, there is no problem with an actual testing branch, but if
we can avoid it with an (what could be) a better workflow with less overhead of
rebasing, dependency manipulation and double-merging etc. then..
-- Krinkle
On Fri, Jun 29, 2012 at 1:23 PM, Krinkle krinklem
awesome!
-- Krinkle
On Thu, Jun 28, 2012 at 9:37 AM, Brion Vibber br...@pobox.com wrote:
On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklem...@gmail.com wrote:
So, stripping inline styles:
* will not fix bad layouts made with tables (which are probably at least as
common as bad layouts made
reports back to Gerrit (our code
review tool)
with a comment linking to the test results and a flag PASSED or FAILED.
For example: https://gerrit.wikimedia.org/r/#/c/13037/ (jenkins-bot)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
they cause problems
* how to solve that (and how the solution is indeed better for everyone)
... then is is a matter of spreading links to that documentation and waiting
for it to be incorporated on the 700+ wikis with the many many portal pages,
and other structures that have bad layouts.
-- Krinkle
/Category:Tutorials
I could also (co-)host that or another session regarding front-end unit testing.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
the flood for support,
while keeping them in the relevant context of developers and conversations.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
suite to his repository.
Ready
to be expanded and build upon!
-- Krinkle
[1] https://github.com/santhoshtr/CLDRPluralRuleParser
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Jun 21, 2012, at 7:13 AM, Krinkle wrote:
On Jun 20, 2012, at 1:02 PM, Niklas Laxström wrote:
No, this is not about a wikitext parser. Rather something much simpler.
Have a look at [1] and you will see rules like:
n in 0..1
n is 2
n mod 10 in 3..4,9 and n mod 100 not in 10..19,70
complicated to use, but provides a lot of features.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or labsconsole, so
nevermind.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
] in labsconsole).
-- Krinkle
[1] simpel pages such as https://labsconsole.wikimedia.org/wiki/Deployment/Help
although probably under a different name.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
I couldn't get it to update (Mac OS X).
Reported in Bugzilla: https://bugzilla.wikimedia.org/37135
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
to the url,
then check the browser console again.
-- Krinkle
[1] https://www.mediawiki.org/wiki/Manual:How_to_debug
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or an assignee
available).
For myself I created a little portal to make working with our current workflow
easy (for MediaWiki core that is).
https://toolserver.org/~krinkle/wmfBugZillaPortal/
On May 22, 2012, at 4:05 AM, Yuvi Panda wrote:
Also, Tracking bugs let us make comments about the release
s = document.createElement('script'); /* ... */ }())}
You get the idea..
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wouldn't be needed (you'd click a few buttons and have it). Take a look at a
GitHub project issue tracker. All it has is titles, assignee, milestone,
open/close and labels. And all can be queried from the overview with a single
click.
-- Krinkle
[1] I know that many of these can be disabled
no such bug or
limitation, and in MediaWiki it will work just fine.
Not sure how that link is relevant..
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On May 14, 2012, at 5:04 AM, K. Peachey wrote:
On Mon, May 14, 2012 at 12:55 PM, Krinkle krinklem...@gmail.com wrote:
I'm convinced all other fields can be done without and removing them will
improve the workflow of the developers and the Bugmeister. Including, but not
limited to:
- Platform
On May 10, 2012, at 8:32 AM, Thomas Gries wrote:
Am 10.05.2012 02:57, schrieb Krinkle:
The MWNightly tool has been down for a while (since February, around
migration to Git), so I took the liberty to write a new tool for this.
https://toolserver.org/~krinkle/mwSnapshots/
Updates hourly
the boxes underneath
next to the first two on the first row.
This example is for example about a table-code layout vs. row containers with
floating elements.
-- Krinkle
[1] Note that at the time (maybe still today) those [expand]/[collapse] buttons
from those Wikipedia templates are shown regardless
Some of the ops that fullfill shell requests paste diffs into BugZilla comments,
which is awesome.
Hereby friendly request to those (and others!) to, from now on, paste links to
gerrit change sets (or gitweb commits) - for easy reference :)
-- Krinkle
On May 10, 2012, at 1:55 AM, Patrick Reilly
The MWNightly tool has been down for a while (since February, around migration
to Git), so I took the liberty to write a new tool for this.
https://toolserver.org/~krinkle/mwSnapshots/
Updates hourly, even.
With Git making packages of a repository is a lot easier, but for those without
On May 10, 2012, at 4:04 AM, Liangent wrote:
On Thu, May 10, 2012 at 8:45 AM, K. Peachey p858sn...@gmail.com wrote:
On Thu, May 10, 2012 at 10:41 AM, Krinkle krinklem...@gmail.com wrote:
Some of the ops that fullfill shell requests paste diffs into BugZilla
comments,
which is awesome
. That way things won't break if a version or
milestone is renamed and new ones are automatically added.
-- Krinkle
[1]
https://github.com/Krinkle/ts-krinkle-wmfBugZillaPortal/blob/c5611c966112d1eb8ff63a5651c7729161cd265a/index.php#L40
[2]
https://github.com/Krinkle/ts-krinkle-wmfBugZillaPortal/blob
Hey all,
Now that we're on a more regular deployment schedule, staying on top of the
blocking bugs and deviding lists into smaller, more managable chunks, is more
and more important.
For that reason I put together a quick tool:
https://toolserver.org/~krinkle/wmfBugZillaPortal/
It is already
On May 3, 2012, at 5:28 AM, Krinkle wrote:
Hey all,
Now that we're on a more regular deployment schedule, staying on top of the
blocking bugs and deviding lists into smaller, more managable chunks, is more
and more important.
For that reason I put together a quick tool:
https
On Apr 26, 2012, at 2:25 AM, Ryan Kaldari wrote:
Krinkle and I went back and forth on this one last year. Apparently, it's a
bit of a bootstrapping problem since all of our comments are currently
written the wrong way (due to an old bug in doxygen that has since been
fixed), and thus our
://gerrit.wikimedia.org/r/#q,8d6b19d8c2ed041443b9433298aa08a187ad1d83,n,z
*
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki%2Fcore.git;a=commit;h=8d6b19d8c2ed041443b9433298aa08a187ad1d83
- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
to centralize the concept for
further collaboration and feedback. Discussion sometimes continues on
wikitech-l, and sometimes on the wiki talk page of the RFC.
-- Krinkle
[1] https://www.mediawiki.org/wiki/RFC
___
Wikitech-l mailing list
Wikitech-l
, I'd say it's better two tables
(say, 'group' and 'item', where item.it_group refers to group.gr_id). So that
you don't have to repeat all information about the group in each item-row, and
if the group has to change, no need to change all item-rows.
-- Krinkle
, and MediaWiki
itself has the module definition of it that contians what it needs and from
where.
This also makes the load module effecient because it is minified (whereas
loading main.css directly is just a raw file).
-- Krinkle
___
Wikitech-l mailing list
On Wed, Apr 18, 2012 at 12:16 AM, Roan Kattouw roan.katt...@gmail.com
wrote:
On Tue, Apr 17, 2012 at 5:37 PM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
On Tue, Apr 17, 2012 at 10:51 PM, Krinkle krinklem...@gmail.com wrote:
On Apr 17, 2012, at 9:05 AM, Thomas Gries wrote:
My
Bug dupe of https://bugzilla.wikimedia.org/show_bug.cgi?id=35875
Fixed, awaiting review / deployment.
-- Krinkle
On Sat, Apr 14, 2012 at 8:15 AM, Thomas Gries m...@tgries.de wrote:
Has someone recently changed something with the source lang=php
extension, style ?
Layout is broken
filed
on top of MediaWiki core master instead of the latest
release so that if you need any additional hooks in MediaWiki core
(which likely will be the case on several occasions), you (or someone
else) can propose them and after they're reviewed/merged into core you
can use them right away.
-- Krinkle
on is that of AIR (uses WebKit). With AIR it still has
most desktop application possibilities such as caching files locally,
updating the application periodically, storing preferences, accessing
the file system, details I/O and up/download uploading/progress
meters etc.
-- Krinkle
[1
for themselves?
-- Krinkle
On Mar 29, 2012, at 11:23 PM, Krinkle wrote:
+1 for There is a problem with this patchset
(without , please improve).
I think that keeps it more neutral without saying anything the user doesn't
intend to say. It also keeps free ambiguity in the intention
On Mar 30, 2012, at 3:07 PM, Chad wrote:
On Fri, Mar 30, 2012 at 8:49 AM, Krinkle krinklem...@gmail.com wrote:
Can we just set it to an empty string and let the numbers and hand-written
comment speak for themselves?
I think this will be more confusing. You need some text for
the radio
On Mar 30, 2012, at 10:14 AM, Amir E. Aharoni wrote:
Hi,
I made a little localization fix to the jQuery.ui datepicker, which is
used by the Upload Wizard. I submitted it upstream through GitHub and
it was merged there.
Krinkle says that jQuery is supposed to be only modified upstream
+1 for There is a problem with this patchset
(without , please improve).
I think that keeps it more neutral without saying anything the user doesn't
intend to say. It also keeps free ambiguity in the intention (to be
disambiguated
in a comment) between 'wontfix' and 'fixme'.
-- Krinkle
On Mar
is visible.
In which case there is no advantage to using an alias over simply using
[[Special:EmailUser]], which is effectively also an alias for the first mail.
-- Krinkle
On Mar 29, 2012, at 9:41 PM, Petr Bena wrote:
Hi,
Lot of volunteers are using email to communicate when they discuss
MediaWiki inherently does not support that either), so a plain for-in loop
over an object (excluding array objects) is perfectly fine according to our
conventions.
See also http://stackoverflow.com/a/1198447/319266
but so much for the good (and bad, evil) parts of javascript :D
-- Krinkle
offtopic
On Mon, Mar 19, 2012 at 2:23 PM, Krinkle krinklem...@gmail.com wrote:
On Mon, Mar 19, 2012 at 9:35 AM, Daniel Friesen li...@nadir-seen-fire.com
wrote:
On Mon, 19 Mar 2012 00:40:54 -0700, Dmitriy Sintsov ques...@rambler.ru
wrote:
var jqgmap = [];
for ( var mapIndex in jqgmap
ontopic :)
On Mon, Mar 19, 2012 at 3:03 PM, Dmitriy Sintsov ques...@rambler.ru wrote:
On 19.03.2012 17:23, Krinkle wrote:
On Mon, Mar 19, 2012 at 9:35 AM, Daniel Friesen
li...@nadir-seen-fire.com**wrote:
On Mon, 19 Mar 2012 00:40:54 -0700, Dmitriy Sintsovques...@rambler.ru
wrote:
var
/Continuous_integration/Workflow
so feel free to edit it as you would any other wiki page.
-- Krinkle
[1]
https://www.mediawiki.org/wiki/Talk:Continuous_integration#Proposal_for_continuous_integration_.28post-Git_migration.29_13216
___
Wikitech-l mailing list
Wikitech-l
know bots do look through
Not to mention the public archives of lists.wikimedia.org :-)
--Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
?
-- Krinkle
[1] The difference between a confirmed bug having an assignee and status
ASSIGNED, is that ASSIGNED means someone has it on his agenda to actively
work on. Whereas the assignee in general is just whoever is currently
watching over it. ASSIGNED and IN_PROGRESS are basically there same
secure.wikimedia.org and are fine doing so as long as the other case is
protocol-relative.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
/Conversion#Unscheduled_items
[2]
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=22596hide_resolved=1
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
focussing on the new system [1], start
elaborating on what the needs are, use cases, requirements and come up with
a design specification and implementation.
Related events: bug 34508[2], bug 30245[3].
-- Krinkle
[1]
https://www.mediawiki.org/wiki/Requests_for_comment
that this is required for ResourceLoader
since
1.17 and becomes extra important with the load queue improvements coming in
1.19. Since faster loading makes race conditions in dependency resolving
more
likely to fail, that is - if dependencies are not declared for all or only
few of gadgets.
Thanks,
- Krinkle
[1
to blacklist this but for now..)
Thanks :)
- Krinkle
[1] http://integration.mediawiki.org/testswarm/
[2] http://www.mediawiki.org/wiki/Compatibility#Browser
[3] http://webaim.org/blog/user-agent-string-history/
[4] http://integration.mediawiki.org/testswarm/user/mediawiki/ (if you
don't see a red
)
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
to the API from
any page,
directing.
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
(unconsciously?)
switched
from just JS by users, to modules (js/css) by origin = site (which also
matches user JS).
I'm not sure if that's how it happened, but that what I remember and it was
kept.
Krinkle
___
Wikitech-l mailing list
Wikitech-l
to see
them all.
-Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
remember having a similar issue when I first installed phpunit on my Mac.
Although I don't know the exact command, I remember having to update some
central installer proces by PEAR (channel ?) to the latest version, which
still had an old
version in it's (local?) database.
Krinkle
On Wed, Jan 4, 2012 at 7:42 AM, Daniel Friesen li...@nadir-seen-fire.comwrote:
On Tue, 03 Jan 2012 06:14:36 -0800, Antoine Musso hashar+...@free.fr
wrote:
Le Fri, 30 Dec 2011 18:31:30 +0100, Krinkle krinklem...@gmail.com a
écrit:
Since virtually any value other than null and undefined
On Dec 7, 2011, at 10:33 AM, Dmitriy Sintsov wrote:
* Trevor Parscal tpars...@wikimedia.org [Tue, 6 Dec 2011 17:21:43
-0800]:
The hype of 2.0 aside, is there a guideline for what should
constitute
a
major version number change?
It looks like we are doing something like:
QUnit tests (for our JavaScript modules) can be ran by opening
./tests/qunit/index.html
in your browser.
Note that this is about to change in a few days, but check
https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing
for the latest info.
On Fri, Dec 30, 2011 at 9:29 PM, Roan Kattouw
' is assigned to allow users to know whether a revision is
patrolled or not and allow them to mark it as such (which can potentially
replace the duplication of 'trusted user' lists, simply check if the user
has
this user right on the target wiki).
Krinkle
[1]
https://meta.wikimedia.org/wiki/User:Krinkle
double work as people click the same links.
I could go on like this but I better stop now. Hop in on #countervandalism
for more.
Krinkle
[1]
https://meta.wikimedia.org/wiki/User:Krinkle/Tools/Real-Time_Recent_Changes
[2] https://meta.wikimedia.org/wiki/User:Krinkle/Scripts/CVNSimpleOverlay
[3
on elements that you inserted
through AJAX or for other reasons are not covered by $( 'table.sortable' )
at document ready.
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
/show_bug.cgi?id=26741
(image/oldimage to filerevision).
And another one would be to make the file system even more like
page/revisions.
By giving implementing file ids and filerevision ids.
- Krinkle
[1] http://www.mediawiki.org/wiki/License_integration
301 - 400 of 486 matches
Mail list logo
