As of T284917, the 'stub threshold' preference has now been removed. Should this ticket therefore be closed?

As of T284917, the 'stub threshold' preference has now been removed, so this ticket has become invalid.

A page is orphaned when it is not linked from anothers page content (or from within other pages). Links from navigations typically not treated as "used" or "linked" as that is a implemantation detail of the software, while an actual link from another page is a detail by the user of the wiki.

Do you think then that https://en.wikipedia.org/wiki/Special:WhatLinksHere/Main_Page should contain a list of all pages on the wiki (and similarly for other pages linked in the navigation)? I think it would be contradictory if it didn't.

My point is that I don't think it does qualify under the criteria as it is linked to via the navigation that is present on every page.

In T56902#6312338, @Legoktm wrote:

In T56902#6312316, @HappyDog wrote:

In T56902#6311472, @Legoktm wrote:

Since it got bumped again, this ticket is more of an idealistic ticket, expressing that MediaWiki should do cache invalidation perfectly...

I get that, but my point was that this is inherently an impossibility - even if this could be guaranteed for MW core, it could not be guaranteed for extensions (which are outside of your control) nor for any dev environment, where things are inherently unstable.

Why can't extensions be fixed? Why can't extension developers vary their caches on page_touched or adjust cache TTLs/disable caches when that isn't possible? Relying on users to click purge is a bug, just like any other broken extension functionality.

In T56902#6311472, @Legoktm wrote:

Since it got bumped again, this ticket is more of an idealistic ticket, expressing that MediaWiki should do cache invalidation perfectly...

As an extension writer, the purge action is massively, massively useful. It is not uncommon whilst working on the extension, to mess-up rendering, and without an easy way to purge the page, you're a bit stuck.

In T161066#5344075, @Krinkle wrote:

1. Simpler, cleaner DB schema.

The current tables are quite simple and straight-forward. I do not see a complexity argument here.

That may be true of a general abstraction layer, but we're talking about a specific abstraction layer for MediaWiki. Therefore, by definition, it is the choice of the application.

In T191231#5312337, @saper wrote:

A tiny example of what I mean is https://phabricator.wikimedia.org/T203850 - had we had an abstraction to handle JSON values in IDatabase, we wouldn't need fixes like https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TemplateData/+/521193 - JSON could end up as JSONB in Postgres and a BLOB in MySQL. Sometimes the abstractions would need to go much higher than this, providing a DB-specific implementation of it.

Otherwise we will end up one day with everything being varbinary or blob.

In T191231#5245501, @HappyDog wrote:

The code may tell you what it does, ...

This is getting somewhat off-topic, but:

In T191231#5245060, @Ladsgroup wrote:

I would argue5 lines worth of documentation comments per field, and probably an average of about 10 lines per table makes any sort of DDL to a documentation piece than a DDL, What is needed is updated documentation in mediawiki.org and clear links of those in the DDL.

Another note: MSSQL has been broken for a while now (Look at my above comment)

Further to my above comment, about my personal use-case, I have found that there are public links - even from prominent pages on mediawiki,org - that are currently dead.

From my perspective, tags are fine.

In T191231#5058412, @Ladsgroup wrote:

• Nothing in mediawiki changes except we replace *.sql files with *.json ones that are DBMS-agnostic (so one per schema change, and one central tables.json for fresh installations)

Maybe I'm confusing things - when I use 'add existing panel' then all the old versions of the panel are still listed, currently. But I don't know how that maps to the suggested workflow - I don't really understand the difference between a query and a query panel.

Sounds reasonable (taking you at your word - personally, I can't think of any reasons why immutable search results are a good idea).

Resolving as complete. Thanks for your help, @Legoktm.

In T191231#4997771, @daniel wrote:

In T191231#4689449, @Legoktm wrote:

Wikimedia CI as a matter of principle (backed up by the terms of use) isn't going to support any non-free software regardless of whether it's installed locally or connecting over the network.

Not supporting CI for any non-free software, but having support for that non-free software in core, seems contradictory. We should have both, or neither.

Why was this declined?

I'm sorry, but that is a totally unacceptable answer.

In T178844#4965750, @Jdforrester-WMF wrote:

Instead of registering your action as a function called from the hook, you register it as a class via the global. There are a fair number of examples of this in code search.

I notice that 1.32 has now been release, but this bug has not been fixed. That means extensions will be broken without any upgrade path being supplied.

In T191231#4674637, @Anomie wrote:

In T191231#4478780, @HappyDog wrote:

There is also this RFC related to abstract schema definitions. Let's call it Proposal #3 (even though the page has been around since 2012): https://www.mediawiki.org/wiki/Requests_for_comment/Abstract_table_definitions

Let's not have to write a parser for a custom format. Other than that, there doesn't seem to be anything there that isn't already in Proposal #1.

Adding to 1.32 release, as it is imperative that there are upgrade instructions before the hook is formally removed.

Please, please, please can you make sure that T178844 is resolved before 1.32.0 is released.

Hi Reedy - sorry not to reply to this sooner. I will take a look at the example you've posted (which I would never have found on my own!) and see if I can get things working.

That seems like a poor design decision. It means there is no way to correct mistakes or adapt to changes.

In T191231#4479734, @saper wrote:

Are we really so nicely abstract on the DML level? My impression was this is a MySQL app and other databases apply workarounds to get rid of MySQL-specific things sprinkled around the code.

There is also this RFC related to abstract schema definitions. Let's call it Proposal #3 (even though the page has been around since 2012): https://www.mediawiki.org/wiki/Requests_for_comment/Abstract_table_definitions

Any word on this? This is preventing me from upgrading my extensions to support the latest MediaWiki versions.

In T191182#4278111, @EddieGP wrote:

The proposal here is to stop using differential.

Removing myself - I created the original manual page for this setting, but all the information was drawn from other sources. I have no direct knowledge about this setting, so can't help with this.

As mentioned in T190363, this is also really important for extension writers who want to support more than the current latest-and-greatest versions of MediaWiki. We need to have an easy way to locate old releases in order to check whether a given feature we would like to use was supported.

The way I see it, there are three areas of interest (which overlap slightly):

Trying to fit all work by all people into a single workflow seems counterproductive to a goal of mine which is to make technical contributions easier

Depends what you mean by 'different projects'. If they include core extensions, or tightly-coupled things like Parsoid, then it adds up to a lot of inconvenience!

I think this is a great idea. There should be clarity and consistency in how/where development takes place.

WikiDB is now very mature, and I think it covers everything in the original request, and more besides: http://www.kennel17.co.uk/testwiki/WikiDB.

Apologies if you found my comments condescending. That was not the intention.

In T119908#3888823, @labster wrote:

It's not as big of a a barrier to contribution as you think. Generally, when I want to commit something on a project hosted by WMF, I push a commit to somewhere else like Github, and then ask someone else who understands Gerrit to merge it. Usually, this is the extension developer, and from there they can either do git remote add or download a patch file.

In T119908#3887916, @EddieGP wrote:

In T119908#3887786, @daniel wrote:

Is there still commitment to doing this? Is this RFC looking for approval?

No:

In T86081#3684818, @MaxSem wrote:

With HHVM ditching PHP compatibility, we're going in the direction opposite to this task.

Also note: gerrit is getting a new ui with gerrit 2.14 which has been released. They are calling it polygerrit and can be viewed at https://gerrit.git.wmflabs.org/r/?polygerrit=1

This should be declined as we will eventually go with differential but that's currently on hold.

In T58269#2012911, @Rcdeboer wrote:

In T58269#2006679, @HappyDog wrote:

One of my extensions seems to be triggering this, and I have no idea what to do about it.

Could you do me a favor and see whether disabling the lines in OutputPage.php I just reported in my other comment fixes your issue? Yours may be entirely unrelated, but it's worth a shot.

PS - What happened here:

One of my extensions seems to be triggering this, and I have no idea what to do about it.

In T118932#1945645, @hoo wrote:

I agree that we should target 5.5.9 as minimum.

Well, I just Googled for Wordpress, and they have a pretty great requirements page: https://wordpress.org/about/requirements/

In T118932#1834586, @Reedy wrote:

In T118932#1834581, @HappyDog wrote:

Your stats are out of date, FWIW according to Wikipedia.

No they're not. They're bang up-to-date. I don't know where WP sourced the information, but different methodologies give slightly different results so there will be some variation. Still, third is still pretty high up the list!

https://redmondmag.com/articles/2015/04/08/windows-xp-usage.aspx

It's either 8th April or the 4th August. One way it's nearly 8 months out of date, the other way it's nearly 4

Your stats are out of date, FWIW according to Wikipedia.

@hashar, support for older PHP versions by various operating systems/distros/other apps was discussed in a fair amount of detail.

The number of attendees was half the number of subscribers here.

I'm very disappointed that the decision seems to have been made without any regard for any kind of usage statistics, beyond WMFs requirement for 5.5 as the upper bound.

In T118932#1818717, @JeroenDeDauw wrote:

FYI: SMW will drop 5.3 and 5.4 support in its next mayor release. Possibly 5.5 as well, though that has not been decided yet.

I'm not sure they are duplicates. I was about to add the dependency on T86081 that comes from that bug, but that ticket shouldn't block a decision being made - it should just block actually putting the decision into action. If we decide to drop 5.3 there will be a requirement to finish the internal WMF migration before actually adopting this as policy (updating docs, allowing > 5.3 code into the codebase, etc.), otherwise things will break.

Out of curiosity, is there anything really evil about traits or are they just out of scope for this RfC?

I think WikiApiary is a good start for stats, but I'm not sure whether it should be the only data source that is considered.

We want to diminish the risk of confusing them by mixing the content relevant to the with the rest of mediawiki.org.

I agree with QGil and Ricordisamoa - skin per page is completely contrary to where consensus seems to be going. You might just about get sufficient support for a separate skin for the namespace as a whole (though there is quite a lot of opposition, too), but I doubt skin-per-page is going to be approved by the community, based on comments made so far (assuming, of course, that the MW community is going to be listened to).

I don't see the benefits to tying ourselves to Vector for this well delimited namespace in mediawiki.org.

I think that splitting these conversations up is a very sensible idea.

Hi - yes, I know that post. I agree with some of it.

A couple of points: