We just released a new version of Research:FAQ on Meta [1], significantly
expanded and updated, to make our processes at WMF more transparent and to
meet an explicit FDC request to clarify the role and responsibilities of
individual teams involved in research across the organization.
The previous version – written from the perspective of the (now inactive)
Research:Committee, and mostly obsolete since the release of WMF's open
access policy [2] – can still be found here [3].
Comments and bold edits to the new version of the document are welcome. For
any question or concern, you can drop me a line or ping my username on-wiki.
Thanks,
Dario
[1] https://meta.wikimedia.org/wiki/Research:FAQ
[2] https://wikimediafoundation.org/wiki/Open_access_policy
[3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953
*Dario Taraborelli *Head of Research, Wikimedia Foundation
wikimediafoundation.org • nitens.org • @readermeter
<http://twitter.com/readermeter>
We’re going to keep both Gerrit and GitLab.
Many of the repositories now on Gerrit require features that are lacking in
GitLab:
- Cross-repository dependent merge requests
- Project gating and deterministic, atomic merges
- Stacked patchsets
- Multiple reviewers
Likewise, GitLab has features that our developers have come to depend on:
- Familiar fork, branch, and merge workflow
- Self-service repository creation
- Jupyter Notebook rendering
- GitLab's self-service CI/CD pipeline
- Bring your own runners
- Artifact and packages registries
As a result, we'll be running both systems for at least the next two years.
More information is available on MediaWiki.org[0], summarized below.
___
*Details*
These repositories have requirements that mean they must remain on Gerrit:
- MediaWiki core
- The subset of extensions and skins which track MediaWiki core’s
mainline branch (including all Wikimedia production-deployed extensions,
skins, and MediaWiki vendor)
- SRE’s Puppet repository along with dependencies and dependent
repositories.
Other repositories on GitLab may return to Gerrit to lessen the mental
burden of working with two systems.
Likewise, some repositories on Gerrit may wish to continue to migrate to
GitLab.
We'll use the Phabricator tag "GitLab (Project Migration)"[1] to track
requests from project stewards to migrate between systems. We’ll be
monitoring that workboard closely through the end of this calendar year to
assist developers with their migrations.
___
*What now*
- We have no intention of shutting down either system for the next two
years.
- We've posted a longer explanation on MediaWiki.org[0]. Please use the
talk page there (rather than this mailing list) for discussion.
- We've gathered a list of questions we anticipate some folks may have
on MediaWiki.org[2].
- Specific requests from project stewards to migrate repositories
between either of our systems should use the Phabricator tag "GitLab
(Project Migration)"[1].
- We'll be hosting office hours to answer any questions. More details
about these sessions will come later.
The decision to keep both systems was challenging. Having two code forges
adds to the fragmentation of our systems, the mental overhead for our
developers, and the maintenance burden of stewards. But each system is
well-suited to a subset of our needs, keeping both systems safeguards the
productivity of our developers and the stability of our systems.
For more details, I encourage you to review MediaWiki.org[0] and engage on
the talk page.
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/GitLab/Migration_status>
[1]: <https://phabricator.wikimedia.org/project/profile/5552/>
[2]: <https://www.mediawiki.org/wiki/GitLab/Migration_status/FAQ>
Hi. Do you know, by chance, what change in the New Vector could broke the
svg files rendering or clickable area image HTML tags? Because now the
areas are moved aside from there original places, in the New Vector only,
and it broke me hundreds of articles. You can see some screensots here:
https://phabricator.wikimedia.org/T368034. Thank you,
Igal
(User:IKhitron)
Hi friends,
Apologies for the short notice, but please be aware of some
interruption to lists.wikimedia.org tomorrow, Tuesday 18th June 2024
between 10:00 and 12:00 UTC.
We will be migrating the Mailman service off of the old virtual
machine and onto new physical hardware. We hope the window will be
shorter than scheduled, but during this time mail delivery to lists
may be delayed, and the web interface will be intermittently
unavailable.
You can follow along with the work on the task [0] or in irc at
#wikimedia-sre-collab
If there are any questions or comments, please let me know
--Eoghan
[0] https://phabricator.wikimedia.org/T367521
I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here.
tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.)
(Is there a place on mw.org to put this tidbit on?)
------- Forwarded message -------
From: "Brian Levine" <support(a)github.com> (GitHub Staff)
To: matma.rex(a)gmail.com
Cc:
Subject: Re: Commits in mirrored repositories not showing up on my profile
Date: Tue, 09 Jul 2013 06:47:19 +0200
Hi Bartosz
In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit.
The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits.
Cheers
Brian
--
Matma Rex
Hello Everyone :)
I am Rohit and I am contributing to the commons-android app.
The issue reference:- https://github.com/commons-app/apps-android-commons/issues/5728 and
the solution PR:- https://github.com/commons-app/apps-android-commons/pull/5741
Before:-
1. Before the PR, the feature to edit the depicts was using wbeditentity API to edit the
entity with a (clear=1) flag.
2. This was causing the whole identity data deletion and adding new data sent to the API
with a data field containing updated depictions.
3. I tried removing that clear flag and it prevented the deletion of the whole data.
However, it was causing depiction to add repeatedly the same without removing the old
ones.
4. I know that it could be the scenario where only the updated depicts were sent to the
API and it'll add the new depicts without causing repetition. But, what about if the
user has removed a depiction?
My Solution:-
1. I used another API to delete the previous depiction first and then, used webeditentity
API to update the new depictions.
2. But, this approach is causing two edit actions on the entity.
Please look at the problem and tell me if there is any way to achieve the desired
functionality in a single edit.
Cloud-vps users:
There are now a mere two weeks remaining before Debian Buster ends its
period of long term support. After June 30th, security upgrades will no
longer be available for this release and VMs running Buster will become
ever more risky and difficult to maintain.
As of today there are still 143 Buster servers running in our cloud[0]
-- some of them are probably yours! Please take some time to delete VMs
that are no longer needed, and rebuild those that are still needed with
a more modern release, ideally Debian Bookworm.
There is a task for your project on phabricator[1] where you can update
your progress. If you have vital VMs that you absolutely cannot rebuild
by July 15th, please update the associated task with your plan and
anticipated timeline. WMCS staff will start shutting down unacknowledged
VMs in mid July in order to attract the attention of users who do not
read email or follow phabricator.
Buster's end of life has been a long time coming, and frequently
announced. If you've been waiting for the right time to think about
this, the time is now.
Thank you!
-Andrew + WMCS staff
[0] https://os-deprecation.toolforge.org/
[1] https://phabricator.wikimedia.org/project/view/6373/