►
From YouTube: 2020-07-16 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
A
A
C
Dokie,
this
is
great.
Now
we
won't
collide
with
that
other
zoom
meeting.
It's
always
a
little
annoying,
because
we
want
these
recordings
to
be
separate
when
they
get
uploaded.
So
if
they
start
winning
the
meeting
before
we
leave,
and
it
just
turns
into
one
long,
continuous
recording,
that's
the
reason
why
we
want
to
use
this
other
zoom
link
a
job
date.
The
information
for
the
calendar
already
I
I
did
yeah
but
again,
I
feel
like
I
did
this
last
week.
D
C
C
E
F
F
E
F
E
F
F
C
Okay,
so
hopefully
that
puts
us
taking
exceptions,
at
least
from
the
spec
issue
seems
like
we're
over
the
finish
line
on
that,
which
is
great.
Are
there
just
to
clarify?
Are
there?
Is
there
further
work
on
exceptions
from
the
point
of
view
of
semantics
conventions
or
anything
else?
Not
not
the
the
error
flagging
that
we're
gonna
get
into,
but
I
believe
that
what
Matt's
done
covers
all
our
bases
from
a
spec
point
of
view,
I
just
want
to
clarify.
Does
anyone
else
think
there's
something
else
related
to
exceptions?
E
That
was
pull
requests
recently
with
what
just
got
cancelled.
We
aim
to
like
expand
spam
status.
There
was
a
discussion
about
the
current
spam
status,
which
is
like
a
copy-paste
of
juror,
PC
statuses
and
we
tried
people
tried,
I
hadn't
participated,
yet
people
try
to
understand
why
these
enumeration
of
statuses
came
by.
So
why
Google
introduced
these
list
of
statuses,
yeah
that
haven't
been
answered
yet
by
by
by
today
by
Google
pp-people.
E
But
then
a
couple
of
opinions
started
appearing
that
do
we
need
that
status
at
all
because
well,
apparently
we
don't
know
for
sure
what
the
numeration
of
statuses
do.
Do
we
want
there,
so
there
was
a
proposed
of
removing
that
statuses
and
the
several
people
chanting
that?
Yes,
that's
a
good
idea.
Nobody
understand
nobody
from
the
vendor,
clients
ever
needed
that.
Why
do
we
have
that
and
so
to
start
things
moving
I
have
created
that
issue.
So
if
we
don't
understand,
why
do
we
need
the
status
and
current
status
start
to
assess
enumeration?
A
The
way
just
for
reference,
the
checker
exporter
and
the
open
tracing
team
for
Java,
they
use
this
one
to
mark
errors.
So
there
are
manual
use
case,
but
yeah.
We
need
to
consider
you
land.
They
use
this
one
which
one
studies
so
basically
yeah,
because
they
have
this
open
tracing
style
of
error
or
boolean
thing
to
sell
it.
It's
not
a
might
major
case,
but
still
use
for
further
reference.
A
E
G
G
C
The
purpose
of
the
status
code
is
to
tell
the
telemetry
system
to
do
something:
you're
telling
the
telemetry
system
that
a
span
is
like
just
an
ordinary
span
or
you're
saying
this
is
an
exceptional
span
in
some
way,
and
so
the
backend
system
should
recognize
it
as
a
exceptional,
and
the
assumption
should
be
that
if
you
do
that,
the
the
chance
that
it
will
be
recorded
goes
up.
That
to
me
is
the
the
primary
purpose
of
something
like
an
error
flag
or
a
status
code.
E
E
C
C
Makes
a
lot
of
sense
I
see
so
yes,
severity
would
work
better
than
a
boolean.
There
was
feedback
from
open
tracing
that
a
boolean
was
not
quite
enough,
so
yeah,
something
like
that's
a
little
more
extensible
than
just
a
boolean
would
make
me
feel
comfortable.
So
maybe
that's
it.
Maybe
it's
it's.
We
just
use
severity.
I
think
the
reason
why
severity
felt
a
little
weird
for
me
as
people
often
request
something
like
that,
so
that
they
can
drop
spans
out
of
a
trace
they're
like
we're
generating
too
many
spans.
So
we
want
to
drop
them.
C
Thinking
like
I
drop,
my
unimportant
logs
the
thing
about
dropping
spans
other
than
logs
as
spans
are
structural
right,
yeah,
so
you're
changing
the
shape
of
the
graph
you're
changing
the
context
in
which
things
occur
and
it
it
doesn't.
It
becomes
super
unclear
what
what
it
means
in
some
cases
to
be
to
be
saying:
I'm
going
to
drop
some
spans
out
of
a
trace,
but
leave
some
other
guns.
So
I
think
that's
that's
the
only
issue
I
would
have
with
calling
it
log
severity
is
need
to
do
something
to
make
sure
people
understand.
C
It's
not
for
dropping
span
just
for
maybe
choosing
whether
to
record
an
entire
trace
or
not,
but
it's
actually
you
as
an
end-user.
You
should
know
you
don't
want
partial
traces.
You
don't
want
to
be.
You
want
to
be
comparing
apples
to
apples
with
your
traces,
so
you're
either
want
the
trails.
We
don't
want
the
trace
so
but.
E
C
I
think
something
like
that:
I
mean
at
the
end
of
the
day.
It's
still
just
another
form
of
status
code
right
like
log
severity,
that's
essentially
a
status
code,
we're
just
the
difference
is
like
the
current
status
code
has
some
semantic
meaning
to
it
beyond.
Just
how
bad
is
it
right?
It's
trying
to
have.
C
E
C
E
C
I
want
to
think
about
this.
Does
this
in
a
way?
Maybe
this
unifies
things
right
in
the
sense
of
it
would
be
now
if
we're
gonna
be
triggering.
You
know,
collection
mechanisms,
people
do
understand
that
with
log
severity
and
if
it
was
Universal
across
different
data
types.
Maybe
that
would
be
helpful
right,
so
it
would
be
less
work
on
the
end
user,
for
example
like
whether
they
change
the
spam
severity
or
not.
If
a
span
contains
events
that
have
a
high
severity
that
can
raise
the
severity
of
the
span
itself
right.
E
C
C
You
just
have
one
way
of
saying
like
hey
this
event.
Like
this
event,
special
I
don't
know
about
the
span
around
me,
but
I'm,
the
guy,
like
there's
another
question
of
who's
responsible
for
the
overall
spam
status
code,
and
it's
a
lot
easier
as
an
individual
writing
your
code
to
be
like
well,
I
know
this
event
is
super
bad
yeah.
C
C
G
A
G
G
G
You
can
always
you
don't
have
to
make
the
judgment
call
upfront.
You
can
always
handle
and
tale
sampling.
Looking
at
other
attributes
like,
for
example,
if
you're
talking
about
HTTP,
you
can
look
at
the
HD
reset
status,
you
could
look
at
the
the
the
duration
spans.
You
could
look
at
the
number
of
events.
E
Yeah
one
problem
here
is
that
I'm
always
looking
at
the
problem
from
the
perspective
of
out
instrumentation
guy.
So
my
idea
is
always
a
end.
User
should
take
our
out
in
station
agent
attached
to
his
process
and
get
the
meaningful
result,
which
means,
among
other
things,
to
get
meaningful
error
rate
metric
today
without
he
without
him,
without
them
needing
to
configure.
Where
is
my
error
threshold
on
on
the
severity,
so
you.
G
E
E
E
C
I
think
use
this
with
log
severity
or
any
of
these
I
think
that
may
be
another
way
putting.
What
Kevin
is
saying
is
we
do
need
to
make
sure,
there's
a
mechanism
that
we
describe
to
people
for
doing
this
in
the
collector.
The
collector
has
a
pipeline
concept
in
it.
That
includes
a
transformation
step
and
in
that
transformation
step
is
where
you
would
be
I,
presumably
setting
it
just
like
any
other
transformation.
You
set
right
now
like
when
you
see
this
pattern,
set
the
status
code.
C
Yes,
but
I
just
mean
like
just
to
describe
what
Kevin's
doing.
Let's
say
it's
a
boolean
flag
where
it's
on
or
off
you.
You
can
configure
this
in
your
back-end
system
to
like
suppress
errors
or
raise
them.
You
know
different
back-end
systems
of
different
tools
for
doing
that,
but
from
an
open
telemetry.
Like
the
telemetry
pipeline
point
of
view,
you
could
do
it
in
the
collector
as
well.
C
It
was
not
an
either/or,
it's
I
think
we
just
need
to
make
sure
you
know
we
explained
to
people,
you
can
do
it
both
ways,
because
I
do
think.
There's
I
worked
with
enough
people
who
use
the
collector
in
this
manner
already
like
they
they're,
already
leaning,
pretty
heavily
on
transformations,
not
necessarily
for
errors,
but
for
a
lot
of
things.
So
it's
not
an
unnatural
place
for
operators
in
particular
to
want
to,
like
you
know,
as
an
operator,
you
might
want
to
just
be
squashing
something
so
you
just
redeployed
collector.
C
C
That
yeah
well
no
I
got
that
trace
I'm,
saying
like
if
you've
got
a
trace
coming,
it's
like
you
really
should
collect
this
trace
and
you're.
You
want
to
put
a
point
in
your
pipeline,
which
is
like
you
see
a
trace
like
that.
Like
this
one
that
says
collect
me,
I
actually
am
NOT
interested
in
that
span
that
trace
so
like
I,
don't
want
to
trigger
trace
collections,
but.
E
But
but
but
you'd
you
in
general
case,
you
don't
see
the
whole
trace
until
the
back
end.
You
have
distributed
trace,
yeah
and
different
differences.
Different
nodes
in
the
distributed
trace
can
send
that
accidentally
to
different
collectors.
So
you
cannot
drop
traces
on
on
the
collector
unless
you
have
single
node
system
or
you're
using
charting.
E
E
E
F
E
F
C
E
E
G
E
G
F
F
If,
if
that's
not
true,
then
you
probably
want
to
suppress
this,
you
may
want
to
record
it
because
it's
interesting
and
you
know
it's
something
that
you
would
would
like
to
be
aware
of.
But
I
think
this
is
a
slightly
separate
topic,
but
probably
can
be
salt
on
the
back
end
or
by
adding
some
sort
of
like
kind
of
per
component
like
error,
filter
or
error
handler,
where
you
can
have
one
last
chance
to
to
get
a
handle
on
an
error
and
say
you
know
what
ignore
this
one
for
me,
I
have.
E
An
issue
from
I,
like
from
my
vendor
side,
just
yeah,
built
in
a
configuration
to
store
those
exceptions
from
the
filtration.
Doesn't
matter?
Don't
race,
race,
don't
race,
a
metal
flag
or
whatnot?
That's
not
an
error,
so
it's
probably
we
will
well
I,
don't
know
if
we
need
that
in
spec,
but
in
that
in
the
practical
sense
and
like
ends
decay
or
actual
agent
sites,
we
need
some
configuration
not
to
for
users
to
tell
this
is
importantly,
this
is
not.
E
E
F
Would
support
before
replacing
it
with
a
boolean
flag?
I
know
Carlos
brought
up
with
the
Jaeger
exporters.
All
those
that
I've
seen
in
the
various
languages
interpret
anything
other
than
a
status.
Okay
as
error,
so
you
basically
collapse
spandau
status
into
a
boolean
flag
and
the
only
one
that's
true
or
the
only
one
that
would
be
error.
False
is
you
know,
okay
status.
C
C
So
if
we
wanted
to
have
a
concept
of
severity,
maybe
it's
the
something
along
those
lines.
But
again
that
gets
a
little
complicated
unless
you
have
the
whole
trace
assembled
to
decide
what
was
the
the
highest
severity
you
you
found
in
a
span
on
the
trace,
but
you
could
say
like
a
trace
where
all
the
spans
are
debug
or
like
the
the
severity
level
of
the
trace.
Overall
is
a
severity
level,
the
highest
severity
of
of
span
on
a
trace.
That
makes
sense
it's
still
more
complicated
than
just
a
boolean.
Oh
yeah,.
C
Yeah
I
mean
we
would
eventually
potentially
just
like
deprecated
the
boolean
potentially
like.
If
we
decided
eventually
law
of
severity
was
enough
I'm
just
trying
to
think
ahead,
it
would
be
feasible
to
eventually
be
like.
Oh,
we
found
a
more
nuanced
system
now
we
don't
need
this
boolean
anymore,
and
so
you
have
to
set
one
or
the
other,
but
the
boolean
is
deprecated.
You
no
longer
need
to
set
it
if
you're
setting
this
other
thing,
so
that
would
be
a
way
to
start
with
the
boolean.
C
Now
simple,
simple
is
good
enough,
but
we're
just
making
sure
we're
not
like
painting
ourselves
into
a
corner.
It
would
be
reasonable
to
add
something
like
severity
later
and
say:
okay,
we
have
a
more
nuanced
thing.
This
simple
thing
is
deprecated,
so
it
still
works.
You
can
still
set
this,
but
if
you
don't
set
it
and
you
set
the
other
thing,
then
that's
fine,
so
we'd
have
a
path
forward.
C
That
actually
makes
me
really
confident
about
going
with
a
boolean
personally,
because
I
do
think,
there's
value
in
investigating
this
log
severity
and
or
a
severity
level
in
applying
that
I
like
clean
designs,
I
like
it
when
we
reuse
concepts
across
different
components
and
open
telemetry,
because
we
have
so
much
surface
area.
I
still
regret.
We
didn't
call
everything
tags
but
whatever,
but
it
would
be
helpful
to
have
a
more
universal
concept
like
log
severity
that
we
could
apply
to
metrics,
and
even
if
you
want
to
think
about
it,
that
way.
E
C
F
C
C
E
D
C
E
A
Tell
me
I
think
we
need
to
ask
Tigran,
but
initially
I
would
be
I
mean.
So
if
you
ask
me,
I
feel
that
marking
the
tracing
parts
as
stable
was
probably
like
something
we
should
have.
You
know
don't
later
on
and
I.
You
know
we
are
before
1.0
I
wasn't
especially
life
having
a
deprecated
field
before
1.0,
so
I
know
it's
painful
to
break
this,
but
my
boat
would
be
for
removing
it
and
break
it,
but
it's
a
sticker
and
other
people
who.
C
Are
stakeholders?
The
reality
is
that
the
collector
and
a
state
will,
but
maybe
not
with
this
data
protocol,
but
the
collector
is
certainly
much
farther
into
production
than
the
rest
of
open,
telemetry.
I.
Think
that's!
That's
where
the
concern
might
be
just
for
clarity,
so
open
telemetry
is
definitely
not
at
1.0
yet,
but
the
collector
is
actually
pretty
well
adopted
in
production
at
a
lot
of
places.
Okay,
so
that
that
that's,
why
it's
some
nuance!
C
A
C
C
So
it's
obvious
that
it's
deprecated
to
someone
using
the
data
format,
and
then
you
just
don't
have
that
in
the
API
anymore.
You
replace
it
with
this
boolean
and
then
it's
clean
and
that
would
probably
be
at
this
stage.
I
would
guess
maybe
a
better
approach,
then
then
breaking
then
breaking
the
protobuf.
So
if
other
breaking
changes
are
gonna
happen
to
that
protobuf,
we
I
guess
would
like
last
say.
If.
F
C
Gonna
break
it
like
please
remove
the
deprecated
fields
while
you're
at
it,
so
yeah.
Okay,
this
this
feels
good
to
me-
is
there
anyone
that
this
does
not
feel
good
for
we're
hearing
a
lot
of
positivity.
Is
there
anyone
on
the
call
with
reservations
about
going
towards
starting
with
this
boolean
and
then
investigating
severity
is
a
longer
term
concept.
C
D
I
just
have
one
more
question
about
the
breaking
change,
which
is
the
the
status
thing
makes
sense,
but
for
adding
the
new
boolean
how-how'd.
Can
that
happen
in
a
way?
That's
not
breaking,
because
it'll
default
to
false
right,
if
it's
not
required
in
the
proto
and
then
and
we'll
expect
people
to
keep
converting
using
the
status
code
if
they
want
to
extract
a
boolean,
I
guess.
My
question,
then,
is:
how
do
you
distinguish
between
the
old
proto
case
and
the
error
was
actually
false
case.
C
You
you,
presumably
the
old
systems
would
still
be
setting
the
status
code,
and
so
you
would
have
like
a
conversion
step,
maybe
in
the
collector
somewhere
else
right
so
somewhere
down
your
pipeline,
you
would
have
a
more
updated
component
that
would
map
it
or
your
back-end
could
just
be
like
if
status
code
is
still
being
set,
I'm
still
gonna
respect
it
just
the
same
way.
You
would
respect
the
boolean
flag
after
you
move
to
you
know
a
new
status
like
log
severity.
So
it's
more
like
that.
If
one.
C
False
or
true
right,
well,
I
should
say
if
boolean,
if
that's,
if
someone's
using
the
old
system,
then
logs,
then
status
code
is
gonna,
be
something
other
than
okay
right.
So
you
can't
say
if
this
is
something
other
than
okay.
That's
that's
also
set
this
error
boolean
or
this
counts
the
same
as
the
error,
boolean
being
true.
If
people
have
moved
past
their
deprecated
system
and
they're,
updated,
then
spam
status
will
always
be
set.
C
Is
okay
because
that's
the
default
I
believe
or
it
will
be
set
to
null
or
something
like
that,
so
you
will
always
be
able
to
tell
right
unless
you
we
what
we
will
have
to
specify
those
look
like
rules,
yeah
you'd
have
to
say
like
if
any
one
of
these
is
set,
then
it
counts,
as
an
error
might
be
the
the
correct
way
of
interpreting
it.
I
agree:
that's
a
thing
to
note
that
we
have
to
actually
give.
D
D
E
E
D
C
F
Hey
you
could
use
these
some
approvals
for
some
other
non,
like
stuffers
right
now,
Christian
from
Dino
trade
says
approved
at
Birth.
All
the
other
approvers
are
from
from
lifestyle.
The
ones
who
have
approval
who-who
are
approvers
on
the
specification.
There's
a
lot
of
non
approvers
who
have
approved
it.
That
makes
it
yeah.
C
People
who
don't
have
the
official
approval
status,
which
maybe
we
should
be
expanding,
I-
think
we're
behind
the
curve
on
I
always
said:
promoting
people,
because
Jesus,
but
I,
think
we
are
be
behind
the
curve
on
honoring
the
commitments
that
people
have
made
so
far
to
the
project
and
reflecting
that
with
community
membership
and
approval
levels.
So
maybe
we
need
to
do
around
as
maintainer
zuv
reviewing
the
roles
and
seeing
if
there
are
more
people
who
are
contributing
currently,
who
could
be
added
to
these
concepts?
C
A
C
C
C
C
A
E
C
But
we've
been
trying
to
do
is
give
like
approval
status
to
some
subsections
of
the
spec
to
allow
us
to
have
a
actually
a
lot
of
spec
approvers
with
domain-specific
knowledge.
But
not
this
feeling,
like
anything,
can
get
okay,
because
there's
just
so
many
approvers,
it's
just
too
easy
to
get
okay
and
we
now
need
to
have
like
eight
approvals
to
pass
something
so
for
the
spec.
Maybe
again
with
this,
it's
like
just
adding
people
to
the
tracing
portion
of
the
spec.
Essentially
because
that's
what
we're
talking
about
so.