►
From YouTube: 2021-10-12 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
Hey
everybody:
let's
start
in
two
minutes,
we
may
not
have
many
people
because
there's
cube
con,
but
let's
see
how
this
goes
so
two
minutes
or
one
minute
actually
just
add
yourself
to
the
chamber.
Please.
A
Okay,
let's
start
thank
you
for
joining
a
pair
of
notes,
a
couple
of
things
important
things,
the
first
one
is
that,
if
I
remember
correctly,
the
metrics
group
wanted
to
have
a
20
minutes
slot
right
for
for
this
during
this
call,
instead
of
having
one
more
call
plaster
yeah.
So
if
that's
perfect,
yes,
that's
the
plan.
Let's,
let's
keep
that
in
mind.
Thank
you.
The
second
one
is
that,
sadly,
I
have
to
drop
off.
I
have
to
yeah
in
half
an
hour,
so
I
hope
somebody
can
help
me
drive
after
this.
A
Okay,
let's
go
for
this.
Let's
start
metrics
update,
please.
B
So
I
put
a
link
on
the
on
the
agenda
to
show
the
current
product
status
so
currently
we're
focusing
on
getting
the
matrix
sdks
back
to
feature
freeze.
There
are
many
open
pr's
and
there
will
be
more
so
we
need
a
review
and
I
put
the
links
there.
There
are
two
pr's
that
I
want
to
call
out.
I
I
put
the
agenda
at
the
very
end
on
the
20
minutes:
carlos
savior,
okay,
the
the
first
one
is
the
matrix
feature
matrix.
B
We
already
discussed
that
there
are
some
some
nets
that
we
want
to
fix,
but
it
shouldn't
block
this
pr.
So
the
ask
for
diago
is:
please
mark
this
pr
as
ready
for
reveal
instead
of
draft
and
then
you'll
get
approval
and
we
should
go
and
merge
it.
Knowing
that
some
of
the
lines
we
might
need
to
change,
but
we
don't
have
to
block
the
pr,
because
there
are
so
many
moving
cars
and
once
we
change
the
spike
people
who
make
the
changes
like
we
add
mi
max,
we
should
go
back
and
update
the
metrics.
B
The
second
one
is
a
pr
from
jack
trying
to
add
min
max
and
that
pr
already
got
three
approvals
from
the
spike
approver.
However,
bogdan
blocked
the
pr
mentioned,
he
had
some
concern,
and
now
I
couldn't
find
bogdan,
it
seems
he's
online.
I
pinned
him
yesterday,
so
I
wonder
if
that
in
such
case
like
if
we
try
to
ping
someone
who
used
to
have
concern
that
we
mark
the
prs
block,
but
later
we
believe
we
resolve
the
blocking
issue,
and
we
also
discussed
in
the
sake,
is
there
a
way
we
can?
A
C
A
second
issue-
and
that
is
this-
the
okay,
so
we
had
been
avoiding
updating
the
data
model
spec.
Oh
my
camera's,
not
working.
I
apologize.
We
had
been
avoiding
updating
the
the
data
model
spec
until
the
proto
is
up
to
date
generally,
and
that
is
not
explicitly
documented
anywhere,
but
it's
one
reason.
I
have
not
clicked
the
merge
button
on
that.
C
Personally,
even
though
I
think
I
approve
the
cl,
because
I
agree
with
the
like
adding
mid
max,
we
have
an
issue
with
optional
protocol
buffer
messages,
so
the
the
specification,
as
is
written
by
jack,
we
actually
can't
implement
today
without
a
fix
to
the
collector
and
we've
taken
an
offline
approach
to
try
to
figure
out
how
to
fix
that.
So,
like
I,
I
would
argue,
because
we
literally
can't
implement
what's
specified
today.
There's
this
open
question
of
what
we
want
to
do.
C
In
that
scenario,
I
I
think
we
should
make
it
clear
like
from
my
perspective.
It
has
enough
approvals
to
go
in,
but
we
can't
actually
implement
it
until
it's
in
the
proto
definition,
and
we
have
a
way
to
generate
that
proto
definition
for
the
collector.
So
previously
we
always
required
the
proto
spec
to
get
updated
before
the
data
model
spec.
We
could
make
that
be
explicit.
That's
an
option
here,
I'm
more
than
happy
to
put
that
in
writing,
because
that
would
just
make
it
clear
what
direction
those
two
have
to
follow.
C
We,
we
never
wrote
it
down.
Second
thing
is
the
with
the
proto
spec.
Now,
since
we
have
this
technical
limitation
on
the
collector,
I
think
this
is
where
we're
still
figuring
out
how
long
it
will
take
to
fix
that
particular
issue,
I'm
working
on
something
locally
honorable.
C
I
also
got
him
on
it,
so
I'm
sure
he'll
have
a
solution
in
like
a
second
but
anyway
we're
working
on
a
solution
for
the
collector
around
what
to
do
with
protocol
buffers
and
this
optional
ality
field
presence
thing
until
that's
through
the
current
design
is
blocked
and
and
jack
would
need
to
go
with
an
alternative
design.
C
So
we've
talked
about
whether
or
not
it's
worth
it
going
for
an
alternative
design.
My
suspicion
is
getting
anything
through.
You
know
bogdan
made
a
one-month
proposal
for
how
long
it's
going
to
take
to
get
the
technical
solution
through
for
this
optional
thing.
I
think
that's
accurate
at
this
point
fully
accurate
in
terms
of
how
long
it'll
take
us
to
resolve
this.
So
that
said,
I
don't
know
if
there's
any
specific
issues
on
the
spec
remaining,
but
we
do
have
this
fundamental
issue
behind
it.
D
Just
quick
clarification
before
people
answer
that
question,
so
the
min
and
max
have
been
added
to
the
metrics
data
model
specification.
This
is
just
the
subsequent
addition
to
the
metrics
sdk
specification.
Oh.
B
Yeah
I'll
clarify,
I,
I
think
what
we
discussed
is
the
data
model
pr
will
be
merged
and
then
we'll
work
with
spoken
to
update
the
protocol.
It
might
take
time
and
it
might
affect
the
otlp
exporter
part.
The
isdk
can
do
it
anyways
because
their
other
exporter
or
in
memory
whatever
exposure,
and
that
that
is
not
blocked
on
the
on
the
platform,
so
we
merge
it
and
and
then
we
can
work
in
parallel.
B
I
I
think
this
is
where
we're
going
to
achieve.
I,
I
guess
the
question
here,
though,
is
more
upper
level,
so
I
I
want
to
send
the
pr
in
the
spike
report
by
saying,
for
example,
we
discussed
in
the
signature
with
overweight,
but
there's
blocking
like
comment
on
the
pr
which
we
believe
we
already
resolved.
I
want
to
have
a
way
that
we,
we
don't
have
to
struggle
next
time,
so
we
have
a
clear
actionable
thing
written
down
in
the
contributing
doc
on
the
spectrum,
possibly
what
to
do.
If
that
happened,.
B
Yeah,
so
my
proposal
would
be
if
we
we've
been
discussed
in
this
inspect
meeting
or
the
channel
and
got
a
general
consensus
and
there's
a
just
field
blocking
issue
and
we
reach
out
to
people
who
block
the
peer,
and
it
has
been
more
than
two
business
days.
Then
the
the
any
spike
approver
or
the
tc
member
can
dismiss
the
blocking
issue
by
pinging
people
again.
B
E
B
I
would
say
I
understand
so
so
I
probably
would
encourage
people
like
by
saying
who
whoever
opened
the
pr
or
people
from
the
same
company
shouldn't
dismiss
the
reveal.
But
if
people
from
another
company
like
being
well
discussed
in
a
meeting
and
they
they
try
to
think
people
in
the
pr
publicly
and
there
hasn't
been
any
response
in
two
businesses,
then
any
spike,
approver
or
tc
member
from
a
different
company
can
dismiss
the
block.
B
I'll
try
to
yeah
try
just
try
to
unblock
things,
because
this
is,
I
believe,
the
third
time
I've
seen
it
not
a
huge
blocker,
but
I
hope
next
time,
when
we
hit
the
same
issue,
we
don't
have
to
struggle
again.
F
That's
understandable,
but
I
think
like
just
like
what
you
said
right
there
like
that
it
can't
be
dismissed
from
somebody
from
the
same
company,
where
I
would
probably
disagree
on
like
90
of
the
issues
that
I've
seen,
because
a
lot
of
the
time
you're
going
to
find
somebody
who
is
proposing
something
or
asking
for
something
to
be
changed
because
of
an
implementation
at
a
company.
So
the
person
at
that
same
company
would
also
have
context
to
understand
if
that
has
been
resolved
or
not.
F
But
again
like,
I
think,
that's
completely
contextual
like
it
could
also
just
be
that
that
person
has
a
particular
coding
style
and
it
isn't
related
to
the
company.
So
I'm.
F
Can
codify
that
into
a
policy?
I
also
wonder
you
know,
is
two
days
appropriate
for
somebody
who's
on
a
week
vacation
you
know
like
these
are
again
like
contextual,
it's
really
hard
to
say.
F
Yeah
I
mean
I,
I
see
that
side
as
well,
like
you,
don't
want
to
stall
the
progress
for
the
month,
but
I
think
there's
a
large
gap
between
installing
a
project
for
a
month
and
waiting
two
days
for
somebody
to
respond.
F
B
G
So
you
raise
it
to
the
technical,
the
tc
and
then
they
maybe
are
have
a
better
ability
to
reach
out
to
a
specific
person,
who's
blocking
something
and
get
something
resolved,
and
so
it's
not
a
set
number
of
days.
It's
more
escalate
the
concern
which
might
be
after
a
certain
number
of
days
escalate.
Then
you
can
find
out.
Oh
this
person's
on
vacation
I'll
wait.
Even
you
know.
B
Well,
yeah
escalation:
oh
that
part
was
already
covered
in
the
current
contributing
dog,
so
we
already
explicitly
called
out
if
a
pr
has
been
stuck
for
a
long
time
then
reach
out
to
the
pc,
and
why
is
that
not
working?
Currently
I
I
think
it
is
working
for
relatively
bigger
thing
for
smaller
things,
where
we're
trying
to
hit
a
particular
release
timeline,
it's
becoming
challenging.
C
Okay,
can
I
make
one
suggestion-
maybe
here
looking
looking
at
the
details
of
this
pr
when
when
we
make
blocking
comments,
just
making
sure
it's
clear
so
so
in
the
event,
you
make
a
review
and
there's
a
bunch
of
comments
in
that
review,
making
sure
it's
clear
which
comment
is
blocking,
because
in
github
the
whole
review
is
marked
as
blocking
not
the
specific
comment,
that's
blocking
so
like
there
should
be
that
effectively
to
any
person
who
sends
a
pr
to
spec.
It
should
be
clear
how
to
make
progress.
That's
the
tease!
C
That's
like
the
goal
of
the
tc.
So
if
the
blocking
comment
doesn't
make
it
clear
how
to
make
progress,
the
tc
should
come
in
and
say
here's
the
thing
that
has
to
be
resolved
before
progress
can
be
made,
but
I'd
more
encourage
reviewers
to
do
this
ahead
of
time,
especially
in
the
the
like
header
for
the
whole
review.
If
you're
going
to
make
a
blocking
comment,
definitely
put
in
that
comment,
what
you
want
to
see
changed
and
the
exact
thing
that
needs
to
get
resolved.
C
So
it's
clear
to
someone
else
reviewing
whether
or
not
it's
been
addressed
as
well
as
much
as
possible,
and
if
it's
not
clear
to
anyone
what
the
blocking
comment
was
or
like
how
to
make
progress.
That's
just
an
issue
with
that
review.
Comment
that,
like
that
review
comment,
needs
to
be
better
right.
It
might
as
much
as
possible
now
to
be
fair.
C
As
tyler
was
saying,
people
go
on
vacation
and
there's
lots
of
nuance
to
some
of
these
things,
and
sometimes
putting
enough
context
into
a
comment
is
really
painful,
depending
on
the
nuance
associated
with
that
thing.
So
I
think
we
do
have
to
you
know,
use
some
judgment
here,
but
I
I'd
encourage
us
all
to
just
be
really
explicit
if
we're
going
to
block
a
pr
to
explicitly
say
what
it's
blocked
for
and
what
resolution
looks
like.
B
Yeah
good
suggestion:
I
think
we
almost
used
20
minutes
so
I'll
stop
here,
just
to
remind
people.
There
are
many
pr's.
So
please
help
to
review.
A
Perfect
yeah
that
totally
makes
sense.
Thank
you
so
much
okay
moving
on
then
some
because
we
have
the
20
minutes
at
the
end
for
metrics
sampling
updates.
H
Hi
I've
been
giving
an
update
weekly
on
that
topic
and
I
didn't
really
get
time
today
to
give
you
a
pitch
on
where
we
are,
but
I
have
been
working
on
a
strategy
to
get
us
something
without
causing
undue
harm
to
the
project.
The
thing
I'm
trying
to
avoid
is
that
we
force
otel
sdks
to
implement
the
current
spec.
That's
been
drafted,
everyone
approved
it,
it's
functional,
it
will
work,
but
it's
it's
not
really
what
the
people
want.
H
As
far
as
I
can
tell
so,
as
you
may
know,
if
you
follow
the
specs
we're
talking
about
a
trace
state
solution,
the
proposal
that
I'm
putting
together
is
that
we
spec
it
out
in
the
data
model,
but
don't
spec,
but
don't
require
any
sdks,
and
what
this
lets
us
do
is
vendors
can
start
to
implement
it.
Vendors
can
put
it
into
their
sdk
wrappers.
H
Vendors
can
start
to
interpret
that
data
and
use
sampling,
outputs,
but
the
hotel
project
doesn't
have
to
do
it,
and
then
we
can
continue
to
focus
our
energy
on
w3c
and
try
to
get
the
spec
that
we
want,
which
then
we
can
try
to
implement
in
all
the
sdks.
This
is
a
shortcut
I
think
it's
going
to
work,
so
I'm
writing
that
up
right
now
and
you'll
see
that
before
next
week.
That's
all
I
have
thank
you.
H
A
C
Yes
is
related
to
clearly
defining
comments.
I
should
have
marked
that
as
non-blocking,
but
I
assume
since
I
didn't
do
a
blocking
note
thing
anyway.
Sorry,
oh
thank
you.
Now
we.
A
Know,
thank
you
so
much.
Okay,
the
next
one
is
related
to
what
ps4
otlp
as
well.
It's
something
we
discussed
during
the
last
release,
and
now
there
was
this.
I
forgot
the
name
of
this
developer,
but
he
was
mentioning
that
why
not
offering
gcp
as
default,
because
that
would
you
know
like
it's
a
shoe
so
no
problem.
It
has
a
pair
of
approvals
already.
A
I
I
So
we
already
got
quite
some
reviews
from
the
people
involved
in
the
work
group
and
in
the
discussions,
so
it
would
be
great
to
like
get
some
have
some
other
people
look
at
it,
especially
the
trace,
approvers
and
the
us
bank
approvers
to
get
some
approvals
on
that
and
we
convert
it
and
also,
of
course,
if
there's
anything
that
you
wanna
be
changed.
Please
also
have
a
look
and
add
your
comments
and
yeah
on
this
thrust.
I
They
will
basically
start
actual
discussions
about
semantic
conventions
based
on
these
coping
scenarios
and
we
will
start
discussing
a
context
propagation
in
the
context
of
messaging
systems,
so
anybody
who's
interested
just
chime
in.
A
I
understood
correctly.
The
work
group
itself
already
is
happy
with
the
state
of
this
attempt
correct.
I
E
A
Perfect,
thank
you
so
much
for
that.
We
will
review
that.
Okay,
the
next
one,
is
attributes
that
are
most
for
sampling
scenarios.
I
don't
know
I
talked
to
me
a
little
while
yeah
perfect.
Please
go.
J
Yeah,
so
a
bit
of
a
context,
I'm
trying
to
define
which
attributes
should
must
be
provided
before
spend
starts,
and
these
are
the
required
attributes
that
are
available
for
http.
So
on
this
pr,
there
is
no
disagreement
on
this
part.
There
is
a
bit
of
discussion
between
beyond
between
most
or
should,
and
the
arguments
for
mass
that
I
have
is.
J
That
is
not
strong
enough
to
force
people
to
do
it
because
they
and
they
don't
always
understand
why
they
should
do
it,
so
they
kind
of
provide
attributes
later
or
if
it
should
different.
Instrumentations
do
different
things
and,
as
a
result,
like
scenarios
like
sampling
based
on
attributes
are
not
working,
and
this
is
very
far
from
people
who
did
the
instrumentation.
It's
on
users
who
experience
it,
so
I'm
kind
of
trying
to
say
must
to
force
everyone,
and
also
the
arguments
against,
must.
Is
that
basically
yeah?
J
We
recommend
it,
but
also
we
are
afraid
that
it's
not
feasible.
So
from
like
the
discussions
we
have
we
had
with
java
folks
and
also
from
what
I
don't
know
from
in.net
world.
There
is
it's
it's
feasible,
so
there
is
no
reason
to
believe
it's
not
feasible,
so
there
might
be
some
instrumentations
that
will
fail.
So
what
I'm
suggesting?
Okay,
let's
start
this
must
this
is
an
experimental
spec.
J
We
should
have
all
the
instrumentations
adopted
before
it
can
become
stable
or
the
next
version
of
it
whatever.
So,
if
we
will
find
out
that
there
is
a
problem
with
whatever
we
defined
the
number
of
instrumentations,
but
that
suggests
that
90
are
great
and
if
we
find
there
is
a
percent
percentage
of
instrumentation
that
can't
follow
it,
let's
switch
to
should
what
do
we
feel
about
it?.
A
E
I
think
I
I
really
like
the
pr
in
general,
I
I
do
understand
yuri's
point
between
must
and
should,
and
I
think
I
think
we
kind
of
mix
up
where
we
use
mass
versus
should
to
be
honest
in
in
the
spec.
So
I
is
not
the
first
time
when
I
see
things
being
showed
or
must
and
I'm
confused.
Is
this
a
really
must
based
on
the
rfc
that
defines
the
world
or
or
not?
So
that
being
said,
I
don't
blame
you
with
mila
being
confused
about
what
to
use
and
and.
E
To
to
make
progress,
I
think
another
thing
that
we
need
to
do
is
probably
to
have
a
tracking
issue
of
this
and
determine
if,
because
we
cannot
reach
consensus,
we
need
to
track
this
decision.
Somehow
correct
like
at
least
have
an
issue
and
say:
hey,
follow
up
with
like
five
six
sigs
to
see.
If
this
can
be
really
a
must
or
we
need
to
revert
back
to
should
because
they
couldn't
implement
this.
So
at
least
let's,
let's
track
the
the
the
possibility
or
the
the
fact
that
this
is
possible
or
not
in
parallel.
E
Probably
we
should
start
thinking
more
about
how
do
when
do
we
use
must
versus?
When
do
you
should?
Personally,
I
feel
a
should
should
be
very
strong
suggestion
to
do
it
and
you
should
just
not
do
it
unless
you
have
very
good
reasons,
must
is
required
for
me,
which
means,
if
I
fail
to
do
that,
I
don't
comply
to
the
spec.
So
it's
probably.
E
Beneficial
to
be
avoided,
if
possible,
but
anyway,
because
we
use
must
in
a
bunch
of
other
places,
I
think
it's
kind
of
we
alterate
the
meaning
of
the
words
a
bit
in
our
specification
so
yeah.
How
do
we
make
progress?
I
think
filing
an
issue
on
this
and
and
then
also
say
that
it
needs
to
be
fixed
before
the
the
specification
goes
stable.
So,
while
it's
still
experimental,
we
need
to
better
evaluate
this.
E
This
decision
until
we
we
make
the
final
call
when
stable,
because
when
I
mean
I
think
the
downgrade
is
fine,
even
after
stable,
but
let's,
let's
make
it
before
stable.
The
final
decision.
J
Thanks
it
makes
sense.
The
the
downgrade
after
stable
is
not
possible
because
it's
the
back
ends
that
will
depend
on
the
stability
of
the
spec
and
they
will
be
broken
if
it
downgrades
from
most.
It
should
so.
It
has
to
be
resolved.
E
Okay,
then
then,
then
it
has
to
be
resolved.
Then,
let's,
let's
I
don't
think
the
back
end
is
necessary,
because
even
if
the,
if
the
attribute
is
is
recorded
a
bit
later,
the
back-end
doesn't
see
that.
E
Yeah,
I
understand
so
anyway,
if
that's
the
case
and
if
we
know
there
are
reasons
that
will
be
a
breaking
change,
let's,
let's
make
sure
we
we
have
the
final
decision
documented
before
the
stability,
so
so
we
need
to
track
this.
J
Yeah
cool
make
sense.
I
will
edit
this.
I
will
try
to
get
more
feedback
on,
but
if
I
understand
correctly,
we
are
fine
with
this
experimental
state,
I
see
the
master
in
experimental
spec
assuming
we'll
have
issue
tracking
and
eventually
this
issue
will
be
resolved,
but
we
are
not
blocking
this
pr
on
the
issue
being
resolved.
Just
the
existence
of
the
issue.
E
I
would
personally
not
block
the
pr
and
the
way
this
is
my
way
of
proposing
how
to
make
progress
so
merge
the
pr,
with
the
caveat
that
you
can
even
link
the
the
issue
close
to
the
mast,
just
in
case
for
people
to
see
that
we
we
don't
know.
Yet.
That
is
the
right
decision
here,
but
we
aim
for
for
making
this
a
must
and
see.
If
we
succeed
or
not.
E
C
I
I
think,
that's
a
good
way
to
make
progress.
I
also
want
to
point
out
that
the
must
that
you
have
in
there
is
really
interesting
to
me,
because
it's
a
should
must
which
we
anyway,
it's
like.
You
must
do
this.
If
you
do
this
other
thing,
which
is
like
a
should
kind
of
a
thing,
so
it's.
This
is
a
very,
very
interesting
debate
to
me
and
I
also
don't
want
to
block
anything.
I
think
what
bogdan
proposes
is
the
best
way
to
make
progress.
C
We
open
a
bug,
we
make
sure
we
resolve
it,
and
you
know
I
have
my
own
personal
preferences,
which
you
saw
my
approval
on
the
pr
so
but
yeah,
let's,
let's
make
sure
it's
resolved
and
just
open
a
bug
and
merge.
H
So
my
when
I
say,
lazy
attributes
it's
something
that
was
present
in
parts
of
the
open
tracing
standard
and
I'm
saying
that
there's
a
moment
during
the
sampler
api
call
where
you
have
to
make
a
decision
and
the
question
is:
are
those
attributes
present
or
not?
If
you
make
the
attributes
be
lazy,
it
means
that
they
are
a
function.
You
can
evaluate
if
you
need
them
and
they
are
a
function
that
you
don't
evaluate.
H
If
you
don't
need
them
so
then
the
sampler
will
evaluate
them
early
when
it
wants
to
use
them
and
make
this
decision.
If
there's
no
sampler,
it
will
not
evaluate
them
early.
The
decision
will
get
made
anyway
and
then,
if
they're,
not
if
you're,
not
sampled,
you
won't
evaluate
those
attributes.
This
is
referred
to
in
issue
620.
I
think-
and
I
support
it-
it's
just
a
tremendous
amount
of
work,
so
I'm
not
particularly
eager
to
start.
E
Let's
separate
that
discussion-
and
I
really
like
that
idea,
josh
and
I
think
we
should
have
these
lazy
attributes
or
lazy
events.
He
was
by
the
way
he
was
in
the
initial
spec
here,
but
got
removed
for
for
better
or
for
worse,
but
I
I
think
we
should.
We
should
do
that
again
and
have
a
support
for
lazy,
evaluated
things
that
will.
E
I
think.net
also
has
some
crazy
reflection,
thinking
that
they
do
with
the
with
different
http
objects
and
stuff.
So
so
we
can
learn
from
from
them.
Probably
we're
not
gonna
have
the
power
that
they
have
in
the
language,
but
let's,
let's
see
how
we
can
propose
something
for
for
all
the
languages
here,
but
anyway
that
doesn't
mean
we
need
to
block
here.
E
I
think
I
think
it's
a
great
discussion
to
have
as
a
separate
thing,
and
maybe
maybe
we
will
not
be
able
to
stabilize
this
until
we
have
that.
That's
fine,
but
I
don't.
I
don't
think
we
should
block
this
pr.
J
Okay,
thank
you
and
short
comment
on
josh
s.
Soros's
should
must
it's?
That's.
The
part
comes
from
http
spec,
suggesting
multiple
sets
of
http
attributes,
so
we
never
know
what
actually
is
the
required
side
people
have.
I
think
this
is
the
issue
on
its
own,
but
it's
unrelated.
I
hope
to
solve
it
too.
Eventually,.
A
Perfect.
Thank
you.
Okay.
The
next
item,
which
is
the
last
before
the
actual
time
for
metrics,
is
that
we
merged
yesterday
at
this
pr,
the
nikita
field
for
not
setting
error
for
server
response
having
400
http
codes.
I
think
everybody
was
happy,
but
maintainers
have
to
know
that
this
change
happened
and
updated
instrumentation.