people who've edited the code in the past" are a
poor
person to ask for review then you do not understand how code review works.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Fundamentally broken sounds like a bit of a stretch.
In fact, it was probably working quite well for our less-trafficked
repositories. But the issues identified must be fixed and decent file
exclusion rules written before it goes back on for the active ones.
-Chad
On Jan 22, 2019 12:11 AM
e the reviewers (not by blame) plugin ages ago. This allows
people to opt in with much more granularity (and would remove the need for
the bot)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Found it :)
https://www.w3.org/MarkUp/SGML/sgml-lex/sgml-lex
Search for "empty comment declaration" :)
-Chad
On Fri, Oct 5, 2018, 11:50 PM Chad wrote:
> I'm personally a fan of .
>
> I came across it years ago--it's a null comment. Can't find the reference
> at the mo
I'm personally a fan of .
I came across it years ago--it's a null comment. Can't find the reference
at the moment though.
-Chad
On Thu, Oct 4, 2018, 2:25 PM Daniel Kinzler wrote:
> Am 04.10.2018 um 18:58 schrieb Thiemo Kreuz:
> > The syntax "[[Schnee]]reichtum&qu
Wouldn't it make to send a 429 instead of 408?
-Chad
On Sep 19, 2018 1:37 PM, "Amir Sarabadani"
wrote:
Hello,
ORES has policy that no more than four parallel connections per IP should
be requesting the service. We weren't enforcing this policy and that caused
several outa
banned for. That's just silly.
>
I'm going to quote someone out of context here, but I think it establishes
the point I'd like to make:
"temporary solutions have a terrible habit of becoming permanent, around
here"
-Chad
___
Wikitech-l
to releasing MediaWiki anymore.
Whomever picks up the torch will do fantastic. See you all around the
Internet :)
-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
ipts that use refs/publish/* should be updated. I assume git-review
will do this in short order.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ing
to do with admin permissions. But that's not the point of this thread at
all...
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
n the same
> >grounds as before, but another developer, Chad Horohoe, overrode me and
> >merged it in. That led to a discussion featuring Antoine, Chad, a few
> >other WMF developers, and me, which you can find here:
> >
> >https://gerrit.wikimedia.org/r/#/c/4
--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
On Fri, May 4, 2018, 1:21 PM Adam Sobieski <adamsobie...@hotmail.com> wrote:
> With such features, we can envision allowing groups of users or admins to
> determine that certain articles require a verified account to edit.
>
Why would this be de
signatures:
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-core-1.31.0-rc.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0-rc.0.tar.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
--
Chad Horohoe
___
MediaWiki
current historic usage - I am
> concerned this will lead to long wait times and a backlog of patches
> which might then block other work.
>
>
I think we could do 4 "changes" in a SWAT, which could consist of a couple
of
individual commits?
-Chad
_
g issues with that tag if they
should absolutely block release).
Have a fantastic weekend!
-Chad
[0] https://phabricator.wikimedia.org/T172165
[1] https://phabricator.wikimedia.org/project/view/3011/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.o
age to the list by sending it to: wikitec...@wikipedia.org"
>
> and
>
> "To post to this list, send your email to:
> wikitech-l@lists.wikimedia.org"
>
>
Fixed the former address to use lists.wikimedia.org as it should. Probably
been well over a decade since someone looked at that.
On Tue, Feb 13, 2018 at 10:27 AM Chad <innocentkil...@gmail.com> wrote:
> On Tue, Feb 13, 2018 at 7:39 AM Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com> wrote:
>
>> Ah, this explains why i wasn't able to login... Really confusing..
>> Can't we set a v
desktop.) Also the new
> non-Phabricator-based repo browser linked from it, which has a much more
> logical UI and it's crazy fast. Clearly a lot of love went into the
> upgrade, thanks Chad for working on it!
>
>
Thanks for the kind words Gergo. Gerrit is a vital part of our day-to-d
gt; DJ
>
Got a fix in the works for this. It's affecting more people than I
initially thought!
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
have for
gerrit.wikimedia.org and try logging in anew.
* Second: if you use Lastpass for your password management...the update
last week seems to have added autocomplete="off" to the login form, which
makes the workflow for password managers a little annoying. I'll look into
this further.
the Cirrus bug. The other one was
temporally related, but I dunno about causally.
Needs more investigation if we want to roll forward tomorrow!
<3
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mail
Howdy Gerriters!
On Friday, I'll finally be upgrading Gerrit from 2.13.9 to 2.14.6. Going to
do this from 21:00–23:00 UTC.
It shouldn't take the full two hours, but hey it's Gerrit.
https://phabricator.wikimedia.org/T156120
<3
-Chad
___
Wikitec
invoked and
> will still validate @covers tags.
>
>
As a friendly reminder: if you don't need all the overhead of
MediaWikiTestCase (ie: you're writing actual unit tests that don't depend
on MediaWiki), it's encouraged to extend PHPUnit_Framework_TestCase
directly. It's wayy faster.
-Chad
___
sites?
The first deploy after a holiday break is already pretty exciting, and
rolling this out feels like something that could use a dedicated window.
(Otherwise, kudos to the MCR team for hitting this milestone)
-Chad
On Fri, Dec 22, 2017 at 2:27 AM Daniel Kinzler <daniel.kinz...@wikimedia
On Thu, Dec 7, 2017 at 12:24 PM Bartosz Dziewoński <matma@gmail.com>
wrote:
> On 2017-12-07 21:05, Chad wrote:
> > Yeah, and when you throw ErrorPageError deep enough in a code path, it
> can
> > explode on cli operations. I've seen this before.
>
> Indeed yo
hrow ErrorPageError deep enough in a code path, it can
explode on cli operations. I've seen this before.
Our MWException handling is weird :\
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Dec 7, 2017 at 11:07 AM Daniel Kinzler <daniel.kinz...@wikimedia.de>
wrote:
> Am 07.12.2017 um 19:48 schrieb Chad:
> > Basically the short version is: exceptions should only be shown to users
> in
> > the situation of *actual software errors*. They're the exception
a helpful error
message, log it, and fall back gracefully.
-Chad
PS: Now that I think about it, there's been a proliferation of
RuntimeException for the exact same thing.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.o
browser support (comments like
[2][3][4] and *especially* [5] are pretty discouraging) it just doesn't
seem worth it the technical maintenance to support it on our end.
Don't get me wrong, the format itself seems kinda cool, but I'd be very
hesitant to be a pioneer for a new graphics standard that n
Actually, I went ahead and deployed that fix now.
I use Timeless and I want to use advanced search too :p
-Chad
On Wed, Nov 22, 2017 at 5:32 AM Birgit Müller <birgit.muel...@wikimedia.de>
wrote:
> The main issues with timeless skin are fixed and will be deployed in next
> weeks' tr
ng typos in source code and package descriptions in the wild, so
> it's tailored to technical jargon and their misspellings. It could be a
> good fit to git commit messages.
>
> That doesn't mean it's free of false positives though, so I wouldn't
> recommend to use it in a voting check
by the end of the month, we've already branched
and are working on making sure the release is ready-to-go :)
--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
No non-emergency deployments on Fridays, Saturdays or Sundays.
Monday could work.
-Chad
On Thu, Sep 21, 2017 at 7:15 PM יגאל חיטרון <khit...@gmail.com> wrote:
> I glad you say so. What about Friday?
> Igal
>
>
> On Sep 22, 2017 05:07, "Chad" &
It wouldn't be hard to do at all, technically. I imagine it'd be something
like a test3wiki.
Main thing to know is when do we cycle off of the old version? When the
version goes out on Tuesdays? That day's already pretty loaded for software
moving about...
-Chad
On Thu, Sep 21, 2017 at 1:25 PM
On Tue, Sep 19, 2017 at 10:50 AM C. Scott Ananian <canan...@wikimedia.org>
wrote:
> Chad: the more you argue that it's not even worth considering, the more I'm
> going to push back and ask for actual numbers and facts. ;)
>
>
As I said in my prior message: it's been conside
On Tue, Sep 19, 2017 at 10:28 AM C. Scott Ananian <canan...@wikimedia.org>
wrote:
> On Tue, Sep 19, 2017 at 1:17 PM, Chad <innocentkil...@gmail.com> wrote:
>
> > be clear: we never chose HHVM for Hack. We don't use Hack. The one
> > experiment I had at trying Ha
timescale there's only one option. PHP has a long-standing history of being
a viable runtime. HHVM does not.
I don't see this as an A/B choice at all, but rather a clear path forward.
So sure: let's have an RfC/TechComm meeting to work out the details, but
eally implemented any HHVM/Hack specific features (as
far as I know) it means there's no reason we have to continue to support
HHVM at all once WMF has moved off of it.
It's been a fun experiment for the past couple of years, but it's time to
move on.
-Chad
_
We could keep it in the XML dumps (it's part of the XSD after all)...just
compute it at export time. Not terribly hard, I don't think, we should have
the parsed content already on hand
-Chad
On Fri, Sep 15, 2017 at 12:51 PM James Hare <jamesmh...@gmail.com> wrote:
> What I wonder
On Wed, Sep 6, 2017 at 2:31 AM Antoine Musso <hashar+...@free.fr> wrote:
> On 05/09/2017 17:47, Chad wrote:
> > On Tue, Sep 5, 2017 at 2:28 AM Joaquin Oltra Hernandez <
> > jhernan...@wikimedia.org> wrote:
> >
> >> I think that people using old br
cales for whom upgrading is a cost-prohibitive
endeavor
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.
(3) I would *really* like to have 2--maybe 3--browsers to list. There's
zero reason to make users think there's only one option when there's a
couple of valid ones.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Firefox and Chromium an option?
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I thought Module:Version handled this template automatically. Sorry about
that folks!
-Chad
On Fri, Jul 14, 2017 at 6:46 AM Andre Klapper <aklap...@wikimedia.org>
wrote:
> On Fri, 2017-07-14 at 13:17 +, Robert Vogel wrote:
> > according to [1] the MediaWiki 1.28.2 was a LTS
://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0.tar.gz
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0.tar.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
-Chad
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0-rc.1.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0-rc.1.patch.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
--
Chad Horohoe
___
MediaWiki
. It makes "how old is a branch" math much
easier.
-Chad
On Tue, Jul 11, 2017 at 1:31 PM Mukunda Modell <mmod...@wikimedia.org>
wrote:
> Maybe we could prevent breaking things by always creating a branch for
> every wmf.XX number. That is, always create a new branch, even on we
it'd help for coordinating cross-wiki efforts (bots, tools) as well
as
seeing which wikis are "done" and could be early candidates for migration.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
releases of
> that series and we're committed to back porting security fixes for some
> time.
>
> This was released with 1.27.0 from the beginning -- it was not later
> backported as an
> incompatible 1.27.1+ fix.
>
> Extensions that are affected should be updated for 1.27.0+ su
support --
that's the fix...nothing
from core.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-1.29.0-rc.0.tar.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
Hello!
I would like to announce the immediate availability of security releases
1.27.3
and 1.28.2. Due to a mistake in packaging, the releases 1.27.2 and 1.28.1
did
not contain the fix for SyntaxHighlight_GeSHi. This new release does contain
that fix.
The task in question:
it to 1.30.0-rc.0.
Let the backports begin! (I want to be generous this time too, so bring 'em
at me)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
master + backport process we all know and
love until we
do the release (looking at May 25th).
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
7 mode
> <https://docs.hhvm.com/hhvm/configuration/INI-settings#php-7-settings>?
>
>
I'm curious if we should enable this in Vagrant and our Jenkins testing so
we can avoid weird failures that spawned this thread.
-Chad
___
Wikitech-
just
check with ctype_digit() so we can handle ints and strings that look like
numbers.
And probably throw an exception if we're not, it's probably bogus config or
a bug
if we're looking at non-numeric input.
-Chad
___
Wikitech-l mailing list
Wikitech-l@list
Hello!
I would like to announce the release of MediaWiki 1.23.17. There was an
issue
in the 1.23.16 release that prevented it from running on PHP 5.3
installations.
Considering the report wasn't very widespread, I'm guessing most people
haven't
been affected yet. If you are, this release will fix
Yes, the tags will be following very shortly. It takes a long time for a
large
pile of changes to make its way through CI.
Apologies for any confusion!
-Chad
On Thu, Apr 6, 2017 at 3:38 PM James Montalvo <jamesmontal...@gmail.com>
wrote:
> This is great. Thank you. I don't believe
Hello!
I would like to announce the release of MediaWiki 1.28.1, 1.27.2 and
1.23.16!
These releases fix five security issues in core and one for the extension
SyntaxHighlight_GeSHi. Download links are given at the end of this email.
Please note that next month is the End-Of-Life date for
Hi,
Tomorrow, April 6th we will be performing a security release of MediaWiki
for all supported branches. The new versions will be 1.28.1, 1.27.2 and
1.23.16. This will resolve 9 issues in MediaWiki core, and one in a bundled
extension.
Have a great day,
--
Chad Horohoe & Sam
Brian is correct, this is off-topic. Let's please not continue this thread
here.
-Chad
On Mon, Mar 13, 2017 at 3:44 PM bawolff <bawolff...@gmail.com> wrote:
> With all due respect, and as much as I support things like this, this
> is offtopic for wikitech-l.
>
> --
> Bri
ely I would attend unless I was
> >specifically proposing an RFC.
>
> Proprietary and capped at 25 participants? No thank you.
>
>
Piling on. I hate hangouts for small meetings with like 5 people, much
less a large group. They're *awful*
The 25 participant problem should make
aid (and Dan pointed out on the task), this is far from a
drop
everything situation...we just need to start making some inroads to this
sooner rather than later. Since it's broken, making it faster is an
optimization
problem so the writing is on the wall.
-Chad
[0]
https://gi
l, but it's out of commission at the
moment.
Major kudos on wrapping this up, been wanting this for awhile.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jan 30, 2017 at 7:16 PM Chad <innocentkil...@gmail.com> wrote:
> Hi,
>
> Due to a current vandalism/spam threat, I've enabled administrator approval
> of all new accounts. Hopefully this won't have to stay enabled long.
>
> Will update when it's turned back of
Hi,
Due to a current vandalism/spam threat, I've enabled administrator approval
of all new accounts. Hopefully this won't have to stay enabled long.
Will update when it's turned back off.
-Chad
___
Wikitech-l mailing list
Wikitech-l
Nope.
mediawiki-l would be more appropriate, as the support list.
-Chad
On Mon, Jan 30, 2017 at 1:27 PM Steven Walling <steven.wall...@gmail.com>
wrote:
> Dear Brad,
>
> Yes.
>
> On Mon, Jan 30, 2017 at 6:42 AM Brad Jorsch (Anomie) <
> bjor...@wikimedia.org>
>
be reverted by Wikimedia system
> administrators.
>
>
As the person to changed the tarball criteria to MUST NOT, I would
be totally in favor of extending that to deployed extensions.
Removing code that's still used in production is embarrassing/sad
and offenders should be ashamed ;-)
-Chad
__
If he had them before, he should retain them. I've granted both.
-Chad
On Tue, Jan 24, 2017 at 7:45 PM Legoktm <legoktm.wikipe...@gmail.com> wrote:
> Hi,
>
> After speaking with Yurik, I've filed
> <https://phabricator.wikimedia.org/T156219> on his behalf to
cookie.
The bug is: https://phabricator.wikimedia.org/T144573
The gerrit change is: https://gerrit.wikimedia.org/r/#/c/16/
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.
It's been published to https://gerrit.wikimedia.org/r/#/c/09/ (for
master)
and is being backported to all supported branches (1.28.x, 1.27.x, 1.23.x)
This isn't an extension we bundle in core MW which explains the oversight.
-Chad
___
Wikitech-l mailing
Already done:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20170111-multiversion
-Chad
On Thu, Jan 12, 2017 at 8:27 AM Chad <innocentkil...@gmail.com> wrote:
> Yeah, I need to write one up, I'll try to get it done today or tomorrow.
>
> There won't be muc
Yeah, I need to write one up, I'll try to get it done today or tomorrow.
There won't be much to learn / do as a result, but it needs to be
documented at the very least.
-Chad
On Thu, Jan 12, 2017 at 8:18 AM Pine W <wiki.p...@gmail.com> wrote:
> Understood. Thanks for your efforts and
thin seconds.
This code is proving rather difficult to clean up :(
-Chad
On Thu, Jan 12, 2017 at 6:54 AM Pine W <wiki.p...@gmail.com> wrote:
> Thanks Florian. I'm curious to know what happened. When you have a
> minute, perhaps
> you could point me to the phab ticket or incide
:)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
mple,
a team of Italians who would rather work in Italian than English. In our
case, we've got *many* languages and being able to use things across
wikis/languages is important.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
We upgraded to Gerrit 2.13.3 today from 2.12.2. However, a couple of users
have reported being unable to login. Based on reports and investigation, I'm
thinking/hoping this is only affecting 11 users.
However, if you find yourself unable to login with the message "Cannot
assign
username to
On Wed, Dec 7, 2016 at 9:22 AM Alex Monk <am...@wikimedia.org> wrote:
> Are we also going to be disabling l10nupdate then? That's surely more risky
> than syncing beta's files (which aren't even loaded by production apaches)
>
>
Sounds l
> accordingly.
>
> Does the freeze also affect the beta cluster? Or just production?
>
>
Considering it's best practice to fully sync config changes to production,
even if they're no-ops intended for beta I would say yes
-Chad
___
>
That is correct :)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ot; window because it overlaps with the time I
picked ;-)
Thanks!
-Chad
[0]
https://wikitech.wikimedia.org/w/index.php?title=Deployments=revision=1088543=1085547
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailma
On Mon, Nov 28, 2016 at 12:08 PM Chad Horohoe <choro...@wikimedia.org>
wrote:
> Hello everyone,
>
> I am happy to announce the availability the general release of MediaWiki
> 1.28!
>
>
Hi!
One minor note. The RELEASE-NOTES-1.28 was not updated prior to re
://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0.tar.gz
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0.tar.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
-Chad
into the p2p network,
> or someone replacing articles with biased versions.
>
>
Same thing here. That being saidI'm curious if there's some sort of
middle ground here. I wonder how much (c|w)ould be saved by serving
static assets (CSS, UI images, etc etc) via P2P. Prolly not much in the
U
Hi,
With the release of MediaWiki 1.28, the lifetime of MediaWiki version
1.26.x has come to an end.
Users still using MediaWiki 1.26.x are advised to upgrade to version
1.28.0, the latest stable version.
-Chad
___
MediaWiki announcements mailing list
. If you hit any other repos than MW that seem to
be having issues, please chime in on
https://phabricator.wikimedia.org/T151676
Have a good weekend!
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
://phabricator.wikimedia.org/project/board/1982/
-- Chad
**
Download:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0-rc.1.tar.gz
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0-rc.1.tar.gz
https
heir mother's uncle could be sniffing the traffic ;-)
Same rule goes for a "generate a random password" site. Don't use
them.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
This. Is. Awesome. I've been wanting to see something like this for ages.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
be updating MW.org shortly.
Tyler Cipriani's assisting me with this release, so expect to see some RCs
with his name
(and signatures) on them :)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
n the butt for basically no gain (in that case).
It's not impossible--there's packages and all that fun stuff for Tomcat and
related tooling--but I think that Tomcat generally isn't worth the overhead
and maintenance burden for a single service.
-Chad
___
Wikite
Heya!
Gonna reboot Gerrit real quick this morning. Turns out "cobalt" did not
have hyperthreading turned on. Services should be back momentarily!
-Chad
On Fri, Oct 7, 2016 at 2:07 PM Daniel Zahn <dz...@wikimedia.org> wrote:
> The Gerrit migration is over. It is back up
on things in the meantime, so if things
deteriorate
again we can start the migration sooner.
(and yeah, wikitech incident report to follow, I'm a little burnt out right
now though)
Thanks again for bearing with us!
-Chad
On Thu, Oct 6, 2016 at 2:32 PM Greg Grossmeier <g...@wikimedia.org>
rate links (e.g. ISBN
> citation templates) instead of relying upon magic link functionality.
>
>
Question: do we have any kinds of numbers yet on how widely these are
used across WMF projects?
It's info something we could probably get out of either Elasticsearch o
sessions. One of two things
happen:
1) You sit there and listen to someone else talk to you, or
2) It's ostensibly a group discussion, but the group is too big and nothing
useful gets discussed because you spend too much time listening to 30
different voices.
(1) bores me to tears. (2) is basically useless.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Another idea could be doing the tasks he had assigned to him.
https://phabricator.wikimedia.org/maniphest/?statuses=open()=PHID-USER-pkzunphfdvlecngun3iz#R
-Chad
On Sat, Sep 3, 2016 at 10:15 AM Luke <luke081...@web.de> wrote:
> Would be a nice idea, John. Sadly there isn't a way yet
, but they should all be there.
I was talking more about putting the "bundled" ones (ie: those in the
tarballs) as submodules of core release branches like we do for the
wmf/* branches.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikim
s/benefits you point out, it also means that the
extensions and skins would be included in the signed tags for each
release, aiding in reproducibility of a release.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I would like to announce the release of MediaWiki 1.27.1, 1.26.4, 1.23.15!
These releases fix five security issues in core and one for the extension
PdfHandler. Download links are given at the end of this email.
== Security fixes ==
* (T139565) API: Generate head items in the context of the
1 - 100 of 1490 matches
Mail list logo
