Sorry, forgot to CC this list.
---------- Forwarded message ---------
From: James Forrester <jforrester(a)wikimedia.org>
Date: Tue, 26 Nov 2019 at 12:50
Subject: Production config dblists are now auto-generated at merge time
from YAML
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Hey all,
[Unless you're writing Wikimedia production MediaWiki-land configuration
changes, you can ignore this note.]
As part of my work on moving variant configuration in static files[0], I've
just merged and deployed a change to how dblists work. They are now
auto-generated at merge time[1] (except for the very few lists which are
live-computed in production, which remain). The lists are calculated from
the per-wiki YAML files in wmf-config/config (and if you try to change the
dblist files manually, CI will error at you).
Changes to dblist memberships are quite rare, and this will enforce that we
don't make mistakes. (As part of this deployment, I removed three duplicate
entries and noted several irregularities we probably didn't intend.)
This means that if you're writing a change that previously would have meant
manually editing the dblist files, you now have to touch the YAML file
instead (and run composer build locally, or use CI to tell you what to
change).
This mostly affects the creation of new wikis (which should now be slightly
simpler), plus a few major features currently enabled through dblists. For
an example, if you were to remove FlaggedRevisions from Chechen Wikipedia,
you'd now need to edit cewiki.yaml[2] to remove the " - flaggedrevs" line,
as well as changes to InitialiseSettings.php.
This work unblocks some of the future re-architecting of config, which I've
mentioned before, as part of the long-term plan to move Wikimedia
production into containers. Configuration traits related to FR will inherit
from flaggedrevs.yaml, and static-like code in CommonSettings.php (and in
this case, flaggedrevs.php) can be significantly shrunk.
If anything has broken or has become, if you have any questions, or want to
talk about things, I'd be happy to discuss, here, on IRC, or on Phabricator.
Thanks!
[0] - https://phabricator.wikimedia.org/T223602
[1] - https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/545411
[2] -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/…
Yours,
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
Totally agreed
so 11. 1. 2020 v 18:21 odesílatel Marco A. <strigiwm(a)gmail.com> napsal:
> Hello and happy new year (first message of the year in this list as
> far as I remember):
>
> El sáb., 11 ene. 2020 a las 17:15, Martin Urbanec
> (<martin.urbanec(a)wikimedia.cz>) escribió:
> >
> > Hello,
> >
> > what do you all think about https://phabricator.wikimedia.org/T242514?
> >
> > Martin
> >
>
> Quick look and opinion only; I have not taken a detailed look at the
> situation.
>
> I am not sure if James or his team be willing to disable VE totally
> for the project, but maybe they can have VE disabled for those
> namespaces where they've found most problems or it is not working
> properly via $wgVisualEditorAvailableNamespaces. I assume they mean
> the Main namespace.
>
> I do not feel against making the wikitext editor the default editor
> for both logged-in and unregistered contributors at that project if
> the community there so chooses.
>
> If the issues reported, howerver, are due to a bug in the VE extension
> itself, I think we should focus on fixing it rather than removing the
> entire feature.
>
> Best regards.
>