== tl;dr ==
On June 29th git.wikimedia.org (running Gitblit) will redirect all
requests to Phabricator. The vast majority of requests will be correctly
redirected.
== What is happening? ==
In an effort to reduce the maintenance burden of redudant services we
will be removing git.wikimedia.org. The software that has been serving
git.wikimedia.org, Gitblit, has given our Operations team many headaches
over the years[0] and now that we have all repositories hosted in
Phabricator[1] there is no reason to keep Gitblit around. Phabricator's
Diffusion (the name of the code browser) provides the needed
functionality that Gitblit served (mostly viewing/browsing repositories,
something which Gerrit does not do).
== When will it happen? ==
June 29th
https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20160629T1600
== How could this affect me? ==
Potentially, you use an unpopular (in the sense of not used often)
feature of Gitblit that is not supported in Diffusion. This should be
unlikely.
Potentially, a link you follow that pointed to somewhere on
git.wikimedia.org will not redirect correctly. This is also unlikely as
we (mostly @Danny_B and @Paladox) took great care to update many
mediawiki.org templates along with providing very robust redirect
rules[2]. If you find one that isn't working, please let us know (along
with the original url and, if possible, the desired target in
Diffusion).
One known issue to call out: Diffusion does not list commits by person.
However Differential (the code-review tool) does this (not just for new
commits). There is no easy/maintainable way to redirect those,
unfortunately.
Something else broken? Please file a task in Phabricator in the
#Diffusion project[3].
Thanks,
Greg, on behalf of WMF Release Engineering (and all the volunteers who
helped along the way (and Ops!))
[0] eg: https://phabricator.wikimedia.org/T73974
[1] https://phabricator.wikimedia.org/diffusion/
[2] https://phabricator.wikimedia.org/T137224
[3] https://phabricator.wikimedia.org/project/profile/53/
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi all,
the Reading Infrastructure team will try to enable AuthManager [1] in WMF
production this week, with the following schedule:
- group0 Tuesday 22:00 UTC (yes, that's pretty much now)
- group1 Wednesday 22:00 UTC
- group2 Thursday 22:00 UTC
I apologize for the very late notice. I realize that such a change should
ideally be fixed long before, advertised via the Tech news etc, but
omitting that seemed like the lesser of two evils. We believe we need to
get AuthManager into the 1.27 release as having to support two completely
different authentication systems in the LTS release would be an
unreasonable burden and risk; to do that, we need to test it in production
in very short order, otherwise the release will be delayed a lot due to
vacations and Wikimania; and we weren't sure until very recently whether we
are able to keep to this schedule.
If all goes well, switching AuthManager on should have very little visible
effect (see earlier announcements [2][3]), but with a change of this
complexity all rarely goes well. If you see authentication-related
problems, please ping or cc Brad Jorsch (IRC: anomie) and me (IRC: tgr). If
we are not around and things break badly, you can revert by setting
wgDisableAuthManager to true in wmf-config.
Gergő
https://www.mediawiki.org/wiki/User:Tgr_(WMF)
[1] https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager
[2] https://lists.wikimedia.org/pipermail/wikitech-l/2016-June/085835.html
[3] https://lists.wikimedia.org/pipermail/wikitech-l/2016-May/085725.html
