/CSS is now served from bits.wikimedia.org
as well, which means things like relative @import statements in CSS
are broken at this time; we're working on a fix for that.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
contain
preferences data.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2011/2/10 Soxred93 soxre...@gmail.com:
prefstats maybe?
Yeah, that would contain some data, but only for the skin and
usebetatoolbar preferences.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
with us
(#wikimedia-tech). Is he.wikisource.org ready?
We can always just change the language on test2.wikipedia.org to
Hebrew or something.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org
heterogeneous
deployments (different versions of the code on different wikis).
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
on the bug noting that
the DOM manipulation our JS does on the textarea might trigger this.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
should watch out and make sure
we've got regression tests covering any cases we find.
Yes, we need minifier tests.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
the edge of the
park.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
component?
There is an InlineEditor component now. I don't know who created it; I
tried to create it just now, but to my surprise it already existed.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
recommend using ?debug=true for that ;)
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
would be a nightmare, and would probably involve setting stuff
to read-only for a few hours.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
and drop the old tables.
Sure, it can be dealt with. It's just that it'd be an epic upgrade :)
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
is ridiculous. That, and it doesn't present
legal problems.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2011/1/21 Trevor Parscal tpars...@wikimedia.org:
Joke or not, it's in there, and it's a violation of the GPL.
Plus the alternative is better anyway.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
saw.
I think he finished recompressing a couple of months ago.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
has some nasty issues with selections.
Have you tried calling .dialog( 'close' ) before doAction() instead of
after? That's the only difference I can find between your code and the
built-in dialogs.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
to wikidiff2 (a custom C++ diff implementation
that generates diffs with HTML markup like ins/del) and caching
the result in memcached.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
like the code for this is already there [5], maybe I should
open a new bug right now?
Would be nice to track it in BZ, yes.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
be broken in 1.17, not in trunk), looking into
that now.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2011/1/7 Bryan Tong Minh bryan.tongm...@gmail.com:
Also FR seems to be unconditionally enabled, also on wikis that do not
have the tables present.
Which wikis would those be? Rob says he ran update.php so all the
tables should be there.
Roan Kattouw (Catrope
2011/1/7 Roan Kattouw roan.katt...@gmail.com:
TW is probably TranslateWiki. I wouldn't know what MWO is without
context, looking.
Seems to be a non-standard acronym for MW.org
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
2011/1/7 Diederik van Liere dvanli...@gmail.com:
The same error is given for:
* Russian
* Japanese
* Italian
* Arabic (ar is the language code)
All fixed now, thanks for reporting. I had tried to run update.php
against all DBs, but I forgot I'd commented out the code for switching
DBs.
Roan
revisions, we cache them in memcached.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
IE8 and below? Do any
of the proxy-needing browsers support CORS?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
can also imagine that there
would be other performance concerns with LST preventing its deployment
to large wikis, but I'm not sure of that.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org
wikipedia using #lst? :-)
Using #lst to implement variables in wikitext sounds like a terrible
hack, similar to how using {{padleft:}} to implement string functions
in wikitext is a terrible hack.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l
time ago) and I
haven't succeeded in convincing him to reply on this list (holidays, I
guess), but he's been playing around for it for about nine months now,
on and off, and from what I've heard and seen it's promising and
entirely in the spirit of your post.
Roan Kattouw (Catrope
welcome there for getting
advice from fellow developers and telling them the next time trunk
breaks like that :)
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
of
limbo where parts of the code are from 1.17, parts are from the code
meant to be in 1.18, and some of the files are mixed...
I'll take a look at cleaning this up right now. I'll do this by
reverting r79129 and merging the revisions it merged more carefully
and in smaller batches.
Roan Kattouw
2010/12/31 Roan Kattouw roan.katt...@gmail.com:
I'll take a look at cleaning this up right now. I'll do this by
reverting r79129 and merging the revisions it merged more carefully
and in smaller batches.
This is fixed now. I didn't go to such extremes as to completely
revert and re-do r79129
support is sort-of-ready before the 1.17
release and doesn't require non-trivial core changes, we can do that.
So Radim, please do all development in trunk, then if and when we
decide the code is 1.17-ready we'll merge it into REL1_17. This is
what we do for everything else too.
Roan Kattouw (Catrope
.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/12/17 Platonides platoni...@gmail.com:
-even assuming that the memcached can
happily handle it and no other data is affecting by it- the network
delay make it a non-free operation.
Because memcached uses LRU, I think this'll also flood a lot of stuff
out of the cache.
Roan Kattouw
-only) or how
much it would help (my impression is ES is one of the slower parts of
our system and reducing the number of ES hits by a factor 50 should
help, but I may be wrong), maybe someone with more relevant knowledge
and experience can comment on that (Tim?).
Roan Kattouw (Catrope
2010/12/7 Trevor Parscal tpars...@wikimedia.org:
I have made this point before, clearly upon deaf ears - but I will make
it again.
I don't think this'll surprise anyone, but I'll just state that I
fully agree with Trevor here.
Roan Kattouw (Catrope
or
changes to one specific component you're familiar with, you're taking
work out of the hands of other reviewers.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/12/7 Roan Kattouw roan.katt...@gmail.com:
When you commit or find a revision post-r77974 that you feel should be
in 1.17 (bugfixes, typically, no new features), tag it with 1.17 in
CodeReview.
It's been pointed out on IRC that you need to be in the coder group on
mediawiki.org to be able
2010/12/7 Roan Kattouw roan.katt...@gmail.com:
I'd also like to call upon everyone to help out with code review.
Another addendum inspired by IRC chatter: not just MediaWiki core
needs to be reviewed, extensions deployed on WMF wikis need review
too. So if you happen to be familiar with the code
that.
That's the correct approach indeed, thanks for correcting me or I
would've done it wrong.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
recent, that'd
be a strong case for moving the branch point into the past.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
some people's time to this).
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
deploy first and release later,
that's what we've always done AFAIK.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
their time to doing review and other things needed
to get 1.17 into shape (WMF-employed reviewers are mostly focusing on
their assigned projects now AFAICT) I think we can definitely finish
before March.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
branch or declare something like a feature freeze and freeze for minor
stuff in trunk. My general opinion on this sort of thing is that trunk
should not generally be subject to such freezes.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l
-cvs, this list is not archived. Tim and I are the current
list admins.
Roan Kattouw (Catrope)
[1] https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=22046
___
Wikitech-l mailing list
, but it's not
unreasonable to want to upload OpenOffice documents. Since the OO
formats are ZIP-like, blocking ZIPs blocks those too.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
2010/11/29 Jan Paul Posma jp.po...@gmail.com:
Full interview videos will be available on Wikimedia Commons somewhere next
month. They are in Dutch, though.
Michael, can we subtitle those with mwEmbed magic?
Roan Kattouw (Catrope)
___
Wikitech-l
with a .class extension. I can’t vouch for this method. **If you did
this, the zip library you used would have to be exactly as tolerant of
zip format errors as the one used by Java.** It would probably be best
to actually shell out to Java to do the test.
(emphasis mine)
Roan Kattouw (Catrope)
[1
and the
downtime situation with download.wm.o
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
modules from an extension
too.
If all you need to do is parse some wikitext without otherwise needing
to do things in PHP (i.e. if you can generate the wikitext to parse on
the JS side), you could use the existing action=parse module to parse
it.
Roan Kattouw (Catrope
6 clusters (three clusters of one, one
of three, one of ~20 and one with the other ~790), so we only need to
connect to 6 DB servers and run one query on each.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
2010/11/10 Jeroen De Dauw jeroended...@gmail.com:
Hey,
...are trying to find images in the /img/ folder...
So why is this, and how can it be fixed? It works when not using the RL...
Could you point me to the code that generates those img tags?
Roan Kattouw (Catrope
2010/11/10 Roan Kattouw roan.katt...@gmail.com:
2010/11/10 Tei oscar.vi...@gmail.com:
Hi,
Just a sugestion.
Downloading the last version of MediaWiki seems to take ages ATM.
Maybe servers are overloaded. And not mirror is offered.
$ wget http://download.wikimedia.org/mediawiki/1.16
This is because of the dumps server outage reported in this channel
earlier. The tarballs are hosted on the same server.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.
However, Trevor also said that other parts of MW already don't obey
$wgStyleDirectory . Maybe someone needs to try setting it and see if
things break.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
don't know where it is (maybe someone who
does can post a link?).
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
talking about here.
I guess you could take a concatenated version of all style sheets and
generate an RTL version of that. What do the current static dumps do?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
2010/11/10 Roan Kattouw roan.katt...@gmail.com:
I guess you could take a concatenated version of all style sheets and
generate an RTL version of that.
Hmm, and remap image paths, now I think of it. It'd probably be easier
to pull the CSS for all modules from the resource loader this way
wrong with image URL remapping here, but it's hard to figure out
what unless I can see it fail in my browser.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
cases.
Sounds good.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
. Static dumps wouldn't be affected as long as
they use one language consistently and fetch the CSS through RL.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/11/8 Ashar Voultoiz hashar+...@free.fr:
With Codereview backlog, manual updates fixing my own bugs ... I am
not sure I am going to help clean up Bugzilla backlog anytime soon :(
We're hiring a Bugmeister soon, hopefully that'll help.
Roan Kattouw (Catrope
to work on certain bugs. Right now my impression is we/they
mostly do projects.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
URL inlining based on user agent. We use
aggressive caching so we can't do anything based on User-Agent. We
still do data URLs, though, with a fallback rule that happens to only
work in browsers that don't support data URLs. It's a dirty hack, but
it works.
Roan Kattouw (Catrope
it at
the moment...
There is an ongoing issue with the thumbnail server, which has been
acting up all week. We're working on a quick temporary fix.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org
will end up near
the bottom of the body though, so you can't use inline JS to call
functions defined in that script.
Aren't too much
number of extensions would become suddenly incompatible due of that
change?
As long as they're not using inline JS, they won't break.
Roan Kattouw (Catrope
there to optimize your site, or you can have humans
implement those optimizations in MediaWiki. The latter is exactly what
ResourceLoader is doing.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org
if those people don't have time because their real responsibilities
take up all their time.
Roan Kattouw (Catrope)
* Back in December 2009, I had to take a few weeks off for fiscal
reasons and spent that time processing some of the backlog, which I
remember jokingly characterizing as doing Rob's
geoip.wm.o allows querying arbitrary IPs, but there's plenty of
other such services out there) and find out the rough location it
corresponds to. That means any questions regarding privacy of location
fall back to privacy of IP, and that's something we already have a
well-established policy for.
Roan
of
enabling a feature on a certain set of wikis (possibly all) upon
deployment and have requests to extend that set go through the shell
request procedure works just fine IMO.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
is a cookieless
domain. As opposed to other domains like wikipedia.org and
wikibooks.org , wikimedia.org doesn't get domain-wide cookies either,
because there are wikimedia.org subdomains not controlled by WMF.
Roan Kattouw (Catrope)
___
Wikitech-l mailing
.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Never before did we load JS through a special page like that, and with
the resource loader coming up it will never be needed ever again,
cause we can and will run everything through load.php . It's a
one-time anomaly, so no need for any convention.
Roan Kattouw (Catrope
complications, I do think Tim should be involved.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
feared, this is an after X plan, where X is the
next release. I disagree that that necessarily implies
procrastination, however. Sometimes there are valid reasons to do X
first, then Y, and I think this is such a case.
Roan Kattouw (Catrope
. Volunteers, in turn, should be aware that they have a
part to play too. Also, both sides should realize behaviors don't
change overnight, and should give each other time to adapt and cut
each other some slack in the meantime.
Roan Kattouw (Catrope
after having worked at WMF for quite some time. Don't
underestimate how long this process takes. We as a community go way
back, and outside staffers have missed all that history.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l
the words out right.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
with the 1.17 release, but that should be
discussed in a separate thread I guess.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
don't think any
new commenters will.
Let's just move Vector and WikiEditor into core soon and be done with it.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
after which the
toolbar will Just Work for them is fine.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/10/8 MZMcBride z...@mzmcbride.com:
I don't see how the link you provided addresses the post you were replying
to at all.
I think Ryan meant that the hiring a (full-time) Bugmeister was in the
annual plan.
Roan Kattouw (Catrope)
___
Wikitech-l
onload hooks fire before imported scripts in Chrome. You could
try using jQuery's document ready instead of addOnloadHook() and see
if that works.
Instead of addOnloadHook( function() { code here } ); do $j( document
).ready( function() { code here } );
Roan Kattouw (Catrope
that 1.4.2 breaks.
If you are the author of a user/site script or gadget, please do check
it for jQuery 1.4.2 compat just to be sure. If stuff breaks, feel free
to poke me on IRC and I'll help troubleshoot.
Roan Kattouw (Catrope)
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=25419
15:00-16:00
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
it.
I don't understand why this would be insulting, but whatever... These
people should file a bug in Bugzilla per the normal site request
procedure.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
2010/10/3 Roan Kattouw roan.katt...@gmail.com:
I don't understand why this would be insulting, but whatever...
Following the causes.com link clarifies this: it's a Russian influence thing.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l
our numbers first, but some preliminary
playing around seems to indicate Tim's right about this one.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
?
Colons get urlencoded but dashes are fine, so what about (and I know
I'm stealing this suggestion from /someone/, I just can't remember who
suggested it to me) 1985-04-12T10-15-30Z ?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l
, because we have a debug mode to give you
unminified (and uncombined) code.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/9/23 Brion Vibber br...@pobox.com:
(If using memcached, be sure to clear those out, reinitialize, or otherwise
do something that forces old values to be cleared or ignored.)
$wgCacheEpoch is a good one for this. The easiest way to change it is
to touch LocalSettings.php.
Roan Kattouw
acceptable usage AFAIK,
but I do think that the Toolserver would better suit your needs.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
it, on WMF we stick
it in memcached, I believe). So unless there's some ridiculous
vulnerability allowing people to obtain the value of arbitrary keys in
$_SESSION, you should be fine AFAIK.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l
SQL query buliding
methods but also the possibility to override the default printer? Why
these methods are limited to action=query lists and generators only?
That's a very good suggestion. Feel free to implement it or, if you
can't or don't want to, file a bug requesting it in Bugzilla.
Roan
2010/9/22 Roan Kattouw roan.katt...@gmail.com:
I understand that not every ApiBase derived class needs these, but many
could have. Why not make inheritance chain like this:
ApiBase - ApiListBase - ApiQueryBase
Actually, let's just put that stuff in ApiBase so every module can use
it easily
to ApiBase won't break any
other ApiBase subclasses. There is no advantage in creating a new
class over simply moving this stuff to ApiBase.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/9/22 Dmitriy Sintsov ques...@rambler.ru:
2. I don't have core commit access only extension commit access, however
I don't feel like MW guru, so I don't even want to request it. I'll
probably file a bug.
You can submit patches on Bugzilla too :)
Roan Kattouw (Catrope
2010/9/22 Dan Nessett dness...@yahoo.com:
How does memcached fit into this? When I looked at BagOStuff, I didn't
find a MemcacheBagOStuff class. Is it defined elsewhere?
Either memcached.php, MemCached.php or MWMemcached.php, I forget. The
class name is MWMemcached.
Roan Kattouw (Catrope
401 - 500 of 779 matches
Mail list logo
