►
From YouTube: 2020-10-14 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
A
B
B
C
D
C
So
the
first
thing
I
I
had
a
question
about
the
this
trace
state
implementation,
but
actually
I
I
was
talking
to
bogdan
and
I
think
I
got
my
question
already
answered,
but
another
dynatrace
employee
had
noticed
that
the
the
tri-state
specification
states
that
it's
immutable
and
that
also
span
context
is
supposed
to
be
immutable.
C
B
That
was
me.
This
is
a
carlo
from
new
relic.
B
So
I
picked
up
this
issue
a
while
back
and
actually
nick
on
the
call-
and
I
are
both
working
on
this
and
we
were
wondering
do
we
just
pull
this
data
off
the
content
length
header
like
it
looks
like
the
spec
says
we
have
to
add
a
request
context
length
or
what
request
content
length
attribute
to
the
trace
or
a
request,
content
length,
uncompressed
and
I'm
not
sure
if
we
have
to
calculate
that
out
or
if
we
just
grab
that
from
the
content
length
header
itself
see
if
the,
if
it's
encoded
or
not,
and
if
it's
not
encoded,
do
we
set
that
as
the
content
length
uncompressed.
C
I'm
not
sure
what
other
sigs
have
done
about
this,
but
I
think
that
probably
just
using
the
content
length
header
is
acceptable.
You
know
just
purely
from
a
a
performance
standpoint.
It
is
probably
simpler
and
faster
to
just
grab
that
header
and
if
it
happens
to
be
wrong,
then
so
be
it,
but
in
most
cases
it
will
be
correct
so
in
in
basically
all
cases
it
will
be
correct.
So
I
wouldn't
worry
too
much
about
it.
Great.
C
A
C
Okay
yeah,
so
I
mean
this
is
probably
mergeable,
except
valentin
mentioned.
He
got
another
error
when
he
was
trying
to
test
it.
A
A
C
So
if
people
can,
please
approve
the
the
12-0
proposal,
I
would
appreciate
that
I
also
wanted
to
mention.
There
are
a
couple
of
prs
that
are
required
for
ga.
C
But
because
these
are
required
for
ga
I'd
like
to
get
them
approved
and
merged
as
quickly
as
possible,
it
looks
like
this
one
actually
already
has
enough
approvals.
C
Yeah,
so
I'll
probably
just
merge
this
one
if
everyone's
okay
with
that.
C
C
E
E
I
added
this
global
error
handler
and
that
merged
recently,
so
some
of
you
may
notice
a
bunch
of
spam
in
standard
out
when
you
run
tests,
which
is
not
great,
but
I'm
not
exactly
sure
what
to
do
about
it.
So
I
was
just
gonna
say
I
I
have
an
issue
here.
If
somebody
has
opinions
or
knows-
or
you
know,
yeah
has
some
ideas
of
the
best
way
forward.
Let
me
know.
C
C
So
I'm
not
sure
if
we
maybe
in
the
default
error
handler,
we
could
detect
whether
or
not
we're
in
tests.
I
don't
know
if
there's
a
reliable
way
to
do
that.
E
I
can
think
about
that
and
if
yeah
I
can
look
into
that
and
think
about
that.
C
Yeah
I
mean
maybe
we
could
even
just
set
an
environment
variable
directly
in
the
package
json
before
we
run
the
test
suite.
We
could
just
run
like
hotel
tests,
true
or
something
like
that
and
check
for
that
in
the
yeah.
A
C
C
So
I
know
short
meeting
today
so
far.
I
guess
ken
was
that
your
name
from
red
hat
are
you?
Was
there
anything
specific?
You
were
looking
to
talk
about
or
learn,
or
are
you
just
looking
to
contribute,
or
are
you
just
here
to
listen
in.
C
Oh
actually
look
like
he
left.
Okay,
all
right!
Well,
I
guess
I
mean
that's
all
I
had
for
today.
If
nobody
else
has
anything
that
they
want
to
talk
about,
I'm
happy
to
give
you
guys
your
time
back.