►
From YouTube: 2020 11 09 Memory Team Weekly
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
episode
of
the
memory
team
meeting
jump
past
the
not
verbalized
topics.
Unless
there
are
any
objections,
I'm
just
I
was
gonna
run
through
the
board
real
quick.
A
All
right
so
for
this
milestone,
I
actually
grouped
them
this
time.
So
hopefully
the
subject
matter
would
go
through
each
one.
First,
so
you're
up
nicola
with
cash
sql
calls
the
first
one
load
balancing.
I
saw
that
you
ping,
are
you
labeled
for
a
group
database
and
I'm
I'm
sure
nobody
got
notified,
so
I
pinged
the
database
team
on
that
one.
Are
you.
B
B
C
Yeah,
so
so
this
is
the
parent
issue.
Basically,
for
all
that's
related
to
caching,
around
rescaling
images,
we
basically
broke
out
one
yeah.
D
C
Thank
you
exactly
this,
so
this
is
the
one
issue
we
broke
out
of
it,
which
will
just
replace
that
because
I
think
it
will
be
sufficient
to
just
do
this,
which
is
to
support
conditional
gaps
in
workhorse.
So
there's
an
mr
and
it's
actually
already
reviewed
eden
by
a
maintainer
in
workhorse,
but
we
said
because
I
really
struggled
to
add
test
automation
in
this,
mr
because
yeah,
like
the
initial
test,
suite
that
we
added
we
weren't
quite
sure.
C
Yet
you
know
what
we
were
doing,
but
back
then,
because
that
was
the
first
feature
we
worked
on.
So
I'm
reworking
the
whole
test
suite
in
another,
mr
that
is
also
in
mr,
but
I'm
waiting
feedback
for
this
still.
Then
we
want
to
merge
this
and
then
we're
going
to
rebase
all
that
work.
On
top
of
that,
because
I
think
it
will
be
easier
that
way
around
and
we
didn't
want
to
merge
something
that
isn't
well
covered
by
tests
yeah.
So.
F
Yeah,
I'm
working
on
this,
it's
quite
in
the
middle
because
I'm
currently
still
hitting
the
issue
with
implementation.
So
thanks
camille
for
your
suggestion
and
trying
it
but
yeah.
I
will
try
to
work
on
it
today
and
see
what
I
could
do
the
next
one.
Sorry
does
it
work
not
entirely.
It
seems
like
the
code
requires
a
full
file
to
be
present
so
end
of
file.
I'm
currently
meeting
the
file
exception,
so
I'm
trying
to
figure
out.
Maybe
it's
my
problem.
F
C
Yeah
because
I
kind
of
realized
that
we
started
adding
these
bits
and
pieces,
you
know
across
several
code
bases
and
we
have
a
run
book-
that
I
need
to
remind
myself-
there's
no
issue
for
this,
yet
that
we
will
need
to
update
again
yeah.
I
I
don't
actually
have
a
super
specific
suggestion
like
how
or
where
we
will
document
this,
but
I
I
think
we
could
benefit
from
some
documentation
in
just
a
developer
or
contributor
docs
there,
especially
now
with
caching.
C
It
will
get
even
more
complicated,
so
yeah,
I
don't
know
what
what
everyone
else
thinks
about
it
do
because
I
wasn't
quite
sure,
should
we
look
at
this
as
a
feature
that
also
that
developers
might
frequently
interact
with
or
should
we
just
treat
it
really
as
an
implementation
detail
to
workhorse,
mostly
in
which
case,
maybe
we
it's
not
worth
documenting
yeah.
I
don't
know,
I
think
when
I
created
it
was
during
the
time
where
we
had
all
these,
mrs
popping
up
around.
C
Oh,
we
need
to
like
set
this
piece
of
config
and
omnibus,
and
that
piece
of
config
and
helm
charts
and
then
you
know
we
need
to
go
back
and
like
here
change
this
header
and
rails,
and
you
know
this
and
stuff
and
workhorse
as
well.
It
feels
like
yeah
or
maybe
that's
just
part
of
the
handover,
for
whoever
we
will
hand
this
over
to
to
really
be
zero
there,
but
it
seems
like
someone
who
is
not
familiar
intimately
familiar
with
how
it
was
built,
might
have
a
hard
time
like
piecing
us
all
together.
A
I
think
I
think
this
is
worth
following
up
on,
because
do
we
have
like
the
the
issue
that
alexia
was
just
talking
about
the
ops
flag?
Is
that
documented.
A
E
C
Yeah,
that's
a
really
good
point.
I
had
forgotten
about
this
almost
because
when
we
set
out
to
build
this,
it
was
meant
as
like
a
really
an
implementation
detail,
but
then
kind
of
eight
percent
of
the
project.
We
decided,
oh
some
of
us
config.
Maybe
we
actually
want
to
expose
that
to
admin,
so
they
can
fine-tune
their
so
so
now
it's.
It
is
actually
at
least
admin
facing
in
a
way
because
there
is
a
piece
of
workhorse
config
that
you
can
where
you
can
tune
this
thing
so
yeah.
That
should
definitely
be
documented.
C
F
C
I
mean
I'm
definitely
sure
that
we
did
not
really
think
about
what
will
happen
if
we
set
this
to
zero
because
it
was
not
expected
to
be
set
to
zero
but
yeah.
I
think
now
that
you
mentioned
it
you're
right,
zero,
meaning
we
will
just
always
we.
It
will
just
not
run.
It's
basically
like
a
feature
toggle
inside
of
workhorse,
but
it
was
not
in
a
way.
It's
just.
I
H
A
All
right,
yeah
good
call
on
creating
that
issue,
so
thank
you,
matthias
camille,
you're
up
with
some
feature
flag
updates.
Yes,.
E
So
I'm
kind
of
like
waiting
for
axi
to
help
me
out
on
that
the
second
one
I
did
not
hit
open
an
issue
like
mr
to
remove
that
I'm
just
gonna
remove
that
future
flag
strike
ops.
There
is
this
discussion
about
the
round
book,
so
I
plan
to
basically
close
that
this
milestone
it's
still
on
track
and
these
arrow
usage
of
the
feature
flight.
Without
definition,
I
am
actually
have
another,
mr
open,
that
is
going
for
review.
E
So
my
only
like
worry
is
like
this
dog's
table,
because
I
don't
know
exactly
if
it's
gonna
materialize
or
not
to
be
honest-
and
I
also
created
another
issue
for
seasons
scraping
basically
so
because,
like
okay,
I
created
a
bunch
of
dishes,
some
of
them
are
served.
Some
of
them
are
open.
For
example,
I
I
open,
mr
today
to
update
my
son
of
all
feature
flights
that
I'm
able
to
update.
E
So
there
is
like
this,
mrs
waiting
for
being
merged,
because
we
have
each
of
the
feature
projects
do
not
have
like
defined
milestone,
but
the
like.
From
the
statistical
point
of
view,
we
need
to
push
the
data
into
sizes
so
like
we
could
basically
for
let's
say
memory
team
dashboard
on
the
periscope.
E
So
a
nice
graph,
hey
your
team-
has
that
amount
of
the
future
flags
that
some
of
them
are
still
to
this
milestone
and
some
of
them
are
disabled.
So
I'm
kind
of
like
trying
to
figure
out
exactly
what
it
takes
to
push
that
into
systems,
and
there
is
like
the
data
issue-
sorry
github
data
issue
created
for
that
particular
purpose
to
to
push
that
there.
So
we
could
kind
of
enforce
each
team
like
with
this
extra
metric
that
they
could
graph
over
time
and
with
the
feature
flags.
E
E
C
Problem,
I
was
just
thinking
it
might
be
good
when,
once
I
get
back
to
the
caching
stuff,
I
actually
wanted
to
that's
not
urgent,
but
I
wanted
to
spend
some
time
actually
writing
some
docs
on
how
http
caching
works,
because
it's
very
confusing
right
now.
So,
if
there's
anything
else
that
might
fit
that
piece
of
documentation.
D
C
No,
it's
not
not
to
do
with
how
http
caching
works,
but
like
how
it
is
implemented
in
gitlab
is
super
messy.
It's
really
hard
to
understand.
C
A
Okay
and
we-
I
didn't
catch
this
on
the
logging
issue,.
C
A
C
This
fell
out
of
the
observability
work
like
when
we
shipped
that
dashboard
for
image
scaling.
We
tripped
our
app
decks
threshold
straight
away
because
we
had
a
whole
class
of
errors
that
totally
went
unnoticed
and
they're
not
like
critical,
like
we
were
quite
yeah.
C
We
were
quite
strict
as
well
like
in
in
the
scale
implementation,
so
we're
actually
rejecting
a
bunch
of
requests
currently
that
we
think
we
probably
don't
have
to
reject
that's
right,
yeah,
that's
what
alex
is
working
on,
and
so
what
we
realized
was
it's
way
too
hard
to
see
like
what's
going
on
and
like
what
these
errors
are.
C
So
we
said
we
want
to
look
into
improving
logs
there
and
it's
actually
quite
messy
in
workhorse
in
general,
because
we
have
this
multi-line
logging
approach
and
the
tags
are
not
inconsis
are
not
consistent.
So
it's
yeah.
It's
like
always
a
bit
of
a
patchwork
to
look
at
the
unlocks
in
cabana.
So
I'm
trying
to
I
had
a
catch-up
call
with
andrew
and
he
he's
amazing,
like
he
has
always
such
great
insights
on
observability
and
how
to
run
these
things
operationally
like
a
little
bit
easier.
C
So
I'm
just
starting
with
that
and
then
see
where
that
goes.
Okay,.
A
C
I
don't
know
what
to
do
with
this
action:
cable
stuff,
because
it
I
mean
it
keeps
coming
up
and
I
spend
time
on
it
occasionally,
but
it
feels
like
it's
just
dragging
on
for
like
forever,
so
I
might
have
to
spend
more
time
on
it
this
week,
because
we're
kind
of
blocked
there
again
from
rolling
this
out.
Okay,
so
yeah,
it's
kind
of
open.
A
Question
yeah:
well,
I
think
they'll
be
bandwidth
for
other
topics,
but
as
long
as
you
don't
think
it's
too
consuming,
but
we
can
talk
about
that
later
if
we
need
to
all
right
jump
back
in
so
for
next
week.
So
I
put
the
topic
up
there.
It
looks
like
folks
have
added
some
lines
in
there
camille
you
want
to
verbalize
your
first
comment
here.
E
Yeah
so,
like
my
first
question
is
really
like:
are
we
rather
like
to
disconnect
from
anything
else
that
can
be
disturbing
and
focus
only
on
the
titan?
I
think
like
that,
for
this
to
be
successful,
we
should
not
spend
any
time
except
this
topic.
Basically.
So
the
question
is
to
everyone
here,
like
how
confident
you
are
like
on
wrapping
up
and
really
focusing
on
this
single
focus.
C
But
camille
do
you
mean
just
being
focused
during
that
week
or
do
you
mean
wrapping
everything
up
and
then.
E
E
C
C
C
I
I
will
have
to
communicate
with
the
action
cable
working
group
because
I'm
not
totally
sure
what
the
timeline
is
by
now
because
it's
stalled.
So
I
don't
want
then
them
to
think
they
need
to
rely
on
me
during
that
week.
But.
E
E
So
I
think
like
as
long
as
we
can
like
announce
all
the
parties
that,
like
we
are
not
available
during
that
time,
unless
there
is
like
some,
I
don't
know,
s1
p1
emergency
and
it's
kind
of
like
epics
everything
else.
E
E
Like
requirements,
it's
like
mine
perception
what
we
should
do
like
you,
don't
have
to
agree
with
my
perception
I
feel
like
you
are
fine
like
to
have
some
other
perception,
but,
like
my
perception
is
like
we
are
focusing
on
the
memory
and
we
want
to
solve
like
the
real
world
problem,
which
is
like
github
running
on
premise,
very
likely
on
the
omnibus.
E
So
I
I
kind
of
wrote
this
perception
of
the
requirements.
Keeping
that
in
mind,
I
don't
care
how
much
cpus
we
have.
We
can
have
16
cpus,
but
only
two
weeks
of
the
memory,
if
this
help
us
to
have
faster
iteration
because
of
the
compile
time
or
whatever
I
I
mean
like.
I,
I
want
to
ask
to
focus
on
this.
Two
gig,
like
like
memory
limit,
probably
starting
even
like,
with
the
higher
limit
to
get
like
an
an
overall
sense.
E
I
mean,
like
it's
completely
acceptable
to
use
development
environment
to
like
to
to
trying
different
aspects,
but
I
think
in
general
like
I
would
consider
this
to
be
a
success
if
we
would
be
able
to
run
github
in
some
form,
maybe
not
complete,
it
doesn't
have
to
be
completely,
doesn't
have
to
have
like
all
functions
but
like
the
the
most
important
ones,
on
like
two
gigs
on
the
end
of
the
week
and
like
kind
of
rounded
with
the
omnibus-
maybe
not
perfect,
but
have
it
somehow
functioning
to
some
extent,
of
course
like.
E
If
you
would
run
github
ce.
It's
gonna
be
much
easier
because
of
a
much
smaller
amount
of
the
dependencies
and
everything,
but
we're
going
to
really
what
we
I'm
looking
at
is
like
figuring
out
the
major
aspects
of
the
this
installation
where
we
can
optimize
or
like
what
components
take
the
most.
But
we
can
maybe
what
gems
we
can
remove
from
the
github
to
be
much
more
far
very
favorable
in
this
two
gig
installation-
or
we
can
just
say.
E
Maybe
at
the
end
of
the
week
we're
gonna
say
like
two
gigs
is
like
not
doable,
but
three
gigs
is
fine
and
it
works
mostly.
It
can
be
also
our
outcome,
I'm
kind
of
assuming
that
it's
there
is
some
way
to
run
it
on
the
two
gigs,
it's
maybe
very
hacky,
so
I'm
really
looking
to
have
as
close
as
the
production
and
as
as
hacky
as
possible
to
get
the
goal
running.
E
It
may
be
unrealistic
to
see
that
in
the
end,
but
I
I'm
looking
at
achieving
the
goal-
I'm
not
too
figuring
out
exactly
how
to
see
that
we're
gonna
figure
out
that
next,
like
later,
when
we
have
like
a
back
of
different
ideas,
what
we
can
change
in
gitlab.
C
Right,
I
have
one
question
if
we
wanna,
because
to
make
it
to
make
that
easy
as
well
I
from
past
experience,
I
found
it
super
hard
to
hack
on
omnibus,
whether
that
be
local
or
even
in
gcp,
I
saw
you
had
a
preference
for
using
gcp,
so
people
spin
up
their
own
vms
I'm
up
for
that.
We
should
probably
make
sure
that,
probably
before
we
go
into
that
week,
everyone
on
the
team
is
familiar
with
how
to
do
that,
and
also
I
I'm
not
totally
sure
how
easy
it
is.
C
Like
last
time
I
played
around
with
this
I
mean
I,
I
was
able
to
fairly
easily
install
a
prebaked
image
from
gitlab
registry,
but
these
take
over
an
hour
to
build.
So
if
we
want
to
iterate
quickly
and
hack,
I
I'm
not
totally
sure
what
a
good
workflow
is.
I
think
we
should
kind
of
try
to
figure
these
things
out
before,
so
that
we
can
be
productive
kind
of
on
day
one.
C
So
maybe
we
can
spend
some
friday
during
the
office
hours,
maybe
or
in
some
other
time
slot
to
maybe
figure
out
a
good
like
work
loop
right.
If
we
want
a
heck
of
an
omnibus,
because
I've
also
used
the
omnibus
builder
in
the
past-
and
I
never
was
able
to
make
it
work
properly-
and
I
know
other
people
had
similar
struggles
and
I
would
hate
if
we
would
lose
a
day
over
this.
You
know
basically.
E
E
Try
to
configure
that
together,
see
where
we
are
at
so
like
we
could
start
with
the
issues
on
the
monday
and
yeah
approaches,
because,
like
I'm
kind
of
like
thinking
that
on
this
friday,
what
we
could
spend
on
is
like
create
the
say,
read
me
or
or
faq
of
the
steps
for
us
to
like
to
replicate
what
we
are
doing
and
have
this
like
as
a
single
source
of
truth
and
then
like.
If
anyone
gets
stuck
at
any
point,
it
could
go
through
this
faq
and
like
reprovision
everything
in
using
that.
E
So
I'm
kind
of
assuming
that,
like
we'll
just
spend
the
friday
on
having
these
games
for
each
of
us,
we'll
together,
try
to
install
that
run.
It
initially
get
some
initial
sense.
Try
to
tinker
and
change
different
aspects
of
the
omnibus
on
github,
maybe
live,
maybe
some
other
way
and
figure
out
a
little
like
toolset
that
we
may
use
to
these.
To
this
like
investigation,
I'm
kind
of
like
matias.
E
I'm
kind
of
certain
that,
like
omnibus,
will
not
make
it
quick
to
test
all
of
the
aspects,
but
I
think
like
in
the
end
what
I
would
like
to
see
like.
If
we
get
something
running
locally
in
the
development,
we
try
to
replicate
it
on
the
omnibus
to
see
exactly
how
it
this
trend
behaves
in
the
production
environment,
which
is
like
something
much
closer
to
the
production
that
we
can
ever
get
with
the
dck
gdk
or
whatever
else.
E
I
E
Though
it's
much
closer
but
like
I'm
kind
of,
I
think
that
my
primary
focus
like
is
like
solve
the
real
world
problem,
not
like
the
artificial
problem
that
we
are
creating
by
adding
another
layer.
Basically,
that's
that's.
That's
primary
goal.
C
No
I'm
totally
with
you
there.
I
I
just
wanted
to
point
out
that
I
I
did
try
it
in
the
past
to
yeah
move
some
of
the
testing
debugging
performance
testing
to
omnibus,
and
it
was
just
not
straightforward,
so
yeah,
but
as
long
as
we
like,
we
will
figure
it
out
somehow
on
friday
to
just
have
a
good
workflow
that
we
can
validate
these
things.
E
G
But
from
from
my
experience
with
geo,
it's
probably
really
worthwhile
setting
these
things
up
ahead
of
time,
because
it
can
be
a
bit
tedious,
there's
also
all
sorts
of
automation
around
by
now.
I
think
grant
knows
more
about
than
I
do,
but
it's
it's
definitely
something
to
do
ahead
of
time.
E
So
maybe
some
of
this
stuff
is
going
to
fail,
but
to
have
some
like
baseline
measurement.
Really
of
that.
So
I
think
we're
gonna
have
pretty
interesting
fighter
to
to
figure
out
these
aspects
about,
like
omnibus
vms,
that
we're
gonna
be
using
tinkering
with
touring
and
also
probably,
how
are
we
gonna,
be
performance,
testing
really
or
like
how
we're
gonna
be
like
trying
to
be
analytical?
Really,
I
guess
this
is
this
is
my
expectation.
C
Yet
do
we
want
to
look
at
the
actual
physical
memory
consumption
that
we
see,
or
are
we
looking
at
these
kind
of
more
vanity
figures
like
rss,
which,
like
a
lot
of
users,
will
look
at
right?
So
we
because
that
can
be
tricky
right,
because
if
you,
if
you
in
actual
physical
memory
use,
you
might
be
lower
than
whatever
the
sum
of
the
rss
reports
are
by
the
all
the
different
processes
right.
F
The
idea
is
to
run
on
two
gig
box,
since
we
are
like
trying
to
solve
when
there
is
this
marketing
component
in
it.
So
it
should
be
running
more
or
less
normally
in
this
to
gig,
whatever
it
sets
by
google
cloud.
E
So
it's
tricky
because,
like
you,
could
have
much
higher
memory
limit
with
the
swapping,
but
if
you're
gonna,
like
yeah
hdd
type
of
the
drive,
this
happens,
gonna
be
terrible.
E
E
I
think
we
will
be
looking
at
the
round
number
like
what
is
like
the
memory
pressure
and
like
how
many,
because
I
I
I
kind
of
expected
that,
on
the
two
gigs
we're
gonna
have
to
configure
some
kind
of
swapping.
It's
like
it's
unrealistic
to
not
run
to
run
without
swap,
but
there
is
a
number
of
the
metrics
which
is
like
what
was
this
net
metric
memory,
validation
or
something
like
that.
That
shows
you.
How
often
system
has
to
reach
the
swap
to
to
to
get
the
data?
E
So
probably
this
could
be
our
magic.
How
severe
is
the
swapping
on
the
two
gig
when
we
are
running
some
kind
of
performance
testing
or
like
how
many
requests
we
can
run
with
the
performance
testing
like
for
the
let's
say,
1k
architecture
that
has,
I
don't
know
four
gigs,
I'm
throwing
that
out
of
the
out
of
the
head,
but
I'm
kind
of
really.
E
I
think
it's
less
important,
how
much
memory
we
use
in
the
end,
but
how
how
performant
is
gitlab
during
that
time?
Can
it
actually
like
run
this
amount
of
the
users
on
the
two
gigs,
because
if
we
are
swapping,
but
this
is
infrequently
access,
swap
it's
not
really
like
the
week
of
the
deal
really
yeah?
I
I
mean
like
it's
still
like
we
are.
E
We
have
over
two
gig
limit,
but
I
think
that
2g
cleaning
is
really
about
like
making
github
installation
usable
on
the
2
hit,
but
not
achieving
like
2gig,
because
like
if
you
would
set
memory
killer
to
500
max
will
be
constantly
swapping,
but
it
it
would
not
be
like
using
two
gigs
even
but
it
would
be
not
usable
at
all
as
well.
So
you
know,
I
think,
like
the
two
geeks
is
like
the
the
limit
of
the
size
that
you
have,
but
whatever
tricks
you
you,
you
do
to
make
guitar
be
performant
on
these
students.
E
It
could
be
like
with
swapping
with
the
memory
compression.
It
could
be
like
with
some
system
tuning
or
something
like
that
about
how
the
swappiness
is
behaving
and
how,
like
the
this
eviction
policy,
is
behaving
so.
E
It's
it's
like
the
match.
We're
gonna
probably
have
two
metrics
like
the
raw
memory
usage
and
like
the
actual
user,
easy
good.
F
A
Are
we
on
to
logistics?
I
think
we
talked
about
most
of
this,
so
we
have
initial
set
of
issues.
We
have
scoring
criteria
out
there.
So
take
a
look
at
those
issues
prior
to
friday
or
monday.
I
suppose
logistics.
I
asked
a
question
about
daily
sync:
camille
said:
yes,
you
feel
like
daily
sync
would
be
beneficial
and
picked
a
time.
Does
that
time
work
for
everyone
to
know
ten
or
one
sorry,
ten
or
eleven.
H
E
F
Okay,
which
one
earlier
or
later
time,
then
I
would
probably
what
someone
who
starts
later
than
you
like
in
my
time
it's
12
00
am
9
am
gmt.
I
would
what
10
am
gmt
is,
if
you're
not
against
it.
B
A
K
It's
the
goal
to
make
gitlab
itself
run
under
2gig,
or
is
the
goldsmith
get
that
run
on
the
box?
That
has
two
gig.
E
So
I
would
assume
that
we're
gonna
have
vm
that
has
two
gig
memory:
image:
yeah,
that's
fine!
That's
what
we'll
start
with
that!
That
has
like
two
gig
on
the
vm
and
see
exactly
how
how
it
works.
J
K
Yeah,
it
gets
a
little
bit
fuzzy
when
it
comes
to
different
operating
systems
and
how
much
memory
they'll
need
in
general
use,
maybe
not
even
initially.
Sometimes
they
might
need
more
memory
depending
on
what
processes
are
running
in
the
background,
so
I
think
it's
still
a
good,
I
think,
to
draw
a
line
in
the
sound.
It's
still
good
to
aim
for
a
two
gig
box.
K
That
makes
sense
because
you
can
have
the
physical
requirement,
but
you
just
to
call
it
that
you
might
need
to
target,
get
lab
lower
to
make
it
work
as
nice
as
possible.
So
you
could
be
our
target
1.8
or
1.6
and
depending
on
how
aggressive
the
barrel
s
is,
although
I
don't
I
don't
sweat,
1.6
would
be
needed.
That's
pretty
low.
C
Yeah-
and
I
mean,
of
course,
like
you
know,
we'll
see
how
it
goes
like
you
know,
but
the
other
aspect
to
this
is
that
you've,
probably
seen
by
now
the
chart
that
chinu
posted
about
the
last
six
months
or
so
so,
the
last
six
iterations
or
releases
of
memory,
growth
that
we've
seen
it's
going
up
and
up
and
up
right
with
every
milestone
release.
I
forgot
by
how
much
the
center
percent.
E
C
But
like
that's
something
to
keep
in
mind
as
well
right,
so
if,
if
we
like,
if
we
were
to
able
to
squeeze
it
just
under
you
know
just
onto
this
vm
or
box
or
whatever,
it
might
not
work
with
the
next
release,
yeah,
because
we
keep
growing
the
app
as
well.
So
that's
something
else
to
give.
C
A
And
all
those
choices
and
decisions
and
caveats
they're
all
we
should
document
them
all
so
that
all
of
our
stakeholders
know
like
gitlab
will
run
if
you
do
all
of
these
things,
and
it
will
only
run
if
we
stay
stay
stable
and
don't
continue
with
the
memory
growth
that
we're
seeing
historically
over
time.
All
that
needs
to
be
documented.
So
it's
not
okay.
We
can
run
on
two
gigs
forever
and
even
if
you
know
ultimately,
we
find
we
can't
what
stopped
us
from
getting
to
that
goal.
A
H
G
All
right,
I
had
a
couple
of
questions
regarding
boards
and
the
location
of
things,
which
is
obviously
very
exciting.
Is
this
a
good
time
to
ask
yeah
okay,
so
I
am
just
trying
to
get
an
overview
of
where,
where
things
are
at
and
we
have
some,
I
mean,
as
you
probably
aware,
from
josh
some
external
constraints.
You
know
when
we
need
to
do
some
videos
and
whatnot,
so
the
purpose
is
not
to
say
this
is
how
we
do
it.
G
G
So
can
you
see
my
screen
yeah?
Okay,
so
I
went
through
some
of
those
bits
here
and.
G
So
what
I've
seen
today
in
the
in
the
call
is
that
you,
you
have
a
sort
of
a
board
that
lists
all
of
the
issues
by
milestone,
and
you
also
have
one
that
lists
things
by
priority
if
you
set
the
labels
correctly.
So
my
first
question
is:
is
this
one,
for
example
here
where
you
have
issues
sort
of
grouped
by
priority
for
memory?
Is
that
something
that
you
use
regularly.
G
Helpful
because
then
that
allows
me
to
know
where
I
need
to
look,
because
I
also
try
to
find
things
here
in
the
and
this
one
and
there
is
a
kind
of
discrepancy
between
what
is
labeled
in
the
workflow
here
and
what
is
actually
in
the
sort
of
milestone
board.
G
A
A
G
A
Yep,
I
was
gonna
say
during
the
meeting,
but
I
was
at
least
gonna
say
asynchronously
we're.
It
looks
like
we're
inconsistent
on
our
workflow
labels.
I
was
just
part
of
reviewing
that,
mr
for
updating
our
product
development
workflow.
A
So
it's
probably
something
we
can
get
better
at
adding
you
know
was
a
flowy
in-depth
workflow
in
review
on
our
issues
getting
better
at
that
by.
F
G
G
You
have
to
update
the
issue
and
you
have
to
do
it.
K
G
Yeah,
okay,
so
this
is
the
board
and
so
for
13.6.
Is
this
roughly
stack
ranked
by
priority,
or
is
it
essentially
a
these?
Are
the
things
we're
going
to
work
on
people
are
assigned
to
them
and
then
every
week
you
kind
of
go
through
this
and
provide
an
update,
just
as
you
did
in
this
meeting.
A
They
are
not
stack
ranked,
we
have
tried
stack
ranking
in
the
past,
but
it
kind
of
fluctuates
so
today
what
I
did
instead
was
just
group
it
by
effectively.
A
Our
swim
lane
functionality
is
not
quite
there
yet
and
we
don't
always
walk
the
board.
Typically,
we
give
like
a
high
level
overview
and
then
kind
of
dive
deep
where
we
need
to,
but
usually
like
the
week
before
I
like
to
go
in
and
walk
the
board
to
make
sure
we
didn't
miss
anything
and
that's
about
where
we
are
in
the
milestone
right
now,
cool.
G
This
is
the
our
ideas
for
what
will
be
prioritized
next
milestone
and
that's
probably
in
need
of
updating
roughly
before
we
actually
make
the
video
okay
that
helps
already,
because
that,
at
least
for
now
makes
it
a
lot
simpler.
For
me,
I
can
ignore
these
other
boards
and
I
think,
just
for
in
geo
we
use
these
workflow
labels
a
little
bit
more
consistently.
G
One
thing
that
we
do,
I
can
just
show,
show
you
it's
like
I
I
personally,
I
really
don't
like
these,
like
gazillion
of
open
issues
and
open
and
closed,
it's
super
messy,
so
one
thing
that
I've
done
with
geo
is
we
have
this?
You
know
we
hack
the
label
system.
We
have
a
geoactive
label
that
I
apply
to
things,
which
is
everything
that
actually
people
will
work
on
right
rather
than
the
entire
backlog
in
in
open,
which
keeps
the
board
pretty
clean.
G
So
we
can
talk
about.
You
know
if
this
makes
sense
to
change
at
some
point
or
not
at
the
moment.
I
think
for
the
next
couple
of
weeks.
While
I
acquaint
myself
with
all
of
this,
I'm
just
going
to
read
all
of
those
issues
right
and
we're
going
to
talk
about
what's
next
and
then
we
can,
we
can
go
from
there,
but
that
helps
one.
Other
question
is
just
because
I
I've
seen
some
of
it,
but
I'm
not
quite
sure
where
we
are
with
this.
G
Do
you
use
epics
to
group
work
yeah,
because
I
I
I'm
a
big
fan
of
of
epics
and
also,
I
think,
similar
to
what
camille
sort
of
proposed
for
next
week
is
to
like
group
things
into
an
epic
and
then
maybe
focus
on
a
few
epics
at
the
time,
so
that
the
focus
of
a
you
know,
group
is
okay.
This
is
the
image
scaling
work
that
we're
focusing
on
which
is
in
this
epic,
and
you
know,
then
you
close
everything
out
from
that
and
it
provides
a
bit
more
context.
G
So
that's
that's
good
because
I
I
think
I
can
help
with
some.
G
I
think
also
for
transparency,
given
I'm
doing
this
for
database
as
well,
but
I'm
I
I
am
happy
with
some
flexibility
as
long
as
it
works
for
for
the
team
right.
So
you
know
if,
if
we
use
certain
things
or
don't
do
certain
things,
because
you
find
them,
you
know
bothersome
and
not
productive,
then
that's
fine
with
me.
I
think
my
main
ask
is
that
we
are
moderately
consistent.
You
know.
G
So
if
we
don't
use
certain
things,
then
we
don't
and
if
we
do
use
them,
then
we
actually
end
up
doing
them,
because
otherwise
it
gets
really
confusing
yeah
cool
that
helps,
I
think
I'll,
do
the
reading.
I'm
super
excited
for
your
one
week,
research
sprint
or
what
I
whatever
the
correct
terminology
is,
I
think,
that's
a
great
idea.
G
I've
done
some
sort
of
design
sprints
in
the
past,
where
a
team
sort
of
it
was
more
structured
but
met
for
a
week
to
find
a
solution
to
a
product
problem,
and
these
things
tend
to
be
highly
productive.
If
you
actually
shut
yourself
away
from
the
rest
of
the
world
and
only
focus
on
this,
so
cool
thanks,
yeah
and
I'll
work
with
craig
and
and
you
to
you-
know,
figure
out
this
week.
What
we're
going
to
announce
for
13.7
and
and
stand
in
front
of
the
video
camera
for
10
minutes.
G
Yeah,
no
I'll,
thank
you
in
slack
and
if
you
need
any
direction
from
me
or
you
need
somebody
to
talk
to
a
customer
or
or
anything
like
that,
then
feel
free
to
ping.
Me
I'm
happy
to
happy
to
help,
and
if
it's
about
release
posts,
shenanigans
and
merging
things
like
that,
you
can
also
always
ping
me
and
I'll
be
happy
to
to
get
these
things
going.