Hi,
I would like to point your attention to
https://phabricator.wikimedia.org/T247172. To me, this seems like a
bypassing of the LangCom.
What do you all think?
Martin
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.
>
Hey all,
As hopefully most of you have heard, I'm working on changing the system we
use to configure Wikimedia production. The main purpose is to make it
output static files and reduce the amount of "code" executed on each page
request as much as possible. This means that much of the way that people on
this list write and deploy configuration patches will have to change.
You can read some details at T223602
<https://phabricator.wikimedia.org/T223602>, but the short version is that
there'll be a YAML file for each wiki which will set unique configuration
for that wiki, and a set of YAML files for "traits" that wikis can inherit
from (e.g. in this demo change for bnwiki
<https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/539414/4/wmf…>,
I'm making it inherit a set of configuration for the "mobilemainpagelegacy"
trait). There won't be an InitialiseSettings file or feature dblists any
more. Much of the configuration in CommonSettings.php will be moved into
these files too. Changes to configuration YAML files will be "compiled"
into a static JSON file per wiki (example for bnwiki
<https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/507729/18/wm…>)
at merge time.
I'd really appreciate thoughts/ideas/concerns/questions any of you might
have.
This is a test email to the google group sitereq-l(a)wikimedia.org
Please let me know if you received this email
Josephine Cabanero (She/Her)
I.T. Technical Support
Wikimedia Foundation <https://wikimediafoundation.org/>
"Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment."