►
From YouTube: 2020 11 16 Memory Team Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
welcome
to
this
version
of
the
memory
team
weekly
meeting.
There's
a
bunch
of
non-verbalized
topics
there,
I'm
assuming
this
one's,
going
to
be
quick,
since
you
all
spent
some
time
today
on
the
2
gigabyte,
sync
meeting,
but
it's
the
end
of
the
milestone.
So
I
wanted
to
run
through
the
issues
and
see
if
there
was
anything
that
was
going
to
carry
over.
B
A
Okay,
does
this,
did
you
say
it'll
get
in
before
the
22nd,
or
do
we
just
need
to
carry
it
over
to
13.7.
A
Sorry,
what
was
the
question?
Do
we
need
to
carry
this
one
over
to
13-7,
or
do
you
think
it'll
be
done
and
shipped
by
the
22nd.
B
A
C
Yeah
so
conditional
gets
so
client-side
caching
is
being
rolled
out
as
we
speak.
It's
on
canary
now
I
tested
it
on
staging
as
well
and
on
canary,
and
it
seems
to
work
fine
from
what
I've
seen.
I
I
still
need
to
pull
cdn
locks,
but
I'm
gonna
wait
with
that
until
it's
fully
rolled
out
to
the
entire
production
fleet,
but
it
looks
good
like
in
if
the
number
us
in
thanos
for
canary
are
to
be
trusted.
C
It
looks
like
we'll
be
at
about
a
fifty
percent
cached
rate,
which
is
up
from
eight
percent,
which
so
that's
great.
So
that's
these
are
requests
for,
for
there
will
be
no
payload
being
served
to
the
client
you
so
there's
like
one
smaller
issue
that
we
that
we
had
to
work
on
today.
Unfortunately,
I
had
to
like
contact
switch
back
and
forth,
which
is
that
we
had
an
elevated
error
rate
for
the
image
scaling,
but
it
was
not
legit.
C
It
was
because
we
kind
of
count
successes
incorrectly
in
prometheus,
due
to
caching
being
introduced,
because
it
was
not
counted
as
a
success,
so
we're
looking
to
there's
a
small.
I
I
sent
an
mr
already.
We
just
need
to
merge
that.
So
when
that
is
live
and
error
rate
is
back
to
normal,
then
I
think
we
can
probably
consider
this
done
and
then
improve
logging.
I
have
there's
some
feedback,
it
has
an
mr.
It
is.
C
We
have
a
solution,
it's
not
pretty
and
I
got
some
feedback
from
a
maintainer.
If
there's
a
way
to
simplify
it,
I
kind
of
agree
that
it
would
be
nice
to
simplify
it
a
bit
more.
I'm
not
sure
if
I
have
time
this
week
to
work
on
it
though,
but
it's
also,
I
don't
think
it
should
be
a
show.
It
should
not
be
a
blocker
for
release,
so
it
might
slip
into
a
13-7,
and
it's
also
it's
kind
of
blocking
the
run
book.
C
Rework
as
well,
because
it
kind
of
I
brought
it
like
to
reference
all
these,
like
new
log
labels
that
we
don't
have
yet
yeah,
so
it
might
slip
and
then
creating
a
documentation.
That's
in
sorry.
C
Okay,
so
the
image
scanning
documentation.
There
are
two,
mrs
open,
I'm
just
I'm
just
waiting
for
feedback
from
the
technical
writer
there
yeah
I'm
just
waiting
for
feedback,
so
I
I'm
pretty
sure
this
will
make
13
seconds.
Okay,.
A
On
the
improved
logging,
do
you
want
to
just
carry
that
over
so
you're
not
distracted
this
week,
or
do
you
want
to
have
the
distraction
in
case
you
get
bogged
down
by
that.
C
I
would
I
would
prefer
that,
because
yeah,
I
would
prefer
that,
because,
like
my
the
first
half
of
the
day
was
already
like,
I
had
to
join
an
incident
calling
and
stuff,
because
this
already
lost
some
time.
I
would
prefer
to
like
move
that,
if
that's,
it
should
be
okay
like
because
it's
really
yeah
it's
it's
it's
a
bit
more
than
just
cosmetic,
because
it
will
it
really.
It's
like
tricky
right
now
to
see
what
is
breaking,
but
it's
not.
I
don't
think
it's
like,
should
be
a
blocker
okay,.
D
Yes,
so
dogskitrap.com
is
kind
of
stuck
I'm
waiting
for
the
technical
writer
teams
to
help
me
out
with
that.
Second,
one,
I'm
gonna
still
like
finish
the
third
one,
is
now
being
collaborated
into
not
scalability,
but
for
the
runbooks
and
basically
approach.
D
These
are
our
usage
of
the
future
facts
bit
of
I'm
not
sure
if
I'm
gonna
be
able
to
match
this
one,
I
guess
it's
like
the
fourth
one
is
like
50
50
at
this
moment.
Okay,
so
I
guess,
like
I'm,
fully
confident
in
second
one,
the
first
one,
it's
kind
of
like
I'm
blocked
right
now
and
the
third
and
the
first
one
I
guess
they
are
50
50.
A
A
D
Right,
I
guys
as
well
have
a
plenty
stuff
with
pages
and
like
discussions
and
things
like
that
that
they
are
not
really
reflected,
but
I'm
kind
of
communicated
that
I
will
be
less
available
during
this
week.
A
That's
it
so
the
recordings
are
going
to
the
cloud.
I've
pulled
them
down
this
morning.
I
haven't
had
a
chance
to
upload
them,
but
I
will
upload
them
and
unfiltered.
A
D
Yeah,
it's
because,
like
we
started
this
meeting
like
twice
yeah
and
like
it,
was
like.
A
Yeah
I'll
make
sure
the
right
one
gets
uploaded
and
I
was
reading
through
the
the
transcript.
There
were
some
pretty
funny
texts
in
there.
I
will
I'll
share
them
internally,
so
you
all
can
see
what
it's
translating
your
words
into.
So
there
was
some
comment
about
creating
a
dog
in
there
somewhere.
So
I'm
sure
that's
not
what
we
talked
about,
but
and
then
so
there
is
an
ongoing
switching
topics.
A
There's
an
ongoing
effort
to
take
a
look
at
mr
rates
across
enablement
because
we
are
as
a
section
lower
than
most
other
development
teams,
and
it's
basically,
they
just
want
to
know
why
we've
talked
about
it
several
times
by.
We
I
mean
me
christopher
and
john,
and
the
request
is
to
just
give
more
information
as
to
why
we
are
different,
sir.
I
think
enablement's
hovering
around
eight
and
the
goal
for
all
sections
is
10
to
13,
I
think,
is
the
new
range
and
new
targets.
A
So
I'm
doing
some
analysis
based
off
the
data
and
found
a
couple
data
points.
I
think
the
one
that's
going
to
be
interesting
is
the
one
that
I
haven't
approached.
Yet
it's
when
we're
context.
Switching
so
I
started
gathering
when
we
started
working
on
big
projects
throughout
the
year
like
when
we
switched
to
project
import.
A
So
again,
as
I
said
many
times,
I'm
not
too
concerned
about
our
mr8,
because
we
have
reasons
why
we
have
a
sine
wave
almost
of
our
mr8
throughout
the
year.
And
basically
this
is
just
going
to
document.
Why
we're
different
than
future
teams
so
and
if
you
all,
have
any
suggestions
on
maybe
areas
that
I
can
investigate
or
provide
more
documentation?
Please
feel
free
to
add
comments
to
that
epic.
E
A
developer,
who
picks
it
up,
will
waste
quite
a
bit
of
time
trying
to
figure
this
out
by
themselves,
which
then
in
turn
reduces
the
the
mr
rate
because
mrs
are
bigger.
So
I
don't
know
if
that's
an
issue
in
in
memory,
but
that's
maybe
also
something
to
at
least
for
me
to
to
look
into
how
how
I
can
help.
A
That's
within
the
epic
seems
like
there's
a
lot
of
issues
written,
but
unless
I
compare
it
to
like
a
true
feature
team
to
see
like
the
comparison
between
product
manager,
writing
issues
and
the
team
writing
issues-
and
I
don't
know-
there's
there's
not
a
team
by
team
comparison
and
I
was
trying
to
look
to
see
if
there
were
natural
spikes
in
when
issues
were
created
like
once.
We
kick
off
an
initiative
or
there
are
a
bunch
of
issues
created
by
the
team
and
then
followed
by
mris
and
there's
nothing
super
conclusive
there.
A
C
Of
this
is
because,
because.
C
Pretty
well
very
well
structured
and
described
so
I
feel
like
the
direction
and
the
gen
yeah
the
general
like
where
we
want
to
be
is
always.
I
always
thought
it
was
very
well.
I
described,
but
then
often
like
the
how
to
get
there
like
the
stuff
that
actually
then
goes
into
issues
that
we
track
across
the
board
is
often
so
super
technical.
C
That
sometimes
I
think
it's
easier
if
the
developers
just
create
that,
and
then
we
have
like
probably
different
ways
as
developers
to
like
then
go
about
how
you
know
what
goes
in
an
issue
and
what
doesn't
and
usually.
C
You
know
that's
enough
context
for
me
to
pick
that
up
kind
of
so
like
for
me
as
a
developer.
I
didn't
feel
like
I,
I
didn't
have
enough
contacts
and
issues
apex.
I
always
felt
that
was
a
really
decent
so
but.
C
If
I
compare
this
to
a
product
team,
you
know
if
you
have
like
proper
user
stories.
You
know,
like
you
know
where
you
think
about
you
know
as
a
user,
I
should
be
able
to
do
this
and
that
and
then
here's
a
way
of
how
we
like
measure
like
if
that
was
successful.
From
from,
like
a
delivery
perspective
like
out
what
we
work
on,
is
it's
just
different
right
so
like
maybe
that's
why
we
don't
always
have
that
up
front
like.
A
A
The
individual
issues
are
not
broken
down
like
fabian
or
josh
are
not
a
month
ahead,
describing
what
features
we
are
going
to
ship
to
the
end
user
and
even
then
yes,
and
it
might
be
difficult.
You
know
to
matthias's
point.
A
Some
of
these
things
are
so
very
technical
that
it
may
be
difficult
to
get
that
far
ahead
and
also
a
lot
of
the
things
we
do
don't
require
feature
flags
either
right
features
as
they're
being
shipped
you're,
going
to
have
the
feature
flag,
mr,
to
set
up
and
tear
down
along
with
the
feature.
So
every
every
user
story
in
theory
for
a
feature
team
could
have
three.
Mrs,
so
again
we're
just
different.
A
E
I
think
one
one
other
comment,
so
I'm
super
happy
to
help
with
that
as
well.
Maybe
if
we
can
demonstrate
that
you
know
that
mra
rate
is
not
lower,
because
we
are
not
doing
many
of
the
best
practices
that
we
we
should
right.
That's
also
maybe
important,
but
as
far
as
I
understand
it,
mr
rate
is
exactly
that
right.
It's
velocity
right!
It's
like
how
many
things
do
you
do.
It
does
not
actually
account
for.
E
Do
you
do
the
right
things
right,
which
is
much
more
important,
and
so
I
think
it's
you
know.
I
think,
as
long
as
there
is
confidence
that
the
team
is
working
on
the
right
areas
and
doing
the
most
important
things,
that's
also,
I
think,
always
important
context
to
present
right
and
then
this
is
just.
This
is
the
nature
of
the
work
that
may
be
the
case,
but
also
in
my
experience
with
this
discussion.
E
A
And
this
came
with
a
caveat
right
that
there
was
no
question
that
the
teams
are
doing
the
right
thing
and
we're
highly
productive.
It's
just
christopher
and
chun
really
just
want
to
know
why.
So
how
so
how
they
can
communicate
up
that?
If
not
the
section
like,
if
not
enablement's
different,
how
are
the
teams
different
because,
like
distribution,
they
crank
out
at
mars,
they
have
no
problem
meeting
the
goal
rates
right,
yeah,
but.
A
You
know
version
of
dependency
right,
exactly
yeah
so,
and
I've
always
advocated
that
the
memory
team
and
the
database
teams
were
just
different
right.
We're
we're
gonna,
have
different
rates,
we're
going
to
fluctuate
and
they
just
wanted
to
have
one
last
communication.
I
don't
think
it's
going
to
be
one
last.
I
think
it's
going
to
be
a
regular
communication
that
we
just
need
to
inform
them
on.
So
that's
all.