There is no quantitive data. The pingbacks are horribly inaccurate, especially insofar as enterprise installations of MediaWiki are represented. Corporate firewalls as well as an attitude of sysadmins to not share installation data by default both cause installation numbers (across all database systems) to be largely underrepresented. In any case, I know personally of at least 20 companies and government organizations using MediaWiki with mssql or that have used MediaWiki with mssql, and I would not be surprised if the true number was in the hundreds. Yes, this isn't much compared to MySQL installations, but it is a non-negligible number.
Fri, Sep 14
Fri, Aug 31
Jul 30 2018
I think the majority want MSSQL moved out of core, but let's bring in some more voices into that.
Declining this task, as the structure to do this isn't nearly in a workable state. Moving out the Database class is about 10% of what is required here; the installer/updater need to work (keep in mind that LocalSettings.php doesn't exist when the installer is being run, yet that needs to be able to load the abstraction and schema). And, if the support isn't in core, then people will simply start using more and more MySQL-specific features making it impossible for an extension to work anyway.
Jul 25 2018
A bot named WikimediaDevelop was recently k-lined from freenode by Sigyn due to sending a channel notice. Need to appeal the k-line (easy) and configure the bot to not send channel notices (just message the channel regularly instead).
Jun 25 2018
Jun 11 2018
Jun 2 2018
In my opinion we should pick one datatype and standardize on it. Migrating existing columns to binary or utf8mb4 should be doable with a maintenance script, and these sorts of migrations and changes seem within scope for the schema abstraction RFC as part of the concerns there is taking the disparate environments of existing installs and standardizing them (although primarily with non-MySQL dbmses, but making MySQL focused on one and exactly one schema seems good as well).
May 16 2018
Modern C++ (aka C++11 and later) can be memory safe and free from buffer overflows as long as good practices are followed -- avoid usage of raw pointers (use unique_ptr and shared_ptr instead), make good use of const reference and move semantics instead of passing things by pointer between functions, allocate on the stack instead of the heap where feasible, and use RAII patterns to encapsulate OS resources like file handles. The main issue is the layer in between the PHP API and the extension, as the PHP API is raw C. Both C++ and Rust can have issues here if that API is misused, so Rust doesn't bring you any advantages in that regard.
Apr 6 2018
Jan 30 2018
Jan 29 2018
Dec 3 2017
The user's registration date and edit count are maintained on import, and existing edits are reattributed (so the maint script which recounts edits won't wipe things). As such, if they meet autoconfirmed criteria on the new wiki, they should be receiving it automatically. I see no reason and have no desire to manually add autoconfirmed as an explicit group in the db due to this.
Added $wgMediaWikiAuthImportWatchlist config var in v1.0.0
Nov 25 2017
Nov 17 2017
New permission mwa-createlocalaccount can be leveraged for this purpose, now in 0.10.0.
Nov 15 2017
Nov 9 2017
Yep, I'm aware of the old one (I was one of the mods there towards the latter years of its life and had thousands of posts as well as wrote a few how-tos). Didn't realize SO was also CC-BY-SA so that was my bad 😊.
Nov 8 2017
As an FYI, I just launched a new site https://mwusers.org which is relevant to this discussion. It's still new and unproven, so I think marking it as the "official" site right now would be largely premature, but I wanted to throw it in for consideration down the road. Unlike Stack Overflow, my forum has the advantage of the content being licensed under CC-BY-SA so that relevant bits can be imported into mediawiki.org's documentation.
Oct 25 2017
Now uses AuthManager as of v0.9.0 (will be submitted to gerrit in the near future)
No longer requires core patches as of v0.9.0 (will be submitted to gerrit in the near future)
Jul 23 2017
Patch pending review at https://gerrit.wikimedia.org/r/#/c/367128/ -- would appreciate if someone could give it a look over
Jul 25 2016
Do not assign tasks to other people without asking them first. If you want to work on this yourself then feel free to submit a patch.
May 2 2016
As of 1.23 the mssql layer used the native drive (sqlsrv), so this has actually been fixed for a very long time :)
Apr 28 2016
Apr 25 2016
Fixed in 1.27 / https://gerrit.wikimedia.org/r/#/c/285139/ (still pending merge, so don't close this task just yet)
Mar 25 2016
Dec 14 2015
- Keep it on-wiki and don't bother having a copy in git/gerrit at all, or perhaps have a placeholder RELEASE-NOTES that offers a link to its location on-wiki
Sep 28 2015
To get a gauge on the sheer number of wikis you'd be impacting by this decision, I reached out to Softaculous to ask for statistics on how many MediaWiki installations were made by them. Softaculous is a one-click installer script found on a number of hosts, as it reduces the friction and knowledge required to install and update applications. Their support team offered this as a response:
Sep 26 2015
Cut the offensive tone @MaxSem, that was incredibly uncalled for. I spent at least 100 hours developing and testing making sure that it worked for far more than just "basic stuff" when I submitted the patch for support in 1.23. Does it work beyond 1.23? No, I went into it only planning to release updates for LTS releases of mediawiki because I don't get paid for this and there are far better uses of my time. I'll update it for the next LTS version, and the LTS version after that as well, and so on until the internal politics and abrasive behavior around here drive me away from mediawiki permanently (which may end up happening sooner rather than later at this rate; so much for what whole Code of Conduct thing).