Simetrical | 1 Jun 17:39
Picon

Re: Database dumps fail in the wrong way

On Fri, May 30, 2008 at 8:35 PM, Anthony <wikimail@...> wrote:
> Asking other people to do your job isn't.

Brion's job is to do what the Board tells him.  If they told him to
make fixing the dumps his first priority, he would, but they haven't,
so it's *not* his job (or anyone's) to fix this immediately.

On Sat, May 31, 2008 at 1:38 PM, Anthony <wikimail@...> wrote:
> I didn't see Brion's comment as a serious request for a patch.  In
> fact, I'm not even sure if he thinks the idea is a good one in the
> first place (or that it's "an aesthetic change that would not have any
> considerable benefit whatsoever").

When a developer in an open-source project says that patches are
welcome, I sure hope that they're serious, because otherwise they're
knowingly tempting people to waste time on patches that won't be
accepted.
Brion Vibber | 1 Jun 19:50
Picon
Gravatar

Re: Database dumps fail in the wrong way

Nicolas Dumazet wrote:
> See http://svn.wikimedia.org/viewvc/mediawiki/trunk/backup/WikiDump.py?r1=35655&r2=35654&pathrev=35655
> 
> It should now sort dumps by (LastDumpFailed, Age) in place of the
> previous by Age order.

Awesome, thanks! :)

I've updated the live script; note that there's currently going to be no 
visible difference, as the aborted dumps were already all at the bottom 
of the list.

There's a distinction between dumps which have been _aborted_, and those 
which have had elements _fail_.

_Aborted_ means that the system broke entirely (probably because the 
server it was running on died, or the dump process crashed or was killed 
manually). The dump monitor later found the expired lock file and 
declared it aborted, without necessarily being sure what went wrong.

These are marked in status.html with: <span class="failed">, and are 
what's currently caught by Nicolas' change.

Other dumps may run to completion, but still have _elements_ which 
failed. You'll see these such as the rash on May 26 marked as "Dump 
complete, 20 items failed" (in this case the MediaWiki-generated parts 
worked, but the raw SQL parts couldn't contact the server).

These are marked in status.html with: <span class='done failed'>

(Continue reading)

Brion Vibber | 1 Jun 20:01
Picon
Gravatar

Re: Database dumps fail in the wrong way

Anthony wrote:
> On Sat, May 31, 2008 at 9:11 AM, Chad <innocentkiller@...> wrote:
>> This community relies heavily on volunteer input,
>> and Brion asking for a patch is part of that.
>>
> I didn't see Brion's comment as a serious request for a patch.  In
> fact, I'm not even sure if he thinks the idea is a good one in the
> first place (or that it's "an aesthetic change that would not have any
> considerable benefit whatsoever").

That particular change is a good idea, but not a high-priority fix 
(Wikipedia is broken, must be fixed immediately!) so I'm not necessarily 
going to jump on it that second.

My role isn't to personally do all software development for Wikimedia; 
it's to make sure that necessary things get done to keep us online. 
While I do some programming myself, my primary responsibility is 
increasingly as an architect, project manager, gatekeeper, and mentor.

Our own programming staff is still very small; throw in a couple 
contract projects and a whole bunch of volunteers with their own 
individual assignments and areas of interest, and it's really a lot bigger.

When some interesting project exists, I have several possibilities:
* do it myself
* assign it to a staff programmer (Tim :)
* find someone to assign it to as a contract project
* find someone interested in poking at it for the fun and experience
* wait for someone interested to poke at it and be there to help them

(Continue reading)

Anthony | 1 Jun 20:26
Gravatar

Re: Database dumps fail in the wrong way

On Sun, Jun 1, 2008 at 2:01 PM, Brion Vibber <brion@...> wrote:
> Anthony wrote:
>> On Sat, May 31, 2008 at 9:11 AM, Chad <innocentkiller@...> wrote:
>>> This community relies heavily on volunteer input,
>>> and Brion asking for a patch is part of that.
>>>
>> I didn't see Brion's comment as a serious request for a patch.  In
>> fact, I'm not even sure if he thinks the idea is a good one in the
>> first place (or that it's "an aesthetic change that would not have any
>> considerable benefit whatsoever").
>
> That particular change is a good idea, but not a high-priority fix
> (Wikipedia is broken, must be fixed immediately!) so I'm not necessarily
> going to jump on it that second.
>
There's currently no valid full history English Wikipedia database
dump available.  (There was a completed history dump on 20080103, but
I seem to remember it not unzipping properly.  If I'm wrong on that,
maybe there has been one successful dump, but it's no longer available
for download, except maybe on bittorrent.)  I'd consider this pretty
important.  Obviously "Wikipedia is broken" would be more important,
but I assume you mean broken technically and not socially in which
case I'd say that doesn't seem to be the case.

Ordering the dumps so that failed ones get regenerated first is one
step that might help mitigate this problem, but ultimately a redesign
of the dump system is probably going to be required.

That's my view of the situation, for what it's worth (probably nothing).
(Continue reading)

Roan Kattouw | 1 Jun 22:06
Picon
Favicon

Re: Scream for mercy: breaking changes

Max Semenik schreef:
> Sorry, this is going to be a blatant rant...
>
> Request: http://www.wikia.com/api.php?action=query&list=categorymembers&cmtitle=Category:Wikia_categories&cmcategory=Wikia_categories&format=xml&cmlimit=500
> Result:
> <?xml version="1.0" encoding="utf-8"?>
> <api>
>      <error code="cmtitleandcategory" info="The cmcategory and cmtitle parameters can&#039;t be used
together" />
> </api>
>   
I hadn't thought about the fact that people might wanna make their code 
work for both pre-change and post-change APIs this way, which is kinda 
stupid. I'll remember to do this better in the future (in fact, 1.13 
will have a change towards that goal). It should also be noted that this 
is kind of a transition phase: the code has only been like this for a 
few weeks, after that cmcategory is ignored completely.
> The moral: please think of long-term consequences of your changes, if
> you change the way a piece of code works, at least (pleeeease!) allow
> people to fall back without much PITA.
>   
action=paraminfo (which IIRC was introduced before cmtitle) does a lot 
of that. Also, breaking changes are announced on the mediawiki-api 
mailing list, which you should really be subscribed to if you're 
developing an application that uses the API.
> And can this mistake be fixed at least in service releases for 1.12?
>   
Why would it? Just upgrade to 1.13 if you're gonna upgrade anyway. 
Service releases only ever address security problems.

(Continue reading)

Roan Kattouw | 1 Jun 22:19
Picon
Favicon

Re: [MediaWiki-CVS] SVN: [35681] trunk/phase3

btongminh@... schreef:
> Revision: 35681
> Author:   btongminh
> Date:     2008-06-01 17:58:27 +0000 (Sun, 01 Jun 2008)
>
> Log Message:
> -----------
> API: Add action=emailuser
>
>
> Modified: trunk/phase3/RELEASE-NOTES
> ===================================================================
> +* Added action=emailuser to send an email to a user
>  
> <snip>
> +		$this->getMain()->requestWriteMode();
>   
Do we really need requestWriteMode() here? Sending e-mails through the 
wiki doesn't really qualify as writing IMO.
> <snip>
> +			// FIXME: How to properly get a token?
>   
Add a gettoken parameter like action=block and action=unblock have.

Roan Kattouw (Catrope)
Simetrical | 2 Jun 00:30
Picon

Re: Scream for mercy: breaking changes

On Sun, Jun 1, 2008 at 4:06 PM, Roan Kattouw <roan.kattouw@...> wrote:
> Why would it? Just upgrade to 1.13 if you're gonna upgrade anyway.
> Service releases only ever address security problems.

They sometimes address more than that.
Simetrical | 2 Jun 02:06
Picon

Re: [MediaWiki-CVS] SVN: [35689] trunk/phase3/includes/Article.php

On Sun, Jun 1, 2008 at 7:47 PM,  <dantman@...> wrote:
> showDiff needs headers as parameters, even though they aren't needed here. Just give it two empty strings
to avoid a PHP error.

This is what parameter defaults are good for, yes?
Brion Vibber | 2 Jun 17:45
Picon
Gravatar

Re: [MediaWiki-CVS] SVN: [35681] trunk/phase3


Roan Kattouw wrote:
> btongminh@... schreef:
>> Revision: 35681
>> Author:   btongminh
>> Date:     2008-06-01 17:58:27 +0000 (Sun, 01 Jun 2008)
>>
>> Log Message:
>> -----------
>> API: Add action=emailuser
>>
>>
>> Modified: trunk/phase3/RELEASE-NOTES
>> ===================================================================
>> +* Added action=emailuser to send an email to a user
>>  
>> <snip>
>> +		$this->getMain()->requestWriteMode();
>>   
> Do we really need requestWriteMode() here? Sending e-mails through the 
> wiki doesn't really qualify as writing IMO.

"Write-mode" should apply to any action that has side effects (modifying
data, causing anything to be sent to a third-party, etc).

It *must* be possible to clearly demarcate between read-only data access
and stuff that does stuff.

For that matter I'm verrrrrrrry leery of any automated interface for
email such as this.
(Continue reading)

Brion Vibber | 2 Jun 18:58
Picon
Gravatar

Re: [MediaWiki-CVS] SVN: [35678] trunk/phase3


minuteelectron@... wrote:
> +* (bug 14370) When a grouppage-x message does not exist the entry on the
> +  ListGroupRights special page links to the main namespace page not the project
> +  namespace page.

This commit does the opposite of its description. Please correct the
comment to describe the *result* of the code change.

> -				$grouppageLocalized = $groupname;
> +				$grouppageLocalized = MWNamespace::getCanonicalName( NS_PROJECT ) . ':' . $groupname;

-- brion vibber (brion @ wikimedia.org)

Gmane