Re: taking forever for MediaZilla registration e-mail to appear

David Wendt wrote:

> I've a question, I registered an account on MediaZilla, and for some 
> reason the e-mail that has my password is... not appearing. Anywhere. 
> I keep checking my POP server (yes I did put in the right address), 
> but Thunderbird says there's nothing on the server. So, did the server 
> forget about my registration or does it just take a long time?
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l <at> wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
Forget that, all my e-mails are appearing in my server. I guess it was me.

Re: taking forever for MediaZilla registration e-mail to appear

On Nov 30, 2004, at 5:41 PM, David Wendt wrote:
> Forget that, all my e-mails are appearing in my server. I guess it was 
> me.

The e-mail server occasionally gets backed up; if nobody notices it can 
take a few hours to get it unclogged and send the mails out again. (I 
just unclogged it about a half hour ago.) We're trying to figure this 
one out; maybe an upgrade to postfix is required...

-- brion vibber (brion  <at>  pobox.com)

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Re: Database abstraction layer

Evan Prodromou wrote:
> I guess I'm mainly worried that this huge change was made without
> considering other options. There wasn't any discussion on this list that
> I can find, and the change isn't documented on meta, AFAICT. Publishing
> design decisions can be a good way to avoid second-guessing by people
> like me after the code is written.

What huge change? Like Brion said, DatabaseFunctions.php has existed 
since the dawn of time. I switched it to OOP to support multiple 
connections, I probably announced that in a post about slave servers and 
load balancing. Then Domas implemented PostgreSQL support as a subclass. 
Domas' work doesn't preclude the use of a DB abstraction layer, in fact 
his work in identifying the use of MySQL-specific features would be 
invaluable should we attempt such a thing.

As far as I'm concerned, DB abstraction is a courtesy to low-traffic 
non-Wikimedia users. The queries we use, and the schema, should be 
optimised for MySQL. My focus has been on emulation of MySQL features, 
not replacement by standard SQL in the bulk of the codebase. INSERT 
IGNORE is the best example of this.

-- Tim Starling

Re: Re: Database abstraction layer

On Wed, 2004-01-12 at 13:24 +1100, Tim Starling wrote:

> > I guess I'm mainly worried that this huge change was made without
> > considering other options.
> 
> What huge change?

Replacing all the SQL strings in the code with function calls into a
much-expanded database object.

> As far as I'm concerned, DB abstraction is a courtesy to low-traffic 
> non-Wikimedia users.

I'm not speaking as a non-Wikimedia user; I'm speaking as a member of
the MediaWiki development team we're both on.

I'm just trying to get across the point that even the World's Greatest
Programmer can benefit from soliciting the ideas of others in a forum
such as wikitech-l. It only takes a few minutes, helps the developer
focus their own thoughts, and could avoid a lot of work for the entire
development team writing, testing and debugging functionality readily
available in an Open Source library. We all benefit from a better
product that comes from sharing our ideas.

And if you fix your ideas in writing, you don't get dumb questions
later. Or, y'know, fewer dumb questions.

Anyways: sorry if I touched a nerve. If it helps, I think this is a real
nice piece of code, and it really cleans up the rest of the codebase.

Re: Re: Re: MultiHosting from single source

> There's no need to change index.php, this is what LocalSettings.php is
> for. (Nor do we need more than one of it, as site-specific setup logic
> happens under it and its includes.)

Maybe I am confused, but as I understood it, the wikipedia site itself is 
running with an alternative configuration, described here:

http://wp.wikidev.net/Wiki_farm

and using this additional configuration
http://wikimedia.org/conf/

and presumably, a modified index.php or LocalSettings that initializes and 
uses the SiteConfiguration object.  The 1.3.8 download does not do 
ordinarily use of the SiteConfiguration object.

But, I think I didn't do a good job of explaining the difference between 
running multiple sites all with the same policy versus running multiple 
sites with different policies.

As a very typical use case, imagine trying to power two (or more) mediawiki 
instances on the same server that are branded completely differently. One 
way to model this is for each of them to have their own skin, which can be 
worked on separately and independently by webdesign specialists.  Creating a 
custom phptal skin requires extending the SkinPHPTal class.  If you are 
managing custom code for two different installations, they really should be 
in their own versioned repositories, not intermingled.

What's the alternative?  Hacking the Skin.php or SkinPHPTal.php directly in 
the single, server-wide, software_home?

Re: Database abstraction layer

Evan Prodromou wrote:
> On Wed, 2004-01-12 at 13:24 +1100, Tim Starling wrote:
> 
> 
>>>I guess I'm mainly worried that this huge change was made without
>>>considering other options.
>>
>>What huge change?
> 
> 
> Replacing all the SQL strings in the code with function calls into a
> much-expanded database object.

I discussed it on IRC, with Brion and anyone else who was around. 
Replacing SQL strings with function calls was done for these reasons:

* Safer quoting, avoidance of SQL injection attacks
* Easier table prefix support
* Simpler interface with PHP data structures, like wfGetSQL() before it
* DB abstraction, specifically:
** Filtering or emulation of unsupported options to queries such as DELAYED
** Emulation of MySQL-specific queries such as REPLACE
** Table name quoting

If you want to be in on these decisions you should hang around on 
#mediawiki more. Discussing things by email is tedious and slow.

-- Tim Starling

Re: Re: Database abstraction layer

On Wed, 2004-01-12 at 17:56 +1100, Tim Starling wrote:

> If you want to be in on these decisions you should hang around on 
> #mediawiki more.

My point isn't that I want to be in on the decisions. My point is that I
want us as a development group to make better decisions, and I want us
as a group to communicate those decisions well to present and future
members of this development team. I know from experience that if we do
this, we will make better software, and our job will be easier, to boot.

>  Discussing things by email is tedious and slow.

Discussing things on IRC is ephemeral and the discussions are hard to
point to later.

~ESP

--

-- 
Evan Prodromou <evan <at> wikitravel.org>

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Re: Re: Re: Re: MultiHosting from single source

On Nov 30, 2004, at 10:50 PM, Jonah Bossewitch wrote:
>> There's no need to change index.php, this is what LocalSettings.php is
>> for. (Nor do we need more than one of it, as site-specific setup logic
>> happens under it and its includes.)
>
> Maybe I am confused, but as I understood it, the wikipedia site itself 
> is running with an alternative configuration, described here:
>
> http://wp.wikidev.net/Wiki_farm
>
> and using this additional configuration
> http://wikimedia.org/conf/

Yes, that's a description of how we use MediaWiki with a single copy of 
the source to run several hundred wikis with varying configurations.

> and presumably, a modified index.php

Nope.

>  or LocalSettings that initializes and
> uses the SiteConfiguration object.

Yes! That's the purpose of LocalSettings.php; to load all 
customizations.

>  The 1.3.8 download does not do
> ordinarily use of the SiteConfiguration object.

The common case is a single installation on a hosted account where 

REL1_4 branched

I've created a REL1_4 branch in CVS. To update your existing HEAD 
working directory:

   cvs up -dP -r REL1_4

To pull a fresh copy (as a developer):

   cvs -d:ext:username <at> cvs.sourceforge.net:/cvsroot/wikipedia \
     co -r REL1_4 phase3

(If you're using Sourceforge's anonymous CVS server it may take a few 
hours before the update goes through there.)

The release branch frees up CVS for more experimental code, while 
REL1_4 should now concentrate on getting what's already in there stable 
and working. We'll tag and release a few beta versions over the next 
couple of weeks, with a 1.4.0 final release when the main things are 
ironed out.

If we make additional 'big' changes before release, they should be done 
in HEAD first. Bug fixes should naturally go both in REL1_4 *and* the 
head branch.

As far as future scheduling:  I would very much like us to start 
getting releases out on a faster schedule, each with tighter changes 
more concentrated on particular areas than the swamps we've done in the 
past. Aiming for 1.5 in February would be nice (~2 months from 1.4). 
We'll do some planning on future directions at the 21C3 conference in 
Berlin in late December.

Account lockout

My account has a guessable password and some idiot has used my account for
some low-grade idiocy (blocked JoeM and put some dumb text on the "Xero"
page, both reverted quickly) and changed the password. I didn't set the
email to the account. Could someone change the password/lock the account and
set the email to "cunctator <at> kband.com" so I can reset the password?

Thx.