►
From YouTube: 2019-10-01 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).
B
B
C
C
D
D
D
D
D
D
C
E
E
E
F
Yeah
sure,
so
let
me
explain
what
the
problem
is
so
far.
The
specification
says.
The
only
thing
that
it
says
is
that
we
need
to
use
semantic
version
versioning,
which
is
good,
but
that's
not
enough,
and
here
is
what
the
problem
is.
We
we
have
an
API
which
is
which
is
defined
by
the
specification
team,
and
we
have
language
libraries
which
are
worked
on
by
separate
teams.
So
these
things
they
work
separately.
F
They
need
to
be
able
to
have
separate
release,
Cadence's
coupling
the
releases,
it's
going
to
be
counterproductive,
most
likely
the
language
libraries
also
known
as
SDKs,
will
need
to
be
released,
probably
more
frequently
anyway.
This
needs
to
be
on
a
different,
cadence,
different
dates,
which
then
means
that
trying
to
couple
these
things
from
versioning
perspective,
it's
problematic
or
this
coupling
in
a
completely
exact
way,
is
going
to
be
problematic.
F
So
let's
say
we
have
a
spec
version,
zero
point,
one
point:
zero
right
now
and
then
the
SDK
or
language
library
authors
go
ahead
and
implement
corresponding
corresponding
SDK
for
that
right
and
they
use
those,
let's
say
the
same
version
number.
Then
they
need
to
make
an
iteration
of
it.
They
need
to
release
another
another.
It's
a
bug
fix.
Maybe
it's
a
minor
update,
some
more
capabilities
within
that
same
specification,
so
nothing
changes
from
the
specification
perspective,
but
the
the
implementation
provides
more
write
more
in
terms
of
functionality.
That
is
not
covered
in
the
specification.
F
So
what
do
you
use
as
a
version
number
then?
Do
you
require
that
the
specification
also
pumps
the
version
number,
which
seems
pointless
right?
Nothing
changed
in
the
spec,
so
that's
the
problem
and
a
couple
of
things
that
we
discussed
was
one
completely
decouple
the
version
numbers.
So
whatever
the
specification
is,
that's
one
version
number
and
the
implementation
carries
its
own
version
number.
So
basically,
an
SDK
is
labeled
by
two
completely
independent
value
numbers.
One
is
the
novel
version
of
the
API.
F
It
implements
the
other,
it's
its
own
version
and
then
the
language
library
is
completely
free
to
use
whatever
version
numbering.
It
was
demands
to
use
now
the
problem
with
this.
It
may
cause
confusion
right
you
it's
it's
not
really
that
obvious
that
you're
using
this
kind
of
versioning
and
it
may
get
people
confused.
The
other
proposal
was
to
basically
require
that
SDKs
use
the
same
major
and
minor
version
numbers
as
the
specification
that
they
implement
and
then
the
SDK
is
free
to
iterate
or
increment
the
patch
number,
the
third
number
in
the
version
string.
F
That
is
probably
possible
to
do.
But
that
puts
a
limitation
on
how
big
of
the
changes
you
can
make
in
the
SDK
releases
or-
or
you
just
have
to
ignore-
that
patch
number
basically
says
nothing
should
change
in
the
behavior.
It's
only
bad
fixes
and
then
you
increment
wash
number
also
for
behavioral
change
releases.
So
those
are
basically
two
proposals
in
summary
that
we
have
seen
so
far.
F
H
F
Yeah
that
was
discussed
as
well.
The
problem
with
that
is,
let's
say
we
have
0.1
spec.
We
implement
SDK
0.1
we're
good
here
now,
SDK
decides
to
implement
something
significantly
more
than
0.2,
then
0
and
3
all
for
the
same
spec
and
then
spec
does
0.2
release.
Now
we're
all
in
a
confusion.
There
is
0.2
spec,
but
that
is
not
implemented
by.
B
B
F
H
H
F
H
I
H
H
The
other
thing
that
I
saw
at
the
GRP,
C
and
I
liked
it
was
the
fact
that
they
have
releases
coordinated
releases
across
languages
and
I
am
curious.
If
we
want
to
do
this.
So,
let's
say
after
one
zero
before
one
zero,
it's
not
necessary,
but
after
one
zero
do
we
want
every
library
to
do
a
release.
Let's
say
every
six
weeks:
the
minor
release
part
released
may
happen
because
you
have
a
file
can
be
dependent,
but
minor
release
is
to
do
coordinate,
E
minor
releases,
or
do
we
want
to
have
completely
separate
version.
F
I'm
I
would
think
that
it
could
be
problematic
for
or
for
an
organization
has
died
versus
open,
Ptolemy's
trees.
There
are
so
many
people
involved,
so
many
companies
involved
so
coordinating
that
may
be
more
difficult.
We
can
think
about
it,
I'm
not
sure
about
it.
It
may
seem
that
for
GRP
see
it
could
be
done
primarily
driven
by
one
company
for
open.
Telemetry
may
be
more
difficult,
but
I
understand
that
the
benefits
of
doing
that,
but
it
may
be
difficult
to
implement
and.
H
Work
or
other
thing
that
we
can
do
is
guarantee
that
every
six
weeks
we
have
at
least
one
release.
We
got
updates
dependencies
and
and
stays
up-to-date.
So,
even
though
we
are
not
adding
too
much
code
into
one
library,
at
least
for
updating,
dependencies
and
stuff,
like
that,
we
guarantee
that
we
do
a
release
every
six
weeks
in
all
the
languages
yeah.
E
H
H
F
E
That
Chris
I
think
Chris.
You
pointed
it
out
to
me
earlier
and
just
as
a
there's
like
a
mental
game,
we're
gonna
sort
out
some
scheme
here.
Right.
Php
is
gonna,
start
up
in
a
couple
of
weeks,
they've
written
no
code
so
far,
so
would
it
think
about
like
whatever
scheme
we
come
up
with?
What
does
it
mean
they
have
to
do
with
their
very
first
release
the.
E
H
Matter,
I
think
I
think
the
most
important
for
me
is
after
one
zero,
so
so
before
before
one
zero,
we
can
start
with
any
number.
So
I
think
we
have
immediate
problem.
Do
we
need
to
rename
zero
point?
Three
point
four
into
some
like
point,
seven
and
point
nine,
so
people
have
like
numbers
in
between
or
we,
which
is.
We
have
I
think.
F
H
H
D
J
E
I
wonder
if
there's
like
a
need
to
go
back
to
the
top
and
be
like
what
it?
What
is
the
point
of
these
versions
like
from
a
practical
matter?
There's,
obviously
a
human
might
want
to
know,
read
the
spec
that
relates
to
the
API,
and
you
want
to
install
an
SDK
package
that
works
with
an
API
package
that
you
have
right,
but
like?
Is
there
really
going
to
be
that
much
confusion?
E
H
E
H
That's
the
only
reason,
that's
the
only
reason
and
I
think
it
adds.
As
Tigran
pointed
it
adds
a
lot
of
more
problems.
If
we
do
this,
especially
because
if
we
follow
the
semantic
version
convention,
we
are
not
allowed
to
have
intermediate
releases
between
two
two
different
points.
So
that's
a
problem
for
for
4d.
So
so.
F
I
guess
it
seems
that
a
technically
more
correct
solution
is
to
use
separate
decoupled
version
numbers.
The
concern
was
that
it
may
be
unconventional
for
people.
They
may
not
expect
that
to
be
the
case.
They
may
assume
that
the
version
numbers
would
be
the
same
and
may
make
a
mistake.
That
was
the
concern.
If
this
doesn't
sound
like
a
problem,
if
people
think
that
it's
not
a
surprising
behavior.
H
For
example,
if
there
is
in
the
specs,
let's
say
in
the
spec
0
3
we
have,
a
notion
of
you
are
allowed
to
do
through.
Do
I
expect
Java
0,
3,
I'm,
reading
the
specs
and
I'm
seeing
oh.
This
is
a
feature
that
I
want.
If
I'm
going
and
use
Java
do,
I
am
I'm
using
zero
point.
Four
I
would
probably
expect
that
to
be.
K
H
I
think
that's
why
I
said
that
we
should
have
a
next
coordination.
Point
of
version
should
be
1
0
when
probably
specs
will
become
way
more
stable
and
will
not
have
that
morph
that
frequent
releases
or
or
milestone
for
specs.
So
we
can
assume
like.
Let's,
let's
say,
while
we
are
on
version
0
library
should
start
from
0.1
and
follow
the
semantics
of
version
with
nice.
If
you
add
a
new
EP
I
will
change
functionality,
you
go
4-0
to.
If
you
just
fix
a
bug,
you
go
with
0.11
it's
stuff
like
that.
H
H
So
don't
use
1.0
everything
before
1.0.
You
can
do
whatever
you
want
use
alpha
in
the
numbers.
If
you
want
like
python,
recommends
or
not,
but
I
think
I
think
to
be
honest.
Everything
else
off
with
zero.
I
know
I
have
this
battle
battle
internally,
with
no
consensus,
because
everyone
is
telling
me
that
the
purchase
starts
with
zero.
So
it's
not
ready
and
I'm
like
no.
H
We
made
a
be
a
bit
of
a
different
promise
that
we're
not
going
to
break
things
even
which
we
start
with
zero,
but
I
think
following
semantic
convention,
everything
that's
not
with
zero
can
be
break.
So
so,
let's,
let's
just
stay
with
pure
semantic
versioning,
which
says
we
do
zero
major
releases.
So
we
are
allowed
to
break
compatibility,
break
everything.
We
want
until
one
point
zero
and
just
ensure
that
one
put
nobody.
Nobody
releases
one
point
zero.
H
Unless
the
before
the
specs
gets
to
one
point:
zero
one
requirement
and
second
all
the
function,
T
defined
in
one
point:
zero
in
the
spec
should
be
implemented.
So
one
point:
zero
is
the
version
where
we
want
to
control
every
library
that
matches
all
the
requirements
in
the
specs
before
that.
Just
just
develop
like
let's
not,
let's
not
be
too
picky
and
not
block
people
for
for
developing
and.
E
B
H
I
mean
if,
like
an
unlined,
we
shall
need
to
understand
how
to
deal
with
this
breaking
change,
correct
but
but
I
think
before
1.0
we
allow
language
to
do
whatever
they
want.
When
we
hit
1.0,
we
do
not.
We
don't
want
to
let
people
implement
features
without
being
specified
so
currently
currently,
because
it's
a
race
between
defining
expects
and
developing-
we
are
fine
with
this,
but
after
1.0
I
would
be
I
would
be
very
negative
on
allowing
people
to
say,
go
and
implement
this
feature.
L
I,
don't
think
this
is
really
possible
because,
for
example,
we
have
a
new
issue
that
wants
to
specify
to
add
multiple
spent
attributes
at
once
and
I
think
this
is
such
a
detail.
Nobody
would
have
doubts,
they're
doing
something
forbidden
when
implementing
that's
just
in
their
language.
So
I
think
this
issue
can
ever
can
always
come
up.
Yeah.
H
But
this
is
a
minor
one,
comparing
with
let's
assume
we
we
decide
to
add
logging
and
there
is
gonna,
be
a
language
that
completely
defines
the
way
they
want.
This
API
completely
independent,
so
I
think
I
think
this
is
a
very
small
issues
like
if
you
have
a
function
or
a
method
that
accepts
multiple
attributes.
That's
a
very
small
thing.
L
A
Could
you
could
you
imagine
this
scenario
where
we,
after
we've
released
1.0
and
one
of
the
languages,
decides
to
make
a
major
API
change
without
adjusting
a
spec
version
and
they
request
that
we
bump
the
major
version
of
the
spec
just
to
give
them
room
so
that
they
can
make
a
new
major
change?
So
nobody
else
wants
version
2.0,
but
one
language
wants
to
completely
redesign.
They
request
that
the
spec
bump
subversion
would
no
change.
That
seems
like
it
would
satisfy
the
requirements.
A
H
If,
if
that
happens,
only
one
language
I
mean
we
think
that
if
it
is
possible
to
just
ship
a
different
package
mean
for
that.
Unless,
unless
is
critical
thing
and
multiple
language
want
to
do
this,
because
we
made
a
big
mistake,
then
yes,
then
we
should
go
with
to
zero,
but
for
just
for
one
language,
I
may
think
of
that
option.
H
F
Let
me
try
to
summarize
the
proposal
is
that
the
API
version
number
and
SDK
version
number
that
implemented
are
weakly
coupled
and
the
coupling
is
that
the
major
numbers
should
match
other
than
that.
There
is
no
special
requirement
for
the
minor
in
touch
version
numbers
and
the
SDKs
must
publish
as
cable
or
whatever
they
want
to
publish,
which
clearly
specifies
that
which
version
number
of
the
SDK
implements
the
the
corresponding
API
version.
Correct.
H
F
Yeah
and
in
which
version
of
your
SDK
release-
yes,
okay,
so
I
guess
I
can
put
up
that
as
a
proposal
and
unless
there
are
disagreements,
I
can
make
a
pull
request
against
the
specification
and
other
to
the
language
library
guidelines.
Thank
you.
Then.
We
can
have
a
final
discussion.
There
think
there.
F
Yeah
yeah
that
Moses
was
a
small
correction
in
the
language
in
the
wording
of
the
language.
There
was
a
confusion
around
whether
the
vendors
are
supposed
vendor.
Exporters
are
supposed
to
go
into
the
SDKs,
which
we
never
intended.
I
think
I,
don't
think
we
ever
intended
that
to
be
the
case,
but
the
wording
was
poorly
done
so
I
removed.
That
seems
like
there
is
an
additional
clarification
needed
I.
Cannot
that
if
there
is
a
need
for
that,
I
don't
know,
but
basically
like.
Let's
try
to
sync
on
that.
F
C
Feels
like
that
introduced
there's
a
lot
of
really
tight
coupling
for
the
open
source
vendor
all
right,
then
they're
tied
to
our
time
frames
right,
like
I,
think
it
makes
better
sense
to
just
keep
them
in
separate
repos
like
I.
Do
see
that
I.
Think
Jaeger
has
something
in
the
open
to
I'm
free,
go
repo,
but
I
personally
like
to
see
it
in
a
separate
repo
that
way
they
can
control
it
and
they
don't
have
to
turn
to
us
for
reviews.
Yeah.
A
H
A
I
can
afford
you.
The
issue
is
because
github
has
a
sort
of
because
of
a
convention
of
using
github
tag
as
semver
that
you
couldn't
I
mean
honestly
I
think
this
was
a
user
who
was
saying:
hey,
look,
I,
don't
want
half
this
API,
please
give
me
the
only
half
of
it
and
so
that
you
know
we
could
also
respond
by
saying
sorry,
but.
E
It
wasn't
good
what
that
person
is
asking
for
is
just
a
little
bit
separate
from
what
we're
talking
about
right
now,
but
I'm
happy
to
jump
back
in
on
that
thread.
I,
don't
think
you
can
separate
metrics
from
tracing,
because
they're
gonna
share
some
underlying
interfaces,
and
that
might
be
difficult.
My.
A
E
Nevermind
they
get
back
on
this
issue
of
like
exporters
and
third-party
dependencies
there's
generally
two
there's
one
is
like
the
dependency
chain
that
u-haul
in
and
trying
to
resolve
that
pendency
chain
and
then
the
other
which
Liz
mentioned
was
like
the
cadence
of
release
and
there's
like
a
matrix
of
compatibility,
which
version
of
the
SDK
with
which
version
of
some
exporter.
You
want
to
look,
and
you
could
look
at
cuba,
Nettie's
and
storage
drivers.
H
H
You'd
have
to
update
that
code
frequently
and
all
the
things
like
update
their
dependencies
and
everything
and
in
the
I
would
prefer
for
people
that
are
maintained,
errs
and
and
approvers
for,
for
the
see
for
a
specific
language,
to
not
focus
on
that
to
just
focus
on
their
work
and
vendors
should
do
that,
work
for
them.
Imagine.
E
H
H
F
H
F
H
Be
there
we
should
probably
have
a
standard
out
or
print
whatever
we
call
it
as
long.
You
think
that
at
least
shows
people
hey
in
your
test.
Look.
This
is
how
data
works.
Yeah
will
work
for
you,
that's
probably
good,
but
now
talking
about
other
specific
vendor
I,
think
I
I
don't
care.
For
example,
here
we
have
Prometheus,
Jager
and
and
unzip
King.
The
three
that
we
said
we
promised
were
to
offer
just
for
people
to
have
an
option
to
play
with
with
the
library
and
with
the
ecosystem.
H
I
I
personally,
don't
care
if
we
put
them
in
the
same
rack
or
not,
but
I
think
it's
good
for
us
to
have
at
least
one
open
source
for
tracing
and
one
for
matrix
just
for
having
examples
to
show
people
hey.
This
is
how,
if
you
instrument
is,
you
will
see
this
metric
and
at
least
this
way
we'll
have
a
way
to
show
them
a
graph
with
some
metrics
or
a
span
or
a
trace,
or
something
like
that.
Yeah.
E
G
E
Do
we
need
something
like
open,
telemetry
contribs
can
put
all
of
these
exporters
and
other
things,
because
I
can
see
us
writing
them
now,
just
to
seed.
You
know
seed
the
community,
but
in
the
longer
run
you
could
see
the
Zipkin
people
wanting
to
manage
their
exporters
and
the
Jaeger
people
when
it
commanders
their
exporters-
and
you
know
we're
just
sort
of
seeding
that
work
now
just
to
get
the
whole
thing
off
the
ground.
I
just.
C
E
E
H
H
Biggest
problem
is
separate
work.
The
same
work
is
who
will
manage
the
integrations
like
CI
CG
and
my
closet
I
think
it's
like
we.
You
want
to
give
permissions
to
all
the
people
who
manage
that
button.
There
is
no
clear
separation.
You
cannot
give
really
tight
permissions
for
webhooks
integration
whatever,
so
it
may
be
challenging
from
just
our
hat
on
managing
this
request.
D
D
D
E
Think
it
sounds
like
the
we
probably
can't
solve
it
on
this
call
and
there's
there's
I,
think
other
items
on
the
agenda,
but
it
sounds
like
there's
this
higher
level
question
of
we're
mostly
working
on
this
core
stuff,
SDKs
collector
API,
but
then,
of
course,
there's
now
going
to
be
like
an
ecosystem
that
gets
built
on
top
of
this
platform.
Some
of
that
we're
at
least
going
to
write
ourselves
right
now
and
are
going
to
maintain
for
the
coming
future,
and
we
just
need
to
think
about
where
we
want
to
put
all
of
that
code.
E
Do
we
want
that
all
in
the
same
org?
Is
that
totally
fine?
It
might
be
fine,
or
do
you
want
to
think
about
having
some
organizational
separation
between
you
know,
governance
and
access,
and
all
these
things
to
these
like
core,
open
telemetry
packages
versus
things
like
exporters,
where
we
may
be
handing
off.
You
know
management,
you
know
to
other
people
or
something
like
that.
E
In
the
longer
run,
though,
I
would
like
to
have
something
more
like
a
registry
on
the
website
where
people
can
go
find
this
stuff
and
it
actually
doesn't
matter
where
the
code
lives,
but
it's
more
just
a
question
of
like
if
we're
gonna
maintain
some
of
this
stuff
in
the
meantime,
just
literally,
where
do
we
want
to
put
it?
Maybe
we
can
just
look
in
the
same
word:
I
kind
of
withdraw
a
country
by
idea,
I
just
put
forth
this.
D
H
That's
that's
something
that
we
can
definitely
for
as
an
alternative
like
we
can
put
every
vendor,
we
can
put
a
lien
because
doesn't
cost
us
to
maintain
anything
to
do
that.
The
problem
is
if
it
comes
to
a
cost
of
maintaining
vendors
code
and-
and
we
can
see,
for
example,
Zeki
has
this
problem.
They
accepted
all
the
possible
all
the
possible
exporters
or
whatever
they
a
lot
of
code
from
from
different
things
that
the
there
is
a
manageable
right
for
that
block.
But.
E
I
think
it's
as
long
as
the
we're
not
baking
in
any
third
party
exporters
directly
into
the
SDK
like
we're
gonna
move
all
those
out,
except
for
the
open,
telemetry
ones,
and
then
on
the
website.
We
have
some
kind
of
registry
or
other
way
to
find
stuff
where
you're
kind
of
on
equal
footing
there,
whether
you're
hosting
you
know
the
package
in
your
own
or
door,
we're
hosting
it.
You
know
it
doesn't
really
matter,
then
it
feels
to
me
like
everything's,
on
sort
of
equal
footing
and-
and
that's
like
really
the
point.
Yes.
F
E
And
there's
may
be
this
bridge
step
right
where
you
know
these
SDKs
have
to
work
right
now
and
maybe
an
SDK
literally
only
has
a
Jager
exporter
and
they
or
Zipkin
exporter,
and
they
don't
have
an
open,
telemetry
one
I
suppose
there's
just
this
process
of
as
soon
as
you
make
the
open
telemetry
one.
Please
move
the
other
one
out
at
that
point.
Right.
E
Think
that
was
like
an
original
goal
of
this
project
and
maybe
open
census
right.
The
idea
that
you
shouldn't
actually
have
to
install
much
other
than
you
should
be
able
to
take
our
default
SDK
with
its
default
setting
and
just
be
happy
with
that
there
and
actually
maybe
move
more
of
this
configuration
out
to
the
collector.
This.
E
I
Yeah
I'll
take
that
one,
it's
more
of
a
question
actually
in
2/4,
so
first
one
is
I'm
not
sure
about
the
progress
we
made
on
the
issue
itself.
So
there's
a
lot
of
discussion,
but
I'm,
not
sure
reaching
consensus
here.
So
if
to
throw
where
to
throw,
are
there
exceptions
vertical
axis
or
exception?
Is
an
implementer,
so
I
think
this
is
rather
important
topic
we
should.
We
should
all
agree
on
and
second
one
which
is
more
specific
was
about.
There
was
one
command
about
having
some
logging
or
on
a
callback
error,
callback
mechanism.
I
If
we
we
think
that's
useful,
you
wanna
have
that.
That's
maybe
right
now,
it's
beyond
the
scope
of
the
original
issue,
so
I
just
wanna
know
what
your
opinion
here.
If
you
should
go,
and
if
you
think
that
having
an
additional
callback
mechanism
for
errors,
if
that's
a
good
idea
and
if
we
you,
maybe
want
to
have
an
extra
RFC
for
that
so
or
if
you
should
address
it
in
this
this
issue
still
so,
what's
your
thoughts
on
that?
Well,.
J
I
J
I
I
J
Yeah
I
would
like
to
do
that
too.
I
I,
think
you
know,
as
as
I'm
thinking
about
the
the
error.
Callback
like
I
wouldn't
expect
this
to
do
a
lot
of
work
and
I,
especially
wouldn't
expect
it
to
do
synchronous.
Work
like
this
would
be
something
like
me,
a
like
another
metric
right.
That
tells
you
the
the
count
of
times
the
instrumentation
has
failed,
and
maybe
you
know
what
place
in
the
code
that
it
failed.
E
E
I
I
guess
one
of
the
intentions
was
also
in
case
of
an
error
case.
Something
goes
wrong,
that
you
don't
want
to
throw
an
exception
and
bring
the
application
down,
but
rather
just
provide
some
error
callback
to
the
user
of
the
SDK
or
that
API
in
that
case,
so
they
can
log
it
to
their
own
logging
system
or
whatever.
So
it's
just
the
diagnosis
mechanism
and
you
wanna
want
your
application
to
be
as
stable
as
possible.
Even
though
open
telemetry
SDK
has
an.
E
Yep
exactly
and
if
you
imply
that
a
method
signature
can
throw
an
exception
or
can
return
an
error.
Then
of
course
the
responsible
end
user
has
to
wrap
all
that
code
up
and
a
bunch
of
stuff,
but
that
caller
doesn't
have
really
like
what
are
they
gonna?
Do
you
know
so
it?
In
that
sense?
It's
it
just
complicates
their
code,
but
it
doesn't
actually
it's
not
actually
helpful
to
them.
So.
F
E
H
Supposed
to
get
that's
that's
also,
very
bad.
Imagine,
for
example,
you
you
have
some
metrics
or
traces
wherever
and
you
have
alerts
set
on
these
and,
let's
assume
you
want
to
count
the
number
of
errors
that
you
have
in
your
application
and
that
metric
does
not
work.
You
better
want
to
crash
your
application,
because
you
know
it's
going
to
be
zero
monitoring,
so
you
don't
know
what's
happening
there,
I
sure,
wouldn't
what
it's
not
I.
H
Saying
that
application
developer
might
decide
to
do
that,
and
this
DK
may
provide
this
ability
and
for
callbacks
is
what
she
grant
question.
There
is
a
language
saying,
as
he
came,
I
choose
to
expose
callbacks
telling
about
the
errors.
So
if
you
want
to
know
about
errors,
you
you
may
how
much
like
way
to
do
that.
But
it's
cause
the
language.
B
I
E
Was
gonna
say
Bogdan
like
if
you
want
it,
I
sure,
there's
a
million
people
on
this
call
who'd
be
like
your
observability
system.
Shouldn't
crash
your
program,
but
if
you
wanted
to
throw
an
exception,
if
you're
like
this
is
so
important,
if
I
can't
report
this
thing,
then
I
just
need
to
tear
this
process
down.
You
could
handle
that
in
an
asynchronous
callback
right.
You
can
get
have
it
that
asynchronous
callback
receive
the
message
that
you
know
the
observability
system
is
no
longer
reporting
and
then
choose
there
to
throw
and
knock
the
system
down.
H
I
think
here,
I'm
talking
more
about,
for
example,
for
matrix.
The
only
exceptions
that
may
occur
is
when
you,
when
you
create
the
metric.
The
starting
of
the
third
thing
and
usually
I,
would
definitely
happen
because,
for
example,
for
whatever
reasons,
I
mix,
configured
and
I
have
to
to
code
places
where
they
I
define
the
same
metric
but
differently,
uh-huh
and
then
I'll
have
a
mess
in
my
observability
I
would
most
likely
want
to
crash
at
the
start
line,
which.
H
Time
if
you
miss
configured
it
completely
as
the
key
must
fail
fast,
but
there
is
no
like
middle
ground.
Sorry
like
fail
fast,
isn't
fine
on
a
startup
of
application
if
it's
misconfigured,
but
then,
if
you
already
started,
then
in
run
time
you
shouldn't.
So
if
you're
a
collector
of
metric
start
returning
exceptions
on
callbacks,
you
cannot
crash.
Oh
yes,
that's
true,
but
I
would
cry.
I
would
just
log
that
for
sure
I
would
I
would
log
that
information
and
people
may
look
for
their
logs
and
stuff,
but.
J
H
A
Like
so
actually
like
the
metrics
question
right,
there
is
I
think
pretty
important
and
we
shouldn't
just
sort
of
like
labor
hands.
I
actually
don't
want
to
crash
in
that
scenario
personally,
but
there
was
a
point
that
we
discussed
crashing
explicitly
in
this
case,
where
you
have
an
argument
list,
that's
ordered
and
has
a
fixed
length
so
Bojan.
A
This
was
your
but
I
believe
desire
to
this
sort
of
very
optimized
mode
of
supplying
label
sets
where
you
give
the
labels
in
exactly
the
order
that
they're
declared
on
the
handle,
and
then
you
want
to
actually
panic
or
thrown
exception.
When
the
argument
lists
didn't
match
the
correct
length
and
I
accepted
that
one,
but
I
actually
don't
think
we
should
be
panicking.
If
you
give
two
definitions
of
a
metric
guys.
E
E
K
I
I
think
there's
no
right
or
wrong
answer
on
this
topic,
so
there
are
just
two
very
opposite
opinions
which
is
French
obvious
or
fresh,
never
and
I.
Guess
we
should
make
that
somehow
configurable
like
having
an
a
notion
of
error,
handling
in
the
API
and
one
implementation
or
one
flavor
of
error
handling
we
just
throw
and
the
other
is
provide
some
implement
your
own
arrogant
thing
mechanism.
So
we
I
think
we
need
to
address
that
these
two
opinions,
let
me
Pierre
leval,
otherwise,
we'll
never!
That
is
fire.
Oh
I,.
A
So,
if
you've
just
done
something
wrong
at
the
user
level,
I
just
want
to
create
a
diagnostic
event,
and
it's
in
order
to
do
that
from
the
inside
of
the
callback
I,
don't
know
how
to
use
the
API
safely
when
you've
called
me
back,
but
I
would
like
to
have
an
open,
telemetry
diagnostic
event
enter
the
stream
of
open,
open,
telemetry
Diagnostics,
and
that's
why
for
me
to
do
it's
the
special
case
right
now:
you're
handling
an
error.
Okay,.
E
E
H
So
we
declare
this
milestones
and
current
milestones
and
Friday,
and
we
have
more
than
one
page
of
issues
on
this
milestone.
So
I
ask
people
to
start
looking
into
these
issues
and
if
you
have
something
assign
it
to
yourself
and
try
to
address
as
soon
as
possible,
if
you
believe
that
issue
doesn't
belong
to
this
milestone,
we
can
safely
like
you,
can
discuss
moving
it
back
back
to
0.3.
H
That
is
like
four
weeks
away
like
five
weeks
away,
so
that
may
be
another
currency,
but
I
would
really
like
us
to
get
on
track
and
like
how
we
handle
issues
and
how,
with
closing
milestones
so
yeah,
there
are
two
links,
one
for
issues
that
need
assignment
another
forty
are
required.
The
issues
are
not
assigned
to
milestones.
So
if
you
can
start
looking
into,
that
will
be
great.
H
E
E
E
A
Want
to
advertise
that
the
metrics
spec
PR
is
number
250
is
outstanding
still
and
has
getting
a
trickle
of
comments.
Sergey
and
Bogdan
are
the
most
recent
ones.
I
feel
that
it's
pretty
important
to
get
something
finished
and
I
responded
as
best
I
could
I
think
we
could
merge
it
and
just
just
decide
to
iterate
post
alpha.
H
A
This
way,
that's
sort
of
us
and
like
a
semantic
spectrum,
the
language
in
the
spec,
not
really
what
the
API
is
gonna
do.
So
it
seems
like
rewording
that
wouldn't
even
change
an
SDK
yeah,
but
that's
the
only
I,
for
my
part,
I
think
need
to
have
a
show.
I
mean
I
want
to
see
a
actual
SDK
before
we
get
to
like
shaking
out
the
remaining
sort
of
questions.
E
I
Hopefully,
less
chatter,
so
yeah
thanks
for
the
feedback,
I
think
it
turned
out
quite
well
the
whole
tip
and
it
has
been
merged.
So
it's
just
about
adjusting
the
respect
now
and
I
think
you
already
inherently
already
have
to
Cooper.
So
so
so
maybe
take
a
look
at
it
and
and
yep.
Hopefully,
so
we
can
get
approached
yeah.