t least not programmatically.
Honestly, if you think "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
enable 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
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]]rei
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 ou
x27;s 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
___
te 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-ann
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
atch, on 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.o
w.mediawiki.org/keys/keys.html
--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikite
On Fri, May 4, 2018, 1:21 PM Adam Sobieski 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 desirable?
-Chad
>
__
rc.0.tar.gz.sig
GPG 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
_
ic 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
___
d as always, tag 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
kitec...@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. Good spotti
On Tue, Feb 13, 2018 at 10:27 AM Chad 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 varnish/apache/nginx/whatever ru
; 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-day
work around her
>
> 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 furt
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
@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
___
major
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
wrote:
> H
On Thu, Dec 7, 2017 at 12:24 PM Bartosz Dziewoński
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 you did, you even fixed
gh 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
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, not the
> > norm
turn an exception when
a user tries to perform an action on it. We should return 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.
___
#x27;s effectively zero 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
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
wrote:
> The main issues with timeless skin are fixed and will be deployed in next
> weeks' train:
> https://phabricator
urce 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
> recommen
e out 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/mediawik
No non-emergency deployments on Fridays, Saturdays or Sundays.
Monday could work.
-Chad
On Thu, Sep 21, 2017 at 7:15 PM יגאל חיטרון wrote:
> I glad you say so. What about Friday?
> Igal
>
>
> On Sep 22, 2017 05:07, "Chad" wrote:
>
> > It wouldn'
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,
On Tue, Sep 19, 2017 at 10:50 AM C. Scott Ananian
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 considered, and discarded
On Tue, Sep 19, 2017 at 10:28 AM C. Scott Ananian
wrote:
> On Tue, Sep 19, 2017 at 1:17 PM, Chad wrote:
>
> > be clear: we never chose HHVM for Hack. We don't use Hack. The one
> > experiment I had at trying Hack never panned out. MediaWiki is in PHP,
> not
> >
ong enough
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
let's not pre
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 wrote:
> What I wonder is – does this *
On Wed, Sep 6, 2017 at 2:31 AM Antoine Musso 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 browsers on desktop, are most sure
e in lower-income locales 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
a good
route to go.
(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
On Fri, Sep 1, 2017 at 6:55 AM Federico Leva (Nemo)
wrote:
> At least until a proper resource exists, just directing people to the
> latest Firefox is probably the most reasonable option (we certainly
> can't support the incumbent).
>
>
Is linking to Firefox and Chromi
I thought Module:Version handled this template automatically. Sorry about
that folks!
-Chad
On Fri, Jul 14, 2017 at 6:46 AM Andre Klapper
wrote:
> On Fri, 2017-07-14 at 13:17 +, Robert Vogel wrote:
> > according to [1] the MediaWiki 1.28.2 was a LTS release. On [2] I can
>
://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
ki/1.29/mediawiki-1.29.0-rc.1.tar.gz.sig
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
_
e this move. It makes "how old is a branch" math much
easier.
-Chad
On Tue, Jul 11, 2017 at 1:31 PM Mukunda Modell
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 weeks
> with
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
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+ support --
> that's the fix...nothing
> from core.
>
> -Chad
>
&
es between
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+ supp
/mediawiki/1.29/mediawiki-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/li
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: https://phabricator.wik
t bumps 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
n we'll be in the normal patch 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
tings#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-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
) 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
wrote:
> This is great. Thank you. I don't believe tags were created for 1.27 o
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 MediaWi
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 wrote:
> With all due respect, and as much as I support things like this, this
> is offtopic for wikitech-l.
>
> --
> Brian
>
> On Mon, Mar 1
less 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 m
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://github.com/peff/git/commit/b5
mission 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 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 off.
>
>
Forg
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
Nope.
mediawiki-l would be more appropriate, as the support list.
-Chad
On Mon, Jan 30, 2017 at 1:27 PM Steven Walling
wrote:
> Dear Brad,
>
> Yes.
>
> On Mon, Jan 30, 2017 at 6:42 AM Brad Jorsch (Anomie) <
> bjor...@wikimedia.org>
> wrote:
>
> > On Sun,
strators.
>
>
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 wrote:
> Hi,
>
> After speaking with Yurik, I've filed
> <https://phabricator.wikimedia.org/T156219> on his behalf to restore his
> membership in th
auth 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
Already done:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20170111-multiversion
-Chad
On Thu, Jan 12, 2017 at 8:27 AM Chad wrote:
> 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,
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 wrote:
> Understood. Thanks for your efforts and the quick ro
ck within seconds.
This code is proving rather difficult to clean up :(
-Chad
On Thu, Jan 12, 2017 at 6:54 AM Pine W 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 incident report.
>
&
r your patience :)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
non-English language. For example,
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 a
On Wed, Dec 7, 2016 at 9:22 AM Alex Monk 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 like a plan!
-Chad
___
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
___
Wikitech-l mailin
>
That is correct :)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
"SF Morning SWAT" window because it overlaps with the time I
picked ;-)
Thanks!
-Chad
[0]
https://wikitech.wikimedia.org/w/index.php?title=Deployments&type=revision&diff=1088543&oldid=1085547
___
Wikitech-l mailing list
Wikitech-l@
On Mon, Nov 28, 2016 at 12:08 PM Chad Horohoe
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 release and
still mentions that the software is
://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)
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
going. 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/ma
bricator:
https://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
cle 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
x27;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
al release of MW
I'll 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://l
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
__
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 wrote:
> The Gerrit migration is over. It is back up and served from new server
>
eping a close eye 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 wrot
plates) 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 or the
dumps probably :)
-Chad
_
skipping most 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()&assigned=PHID-USER-pkzunphfdvlecngun3iz#R
-Chad
On Sat, Sep 3, 2016 at 10:15 AM Luke wrote:
> Would be a nice idea, John. Sadly there isn't a way yet, to
ll 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.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 give
1 - 100 of 1648 matches
Mail list logo
