Hi,
YuviPanda, prtksxna, and myself (with help from Tim and Aaron) have been
working the UrlShortener extension, which is designed to implement the
URL shortener RfC[1] (specifically Tim's implementation suggestion).
I've filed T108557[2] to deploy the extension to Wikimedia wikis. We'd
like to use the "w.wiki" short domain, which the WMF is already in
control of.
A test wiki has been set up mimicking what Wikimedia's configuration
would be like: http://urlshortener.wmflabs.org/, and has an accompanying
"short" domain at us.wmflabs.org (e.g. http://us.wmflabs.org/3). Please
play with it and report any bugs you might find :)
[1] https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener
[2] https://phabricator.wikimedia.org/T108557
Thanks,
-- Legoktm
On Thu, Feb 4, 2016 at 8:20 AM, MZMcBride <z(a)mzmcbride.com> wrote:
> Federico Leva (Nemo) wrote:
>>Login pretty much never does what I expect nowadays, but I'm not sure my
>>expectations are correct so I can't identify actual bugs.
>
> There are various open tasks in Phabricator about user sessions currently,
> such as <https://phabricator.wikimedia.org/T124440>. Being unexpectedly
> logged out lately has been a bit annoying, though I don't know if it's
> related to the Performance team or some other team.
The origin of the unexpected logouts falls on the AuthManager project
and specifically the SessionManager component that rolled out in
1.27.0-wmf.11 [0]. We had various issues related to the session
handling changes including a bug that was overloading the storage
capacity of the Redis servers that store session data [1] and two
other issues which required rolling the wikis back to 1.27.0-wmf.10
[2][3].
Both rollbacks were accompanied by a run of the
"resetGlobalUserTokens.php" maintenance script which updates each
user's CentralAuth records in such a way that their authentication
session will be considered invalid the next time it is used on a wiki.
This was done from an abundance of caution point of view concerning
possible issues with sessions that had been issued by the
SessionManager software. The reset script is not fast [4], so session
invalidation has slowly worked its way across the CentralAuth user
table.
Part of the enhancements that are being applied in order to bring
SessionManager back to production with 1.27.0-wmf.13 is a new config
setting that can be used to give us a nearly instant switch to throw
to invalidate all active sessions. This setting is actually included
in 1.27.0-wmf.12, but the configuration on the Wikimedia cluster has
not been changed to make use of it yet. Invalidating all user sessions
is not something we plan to do for fun certainly, but there have been
in the past (and likely will be in the future) software and
configuration issues that necessitate the use of that heavy hammer
approach.
[0]: https://phabricator.wikimedia.org/T123451
[1]: https://phabricator.wikimedia.org/T125267
[2]: https://wikitech.wikimedia.org/wiki/Incident_documentation/20160123-Session…
[3]: https://tools.wmflabs.org/sal/log/AVKZtfQXW8txF7J0uNE2
[4]: https://phabricator.wikimedia.org/T124861
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
Hi all,
I would like to introduce to the Wikimedia community WikiToLearn, a FOSS
project of which I am a participant and which is lately getting a lot of
contributions and momentum.
It is a KDE project sponsored (among the others) by Wikimedia Italy and
recently joined by institutions such as HEP Software Foundation (CERN,
Fermilab, Princeton...) or Universities such as University of Pisa and Milano-
Bicocca. These institutions are already populating the website with content.
We aim to provide a platform where learners and teachers can complete, refine
and re-assemble lecture notes in order to create free, collaborative and
accessible textbooks, tailored precisely to their needs.
Although the project is quite young (only a few months old), it is already
growing in allure at an unexpected rate. Thanks to this we are now counting on
nearly 40 developers, and growing (including content developers).
We are different from Wikipedia and other WMF projects in several ways, and in
a sense, complementary. Our focus is on creating complete textbooks (and not
encyclopedic articles), drawing from a professor’s or a student’s own notes,
either existing or that have to be written down.
We also have a strong focus on offline use: all the content of WikiToLearn
should be easily printable by any student for offline use and serious
studying.
Besides a good team for content development, we can count on a small but
motivated team of developers, and we would like to improve communication with
upstream (a.k.a. you ;-) ), because we found ourselves developing a few
features which could probably be made available to the general public, with
some generalization and polishing. ;-)
Is this a right place to start such a discussion?
We would like to help as much as we can, but we might need some mentoring in
how to best approach MediaWiki development, as many of us are relatively new
to OSS/Web development.
Bye,
-Riccardo
We have decided to officially retire the rest.wikimedia.org domain in
favor of /api/rest_v1/ at each individual project domain. For example,
https://rest.wikimedia.org/en.wikipedia.org/v1/?doc
becomes
https://en.wikipedia.org/api/rest_v1/?doc
Most clients already use the new path, and benefit from better
performance from geo-distributed caching, no additional DNS lookups,
and sharing of TLS / HTTP2 connections.
We intend to shut down the rest.wikimedia.org entry point around
March, so please adjust your clients to use /api/rest_v1/ soon.
Thank you for your cooperation,
Gabriel
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
Assuming there's no easy way to merge the databases, we are fine with
dropping the old db. I believe most content was imported to the current
wiki at the time of the migration, see
https://phabricator.wikimedia.org/T25537. An xml dump was used, not an SQL
one, so I suppose stuff like logs may not have been preserved, but in any
case it's not critical that we preserve all that historical info. I mean,
it would certainly be nice, but we can live without it.
Or we could use the pt2wikimedia, as that would allow future archeologists
to recover the data from the beginning of the wiki :) Either option is fine.
On Wed, Feb 24, 2016 at 12:13 PM, This, that and the other <
at.light(a)live.com.au> wrote:
> Why not just delete the old ptwikimedia site and put the new one in its
> place, using the same dbname?
>
> The old wiki is inaccessible, since pt.wikimedia.org redirects offsite,
> so it's unclear if the old DB even needs to be preserved. And presumably
> any configuration bits that refer to ptwikimedia will still be relevant to
> the new site.
>
> If for some reason that is not feasible, I guess pt2wikimedia is
> acceptable, though only as a last resort. As I've said before, there really
> needs to be a better way to rename wikis without wasting hours of
> everyone's time...
>
> TTO
>
> --
> "Alex Monk" wrote in message
> news:CALMPGzX_E4ML0xD2A_2vTRZ+2a+nWtpC9KkJe58x=mdG-uOxEQ@mail.gmail.com...
>
>
> Hi all,
>
> A request has come up (https://phabricator.wikimedia.org/T126832) to
> re-create pt.wikimedia.org on the wikimedia cluster. Unfortunately it was
> previously hosted there and so the 'ptwikimedia' database name is already
> taken.
> Since database renaming does not really appear to be an option, does anyone
> have any objections to using 'pt2wikimedia' (or similar, suggestions
> welcome) instead for the new wiki? I know this doesn't fit the existing
> pattern so I'm unsure about just going ahead without asking for input from
> a wider audience.
>
> Alex
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
There will be a brown bag Tuesday, March 1st at 1pm Pacific time. We will
review some new changes to Phabricator. Many of these changes will be
relevant specifically to advanced users.
We will review:
- where Phabricator administration conversations are happening
- the custom forms feature
- the updates to projects, sub-projects and milestones
- other smaller changes
We should have plenty of time for Q&A
Blue jeans link [1]
The Blue Jeans video will be recorded. The recording and slide deck will be
posted to the Phabricator mediawiki pages [2].
[1]
https://bluejeans.com/105994346
[2]
https://www.mediawiki.org/wiki/Phabricator
Hi folks,
An ArchCom RFC triage (per
<https://phabricator.wikimedia.org/T125865>) was penciled in for this
past RFC meeting (<https://phabricator.wikimedia.org/E144>), but I was
out for jury duty and wasn't able to make the push for this or
facilitate it if we stuck with my hasty plan. I'm done now, and would
be happy to accommodate assuming everyone is available and up for
helping out with a triage for this coming meeting on Wednesday
2016-03-02 (<https://phabricator.wikimedia.org/E146>)
The point of the triage would be to try to ensure that more RFCs have
assigned shepherds on ArchCom. That, in turn, would hopefully make it
more likely for an RFC to make it through the process more quickly.
Instead of having to ask all of ArchCom status about a particular RFC,
there would be a single ArchCom owner to check in with.
Any RFC that doesn't have a shepherd is not likely to move through the
process. There are always going to be several RFCs that don't have
shepherds. Just submitting an RFC doesn't guarantee that an ArchCom
member will think your RFC is important. Life is hard that way. Make
your case!
Note also: shepherd != slave. Even when an RFC has a shepherd,
there's no guarantee that the RFC is a high priority for the shepherd.
Certainly, the shepherd's credibility as a worthy ArchCom member is
potentially damaged by foot dragging, but don't bank on being able to
dump blame on the shepherd if your RFC isn't going fast enough for
your taste.
Thoughts?
Rob
Please join for the following tech talk:
*Tech Talk**:* Automated citations in Wikipedia: Citoid and the technology
behind it
*Presenter:* Sebastian Karcher (Syracuse University, Zotero)
*Date:* February 29th, 2016
*Time: *20:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+Autom…>
*Length:* 1 hour
Link to live YouTube stream <http://www.youtube.com/watch?v=ltEL-kPURKs>
*IRC channel for questions/discussion:* #wikimedia-office
*Summary: *The talk provides a very brief introduction to Marielle Volz's
Citoid, the tool providing Wikipedia's new automated citations.I then focus
on the technology underlying Citoid, Zotero translators, and discuss how
interested users/developers can help improve that functionality to better
serve the Wikipedia community.