static dump

So CR comments will still be available to read? Will it be possible to have URLs automatically redirect since they're still linked in a bunch of places and in git log?

I'm pretty sure we can do an Apache redirect.

In T116948#1762962, @Legoktm wrote:

static dump

So CR comments will still be available to read? Will it be possible to have URLs automatically redirect since they're still linked in a bunch of places and in git log?

Yeah. I'd say the actual approve/disapprove logs aren't useful, so only the revisions with actual comments on them need archiving.

I'd say we could automatically redirect easily enough.

I'm also curious if we could turn them into Phabricator audits (post-commit reviews) and copy the comments over there since we already have the SVN repo imported.

Change 298509 had a related patch set uploaded (by Awight):
Delist Special:CodeReview

https://gerrit.wikimedia.org/r/298509

+1
At the very least, let's delist it from SpecialPages... (patch)

Change 298544 had a related patch set uploaded (by Awight):
Delist Special:CodeReview

https://gerrit.wikimedia.org/r/298544

One downside to my approach is that, with less traffic, the extension will deteriorate even faster and we'll risk losing the ability to easily produce the archived, static dump.

Deteriorate even faster? Nobody's been making fixes for our version of it in forever...

Change 298509 merged by jenkins-bot:
Provide a configuration option to delist Special:CodeReview

https://gerrit.wikimedia.org/r/298509

We should probably set up some general-purpose redirects so catch all the old incoming traffic (of which there's a ton of links that will break).

Change 298544 merged by jenkins-bot:
Delist Special:CodeReview

https://gerrit.wikimedia.org/r/298544

Change 409290 had a related patch set uploaded (by Chad; owner: Chad):
[operations/puppet@production] Rewrite old Special:Code urls to Phabricator SVN clones

https://gerrit.wikimedia.org/r/409290

Change 409290 abandoned by Chad:
Rewrite old Special:Code urls to Phabricator SVN clones

Reason:
Too soon for redirects.

https://gerrit.wikimedia.org/r/409290

Hi. Unfortunately, this was an extension that I have used on my server. I came to reinstall it after a recent Ubuntu update caused my post-commit hooks to freeze up (and break Apache in the process), and saw the header on the extension page.
Is there any fork in development for this extension?

@BFeely file a task about that under the CodeReview project. It's just unused at Wikimedia, not deprecated or archived. In fact, I think @ashley uses it still?

At this point, I am re-deploying it on my newer MediaWiki instance, starting from scratch. I will see if the freezeups go away. I won't be able to test fully of course until I push my next commit.

As a heads-up, I have determined the freeze is not due to the extension but the svn command itself freezing up.

I just posted a test commit on my new CodeReview instance and it completed without issue, though I did have quite a few freezes of the SVN command during the initial import.

@BFeely: Hi and welcome! This task is about removing that extension from being available on WMF websites (but not about removing its code repository). Please file a separate task at https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=mediawiki-extensions-codereview about any problems with running that extension on your server - thanks a lot!

@Krinkle please file a new task for the Code-Stewardship-Reviews instead of hijacking this one.

I believe T222918: Put "shim" code for namespaces, logs, and log i18n into WikimediaMessages so we can undeploy extensions is not a blocker for this because CodeReview did not add any logs nor namespaces to mediawiki.org. The only thing it added were some API modules and the special page. The API modules will obviously break, and we're going to preserve the special page links via Apache rewrites.

In T116948#5808024, @Legoktm wrote:

I believe T222918: Put "shim" code for namespaces, logs, and log i18n into WikimediaMessages so we can undeploy extensions is not a blocker for this because […] we're going to preserve the special page links via Apache rewrites.

Ah, right, cool. :-)