►
From YouTube: 2021 01 18 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
B
Yeah
I
just
wanted
to
update
on
github
exports
for
that
one
more
much
request
which
droppings
matrix
was
merged
today
and
I
had
another
mesh
request
which
removed
support
which
was
producing
this
matrix,
but
I
was
waiting
for
the
mentioned
camera
to
be
merged,
so
I
will
pick
it
up
in
parallel
with
puma,
but
it's
not
factored
because
it
won't
affect
performance
itself.
It
just
clean
up.
C
Yes,
yeah,
I
was
working
on
the
configuration
switch
that
would
allow
us
to
swap
out
the
rack
server,
which
we
first
had
thought
was
the
main
offender
in
terms
of
memory
use
turns
out
it
wasn't.
It
was
it's
like
it
was
my
mistake
to
be
honest,
like
I
should
have
spent
more
time
on
actually
validating
that
hypothesis.
It
sounded
very
reasonable,
so
I
kind
of
yeah
I
ran
some
experimentations
and
benchmarks,
and
webrick
came
out
using
less
memory.
C
It's
this
is
so
tricky
to
measure
the
stuff
and
it
turned
out
that
it
was
again
a
similar
problem
to
what
we
had
experienced
with
the
main
app
that
if
you
actually
run
these
experiments
over
a
longer
period
of
time
and
actually
swings
pretty
widely
and
yeah,
so
it
was
actually
not
conclusive
in
the
end,
so
camille
found
a
different
way
to
get
memory
use
down,
which
works
equally
well
for
any
of
these,
so
this
is
now
kind
of
like
reduced
to
a
nice
to
have,
but
it's
done
anyway.
C
So
I
thought
you
know
why
not
ship
it
yeah,
there's
also
that
2mrs
open
one
is
the
main,
mr
for
omnibus,
which
is.
It
is
reviewed,
I'm
just
waiting
for
folks
to
merge
it.
So
I
don't
know
if
it's
going
to
make
13.8
and
that
is
there's
also
the
corresponding
ducks
doc
dox,
mr,
which
is
kind
of
yeah.
We
need
to
merge
these
together
because
one
doesn't
make
sense
without
the
other
yeah.
That's
it.
B
So
about
nakayoshi,
it's
in
maintainers
review,
so
yeah,
just
waiting
for
standard
review
and
thanks
team
for
the
feedback
was
great
about
puma
single.
I
just
started
today,
so
I
underestimated
nakayoshi
worked
because
there
were
a
lot
of
mesh
requests
and
a
lot
of
like
verification
needed
to
be
done.
So
I
just
asked
the
question,
and
I
see
camille
and
matthias
the
milan
spirit
that
I
probably
will
start
with
measurement
and
then
I
will
try
to
fix
the
application
and
I'll
get
broken
like
boom
soon
right.
A
C
We
definitely
need
to.
We
did
a
lot
of
like
ground
work
now,
and
then
we
can
circle
back
to
looking
into
gc
tuning
the
main
app.
It
was
just
really
difficult
to
do
it
initially.
So
all
of
these
things
will
help
with
that.
C
So
one
thing
I
added,
though,
is-
and
that
will
also
help
with
this-
is
it's
kind
of
difficult
right
now,
not
difficult,
but
it's
cumbersome
to
run
puma
in
single
mode,
because
you
always
have
to
go
into
your
omnibus
instance
and
comment
out
this
initializer
that
checks
that
you
never
run
gitlab
with
less
than
one
worker
right.
It's
kind
of
like
a
safety
guard
right
and
so
yeah
camille
had
a
very
pragmatic
suggestion.
Why
don't?
We
just
add,
like
a
development
switch,
you
know
undocumented
just
for
us.
C
It
allows
us
to
bypass
this
until
we
actually
support
single
mode,
because
I
don't
think
we
should
wait
for
that.
It's
just
a
little
like
quality
of
life
improvement,
so
I
sent
out
nmr
for
this
just
now.
Well,
you
could
just
send
an
environment,
set
an
environment
variable
and
we'll
bypass
that
initializer.
E
E
If
you
want
to
move
all
the
specs
in
the
in
the
engine
itself,
then
you
will
need
to
mimic
all
the
dependencies
from
the
main
application
to
the
dummy
application
which,
like
increase
the
complexity
of
the
solution,
and
it
will
be
really
difficult
in
the
future,
because
these
engines
will
grow
in
time
and
adding
new
stuff
will
be
more
complicated.
So
I
discussed
it
last
week
with
camille
and
we
found
a
way
how
to
still
split
those
specs
without
moving
all
those
dependencies
in
the
engine
itself.
E
So
I'm
currently
working
I'm
still
working
on
it
like
the
solution,
seems
to
work,
but
I
will
still
need
to
fix
some
of
the
specs
and
then
the
next
step
is.
It
will
be
really
nice
that
we
measure,
like
the
memory
impacts
when
this
engine
is
loaded
and
when
it's
not
and
to
compare
with
our
base
base
metric-
and
I
will
still
need
probably
to
add
these
graphql
specs
to
this
another
ca
job.
So
we
can
run
all
the
specs
without
graphql
and
only
graphql
specs
separately
sca
jobs.
E
D
D
D
Let's
say
the
the
in
the
best
case
scenario,
minimal
memory
research,
so
I'm
kind
of
like
what
sages
you
to
like
think
with
the
matias
and
like
what
he
was
testing
to
translate
that
to
the
main
up
and
get
some
like
baseline,
like
measurements.
So
you
could
then,
like
nikola
could
use
this
config
as
well.
E
C
Yeah,
I'm
still
I'm
still
on
that.
I
just
I
just
took
like
more
than
a
week
of
detours
because
it
was
so
difficult
to
verify
any
of
these
hypotheses.
So
we
now
added.
C
We
now
changed
a
bunch
of
things
and
actually
the
work
and
gitlab
exporter
helped
us
as
well
to
understand
thanks
to
camille
like
he
he
he
did
a
really
great
job
like
looking
at
gc
settings
for
gitlab
exporter
as
well,
and
I
we
we
will
have
to
check
like
if
the
you
know
similar
similar
tweaks
will
work
well
for
the
main
app.
Maybe
not,
but
it's
a
good
lead.
You
know,
and
so,
if
we
can
yeah
make
the
test
results
a
bit
more
stable
so
that
we
can
actually
add
proper
before
after
comparisons.
C
You
know
we
have
that
new
endpoint.
Now
that's
already
on
master
on
main
and
what
else
was
there
yeah.
D
A
All
right
take
that
as
a
no,
so
this
next
item
came
from
a
one-on-one
during
my
conversation
with
bobby
on
and
we're
talking
about
what
is
the
success
criteria
for
running
gitlab
in
a
memory
constrained
environment
and
we're
going
to
talk
about
during
today's
meeting
fabian.
You
got
a
couple
comments
in
here.
Oh.
F
Yeah,
I
just
threw
them
in
there.
I
actually
forgot
that
we
spoke
about
it,
so
this
is
again
fully
on
top
of
things
here
so
like
these
are
just
some
some
high
level
comments
from
me.
I
think,
with
all
of
this
effort
and
feel
free
to
disagree.
This
is
really
up
for
discussion
right.
F
It's
like
it
may
be
worth
saying:
okay
at
any
point
in
time,
maybe
after
13.9
right
to
just
sort
of
stop
and
say,
given
all
of
the
things
that
we've
done,
you
know
what
are
the
things
that
we've
actually
improved
and
you
know
what
does
that
look
like?
It
may
be
a
more
complicated
answer,
but
at
least
I
think
at
that
point
we
will
be
able
to
say
okay.
F
This
is
this
is
the
impact
that
we've
had,
because
I
I
think
that
would
help
us
also
establish
you
know,
given
all
the
things
in
the
future,
you
know
like
how
much
more
work
is
that
right?
How
much
have
we
have
we
accomplished
to
this
point,
and
then
we
can
also
see.
Is
it
worth
continuing
on
that
path
and
then
something
completely
optional,
and
this
is
maybe
a
different
topic
altogether,
so
we
can
talk
about
that
is.
F
You
know
like
really
cut
these
things
out
and
then
also
add
that
to
to
our
evaluation,
because
it
may
be-
and
I
don't
again-
I
don't
know
right-
we
we
will
come
to
sort
of
a
conclusion
say
like
we
saved
you
know,
500
gigabytes
or
a
gigabyte
of
memory
just
by
making
these
improvements,
which
is
great,
but
if
we
just
disable
the
metric
stack,
because
we
think
it's
used
useless
for
this
use
case.
Specifically
we'll
save
another
350
megabytes
right.
We
don't
need
to
make
memory
improvements
to
this.
F
F
C
Yeah-
and
so
I
that
would
have
been
my
first
choice
as
well,
because
there's
definitely
some
there
would
be
some
real
gains
if
we
were
to
look
into
that
but
fabian.
What
would
be
your
feeling
after
we
had
caught
up
with
sarah
and
the
the
team?
The
monitoring
team
like
it
sounded
like
they
were
not
a
huge
fan
of
the
idea
of
you
know
not
running
this
by
default,
so
so
yeah.
F
I
appreciate
their
concerns
right
and
I
actually
I
share
some
of
them,
but
I
think
also
we
need
to
you
know.
I
think
the
the
question
is,
if
you
know
like,
if
it
would
take
us,
you
know,
let's
say
another
six
months
to
actually
get
to
this
goal
right
then,
by
making
improvements
right
or
we
could
actually
look
at
the
use
cases.
For
this
instance
and
say,
let's
just
disable
some
of
those
things
right
and
then
we
are
there
essentially
by
tomorrow.
F
F
I
think
it
would
still
be
valuable
to
to
make
that
statement
and
on
top
of
it,
I
think
camille
pointed
this
out
last
call,
I
think,
if
we
had
some
documentation
right
for
a
memory
constrained
instance
that
says:
okay,
you
know
these
are
some
of
the
changes
that
you
can
make
to
make
get
that
more
memory
efficient
right.
We
could
be
very
pragmatic
and
just
have
an
optional
section
and
say
here:
are
some
of
the
product
features
right
that
actually
consume
a
large
amount
of
memory?
F
This
is
how
you
can
disable
them
right.
If
you
don't
need
them
and
maybe
we'll
have
them
enabled
by
default
right,
but
we
we
may
just
be
able
to
give
some
documentation
for
people
to
actually
disable
it
either.
That
may
be
a
sort
of
a
cheap
way.
Out
of
that,
you
know,
and
I
think
that's
just
a
high
level
thought
I
I
was
just
contemplating
on
this
last
week,
a
little
bit
like.
Maybe
we
need
to
be
a
little
bit
more
decisive
and
and
say
like
in
this
regard
right,
it's
like.
F
Maybe
we
can't
have
everything
right
and
maybe
you
know
it's
okay,
but
we
don't
need
to
make
that
decision
for
everybody
either
right.
We
can
just
document,
that's
an
option.
It's
just
a
it's
a
different,
different
question.
D
I'm
kind
of
thinking
that,
like
we
could
consider
like
grading
like
memory
constrain,
we
could
start
like
what's
right,
like
with
the
four
gigs.
This
is
how
you
run
that
if
you
have
three
gigs,
this
is
how
you
configure
that
if
you
have
two
gigs,
this
is
how
you
configure
that,
and
these
are
the
limitations
of
this
2gig
installation
to
achieve
some
kind
of
like
working,
and
I
mean
it's
still
better
than
like
not
having
anything.
D
F
And
I
think
I
think
it's
also,
I
think
the
question
there
is-
and
I
think
this
is
also
something
that
I
discussed
a
little
bit
last
week
like
it's
sort
of
the
the
effort
versus
output
when,
if,
if
these
are
some
things
that
we
can
do
relatively
easily
right-
and
you
know
they
are
maybe
more
controversial
right
then,
but
that
may
still
be
better
than
investing
a
large
amount
of
time
on
it
right
with
like,
maybe
not
as
much
impact
for
this
very
memory
constrained
environment
and
we
can
at
least
tell
people
that
that's
an
option
right
I
mean
we
may
get.
F
We
may
get
some
flack
for
for
doing
this
right,
I'm
just
putting
it
out
there,
it's
a
little
bit
controversial,
but
I
think
we
should.
We
should
also
be
transparent
right
and
say
you
know.
Actually
this
is
the
big,
a
big
thing
that
we
could
do
right.
We
may
not
be
able
to
do
it
by
default,
but
you
know
we
shouldn't
hide
that
either
I
mean
you
can
disable
prometheus
right
now.
If
you
wanted
to
right
or
you're
the
monitoring
stack
right,
it's
not
not
something.
We
never
have
supported
before
right.
D
I'm
kind
of
thinking
that
really
like
the
way
I
maybe
how
to
approach
this
documentation.
It's
like
maybe
for
each
of
these
grading
is
to
provide
like
that.
D
D
That
may
hurt
the
performance
editor,
but
maybe
this
is
not
the
trait
of
so
maybe
so
maybe
this.
This
is
like
the
task
for
me,
like
I'm
just
gonna.
Maybe
start
writing
like
this
documentation
with
this
diff
with
these
different
gradings
and
like
the
expectations
about
how
the
environment
should
be
configured
and
like.
We
could
then
fill
the
like
this
section
about,
like
the
configuration
for
the
github
rb,
that
you
should
put
in
these
different
environments.
F
I
think
I
think
it's
also
in
that
like
again
to
be
really
really
transparent.
From
my
end,
like
I
think
this
is
really
important
to
gig
week,
but
I
think
we
have
also
some
some
work
that
is
going
to
kick
off.
That
has
global
implications
also
for
dot
com
right,
which
I
think,
and
in
in
general,
for
a
very
large
user
base
right
where
we
can
make
make
changes,
and
so
I'm
also
a
little
bit.
F
You
know
they
are
actually
also
quite
quite
important,
and
I
would
I
think
this
is
for
me
to
say
maybe
in
the
next,
let's
say
two
months
or
two
releases,
or
so
we
come
to
a
a
point
where
we
can
say
this
is
what
we've
accomplished
here
right
in
product
the
improvements
that
we've
made
and
this
these
are
some
of
the
settings
that
you
can
still
tweak
to
disable
certain
things,
and
that
is
that
is
where
we
are
at
and
then
you
know
you
can
always
evaluate.
F
Is
it
worth
continuing
spending
time
on
this
for
another
month?
Right
or
are
there
maybe
other
things
you
know
in
the
product
overall
that
we
consider
more
impactful
right,
because
you
can.
We
can
probably
spend
a
very
long
time
on
this
right
and
I
think
we
should
at
least
define
a
point
at
which
we
say.
Okay
is.
Is
this
something
where
we
want
to
continue
or
this?
Because
there
are
still
like
a
few
things
that
we
really
can
do
right
or
is
it
getting
harder
and
harder
for
less
less
output?
F
And
I
think
I
spoke
about
that
with
camille.
I
think
it
is
still
true
in
general,
maybe,
but
also
here,
maybe
80
percent.
You
know
finishing
80
of
it
is
you
know
a
lot
easier
than
the
last
20,
which
will
then
take
another
80
of
your
time
right
and
I'm.
I
think
we
should
at
least
surface
that
at
some
point
also
to
you
know
the
product
team
and
to
enablement
more
generally.
You
know
when
we
essentially
at
the
point
and
say
like
hey,
we've
done
80.
F
A
So
how
do
we
go
about
the
first
bullet
there
time
boxing
and
finding
a
point
where
we
can
make
those
trade-offs?
It's
great
to
talk
about
it,
but
what's
the
actionable
items
from
here.
B
I
think
the
actual
actionable
item
should
be
like
restricted
list
of
of
issues
we
are
trying
to
accomplish
and
some
deadline
or
like
some
when
they
are
making
decision.
C
Thank
you
it.
We
had
our
scored
like
our
ranked
list
of
issues
right,
but
we
they
had,
like
you
know,
weights
in
terms
of
effort.
It
will
take.
I
mean
because
at
some
point
we
will
also
just
run
out
of
these
like
lower
hanging
more
immediately
available
issues
anyway.
D
C
This
thank
you,
so
maybe
we
just
have
to
revisit
this.
Maybe
we
should
just
really
kind
of
check
in
you
know,
with
our
own
estimations
here
every
now
and
then.
F
I
think
maybe
my
suggestion
would
be
that
maybe
in
I
mean
the
new
releases,
13.9
is
going
to
start
right.
Maybe
when
we're
sort
of
two
weeks
into
the
release,
we
can
revisit
this.
So
maybe
in
a
couple
of
weeks
and
just
see
okay,
where,
where
are
we
at
right?
Because
then
we
also
have
an
interesting
opportunity
to
either
say
you
know
by
the
end
of
13.9.
F
The
only
thing
that
we're
going
to
do
is
create
all
of
the
documentation,
and
you
know
say
this
is
where
we
are
or
maybe
we
would
say
we
need
another
release,
because
there
are
two
or
three
things
that
we
can
still
do
and
that
they
are
worth
doing
when
then
it
may
be
13.10,
but
I
think
we
can
revisit
this
in
a
couple
of
weeks
or
so
that
gives
us
also
a
little
bit
of
headway
to.
F
A
All
right
yep,
I
I
put
it
on
our
future
agenda
there.
So
it's
a
good
idea,
thanks
for
reminding
me
about
their
ice
cream
mark
matias.
That's
a
good
call.
C
C
Is
like
I
don't
know
if
this
is
going
to
help,
but
we
also
have
a
major
release
coming
up
in
april.
I
believe
right
that
would
be
14..
C
I
wonder
like
if
there's
anything
that
comes
up
what
we
think
actually
making
a
hard
cut
would
be
helpful
here
by
ripping
something
out,
for
instance,
that
might
be
difficult
to
do.
Otherwise.
That
might
be
a
good
point
in
time,
because
there
won't
be
another
one
for
a
year
right.
I'm
just
saying.
Maybe
this
is
something
we
should
consider,
because
it
kind
of
fits
that
timeline
right,
because
I
think
3010
that
would
put
us
in
march.
I
think
so.
If
there's
anything,
we
want
to
yeah
we're
considering
to
completely
retire.
C
That
might
be
a
good
opportunity.
I
know.
Gitlab
exporter
is
probably
probably
not
that,
but
maybe
maybe
something
you
know
comes
to
mind.
B
Yeah
good
point,
actually
a
lot
of
changes
requiring
this
kind
of
credit
card
from
the
beaches
to
me.
So
maybe
I'll
find
something.
D
F
Because
I
think
the
the
one
thing
this
is
my
perception
perspective.
It
may
not
be
shared
by
by
everyone
for
me.
If
you
do
something
like
this,
the
success
is
not
necessarily
that
you
manage
to
get
the
gitlab's
memory
usage
under
two
gigabytes
right.
The
success
is
understanding.
You
know
why
you
are
stopping
at
a
certain
point
right.
If
you
know
what
you've
accomplished
right
and
you
you
can
make
a
specific
statement
and
say:
we've
done
this.
This
was
the
impact
right.
F
These
are
the
things
that
we
may
be
able
to
do
right,
but
we
will
probably
not
be
able
to
go
under
two
gigabytes
unless
we
deactivate
some
of
those
things.
That's
an
outcome
for
this
right.
It
may
not
be
you
know
what
what
we
would
have
hoped,
but
that's
the
that's
the
reality
right
and
then
you
know,
I
think,
the
that's.
I
think
where
you
need
to
need
to
end
right
and
that's,
I
think,
good
enough
for
me,
because
then
you
can
actually
explain
to
people.
You
know
if
they
say.
A
Okay,
moving
on
to
the
next,
so
other
things
that
we've
talked
about
in
various
one-on-ones
is
what's
what's
up
next
for
future
milestones
on
our
roadmap,
and
these
are
some
of
the
items
there
there's
a
mix
of
issues
and
items,
sorry
issues
and
epics
in
here
this
first
one
we
probably
need
to
promote
to
an
epic
there's
a
lot
of
work
that
needs
to
take
place
there
and
need
to
measure
the
impact
of
this.
A
It's
it's
it's
not
obvious,
but
the
accumulation
of
rails
boot
time
taking
as
long
as
it
does
is
costing
us
a
lot.
You
can
do
some
research
to
further
quantify
the
impact
of
that
and
the
rest
of
the
issues
out
there.
You
all
can
read
and
we
can
over
the
next
couple
milestones
prioritize
order
and
get
some
more
research
on
these.
So
I
just
wanted
to
throw
these
out
there,
because
our
actual
roadmap
that
I
created
a
while
back,
doesn't
contain
a
lot
of
these.
A
A
Yep
high
level
decision
first
and
then
price
framework
later
on.
F
Yeah
also,
some
in
sort
of
some
feedback
that
we
got
on
the
rice
work
in
the
database
group
as
well.
It
works
better
for
larger
epic
items
right
when
you
have
to
discuss
sort
of
the
impact
of
moving
to
ruby,
3
versus
object,
storage
improvements
right.
These
are
sort
of
at
the
level
where
people,
if
you
do
a
little
bit
of
research
ahead
of
time,
you
know
it
becomes
a
little
bit
easier
compared
to
implementation
issue.
One
versus
implementation
issue,
two
right:
it's
that
may
be
a
little
bit
too
fine,
fine
grained.
F
A
A
Familiarize
yeah
139
is
pretty
booked
with
the
memory
constrained
environment,
so
I
would
imagine
14.00
1310.
All
right
numbering
will
be
where
we
start
talking
about
these
and
better
grooming
them
out.
B
F
I
had
only
one
thing
that
I
forgot
to
put
on
the
agenda,
because
I
just
thought
about
it
and
that
is
to
do
with
the
the
potential
of
using
a
more
sort
of
kanban
style
board
view
for
for
the
memory
group
as
well.
I
think
we
had
some
process
discussions.
The
database
group
is
moving
towards
it.
I
I'll
just
put
it
on
the
agenda
for
next
week,
but
I
would
personally
be
quite
up
for
creating
a
sort
of
a
process
for
working
that
primarily
emphasizes
reduction
in
cycle
time
right.
F
So,
rather
than
focusing
on
on
releases
and
saying,
oh,
we
do
stuff
for
a
month
right,
and
these
are
all
the
things
really
focus
on
having
a
single
board,
especially
with
with
items
on
them
and
moving
them
from
you
know,
actually
having
them
to
having
them
in
production
as
fast
as
possible,
because
I
think
that
is
that
I
think,
especially
for
some
of
the
work
that
you
do.