Diffusion needs some time to sync its mirrors so the skin is shown as archived here as well.

This is just stale…

You did not specify any extension/skin here. After doing so, feel free to repoen.

I think the way forward proposed by the patch is confusing. Either we should remove the setting altogether, or keep it functional for another version of MediaWiki. Removing its functionality without removing the setting seems unhelpful at best.

Requested public project User-Demian has been created: https://phabricator.wikimedia.org/project/view/4852/

Are you sure you are pushing to the correct URI? (http://phabricator.wikimedia.org/source/tool-commons-android-app.git) and using the correct credentials?

Done.

Considering the discussion in T236809, I am against doing anything here. There is no suitable alternative, as InternalParseBeforeLinks will probably recieve the same treatment, and the deprecation should be removed soon.

The problem of deprecations is that they can not just be ignored by extension developers, as they make unit tests fail. Such, jenkins awards -1 Verified to every changeset uploaded for an extension that does use them.

By the way, what I really do not like here is that there is no reasonable path forward for extension developers. If I replace hooks by other hooks that are not deprecated yet, there is a high probablity that those other hooks will be deprecated a few months later, for example the InternalParserBeforeLinks hook.

Can we do the same for the InternalParseBeforeSanitize hook?

Resolved by https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Arrays/+/539673/.

Can you try again with the master version of the Arrays extension? This is probably broken because the global default value has been broken for some time in v2.2: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Arrays/+/6a47eac735e7cd9c16b445453f960e6b057845ae

Adding documentation in a way like this is recommened in the extension registraion documentaton, which is why I added it.
Currently, it says that this is not supported for config anymore, but when I added the key, it stated otherwise.

To clarify something: I think I translated my thoughts into English in a misleading way: When I was talking about "objecting", I meant that I would like to raise the question why the request was refused, considering other decisions concerning membership in acl*repository-admins have been handled much more lenient in the past. In particular, I had no intent to overrule this decision (which would be totally presumptuous) or anything like that, but just to ask to reconsider.

If T249730 is resolved, can it be made public?

Considering the European GDPR, we might even be legally mandated to provide this information to users, as users have the right to access any information a given website is storing about him.

I think blocking MessMessages would create more problems than it would solve. Massmessages which are not delivered to single persons because of partial blocks seem to be quite problematic to me.

This task would be done when every extension has its own project and MediaWiki-extensions-Other is archived.

Please be aware that in the current parser implementation, some extensions use the onClearState hook provided by MediaWiki. Are you planning on removing that too?

This can not be fixed by the extension without dropping features. See T236809 for further information.

In T236809#6067132, @gerritbot wrote:

Change 589459 merged by jenkins-bot:
[mediawiki/core@master] Deprecate infrequently-used parser-related hooks

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

I would like to object this refusal. This is about phabrricator repository adminship, not about gerrit permisions. In practice, these are used for repository management stuff and nothing else.

Rejecting worked for me now.

In T706#5952355, @Zoranzoki21 wrote:

Hello, I would like to request this also. I want to help with creating projects when requested and etc.

This puzzled me – is there any reason why this is open about 50 times longer than these tasks usually are? Is there something blocking this?