►
From YouTube: 2021-08-25 Create:Code Review Weekly Sync
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
Right
welcome
to
code
review
weekly,
so
my
first
point
I
just
wanted
to
keep
you
up
to
speed.
So
thomas
was
on
a
call
hi
thomas,
his
digging
and
finding
improvements
for
the
total
blocking
time
on
the
discussions.
Tab
looking
to
improve
that
and
he's
already
found
some
improvements
where
we
load
the
virtual
scrolling
library
dynamically,
but
that
while
discussing
that
as
a
team
we
figured
out,
it
would
be
worth
trying
the
implemented
virtual
scrolling
that
we
had
on
the
changes
tab.
A
Now
that
it's
fully
released
and
we
already
got
the
learnings
about
the
finance
page
and
everything
looking
like.
Let's
see
the
impact
of
doing
this
on
the
discussions,
how
what
metrics
will
be
impacted
by
how
much
before
we
pursue
anything.
B
Okay,
yeah,
I'm
just
gonna,
you
sort
of
address
it,
but
any
concerns
about
find
on
page,
and
I
only
say
that,
because
it
looks
like
there's
at
least
a
couple
people
who
are
experiencing
issues
with
fine
on
page
in
the
changes
tab.
As
of
this
week,
I
saw
one
bob
and
then
someone
else
commented
in
the
issue
after
bob
left
his
comment
that
it's
not
working
correctly
for
either
one
of
them.
A
I'll
so
the
the
one
thing
that
might
be
happening
is
either
two
things:
either:
there's
a
bug
that
we're
not
disabling
the
virtual
scrolling
when
the
when
the
person
triggers
that,
so
there
might
be
some
problems
in
detecting
the
different
modifier
keys
that
people
use
different
systems.
So
there
might
be
a
problem
there,
where
the
mitigation
strategy
that
we
have
is
not
working
in
some
conditions.
A
The
other
is
that
when
we
do
that
and
we
disable
the
virtual
scrolling,
there's
a
lot
of
work
being
done
by
the
browser,
it
might
not
be
immediate
and
if
it
doesn't
appear
right
away,
they
label
that
as
a
bug.
So
that's
why
we're
trying
to
figure
out
what
scenario
is,
and
there
might
be
some
other
scenarios
that
we
don't
understand.
Yet
I
wouldn't
call
it
a
concern.
A
Like
I
said,
we
don't
expect
it
to
ship
it
because,
like
we
talked
about
on
the
other
time,
like
one
thing
is
to
enable
the
virtual
scrolling,
the
other
is
to
deal
with
the
fallout
of
that
making
sure
that
the
links
to
the
notes
work,
making
sure
that
all
of
the
pagination,
I
don't
think
we
have
pagination
but
all
of
the
functionality
works.
There's
also
the
on
the
notes.
A
B
C
B
Yeah,
I
guess
we'll
see
if
it's
fixed,
is
that
better
now,
yes,
yeah!
Okay!
Thank
you!
That's
interesting.
I
was
just
gonna
ask
for
an
update
on
engineering
allocation.
I
like
I'll,
also
preface
this
and
say
I'm
probably
just
gonna.
Add
it
as
like
a
standing
item
for
weekly
sync
until
we're
out
of
engineering
allocation.
I
think
it'll
be
the
one
thing
that
we
want
to
know
so.
C
Sorry
well
I'll
give
you
an
update.
Also.
My
first
point
here
is
that
so
I
have
to
report
on
this
every
week
in
a
different
call.
So
when
I
do
that,
I
will
try.
I
will
start
also
updating
the
epic
this
one
that
I
linked
here
with
that
status
and
I'm
just
trying
to
keep
that
better
up
to
date,
which
I
had
not
been
doing
until
this
morning.
C
So
I
will
I'll
try
to
do
that
just
for
transparency
purposes,
but
yeah,
so
the
where
we
are
right
now,
there's
really
just
two
infra
dev
issues
that
we're
working
on
there's
this
giddily
n,
plus
one
errors
where
we
patrick
fixed
a
couple
things
already,
which
had
a
lot
of
improvements.
But
then
we
found
one
more
case
where
it
looks
like
we're
running
into
the
same
problem.
C
Caillou
helps
kind
of
debug
that
I
think
it's
a
width.
If
you
have
lots
of
comments
on
lots
of
different
commits,
then
the
number
of
calls
we
make
to
get
italy
just
balloons,
so
we're
gonna
try
to
see
what
we
can
do
about
that
and
then
the
other
main
one
that
we're
working
on
is
around.
Caching,
for
the
mergeability,
the
merge
request,
mergeability
check
worker,
that's
the
other
infradeb
issue,
so
we
had
a
fix.
We
rolled
it
out.
C
It
broke
things
in
production,
flipped
the
feature
flag
off
right
away,
so
it
was
good
that
we
were
able
to
mitigate
that.
We
found
a
kind
of
a
new
way
to
do
it
that
has
just
been
merged.
So
now
we
can
try
the
feature
flag
process
again
and
in
a
much
slower
rollout
plan
this
time
to
try
to
prevent
any
problems
or
catch
problems
earlier.
C
So
those
are
the
two
main
infra
dev
issues,
there's
one
more.
That's
just
called
like
production
readiness,
improvement,
that's
on
our
list,
but
there's
not
really
much
else
that
we
need
to
do
on
that
one.
So
I'll,
probably
just
close
that
out
this
week,
I
just
they
have
infrared.
The
infrastructure
team
generates
these
reports
and
that
one
specific
issue
is
linked
to
all
these
production
incidents.
So
if
I
close
that,
then
it'll
drastically
change
our
standing
in
this
report,
but
in
a
good
way.
C
I
think
so
I
think
we're
I
think,
we'll
be
okay
to
just
close
that
one.
The
other
thing
we're
focused
on
is
air
budget
improvements,
so
some
of
the
caching
stuff
that
we
had
been
working
on
already
seems
to
be
helping
that
a
little
bit.
C
It's
with
holiday
time
the
the
buckets
of
data
they
collect,
so
they
have
a
little
longer
span,
which
means
we
can.
It
will
work
well
we're
getting
the
same
number
of
errors,
but
it'll
look
like
slightly
less
because
we're
we're
less
strict
on
the
reporting
of
it.
So
so
that's
good,
so
our
our
rate
is
inching
up
very
slowly
like
a
tenth
of
a
percent
a
day
or
something
like
that,
but
it's
over
the
measurements
over
28
days
and
they
just
made
that
change
a
few
days
ago.
C
So
as
that
28
days
fills
up
with
this
new
reporting,
then
our
number
will
keep
going
up.
A
B
B
C
Right
I'll
I'll
put
the
link
in
here
right
and
yeah.
The
issue
we
ran
into
is
that
yeah
our
tests
didn't
cover
it
and
then
the
automated
tests
eventually
caught
it,
but
not
until
like
it
was
in
production
and
then
that
test
didn't
really
alert
correctly.
So
one
of
the
things
we're
going
to
fix
is
we
kind
of
promoted
that
test
to
be
a
little
more
severe
when
it
fails.
C
C
So
we're
working
on
a
fix
to
the
chat,
ops,
feature,
flag
tool
will
now
check
to
see
what
the
status
isn't
staging
before
you
set
it
in
production
just
to
kind
of
verify,
and
then
warn
you
if
you're
trying
to
do
something
crazy,
again,
yeah.
So
there's
that
and
then
the
other
thing
we're
doing
we're
just
trying
to
clean
up
the
future
flag
template
the
rollout
issue
template
trying
to
make
it
a
little
more
clear
what
the
expectations
are
there.
C
A
Of
gonna
move
forward.
Are
you?
Are
you
aware
of
the
upcoming
new
staging
thing,
new
work,
that's
being
done.
A
Link-
maybe
here
I
don't
know
yeah,
I
think
you
hear
about
the
upcoming
new
staging,
so
you
can
follow
along
because
I
think
that
will
help
mitigate
a
bunch
of
things,
because
different
teams
require
different
things
from
staging
and
we
do
different
kinds
of
testing
on
staging,
and
this
will
help
us
be
more.
B
Great
lovely,
maybe
it's
the
background
I
don't
know
like
well,
whatever
we'll
mess
up
later,
the
first
one
is
the
n
plus
one
it
might
be
good,
annabelle
and
andre.
B
If
you
look
at
that,
the
issue
is
that
if
you
know
how
we
show
diffs
in
the
overview
tab-
and
we
show
the
comments
underneath
them,
and
so
when
you
every
time
like
a
new
commit
happens,
we
still
have
to
show
you
the
old
version
of
the
diff,
and
so
what
happens
in
like
large,
mrs
that
go
on
for
a
long
period
of
time?
Is
lots
of
comments
happen
on
older
discs
that
are
no
longer
relevant,
but
we
have
to
go
fetch
those
discs
every
time
and
that's
where
the
impulse?
B
That's
where,
like
all
the
getaway
calls
come
from,
I
don't
know
that,
there's,
like
legitimately
a
back
end
fix
for
that
gary's
gonna
look,
but
we
may
need
to
think
like
creatively
about
like
ui
ways
to
deal
with
that,
like
not
loading
those
threads,
I
know.
Maybe,
if
they're
collapsed,
we
don't
actually
fetch
them
until
something
else.
I
don't
know
if
we
do
that
already
or
like
other
front-end
options
to
sort
of
help
mitigate
that,
but
it
may
be
useful
to.
E
B
Doesn't
always
close
it?
It
says
it's
an
outdated
diff,
but
it
only
collapses
by
default
if
they're
resolved.
So
it
does
just
by
committing
to
the
same
file
that
doesn't
necessarily
make
it
resolve
right
because
you
could
commit.
A
The
most
immediate
way
of
that
we
could
work
on
that
is
that
we
remove
that
from
the
payload,
because
we
don't
need
to
if
we
remove
the
diff
lines
from
the
payload,
and
we
just
add
a
button
to
show
the
diffs,
like
you'd
click,
a
button
to
show
the
divs,
and
then
we
would
request
one
by
one.
You
would
have
an
impact
on
the
ux,
but
also
you'd
only
request
it
when
we
actually
need
it.
A
So
yeah,
there's
there's
a
couple
of
ideas
that
have
floated
around
about
starting
to
not
display
the
entire
archive
of
notes.
All
of
the
time
on
the
discussions
where
we
just
display
the
last
time
frame
like
the
last
two
weeks
or
something
then
for
anything
beyond
that,
we
would
request
that
by
explicit
clicking
a
button
which
starts
being
very
beneficial
for
this
topic.
A
When
we
have
large,
mrs
that
are
going
on
with
discussion
for
a
long
time,
it
might
be
tricky
if
you
have
unresolved
discussions
beyond
two
weeks,
but
anyway,
that's
just
going
getting
smarter
into
the
loading
of
the
data
and
notes.
But,
okay,
is
there
an
issue
for
something
like
that?
I
know.
B
I
don't
think,
there's
any
issues
I
think
for
now.
I
would
say
like
follow
along
to
that
infra
issue
and
keep
keep
tabs
on
it.
Just
so
I
don't.
I
don't
know
what
progress
gary
will
make
today
or
when
he
looks
at
it
again,
but
it
does,
it
does
feel
like
it'll
be
hard
to
solve
solely
on
the
back
end,
so
it
may
be
one
of
those
things
that
we've
got
to
think
about
in
a
different
way
at
some
point,
so
just
keep
an
eye
on
that
one.
So.
B
B
It's
not
draft
controller
exclusive
anymore,
yeah,
all
right,
all
right
I'll,
keep
an
eye
on
that
and
I'll
get
involved,
thanks
yeah
and
then
matt.
The
other
question
for
you
is
like
it
sounds
like
progress
is
fairly
far
along
other
than
this,
like
n
plus
one
issue
which
sort
of
is
what
it
is
and
then
the
caching
I
know
is
already
back
in
either
mr
review
or
close
to
being
like
rolled
out
like
and
with
error
budgets
being
changed.
B
B
C
That
is
a
great
question
and
probably
another
thing
we
should
cover
every
week
until
until
we're
out
of
this,
because
I
don't
know
the
answer,
and
and
it's
not,
there
wasn't
really
a
kind
of
a
definition
of
done
for
for
this,
like
how
do
we?
Where
do
we
go
or
what
are
the
exit
criteria?
C
I
know
I've
been
kind
of
asking
that
and
darva
has
two
of
like
okay
when
like
what's
next.
How
do
we
get
out
of
this?
So
I
think
we'll
be
able
to
make
a
good
case
for
it
once
the
infrared
issues
are
resolved,
definitely
for
at
least
reducing
the
percentage.
C
That's
yeah
bottom
line.
Don't
have
an
answer
quite
yet,
but
yeah.
I
think,
as
we
wrap
up
these
last
few
infradeb
issues,
and
we
really
the
good
thing
is
that
knock
on
wood
there
has
not
been
a
lot
of,
or
there
hasn't
been
any
new
production
incidents
related
to
our
team,
like
from
an
infradep
standpoint.
There
hasn't
been
new
infradeb
issues
in
about
a
month,
I
think
for
our
team.
C
B
Okay
sounds
like
just
keep
we'll
just
keep
asking
and
you're
going
to
keep
working
on
it.
I
agree:
there's
not
a
clear
definition.
B
Exit
criteria,
which
is
why
I'm
asking
because
it's
yep-
that's
fair,
it's
weird,
it's
weird
that
we
got
in
it
and
then
there's
no
way
out
of
this.
So
yeah,
I'm
fine
with
waiting
until
those
infra-dead
issues
are
closed
to
sort
of
bring
it
up.
Again,
though,
that
makes
sense,
I
just
added
one
more,
which
is
the
sub
transactions
yeah.
E
B
C
That's
the
case
yeah,
so
just
for
some
background.
So
last
friday
I
think
it
was.
We
identified
that
if
anywhere
in
the
code
we're
using
sub-transactions
that
could
cause
a
lot
of
database
problems,
especially
with
long-running
queries
and
the
way
postgres
handles.
It
is
inferior
and
there's
some
patches
that
we
could
try,
but
the
goal
was
then:
let's
just
try
to.
We
don't
really
need
to
use
them.
So
let's
just
try
to
get
rid
of
all
the
sub-transactions
in
the
code,
so
they
ran
a
report.
C
C
A
Cool
then,
I
have
my
last
point
just
following
up
a
discussion
on
slack.
I
want
to
take
the
opportunity
that
we're
all
here,
although
we
might
want
to
follow
up
this
into
the
ux
weekly
or
something,
but
I
found
that
very
interesting
discussion
about
what
they
call
it.
Unbreaking
collaboration
is
it
and
breaking
code
collaboration-
and
I
was
talking
to
tomas,
did
this
morning
and,
following
that
whole
conversation
that
we've
had
in
the
past,
about
supporting
better
the
attachment
of
patch
files
onto
the
mr.
A
I
feel
like
that
if
we
invest
some
some
more
work
on
on
that
workflow,
I
feel
like.
We
can
then
make
that
whole
thing
much
easier
and
automatic
from
the
user's
perspective
that
are
using
the
the
gitlab
workflow
extension,
but
also
people
that
are
producing
their
own
patches.
It
would
be
basically
like
whatever
tool
you
use.
If
you
add
a
patch,
you
would
benefit
from
this
work,
and
somebody
was
saying
I
think
yeah
annabelle
you're
saying
like
take
it
all
take
all
of
it
or
none
of
it.
A
E
I
don't
have
anything
specific
to
add
right
now.
I
think
that
the
whole
concept
is
really
is
really
cool.
I
I
would
have
loved
it
when
I
was
a
developer.
I
don't
know
how
many
other
people
would
have
really
liked
this.
I
don't
know,
but
I
love
the
idea
of
being
able
to
propose
this
big
number
of
changes
via
multiple
files
and
then
kind
of
push
it
up
and
it
would
just
appear
in
the
merge
request
and
that
user.
That
author
could
say.
Oh
okay,
let
me
review
these
suggestions
all
at
once.
E
You
know
yes,
no,
yes,
no
apply
them
if
not
reply
them.
If
they
want
to
reject
them.
If
not,
and
it
would
be
like
a
mini,
merge
request
within
the
merge
request.
I
don't
know.
I
understand
the
reasons
why
we
might
want
to
use
snippets.
For
that.
I
don't.
I
think
someone
there's
many
issues.
I've
looked
at
regarding
this.
I
don't
love
the
idea
of
saving
these
as
snippets
that
you
just
have.
E
I
understand
the
use
case
for
like
creating
a
snippet
to
set
up
something
locally
for
development
or
testing
purposes
that
you
might
want
to
reuse,
but
I
don't
know
yet
how
this
would
work,
but
I
think
that
the
concept
is
really
cool
and
especially
if
we
could
use
a
custom
get
extension
or
something
that
apparently
we
already
had-
and
I
didn't
even
know
that
you
could
push
to
a
merge
request
right
away
via
that
quick
command
that
we
have
or
get.
E
I
don't
know
what
it
is
actually,
but
I
think
there
are
a
lot
of
opportunities.
I
think
it
needs
a
lot
of
research
because
I
don't
know
how
many
people
actually
want
this
and.
E
A
Yeah,
it
definitely
feels
like
something
worth
doing
some
user
research
to
see
how
how
to
validate.
If
you,
I
know
that
if
you
ask
paul
slaughter,
he
will
love
it
and
he
will
say
that
he
wants
it
tomorrow,
but
yesterday
but
yeah
it
would
be
worth
doing
some
user
research
just
trying
to
understand
how
how
prevalent
this
would
be.
D
B
B
A
A
There's
one
thing
that
I
can
tell
you
this:
if
we
want
to
make
the
user
load
the
patch
file
on
just
the
front
end
show
the
lines
they
could
be
unselecting
certain
lines
and
then
sending
that
to
the
server
to
apply.
That
would
be
doable
and
straightforward
enough
on
the
front
end
the
application
on
the
back
and
might
not
be
as
simple
and
that
I
don't
know
matt
if
you
have
any
thoughts.
A
But
maybe
we
can
create
an
issue
for
that
and
then
eventually
discuss
it
there
and
bring
in
the
engineers
to
weigh
in
because
it
feels
like
from
the
front
end.
It
would
be
definitely
doable
to
detect
the
patch
file
on
the
comments
had
a
button
and
then
smart
application
of
patches
or
something,
and
it
would
allow
the
user
to
to
select
that
that
would
be
doable
on
the
front
end.
A
B
E
C
A
A
Yeah,
but
we
can
keep
talking
about
it
on
slack
or
on
the
ux
call.
Okay,
thanks
everyone
good
to
see
you
thanks,
bye.