[Pkg-mediawiki-devel] Fwd: Re: MediaWiki patches in Debian.

[Platonides]

On 12/06/12 09:16, Thorsten Glaser wrote:
> On Mon, 11 Jun 2012, Platonides wrote:
> 
>>>> +  * debian/patches/tarent.patch: new
>>>> +    - includes/specials/SpecialAllpages.php:
>>>> +      raise $maxPerPage, $maxLineCount
>>
>> With a significant number of subpages available, this patch would
>> allow to DoS a wiki with simple F5 being constantly pressed.
> 
> DoS is doable much more easily, so that’s no concern here,
> but ok, then this is not upstreamable.

You may want to add a hook to make the change possible as an extension.

(...)
>> All such changes kill people's ability to painlessly switch to
>> tarball in case they need something fresher than what packages can
>> give them. Or if packages are broken.
> 
> Fix the packages, then.

Isn't that what we are discussing here?


>> Also, I strongly doubt about these protocols' support across different
>> browsers and platforms (especially file:), which means more nice ways
>> to shoot yourself on the foot.
> 
> Konqueror (standard browser on KDE environments) supports them, and
> our document management software is usable best via WebDAV. This is
> a case of “Wikipedia” thinking vs. “Wiki used inside a specific en‐
> vironment, such as a company” thinking. And if one of these links
> does not work for a user, that does not matter at all, either. The
> important thing here is that it works for most, and that it should,
> must, be included.

Sorry?, "if one of these links does not work for a user, that does not
matter at all, either", we like our features to work for everbody for as
much as possible.

Not really "wikipedia thinking". file:// links don't work in firefox,
chromium, midori, epiphany...
And even the browser you advocate (knoqueror) shows a nasty warning each
time you try to follow one of such links.

We do allow you as a site admin to customize that, by providing a
configuration setting for changing them.
You can configure it in your company as you wish, that's an highly
customized environment, so if you want to setup it that way, configure
as you wish. When their site doesn't work they won't come to bug me either.
But don't expect to make that the default for everybody. Specially since
"most users" in your company is verey different than in the outside.


(As I said, I don't see a problem with adding webdavs:// upstream)


>>>> +  * debian/control: prefer PostgreSQL over MySQL in Depends/Recommends
>>
>> PG is currently third DB in terms on MW support, significant number of
>> extensions don't support it. If we recommend MySQL for MW, pretty
> 
> MySQL is not a database, and the MW installations in FusionForge use
> the same database as the forge itself, just a different schema (one
> per project). Why do you try to force your limited world view on
> everyone?

MySQL *is* a database. It may not be pretty, you may not like to work
with it, but it is a db. And is the db which works best with MediaWiki.
FusionForge is obviously free not to support MySQL, and to force
MediaWiki to use PostgreSQL when they're jointly installed.


> Honestly, if MW does not work with PostgreSQL, either that’s going
> to be fixed or MW is abandoned.

Wrong. Most of our reusers use MySQL. Requests to use other DBs come
from people which already have another database system in place.
People installing just MediaWiki on their servers won't care much if
they use PostgreSQL or MySQL. And people using shared hosting are pretty
much locked with MySQL (not that PostgreSQL couldn't be offerted by the
hosts, but it's not happening).


>>> maxPerPage and maxLineCount by two orders of magnitude?  Is there any
>>> benefit to showing 30,000 pages on an index sub-page?
>>
>> Because someone wanted it and haven't thought about performance.
> 
> See my other reply for VALID reasons. Performance is impossible
> with a PHP web application, anyway, already. Again, your reply
> shows trying to force your limited world view upon everyone. I
> personally don’t mix well with that (strictly not speaking for
> FF, Debian, or my employer).

It depends on what you mean by performance. It can't compare with
hand-crafted assembly, a C application or static html. But you can get
very good results.
That MediaWiki is running on PHP the sixth-most-popular website, is a
sign to me that you can get good perfomance out of it.