►
From YouTube: 2020-07-23 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
A
C
C
D
B
I
also
wasn't
here
last
week,
so
yeah
nikita
matt,
you
wanna,
you
wanna,
run
this.
E
C
B
Just
pop
them
on
the
I'm
gonna
pop
the
link
into
the
chat
here.
If
people
don't
have
a
link
to
the
agenda
already,
also
people
wouldn't
mind
filling
their
name
in
under
the
attendees
section.
That's
always
helpful.
F
I'd
like
to
talk
through
some
of
the
issues
that
came
up
in
that
nikita's
pr
from
last
time
about
removing
the
span
status.
Thinking
about
it
and
looking
through
that
pr,
it
looks
a
little
bit
like
having
just
air
I'm
coming
always
from
the
perspective
of
the
back
end
and
like
filtering
errors,
especially
having
just
an
error
and
a
log
severity
makes
it
a
little
hard
to
filter
down
errors,
sometimes
because
you
can
filter
by
severity.
But
if
that's
set
by
some
instrumentation
somewhere.
F
D
Http
databases,
file,
system
whatnot,
so
we
we
have
exceptions.
D
D
D
E
C
There
was
the
actual
goal
on
that.
I
was
just
going
to
ask.
There
is
an
issue
to
remove
span
status
yes
and
create
created
by
you,
and
one
of
the
suggestions
was
replacing
it
with
simply
a
an
error,
equal,
true,
boolean
or
something
similar.
Is
this
still
something
on
the
table?
Is
this
something
interesting
on
the
call.
D
B
D
D
If
I,
if
I'm
not
mista
taken
right
now,
even
in
spec
in
spec
repo,
there
is
a
either
issue
or
pull
request
from
tigran
about
aiding
severity
to
like
spans.
As
the
first
add
severity
number
to
span
events.
Okay,
that's
part
against
no,
not
spawn
okay,
that
does
good.
So
we
we.
There
is
a
proposal
to
add
severity
to
spam
events,
and
that
seems
like
really
reasonable
and
make
sense,
and
now
the
question
when
this
is
done.
D
D
I
don't
know
an
answer
to
that,
and
so
I
would
say,
as
far
as
we
as
different
users
can
solve
their
problem
just
on
the
back
end
or
in
the
collector,
based
on
the
factual
information
that
has
happened
during
this
span.
D
C
So
I
still
kind
of
I
at
least
have
one
wishlist
item
that
I
think
is
probably
a
requirement
for
most
people
for
ga,
and
that
is
a
way
to
easily
tell
from
reading
a
property
on
the
span
whether
the
span
is
abnormal
or
not
like.
Ideally,
an
error
equals
true
or
a
status,
something
that
doesn't
require
you
to
have
to
iterate
through
span
event,
attributes
or
iterate
through
span
events
to
kind
of
try
to
determine
this
or
even
iterate
through
the
attributes
on
the
span
to
figure
this
out
so
like.
C
C
D
But
how
can
you
know
a
and
how
can
how
the
instrumentation
know
that
error
has
happened?
If
you
don't,
if
you
cannot
agree
on
whatever
it
is,.
F
So
one
one
suggestion
that
I
did
like
I
think
was
coming
from
christian,
which
is
a
field:
that's
not
a
boolean,
but
something
like
error.message,
something
that
you
can
put
detail
into
the
field,
but
the
presence
of
the
field
really
tells
you
like.
F
There
was
an
error,
so,
if
you're
just
interested
in
like
knowing,
if
there
is
an
error,
you
can
just
check
and
see
if
that
was
there,
and
also
if
you
want
the
filtering
capabilities,
if
some
instrumentation
is
saying
some
specific
error
is
relevant
enough
to
have
an
entry
and
error.message
and
some
user
wants
to
decide.
Actually
this
isn't
an
error.
They
can
do
that
filtering
because
they
have
the
deal.
The
detail
in
that
attribute
also.
D
So
I
have
like
two
so
first
to
math
that
having
a
field
as
opposed
to
attribute,
do
you
care
about
backend
cpu
cycles.
So
why
do
you?
Why
do
you
need
that
fast
way
to
find.
C
I
think
everybody
wants
their
stuff
to
be
fast,
but
I
think
this
is
going
to
be
a
a
common
operation
on
on
the
back
end
is
to
look
at
that
and
say
you
know
what
I
should
probably
scrutinize
the
span
a
little
bit
more
or
this
trace.
I
should
be
a
lot
more
worried
about
this
trace
yeah,
but.
D
D
B
So
what
yeah
I
mean,
it's
certainly
a
thing
we
do
at
light
step,
which
is
like
we,
we
have
a
more
advanced
form
of
sampling
where,
if
we
see
any
span
that
looks
like
an
error,
we
can
trigger
collection
of
all
the
other
spans
in
the
trace.
B
D
We
probably
want
that
extra
information
which
we
think
like
error,
message
or
detail.
That's
fine
question
is:
do
we
need
a
separate
field
for
that
or
it
can't
be
attribute
or
it?
Oh,
it
can
be
event
or
or
just
dramatic
connection
attribute
is
enough
because
that's
well
yeah
so
attributes
like
semantic
connection,
a
little
bit
easier
and
but
again,
if
you're
speaking
about
error
message
we
back
to
square
one.
E
Yeah
I
was
listening
this
discussion
and
I
I
had
some
some
thoughts
on
this.
So
first
of
all,
as
anyone
pointing
maybe
status
is
not
the
right
thing
to
have.
I
do
believe
personally
that
it's
good
enough,
but
anyway,
let's
assume
it's
not
good
and
you
should
be
moving.
E
Let's
treat
that
as
a
separate
discussion
compared
with
what
we
add
instead,
so
so
I
would
like
to
in
order
to
make
progress,
I
would
like
to
treat
them
as
two
separate
events,
and
first
event
should
be
okay
if
every
one
of
these
are
status
and
the
way
how
they
define
errors
like
codes
and
stuff
is
not
good
enough
for
for
for
this
thing,
let's,
let's
remove
it,
okay
and
and
try
to
to
come
up
with
a
better
solution.
Now
what
I'm
hearing
from
you?
E
What
I'm
hearing
from
you
guys
is
that
there
is
this
bullen
or
a
signal
of
something
is
an
error,
and
I
would
like
you
to
think
about
one
example.
For
example,
let's
say
in
a
file
system
call
you
get
a
return
value
called
file
not
found.
Okay.
Is
that
an
error
or
not.
B
Here's
what
I
wonder,
though,
right
this
keeps
coming
back
to
this
question
of
like
how
do
you
determine
whether
something's
an
error-
and
I
kind
of
want
to
like
put
that
aside
for
a
second,
let's
say
you
have
an
error
and
you're
like
hey.
This
is
an
error.
How
do
you
do
it
right,
you're,
an
end
user
you're,
not
auto
instrumentation
you're,
just
writing,
instrumentation
for
your
system
and
you're
like
I
want
to
know
about
this
situation,
because
it's
bad.
So
how
do
I
say
that
ideally.
E
In
an
ideal
world
in
an
ideal
world,
most
likely
okay,
so
I
see
I
see
your
point
but
but
before
doing
that,
so
there
are
a
couple
of
personas,
remember
our
docs
in
the
specs.
So
there
is
a
persona
that
does
just
the
instrumentation
of
if
the
file
system,
library,
let's
assume-
and
there
is
a
file
not
found
a
return
code
from
from
the
from
the
call
like
open,
you
do
and
file
open
and
you
get
the
file
not
found.
Do
you
set?
E
B
Yeah,
I
I
exactly
see
the
point,
so
it's
like
we
could
have
an
error
boolean,
but
maybe,
if
you're
writing,
auto
instrumentation
code,
you
don't
set
that
you
just
say:
here's
an
exception
and
like
the
sdk
or
you
know
the
collector
or
somewhere
down
the
line
like
someone
can
configure
it
to
be
like
yep.
Don't
want
those
I'm
I'm
calling
that
an
error.
Okay,.
E
Don't
use
auto
instrumentation
because
it's
not
auto
instrumentation,
it's
still.
It's
not
byte
code
or
is
not
all
magic.
It's
just
a
plugin.
E
Correct
so
the
the
person
so,
first
of
all,
we
have
to
understand
that
the
person
writing
generic
instrumentation
that
may
be
used
in
multiple
applications
cannot
say
what
is
an
error
or
not
yeah
I
mean
it
can
say
what
happened
like.
I
got
a
file
not
found
exception,
but
it
cannot
say
that
this
is
an
error.
C
So
this
kind
of
brings
up
like
I,
I
think
we
keep
going
back
and
forth
between
this,
like
what
is
an
error
to
it
to
a
user,
because
I
think
there's
no
universal
definition,
even
even
for
things
that,
like
90
percent
of
people,
can
agree
upon,
there's
a
always
going
to
be
like
a
10
who
wants
something
else.
So,
like
I
think,
error
suppression
is
definitely
a
and
something
that
needs
to
be
explored.
And
it's
something
that
you
could
consider
as
a
back-end
feature.
E
The
developer
of
this
service
probably
has
a
lot
more
context
of
the
application
behavior
and
can
say
sometimes,
as
ten
pointed
sometimes
this
person
can
say
that
okay,
this
is
completely
unexpected
for
my
application
for
my
service
for
my
behavior,
so
it's
correct.
So
there
are
scenarios
where
this
person
can
say
from
the
code
that
this
is
unexpected.
This
is
an
error.
I'm
not
going
to
behave
correctly
for
with
this
with
this
data.
E
E
Is
writing
some
instrumentation
itself
of
its
own
app
or
combines
other
instrumentation
plus
its
own
thing,
but
it
knows
it,
it
may
be
the
person
that
does
that
it
may
be
just
a
simple,
let's
say
the
the
sre
that
runs
this
and
knows
that
hey.
If,
if,
when
I
talk
to
to
the
db,
I
get,
for
example,
entry
not
found
on
a
on
a
lookout,
call
like
for
user
lookup,
that's
an
error,
but
when
I
get
entry
not
found
when
I
want
to
create
a
new
user,
that's
not
an
error.
C
So
so
I
think
the
problem
is
this:
error
could
happen
deep
in
your
database
library
and
this
this
persona.
This
application
developer
is
far
removed
from
the
the
code
where
the
exception
happens,
so
they
may
not
even
have
like
an
opportunity
to
to
identify
that
as
being
being
an
error
or
non-error,
even
even
if
they
wanted
to.
I
guess,
because
they
may
not
have
access.
E
On
their
api
on
their
public
api
as
a
service
owner,
you
should
know
what
you
return
to
the
previous
thing.
You
should
know
that
you
return
an
error
from
your
public
api
or
not
like
you.
You
should
know
if
your
receiver,
if
you
receive
a
request
to
create
a
new
user
and
the
ldap,
is
already
there
it's
already
existing.
You
know
that
you
return
an
error
to
the
to
the
caller.
E
So
somehow,
at
the
api
level
you
mean
you
probably
know,
because
I
I
cannot
believe
there
is
an
application
that
you
don't
know
what
you
return.
I
mean
you
have
to
return
something
to
the
caller
correct,
but
it's
so
what
I'm
trying
to
say
it's
super
complicated.
There
are
super
a
lot
of
scenarios,
yeah
and
so
far.
The
best
solution
that
I
found
is
first
of
all,
we
we
need
to
really
really
put
into
spans
in
different
ways.
E
E
B
I'd
actually
like
to
to
second
this,
I
know
everyone's
gotta
everyone's
got
opinions,
but
I
I
feel,
like
I'm
thinking
along
similar
lines
to
you
bogdan,
which
is
it
could
be
that
what
we're
saying
is
there's
something
like
an
error
field
or
like
a
span
status
that
doesn't
have
that
just
has
its
enumerations
changed
to
something
more
pointed,
like
user-defined
error,
or
something
like
that,
where
you
can
say
automatic
instrumentation
should
just
write
exceptions,
another
way
of
putting
this
it's
obnoxious.
B
B
B
B
I
want
that
to
be
marked
as
an
error,
or
you
could
get
into
more
advanced
pattern
matching
perhaps
in
the
collector
yeah,
and
we
say
like
this
is
how
you
should
do
it
and
we
could
even
come
up
with
like
pattern,
matching
schemes
that
were
like.
We
think
this
is
a
good
default
right,
like
all
http
500s
are
our
errors.
E
The
other
thing
is
what
error
means
for
the
trace,
so
we
are
talking
about
a
distributed
operation,
okay,
and
I
would
like
to
understand
what
setting
up,
let's
say,
a
boolean
or
whatever.
It
is
a
signal
that
a
specific
span
marks
as
an
error.
Does
it
mean
that
error
happened
in
that
span,
or
it
means
here
is
where
I
can
determine
that
is
actually
an
error.
There
may
have
been
exceptions
down
the
stack
in
other
spans,
but
the
combination
of
all
these
exceptions.
E
The
combination
of
all
these
behaviors
makes
me
to
feel
that
this
entire,
this
specific
operation
will
end
up
in
an
error,
but
that
doesn't
mean
that
error
happened.
Exactly
here
is
where,
where
the
combination
of
all
these
things
that
happened
down
the
stair
down
this,
the
call,
the
the
calling
stack
ended
up
in
an
error
here.
So
another
thing
that
I
would
like
to
to
to
to
maybe
think
about
is
the
scope
of
this
error
inside
the
trace,
because
it's
not
clear
that
one
span
may
may
cause
the
error
in
the
entire
thing.
E
I
may
have,
for
example,
an
operation
that
does
retries
and
even
though
I
may
do
prefer,
span,
get
off
request
failure
and
then
I
retry
I'm
succeeding
again.
That
doesn't
mean
that
my
thing
is
failing,
so
so
I
need
to
to
understand
a
bit
a
bit.
The
scope
of
this
error,
and,
and
and
and
one
thing
that
open
tracing
did
not
do
very
well
in
my
opinion,
was
exactly
your
example
that
if
I
have
an
an
exception
here,
I
need
to
mark
that
the
things
are.
Zero.
E
No
error,
error
and
exception
should
be
completely
two
different
things
like
marking.
Something
as
an
error
should
be
a
completely
different
thing,
and
it
may
mean
that
the
combination
of
a
lot
of
spans,
like
child
spans
or
child
of
child
or
grandchild
whatever
it
is
somewhere.
A
combination
of
multiple
events
happen
for
me
to
know
that
now,
I'm
in
an
error
state
here.
B
B
E
Failed
now
now
there
is
an
interesting
thing
is
this
can
do
we
want
to
have
only
on
the
stress,
the
big
trees,
or
do
we
want
to
have
it
only
on
the
on
the
sub
trees?
So,
for
example,
for
example,
if
you
have
multiple
service
calls,
you
have
a
front
end
and
the
back
end.
Okay,
front
end
calls
to
the
back
end.
The
back
end
calls
into
a
db
for
from
the
back
end,
for
example,
the
operation
of
create
user,
or
whatever
you
called
into
the
back
end.
E
Backhand
goes
talk
to
the
db,
cannot
reach
the
db
for
a
certain
period
of
time.
From
the
back
end,
this
operation
is
a
failure.
Okay,
because
I
have
to
return,
I'm
deadlining,
I
have
to
return,
or
I
close,
the
request
cancel
the
request
because
I
deadline
okay,
so
from
the
back
end,
this
is
an
error,
but
now
the
back-end
does
not
know
if
the
front-end
will
retry
and
the
second
time
will
succeed.
E
B
F
That
is
also
interesting,
but
it
would
probably
be
identifiable
just
from
the
presence
that
you
have
errors
going
all
the
way
up
your
trace
and
if
your
database
call
failed
and
then
also
your
front
end,
doesn't
retry
and
returns
an
exception
to
the
user,
whatever
that's
also
going
to
be
an
error
so,
like
those
are
kind
of
two
different
cases,
just
because
you'll
be
able
to
see
how
far
like
how
many
spans
have
error
are
flagged
with
this.
This
canonical
error
identification,
but
you
can
see
this.
E
F
D
D
If
I
can't
open
the
files
there
or
not,
which
means
that
no
backend
can
really
trust
that
one
single
boolean
field,
they
still
have
to
dig
deep
to
understand
what
has
happened
if
my
whole
system
is
out
instrumented,
I
don't
trust
that
boolean
flag,
because
nobody
knows,
except
for
me
for
the
back
end,
so
you
still
will
need
to
pass
your
whole
trace
and
span
in
order
to
understand
what
the
hell
is
happening.
We
cannot
trust
single
field
and
the
second.
D
The
only
point
you
can
make
that
the
the
decision-
if,
if
you
see
the
majority
of
the
trade
on
the
back
end,
you
can
record
factual
information
on
all
levels.
You
can
augment
that
factual
information
on
on
collectors,
if,
if
you
want,
but
it's
still
it's
not
that
simple
as
we
have
a
flag
on
honest
status
and
that's
enough.
A
Yeah
so
chris
hansen,
first
time
attendee
long
time
fan
yeah
yeah.
I
think
it
sounds
like
there's
a
general
agreement
that
we
want
to
stick
to
the
facts,
because
what
we're
talking
about
here
is
what
instrumentation
is
going
to
report
and
so
minimal
or
no
opinions,
just
just
the
facts,
and
that
the
the
what
happens
the
exception
that
occurred
or
the
error
that
occurred
is
a
fact.
The
boolean
may
not
be
enough
to
really
be
an
actionable
fact,
but,
but
that
the
instrumentation
doesn't
have
a
whole
lot
of
context.
A
So
it
may
not
even
know
about
the
full
span.
It
may
just
be
adding
an
event
to
the
span,
but
that's
pretty
uncontroversial.
You
can
say
okay,
this
section
this
exception
happened
in
getting
a
file
not
found
that
happened.
We
don't
know
the
impact,
but
at
least
we
record
that
event.
A
It
seems
like
something
that
hasn't
been
brought
up
in
this
conversation
is
the
distinction
that,
if
the
span
ends
with
that
error,
that
does
seem
meaningful
and
at
a
fact
is
that
an
exception
was
not
caught
or
an
error
came
back
from
like
a
go
function.
That's
that's
not
nil!
That
that
those
are
things
where
you
can
report
on
that
span
an
attribute
to
say
here's,
the
the
exception
class
or
the
or
the
error
message,
and
that
that's
not
that's
not
opinion.
A
That's
that's
part
of
what
happened
with
that
spam
and
then
we
can
leave
it
to
you
know,
upstream
or
downstream,
rather
to
to
say
you
know,
did
that
end
up
getting
recovered.
Was
that
just
part
of
some
some
circuit
breaker
or
exception
handling,
where
it
was
just
a
cash
cash
miss
that
got
they
got
recovered
from,
but
that
do
people
agree
that
that
the
span
ending
in
an
error
is
significant
and
should
be
reported.
A
E
Parents
parents
spend
from
the
code
will
know
if
I
called
foo
for
return
and
error.
If
I,
if
I
am
able
to
handle
it,
I'm
not
going
to
record
it,
I
mean
I
may
record
it
as
an
event
as
a
fact,
but
if
I'm
returning
it
to
the
parent
as
well,
then
is
when
probably
chris
points
to
so
so.
If,
if
I
have
a
function,
full
calls
into
bar
bar
returns
an
error,
but
then
I
do
something.
E
There
is
a
logical
error,
reporting
back
chain
that
happens
correct
and
the
spans
map
kind
of
with
these
call
chains.
So
if,
if
the
spam
reported
back
to
the
parent
and
error,
that's
probably
when
an
event
or
something
should
happen
on
our
side
to
to
say
that
an
error
happened
yeah
or
I
return.
Let's
say
I
return
an
exception
or
I
return
an
error
or
I
return
a
non-okay
thing.
D
There
was
a
proposal
during
record
exception,
recording
pull
requests
that
we
can
have
one
extra
attribute
if
that
exception
was
like
handled
or
not,
which
potentially
may
may
solve
this.
This
issue
as
well,
but
so.
F
F
If
we
don't
want
auto
instrumentation
to
whether
it's
error
equals
true
or
a
specific
status
code
or
something
we
want
the
instrumentation
library
instrumentation
to
just
record
the
facts,
about
an
error
and
also
have
a
separate
mechanism
for
end
users
to
say
like
no.
I
don't
even
want
to
record
the
facts.
I
just
want
to
say
this
was
an
error.
D
B
There's
just
this
one
nuance,
though,
which
is
helpful
to
not
have
to
inspect
every
event
on
the
back
end
to
know
whether
a
span
has
an
exception,
but
I
wanna.
Let
me
hang
on
a
second.
Let
me
run
with
this
just
for
a
second
something.
Chris
said
that
I
think
is
important.
Is
that
or
at
least
the
thing
we've
also
been
talking
about?
Is
that
it's
subjective
right?
B
B
B
C
B
No,
I
think
that's
good,
but
and
and
yes,
I
think
it
should
be
done
automatically
whatever
it
is.
You
should
just
perform
one
action
to
record
an
exception.
You
shouldn't
have
to
like
have
a
pile
of
steps,
but
what
I
wanted
to
get
at,
though,
is
maybe
what
needs
to
be
part
of
this
status
code
is
the
subject
if
it's
subjective
as
to
who
thinks
this
is
an
error
you
can
differentiate
between
whether
this
span
was
knocked
into
an
error
state
simply
because
an
exception
was
logged
on
it
right.
B
D
D
E
I
have
I
have
to
stop
this
discussion
and
tell
everyone
that
we
have
a
goal
in
the
next
couple
of
months
to
go.
Ga
so
because
of
that,
I
want
to
stop
this
discussion
and
remind
everyone
that
adding
new
new
fields,
new
things-
is
backwards.
Compatible.
Removing
things
is
not
so.
E
E
We
want
to
allow
recording
exception,
slash
errors
in
goal,
slash
whatever
it
is
in
other
languages,
and
then
there
there
is
a
discussion
about
recording,
an
error
or
user,
or
something
like
that
which
doesn't
feel
that
we
are
on
a
same
page
of
all
of
us,
I'm
proposing,
at
least
for
from
dj
perspective,
let's
document
the
first
two
agreements
that
we
have:
let's
put
them
in
place
and
maybe
maybe
start
giving
a
try
to
this
and
see
where
we
are
it's
it's
more.
E
I
think
it's
more
healthy
to
do
that
way
and
see
what
we
are
lacking,
because
adding
new
things
will
not
be
that
hard.
Also,
what
I'm
hearing
from
ted,
which
may
be
important
to
discuss
is
if
these
exceptions
should
not
be
put
into
events
and
maybe
put
in
a
separate
repeated
field
just
for
for
for
some
of
the
backends
that
want
to
look
only
at
this
to
to
to
do
it.
That's
a
separate
discussion
which
it
may
be
important
for
ga
to
be
discussed.
E
Also,
also,
to
be
honest,
we
still
I
mean,
let's,
let's
have
that
discussion.
So,
let's,
let's,
let's
have
a
list
of
agreed
things
and
let's
have
a
list
of
things
that
need
more
thoughts,
need
more
things
and
draw
a
line
of.
E
If
we
get
all
of
these,
we
are
confident
to
to
make
the
ga
step
if
we
don't
get
all
of
these
or
or
things
that
can
happen
after
ga
versus
things
that
cannot
happen
after
g.
Let's
put
this
way:
does
it
make
sense
to
everyone?
I
mean
I
want
everyone
to
focus
that
we
have
a
goal
of
gaining
very
very
soon
each
and
every
that
doesn't
mean
that
doesn't
mean
this
group
will
not
continue
to
work
after
ga.
B
So
I
certainly
think
we
should
stop
at
this
point,
because
we've
got
10
minutes
left,
because
I
think
this
is
a
good
discussion
and
do
what
you
said
and
first
record,
where
the
agreements
are
like
clearly
and
where
the
areas
for
investigation
are
that.
That
seems
reasonable
to
me
and
for
the
stuff
where
there
is
agreement.
E
Again,
removing
is
critical
right
now,
because
it's
backwards
incompatible
and
we
cannot
do
it
after
ga
that
easily.
So
if
we
are
not
sure
about
something,
I
would
encourage
everyone
to
take
a
step
and
say
remove
it
like
it's,
it's
the
right
time
to
remove
all
the
things
that
during
the
year
or
something
we
couldn't
convince
others
that
they
are
useful
or
something
let's
right.
Let's
start
a
bit
smaller
with
the
with
the
whole
idea
that
okay,
when
we
remove
this,
we
document
reasons
we
document
things
just
for
posterity.
E
B
I
think
this
is
great
if,
if
people
are
satisfied
with
this,
could
we
so
I've
got
agreements
and
areas
for
investigation
down
in
the
dock?
Could
we
can
we
just
iterate
over
them
again,
just
to
make
sure
it's
clear
at
a
speed
at
which
I
can
type?
So
I
think
the
first
agreement
I
think
in
general
is
the
current
span
status
is
too
subjective
and
should
be
removed.
C
E
Yeah,
that's
why
what
that's
I
said,
but
I
was
muted
it's
for
the
moment.
We
remove
it
for
the
moment,
because
we
are
not
sure
if
we
can
come
up
with
a
better
solution.
Man.
E
B
Make
sense
I'd
like
to
make
a
suggestion
for
a
second
agreement,
which
I
I
think
we
have,
which
is
that,
if
your
instrumentation,
you
shouldn't
have
to
do
anything
other
than
record
an
exception
event
with
a
log
severity
right,
whatever
we're
gonna
add
in
in
the
future,
if
you're,
just
writing,
instrumentation
right,
like
you're,
just
trying
to
report
what
the
system
is
doing,
you're
trying
to
be
objective,
you're
not
trying
to
be
subjective,
and
that
should
be
simple.
A
B
E
By
the
way,
give
you
a
bit
of
context,
we
talked
with
sanjay
me
and
josh
sanji
gemata
from
google
who
who
invented
these
status
by
the
way.
So
we
talked
to
team
and
say
in
in
google,
there
was
a
another
thing
called
error
space.
So
they
had
these
status
not
only
with
canonical
codes,
but
they
have
different
aerospaces
inside
google,
which
means
there
was
an
http
aerospace.
E
Where
we
report
error
codes
from
http
and
and
stuff,
they
found
it
very
hard
for
them
to
to
keep
to
keep
the
conversion
between
severity
or
anything
from
http
to
to
to
to
this,
without
having
only
one
way.
So
so,
essentially
they
had.
They
had
this
subjective
part
that
forces
them
to
drop
this
support
of
allowing
them
to
have
aerospaces
and
stuff.
B
C
C
E
E
Sure
do
other
spaces
map.
Do
you
know
offhand?
Yes,
they
mapped
even
these
corporations.
I
know
for
sure
they.
They
map
file
system
errors
because
they
map
that
into
the
disk
service
they
map-
I
don't
know
the
mapping,
but
we
can
ask
them
to
give
us
the
mapping
from
the
file
system.
I
know
for
sure
what
else
do
they
map
they
map?
Also
some
of
the
posix
codes.
I
can
ask
them
to
to
give
us
more
mapping
but
for
sure
they
might
file
system
they
map
http.
B
So
we
got,
we
got
two
minutes
left.
Are
there
other
agreements
and
areas
for
investigation?
We
want
to
record
before
we
end
here,
I
feel
like
we
had
more
bogdan.
You
had
a
good
list
before.
Maybe
you
can
help
me
fill
out
disagreements
and
areas
investigation.
In
fact,
anyone
in
this
call
is,
you
know,
perfectly
welcome
to
the.
D
F
It
sounded
like
we
were
all
in
agreement
that
we
want
a
way
for
an
end
user
to
mark
a
span
as
an
error,
something
that
is
not
just
necessarily
recording
more
facts
about
the
span,
but
just
saying
yes
put
the
sticker
on
it.
This
is
an
error
needs.
E
A
B
Yeah,
and
so
I
think,
there's
what
does
and
and
user.
A
B
Ideally,
we
keep
these
discussions
on
github,
that's
been
the
I
mean
we
can.
Certainly
we
have
a
getter
channel,
so
people
can
definitely
chat
in
there,
but
we've
been
trying
to
say
it's
a
little
more
helpful
to
keep
this
like
discussions
of
record
in
like
a
github
issue.
So
this
would
be,
I
think,
a
spec
issue.
Spec
issues
is
where
we'd
want
to
continue
this
stuff.
B
If
it's
more
concrete,
if
it's
just
trying
to
like
figure
out
what
kind
of
github
issues
or
just
chat
about
it,
then
then
the
the
getter
channels,
where
we
should
do
that.
But
if
we
start
doing
something
like
making
a
decision
or
having
some
consensus,
we
want
to
get
that
recorded
in
an
issue.
We
don't
want
getter
to
be
the
log
record
because
it
sucks.
E
B
Here
all
right,
I
don't
know
if
I
recorded
everything
in
these
agreements
and
areas
of
investigation,
but
we
are
at
a
time
so
yeah
make
sure
everyone's
logged
into
that
gitter
channel
and
paying
attention
there.
E
By
the
way,
matt
to
to
make
sure
I
I
feel
I
feel
the
instrument,
an
api
that
we
right
now
have
record
exception
is
good
enough.
Even
if
we're
gonna
keep
a
status
in
the
end,
because
from
the
exception,
we
can
transform
it
into
a
status
at
one
point,
so
I
don't
think
we
are
going
into
the
wrong
direction
by
having
an
api.
It's
especially
for
languages
that
have
exceptions
to
record
exception.