►
From YouTube: 2020-09-17 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
B
That's
actually
a
really
good
plan.
I
wasn't
sure
if
this
was
going
to
happen
today,
because
ted's
otep
was
merged,
but
here
speak
of
the
devil,
hello.
A
A
A
C
We
actually
work
on
specification.
A
lot
of
changes
can
still
happen
and
that's
like
we
I
mean
I
understand
his
point,
but
this
is
not
a
specification
change.
This
is
just
an
attempt.
You
know
that
this
is
trying
to
settle
the
ground
and,
of
course,
in
the
specification
itself,
we
can
probably
talk
about
any
any
change
that
we
want.
A
I
agree:
yeah
I'll,
send
a
message
with
that.
I
won't
make
you
all
sit
here
while
I
type
it
up,
but
I'm
confident
that
the
people
who
care
about
this
are
satisfied
as
well
as
anyone
can
be
satisfied
on
such
a
tricky
subject,
and
I'm
happy
that
the
proposal
that
we're
doing
doesn't
involve
a
bunch
of
breaking
changes
and
it's
extensible.
A
A
Let's
just
not
report
errors
and
back
ends,
we'll
figure
it
out
that
that
was
rushing
if
we
rolled
something
like
that
out
without
really
proving
that
it
would
work,
because
it's
a
pretty
big
departure
from
how
open
census
and
open
tracing
works,
whereas
the
thing
we
merged
it
now
really
isn't
it's
it's
the
same
stuff
we've
been
doing
and
no
works.
It's
just
a
little
more
nuanced,
so
I'm
satisfied
but
yeah
do
people
have
other
things
they
want
to
talk
about.
A
On
this
front,
we
could
potentially
move
to
talking
about
some
of
the
nuances
of
merging
some
of
this
stuff.
A
But
did
people
have
other
subjects,
air
related
that
brought
them
to
the.
D
D
A
A
Yeah
today
I
want
to
go
in
and
clean
up
yeah
there's
a
fair
number
of
issues
around
removing
status,
codes
and
stuff,
like
that.
I
think
we
can
just
go
in
and
do
a
clean
sleep
of
all
of
that.
I
think
the
api
changes
are
really
straightforward.
A
That's
that's
not
going
to
be
complicated
to
add
and
I
think
actually
adding
the
status
code
designations
to
our
semantic
conventions
might
take
a
little
bit.
I
mean
it's
easy
for
http,
but
it's
kind
of
a
question
mark
for
things
like
database
protocols,
but
you
know
we
agreed
that.
Doesn't
that's
not
a
blocking
it's
not
on
the
critical
path
to
ga
right
now.
So
I'm
not
worried
about
that.
The
one
thing
I
am
a
little
worried
about-
or
I
think
at
least,
is
going
to
require
some
attention.
A
Is
the
protocol
changes
to
otlp
because
we're
changing
around
enums
and
status
codes
and
things
that
are
already
in
there
and
otlp
and
the
collector
are
the
parts
of
open
telemetry
that
probably
have
the
most
adoption
at
this
point.
So
I
think
that's
actually
a
tricky
wicket,
so
I'm
hoping
tgrin
has
some
good
ideas
on
that
front.
A
But
if
there's
anyone
on
the
call
who
can
think
about
what
what
the
constraints
or
gotchas
might
be
there,
that
would
be
good
to
get
a
list
of
them
going.
A
Yeah
and
maybe
that's
just
what
we
do,
but
the
protocol
is
a
little
bit
different
than
like
what
the
collector
does,
and
you
know
I
do
think,
because
we're
keeping
the
status
code
field
but
changing
the
enums
in
it.
That's
probably
the
part
where
there's
maybe
some
nuance,
there's
probably
a
couple
ways
to
do
that
like
are
these
all
new
status
codes,
so
you
can
differentiate
them
from
the
old
status
codes.
A
Can
we
just
remap
existing
status
codes
and
then
what
happens
to
the
old
status
codes?
You
know:
do
they
get
deprecated
and
left
in
or
do
we
rip
them
out
and
things
break
for
people
if
we
rip
them
out
but
reuse,
a
status
code?
Okay
gets
mapped
to
what
used
to
be
an
error.
Is
that
gonna
create
a
disaster
for
someone
with
an
edge
case,
not
realizing?
They
have
a
new
version
of
the
protocol
stuff
like
that.
A
So
I
think
that's
the
only
nuance,
but
I
think
we
have
enough
protocol
protobuf
experts
on
the
project
that
that'll
get
solved
correctly
so
yeah.
Hopefully,
I'm
gonna
make
prs
for
all
of
this
except
the
proto
part
today,
and
so
hopefully
we
can
get
those
less
controversial
pieces
merged
and
so
be
on
the
lookout.