On 6 February 2013 23:58, Tim Starling <tstarling(a)wikimedia.org> wrote:
> I think we can turn MediaWiki into a fully featured wiki engine which
> can compete with the likes of Confluence. I don't think it can ever
> compete with TiddlyWiki or UseModWiki in their respective niches.
(veering slightly off topic)
What in Confluence are you thinking of MediaWiki as lacking?
The main two in my experience are (1) firm access control (2) WYSIWYG
editor. (1) is just not something MW can promise to do securely unless
pretty much every developer cared and (2) is on the way (certainly
before the end of time). Any others of importance?
[ps: Confluence is horrible and its hardware requirements do in fact
make MediaWiki look lightweight.]
- d.
Hi Erik,
> You're quite right numbers are inflated, and we've been over this before [1].
> Below are some sampled data for da.wiktionary from webstatscollector [2] and squid log [3]
> Bot traffic is a substantial share of 'page views' (but not the majority as you suggest).
>
> We discussed this extensively in April and as I remember (my mail archive is somehow incomplete)
> decided to implement a second cleaned-up stream
> without /bot/crawler/spider/http (keeping the original stream so as not break trend lines)
>
> However that bot free stream (projectcounts files with extra set of per wiki totals)
> never happened yet, and I'm pretty sure we changed plans since,
> and probably now wait for Kraken. Diederik can you add to this?
Oh my, I thought this was in operation already.
I've actually been looking at these page view stats,
and now I feel like a fool.
Why not just remove these web pages at
http://stats.wikimedia.org/wiktionary/EN/TablesPageViewsMonthly.htm
since they contain only nonsense? Continuity with
old nonsense is still nonsense, so remove everything
now and start a new project with real numbers.
> [1] On April 8, 2012 you reported a similar issue for Swedish Wikipedia.
> I checked by then one hour of sampled squid log. 9 out of 13 requests were bots.
Nobody doubts that the Swedish Wikipedia has a
substantial amount of human traffic. But for smaller
projects, the background noise will dominate. If
bots are 9 out of 13 requests to sv.wikipedia (really?),
they can easily be 99% of traffic to da.wiktionary.
One easy way to tell would be to observe the daily
rhythm. Since Swedish and Danish are limited to one
timezone, traffic in the middle of the night should be
much smaller than mid-day traffic. But bots could
be operating all night, all day. So the least active hour
is probably the background noise from bots.
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
Hi,
I have installed Maria DB to all my servers, including production servers
few weeks ago, and I found it quite stable and I like it (even the command
line tool for working with sql is far better than the one included in mysql
pack)
It's supported on all latest ubuntu versions from 10.04 UP (maybe even
older) - so my question is, are we going to use it on wikimedia production?
I think we could migrate beta cluster for now - it has terrible performance
and this could help. It could be a first step to migrate wikimedia
production cluster.
Hi all,
I have been talking to many third-party yas part of my WMF internship in
the last few weeks and one the main concerns they express is the lack of
stability in the PHP classes MediaWiki exposes from version to version. The
frequent changes in what I would call the PHP-API makes extentions
developement and maintenance much more difficult with compatibility from
version to version becoming a problem. Solving the problem would probably
result in the development of more extensions, easier maintenance, less
hacks to core and more users upgrading to the latest MediaWiki version. I
am sure WMF developers are facing similar issues especially with projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki carries,
is it possible to have a (relatively) stable set of PHP classes defined,
with a pledge not to change them in the next X releases or at least with
some longer deprecation time? What would maintaining such a PHP-API entail?
How difficult is it given the vast number of dependancies in MediaWiki
code? Does it require restructuring a lot of the current core code? Do you
think it should be a definite goal for WMF?
Thank you.
Mariya
At
http://www.mediawiki.org/w/index.php?title=ResourceLoader/Features&oldid=64…
it is written:
It starts by performing a quick sanity check that bails out if the
current browser is not supported. This saves bandwidth as well as
preventing broken interfaces, basically leaving the user with an
untouched page with the natural non-javascript fallback behavior.
Browsers such as Internet Explorer 5 and early versions of Mozilla fall
in this category.
While I see that it works, I can't find where exactly in the code is
this sanity check located. Any pointers?
Sorry, I've replied to Sumana directly instead of the mailing list. So
now duplicating into the mailing list.
Sumana Harihareswara писал 2012-12-19 22:30:
> Try these tips:
> https://www.mediawiki.org/wiki/Git/Code_review/Getting_reviews
Sumana, it's all very good but:
1) I think it's not so comfortable to push other developers personally
when adding them as the reviewers... And I don't know whom to add as the
reviewer, so I just choose randomly. But what if that guy doesn't want
to do review for that extension? For example what if he is already very
busy in working on mediawiki _core_, and I ask him to review a trivial
extension?
2) Who can verify changes in extensions? There is no CI. So, people who
can verify changes and people who can put +2 - are they the same people?
But it again leads to short-circuiting all the work to the "core"
people, and aren't they already busy? (I assume they are as they don't
review all the changes)
3) As a solution, I think it would be good if - at least in
not-so-important-as-the-core extensions - the changes merged
automatically after getting, for example, 2x "+1"... Or will you end up
with changes reviewed by not merged by anyone? And also, maybe it would
also be good if the system automatically added some reviewers - randomly
or based on some "ownership" rules...
Hi all!
Since https://gerrit.wikimedia.org/r/#/c/21584/ got merged, people have been
complaining that they get tons of warnings. A great number of them seem to be
caused by the fact the MediaWiki will, if the DBO_TRX flag is set,
automatically start a transaction on the first call to Database::query().
See e.g. https://bugzilla.wikimedia.org/show_bug.cgi?id=40378
The DBO_TRX flag appears to be set by default in sapi (mod_php) mode. According
to the (very limited) documentation, it's intended to wrap the entire web
request in a single database transaction.
However, since we do not have support for nested transactions, this doesn't
work: the "wrapping" transaction gets implicitely comitted when begin() is
called to start a "proper" transaction, which is often the case when saving new
revisions, etc.
So, DBO_TRX sems to be misguided, or at least broken, to me. Can someone please
explain why it was introduced? It seems the current situation is this:
* every view-only request is wrapped in a transaction, for not good reason i can
see.
* any write operation that uses an explicit transaction, like page editing,
watching pages, etc, will break the wrapping transaction (and cause a warning in
the process). As far as I understand, this really defies the purpose of the
automatic wrapping transaction.
So, how do we solve this? We could:
* suppress warnings if the DBO_TRX flag is set. That would prevent the logs from
being swamped by transaction warnings, but it would not fix the current broken
(?!) behavior.
* get rid of DBO_TRX (or at least not use it per default). This seems to be the
Right Thing to me, but I suppose there is some point to the automatic
transactions that I am missing.
* Implement support for nested transactions, either using a counter (this would
at least make DBO_TRX work as I guess it was intended) or using safepoints (that
would give us support for actual nested transactions). That would be the Real
Solution, IMHO.
So, can someone shed light on what DBO_TRX is intended to do, and how it is
supposed to work?
-- daniel
Greetings all,
Victor is releasing a video tomorrow for valentines day and whilst I was
discussing it with him, the topic of "how many users actually watch our
videos" came up. Do we currently have a way of collecting play/click stats
for content played by the TimedMediaHandler off of commons?
If not, does anyone have any ideas on how to go about getting this
information?
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team