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

[Romain Beauxis]

Hi,

As a former mediawiki, I can't help responding to your email.

I am not sure that ignoring reasonable concerns by sarcasm or
dismissal is such a great idea for a stable release. See for instance:

> DoS is doable much more easily, so that’s no concern here,
> but ok, then this is not upstreamable.

> Konqueror (standard browser on KDE environments) supports them, and
> our document management software is usable best via WebDAV.
(...)
> 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.

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

> Performance is impossible with a PHP web application, anyway, already.

Another point of concern is the following claim:

> This is a case of “Wikipedia” thinking vs. “Wiki used inside a specific en‐
> vironment, such as a company” thinking.

and, again:

> 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).

Which is curious when preceded by statements such as:

> These are the local patches I added in our company’s APT repository,
> where “people” means “the sysadmins”, and that’s, in the case of
> wikis, me. So this is no point.

It seems pretty clear that you are applying patches to Debian's
mediawiki package that come from mediawiki's use in your company. I do
not think that this is good for the whole spectrum of users that will
depend upon this package when the next stable release is published.

On top of that, going against upstream, patching parts of the code
that have been noted by them as potential security issues, or
switching the default DB engine to one that they told you is not fully
supported is not acceptable. Even less if you realize that all those
change are being rushed on the last weeks before the stable freeze
occurs.

You're the packager now, so at the end of the day it is your call. I
just wanted to voice my opinion when there is still a chance to avoid
some serious problems that will likely happen in the future.

Romain


2012/6/12 Thorsten Glaser <t.glaser at tarent.de>:
> 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.
>
>> >> +    - includes/DefaultSettings.php: add webdavs:// and file: support
>>
>> Apparently, NEVER EDIT THIS FILE at the top of DefaultSettings is not
>> enough? All such changes kill people's ability to painlessly switch to
>> tarball
>
> These are the local patches I added in our company’s APT repository,
> where “people” means “the sysadmins”, and that’s, in the case of
> wikis, me. So this is no point.
>
> Also, a packager is bound to change files. Even if this were not a
> local patch, I’d say, “so what? only packages are supported”. (But
> please, let’s not go there. I just wanted to present the few local
> changes I have for possible inclusion.)
>
>> give them. Or if packages are broken.
>
> Fix the packages, then.
>
>> 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.
>
>> >> +  * 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?
>
> Honestly, if MW does not work with PostgreSQL, either that’s going
> to be fixed or MW is abandoned.
>
>> > 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).