►
From YouTube: 2020-07-16 Spec SIG
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
B
B
But
basically,
I
think
users
should
be
able
to
register
an
error
handler
any
error
that
the
sdk
encounters
will
be
passed
to
it
and
you
can
use
it
for
things
such
as,
like
logging.
B
I
feel
like
this
is
related,
but
not
really
related.
This
is
not
really
something
that
we've
talked
much
about
at
the
heirs
working
group.
It
doesn't
really
solve
any
of,
like
the
suppression,
the
air
suppression,
things
that
we
were
talking
about.
C
This
is
really
about
recording
internal
errors,
or
you
know
failed
to
send
from
an
exporter,
for
example,
gives
you
a
way
of
reporting
that,
in
whatever
way,
you
choose
whether
you're
going
to
send
it
to
like
bug,
snag
or
log?
Something.
B
Yeah,
so
I
think
it
it's
something
for
you
to
do
something
other
than
just
log.
The
error
which,
hopefully
your
sdk
is
doing,
but
at
least
allows
you
to
get
a
handle
on
this
error
and
take
take
further
action
with
it.
B
Yeah-
and
I
guess
once
I
run
through
this
spec
sig
actually
we'll
get
into
some
air
stuff
towards
the
end
of
that
and
I'll
kind
of
recap.
What
happened
at
our
errors
working
group
a
little
earlier
yeah.
So
I
think
there
is
this
release
required
for
ga
tag
on
the
spec
repo
and
there
are
83
open
issues
and
I
think.
B
That
led
to
a
discussion
like
when
is
open,
telemetry
expected
to
ga
and
people
were
saying
you
know
this.
This
fall,
or
maybe
you
know
a
little
bit
later
this
year,
and
it
was
pointed
out
that,
in
order
for
that
to
happen,
that
would
be
like
closing,
like
an
issue
a
day,
which
would
probably
be
pretty
optimistic,
given
the
rate
at
which
things
get
closed,
especially
at
the
specification
level.
B
So
I
don't
know
that
anyone
had
any
great
solutions
for
this.
I
still
keep.
Oh.
If
anybody
will
listen
to
me
when
we
talk
about
this,
I
still
start
talking
about
rolling
ga,
where
you
can.
B
B
B
B
Data
but
yeah,
I
think
I
think
that
is
because
a
lot
of
these
are
around
errors.
A
lot
of
them
are
around
sampling.
Some.
B
B
But
so
there
there
kind
of
have
been
like
these
sub
sigs.
Now
that
are
spinning
up.
Metrics
has
been
around
for
a
while
error.
Reporting
is
another
one
that
happens
on
thursdays
at
8
a.m:
pacific
right
before
this
meeting,
there's
a
sampling
sig.
I
think
they
are
meeting
on
fridays.
B
C
The
sdk
side,
it's
still
possible
to
get
more
data
out
of
the
system.
It's
basically,
you
can't
make
breaking
changes,
but
this
is
protobuf,
so
you
can
certainly
add
new
fields.
You
just
can't
take
away
fields,
basically.
B
Then
yeah,
so
I
guess
moving
on.
B
People
have
come
around
on
this
issue,
which,
which
is
mine.
It's
a
it's
an
update
of
427,
which
kind
of
adopted
the
open
tracing
error,
semantic
conventions
for
for
open
telemetry.
This
basically
does
the
same.
It's
changed
very
little,
but
we've
changed
to
calling
these
exceptions
instead
of
errors,
because
it's
easy
to
identify
an
exception
in
code.
Error
is
a
little
bit
more
nuanced.
B
So
if
you
so,
this
spec
is
really
focused
on.
I
have
seen
an
exception.
I
want
a
way
to
record
and
report
it,
so
people
seem
happy
with
it.
The
last
comment
that
came
in
wanted
me
to
split
this
out,
though,
so
that
there
is
a
semantic
conventions
document
and
then
the
api
talks
about
we
talk
about
this
in
the
api
span.
B
Part,
so
one
of
the
things
that
were
that
was
brought
up
at
least
for
for
trying
to
get
better
velocity
is
like
not
always
trying
to
build
something
that
is
100,
complete
and
100
perfect,
but
approaching
things
from
is
you
know,
would
this
work
as
an
mvp
and
does
it
leave
the
door
open
for
us
to
kind
of
add
to
later
and
not
paint
ourselves
into
a
corner?
At
least
like
have
have
that
kind
of
approach
to
things,
and
I
think
that's
true.
B
I
think
this
is
mvp
for
like
hey,
I
had
an
exception.
This
is
how
I
can
record
it.
I
brought
up
two
other
things
at
this
meeting
that
we
also
talked
about
at
the
error
heirs
working
group
today,
and
that
is
okay.
Now
that
we
have
a
way
to
record
an
exception,
people
aren't
going
to
want
to
know
what
their
error
rate
is.
So
we
need
a
way
to
like
identify.
B
We
do
need
a
way
to
indicate
that
an
exception
is
an
error.
I
think,
every
time
we
have
those
discussions
at
the
spec
sig
level.
There's
always
these
things
where
people
are
like.
B
Well,
an
error
to
errors
are
very
kind
of
user
and
application
dependent,
so
an
error
to
one
person
and
application
might
not
be
to
another,
and-
and
I
agree
so
this
that's
the
thing
that
I'm
calling
air
suppression,
but
that
doesn't
mean
we
can't
have
a
way
to
identify
that
a
span
encountered
something
that
is,
that
is
an
error,
and
when
it
comes
from
auto
instrumentation,
your
auto
instrumentation
is
going
to
see
an
unhandled
exception
and
it's
going
to
do
the
best
at
it
best
thing
that
it
can
do
to
let
you
know
that
something
happened,
and
it's
probably
going
to
want
to
say
this
is
an
error.
B
I
think
where
air
suppression
comes
in
is
depending
on
your
application
in
your
system,
like
you
may
or
may
not
want
this
to
be
something
that
counts
towards
your
error
rate
or
basically
ends
up
being
something
that
you
end
up
getting
alerted
on.
You
don't
like
some
yeah.
I
think
that's
where,
like
the
interpretation
comes
in,
is
that.
B
B
I
think
that's,
that's
a
slightly
another,
a
slightly
different
topic,
so
I
kind
of
chunked
these
up
into
three
things:
exception,
reporting
a
way
to
flag
a
span
as
having
had
an
error,
so
kind
of
indicating
an
error
has
happened
and
then
third
kind
of
suppression,
ways
to
suppress
something
that
has
been
identified
as
an
error.
If
for
your
application,
it's.
A
A
B
So
we
haven't
taken,
we
haven't
talked
too
much
about
air
suppression,
yet,
although
it
was
kind
of
coming
up
at
the
ariz
working
group
today,
so
air
suppression,
I
would
say,
is
synonymous
with
expected
error.
B
Today,
the
discussions
at
the
errors
working
group
were
largely
around
possibly
replacing
span.status
with
just
an
error,
equal
true
boolean,
on
the
span.
B
I
can't
I
think
this
span
status
has
been
kind
of
controversial.
I
think
a
lot
of
people
don't
always
understand
it.
A
B
Yeah,
so
span
status
is
kind
of
a
canonical
list
of
statuses
that
google
has
made.
They
happen
to
also
be
the
grpc
statuses,
and
you
know
from
what
I've
heard
it's
a
very
well
thought
out
system
of
status
codes
and
that
at
google
like
they
are
able
to
map.
B
Basically,
you
know
errors
from
other
spaces
from,
like
you
know,
http,
maybe
even
posix,
into
this
canonical
canonical
list
of
statuses,
and
I
think
people
have
been
asking
like.
Can
you
tell
us
how
to
map
all
these
things
to
this,
to
the
google
canonical
status,
statuses,
and
maybe
this
would
make
more
sense,
but.
B
We
haven't
gotten
any
guidance
there,
so
I
think
now
people
are
just
asking
for
for
a
boolean,
something
that
you
can't
understand.
B
Ultimately,
you
do
kind
of
need
this
mapping
from
status
to
boolean
anyways
for
at
least
like
the
it's
like
jaeger
and
zipkin.
They
have.
This
error
equals
true
semantic
convention
and
right
now,
when
exporting
to
those
most
exporters
that
I've
seen
will
just
kind
of
interpret
any
spam
status.
That
is
not
okay,
as
error
equal,
true.
B
Yeah,
I
think
in
theory
it's
not
a
terrible
idea
and
like
it
yeah
like
I've.
I've
heard
from
former
googlers
that
this
is
a
really
well
thought
out
system
and
everything
will
map
into
it
somewhere,
but
unless
you're
also
going
to
provide
the
mapping,
I
think
it's.
A
B
Yeah
yeah
and
like
I
guess
there
was
like
a
group
of
people
who
worked
on
coming
up
with
this
canonical
list
for
quite
a
while.
They
studied
a
number
of
systems
to
make
sure
that
they
came
up
with
something
that
had
that
it
could
describe
all
air
conditions
that
they
were
aware
of
so
yeah
in
theory.
It
is
a
good
idea,
but
I
think
there
just
hasn't
been
enough
information
for
us
to
to
use
it.
B
I've
mentioned
this
before,
but
I
kind
of
noticed
that
every
sig
was
adding
our
mini.
Cigs
were
adding
environment
variables
in
kind
of
a
one-off
fashion
and
different
cigs,
we're
adding
differently
named
environment
variables
that
control
essentially
the
same
thing.
So
I
thought
we
should
have
a
place
to
collect
all
these
so
that,
if
you
add
an
environment
variable,
you
can
at
least
align
the
naming
in
conventions.
B
So
this
is
really
kind
of
an
mvp
there.
It's
not
meant
to
be
comprehensive
and,
as
as
I
went
through
and
just
kind
of
catalogued
the
environment
variables
that
were
in
different.
B
In
the
different
sdks
that
I
looked
at,
I
just
kind
of
put
them
all
in
a
list
and
tried
to
like
come
up
with
a
convention
for
naming
and
just
kind
of
unify
the
naming
so
in
in
that
process.
I
realized
that
there
were
some
common
themes
and
seemed
like
all
the
exporters
had
had
configuration.
B
B
B
B
This
is
a
pretty
short
and
sweet
spec,
but
I
think
it's
it's
good
to
have
this
just
so
that
there
is
alignment
over
what's
configurable.
C
B
Yep
yeah,
I
think
I
think
this
should
probably
mention
other
other
transports.
B
I
think
most
projects
have
just
implemented
grpc,
but
the
javascript
sig
is
in
a
similar
boat,
where
everybody
wants
something
slightly
different,
so
I
think
we
have
all
of
them.
We
have.
We
have
grpc,
we
have
proto
over
http
and
json
or
http.
C
Yeah,
it's
also
interesting
that
they're
splitting
up
span
and
metric
export
kind
of
the
point
of
open,
telemetry
protocol
is
that
it
includes
both
and
in
general,
I
wouldn't
want
to
have
separate
connections
for
metrics
export
and
span
export.
If
I
can
help
it
and
eventually
logs
export,
I
feel
like
I'd
really
want
to
have
a
single
transport
for
all
telemetry.
B
Yeah
I
mean
so
when
it
comes.
This
is
one
thing
that
I
was
curious
about,
especially
as
I
put
together
that
environment
variable
spec
is
whether
or
not
you
needed
separate
endpoints
for
spans
and
metrics.
B
It
seems
like
you
might
in
for
like
at
least
put
over
http
or
json
over
http,
depending
on
what
your,
how
the
backend
is
structured.
Basically,
just
how
is
routing
going
to
work
there.
B
C
C
The
I'd
almost
prefer,
or
in
fact
I
would
prefer
to
have
a
single
hotel
exporter
and
the
ability
to
indicate
which
kinds
of
things
I
want
to
be
able
to
export
from
it.
C
Or
I
don't
know
it's
just
the
way
this
document
is
structured.
It
really
feels
like
it's
assuming
I'm
going
to
have
separate
exporters
for
metrics
fans
and
eventually
logs
instead
of
a
single
one
that
can
handle
all
of
them
and
if
I'm
just
specifying
them,
if
environment
variables
and
then
in
fact
that
is
what
I'm
I
think,
forced
to
do.
C
Whereas
I'd
really
prefer
to
have
these
funnel
down
into
the
same
thing,
I
mean,
I
guess
we
need
separate
interfaces
for
spanx,
bottom
metrics,
exporter
and
so
forth,
but
those
are
just
apis
and
we
can
have
a
single
entity
that
actually
implements
the
the
you
know
by
duck:
typing
span:
exporter,
metrics
exporter
and
logs
exporter
and.
B
Yeah,
it
would
be
good.
It
would
be
good
to
comment
on
this.
I
was
hoping-
or
I
also
expect
people
from
the
collector
should
have
a
look
at
this
and
weigh
in
on
whether
this
separation
is
really
necessary,
because
it
is,
it
does
seem
inconvenient
right
if
all
of
your
stuff
is
going
to
the
same
place.
C
I
don't
know
how
this
lines
up
with
the
implementation
in
each
language.
C
B
Yeah,
I
think
I
think
one
yeah
you
mentioned
that
a
number
of
languages
do
have
otop
exporters,
and
this
is
one
of
the
reasons
why
why
we
really
do
need
this
spec
is
that
all
of
them
were
slightly
different.
B
I
think
it
was
kind
of
a
toss
up
whether
or
not
you
could
pass
headers
or
grpc
metadata.
I
think
that
this
is
a
synonym.
I
think
it
varies
based
on
what
your
transport
actually
is,
what
that
ends
up
being,
but
some
of
them
just
didn't
have
the
ability
at
all,
because
there
was
no
spec
to
say
that
you
needed
it
so
so
I
definitely
think
we
need
this
spec.
B
So
ultimately,
I
don't
think
this
is
it's
not
set
in
sewn
by
by
any
means,
and
I
think
any
feedback
is
would
be.
B
All
right,
riley
had
a
question
about
spec.
Mentioning
that
span
exporter
should
not
be
called
simultaneously.
B
C
Yeah,
so
I
mean
that's
been
there
for
forever.
Basically
that
requirement.
Well,
yes,
it
is
a
big
performance
concern
for
the
simple
span
process
case.
It
is
also
like
expected
right.
Simple
span.
Processor
is
typically
only
used
for
development
environments
when
you're
just
doing
logging
or
something
like
that.
C
B
C
B
C
Sure,
sorry,
I
just
in
the
background
looking
at
the
otlp
exporters,
it
looks
like
just
to
finish.
The
thought
there
it
looks
like
go
is
providing
a
single
exporter
that
you
just
configure
with
like
what
do
you
do
you
end
up
calling
oglp
new
exporter
and
then.
C
Yeah
that
implements
the
interfaces
for
trace
export
and
for
metrics
export,
and
you
just
plug
it
into
the
appropriate
export
pipelines
there,
the
other
languages
so
java
and
javascript
to
the
languages
that
I
looked
at.
In
those
cases,
they
provide
separate
exporters
for
separate
connections
for
metrics
and
for
traces.
B
A
B
So
we
have
zero
open
issues
in
our
current
milestone,
which
means
that
I
think
we're
ready
for
a
release.
Is
that
correct
yep?
That's
right.
B
Cool,
I
will
try
to
get
that
out
either
today
or
tomorrow.
B
B
But
yeah
I
will
at
least
start
prepping
this.
I
think
I'll
probably
just
need
to
do
like
a
virgin
bump
pr,
and
that
should
be
enough
to
get
things
get
the
ball
rolling
there
and
if,
if
the
release
turns
into
a
catastrophe,
I'll
probably
just.
C
Circle
ci
versus
github
actions.
I
have
not
seen
like
there's
no
pr's
in
progress
yet
for
this.
As
far
as
I
can
tell,
there
were
questions
on
ditter
about
it
and
there
is
an
issue
open
for
it,
but
yeah.
I
really
have
no
idea
what
the
status
of
that
is.
B
All
right
cool-
hopefully
nothing
has
happened
yet
and
I
can
get
this
release
out
before
something
happens
and
then
we'll.
C
But
yeah
yeah
there
are
no
actions
set
up
yet
I
just
took
a
look:
there's
no
action
set
up
yet
for
our
repo.
So
great,
I
think
we're
just
using
circle
for
me.
C
The
open,
tracing
and
open
census
compatibility
shims
are
well
at
least
the
open
tracing.
One
is
a
pr
that's
a
bit
stale
now,
but
we
probably
want
to
get
that
cleaned
up
and
shipped
at
some
point.
C
I
suspect
the
metrics
thing
will
just
get
punted
again
to
another
release.
I
think
we
probably
all
want
to
focus
on
tracing
for
a
while
the
open
census
compatibility
shim.
I
think
we
need
to
really
ask
at
the
spec
level
what
the
plan
is
here,
whether
we're
going
to
force
everybody
to
build
open
census,
compatibility
shims
in
each
language
or
whether
this
requirement
is
just
going
to
be
quietly
dropped.
C
We
don't
really
have
a
milestone
yet
for
post
alpha
zero
six.
I
don't
know
whether
we
think
we'll
have
enough
like
an
alpha,
zero,
seven
or
whether
we'll
have
the
beta
milestone.
Maybe
we
can
just
bump
those
two
to
the
beta
milestone
for
now.
B
C
C
August
sometime,
they
have
no
idea
about
the
adapters
when
those
will
will
get
done.
That's
a
whole
lot
of
help
wanted
at
this.
C
A
I
started
to
look
at
some
of
these
issues
this
past
weekend
trying
to
get
stand
on
where
they
are
I'm
trying
to
see
where
I
can
actually
help
push.
Some
of
these
we've
been
very
busy
internally
and
getting
already
out
the
door,
and
now
they're
almost
done
so
I'm
going
to
be
freed
up
actually
look
at
some
of
my
stuff,
I'm
trying
to
help
out.
I
don't
know
if
that's
gonna
help
you
guys
here,
I'm
hoping
to
be
able
to.
B
A
C
C
Should
adapters
really
be
part
of
these
milestones,
or
should
the
milestones
be
focused
on
the
requirements
laid
out
in
the
hotel
specification
and
then
the
second
question
is:
should
we
consider
moving
the
adapters
out
to
their
own
repo.
B
B
I
guess
the
question
is:
do
we
feel
like
the
api
and
sdk
are
stable
enough,
that
that's
not
gonna,
be
too
cumbersome?
B
We
did
have
a
repo
for
a
little
while
I
saw
they
closed
it
because
we
never
set
it
up.
We
can
always
ask
for
another
one
and
then,
in
terms
of
should
our
milestones
be.
B
Be
focused
solely
kind
of
on
the
required
for
ga
stuff.
I
feel
conflicted
there
as
well,
like,
I
think,
that's
like
probably
the
official
like
project
guidelines.
You
know
for
from
like
the
technical
committee
on
things,
but
we
could
have
like
a
really
nice
gold-plated
api
and
sdk
with
like
no.
B
A
I
think
for
me
having
it
all
in
one
repository
right
now:
it's
been
inefficient
because
I
I
get
a
better
view
of
what
all
we
have
and
what
we
don't
have.
They
would
all
step
right
down
and
I
had
to
go
hunting
and
trying
to
figure
out
things
and
the
other
thing
about
it
all
being
in
one
repository,
it
seemed
like
the
movie
communities
a
lot
smaller
with
a
lot
less
manpower
than
all
the
other
languages.
A
B
Yeah,
I
think
I
think
someday
we're
going
to
want
to
make
this
split,
but
I
my
gut
feeling
right
now
is
just
like.
If
we
decided
to
do
this
today,
it's
like
who's
going
to
have
the
time
who's
actually
going
to
do
it.
I
don't
know
if
any
of
us
are
that
person
right
now,
and
I
think
we
could
focus
our
efforts
on
on
adding
more
instrumentation
or
you
know
letting
these
exporters
and
other
things
that
are
going
to
be
a
little
bit
more
interesting
for
our
users.
I
think
we
should
definitely
keep.
B
A
A
B
Wings
yeah,
so
I
don't
know.
I
think
this
is
a
good
discussion.
I
don't
know
that
that
we
have
enough
information
or,
if
anybody's
strong
enough
opinions,
that
we
should
make
any
changes.
B
Let
me
know,
but
maybe
we
should
revisit
this
for
now-
I'm
kind
of
inclined
to
kind
of
leave
this
as
a
milestone,
I'm
kind
of
inclined
to
just
put
like
a
due
date
of
like
a
month
out
realizing
that
probably
only
a
few
of
these
things
will
be
done
by
then,
but
I
think
it
will
just
be
like
a
reminder
in
a
month
to
kind
of
look
at
where
we
are
and
either.
B
Scrubs
off
to
the
next
milestone
and
try
to
like
release
something
if
we
have
enough
or
just
extend
just
change
the
due
date.
If
we
think
that's
that's
the
best
thing
to
do.
C
C
At
some
point,
I'd
like
our
alpha
beta
ga
milestones
to
reflect
what
we
need
to
hit
in
terms
of
the
spec
and
then
possibly
add
milestones
for
things
that
are
outside
of
the
spec
or
that
are
above
and
beyond
what
the
spec
requires,
but
yeah.
I
don't
think
we
need
to
jump
into
that
mode.
C
Just
yet,
possibly
once
more
of
the
spec
ga
burn
down,
issues
have
been
resolved,
then
we
can
focus
more
on
like
what
do
we
need
to
do
to
ga.
B
Yeah,
I
think
that
all
makes
sense
so
so
yeah
as
as
we
have
information
or
as
as
we
want
to
make
improvements
to
this
process,
let's
just
bring
it
up
and
do.