Στις 07-07-2013, ημέρα Κυρ, και ώρα 21:09 -0700, ο/η Randall Farmer
έγραψε:
> Sorry, reading back over this thread late.
>
>
> > What I hope for is a format that allows dumps to be produced much
> more
> > rapidly, where the time to produce the incrementals grows only as
> the
> > number of edits per time frame grows
>
>
> Curious: what's happening currently that makes the time to produce
> incrementals grow more quickly than that?
>
We don't produce true incrementals now; we produce 'adds/changes' dumps
which don't acocunt for deletions, oversights, page moves, etc. And you
can't add them onto a full to get a new full. When they are produced, I
want them to behave as described above.
Ariel
Hello! Our current generated documentation[1] uses doxygen, and
leaves... a number of things to be desired - such as:
1. Not be tortoise slow
2. Have usable search
3. Prettier interface
I was looking around for alternatives, and ran into phpdocumentor2[2].
The project still seems active (latest commit was 3 days ago, and for
vagrant support!), and the demo was quite pretty:
http://demo.phpdoc.org/Responsive/namespaces/phpDocumentor.html
Is there any particular reason we are still sticking with doxygen? Or
is it just 'someone needs to find the time to move things over to the
new system'?
[1]: https://doc.wikimedia.org/mediawiki-core/master/php/html/
[2]: http://www.phpdoc.org/
--
Yuvi Panda T
http://yuvi.in/blog
Rob Lanphier has asked that the WMF architects -- namely Brion Vibber,
Mark Bergsma, Asher Feldman and myself -- take a leading role in
accepting or rejecting RFCs, or delegating that decision as appropriate.
Along these lines, I'd like to add an header template to every RFC
indicating its status as determined by one of these architects or the
people to whom they delegate authority. The header would indicate not
only status (mirroring the index page) but also the name of the person
who chose that status.
Seeking consensus has always been a key part of my work on MediaWiki.
I expect that a large part of assigning a status to an RFC will simply
be to evaluate the comments of the participants, or to seek comments
from specific domain experts where none have been given.
Many RFCs are just "good ideas", often attracting no comment because
there is no obvious criticism of the feature at the level of detail
given by the proposer. This raises the question of whether an RFC is a
feature request (like a Bugzilla enhancement) or a design document. If
an RFC is a design document, then we might ask for more detail about
feature implementation, and close the RFC if none is given. This may
lead to the closure of RFCs which have no interest or support from
developers. I'm inclined to think that this is an appropriate path to
take, i.e. that RFCs should be design documents, but I am interested
to hear comments on the subject.
Please comment here or on
<https://www.mediawiki.org/wiki/Talk:Requests_for_comment>
-- Tim Starling
I'm writing it in C++.
If you want, you can follow my progress in the operations/dumps/incremental
repo, branch gsoc [1] (but there isn't almost anything there yet).
And I don't have any computers with non-x86 architecture, so I won't be
able to test that.
[1]:
https://git.wikimedia.org/log/operations%2Fdumps%2Fincremental/refs%2Fheads…
On Wed, Jul 3, 2013 at 10:13 PM, Byrial Jensen <byrial(a)vip.cybercity.dk>wrote:
> At 03-07-2013 18:29, Petr Onderka wrote:
>
>> I'm primarily a Windows guy, so I'm trying to write the code in a
>> portable way and I will make sure the application works on both Linux
>> and Windows.
>>
>
> That sounds good. Just remember that portable not only means that it works
> on different operating systems on the same computer architecture, but also
> on different architectures. What programming language do you intend to use?
>
>
>
> ______________________________**_________________
> Xmldatadumps-l mailing list
> Xmldatadumps-l(a)lists.**wikimedia.org <Xmldatadumps-l(a)lists.wikimedia.org>
> https://lists.wikimedia.org/**mailman/listinfo/xmldatadumps-**l<https://lists.wikimedia.org/mailman/listinfo/xmldatadumps-l>
>
Hi,
I've hit an interesting problem with the URL of an image (not the
description page) on the OSM wiki. I could not see the image from
http://wiki.openstreetmap.org/wiki/File:731.jpg until I actually
clicked on the "full resolution" link. The reason for that was that
the image URL was http://wiki.openstreetmap.org/w/images/a/ad/731.jpg
, and one adblock rule was blocking "/ad/".
That particular rule was from my personal list, but I've noticed that
EasyList, the "basic" subscription for AdBlockPlus users, is also
blocking lots of strings that start with /ad/.
Has someone else notice such a problem on WMF wikis? Do you think it
would be worth it to change MediaWiki so that it doesn't generates
URLs containing /ad/, /ads/ or something else along these lines?
Thanks,
Strainu
