►
From YouTube: 2021-07-07 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).
B
Yes,
thank
you,
so
I
wanted
to
provide
a
bit
of
an
update
on
performance
work.
I
I
on
purpose,
didn't
do
the
mid
milestone,
checking
just
because
this
muscle
we
have
a
lot
of
performance
work
and
that's
kind
of
what
I'm
giving
out
here,
but
it's
hard
to
get
a
number
on
and
I'll
explain
why
so
virtual
scrolling,
we
have
been
carrying
out
the
roll
rollouts.
We
tried
rolling
it
out
in
staging
last
friday
and
we
ran
into
some
bumps
some
problems.
Some
tests
were
failing.
B
So
at
this
moment
we're
waiting
to
hear
feedback,
we're
waiting
to
hear
we're
waiting
to
see
the
metrics
change
a
little
bit
as
well,
but
right
now
any
feedback
that
you
hear
from
anyone
on
this
topic.
Please
let
us
know
and
yeah
that's
kind
of
where
we're
at
the
next
steps,
for
this
is
going
to
be
rolling
out
all
projects
on
github.com.
B
If
no
red
flags
come
up
potentially
later
this
week
tomorrow
or
friday,
probably
tomorrow.
So
we
avoid
friday
and
again
after
a
couple
days,
we
might
be
ready
to
make
default
on,
depending
on
the
feedback,
I'll
of
course,
loop
pedro
to
have
the
final
approval
on
it
and
and
kai
as
well,
so
that
we're
ready
to
make
that-
and
now
I
mean
we
don't-
have
an
announcement
for
the
release
post,
but
if
you're
ready
for
it
or
not,
but
I'll
keep
you
posted
on
that
front.
We
have
any
questions
for
this.
B
C
B
Right
so
there's
there
are
several
different
different
kinds
of
tests:
the
current
ones
that
we're
tracking
that's
actually
a
great
question.
Matt
performance.
B
We
do
have
a
a
dashboard
for
a
merge
request
that
we've
been
tracking
from
gitlab
foss
project
and
that
should
have
been
affected.
This
on
the
recent
runs.
So
I'm
trying
to
open
it
right
now
to
see
if
it's
there
that
one
will
catch
it
for
sure.
We
already
had
one
different
url
to
track
it
for
forcing
the
virtual
scrolling.
So
we
already
know
the
metrics
and
the
tbt
was
around
10
seconds,
which
is
great
used
to
be
at
around
30..
B
We
also
shipped
other
improvements
like
the
functional
components
brought
down
those
metrics
as
well,
and
then
there's
the
10k
reference
architecture
that
the
quality
team
runs.
Those
will
only
be
affected
when
the
feature
flag
is
default
on
because
they
run
it
on
a
nightly
and
they
run
it
on
a
separate
environment.
So
only
when
the
feature
flag
is
on
will
that
be
affected
by
the
virtual
scrolling.
B
B
We've
been
looking
at
the
is
this
known.
We
did
mention
it
on
the
vp
development
channel,
so
that
christopher
was
on
the
loop
and
everything
right
now
we
didn't
get
any
feedback
of
feature
bugs
or
something
like
that
or
or
we're
very
vigilant
for
the
copy
for
the
finding
page
feedback.
B
We're
very
like
see
if
anybody
mentions
it,
it
might
take
a
while,
because
it's
one
of
those
things
that,
even
if
you
use
it
and
they
fail
like
you-
pay
the
utilist
last
week,
even
if
it
fails,
they
might
not
notice
that
it
failed.
So
it
might
take
a
while
for
them
to
realize
that,
but
we're
being
careful
in
watching
that,
but
yeah
so
far,
nothing
we
did
get
a
feedback
from
broken
drop
down,
so
the
drop
down
would
be
overlapped
by
the
by
the
following
diff
file.
B
If
it
was
too
small
of
a
diff,
but
that's
fixed
already,
nothing
else.
A
Okay
yeah,
I
was
curious
if
we
should
post
in
development
or
what's
happening
at
get
lab,
yep
development
seems
like
target
audience
and
the
other
one
doesn't
I
I'm
hesitant
to
like
call
attention
to
something
and
say
go
find
bugs
in
a
way.
That's
like
not
helpful,
but
I
wonder
if
we
may
just
be
able
to
generate
some
kind
of
feedback
by
doing
it.
I
think
it's
a
fine
balance
to
walk,
because
it's
like
sort
of
a
it's
not
a
feature.
B
You
know
that
seinfeld
episode,
where
elaine
had
a
cashmere
sweater
and
they
had
a
red
dot
and
they're
like
you,
see
the
red
dot
in
my
sweater
and
then
somebody
said
I
don't
see
the
sweater.
I
just
see
the
red
dot
now
that
you
mention
it.
So
if
you
call
attention
to
it,
you're
right
so
I'll
give
it
probably
another
week
for
your
spontaneous
feedback,
but
before
we
turn
it
on
for
all
projects,
I'll
definitely
do
that.
So
what
do
you
all
think
about
waiting
for
the
next
week?
To
do
that
sounds
good.
B
A
B
Okay,
so
100
one
other
thing
we're
not
in
a
rush
to
make
a
default
on
for
customers.
Okay,
we
do
want
it
to
be
on
by
default.
We
do
want
to
be
on
github.com
by
the
end
of
this
quarter,
but
that
still
gives
us
time
in
14.2
and
that
would
have.
That
would
probably
be
the
cautious
thing
to
do
honestly
to
give
it
more
time,
since
the
feedback
might
take
a
little
longer
together.
B
So
I
don't
have
any
rush
in
enable.
I
didn't
promise
anyone
that
will
be
enabling
this
by
default
on
fourteen
one,
my
forecast
is
that
we'll
be
enabling
this
on
early142
in
the
best
scenario?
Well,
not
the
best
scenario,
the
realistic
scenario
enabling
it
in
early
14-2,
so
I
don't
necessarily
feel
we
should
rush
turning
it
on
just
because
we
want
it
out,
especially
for
customers
on
gitlab.com
once
we
have
it
for
all
projects,
I
think
the
feedback
will
roll
in
if
there's
anything
meaningful,
but
I'm
not
in
a
rush
for
fortune.
B
Sweet
next
memory
efforts,
so
we
had
some
tasks
for
memory
efforts,
one
in
particular
about
object,
freeze
and
that
turned
out
to
not
be
as
worthwhile
as
we
thought
it
could
be
that
the
benefits
we
shipped
recently
have
brought
down
the
fat
of
the
app
in
terms
of
memory
already
until
we're
kind
of
like
scraping
the
barrel
there.
But
we
do
have
other
ideas
so
we're
still
pushing
for
improvements
in
other
places.
One
of
the
things
we
brought
up
that
was
brought
up
pedro.
B
B
That
too,
tvt
and
memory.
D
B
B
A
B
Goal
that's
a
great
question
and
try
to
recover
the
url.
I
think
we're
so
assuming
the
virtual
scrolling
is
that
what
you're
asking.
A
We
thought
yeah
like
let's
assume
virtual
scrolling's
on
yeah
that'll
cover
like
one
page
like.
Where
are
we
at?
I
guess.
B
B
We
were
at
57
percent,
57
of
the
memory
objectives
and
76
of
the
timing
objective,
so
the
timing
objective
is
kind
of
like
already
in
the
success
area.
So
if
we
get
in
between
the
seventy
eighty
percent
success
of
an
okay
r,
we
kind
of
d
as
a
success,
the
memory
is
a
bit
behind,
but
that's
when
I
took
that
we
didn't
have
the
functional
components
in
there.
So
we
thought
the
functional
components
with
virtual
scrolling
with
that
57.
B
That's
that's
a
meaningful
metric
cool
moving
on
then,
for
the
sake
of
time,
I
wanted
to
bring
it
up
here.
We
do
have
a
thing.
We
we
got
a
blocker
so
to
speak,
place
with
the
the
cog
menu,
adding
a
button
and
reloading
the
whole
app
because
it
wasn't,
it
wasn't
producing
worthwhile
improvements.
B
It
was
actually
becoming
slower
in
some
in
some
cases
and
another
question
that
we
have
is
we
have
the
addition
of
the
button
and
the
reload
of
the
application
did
two
different
things,
and
I
know
that
we
had
a
discussion
and
pedro.
You
were
engaging
with
phil
and
I
from
what
I
understood
if
I
understood
correctly
we're
holding
off
from
shipping
the
button
itself,
and
I
wanted
to
understand
better
about
why
and
what's
the
concerns
there
and
why
shouldn't
we
just
release
the
button
itself
without
the
reload.
B
D
Yeah,
the
the
reason
is,
we
were
waiting
on
data
to
understand
how
often
those
options
are
changed
and
if
users
change
them
in
a
short
succession
and
if
they
change
so
basically
if
they
change
multiple
options
in
a
very
short
amount
of
time.
If
that's
the
usual
behavior,
it
makes
sense
to
add
an
extra
because
we're
saving
requests.
B
Okay,
yeah,
I
I
I
understand
that
that
perspective
is
that
easier
to
gather
that
data
in
terms
of
how
much?
How
long
will
it
take
for
us
to
gather
that
data.
A
B
Okay,
that's
fine
mike.
My
fear
is
that
the
the
detection
of
the
suspect
succession
of
changes
it's
going
to
be
harder
to
detect
on
the
data
than
just
shipping.
It
the
feature
itself-
and
this
is
what
I
want
to
talk
about
to
the
level
of
effort
right
now.
We
have
both
of
those
things
in
code
written
and
we
just
extract
the
part
where
it
reloads
differently
and
would
keep
the
button
in
and
from
what
I
got
from
field
is
pretty
straightforward
to
ship
it
as
it
is
even
behind
a
feature
flag.
B
B
That
was
great
as
a
benefit,
so
I
don't
know
if
we're
just
going
a
little
bit
overly
cautious
on
waiting
for
the
data
that
it's
hard
to
collect
instead
of
just
shipping,
something
that
kind
of
makes
sense
on
its
own.
But
I'll
defer
to
you.
I
just
wanted
to
voice
that
in
terms
of
level
of
effort,
it's
very
easy
to
just
ship
it
the
button
and
if
the
date
is
hard
to
collect,
bear
that
in
mind
that
the
the
fix
is
easy
to
ship.
D
You're
done
yeah.
I
wanted
to
quickly
bring
up
the
topic
of
the
implementation
for
the
merge
request.
Villages
redesign-
and
I
know
that
you
and
I
feel
chatted
about
this.
D
I
don't
have
a
preference
or
right
answer
for
the
data
fetching
question,
but
for
having
individual
groups
have
each
widget
inside
of
the
gitlab
ui,
I'm
tempted
to
just
say
that
we
want
a
generic
widget
that
each
group
can
then
customize
in
gitlab
in
the
gitlab
implementation,
but
I'll
wait
for
team
noah
to
also
answer
to
that
because
he's
the
the
dri
he's
leading
this.
But
in
any
case
I
just
wanted
to
know.
B
So
this
is
great
to
have
a
dri
on
this,
because
it
does
it
does
it's
important
from
the
implementation
side
of
things
I've
been
talking
to
some
people
and
getting
some
feedback,
and
I'm
going
to
be
sharing
my
views
on
the
issue
this
week.
B
B
So
full
disclosure,
I'm
leaning
more
towards
forming
a
working
group
which
will
have
members
from
each
one
of
the
groups
that
will
be
implementing
widgets
and
then
they
can
create
their
own
okrs
to
implementing
the
updating
the
widgets
themselves,
but
they
will
always
have
someone
on
the
on
the
kind
of
board
thing
in
the
loop
of
what's
the
direction
and
having
a
strong,
strong
workflow
of
approval
for
code
review.
So
we
would
be
overseeing
everything,
but
not
necessarily
writing
the
code,
but
we
will
be
overseeing
every
architectural
decision
and
every
implementation
as
well.
B
That's
what
I'm
leaning
to
it
does
come
with
a
little
bit
of
overhead
because
we
need
a
sponsor,
but
I'm
still
figuring
that
out.
I
think
we
have
a
a
good
idea
of
who
could
that
be
and
that
will
drive
results,
we'll
have
an
exit
criteria,
we'll
have
concrete
actions
to
and
frequent
update,
frequent
meetings
and
stuff.
So
that's
what
I'm
leaning!
B
I'm
gonna
propose
that
on
the
issue
once
I
have
it
more
materialized,
potentially
tomorrow
and
we'll
go
from
there,
because
it's
starting
to
get
close
to
the
start
of
the
quarter,
so
we
need
to
get
it
moving.
B
D
I
understand
what
what
you're
saying
and
why?
Maybe
a
more
formal
approach
would
be
preferable.
Yeah,
and
I,
although
this
is
something
that
yeah
recently.
I
know
that
this
is
something
that
fell
on
your
lap
and
everyone's
flap.
D
B
B
We
all
know
the
pain
of
the
widgets,
so
it's
great.
D
Thanks,
I'm
very
thankful
for
you
to
be
thinking
through
this
and
coming
up
with
with
the
proposal.
Thanks.
A
You're
welcome.
Can
you
like
if
it
feels
like
we
have
time
to
ask
this
question?
Can
you
clarify,
like
phil's
statement
of
where
shifts
the
data.
B
So
that's
one
of
the
technical
decisions
that
we
haven't
been
able
to
make
because
we
don't
have
the
right
people
on
the
table
to
have
that
discussion
having
that
working
group
would
help.
The
question
is
this:
right:
now
we
have
the
code
divided
by
the
code,
that's
in
gitlab
and
the
code.
That's
in
gitlab
ui,
all
the
code.
That's
in
gitlab
ui,
it's
kind
of
like
a
dumb
component
that
gets
used
by
the
applications.
The
applications
gets
the
data
fetched.
B
Then
they
pass
it
to
the
property,
to
the
components
through
properties
to
render
the
data,
but
the
data
fetching
itself
would
be
done
by
the
app,
not
gitlab,
ui
torrey,
proposed
it
moving
into
gitlab
ui.
It's
something
that
we
have
in
our
minds,
I'm
personally
in
favor
for
now
in
moving
to
gitlab
ui,
but
it
does
come
with
a
lot
more
logic
than
usual
than
the
current
gitlab
ui
component.
B
So
it
could
be
a
different
dimension
of
components
in
gitlab
ui
and
that's
the
question
that
that
phil
is
asking
is:
is
it
okay
to
put
the
data
fetching
responsibility
inside
gitlab
ui
like?
Would
we
configure
the
instance
of
gitlab
that
the
component
would
drink
from?
So
that's
a
new
thing
for
gitlab
ui
that
we're
we
have
to
talk
to
to
the
engineers
and
to
see
what's
the
right
approach
for
gitlab
ui
itself?
B
What
I'm
thinking
personally
is
if
it's
on
gitlab
ui
and
it's
it's
a
fully
capable
component
to
just
drink,
we
give
it
that
we
give
it
the
id.
We
we
configured
the
instance
and
the
the
widget
itself
is
capable
of
fetching
the
data
them
themselves.
Then
we
can
have
the
core
component
of
the
extension
gitlab
ui,
but
also
the
secure
widget
and
the
ready
to
merge
widget
and
all
that
stuff.
B
That
would
we
be
able
to
import,
for
example,
for
the
vs
code,
like
just
as
an
example
or
a
third
application
that
we
wanted
to
show
the
merge
request,
we'll
be
able
to
import
the
ui
of
the
merge
request
to
different
applications.
Instead
of
we
have
the
core
in
gitlab
ui.
That
is
very
dumb
and
it
just
gets
that
data
passed
to
it
or
do
we
have
the
actual
widgets
built
customized
through
it?
So
that's
the
a
big
a
bit
of
a
question.
B
No,
this
would
be
the
first,
I
think,
from
from
what
I
understand
and
we're
okay
in
keeping
it
separate
and
having
just
the
component
on
the
share
and
the
view
shared
folder
of
gitlab,
it's
just
harder.
First,
it's
harder
to
develop
because
it
takes
longer
to
run
the
pipelines
than
gitlab
ui.
We
have
regression.
B
We
have
a
visual
testing
on
gitlab
ui
that
we
don't
have
on
gitlab
and
there's
a
third
thing:
yeah
the
enforcing
loosely
coupled
components
on
the
view
shared
side
of
gitlab,
it's
harder,
because
you
can
totally
reach
overreach
to
code,
that's
just
available
in
gitlab,
whereas
in
gitlab
ui
you
know
that
you're
not
going
to
use
anything
directly
from
git
cloud
project
because
you're
on
a
separate
project,
so
that
would
be
easier
to
enforce
that
loosely
coupledness
that
we
want
from
those
components.
B
It's
a
harder
harder
separation
kind
of
thing,
but
there's
also
cons
to
do
with
that.
To
do
it
there
less
flexibility
that
sort
of
thing
so
yeah,
we'll
we'll
weigh
all
of
those
in
and
find
a
better
way.
We
do
want
to
invite
the
groups
into
this
conversation.
So,
that's
why
it's
a
question,
but
I
don't
think
we'll
have
an
answer
until
we
have
everyone
from
secure
and
from
other
groups
on
board
so
that
they
can
weigh
in
and
say
from
my
perspective
it
doesn't
make
sense
from
my
perspective,
it
does.