In T218456#5033420, @Addshore wrote:

@daniel I guess that is actually https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/466981/ for the retry strategy? Which doesn't appear to be merged yet.

Is it possible that you are seeing something fail during the retry, but the cause for the retry was something else?

That raises the question why that job fails.

The patch in question should only chnange the behavior of *failing* DataUpdates. If no DataUpdates fail, the new behavior should be exactly the same as the old.

In T191231#5032958, @Anomie wrote:

It also sounds like using DBAL, if it works out, would be only one piece of the whole task here? So some amount of additional development would probably be needed in any case to achieve the goals here.

In T191231#5028376, @Ladsgroup wrote:

Yes, That's my suggestion here, we can use DBAL as much as possible and write other parts we need.

In T198341#5025722, @BPirkle wrote:

Should compressOld.php and trackBlobs.php be in the same patch, as they both suffer from the " processing multiple blobs per revision" problem?

I would like to understand the problem better. If DBAL can do the schema changes, why can't we use it for the schema changes, even if it doesn't help us with the other parts of the issue?

Consistent CSS classes and element IDs would indeed be great. This could go along with documentation stating explicitly what guarantees are (not) given.

I would truly value having a proper API for accessing skins via gadgets rather than relying on CSS selectors.

In T198341#5024626, @Anomie wrote:

Here's one place where Daniel and I differ: I'd put most of these in one patch instead of having 10+ single-file changes.

What are everyone's thoughts on how to address making a consistent DOM across all skins?

In T191231#5023737, @Ladsgroup wrote:

In T191231#5019017, @Anomie wrote:

I note the review so far seems to have ignored that part of schema changes is checking the existing schema to determine whether the schema needs changing (MW currently does a somewhat crappy job of this).

Good point but I think we should focus scope of this ticket to unify and abstract away schema changes and not fix all of the issues with our current schema change system.

In T218183#5023026, @Jdforrester-WMF wrote:

We could use this in the PageLayoutFormatter stuff that MCR promises but hasn't yet delivered (see T209878). Right now in WikibaseMediaInfo we're having to do a series of regexs (:-().

In T193613#5023037, @Krinkle wrote:

This came up a while back in an internal meeting to revisit at some point. I'm not 100% sure whether the above is result of that already happening or whether there is something specific Daniel wanted us to do as a group.

@Skizzerz TechCom is trying to shift weight from IRC meetings to discussion here on phabricator. For this purpose, I suggest to copy the essential parts of the RFC from the wiki to the task description and writing an email to wikitech-l, asking for input. This would mean moving the RFC to "under discussion" on the RFC board for now. If it appears like there is consensus forming in the discussion on this ticket, we could perhaps move the RFC directly to last call without the need for an IRC meeting (or you could request an IRC meeting again, if you think it would be useful).

Accepted as an RFC

In T198341#5021347, @BPirkle wrote:

rev_text_id references that will be removed/refactored in this task:

• includes/Revision/RevisionStore.php (I'll touch only getQueryInfo(). All other references are either gated directly, or are in private functions with all calls gated)

includes/Revision/RevisionStore.php (I'll touch only getQueryInfo(). All other references are either gated directly, or are in private functions with all calls gated)

In T218127#5020863, @Anomie wrote:

In T218127#5020389, @Lucas_Werkmeister_WMDE wrote:

Then why are we even using the Message class for comments?

Because Wikibase wants i18n.

In T198341#5019920, @BPirkle wrote:

Question on one occurrence of these fields: is the maintenance script fixT22757.php still relevant?

To clarify: the intent of the new policy is to allow +2 access to be granted without community discussion or consensus building, upon request of trusted organizations. This does not imply a right or automatism for that request to be followed, it can still be denied or revoked at the discretion of the groups/roles mentioned in the policy. This means that membership in a trusted org's own group must not auomatically imply membership in the mediawiki group.

In T138708#5017062, @jeblad wrote:

Note that "click 'sign this' icon next to a statement" imply a fundamentally insecure and broken process. You don't sign something after it is uploaded, you sign it before and while it is still on your own machine. The JSON code snippet should be signed, and then a provenance for the statement including that snippet should be provided.

In T217881#5016597, @santhosh wrote:

/required?optional1=value1&optional2=value2

@Ladsgroup that seems quite promising! @Anomie, do you think this is ready for a prove-of-concept?

In T212482#5011281, @Anomie wrote:

@daniel: You should go read what I wrote in T212482#4841064.

The proposal states:

In T191231#5008431, @Ladsgroup wrote:

Reading the minutes of the meeting (sorry I couldn't join) I volunteer to do a basic research on Doctorine and how feasible it is to use. Is it okay with the TechCom and @Anomie ?

I put some related thoughts here: https://www.mediawiki.org/wiki/User:DKinzler_(WMF)/TechCom_MO#RFC_Facilitation

In T208768#4844079, @Tgr wrote:

Another thing that would be nice to figure out if there's an authz refactoring is T212639: Separate could do / can do / is doing permission checks in MediaWiki.

In T191231#5002737, @Legoktm wrote:

In T191231#5000704, @daniel wrote:

But discussion of this argument with regards to things other than databases is off topic here.

That makes no sense, why is it off topic? I don't think it's very fair for you to make a broad claim saying that we should remove support for non-free software in core that CI doesn't test and then respond to a counter-argument with "that's off topic".

Any of the patches require a +1 from all of people who contributed to the files otherwise will be legally in trouble (we can't just change license of a file)

In T191231#5000608, @Legoktm wrote:

Are you proposing to drop support for all calls to wfIsWindows() for Windows compatibility or any macOS workarounds? What about the few hacks that are there for proprietary webservers? Or the compatibility JavaScript we have for proprietary web browsers? None of those run through our CI.

In T191231#5000601, @Freakolowsky wrote:

So while it was fun working on this project i have lost track of the changes more than a year ago and I think it's best interest of everyone, that if you do not plan to keep it in the core and offer active support and maintenance from the core dev side, to just draw a line and drop the proprietary DB code from repos.

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.

In T214362#4970942, @Addshore wrote:

We can continue to generate constraint check data on the fly when missing in GETs and simply not put it in the storage.

In T215465#4970630, @Tgr wrote:

I guess there is no harm in writing this down but it happens even without a policy. Why would anyone not use service abstraction layers?
RedisConnectionPool and BagOStuff are at very different levels of abstraction, though.

What about higher abstraction layers like the XxxStore classes? Do we generally expect non-legacy code to use that?

@ssastry @Anomie is this done? Can the ticket be closed?

Sendmail integration could perhaps be tested on the beta cluster, but it would need manual patching.

Moving to backlog, since we are waiting for feedback from the RFC's author.

In T212521#4955458, @Catrope wrote:

I think this is a good direction, but I'm skeptical that we can, without a lot more effort, get rid of browser QUnit tests. A number of them depend on the MediaWiki environment (or literally on being in a browser) and it can be difficult or cumbersome to mock the MW environment and/or the browser environment (including the DOM) faithfully enough to make these tests work.

Here are a few ideas I have:

• provide a checklist for "when should I file an RFC"
• provide a checklist for "what should be in an RFC document"
• consider a last call with no feedback from outside TechCom failed. Positive feedback would be required for an RFC to be approved. This ensures that we solicit input from relevant stakeholders.
• make explicit that it is TechCom's job to solicit input from relevant stakeholders. Presently, we usually just hope that relevant people would read the radar email and react.

There is also the change that Marko proposed: require the RFC to be on phabricator, with the option to reference wiki pages; and require teh RFC discussion to be on phabricator, and discourage on-wiki discussion once discussion on phab has started.

I propose that getID() return null instead of throwing a NameTableAccessException

In T198557#4961828, @BPirkle wrote:

I'm happy to, but it appears that I cannot edit or claim the task.

In T198341#4962428, @BPirkle wrote:

Task description refers to "RevisionStore::newRevisionRecordFromRow()". Should that be "RevisionStore::newRevisionFromRow()"?

@Aklapper As far as I understand, the ultimate authority on who should have access to which of our repos is the CTO. Relevant angles on the issue can probably be provided by community engagement, legal, and HR. No idea what the best venue for discussion is, sorry...

All usages in core are gone. Now we should remove usages in extensions, at least in the ones WMF maintains. Dow we want to have a separate ticket for that? The current task description doesn't call for usages to be removed.

In T213318#4955592, @dbarratt wrote:

On the other hand (at least for those employed by the Foundation), this is real money that is being used by our "customers" (our donors), so I think it's important to know what our Product strategy is (I assume we have one, but I'm not aware of it). Without that, I don't know how we can make informed decisions about the platforms we should or should not support.

In T213318#4955519, @dbarratt wrote:

Are our target demographics (and the reason why we are targeting them) documented somewhere?

In T213318#4955529, @Smalyshev wrote:

Having both 1 and 2 at the same time would be awesome, but I guess I'd also be fine with saying "you can have 1 but lose support for 2 or you can have 2 but then you need to have install beyond 1". By which I mean, if the install runs only minimum LAMP stack, basic functionality supplied may not necessary include all necessary for supporting 2. That would not be perfect but I think still OK.

In T213318#4954287, @dbarratt wrote:

I wasn't aware of that. Could we update the Principles page to reflect that?

In T213318#4954262, @dbarratt wrote:

Another solution to this problem would be to require Docker and Kuberneties which are both free and trivial to setup (especially if we distribute MediaWiki and all of it's services with Helm)

@Smalyshev My understanding (which may be dated or incomplete) is this: there would be no PHP rendering, JS rendering would need to happen either in the browser on on the server. If the server supports SSR (e.g. for Wikimedia projects), you can read with a non-JS browser. If the server does not support SSR (e.g. on shared hosting), then you need a JS enabled browser to read.

In T205133#4951353, @kostajh wrote:

Let me know if you need help triggering a build for core or an extension. Once https://gerrit.wikimedia.org/r/c/integration/config/+/487880 is merged you should be able to create a patch which defines a sonar-project.properties file and then run "check experimental", but until then it's a more manual process.

@daniel, could you elaborate? I would like to create a sub-task, but I want to make sure that it's not my interpretation.

Where can I find the sonarquebe interface?

For the record, I'm currently evaluating sonograph (a desktop code analysis tool).

@daniel: sorry, I don't see how/why this should go on the releng-kanban board?

For reference: https://www.mediawiki.org/wiki/Wikibase/DataModel/Primer#Statements

In T28741#4942819, @jcrespo wrote:

As I said multiple times, hypernormalization would bring performance concerns- right now image and revision are handled on separate tables. Unless you also implement MCR sharding, we should try to make separate concerns into separate tables. Let's not convert Mediawiki into Drupal. That doesn't mean image could not be a "slot", but leave metadata to its own separate table.

In T28741#4940685, @Tgr wrote:

Also revision deletion would have to trigger file version deletion, but only if all revisions of the page that reference a certain version of the file have been deleted. That would have to be a whole new mechanism, and does not fit neatly into MCR which treats content objects as completely opaque.

In T28741#4939578, @Tgr wrote:

We need the file metadata for the current version of the file and basic info like size and mime type for the old/deleted versions, so we'd still need two tables, a page analog and a content analog.