Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
Hello,
can someone to update list https://phabricator.wikimedia.org/P10500 which
contains repositories which haven't mediawiki/mediawiki-codesniffer.
I found in list that much repositories are empty, and repositories which
aren't available on Gerrit.
So, can someone please update this list of repositories (in
mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at
least, contains one PHP file. or to provide me command with which I can
update list when I want, so I don't need to request it every time.
Best regards,
Zoran.
P. S.: Happy weekend! :)
Hello,
Recently, I stumbled upon a technical writing course which I found very
useful and I wanted to share it and thought of sending an email to
wikitech-l recommending it. Also, I've been looking for a resource about
VueJS with not much luck and wanted to send an email asking if anyone knows
any.
Instead, I have this idea to have a virtual library for developers so they
can share useful resources with each other. You go to a wiki page and see
list of courses, books, conference videos, on each topic and different
people recommanding them. You can also request a resource for a topic and
people respond to you. If the wiki page grows too big, we can split them to
sub pages based on topics, and so on.
I started the page in https://www.mediawiki.org/wiki/User:Ladsgroup/Library
but I'm planning to move it to the main namespace if no one objects. Please
take a look, add more recommandations, co-sign, request for a resource,
respond to a request for a resource, etc.
What do you think? Please let me know if you think it's a horrible idea or
you have feedback on details (mediawiki.org? maybe we should move it to
wikitech.wikimedia.org?)
Hope that'd be useful.
Best
--
Amir (he/him)
It does the same as the @ operator, except that it takes care to prevent a
very bad bug that existed before PHP 7. Details at
https://phabricator.wikimedia.org/T253461
If there are other issues or benefits, please write them on the task. The
overhead of AtEase is prerty minor, so really any benefit at all is likely
to tip the balance toward keeping it. But, in the event that there isn't
any, then perhaps we should slowly phase it out.
Best,
-- Timo
Hello,
The current logo of MediaWiki was adapted slightly more than fifteen years
ago and hasn’t changed since. This logo despite having the nice concept of
sunflower, is old. The sunflower represents the diversity, the constant
growth and also the wildness.
Among its biggest issues I can point out that it’s a bitmap picture so it’s
unusable in large sizes (like large posters) and it’s too realistic making
it unusable in small sizes.
Most, virtually all, software products use a simpler and more abstract
form. For example, docker, kubernetes, Ubuntu, VueJs, React, Apache Kafka,
and many more. It’s a good time for MediaWiki to follow suit.
My request is for changing the logo of MediaWiki and I have no plans or
interest in changing logo of any other project.
Please show your support, oppose or your comments in the discussion page.
You can also add more suggestions.
The discussion page:
https://www.mediawiki.org/wiki/Project:Proposal_for_changing_logo_of_mediaw…
Best
--
Amir (he/him)
Phabricator users,
this is to let you know that the "aphlict" service has been disabled on
Phabricator (for now) because it caused stability issues.
This means you will not get realtime (pop-up) notifications on Phabricator.
(If you had those enabled in the first place).
Regular notifications (that do not pop-up) and emails are not affected by
this.
https://phabricator.wikimedia.org/T238593
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
On March 30, we announced that we were temporarily pushing back the release
of MediaWiki 1.35 due to uncertainty resulting from the COVID-19 pandemic.
We are now ready to begin the process of moving forward with the release.
The first step is cutting the release branch, REL1_35, which will occur on
Monday, July 13.
We will then be in "pencils down" mode: developers will stop targeting
MediaWiki 1.35 for new features. Instead, any new features would continue
to be applied to master and would target MediaWiki 1.36 or later. The only
work that would continue towards MediaWIki 1.35 would be blockers -
critical bug fixes or features close to completion that need to make it
into the release. This would happen by merging those patches into master
and then backporting them to the REL1_35 branch.
We anticipate that MediaWiki 1.35 will be released at the beginning of
August.
We appreciate your patience in these difficult times. Wishing you safety
and health,
Cindy
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.
The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.
Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023…
I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller", "governer", "ruler", lead "officer", or such.**
* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_…
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium…
--
-Aaron
Hello,
TLDR: The following hooks are deprecated in 1.35:
SkinTemplateBuildNavUrlsNav_urlsAfterPermalink,
SkinTemplatePreventOtherActiveTabs, SkinTemplateTabAction,
BaseTemplateAfterPortlet, SkinTemplateToolboxEnd, BaseTemplateToolbox,
SkinTemplateOutputPageBeforeExe.
The longer version:
As part of the desktop improvements project
<http://mediawiki.org/wiki/Desktop%20improvements> we've been making some
exciting changes in MediaWiki's skin architecture. This has involved
migrating away from the BaseTemplate PHP class to Mustache as the render
engine for Vector. In 1.36, the Vector skin plans to use the new SkinMustache
class
<https://github.com/wikimedia/mediawiki/blob/master/includes/skins/SkinMusta…>
and do away with the BaseTemplate class. This meant that we had to
deprecate various BaseTemplate hooks, providing more suitable generic
alternatives in the shared Skin.php layer. We also took the opportunity to
reduce the number of active hooks that operate in the skin layer for
developer sanity.
>From now on it is intended that any skin modifications are done *prior *to
rendering. The renderer whether it is BaseTemplate or SkinMustache will
simply render the data that's been provided.
As a result of this I have various changes to report!
The *SidebarBeforeOutput
<https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Hooks/SidebarBefor…>
*hook now can be used to modify the toolbox and languages portals.
Previously these sidebar menus had their own bespoke hooks.
The SkinTemplateBuildNavUrlsNav_urlsAfterPermalink hook
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateBuildNavUrlsNav_url…>
is deprecated and can be replaced with the new and improved
SidebarBeforeOutput hook.
The SkinTemplatePreventOtherActiveTabs and SkinTemplateTabAction hooks
<https://phabricator.wikimedia.org/T253814>were seldom used and replaced
with SkinTemplateNavigation::Universal .
All BaseTemplate hooks should now be considered deprecated per T253809
<https://phabricator.wikimedia.org/T253809>.
- BaseTemplateAfterPortlet
<https://www.mediawiki.org/wiki/Manual:Hooks/BaseTemplateAfterPortlet>
is replaced with the template-rendering agnostic SkinAfterPortlet
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinAfterPortlet>
- SkinTemplateToolboxEnd
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateToolboxEnd>is
replaced with the new and improved version of SidebarBeforeOutput
- BaseTemplateToolbox
<https://www.mediawiki.org/wiki/Manual:Hooks/BaseTemplateToolbox> is
replaced with the new and improved version of SidebarBeforeOutput
Finally a big one:
The SkinTemplateOutputPageBeforeExec hook is now deprecated
<https://phabricator.wikimedia.org/T60137>. Previously this hook could do a
lot of things and often in ways that were hard to reason with. For example,
previously this hook was used alongside other hooks to add items to the
footer and to override skin internals to display portals that were normally
hidden. We looked through all the use cases for this hook and are confident
we've caught the most confident use cases. Migration depends on what it was
previously used for but are documented on mediawiki.org
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateOutputPageBeforeExe…>.
It's possible there are other use cases, we missed and if so we plan to
cover those during the 1.36 release.
If you are an extension developer and have any questions about migration
please feel free to ping me on the associated Phabricator ticket or hook
talk page, we will be happy to improve the documentation and help you find
the right way to upgrade your code.
As we go into 1.36 we plan to make changes that simplify MediaWiki skin
development and make the ecosystem friendlier to frontend developers and
make skins easier to maintain. In fact, in future, it will be possible to
write skins without a single line of PHP. If you are excited or intrigued
by these changes and want to get involved in the conversations I urge you
to subscribe to our board.
<https://phabricator.wikimedia.org/project/board/4795/>
I'm particularly interested in hearing from developers who are keen to make
skins in the new ecosystem. Your input and creativity would be much
appreciated. Feel free to drop me a private mail or engage in open
conversations.
In addition to all the extension developers who helped review changes to
their hook contracts, I would like to especially thank the following people
for getting us to this landmark: Ammarpad, Timo, Volker and Mainframe98.
I'd like to give a specific shout out for Ammarpad who has been a huge
driving force here, preventing various bugs from occurring and swiftly
responding to many of the unexpected regressions that we encountered during
this work. We couldn't have done this without you!
Thanks for reading!
Jon
[Apologies for cross-posting]
Hi,
TL;DR: We will take our Gerrit instance at gerrit.wikimeda.org offline
on Saturday, 27th of June from 17:00--22:00 UTC (hopefully much
shorter) to upgrade to the latest Gerrit v3.2.2.
(10:00--15:00 San Francisco time, and 19:00--24:00 Central
European time)
---------------------------------
We're currently running Gerrit v2.15, which is no longer supported and
we will upgrade to Gerrit v3.2 on Saturday 27th of June. This new
version brings lots of improvements. The most noticeable change is
probably the UI overhaul. The (default) "old UI" gets removed and the
"new UI" has been completely revamped. It's much more modern looking
and easier to use. And it also became far more usable on mobile
phones. But the new version of course also comes with fixes and
additions around the ssh interface, and the HTTP API.
Since this is such a big upgrade, we want to give you a chance to look
at it beforehand. You can test at
https://gerrit-test.wikimedia.org/
It holds a copy of our Gerrit data as of 15th of June, and it runs the
new Gerrit v3.2.2. We'll keep tuning things there during this week, so
it might get an occasional restart. But look around and test the new
UI, the HTTP API, etc.
If you run into issues or discover bugs, please open tickets in
Phabricator and set the Gerrit 3.x upgrade task (T254158) as parent.
Note that this test Gerrit instance is already hooked up with our
Phabricator. If you upload / merge / abandon / etc changes with a
`Bug: Tnnnn` footer, you'll get comments on the corresponding tasks in
Gerrit. So please use our test task T775 for your experiments.
As everything, also this upgrade comes with a few downsides:
* The new UI no longer works on Internet Explorer (currently ~0.02% of
Gerrit's web requests).
Microsoft's Edge browser works though.
So if you are still using Internet Explorer, please consider switching
to a different browser.
* Users of git-review need to use at least version 1.27 (released
September 2018). Otherwise uploading changes will fail.
* Your git should be at least version 2.2.0 (released November 2014)
to take advantage of the new, much simpler commit-msg hook.
Keeping my fingers crossed for a painless update,
Christian with lots of helping hands from RelEng, and SRE