►
From YouTube: 2020-09-10 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
That's
the
thing
that
we
need
to
discuss,
I
believe,
but
if
he's
not
here
yeah,
let's
wait
a
bit
hope
he
gets.
D
E
Yeah
apologies.
I've
not
had
a
chance
to
look
at
github
yet
this
morning,
so
I
haven't
read
any
new
comments
that
may
have
showed
up.
E
E
A
E
So
with
just
to
make
it
clear,
I
started
with
the
additional
additional
status
codes
to
make
to
make
this
an
override,
and
then
there
was
a
request
to
possibly
make
those
separate
as
a
way
of
being
able
to
potentially
retain
that
status
code
space.
So
you
know
it
could
be
one
way
or
it
could
be
the
other,
but
yeah.
A
And
that-
and
that
is
my
my
my
main
problem
currently,
I
very
liked
your
in
the
initial
version
of
your
pull
request
exactly
because
it
from
one
point.
Through
from
one
hand,
it
removes
the
current
burden
of
the
instrumentation
to
map
every
possible
situation
to
that
fixed
google
status
quotient,
which
we
have
problems
with
it.
On
the
other
hand,
so-
and
it
completely
removes
the
burden
of
of
the
auto
instrumentation
to
to
decide
if
they
don't
know
what
status
should
they
put,
because
we
have
that
unset
or
undefined.
A
So
from
the
auto
instrumentation
perspective,
I
was
happy
and
at
the
same
time
time
there
is
a
possibility
for
end
user,
be
it
application,
developer
or
operator
guy
to
set.
I
know
what
the
status
should
be
yeah,
so
it
was
very
nice,
in
my
opinion,
very
nice
compromise
between
different
problems.
Current
state,
if
I
read
it
right,
contains
only
one
additional
field
for
override
and
in
my
opinion,
that
doesn't
solve
almost
any
problem.
E
Well,
we
could
definitely
include,
as
part
of
this
stripping
out
all
the
rest
of
the
statuses.
So
just
to
be
clear,
you
could
say
all
we
have
are
okay
and
error
as
the
two
statuses
and
then,
if
the
option
is
like
do
we
have
okay
and
error
and
then
two
additional
statuses
that
are
like
okay,
override
and
error
override,
or
do
we
have.
A
One
more
one
more
remark:
your
initial
version
didn't
have:
okay,
it
had
undefined
and
that's
very
that's
very
different
semantic,
and
I,
like
I
undefined
more
so
okay,
we
have,
if
you
have
undef,
so
that
we
have
to
have
undefined
okay,
error
and
and
the
field
for
for
that
boolean
override.
If
you,
if
you
want
to
have
a
boolean,
I
like
the
initial
idea
with
just
undefine.
What
was
that
all
the
right?
Okay,
overwrite,
false
or
write
error?
E
A
A
E
So
that's
what
I
had
before
and
then
there
were
requests
to
to
turn
that
into
basically
a
flag
and
then
the
other
thing
was
you
know.
I
didn't
want
to
necessarily
complicate
this
by
also
declaring
that
we're
stripping
out
the
remaining
status
codes.
But
if
that's
uncontroversial,
I
am
happy
to
just
put
that
back
in
here
and
say
we're
skipping.
A
F
A
E
Well,
I
mean
I
was
trying
to
add
in
additional.
You
know
additional
feedback,
but
to
be
clear,
I
I
think
the
main
thing
that
you're
looking
for
is
to
include
the
reduction
of
the
status
code,
space,
right,
you're,
saying
and
having
undefined
topics
and
then
have
undefined
as
the
basic
thing
I
think,
that's
perfectly
reasonable,
but
we
can
add
that
back
in
the
question
is:
do
we
want
to
have
this
override
as
a
boolean
or
or
something
in
the
status
space?
That
was
the
the
only
thing
that
really
changed.
E
As
far
as
like
okay
versus
undefined,
it
wasn't
clear
when
someone
would
set
okay
explicitly
and
have
it
not
be
a
user
override.
If
that's
a
thing,
then
we
can
add
that
back
in,
but
it
wasn't
clear
to
me
when
that
would
be
happening,
but
I
think
it's
fine.
So
we
can
do
that.
G
Yeah,
I
was
just
I
was
just
going
to
say.
It
seemed
like
moving
that
override
into
a
separate
field
seems
like
something
that
has
value
if
we're
going
to
keep
the
status
codes
around
so
that
we're
not
wiping
away
whatever
was
in
the
status
code
by
setting
a
different
field.
But
that
was
the
one
comment
I
had
kind
of
on
on
reading
through
this
was
that
the
behavior
of
the
existing
statuses
wasn't
super
clear
and
and
like
what?
What
they're,
really
implying?
E
But
I
think,
there's
just
to
be
clear.
I
think
there's
a
difference
between
saying
we're,
not
sure
what
to
do
with
these
right
now
and
saying:
there's
no
value
in
being
able
to
differentiate
between
different
statuses
without
having
to
parse
and
scan
all
of
the
attributes.
I
do
know
people
at
google
who
are
involved
in
the
creation
of
all
of
this,
and
you
know
it
was
done
with
a
lot
of
thought,
and
so,
if
we're
going
to
rip
it
out,
we
should
rip
it
out
with
a
lot
of
thought
as
well.
E
So
the
main
reason
I
was
looking
the
responding
to
the
feedback
that
maybe
this
should
be
a
an
override
is
because
we're
going
to
strip
all
these
out
right
now,
but
it's
not
clear
that
we
may
not
want
to
add
more
error
types
back
in,
maybe
not
all
of
the
one
that
we're
in
there.
I
could
certainly
see
like
network
errors,
are
fairly
standard.
E
E
I
do
think,
even
if
we
have
just
one
status
code
error,
we
do
need
to
have
a
status
mapping
even
with
that
right.
They
don't
have
to
pick
which
kind
of
error,
but
just
to
be
clear,
I
do
think
we
have
to
like
say
if
you're
writing,
instrumentation
and
you're
using
semantic
conventions-
and
this
is
all
standard
like
you,
don't
guess
which
http
status
code
you
know
maps
which
status?
Is
this?
Don't
guess
which
db
error
type
you
know?
Does
this?
These
are
the
errors
so
end
up
with
that.
It's
just
a
very
simple
mapping.
E
A
For
me,
there
are
at
least
two
at
least
three
different
different
topics.
In
fact,
one
is
we
want
to
mark
spann
as
interesting,
error
or
whatnot,
and
that
your
original
proposal
with
just
four
statute
statuses,
did
nicely
great.
Next,
we
have.
We
have
the
problem
of
those
reporting,
those
all
those
very
different
error-like
situations
like
network
errors,
almost
authenticated.
A
What
not
for
that.
We
have
the
the
seat
of
the
proposal
from
from
matt
about
having
those
separate
status
code
name,
spaces
without
need
to
map
everything
to
one
single
enumeration.
Go
go
google
that
we
that
will
nicely
explain
what
what
has
happened
without
without
having
again
to
decide.
If
that
error,
or
not,
that
separate
question
they
may
be
related,
maybe
not,
but
that
totally
is
a
separate
question
sure
and,
and
the
third
is
giving
recommendations
for
auto
instrumentation
with
that
how
to
map
different,
for
example,
http
status,
to
error
or
not.
A
I'm
not
sure
if
that
is
good,
because
that
that's
one
of
the
most
controversial
topics
that
we
had
at
the
beginning
and
again,
even
if
you
want
to
do
that
for
me,
that's
that
separate
thing.
What
what
what
we
have
currently,
I
think,
and
what
we
have
to
do
before
ga
all
other
things.
We
can't
do
after
ga
what
we
have
to
decide
before
ga,
if
what
we
do
with
current
spam
dot
status,
and
for
that
we
currently
have
two
or
two
two
proposals
which
are
mostly
accepted,
but
not
completely.
A
One
is
to
remove
status
completely
and
another,
this
new
all
tab
to
have
only
four
strategies
which
signal
error
or
not
ignore
override
that
we
have
to
decide
before
ga
all
other.
We
can't
decide
after
that's
why
I'm
trying
to
keep
the
scope
small,
that's
why
I
think
that
we
can.
We
have
only
two
options:
either
remove
status
or
your
attack
in
in
its
initial
version
with
four
statuses,
and
I
think
your
trap
with
four
statuses
is
less
controversial
that
might
for
removal
of
status,
yeah.
A
E
E
So
if
we
have
to
make
these
helper
functions
for
people
anyways,
which
I
suggest
that
we
do
because
it's
you
know
it's,
it
helps
us
make
sure
that
the
data
quality
is
high.
If
we
provide
tooling
to
instrumentation
authors
to
get
it
right.
If
we
say
it's
your
job
to
get
it
right
by
just
looking
at
the
spec,
then
it's
skewed
all
over
the
place
and
you
have
to
like
you
know,
really
pay
attention
to
what
everyone
is
doing.
So
I
do
think
we
need
to
provide
those
methods.
E
If
you
do
provide
those
methods,
those
methods
can
also
set
the
status
code
for
you
right.
So
even
that
you
don't
have
to
do,
is
it
an
error
or
not?
You
don't
have
to
think
about
that
anymore,
because
it'll
just
get
mapped
automatically
once
that's
in
place.
How
many
flavors
of
error
don't
matter
from
the
perspective
of
the
instrumentation
author
right,
if
it's
all
being
set
through
a
helper
function,
then
you
don't
have
to
worry
about
this
mapping.
E
A
E
People
who
are
writing
instrumentation
plugins
so
when
I
say
instrumentation
author
just
to
be
clear,
I'm
talking
about
people
who
write
plugins,
mostly
thinking
about
the
plugins
we
ship
by
default.
But
you
know
anyone
who
wants
to
provide
a
plug-in
for
their
library
right.
E
E
So
the
people
who
application
developers
they
can
make
a
subjective
decision
about
what's
an
error
or
not
that's
fine,
and
if
they
want
to
then
say
like,
I
really
mean
it
like.
E
Then
there's
an
option
to
to
set
this
boolean
in
order
to
say
like
this
is
not
just
like
this
differentiates
between
just
a
instrumentation
that
was
said.
This
is
saying
you
really
should
respect
this,
because
a
subjective
has
been
made
by
an
end
user
about
this
specific
situation.
So
this
is
actually
relevant
and
that
will
be
useful
for
back
ends
to
to
be
able
to.
You
know,
decide
which
thing
they
want
to
do
so,
and.
A
E
A
E
E
More
or
less
it
I
agree.
I
agree
that
there
are
many
cases
where
people
will
want
to
deviate
from
some
baseline,
but
I'm
saying
the
baseline
that
nothing's
an
error
is
incorrect,
so
there
has
to
be
another
baseline.
Even
if
we're
just
saying,
okay
or
error,
saying
nothing's,
an
error
who,
who
are
we
to
know
what
an
error
is?
That's
that's
not
a
good
starting
point
for
people
to
have
a
good
out
of
the
box
experience
it's
much
better.
To
say
like
this
is
a
reasonable
mapping
of
status
codes
or
other
things
to
error.
E
Okay,
now
I
mean
most
most
semantic
conventions,
it's
kind
of
straightforward
right.
If
it's
like
file
not
found
you're
like
well,
that's
an
error
or
if
it's
like
database
blew
up
you're
like
okay,
that's
an
error,
but
I
agree:
there's
some
gray
space.
Nevertheless,
we
do
have
to
pick
something
and
if
we
don't
pick
something
specific,
if
we
don't
say
if
you're
just
doing
this
from
scratch
and
you're
specifically
implementing
these
semantic
conventions,
these
are
the
status
codes.
These
are
the
ones
that
count
as
errors,
okay,
starters
and
then
going
past
that
end
users.
E
I'm
thinking
mostly
the
operator
would
probably
be
the
person
who
wants
to
do
this
can
adjust
that.
So
we
also
need
something
in
the
collector,
some
kind
of
configuration
language
that
that
makes
it
a
nice
experience
to
manage
these
things,
because
they're
going
to
have
to
do
this
anyways
right,
even
if
it's
their
own
stuff,
that
they're
setting
as
errors
or
not
there's
going
to
be
situations
where
they're
going
to
want
to
suppress
things
or
they
got
it
wrong
and
they
don't
want
to
do
a
redeployment
or
whatever
and
so
they're
going
to
do
this.
A
E
Override
we
have
to
have
a
status
mapping,
we
have
to
provide
convenience
functions
to
the
end
user
so
that
it's
not
a
pain
to
implement
any
of
these
conventions,
including
the
status
mapping,
and
we
need
to
provide
something
in
the
collector
to
let
them
massage
this
data,
so
those
are
agreed
right.
So,
if
you
have
those
as
all
of
the
pieces,
then
it
doesn't
seem
to
me
that
in
this
proposal
it's
a
necessary
thing
to
remove
all
of
the
status
codes.
Now
we
can.
E
But
my
point
is
in
the
proposal
as
it
is
now,
you
could
leave
the
status
codes
in
if
we
decided
we
wanted
some
or
later
on,
we
decide.
You
know
what
we're
gonna
add
some
back
in,
because
it
turns
out.
There
was
a
reason
for
these
and
in
our
rush
to
ga
we
just
didn't
figure
out
what
that
reason
was
you.
E
Saying
before
you
tear
down
a
fence,
you
must
first
understand
why
the
fence
was
put
up
right.
So
if
we're
gonna
do
it
the
way
I
propose
we
could
remove
all
of
the
status
codes
right
now
and
if
later,
we're
like,
we
have
to
add
some
back
in
those
can
go
in,
they
can
go
into
the
convenience
functions
that
we've
made
for
people,
and
this
will
like
keep
the
burden
light
and
I
think
it's
our
responsibility
to
provide
all
of
that
so
that
that's.
E
Shifted
to
what
I
did
and
when
I
shifted
it
just
to
be
clear,
because
I
was
no
longer
explicitly
touching
the
status
code
anymore
to
make
this
proposal
work.
That
was
why
I
didn't
leave
the
change
of
like
the
default,
be
undefined
versus
okay.
We
could
change
it
to
undefined
and
I
think
that
would
be
fine
or
not
set.
I
actually
do
think
that
would
be
fine,
but
that
would
just
be
a
re-labeling
of
okay
right,
we're
just
gonna
in
our
docs
and
everywhere.
Just
change,
okay
to
not
set
so.
A
Okay,
if
we
have,
if
we
have
the
possibility
for
our
instrumentation
to
not
set
statuses
or
to
set,
is
that
unsaid,
undefined
unknown
yeah
undefined?
That's
that's
one
less
concern
for
me.
That's
very
good,
and
now
my
next
question
you
all
those
pieces
that
you
said
totally
agree.
They
are
helpful
and
probably
even
needed.
Question
is
what
pieces
are
absolutely
must
be
for
ga.
E
The
pieces
that
must
be
for
ga
is
what
we
decide
on
the
status
codes,
you're
right
and
adding
this
user
override
and
adding
this
schema
like
we
could
do
the
schema
after
ga.
But
if
we're
like,
I
would
prefer
us
to
like
take
a
stab
at
that,
because.
A
That's
that's
my
concern
that
having
unset
status
is
probably
uncontroversial.
Having
that
override
marker,
probably
uncontroversial,
we
can
do
that
and
we
will
agree
as
soon
as
we
start
proposing
any
mappings.
A
E
Ask
but
there's
something
subtle
here:
we
could
remove
all
the
ex.
You
know
what
we're
calling
the
extraneous
status
codes
like.
We
could
only
have
one
flavor
of
error,
but
you
still
have
to
have
an
agreed-upon
mapping
of
our
conventions
to
errors,
otherwise,
otherwise
the
instrumentation
we're
shipping
to
people
is
going
to
be
uneven
right,
we're
going
to
be
shipping
a
bunch
of
http
libraries
that
don't
necessarily
flag
the
same
status
codes
as
errors.
That
seems
to
me
to
be
like
just
lowering
the
quality
of
the
data
that
we're
giving
to
people.
If
we're.
E
If
we're
gonna
say
that
people
need
to
set
errors,
they
need
to
set
these
conventions.
We
should
tell
people
that,
like
the
default,
the
starting
point
is
these
are
errors,
and
these
are
not.
You
can
deviate
from
that,
but
you
we
do
need
to
provide
some
guidance
to
people
who
are
writing
instrumentation,
so
they're
not
asking
this
question
of
like
well.
Otherwise
they
hit
the
point
of
these
like
http
status
codes,
and
they
go.
E
E
No
because
it's
not
that
it's
impossible
to
know
which
of
these
are
errors.
Obviously
a
bunch
of
them
are
errors
like
500s
are
obviously
errors.
You
may
want
to
squelch
some
of
those,
but
you
don't
want
to
start
if
open
telemetry
ships
out
of
the
box
and
doesn't
call
anything
an
error.
So
even
500
don't
get
called
an
error,
then
paul
draper
and
a
bunch
of
end
users
are
going
to
have
a
cow,
because
that's
okay,
not
what
they're
expecting
okay.
A
E
E
If
you
want
like
errors,
you
have
to
run
the
collector,
but
there's
two
problems
with
that:
one
now
we're
telling
people
they
have
to
run
the
collector,
and
I
love
the
collector,
but
we've
tried
our
best
to
keep
all
of
these
pieces
orthogonal
and
not
say
that
if
you
don't
run
the
collector,
then
open
telemetry
is
like
broken
or
like
missing
some
key
feature
and
air
reporting
seems
like
a
key
feature.
So
that
was
one
thing
that
was
making
me
concerned.
E
The
other
thing
was
talking
with
a
number
of
engineers
about
the
performance
concerns
of
having
to
do
this
on
every
span,
and
there
was
some
concern
there
that
the
the
overhead
of
having
to
do
all
the
error,
processing
and
scanning
all
the
time
was
was
problematic
and
in
fact
that
was
sort
of
the
point
of
the
the
error
status
to
begin
with
right.
So.
A
A
The
collector,
what
I
ask
I
haven't
talked
about
process
collector
at
all,
so
I
I
asked
we
have.
Can
we
have
two
separate
issues
or
prs
or
oteps
one
about
having
unsaid
status
and
probably
that
other
right?
If
we
wish,
I
would
prefer
to
have
only
four
strategies,
but
that's
okay
and
having
mapping
as
a
separate
issue.
All
all
I
ask.
E
And
I'm
saying
I
want
to
do
it
all
in
in
one
go,
so
how
about
this
I
can
I
can
remove
because
otherwise
I
don't
want
to
leave
this
contentious
stuff
around
and
I
don't
want
us
to
ship
instrumentation
one
way
and
then,
after
ga,
suddenly
change.
What's
coming
out
the
box
for
people.
I
would
ideally
like
us
to
to
get
that
right
and
I'm
willing
to
do
the
work
to
to
you
know
make
this.
This
schema
for
people.
This
status
mapping
schema,
and
I
agree
it's
a
lot
easier.
E
If
it's
it's
fairly
straightforward
to
just
say
it's
just
all
going
to
map
to
errors,
but
you
know
just
these
are
the
ones
that
errors
and
these
are
not,
and
then
people
can
you
know
bike
shed
about
the
the
defaults,
but
I
do
want
to
say
these
are
just
the
defaults
and
that's
why
I
want
to
include
stuff
like
the
collector
processor,
because
I
want
to
reassure
people
that
we're
just
saying
this
is
like
the
starting
point.
We
don't
want
people
to
start
from
zero.
We
wanted
people
to
start
from
a
reasonable
mapping
and
okay.
E
Like
specified,
then
that
means
explicitly
they're
no
longer
implementing
some
kind
of
semantic
convention
that
we've
defined.
So
at
that
point
they
do
have
to
make
a
decision
because
they're
doing
something
that
that
isn't
standard.
So
obviously
we
can't
provide
them
advice
about
which
status
codes
of
their
weird.
You
know
gamer
udp
protocol
count
as
like
you
know.
I
have.
E
When
does
mumps
emit
an
error,
I
have
no
idea.
I've
never
used
that
data.
What
should
I
do
right?
So
in
those
cases
they
have
to
make
a
decision.
Obviously
they
have
to
make
a
decision.
What
we're
saying
is
to
them
that's
what
definitely
out
of
out
of
the
box.
If
you
instrument,
one
of
those,
you
have
to
do
start
with
saying
like
these
are
errors,
and
these
are
not,
and
so.
A
E
D
E
E
A
E
One
issue
or
two
different
issues:
no,
it's
it's
one
issue
like
if
we're
gonna,
if
we're
gonna
change
the
status
code,
let's
do
it
in
this
this
pr
right.
So
if
we,
if
it's
worth
it
to
do
it,
let's
do
that
so
I'm
I
do
think
it's
fine
to
rename
okay
to
unset.
My
question,
then:
if
we're
doing
that,
do
we
need
an
okay
status
like
an
explicit
okay
status,
it
seems
like
we
do,
but
it
also
seems
like
we
don't
want
instrumentation
authors
to
set
that
right,
but.
A
E
E
If
you
want,
if
we
want,
if
we
want
this
part
of
this
pr
to
also
reduce
the
status
page
states
like
we're
going
to
say
it's
unset
and
okay
and
error-
and
that's
all
we're
going
with
for
now
and
we're
going
to
remove
all
of
that-
I'm
fine
putting
that
into
this
pr.
So
that
sounds
like
to
actually
be
the
controversial
thing
here
that
it's
not
solving
that
need
that
other
prs
were
trying
to
do
so,
just
to
be
clear,
let's
assume
going
forwards
this
pr
we're
talking
about.
E
B
Not
commenting
on
the
technical
merit
of
the
solution
just
on
the
process,
I
think
that,
if
we're
talking
about
the
mappings
as
in
specific
mappings,
not
just
generic
guideline
about
how
to
come
up
with
with
the
idea
of
whether
something
should
be
an
error
or
no,
but
if
we're
talking
about
the
actual,
like,
like
literally
tables
of
http
status
codes,
mapped
to
the
error
status.
B
I
think
that
that
is
a
significant
volume
of
work
that
will
take
time
so
for
the
for
the
from
the
perspective
of
process,
I
think
it
would
be
reasonable
to
decouple
these
two
things
right.
So
first,
first
come
up
with
the
data
model
of
what
an
error
is
and
how
it
is
recorded
in
span
and
then
again,
I
agree
it's
useful
to
have
the
guidelines
and
exact
mappings
for
the
instrumentation
offers
to
know
when
I
see
an
http
status
called
408
or
four
four,
four,
four.
B
E
Okay,
I
would
like
us
to
decide
if
we're
doing
it
or
not,
though
all
in
one
go
like.
I
do
think
if
there's
agreement
that
we
need
this,
then
we
should
keep
it
here
because
we're
trying
to
get
a
freeze
on
the
spec.
If
we
don't
need
to
implement
that
right.
If
we're
saying
like
we
don't
have
time
to
to
actually
massage
out
this
whole
table
before
ga
we're
sorry,
instrumentation
might
be
a
little
uneven
until
we
do
that,
then
that's
that's
life,
I
suppose
so
I
guess
it
depends.
B
B
A
B
B
E
We
we
have
to
provide
it
right
it
to
not
provide.
It
actually
makes
life
harder
for
an
instrumentation
author,
because.
B
E
F
So,
okay,
I'd
like
to
ask
kind
of
a
clarifying
question
about
the
process.
If
we
decide
to
merge
this
otap,
are
we
then
are
we
required
to
do
all
of
this
work
in
one
pr
to
the
spec?
Also,
no,
and
does
this
otep
imply
that
we
have
to
have
comprehensive
semantic
convention
coverage
in
time
for
ga.
E
No,
I
mean
we.
We
ideally
need
to
get
all
of
this
stuff
baked
into
our
instrumentation
right,
but
we're
we're
saying
ga
is
getting
the
core
stuff
out.
So
I
don't
want
to
lollygag
on
that.
But
you're
right,
like
we.
A
F
E
That
sounds
reasonable
to
me.
I
I
think,
but
I
don't
want
to.
I
guess
I
want
to
avoid
perfect
being
the
enemy
of
good
enough
right
like
we.
We
won't
be
able
to
define
all
of
these,
but
there's
the
big
sweet
spot
in
the
middle,
where
it's
it's
fairly
straightforward
and.
F
Yeah
this
is
what
I'm.
This
is
what
I'm
suggesting.
Maybe
in
this
otech,
we
say
that
you
know
we're
aiming
for
to
cover
like
the
happy
path
like
the
most
common
use
cases
we're
going
to
try
to
cover
in
semantic
conventions,
and
that
we'll
just
make
our
best
effort
to
add
to
those
over
time
as
we
need
to.
E
I
mean
it's
both
like
in
another
way
of
saying
this,
like
the
semantic
conventions
are
going
to
grow
over
time,
like
not
just
this
air
bit
like
like
yeah,
you
know
you
can
look
at,
especially
when
I
look
at
like
the
database
area,
for
example.
It's
it's
super
generic
right
now
and
that's
a
great
way
to
start,
but
eventually,
hopefully
we
can
get
some,
my
sequel
and
postgres,
and
you
know
experts
to
to
start
standardizing
some
of
that
information
better,
but
we
can't
do
all
of
that
by
ga.
Okay,
that's
that's
reasonable.
E
So
I
feel
like
the
loudmouths
have
been
talking
a
lot
so
far.
I
want
to
take
some
time
and
space
here
to
see
if
other
people
have
some
thoughts,
that
they've
been
putting
together
a
little
more
slowly
and.
B
E
B
Not
on
the
technical
merit
of
the
particular
suggestion,
but
I
think
it's
important
that
we
that
we
follow
the
right
principles
that
when
we're
doing
this
work,
there
is
no
full
agreement
on
the
of
the
opinions
of
how
exactly
we
want
to
record
the
errors,
and
in
this
situation
I
believe
it's
important
that
we
are
cautious
and
don't
overdo.
Don't
over
engineer,
don't
try
to
do
more
than
more
than
we
can
agree
on
right.
B
I
would
prefer
to
not
have
any
error
handling
than
to
have
an
error
handling
on
which
we
cannot
agree
on
yeah,
and
I
would
prefer
to
have
a
very
primitive
one,
a
simplistic
one,
as
opposed
to
a
very
comprehensive
one,
but
which
is
again
controversial
right,
as
I
just
want
to
suggest
this
as
a
principle.
If
we
guys
cannot
agree
on
the
very
smart
one
but
which
is
kind
of
difficult
to
agree
on,
then
let's
keep
a
simple
one
right.
Let's
have.
Maybe
maybe
that
means
that
we
don't
even
have
any
error
solution.
B
Hopefully,
it's
not
we
the
conclusion
that
we
come
to,
but
or
maybe
the
solution
is
that
it's
a
simple
boolean
flight
like
we
have
in
open
tracing
right,
but
I
want
to
ask
to
try
to
follow
this
principle,
because
this
this
topic
has
been
dragging
on
for
a
while,
and
I
feel
like
that
we
try
to
solve
a
non-trivial
problem.
It's
obvious
right.
It
was
trivial.
We
would
have
solved
it
by
now.
So
it's
a
non-trivial
problem.
People
have
very
different
opinions.
B
B
E
Yeah
yeah
sorry
for
the
the
ringer
about
not
waving
my
hands
about
the
status
codes
in
this.
I
agree
with
you
fully.
I
just
didn't
want
to
overreach,
but
I
realized
now
that
was
the
wrong
approach,
because
we
want
to
actually
just
get
everything
all
of
this
stuff
down
in
one
place
in
an
otep
and
agree
to
it.
C
Yeah,
I
I
was
just
going
to
ask
a
little
bit
about
the
override
and,
ultimately,
what
what
the
full
plan
is
is
for
status.
It
sounds
like
the
plan
is
to
pare
it
down,
but
yeah.
I
guess
like
the
from
my
perspective,
I
think
that
there
are
like
two
tried
and
true
methods
for
error
or
for
for
setting
kind
of
an
error,
status
or
error
like
status
on
spans,
and
one
of
them
is
kind
of
the
open.
C
The
other
thing
is
span
status,
which
you
know
has
been
tested
from,
like
at
google
and
as
part
of
the
census
project.
So,
like
I
think
ultimately
like,
like
the
google
canonical
space,
it's
probably
not
a
bad
space
at
all.
I
think
it's
just
like
very
misunderstood.
C
So,
like
I'm
wondering
if
we,
if
we
pare
down
status
like
I
do
think
it
should
be
kind
of
like
a
strict
subset
of
of
the
google
canonical
space
so
that
we
can
expand
back
into
the
kind
of
to
the
google
canonical
space
if
we
choose
to
and
as
we
get
kind
of
these
helper
methods,
that
will
help
kind
of
do
the
mapping
for
you,
yeah,
the
one
complication
is
kind
of
the
override,
because
it's
adding
in
possibly
some
new
statuses
if
it's
part
of
status,
but
if
it's
separate
from
status
then
like
it
kind
of
still
keeps
that
clean
separation
where
you
can
expand
into
a
different
or
to
the
google
canonical
space
without
having
these
problems
so
yeah,
I
guess
I'm
kind
of
wondering
would
this
be?
C
Could
this
be
like
a
semantic
convention
or
something
you
know
slightly
separate
from
status,
so
that
is
not
kind
of
changing
the
the
status
space
at
all
or
it's
not
augmenting
the
status
face
at
all.
E
So
in
the
current
proposal,
that's
an
extra
boolean
called
user
override,
rather
than
having
it
be
a
status
code
for
the
reason
you
suggested
right,
which
is
you
look
at
some
of
those
status
codes
and
some
of
them
are
like
data
loss
and
we're
like?
Oh
yeah,
that's
terrifying.
E
I
don't
know
if
we
need
a
precise
data
loss
status
code,
but
we
may
need
a
like
oh
status
code
at
some
point,
but
it's
not
useful
to
put
that
in
now.
If
there's
no
direction
of
what
people
are
supposed
to
do
with
it,
if
you
said
it
right,
but
if
we
want
anything
in
the
future,
we
seemed
like
we
were
gonna
cut
off
all
of
those
avenues.
E
If
we
made
the
override
status
codes-
or
we
would
just
end
up
in
this
like
giant
status
code
space
of
like
you
have
every
status
code
and
you
have
an
override
version
of
every
status
code.
I
guess
that
would
be
fine.
Why
not
have
more
enums
but
that
it
seemed
like?
Maybe
a
boolean
was
a
a
cleaner
way
to
do
that.
Yeah.
B
D
B
I'm
not
sure
about
the
name,
to
be
honest
user
override.
My
understanding
is
that
we
want
to
convey
the
information
about
who
recorded
the
status.
That's
my
understanding
was
it
recorded
by
an
instrumentation
author
or
an
application
offer.
B
If
that's
the
case,
then
I
think
that's
a
useful
information
to
record
and
that
that
that
complies
with
with
the
proposal
that
pogba
made,
which
I
like,
is
that
we
record
facts,
not
opinions
and
it's
a
fact
who
did
the
recording
right
and
maybe
a
better
name,
would
be
more
useful,
like
source
of
status
right.
Something
like
that.
I
don't
know,
what's
a
better
name
to
be
honest
to
to
answer.
Matt's
concern
about
the
status
called,
not
matching
the
google
space
and
possibly
creating
a
problem
down
the
road.
B
I
think
the
way
that
it
is
the
intent
is
to
have
okay
and
an
error,
values
right
and
the
third
one
which
is
on
set,
which
is
basically
we
don't
know
that
quite
closely
matches
the
open
tracing
right.
The
open
tracing
was:
is
it
an
error
or
not
right,
so
we're
not
attempting
to
categorize
the
errors
in
some
way?
We're
just
saying:
is
it
an
error
or
no
in
the
spirit,
it's
very
close
to
open
tracing
approach
with
with
a
single
boolean?
B
And
honestly,
I,
like
that
simplicity,
simplicity
of
that
right.
I
I.
I
don't
think
that
there
is
a
very
good
way
to
create
categories
of
the
errors
which
are
very
meaningful.
I
I
doubt
it
to
be
honest
that
what
google
did
is
very
valuable.
B
In
my
opinion,
if
you
have
a
specific,
erroneous
condition
in
your
application,
it's
very
it's
highly
dependent
on
what
you
were
doing
right.
Are
you
doing
an
http
request?
Http
has
its
own
way
of
telling
what
the
problem
is
actually
trying
to
map
that
into
some
categories,
generic
categories,
which
makes
sense
for
everything
in
the
world.
B
I
think
that's
that's
not
going
to
work,
that's
my
opinion,
so
I
haven't
seen
anybody
actually
demonstrating
that
the
google
status
codes
or
grpc
status
quotes
can
be
used
in
a
very
meaningful
way
to
do
some
smart
analysis,
where
you
don't
really
write
a
specific
code
for
for
your
analyzing
http
request,
but
you
don't
write
code.
That
knows
that
this
is
an
http
request
and
it
just
uses
the
generic
status
code,
and
it
works
very
nicely.
I
I
don't
know
I
haven't
seen
it.
E
So,
just
to
explain
why
google
did
it-
and
I
agree
with
you-
I
don't
know-
I
think
it
was
useful
for
google,
because
it
was
a
closed
system
right
like
there's.
Only
it's.
The
instrumentation
was
all
getting
funneled
into
one
analysis
tool
right
as
opposed
to
this
clean
separation
between
the
telemetry
and
the
analysis
tool
which
taking
a
tool
like
this
and
moving
it
out
into
the
open
source
in
the
real
world
outside
of
google.
You.
E
These
are
the
kind
of
changes
you
have
to
make,
but
why
they
just
to
clarify
why
it
was
useful
within
google
has
to
do
with
air
budgets
and
wanting
to
have
different
buckets
of
error
budgets
and
having
a
very
cheap
way
of
being
able
to
count
things
against
error
budgets.
And
so,
if
you
only
have
one
error
status
code,
then
now
you
have
a
choice
either.
E
All
of
your
404s
are
getting
counted
in
the
same
bucket
or,
if
you
don't
want
them,
you
have
to
go
back
to
to
scanning
and
since
they
really
care
about
performance
at
google,
I
believe
that's
why
they
baked
all
this
stuff
into
this
status
code
so
that
they
could
do
that
counting
and
aggregation
without
having
to
to
take
the
hit.
Now
again
when
we
move
it
out
into
the
real
world.
E
I
mean
we
like
to
say
that
we
care
about
performance
and
we
do,
but
it's
not
quite
to
the
same
fetishistic
level
that
they
do
inside
of
google
necessarily,
but
I
could
see
us
in
the
future.
I
believe
if
it
did
come
back
in
it
would
be
for
that
reason,
right
like
it
turns
out
it's
it's
expensive
to
not
differentiate
between
these
things.
E
In
some
way,
however,
I
believe
you
can
look
at
a
bunch
of
existing
systems
out
there
that
that
don't
do
this
like
I,
I
don't
you
know,
maybe
matt
you
can
speak
for
new
relic,
or
so
we
got
several
new
relickers
actually
justin.
You
should
speak
for
new,
relic
matt
you're.
Speaking
for,
like
I
said
now
like
this,
isn't
a
necessary
thing
in
new
relic
right,
this
kind
of
that
kind
of
optimization
they
were
doing
in
google.
F
For
spans,
I
think
no,
it's
not
a
requirement
for
new
relic.
I'm
definitely
very
curious
to
see
how
this
plays
out
for
metrics,
because
we
definitely
want
some
kind
of
low
cardinality
signal
about
metric
errors.
E
So
so
I
think
we
can
reduce,
I
think
what
tigran's
proposing.
Is
this
the
wisest
thing
right?
Let's
reduce
the
space
but
keep
the
door
open
like
for
now,
there's
just
one
kind,
but
we
don't
want
to
go
all
the
way
back
to
like
error
equals
true
boolean,
because
then,
if
it
turns
out,
we
want
any
of
this
other
stuff.
We're
just
going
to
reinvent
span
status.
E
E
I
think
that's
great
I'm
trying
to
to
capture
all
of
this
in
the
agenda
by
the
way.
So,
if
I
share
a
screen,
maybe
we
can
like
have
a
look
at
what's
going
on
in
here,
just
because
I
want
to
leave
this
meeting
and
go
make
these
edits
to
immediately
make
these
edits
to
the
pr
so
that
we
can
continue
the
discussion
there.
But
it
would
be
great
if
we
leave
this
meeting
on
the
same
page.
E
So
I
think
this
is
the
the
primary
thing
that
I
want
to
change
in
that
opet
is
saying
we're
going
to
explicitly
reduce
the
status
code
space
down
to
unset,
okay
and
error.
E
I
do
think
we
need
a
status
mapping,
but
I
can
put
some
words
into
that
otp,
that
that
does
that's
gonna,
grow
and
change
over
the
time.
We
don't
need
that
by
ga
and
then
there's
the
the
actual.
Maybe
remaining
bike
shed
is
okay.
We
want
to
have
this
override.
E
We
were
proposing
a
boolean
of
like
it's
just
I
mean
it
or
not,
and
a
more
nuanced
thing
I
think
just
got
proposed,
which
is
rather
than
a
boolean,
but
another
status
code
that
was
like
yeah,
you
know
you
could
have
like
instrumentation,
location
and
operator
would
be
the
three
three
people,
the
three
set
by
status
recorded
by
things.
Those
are
the
three
buckets
that
I
think
about
that.
We
have
right
now.
B
It
serves
the
same
purpose,
but
just
the
different
name
of
the
field
and
not
a
boolean,
but
then
any
narration,
but
I
think
guys
were
at
12,
so
we
have
another
sig
meeting,
starting
so
we're
using
the
same
zone.
We
have
two.
E
Well,
I'm
gonna
make
these
changes.
Hopefully
people
like
them.
I
appreciate
everyone
coming
onto
this
call.
Thank
you
all
for
taking
the
time
to
push
this
over
the
finish
line.