On 25/03/11 14:41, Daniel Friesen wrote:
> For awhile I was thinking 'What if I give memcached on a machine of it's
> own a really large size and let it swap?'.
One problem you would likely run into is that the metadata is not
localised at all, so you would end up loading a lot of pages to do a
s
On 11-03-24 07:43 PM, Tim Starling wrote:
> Our parser cache hit ratio is very low, around 30%.
>
> http://tstarling.com/stuff/hit-rate-2011-03-25.png
>
> This seems to be mostly due to insufficient parser cache size. My
> theory is that if we increased the parser cache size by a factor of
> 10-100
Our parser cache hit ratio is very low, around 30%.
http://tstarling.com/stuff/hit-rate-2011-03-25.png
This seems to be mostly due to insufficient parser cache size. My
theory is that if we increased the parser cache size by a factor of
10-100, then most of the yellow area on that graph should go
On 11-03-24 06:12 PM, Aryeh Gregor wrote:
> On Tue, Mar 22, 2011 at 10:46 PM, Tim Starling
> wrote:
>> If we split up the extensions directory, each extension having its own
>> repository, then this will discourage developers from updating the
>> extensions in bulk. This affects both interface ch
On Thu, Mar 24, 2011 at 9:27 PM, Happy-melon wrote:
> I think Roan hits it on the nose. Most of the problems Ashar and Neil raise
> are flaws in our code review process, not flaws in the tools we use *to do*
> code review. I actually think that CodeReview works quite well, **for the
> system we
On Thu, Mar 24, 2011 at 9:22 AM, Joseph Roberts
wrote:
> Ah, cool. If no one minds, shouldn't [[mw:HTML5]] be editted to
> reflect what h in the mainstream?
[[mw:HTML5]] only really covers the use of HTML5 markup, not other
HTML5 features. The idea was to discuss the benefits of changing our
do
I think Roan hits it on the nose. Most of the problems Ashar and Neil raise
are flaws in our code review process, not flaws in the tools we use *to do*
code review. I actually think that CodeReview works quite well, **for the
system we currently use**. I think many of us agree that, one way o
On Thu, Mar 24, 2011 at 2:00 PM, Roan Kattouw wrote:
> 2) Resolving conflicts between patches is done by reviewers when they
> apply them instead of being conveniently outsourced to the
> author-committers
If there's a conflict, the reviewer can ask the patch submitter to
submit a new version wit
On Tue, Mar 22, 2011 at 10:46 PM, Tim Starling wrote:
> The tone is quite different to one of the first things I read about
> Mercurial:
>
> "Oops! Mercurial cut off your arm!
>
> "Don't randomly try stuff to see if it'll magically fix it. Remember
> what you stand to lose, and set down the chains
Yuvi Panda wrote:
> Hi, I'm Yuvi, a student looking forward to working with MediaWiki via
> this year's GSoC.
>
> I want to work on something dump related, and have been bugging
> apergos (Ariel) for a while now. One of the things that popped up into
> my head is moving the dump process to another
>> So, thoughts on this? Is 'Move Dumping Process to another language' a
>> good idea at all?
>>
>
> I'd worry a lot less about what languages are used than whether the process
> itself is scalable.
I'm not a mediawiki / wikipedia developer, but as a developer / sys
admin, I'd think that adding an
On Fri, Mar 25, 2011 at 7:40 AM, Sumana Harihareswara wrote:
> There's no point in having our GSoC applicants wasting time working on
> proposals that we aren't really interested in
Who is "we" the wikimedia foundation? the medawiki developers? someone else?
If anyanything they should be striked
On Thu, Mar 24, 2011 at 1:05 PM, Yuvi Panda wrote:
> Hi, I'm Yuvi, a student looking forward to working with MediaWiki via
> this year's GSoC.
>
> I want to work on something dump related, and have been bugging
> apergos (Ariel) for a while now. One of the things that popped up into
> my head is
There's no point in having our GSoC applicants wasting time working on
proposals that we aren't really interested in, that another developer is
already half-done implementing, or that are just plain bad ideas. So
please take a look at the project ideas page
http://www.mediawiki.org/wiki/Summer
On 03/24/2011 04:45 AM, Joseph Roberts wrote:
> Actually, looking through OggHandler, I do think that developing a
> seperate entity may work well.
> I'm not quite sure what is wanted by the general public and would like
> to do what is wanted by the majority, not just wat would be easiest or
> eve
Hi, I'm Yuvi, a student looking forward to working with MediaWiki via
this year's GSoC.
I want to work on something dump related, and have been bugging
apergos (Ariel) for a while now. One of the things that popped up into
my head is moving the dump process to another language (say, C#, or
Java, o
On 24/03/11 09:41, K. Peachey wrote:
> It's sitting there in SVN, nothing is stopping people from working on
> it, In fact Sam and Chad might like the help, But your arugment that
> having more developers(/man power) != better working systems.
I am a dev with commit access and could probably sync
2011/3/24 Neil Kandalgaonkar :
> - Allows us to deploy trunk. At any time. Eliminate the production
> branch. Any developer in the world should be able to work on the code we
> actually have in production without having to decide between trunk and a
> production branch.
>
You're basically arguing f
Hi All,
yes, I think we could bring up support for WikiTrust on the Spanish
Wikipedia for this purpose.
The way we worked with Martin Walker for the English project is that he gave
us a list of page_ids, and we gave back a csv file with, for each page_ids,
the recommended revision_ids, each with a
On 03/24/2011 10:13 AM, Neil Kandalgaonkar wrote:
> Anyway, this is all vague and clearly I'm talking about radical changes
> to the entire MediaWiki community. But I believe it would help quite a bit.
>
> Maybe I should work on it a bit more and present it on a wiki page
> somewhere, as well as in
Am 23.03.2011 23:33, Tim Starling wrote:
> recursiveTagParse() is the function to use from a tag hook or other
> parser hook, to parse text when a parse operation is already in
> progress on the same Parser object. It should not be used when a parse
> operation is not in progress. Its output is act
On Wed, Mar 23, 2011 at 4:14 PM, Daniel Friesen
wrote:
> On 11-03-23 06:36 AM, Marcin Cieslak wrote:
> > [...]
> > Just to give a not-so-hypothetical example, since I don't like discussing
> > in vain, what about this:
> >
> > Is this okay to fix
> https://bugzilla.wikimedia.org/show_bug.cgi?id=
On 03/24/2011 12:44 AM, Ashar Voultoiz wrote:
> On 24/03/11 06:47, MZMcBride wrote:
> > It's only impolite if you criticize the code review tool without being
> > constructive. What specifically do you not like about the current code
> > review tool?
I agree with most of what Ashar said. Lack
On Thu, Mar 24, 2011 at 3:44 AM, Ashar Voultoiz wrote:
> - I still have not figured out how to filter by author AND path
Special:Code/MediaWiki/author/hashar?path=/trunk/phase3
or if you only want unreviewed revs:
Special:Code/MediaWiki/status/new?author=hashar&path=/trunk/phase3
The UI still
Hi Markus,
That sounds good. I have added some common tasks/assertions.
How do you think one could use those in test plans/descriptions?
If you are interested in how we plan/do use WMF Selenium framework, I have
updated SMW Selenium tests documentation [1].
Best,
Benedikt
[1] http://www.sema
On 24 March 2011 12:18, Bryan Tong Minh wrote:
> On Thu, Mar 24, 2011 at 12:27 PM, Joseph Roberts
> wrote:
>> Thanks, would it be preferable to add HTML5 to that or make another
>> extension purely for using /?
>>
> OggHandler already implements . It tries to select an
> appropriate player (, Cor
Yours sincerely,
Has long tried to start a Wikipedia 1.0 project in Spanish
(http://es.wikipedia.org/wiki/Wikipedia:Wikipedia_en_CD). Project
similar to the English version.
The problem is that I have been unable to contact WikiTrust team
(http://www.wikitrust.net/authors). We need the support of
On Thu, Mar 24, 2011 at 12:27 PM, Joseph Roberts
wrote:
> Thanks, would it be preferable to add HTML5 to that or make another
> extension purely for using /?
>
OggHandler already implements . It tries to select an
appropriate player (, Cortado or VLC) depending on the user's
browser.
Actually, looking through OggHandler, I do think that developing a
seperate entity may work well.
I'm not quite sure what is wanted by the general public and would like
to do what is wanted by the majority, not just wat would be easiest or
even the best.
What would be the best way to implement a HT
Thanks, would it be preferable to add HTML5 to that or make another
extension purely for using /?
On 24 March 2011 11:16, Bryan Tong Minh wrote:
> On Thu, Mar 24, 2011 at 12:05 PM, Joseph Roberts
> wrote:
>> Hey all,
>>
>> I've been scanning the source and I can't find where the players are kept
On Thu, Mar 24, 2011 at 12:05 PM, Joseph Roberts
wrote:
> Hey all,
>
> I've been scanning the source and I can't find where the players are kept.
> Can anyone add any insight on this? Is it done as a hook or direct code?
Extension:OggHandler. The video player is Cortado, which is bundled
with Ogg
Hey all,
I've been scanning the source and I can't find where the players are kept.
Can anyone add any insight on this? Is it done as a hook or direct code?
TIA - Joseph Roberts
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.
On Thu, Mar 24, 2011 at 5:44 PM, Ashar Voultoiz wrote:
> Neilk is realist. Either we bring more developers in the system or we
> drop it and reuse another system already having some developers.
It's sitting there in SVN, nothing is stopping people from working on
it, In fact Sam and Chad might lik
On 24/03/11 06:47, MZMcBride wrote:
> It's only impolite if you criticize the code review tool without being
> constructive. What specifically do you not like about the current code
> review tool? And have you filed bugs about getting these issues addressed?
I have answered to this message in a n
Neilk wrote:
>> At the risk of being impolite -- our code review tool is not that nice.
>> (I don't expect that anyone who worked on it would even disagree with me
>> here.)
On 24/03/11 06:47, MZMcBride wrote:
> It's only impolite if you criticize the code review tool without being
> constructiv
35 matches
Mail list logo
