Re: [Wikitech-l] We're not quite at Google's level

On Sat, May 16, 2009 at 2:58 AM, The Cunctator wrote: > We should definitely highlight real downtime as a reason for funding, > especially in a way that discusses practical steps that would be taken to > reduce the problem and how much those steps would cost. And highlight how much previous donat

[Wikitech-l] MediaWiki release candidate 1.15.0rc1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MediaWiki 1.15.0rc1, a release candidate for the 2009 Q2 branch of MediaWiki, is now available. Please try it out and tell us if it works for you. This is a beta release and is not recommended for use in a production environment. SQLite support has be

Re: [Wikitech-l] Procedure for renaming files as a part of patches

On Fri, 15 May 2009 21:57 -0400, "Chad" wrote: > I'm aware of the bug, I just didn't see any major reason > to do it. However, consistency is always good and this > is a pretty low-impact change. > > -Chad > > On May 15, 2009 9:50 PM, "Karun Dambiec" wrote: > > > > On Fri, 15 May 2009 21:

Re: [Wikitech-l] Procedure for renaming files as a part of patches

I'm aware of the bug, I just didn't see any major reason to do it. However, consistency is always good and this is a pretty low-impact change. -Chad On May 15, 2009 9:50 PM, "Karun Dambiec" wrote: On Fri, 15 May 2009 21:44 -0400, "Chad" wrote: > That should be a part of your patch, renaming

Re: [Wikitech-l] Procedure for renaming files as a part of patches

On Fri, 15 May 2009 21:44 -0400, "Chad" wrote: > That should be a part of your patch, renaming the files. > If you renamed via svn, then it should be included in > your unified diff. Fwiw, is there any compelling reason > to change them all to .inc? The majority seem to be > .inc.php. > > -Chad

Re: [Wikitech-l] Procedure for renaming files as a part of patches

That should be a part of your patch, renaming the files. If you renamed via svn, then it should be included in your unified diff. Fwiw, is there any compelling reason to change them all to .inc? The majority seem to be .inc.php. -Chad On May 15, 2009 9:40 PM, "Karun Dambiec" wrote: Hello, I hav

[Wikitech-l] Procedure for renaming files as a part of patches

Hello, I have been working on a patch for Bug 18698 which is where we have inconsistent file naming standards being .inc and .inc.php The patch I have created corrects the file naming to .inc in the affected files. Once it has been reviewed and after that, is there some form of procedure or proces

Re: [Wikitech-l] Database Abstraction

I already run Mediawiki on ADODB (see bug 9767 over at Bugzilla) and concur with what I see as the intent of the start of this thread. As I began to move from 1.14 to 1.15, I noted a problem with Special:RecentChanges and Special:RecentChangesLinked that are characterized in that message (i.e., qu

Re: [Wikitech-l] Database Abstraction

On Fri, May 15, 2009 at 5:01 PM, Thomas Dalton wrote: > 2009/5/15 George Herbert : > > Domas, I assume you're still on this list - can you give us some > background > > why we're not on a closer to current release MySQL within the WMF > > environments? > > Upgrading for the sake of upgrading is al

Re: [Wikitech-l] Database Abstraction

2009/5/15 George Herbert : > Domas, I assume you're still on this list - can you give us some background > why we're not on a closer to current release MySQL within the WMF > environments? Upgrading for the sake of upgrading is always a bad idea. The question should also be "why should we upgrade?

Re: [Wikitech-l] Database Abstraction

Hi! > MySQL 5.x have been out for a very long time now. 3.5 years of > production > stable release for 5.0. Oh! Time flies fast. > Domas, I assume you're still on this list - can you give us some > background > why we're not on a closer to current release MySQL within the WMF > environments

Re: [Wikitech-l] More aggressive DEFAULTSORT

MySQL is open source -- what sort of changes did you have in mind? 2009/5/15 Domas Mituzas > > > > Given that WMF is one of the largest and most visible MySQL users, > > wouldn't it > > be possible to push this a bit? Perhaps even help with developer > > time (that > > would otherwise be spent o

Re: [Wikitech-l] More aggressive DEFAULTSORT

> > Given that WMF is one of the largest and most visible MySQL users, > wouldn't it > be possible to push this a bit? Perhaps even help with developer > time (that > would otherwise be spent on working around this problem)? :-) Domas ___ Wikitech-

Re: [Wikitech-l] Database Abstraction

On Thu, May 14, 2009 at 6:50 AM, Aryeh Gregor > wrote: > ... Keep in mind that we can't be purists here > about standard SQL or whatever -- the code must work on MySQL 4.0, and > it must be *efficient* on MySQL 4.0, at any cost, since that's what > Wikipedia runs. Still? MySQL 5.x have been o

[Wikitech-l] Tracking Wikipedia using ShowSlow

Guys, I've added Wikipedia homepage and Hillary Clinton (Re: bug #17577) page to ShowSlow.com's tracker: http://www.showslow.com/details/?url=http%3A%2F%2Fwikipedia.org%2F http://www.showslow.com/details/?url=http%3A%2F%2Fen.wikipedia.org%2Fwik

Re: [Wikitech-l] Database Abstraction

On Fri, May 15, 2009 at 5:48 PM, Karun Dambiec wrote: > The first benchmark is a synthetic one that does not measure > live performance. This benchmark tries to be more realistic, > measuring HTTP requests/second. In this test, we select and > display 82 rows from the products table once per page

Re: [Wikitech-l] Database Abstraction

On Fri, 15 May 2009 09:45 -0400, "Aryeh Gregor" wrote: > On Fri, May 15, 2009 at 6:48 AM, Karun Dambiec wrote: > > From looking further into ADODB, it appears that the performance hit > > from using it could be significant for projects like Wikipedia (14% or > > so from the statistics on the A

Re: [Wikitech-l] More aggressive DEFAULTSORT

On Fri, May 15, 2009 at 1:27 PM, Nikola Smolenski wrote: > Given that WMF is one of the largest and most visible MySQL users, wouldn't it > be possible to push this a bit? Perhaps even help with developer time (that > would otherwise be spent on working around this problem)? Wikimedia is nowhere

Re: [Wikitech-l] More aggressive DEFAULTSORT

Дана Friday 15 May 2009 11:47:56 Tisza Gergő написа: > What are the chances that we get decent MySQL collation in the close future > (say, next few years)? Bug 164 was opened 5 years ago, there is no point in > waiting another 5 years for database-level collations (and we do get them, > the system

Re: [Wikitech-l] We're not quite at Google's level

We should definitely highlight real downtime as a reason for funding, especially in a way that discusses practical steps that would be taken to reduce the problem and how much those steps would cost. On Fri, May 15, 2009 at 12:46 PM, Thomas Dalton wrote: > 2009/5/15 Bilal Abdul Kader : > > Sorry

Re: [Wikitech-l] We're not quite at Google's level

2009/5/15 Bilal Abdul Kader : > Sorry I missed the point in a previous post then. The wordings looked like > using the downtime as a strategy. Oh, no, I certainly wasn't proposing we fake downtime, that would be seriously unethical, I agree. We have plenty of natural downtime we can exploit. (The

Re: [Wikitech-l] How to submit a patch for Mediawiki extensions?

On Fri, May 15, 2009 at 10:41 AM, Strainu wrote: > I'm sure that it's written somewhere on Mediawiki.org or on meta, but I > can't get hold of the information right now. Can somebody help me? If it's an extension in Wikimedia's SVN, then you can submit it on Bugzilla (bugzilla.wikimedia.org). Ot

Re: [Wikitech-l] We're not quite at Google's level

Sorry I missed the point in a previous post then. The wordings looked like using the downtime as a strategy. On Fri, May 15, 2009 at 12:02 PM, Thomas Dalton wrote: > 2009/5/15 The Cunctator : > > No, and it's stupid. It's not like this is a covert discussion. > > > > On Fri, May 15, 2009 at 11:

Re: [Wikitech-l] We're not quite at Google's level

2009/5/15 The Cunctator : > No, and it's stupid. It's not like this is a covert discussion. > > On Fri, May 15, 2009 at 11:45 AM, Bilal Abdul Kader wrote: > >> Is it ethical? How is it unethical? We take advantage of downtime to explain to our readers that we rely on donations to keep the site run

Re: [Wikitech-l] We're not quite at Google's level

No, and it's stupid. It's not like this is a covert discussion. On Fri, May 15, 2009 at 11:45 AM, Bilal Abdul Kader wrote: > Is it ethical? > > > On Fri, May 15, 2009 at 8:03 AM, Karun Dambiec wrote: > > > It could possibly be a strategy to increase the number of donations. > > -- > > Karun Dam

Re: [Wikitech-l] We're not quite at Google's level

Is it ethical? On Fri, May 15, 2009 at 8:03 AM, Karun Dambiec wrote: > It could possibly be a strategy to increase the number of donations. > -- > Karun Dambiec > ka...@fastmail.fm > > > On Fri, 15 May 2009 12:59 +0100, "Thomas Dalton" > wrote: > > http://news.bbc.co.uk/1/hi/technology/80512

Re: [Wikitech-l] How to submit a patch for Mediawiki extensions?

Hello, I understand you that you have resolve a bug in a extension? Now you want to publish this change? If the extension is on the Wikimedia SVN, you need commit access(http://www.mediawiki.org/wiki/Commit_access). That is only needed if you interested in a "long work", else send the files with

[Wikitech-l] How to submit a patch for Mediawiki extensions?

I'm sure that it's written somewhere on Mediawiki.org or on meta, but I can't get hold of the information right now. Can somebody help me? Thanks, Andrei ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/lis

Re: [Wikitech-l] Database Abstraction

On Fri, May 15, 2009 at 6:48 AM, Karun Dambiec wrote: > From looking further into ADODB, it appears that the performance hit > from using it could be significant for projects like Wikipedia (14% or > so from the statistics on the ADODB site). 14% over what? For trivial queries that take 0.1ms to

Re: [Wikitech-l] More aggressive DEFAULTSORT

On Fri, May 15, 2009 at 4:22 AM, Tisza Gergő wrote: > Would it be very expensive to have a separate (namespace, title, sortkey) > table, > and join on that for queries that need sorting? You would have to scan the *entire* table you're joining from (which may be hundreds of millions of rows). N

Re: [Wikitech-l] We're not quite at Google's level

It could possibly be a strategy to increase the number of donations. -- Karun Dambiec ka...@fastmail.fm On Fri, 15 May 2009 12:59 +0100, "Thomas Dalton" wrote: > http://news.bbc.co.uk/1/hi/technology/8051262.stm > > Google has an hour of slow service and it's headline news. Imagine the > d

[Wikitech-l] We're not quite at Google's level

http://news.bbc.co.uk/1/hi/technology/8051262.stm Google has an hour of slow service and it's headline news. Imagine the donations we could get if our downtime (which, as David is fond of saying, is our most profitable product) got into the headlines! Perhaps we should take to issuing press releas

Re: [Wikitech-l] Database Abstraction

On Thu, 14 May 2009 15:18 +0300, "Domas Mituzas" wrote: > Hello, > > > Are there any disadvantages that would result from doing work on > > using a > > database abstraction layer such as Adodb? Or advantages that are > > gained > > from the current methods of accessing databases. > > our l

Re: [Wikitech-l] More aggressive DEFAULTSORT

Aryeh Gregor gmail.com> writes: > On Thu, May 14, 2009 at 10:34 AM, Marcus Buck marcusbuck.org> > wrote: > > Take the pagename and make it uppercase (could be lowercase too, but > > uppercase seems better as the first letter will show up in the > > category). str_replace "Ä" with "A", "Ö" with

Re: [Wikitech-l] More aggressive DEFAULTSORT

> Would it be very expensive to have a separate (namespace, title, > sortkey) table, > and join on that for queries that need sorting? yes, very. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/lis

Re: [Wikitech-l] More aggressive DEFAULTSORT

Aryeh Gregor gmail.com> writes: > Other than that, a problem with this is that page titles aren't just > in page, they're scattered all over the place. We use (namespace, > title) pairs for pagelinks, templatelinks, recentchanges, watchlist, > logging, redirect, protected_titles, among others, a