[Wikitech-l] Today's CREDIT showcase - video

[Adam Baso]

Here's video from today's 12-May-2016 CREDIT showcase
.

https://www.youtube.com/watch?v=GwTDDWjxoek=youtu.be=7

https://commons.wikimedia.org/wiki/File:CREDIT_-_May_2016.webm

== Contents ==

* Derk-Jan Hartman: Video.js progress
* Dmitry Brant: Wikidata infoboxes in Android app
* Joaquin Hernandez: Vicky chat bot
* Baha: mobile printing for offline reading
* Monte: "smart random" content service endpoint
* Erik: Geo boosting search queries
* Julien: Maps for Wikivoyage

Thanks!
-Adam
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Jon Robson]

.
On 12 May 2016 4:18 p.m., "Stas Malyshev"  wrote:
>
> Hi!
>
> > No, -2 is restricted to project owners and thus not an op-
> > tion for the vast majority of contributors.  For that pur-
> > pose, I proposed a Gerrit label "WIP"
> > (cf.
http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/84068
).
>
> This looks like a nice solution.

Seconded. What's stopping us from adopting? It seems in that thread nothing
happened.

Greg - is this something we can do?

>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] 1.28.0-wmf.0 on hold for now

[Erik Bernhardson]

It looks like the train didn't roll forward today? I was going to swat out
a new test that depends on 1.28.0-wmf.1 but 1.27.0-wmf.23 still looks to be
running group2

On Thu, May 12, 2016 at 9:01 AM, Chad Horohoe 
wrote:

> Thanks Roan & Brad! We'll get back on track with wmf.1 deployments today :D
>
> -Chad
>
>
> On Wed, May 11, 2016 at 11:08 PM, Roan Kattouw 
> wrote:
>
>> TLDR: the bug is fixed and the errors have stopped.
>>
>> I started working around this train hold by backporting the entire Echo
>> extension from wmf1 to wmf23, assuming that the bug would be in MW core and
>> updating Echo wouldn't affect it. Right after I deployed that, these errors
>> started being thrown by wmf1 too.
>>
>> It turned out that one of the Echo changes I backported stores the
>> integer -1 in redis under some circumstances. RedisBagOStuff treats
>> integers specially, in order to make incr() work: it stores them as plain
>> numbers instead of PHP-serialized data. But when retrieving this value, the
>> code didn't recognize -1 as a plain number because it didn't consist solely
>> of digits ('-' is not a digit), so it thought it was PHP-serialized data
>> and passed it to unserialize(), which caused the error. Apparently no one
>> had ever tried to store a negative integer in redis (!) until my Echo
>> change exposed the bug.
>>
>> Brad did all the hard work, diagnosing this and writing up a fix on
>> Phabricator. I turned that into a patch and deployed it about an hour ago.
>> There haven't been any more errors since then.
>>
>> On Wed, May 11, 2016 at 1:59 PM, Chad Horohoe 
>> wrote:
>>
>>> Hi,
>>>
>>> When we deployed the first 1.28 release to the cluster yesterday, we got
>>> a new error[0] relating to
>>> unserialization of redis data. It's pretty spammy already, so I'm
>>> paranoid about deploying wider until
>>> we figure out why. Deploying some debugging work soon so we can figure
>>> out what's going on.
>>>
>>> If you've got any information you think would help, please chime in on
>>> the bug.
>>>
>>> -Chad
>>>
>>> [0] https://phabricator.wikimedia.org/T134923
>>>
>>> ___
>>> Engineering mailing list
>>> engineer...@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>>
>>>
>>
>
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Stas Malyshev]

Hi!

> No, -2 is restricted to project owners and thus not an op-
> tion for the vast majority of contributors.  For that pur-
> pose, I proposed a Gerrit label "WIP"
> (cf. 
> http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/84068).

This looks like a nice solution.

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Tim Landscheidt]

Jon Robson  wrote:

> Gerrit is commonly used as a place to share works in progress early.

> This is great, but it has an unfortunate side effect of making it
> harder for would-be reviewers to find patches that need reviewing
> using this query:
> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z

> Could I ask that as a norm, if you post a WIP patch that you also self -2 it?

> […]

No, -2 is restricted to project owners and thus not an op-
tion for the vast majority of contributors.  For that pur-
pose, I proposed a Gerrit label "WIP"
(cf. 
http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/84068).

Tim


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Mukunda Modell]

Oh good point, you are correct, at least it would seem that way. I only
have the option to -1 and +1 on operations/puppet, no -2

On Thu, May 12, 2016 at 5:12 PM, Alex Monk  wrote:

> On 12 May 2016 at 22:26, Jon Robson  wrote:
>
> > Could I ask that as a norm, if you post a WIP patch that you also self -2
> > it?
> >
>
> I think you can only -2 if you have the rights necessary to +2?
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Mukunda Modell]

We definitely need consistency for any convention like this to be useful.
Phabricator has the equivalent of self-2 in Differential: `arc diff
--plan-changes`

It's a good convention, and I will try to adhere to the self-2 in addition
to added WIP in the commit subject.

On Thu, May 12, 2016 at 4:44 PM, Jon Robson  wrote:

> I didn't know you could search message. Thanks. Even so.. the crux of
> what I'm asking for is a reliable way to filter these out. Even with
> the search you gave me I see "DONOTSUBMIT" in certain messages :)
>
>
> On Thu, May 12, 2016 at 2:29 PM, James Forrester
>  wrote:
> > On 12 May 2016 at 14:26, Jon Robson  wrote:
> >
> >> Gerrit is commonly used as a place to share works in progress early.
> >>
> >> This is great, but it has an unfortunate side effect of making it
> >> harder for would-be reviewers to find patches that need reviewing
> >> using this query:
> >>
> >>
> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
> >>
> >> Could I ask that as a norm, if you post a WIP patch that you also self
> -2
> >> it?
> >>
> >
> > I disagree with this suggestion. The convention to date is having "WIP"
> or
> > "DONTMERGE" in the git commit title. What's wrong with that?
> >
> >
> >
> >> I'd love to get us to a place where
> >>
> >>
> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
> >> is manageable that code gets merged left right and center :)
> >>
> >
> > Use
> >
> https://gerrit.wikimedia.org/r/#/q/(NOT+message:WIP)+AND+(NOT+message:DONTMERGE)+AND+(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2))+age:24w,n,z
> >  instead.
> >
> > J.
> > --
> > James D. Forrester
> > Lead Product Manager, Editing
> > Wikimedia Foundation, Inc.
> >
> > jforres...@wikimedia.org | @jdforrester
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Alex Monk]

On 12 May 2016 at 22:26, Jon Robson  wrote:

> Could I ask that as a norm, if you post a WIP patch that you also self -2
> it?
>

I think you can only -2 if you have the rights necessary to +2?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] PyWikibot reviewers needed!

[John Mark Vandenberg]

No!
Quality rapidly decreases when you force unpaid people to rush reviewing so
the queue looks better.
Last time people rushed pywikibot reviewers, lots of junk was committed,
creating lots of bugs, and the tree has been red for months now, making it
more difficult to merge old large changesets. Busy work. By unpaid people.
Because paid people complain about the queue.
We recently lost a very good reviewer & +2'er, putting a large spanner in
the system. But other than that you will see pywikibot has been very active
.
On 13 May 2016 04:17, "Jon Robson"  wrote:

> I'm keen for us give attention to people who have open patchsets that
> they are looking for review. We had the first code review office hours
> today and I hope in the long term during this hour we can work on
> reviewing patchsets from this search:
>
> https://gerrit.wikimedia.org/r/#/q/(+label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)+),n,z
>
> Pywikibot has 145 open patches on Gerrit.
> You can see them all here:
>
> https://gerrit.wikimedia.org/r/#/q/status:open+project:pywikibot/core+(+label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)+),n,z
>
> Can someone who is familiar with this codebase commit to helping
> getting all these reviewed?
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Jon Robson]

I didn't know you could search message. Thanks. Even so.. the crux of
what I'm asking for is a reliable way to filter these out. Even with
the search you gave me I see "DONOTSUBMIT" in certain messages :)


On Thu, May 12, 2016 at 2:29 PM, James Forrester
 wrote:
> On 12 May 2016 at 14:26, Jon Robson  wrote:
>
>> Gerrit is commonly used as a place to share works in progress early.
>>
>> This is great, but it has an unfortunate side effect of making it
>> harder for would-be reviewers to find patches that need reviewing
>> using this query:
>>
>> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
>>
>> Could I ask that as a norm, if you post a WIP patch that you also self -2
>> it?
>>
>
> I disagree with this suggestion. The convention to date is having "WIP" or
> "DONTMERGE" in the git commit title. What's wrong with that?
>
>
>
>> I'd love to get us to a place where
>>
>> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
>> is manageable that code gets merged left right and center :)
>>
>
> Use
> https://gerrit.wikimedia.org/r/#/q/(NOT+message:WIP)+AND+(NOT+message:DONTMERGE)+AND+(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2))+age:24w,n,z
>  instead.
>
> J.
> --
> James D. Forrester
> Lead Product Manager, Editing
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[James Forrester]

On 12 May 2016 at 14:26, Jon Robson  wrote:

> Gerrit is commonly used as a place to share works in progress early.
>
> This is great, but it has an unfortunate side effect of making it
> harder for would-be reviewers to find patches that need reviewing
> using this query:
>
> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
>
> Could I ask that as a norm, if you post a WIP patch that you also self -2
> it?
>

I disagree with this suggestion. The convention to date is having "WIP" or
"DONTMERGE" in the git commit title. What's wrong with that?



> I'd love to get us to a place where
>
> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
> is manageable that code gets merged left right and center :)
>

​Use
https://gerrit.wikimedia.org/r/#/q/(NOT+message:WIP)+AND+(NOT+message:DONTMERGE)+AND+(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2))+age:24w,n,z
 instead.

J.
-- 
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Best practice for WIP patches to help code review office hours

[Jon Robson]

Gerrit is commonly used as a place to share works in progress early.

This is great, but it has an unfortunate side effect of making it
harder for would-be reviewers to find patches that need reviewing
using this query:
https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z

Could I ask that as a norm, if you post a WIP patch that you also self -2 it?

In addition to this, if a patch is open for longer than several months
you may want to abandon it - it's much more useful to link to an
abandoned patchset in a phabricator task which has all the context for
someone who might be able to solve the problem it tries to solve.

I'd love to get us to a place where
https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
is manageable that code gets merged left right and center :)

Warm regards,
Jon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] PyWikibot reviewers needed!

[Jon Robson]

I'm keen for us give attention to people who have open patchsets that
they are looking for review. We had the first code review office hours
today and I hope in the long term during this hour we can work on
reviewing patchsets from this search:
https://gerrit.wikimedia.org/r/#/q/(+label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)+),n,z

Pywikibot has 145 open patches on Gerrit.
You can see them all here:
https://gerrit.wikimedia.org/r/#/q/status:open+project:pywikibot/core+(+label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)+),n,z

Can someone who is familiar with this codebase commit to helping
getting all these reviewed?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator Differential lackings

[Mukunda Modell]

I just noticed something else, which I think I missed previously:

To see open differential revisions for a repository, you just have to go to
the browse interface:

https://phabricator.wikimedia.org/diffusion/PHAB/browse/wmf%252Fstable/

Notice there are open revisions listed right above the readme.

On Mon, May 9, 2016 at 1:26 PM, Krinkle  wrote:

> I apologise if some of the below does in fact exist, I'd gladly find out!
>
> There are three major parts of my workflow as project maintainer and
> contributor that I find lacking in Differential right now and are strong
> reason for me to discourage anyone from migrating to it. In addition,
> projects that have already migrated are essentially non-existent and blind
> to my workflow as a result. I've tried but even if I accept loss in
> productivity, I can't even find a workaround for these.
>
> 1. Casual notifications about new patches and merged commits (IRC
> notifications). - https://phabricator.wikimedia.org/T116330
>
> 2. Discover pending patches.
>
> While Diffusion is a fine repo browser, it appears to lack any link back to
> Differential. Even when manually going to Differential, it doesn't appear
> to be any concept of "repo". It only has a global concept of "diff" and
> "reviewer" (e.g. you can list diffs for review, and your own open diffs).
> Unlike Maniphest (which has a concept of projects that have their own pages
> with useful outgoing links). There is no list of projects with a link to
> see a project's patches. This unlike Gerrit or GitHub where projects are
> linked to searches for open patches or open pull-requests. This makes it
> very non-transparent for potential consumers of our code, and casual
> contributors to find out about open patches. This is an important indicator
> for developers to determine the health of a project. It's also an easy
> way-in to for new reviewers, and an important interface for project
> maintainers to easily list open patches from time to time. Without this, I
> expect our code review habits to become even worse than they already are.
>
> https://phabricator.wikimedia.org/differential/ (no projects listed) ->
> https://phabricator.wikimedia.org/differential/query/all/ (no repos named
> alongside the diffs) -> https://phabricator.wikimedia.org/D229 (links to
> diffusion) -> https://phabricator.wikimedia.org/diffusion/GOJR/ (no link
> to
> query to differential).
>
> If I see this correctly, there is simply no way to naturally get to a list
> of open patches of a project.
>
> 3. Notification about new patches and merged commits.
>
> There is appears to be no way to subscribe to a repo (e.g. as a maintainer
> of that repo) so that I may be notified of new diffs and/or landed commits.
> This is worse due to #2, which would've been a workaround (albeit a costly
> one, due to pull:N vs push:1).
>
> In addition to these workflow concerns, there is also Continuous
> integration of course. But that's a separate issue.
>
> I'm bringing up these concerns now because contrary to what I expected,
> Differential is being adopted by quite a few repos now despite it being
> premature.
>
> -- Krinkle
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 12-May-2016 CREDIT, going back to Hangouts on Air/YouTube

[Pine W]

FYI, this week's presentations, according to the Etherpad, are:

* *Derk-Jan Hartman:* Video.js progress
* *Dmitry Brant*: Wikidata infoboxes in Android app
* *Joaquin Hernandez*: Vicky chat bot
* *Baha*: mobile printing for offline reading
* *Monte*: "smart random" content service endpoint
* *Erik*: Geo boosting search queries

Cheers,

Pine


On Thu, May 12, 2016 at 9:17 AM, Adam Baso  wrote:

> Reminder...
>
> On Thu, Apr 14, 2016 at 12:13 AM, Adam Baso  wrote:
>
> > Hi all,
> >
> > The next CREDIT showcase will be Thursday, 12-May-2016 at 1800 UTC (1100
> > SF).
> >
> > https://www.mediawiki.org/wiki/CREDIT_showcase
> >
> > For this one we'll use Hangouts on Air for presenters, and the customary
> > YouTube stream for viewers.
> >
> > See you next month!
> > -Adam
> >
> >
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 12-May-2016 CREDIT, going back to Hangouts on Air/YouTube

[Adam Baso]

Reminder...

On Thu, Apr 14, 2016 at 12:13 AM, Adam Baso  wrote:

> Hi all,
>
> The next CREDIT showcase will be Thursday, 12-May-2016 at 1800 UTC (1100
> SF).
>
> https://www.mediawiki.org/wiki/CREDIT_showcase
>
> For this one we'll use Hangouts on Air for presenters, and the customary
> YouTube stream for viewers.
>
> See you next month!
> -Adam
>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] 1.28.0-wmf.0 on hold for now

[Chad Horohoe]

Thanks Roan & Brad! We'll get back on track with wmf.1 deployments today :D

-Chad

On Wed, May 11, 2016 at 11:08 PM, Roan Kattouw 
wrote:

> TLDR: the bug is fixed and the errors have stopped.
>
> I started working around this train hold by backporting the entire Echo
> extension from wmf1 to wmf23, assuming that the bug would be in MW core and
> updating Echo wouldn't affect it. Right after I deployed that, these errors
> started being thrown by wmf1 too.
>
> It turned out that one of the Echo changes I backported stores the integer
> -1 in redis under some circumstances. RedisBagOStuff treats integers
> specially, in order to make incr() work: it stores them as plain numbers
> instead of PHP-serialized data. But when retrieving this value, the code
> didn't recognize -1 as a plain number because it didn't consist solely of
> digits ('-' is not a digit), so it thought it was PHP-serialized data and
> passed it to unserialize(), which caused the error. Apparently no one had
> ever tried to store a negative integer in redis (!) until my Echo change
> exposed the bug.
>
> Brad did all the hard work, diagnosing this and writing up a fix on
> Phabricator. I turned that into a patch and deployed it about an hour ago.
> There haven't been any more errors since then.
>
> On Wed, May 11, 2016 at 1:59 PM, Chad Horohoe 
> wrote:
>
>> Hi,
>>
>> When we deployed the first 1.28 release to the cluster yesterday, we got
>> a new error[0] relating to
>> unserialization of redis data. It's pretty spammy already, so I'm
>> paranoid about deploying wider until
>> we figure out why. Deploying some debugging work soon so we can figure
>> out what's going on.
>>
>> If you've got any information you think would help, please chime in on
>> the bug.
>>
>> -Chad
>>
>> [0] https://phabricator.wikimedia.org/T134923
>>
>> ___
>> Engineering mailing list
>> engineer...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>
>>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l