On 06/06/2012 01:48 PM, David Gerard wrote:

is there any reason this list should be separate from mediawiki-l? At least it should be announced there.

Done.

Definitely interested! I have just finished some packaging for the Web App

Gallery

and would like to see (and add) some more flexibility to the installer.

Also, at SF

Hackathon, we had some discussion about the use of MediaWiki by outside parties, their issues and how to make their lives easier ;)

What did your discussions conclude?

Also I agree that this is a marvellous idea. I personally am unable to help, but it has my support 100%.

Thank you, Derric Atzrott

On 6 June 2012 19:20, Mark A. Hershberger mah@everybody.org wrote:

Speaking of testing, if anyone wants to help make sure the 1.19 release of MediaWiki included in the next Debian package (and probably the next Ubuntu package) is working, now is the time to test.  Debian will soon freeze their packages for their upcoming stable release. http://packages.debian.org/experimental/mediawiki

Last I recalled, the Debian MediaWiki was regarded as a pit of gratuitous weirdness of sufficient extent that it was all but deprecated, and any sane admin installs from the tarball. Is this still the state of play, and if not then what improved?

- d.

On 06/06/2012 02:29 PM, Chad wrote:

Well since we introduced a CLI installer ...

Side note: we re-introduced the CLI installer. I discovered this while tracking down ancient MediaWikis last week, an ancient version of MW (1.2?) used a command line install method.

I'm sure the current one is much better, though.

Mark.

On 06/06/12 20:29, Chad wrote:

Well since we introduced a CLI installer, it should make the process much cleaner for people packaging the wiki. I don't know what work has been done (if any), but the groundwork's been laid on our end.

The other big complaint we've had over time is moving stuff around to the typical Debian-esque locations (eg: putting LocalSettings in /etc). Don't know what the status is on that though.

-Chad

The problem in the past was primarily lack of cooperation from the packagers. I remember years ago that Aryeh offered help in some bug trackers (with little/no response).

I'd happily add hooks they needed to remove the need of patching for MediaWiki packagers, or including a script to move if that's what they really want.

Also, it'd be cool if downstream maintainers, that are keeping security patches for old versions, did it in MediaWiki repo. * Cross-distro work. No need to independently patch or copy the patches from other distros. * Just one repository, no need of stacked patch queues. * Availability in the upstream official repo. * Easy for us to review/fix in case we spotted something there. * We could commit the fixes for the externally-lts-maintained branched at near-0 cost when backporting some fixes.

Cons: * They need to request a gerrit account. * Yet another website for them to use. ?

IMHO that's a win-win.

On 6 June 2012 23:53, Mark A. Hershberger mah@everybody.org wrote:

To encourage cooperation, I started the low-traffic mediawiki-distributors last week.  I also asked Debian to work on packaging 1.19 instead of 1.18 for their impending freeze and have been working with them on their pkg-mediawiki-devel mailing list to do sane things with packaging. For example, today they were thinking about dropping wikidiff2 and (with Chad's input) I pointed out some problems with this.  So, someone has stepped up to take on the work.

This is most promising!

Absolutely.  This is one of the main reasons that I want to tag 1.19 as a LTS version -- so we can continue to do our work in Gerrit without a problem.

Oooh. How long do you roughly guess this means?

- d.

On 6 June 2012 23:53, Mark A. Hershberger mah@everybody.org wrote:

By the way, I noticed today that this page exists and is in sore need of updating:

https://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Debian_GNU/Linux

- d.

On 7 June 2012 16:26, Chad innocentkiller@gmail.com wrote:

We should kill those distro-specific pages and I've been saying that for years. Most of the advice ends up being rather generic, it forks the content, and they generally end up being abandoned and out of date.

*Not while they need to exist*. At the least, we need to document when a distro does something weirdarse. And this particularly applies to Debian, which does a pile of weirdarse things, to fit in with the weirdarse things they do with Apache. (Which the distro-specific page also needs to list.)

This will increase the probability that people like me will actually use the distro version rather than finding it a weird unsupported fork.

Of course, this requires a list of weird things Debian does. Is there such a list? (I see the MediaWiki page on the Debian wiki is proposed for deletion ...)

I'll start hacking that page to bits, on the assumption that it needs burning and starting over. What is Debian's mailing list for MediaWiki? I went looking for it and couldn't find it ...

- d.

- d.

On 7 June 2012 18:07, Mark A. Hershberger mah@everybody.org wrote:

On 06/07/2012 12:55 PM, David Gerard wrote:

...

I'll start hacking that page to bits, on the assumption that it needs burning and starting over. What is Debian's mailing list for MediaWiki? I went looking for it and couldn't find it ...

http://lists.alioth.debian.org/pipermail/pkg-mediawiki-devel/

kewl :-) Quick page here, with no pretensions to being a manual page. Links to the existing pages, all of which are indeed obsolete. I'll add to this as I go.

https://www.mediawiki.org/wiki/Debian/Ubuntu

- d.

On Fri, Jun 8, 2012 at 4:02 AM, Benjamin Lees emufarmers@gmail.com wrote:

On Thu, Jun 7, 2012 at 9:32 PM, Tim Starling tstarling@wikimedia.orgwrote:

...

I've long believed that MediaWiki should be considered a project of the WMF, on the same level as the wikis we host. Perhaps if we included donation requests on the download and installer pages then MediaWiki might be considered worthy of some attention in its own right?

If MediaWiki is currently underserved and would only receive attention from the WMF by virtue of its revenue generation (rather than its contribution to the WMF's mission), maybe it needs a separate (subsidiary?) organization to address the needs of third-party users.  Third-party users could donate money (or buy support, as with Canonical vis-à-vis Ubuntu) with the knowledge that it will be spent on the things they need done.

I've long mused out loud about this possibility, but I've become less certain over time that this is a good outcome based on what happened with Mozilla Messaging (spun out to work on Thunderbird, then folded back into Mozilla). The overhead of yet another organization wasn't worth it for them, and probably won't be worth it for us.

That said, I think there is a structural problem here, and I'm glad Mark has started the process of making release management something that has more volunteer involvement. The needs of running the Wikimedia family of websites are strikingly different than the needs of small websites who want a simple-to-install wiki. For that matter, they are very different than the needs of large websites that need wiki software, but consider it a commodity that they don't want to think about very much, rather than as their core product. Without the concerted involvement of people who understand and are good at balancing those concerns, we'll do a poor job of serving those folks. We'll be able to empathize and guess, and probably continue to do alright, but due to human+organizational nature, it'll probably never be as great as it could be.

I think MediaWiki as a standalone product suffers from some of the same problems as Bugzilla as a standalone product. Since both are byproducts of each organization serving a different mission than "make great general purpose software in category X", it's difficult to dedicate the kind of attention necessary to make both great general-purpose products, which is sad, because the world needs great general purpose products in both areas. In fact, even the areas that WMF could benefit greatly from, we seldom muster the energy (such as in the area of integration between the MediaWiki and Bugzilla akin to the much-touted integration between Confluence and JIRA).

In answer to Tim, I've lobbed the idea out there of MediaWiki-focused fundraising to WMF people outside of WMF Engineering, to somewhat lukewarm response in the past. It may be possible that the time wasn't right, or that my pitch sucked (it was admittedly not a fully polished proposal, but just a casual suggestion). That said, I suspect the people who deal with bringing in money generally have an even stronger Wikimedia-project focus than I'm expressing here. Standalone MediaWiki goals are not on the 5 year plan; not even on next fiscal year's plan, so it's hard to invest direct Wikimedia resources in this area beyond what we're already doing.

Just because a separate standalone MediaWiki entity isn't necessarily viable, that doesn't mean that we can't figure out how to make the release process a little more community-driven, so I'm glad there seems to be momentum around outside contributors participating more actively here.

Rob

On Sun, Jun 10, 2012 at 10:03 PM, Tim Starling tstarling@wikimedia.org wrote:

On 09/06/12 09:46, Rob Lanphier wrote:

...

I've long mused out loud about this possibility, but I've become less certain over time that this is a good outcome based on what happened with Mozilla Messaging (spun out to work on Thunderbird, then folded back into Mozilla).  The overhead of yet another organization wasn't worth it for them, and probably won't be worth it for us.

The two organisations would have to compete for senior staff, instead of the time allocation being internally managed. I'm not sure who would win.

The competition would be a fine thing. That's not the issue. It's the challenge of making sure the separate organization has the administrative ability to compete for the talent, which is a lot of overhead to set up.

We could do better than how we're doing now, if the WMF executive recognised it as something we can legitimately spend time on.

Actually, I believe WMF executives (depending on which ones you're referring to) think that some investment in this area is perfectly reasonable. Many of the tradeoff decisions you may be frustrated with are quite likely ones I've made personally (implicitly or explicity), so let's not focus on the unnamed powers-that-be.

What level of investment do you believe we should be putting in here? We're still planning to actually publish the tarballs and issue security releases. We might even get in there and fix some installer bugs as the crop up.

Sure, there's all types of work that would make MediaWiki for third parties great: * Making it so that Linux distro installs are great out of the box * Distro-native packages are created automatically for all extensions * Web-based installation and upgrading of extensions ala Wordpress * Much smarter default install/configuration of MediaWiki+essential extensions

However, even assuming we agree these are the most obvious things to work on (I suspect your list is different) we're far more likely to find motivated volunteers to make this all happen than we are to put a sustained effort on this stuff ourselves.

There are many things that benefit us *and* third parties: * Visual editor * Configuration database (i.e. make $wg* die in a fire) - slated for next year * Lua * Mobile support in MediaWiki core

I'm pretty sure that for every third-party-only feature idea we could come up with has a pretty compelling "benefit everyone" counterpart.

...

Just because a separate standalone MediaWiki entity isn't necessarily viable, that doesn't mean that we can't figure out how to make the release process a little more community-driven, so I'm glad there seems to be momentum around outside contributors participating more actively here.

The problem with community involvement is that the community is continually undermined by the WMF, which hires all the best volunteer developers and assigns them to work on things that benefit the Wikimedia wikis.

Unlike most for-profit ventures, we're not planning to expand indefinitely. Even if we did, reality would likely intervene to keep us from getting very far.

So, this is, at worst, mostlya temporary problem. Moreover, is it that much of a problem? It's not like those people are being forced to work here. "Careful, don't volunteer to develop on MediaWiki, or you might find yourself with a JOB that you get PAID for." :-)

Many of the volunteers that we hire were already working on Wikimedia-specific stuff. I know there are plenty of cases where volunteers have been working on third-party-specific features that we've hired, but it's not clear they would have had the time/energy to continue at the pace that they were sans a job from us (especially those that started as volunteers while going to school).

Doesn't the WMF have a responsibility to contribute back to the community from which it draws so much code and talent?

If we had a private fork of the code, I'd accept this as a criticism. We publish the source code, and I think we're generally pretty good at being mindful about how the software will work for third parties.

This also gets back to the structural problem I've referred to. Given the choice between: a. Something that benefits Wikimedia sites, but not third party sites b. Something that benefits Wikimedia sites and third-party sites c. Something that benefits third-party sites, but not Wikimedia sites

...we're frequently going to shoot for "b", sometimes only achieve "a", and rarely even aim for "c". It's just the nature of how we're set up, and it's also not smart for us to throw a lot of resources at "c". We have so much to do in category "b" alone to keep us busy for a very long time.

We do put some work into category "c", and we're not planning to pull back from that. My point is that this is an area that is very well suited to outside/volunteer work, since after all, outsiders will be far more motivated to do a great job than we will.

Rob

On Tue, Jun 12, 2012 at 1:58 PM, David Gerard dgerard@gmail.com wrote:

Motivated volunteers - e.g. people like me who use the tarballs - are probably the right people for the job 'cos we'd be scratching our itches. (I suppose this means I have to actually do things now.)

Bwahahaha...he falls right into my trap :)

So is there a good Bugzilla query for tarball-related matters? From hideous bugs to little papercut annoyances.

I'd say searching for "installer" bugs is one good list: https://bugzilla.wikimedia.org/buglist.cgi?list_id=122576&resolution=---...

Also, searching for "postgresql" is interesting: https://bugzilla.wikimedia.org/buglist.cgi?title=Special%3ASearch&quicks...

...or just looking at the PostgreSQL tracking bug for a cleaner list: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=384&hide_resolv...

The most important bugs (mixed in with lots of "good for everyone" bugs) are here: https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=runnamed&namedcmd=1.2...

Hope this helps!

Rob

On Thu, Jun 7, 2012 at 1:45 PM, Platonides Platonides@gmail.com wrote:

On 07/06/12 00:53, Mark A. Hershberger wrote:

...

...

I'd happily add hooks they needed to remove the need of patching for MediaWiki packagers, or including a script to move if that's what they really want.

Packaging is happening right now.  Look at the patches they're making here: http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/trunk/debian/patche...

A supported release shouldn't need any patching...

Let's look at them:

...

series         319     2 days          jmw     Don't use fix_invalid_sql_2.patch after all, it appears to be fixed upstream

Good :) (although 'it appears to be fixed' sadly means that it wasn't linked to a bug number in our tracker, from which it can be confirmed)

== fix_invalid_sql.patch == It is converting an INSERT IGNORE into an insert, following a bug report at https://evolvis.org/tracker/index.php?func=detail&aid=1377&group_id=... then moved to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615983

I haven't found it on our bugtracker.

Not explicity said on the bug report, the backtrace reveals it is happening with PostgreSQL backend.

DatabasePostgres::insert() contains code to deal with INSERT IGNORE since d5b71 (July 2008), and it seems to have been doing something even before. But it was missing in the insertSelect wrapper. That's bug 18909. https://bugzilla.wikimedia.org/show_bug.cgi?id=18909 which got fixed in r58179 (October 2009) and got into 1.16.

The backtrace in the 2011 bug does show that their DatabasePostgres wrapper didn't contain insertSelect() method (confirmed by reporting the bug against 1.15.3).

== mimetypes.patch == Changes $wgMimeTypeFile from "includes/mime.types"; to "/etc/mime.types", fair one.

== suppress_warnings.patch == Changes session_start(); to @session_start(); inside a pair of wfSuppressWarnings() wfSuppressWarnings(). WRONG. The patch is not needed.

Moreover, it was an @session_start() until Tim changed it to wfSuppressWarnings() in fbfb50 (March 2008). Previosuly it had been changed from session_start() to @session_start() by Gabriel Wicke in 90aadf7 (April 2004).

So this patch has been unneeded at least for 8 years :) (svn history suggests that it was created in 2010, not knowing that wfSuppressWarnings actually deals with php warnings)

== texvc_location.patch == Adds $wgTexvc = '/usr/bin/texvc'; to DefaultSettings.php (plus a comment).

Useless change. That's not enough to make <math> work. The math tag was been splitted to a separate extension in 1.18. So the user would *also* need to include the math extension in LocalSettings. That line should go in the extension package, not in MediaWiki DefaultSettings.php

= Summary = Out of 4 patches, only 1 seems to be 'useful'.

Even that, it could be moved to a different file instead of a core hack. Are they using something like a /etc/mediawiki.d/ folder?

So yes, I'm happy we are improving collaboration packagers <-> upstream.

Looking at the Ubuntu package[0], there's a *bunch* of other patches Have these all been upstreamed (some obviously have, and some are backports)

-Chad

[0] http://packages.ubuntu.com/quantal/web/mediawiki

The debian import freeze for ubuntu 12.10 is at july 5th[0]. They import testing and/or unstable, and they both have 1.15. The MediaWiki 1.19 package is in experimental currently[1], but I don't really know why. Maybe ask the maintainer to push the 1.19 package to testing?

[0] https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule [1] http://packages.debian.org/experimental/mediawiki

On Sun, Jun 10, 2012 at 9:50 PM, David Gerard dgerard@gmail.com wrote:

On 7 June 2012 18:55, Chad innocentkiller@gmail.com wrote:

...

Looking at the Ubuntu package[0], there's a *bunch* of other patches Have these all been upstreamed (some obviously have, and some are backports) [0] http://packages.ubuntu.com/quantal/web/mediawiki

By the way - that's still MW 1.15. Is it too late for Ubuntu 12.10 to pull MW 1.19 from Debian?

• d.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 06/07/2012 01:45 PM, Platonides wrote:

So yes, I'm happy we are improving collaboration packagers <-> upstream.

Thanks for looking at it! I'll make sure they see your comments.

Mark.

On 6 June 2012 19:31, Mark A. Hershberger mah@everybody.org wrote:

On 06/06/2012 02:25 PM, David Gerard wrote:

...

Last I recalled, the Debian MediaWiki was regarded as a pit of gratuitous weirdness of sufficient extent that it was all but deprecated, and any sane admin installs from the tarball. Is this still the state of play, and if not then what improved?

I've heard this many times and, as a result, I have not tried the Debian Package.  However, many people use their system's package. I don't know about you, but *I* don't want an awful Debian package to be people's first experience with MediaWiki.  We can improve this situation and now is the perfect time to do that.

I'd *like* their package to be suitable. We use Ubuntu 10.04 at work, and 14.04 or the corresponding Debian as of late 2014 are the hot prospects for next refresh. So for me testing the Debian version depends on how well the lone debs install on what's effectively an old version ...

- d.

8 Июнь 2012 г. 5:33:06 пользователь Tim Starling (tstarling@wikimedia.org) написал:

On 07/06/12 03:36, Mark A. Hershberger wrote:

...

The Foundation has made MediaWiki available for everyone and that's a great thing.   But Wikimedia's funding comes from donations as a result of requests on Wikipedia, not from distribution of MediaWiki, so they are rightly focused on their production cluster.

I've long believed that MediaWiki should be considered a project of the WMF, on the same level as the wikis we host. Perhaps if we included donation requests on the download and installer pages then MediaWiki might be considered worthy of some attention in its own right?

-- Tim Starling

MediaWiki is quite worth itself for many different projects. Additional funding could be received by expanding the commercial support of another MediaWiki-based projects. Also by making MediaWiki more CMS-like (despite the countless warnings that MW is not CMS, it becomes more and more CMS-like with every version, especially when bundled with extensions). With Router, Actions, also with non-wikitext page views in development (WikiData), semantic, ACL extensions and so on.

Perhaps MediaWiki could become something like Confluence but in PHP. I don't know.

Speaking of tarballs, I was quite surprised that non-recommended to use, non-tarball 1.18-wmf1 has 'mediawiki.jqueryMsg.js' ResourceLoader module, while newer and recommended 1.18.2 / 1.18.3 tarball has not.

Dmitriy

On 8 June 2012 02:32, Tim Starling tstarling@wikimedia.org wrote:

I've long believed that MediaWiki should be considered a project of the WMF, on the same level as the wikis we host.

It's quite definitely on-mission: it makes this form of knowledge-spreading normal and expected.

(Of course, just consider the perennial cries for WMF support from non-Wikipedia products ...)

Perhaps if we included donation requests on the download and installer pages then MediaWiki might be considered worthy of some attention in its own right?

A "help MediaWiki, donate to WMF" link next to the download button strikes me as entirely appropriate. I assume our fundraising includes some way to tell what links are on the path to a given successful donation.

- d.