I thought about it yesterday. We should just bite the bullet and get git-lfs support for Gerrit. This is possible and is the best long-term solution. It keeps us from being tied into git-fat (unsupported and effectively forked by us), rsync, or archiva.

Thank you, that's what I sort of remembered from when we moved it, and it makes more sense now. I'm fine with leaving it in group0 to be honest.

Care to elaborate?

Added again, flushed caches. (Sorry for delay, was on vacation)

In T172927#3531720, @Legoktm wrote:

• The tarball is built in an isolated environment in production, so we can't run composer during tarball build.

Disabling account creation is easy and can be done immediately and I think would be a decent stopgap for the current issue. Titleblacklist should be able to handle the editing issue, I think. Could probably add some new group if desired to simplify things?

In T172927#3525339, @MaxSem wrote:

Do we really need to use mediawiki/vendor for tarball? We can just install prod dependencies from composer.json.

Meh.

In T164898#3309866, @tstarling wrote:

T37043 can be fixed with about 5 minutes' work. Just cherry-pick the SearchPostgres.php change into master so that it's not tied to that broken attempt at unit testing. It's already been tested manually and is a clear improvement on the existing code. I'd be happy to give it +2.

In T164898#3531217, @Turnstep wrote:

Rename tables mwuser to user, and pagecontent to text. Table names are always quoted, so
it doesn't matter if they are keywords. A table prefix can be used if desired to avoid having
table names that are keywords.

It does matter as far as every other thing that is not direct MW code (e.g. SQL files, accessing via psql or other interface). So +1 for avoiding keywords even if that means another table prefix (can someone expand on what exactly that would mean and where it would be set?)

In T170632#3526952, @Legoktm wrote:

https://gerrit.wikimedia.org/r/#/c/372097/ is a cherry-pick for T173394: Fatal error from AntiSpoof when logging in .

I can confirm it's unused on mediawikiwiki. Stupid experiment: I pushed for installation and I pushed for its removal.

In T172146#3493172, @daniel wrote:

In T172146#3490130, @demon wrote:

Is that actually true? With the underlying RFC, couldn't a wiki potentially make NS_USER not have a corresponding talk?

Not legally. $wgCanonicalNamespaceNames is private and is not supposed to be changed per install. Anything defined there can be assumed to be the same on all installs.
In fact, we currently guarantee talk namespaces for all default namespaces. But the User namespace is special, in that linking to the user talk page is very common. So it is useful to explicitly guarantee that the User_talk namespace is always defined.

Seems legit

I'm curious about usage stats on this preference generally, at least across large.dblist.

More like just shy of 6%

chad@notsexy /a/ops/mediawiki-config/dblists (master)$ cat flaggedrevs.dblist | wc -l
      53
chad@notsexy /a/ops/mediawiki-config/dblists (master)$ cat all.dblist | wc -l
     909

This is fine by me. @mmodell? @greg?

In T172146#3487982, @SamanthaNguyen wrote:

Removed SiteScout from the list as those 2 cases are false positives (those calls are getting the user talk)

In T171643#3485107, @Marostegui wrote:

After solving the subtask, we could run the following query on all wikis:

I would prefer if this gets run by a maintenance script using mediawiki, we normally do not touch data directly on the databases as it can be dangerous and create inconsistencies.

If we want to do it in two batches as you're suggesting, we can amend my patch to do so. Let's follow up there

The idea I was noodling the other day was kind of a generic rsync service that "anything" (tbd how wide anything means) could hit. This would allow us to publish files to a single location for all git-fat users rather than having each service having to setup their own (and potentially set up multiple ones for various testing/staging environments as well).

Just wanting to clear up a little bit of FUD, since there seems to be this misconception that git-fat does not work in labs....

In T171619#3475026, @Halfak wrote:

but it's not undoable.

What?

For checking in, yes without issue (that's all client side). However fetch/pull requires rsync access to fatten the blobs (internal term is hydrate).

We can also safely normalize the back compatible version to the new one 😊

In T171643#3472259, @matmarex wrote:

The only valid values here are monobook, vector, cologneblue, modern and the various minervas (which should be merged, see T171644: Clarify minerva preference name).

That's not true. '0' and '2' are also valid values, mapped to Vector and CologneBlue by Skin::normalizeKey().

I did not use that branch. I didn't even know it existed.

Reception123 is not missing from the database.

I don't want to backport this behavior. It's inconsistent, and the tags will be all wrong. The logic to build a particular release--they're repeatable--operates on major version numbers. Adding the minor version numbers for 27/28 special casing would complicate things needlessly. Please abandon those changes.

In T171342#3461960, @Dzahn wrote:

The other deployers would still have to decrypt the encrypted files to actually see content though, so it's not really sharing secrets with them unless we don't trust GPG by itself.

In T171342#3461910, @MoritzMuehlenhoff wrote:

There's really no need for a separate VM, a pwstore is just a git repo with a few megabytes of data :-)
I suggest you simply use a /srv on e.g. tin (or some other host where anyone from releng has access to).

The current ops pwstore is on neodymium which is a restricted host, so we can't easily share this.

In T171342#3461714, @Dzahn wrote:

actually, it may even make sense to do it all in a single pwstore repo and just add a new group for releng.

I was under the impression we couldn't do port-based LVS to the same domain. But I'm gladly willing to be wrong ☺️

Thanks for all the work on this yesterday folks. We're resolved, so I'm guessing ok to move forward on wmf.10 for wikidatawiki?

Well perhaps the issue is in the underlying JsonConfig that this is based on (which also has its share of issues filed....)

This really really needs fixing by someone who owns the extension. This has been going on for ~2 months now.

Okie dokie, misunderstood :)

In T169376#3451494, @Marostegui wrote:

s3 - table is empty in all the wikis where it exists from the s3.dblist.

To be clear: it's not that this doesn't provide us some non-zero performance improvement. I just want to measure what kind of difference it makes in the world of HHVM. If it's needed still, fine. But if it's not, it's a weird legacy thing that I'd love to jettison (as it causes no end of headaches & confusion for people).

For CentralAuth? Eh, if you think it's necessary. I say just toss the fix over the wall and e-mail wikitech-l like usual. It's a pretty WMF-centric extension.

Count me in for Horizon over continuing to use Wikitech. Everything is moving to Horizon, it makes zero sense to have two places for this.

Is anything left for this?

In T159403#3069340, @EBernhardson wrote:

Rather than specializing the prefix: operator with special syntax, i'd prefer we get our query parsing into a sane state where we can specify prefix:foo OR prefix:bar

• Make path configuration file for conftool configurable (also lets us disable the functionality)

• Fix line too long error

• Reuse existing node objects rather than constructing new ones
• Catch failures, and return the success/failure scenario to callers, it's on them to resolve as desired

@Ottomata Staff member w/ NDA? Jfdi

Done

1.30? We haven't even begun yet. Go ahead