I think more went inactive generally than gave up on this specific issue. But still, we really need to do better here.

The grid engine has been shut down, so I'm closing any remaining migration tasks as Declined. If you're still planning to migrate this tool, please re-open this task and add one or more active project tags to it. (If you need a project tag for your tool, those can be created via the Toolforge admin console.)

Hi @Dereckson, we are going to be stopping any Grid processes for any tools that did not migrate yet to kubernetes tomorrow, I see that there's still a lighthttpd process running from your tool.

This is still blocked on https://gerrit.wikimedia.org/r/c/operations/puppet/ /631888. It's probably fair to assume the volunteer gave up.

@Dereckson: Per emails from Sep18 and Oct20 and https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup , I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action... → Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!

This is a reminder that the tool for which this ticket is created is still running on the Grid.
The grid is deprecated and all remaining tools need to migrate to Toolforge Kubernetes.

In T109950#9175846, @Dereckson wrote:

Who are the ones responsible for this review?

Who are the ones responsible for this review?

@Aklapper asked the same on Gerrit, it seems to me this is serviceops rather than traffic because it's an appserver change and mediawiki module.

I'm BOLDly closing this as I came to the same conclusions as @Pcoombe.

I'm not sure I understand the reasoning for this. Wikimedia's CentralNotice generally isn't blocked by ad lists such as EasyList since they consider an advert "the promotion of third party content in return for goods or services" which excludes both fundraising and community banners

Adding traffic to analyses the varnish comment, however i also wonder if this task is still valid or has perhaps been resolved some other way in the mean time?

T300563 is a good example of where such thing can potentially be helpful (although I do not know how that particular thing is implemented under the hood to know if it would actually be helpful)

In theory yes, but I think canonical name is a stronger contract of a sorts. And then I think it would be inconsistent with the default namespaces. And if there are several English (Latin script?) names it is not clear how to get which one is canonical but brute-force through the list.

Would the same goal be achieved if consistent English aliases were added to those custom namespaces?

I don't get what this task is about...custom namespaces are custom, what would the canonical value even be?

Ping - how to get a review from SRE on this patch? (@Vgutierrez was mentioned in https://gerrit.wikimedia.org/r/c/operations/puppet/ /631888/ ?)

Change 631888 had a related patch set uploaded (by Dereckson; owner: Dereckson):
[operations/puppet@production] Redirect svn.wikimedia.org/doc properly

Actually, you can use the compiler of redirect.dat as a software to output to stdout the result:

Current status

Thanks for the reminders.

Thanks for finding that Andre!

I was thinking mainly of this example and the fact that community discussion is not requested for the addition, unlike the withdrawal.

@Akeron: You imply that requests are accepted almost automatically. Which (recent) information is your statement based on?

@Dzahn Sorry, my message was not clear. I know how adding blogs is done on metawiki. What I meant to say is that the banned user just had to create a disposable account to index his blog https://meta.wikimedia.org/wiki/Special:Contributions/Blogdukiwi. It would probably be useful not to accept all these requests almost automatically, rather to filter the requests. For example according to the seniority of the user who made the request or that of the blog (in this case both were new).

@Akeron There is no automatic indexing. Wiki users and blogs being added to planet are totally separate. I don't know when it was added but we could find out in git log. It is unrelated to wiki user creations though.

Hi @Dzahn, thanks for removing.
As this could happen again, it might be better to start by not allowing this kind of disposable account out of nowhere https://meta.wikimedia.org/wiki/Special:CentralAuth/Blogdukiwi to be automatically indexed on request.