►
From YouTube: 2022-04-28 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
Yeah,
it's
like
traveling
on
the
west
coast
is
not
too
bad.
I'm
always
used
to
like
going
across
the
country
because
my
family's
in
on
the
east
coast,
so
that
that's
pretty
horrible
but.
A
Oh,
I
see
okay,
there's
an
issue
also
two
six
four
six
man:
what
okay
cool?
I
guess
we
could
just
get
started
yeah!
Oh
my
god.
It's
ted!
What's
up
ted.
C
Hey,
hey
yeah,
I
have
an
agenda
item
but
don't
don't
let
me
slow
your
roll.
A
Yeah,
that's
fine.
Is
it
okay,
yeah.
C
It's
a
just,
maybe
real,
quick
and
then
I
can
get
out
of
your
hair.
So
I'm
helping
a
number
of
the
like
instrumentation
sigs.
C
What
instrumentation
sigs
are
trying
to
do
is
basically
update
our
semantic
conventions
after
kind
of
reviewing
them
with
subject
matter,
experts
and
stuff
like
that,
and
then
trying
to
get
them
declared
stable
and
as
part
of
that
process,
we
kind
of
want
to
like
do
an
audit
of
all
existing
instrumentation
of
that
particular
class
and
and
get
it
kind
of
like
up
to
date.
C
The
one
we're
starting
with
is
http
simple
enough,
so
I'm
just
kind
of
going
around
to
the
sigs
and
kind
of
just
checking
in
about
contrib
packages
like
who,
how
how's
it
going
with
them
in
this
language.
Are
there
maintainers
for
them
and
also,
if
you
wouldn't
someone
from
the
sig
wouldn't
mind,
giving
me
a
list
of
all
the
packages
we
currently
have
that
have
http
instrumentation
in
them?
I'm
just
trying
to
like
basically
make
a
spreadsheet
of
all
the
things
we
need
to
update.
C
So
so
those
are
my
requests,
but
we
don't
have
to
like
halt
the
meeting
to
go
through
that.
I
could
follow
up
with
you
guys
later.
A
Yeah,
I
can,
I
can
compile
a
list
for
you
of
the
http
instrumentations.
A
So
right
now,
like
all
of
our
instrumentations,
are
in
some
sort
of
beta
version,
they're
all
being
released
in
lockstep,
so
they
all
have
the
same
versions
yeah
as
usual:
no
no
stable
promises!
Yet
in
terms
of
maintenance.
We
are
having
like
a
like
a
folder
level
kind
of
component
owners,
kind
of
structure
right,
I
believe,
similar
to
other
repositories
as
well
as
for
the
http
libraries.
A
I
I
only,
I
don't
believe
any
of
the
big
ones
have
specific
component
owners,
but
I'm
sure
that
most
of
the
well
at
least
me
personally
would
be
a
maintainer
for,
like
the
large,
largely
used
http
libraries,
just
a
few
of
them
like
specific
ones
like
httpx
that
aren't
popularly
used
have
specific
maintainers
for
them
because
of
the
the
people
that
contributed
were
willing
to
offer
their
time
but
other
than
that
for,
like
the
large
ones.
A
I
believe,
like
the
whoever
is
a
maintainer,
would
would
definitely
be
willing
to
step
up
for
maintenance
and
support
for
that.
So
awesome.
C
These
are
the
things
we
changed
and
want
to
add,
and
then
maybe
post
like
a
like
a
help,
help
wanted
issue
that
we'll
try
to
to
then
serve
up
ourselves.
If
we
can,
the
other
people
want
to
do
it.
It's
great
for
someone
who
knows
python
they're,
probably
pretty
trivial
changes,
but
I
just
wanted
to
make
sure
that
there's
there
are
people
who
are
monitoring
the
the
pr
backlog
for
for
those
repos,
and
it
wouldn't
be
like
burdensome
to
be
making
prs
to
do
that
stuff.
A
Yeah,
I
have
a
question:
is
there
so?
I
know
there's
like
instrumentation
sig.
Is
there
like
a
maybe
like
an
issue
or
anything
that
we
can
follow
in
terms
of
this
compiled
list
of
things
that
are
necessary
to
make
things
stable.
C
Yeah,
so
let
me
see
so:
there's
there's
a
http
and
a
messaging
working
group
right
now.
They
each
have
a
project
board.
I
could
provide
a
link
to.
I
don't
know
if
that's
totally
helpful,
but
the
rest.
The
project
board
at
least
shows
that
the
issues
that
are
getting
prs
that
are
getting
made
against
the
spec.
C
C
One
of
the
things
changes
we
want
to
get
in
there
is
ensuring
that
instrumentation
is
pre
emitting
a
schema
version
as
as
part
of
what
it's
submitting,
because
we
have
this
schema
system
now
in
the
in
the
spec,
where
like
instrumentation,
should
be
able
to
identify
which
version
of
the
spec
get
implemented
and
having
that
information
at
least
allows
collector
processors
and
back-ends
to
like
do
some
kind
of
conversion
if
they
need
to
do
like,
like
conversions
to
prevent
dashboards
from
breaking.
C
But
since
like
none
of
the
instrumentation,
we
have
today
really
emits
that
information
and
they're,
not
they're,
all
targeting
some
nebulous
spec
version.
Our
first
step
is
to
at
least
even
if
things
aren't
stable
to
to
get
it
to
that
point.
So
at
least
it's
a
known,
a
known
implementation,
we're
also
interested
in
in
trying
to
build
some
test
harness
helpers
for
this
stuff,
something
that
keeps
coming
up
is
like.
C
It
would
be
great
to
have
like
a
collector
processor
that
that
could
you
could
just
tell
it,
I'm
sending
you
http
span
server
spans
that
are
supposed
to
be
compliant
with
1.11
of
the
spec,
and
it
could,
you
know
just
like
run
some
tests
and
spit
out
some
json
or
something
that
says
like.
Yes,
that's
what
you
gave
me
or
like
no,
you
gave
me
some
weird
something
some,
basically
something
that
would
make
like
the
testing
infrastructure
for
these
things,
a
little
more
straightforward
and
less
reliant
on
the
the
person.
C
Yet
so
probably
what
we'll
end
up
with
is
just
like
a
spreadsheet,
like
a
google
spreadsheet,
where
I'm
trying
to
like
just
list
all
of
these
things
and
try
to
figure
out
what
version
they're
in
and
then
like
for
each
one
of
these
things
we'll
just
be
making
like
a
google
doc
with
just
like
a
checklist
for
like
this
one,
this
one
particular
versioning
that
we're
doing
doing,
but
we
are
interested,
I
think,
in
the
long
term,
of
building
up
some
infrastructure
that
would
help
with
this
maybe
connect
it
up
to
the
registry.
C
You
know
so,
like
the
registry
stays
up
to
date,
explaining
what
version
of
what
you
know
each
library
is
producing
or
something
like
that,
but
that's
all
perfect
being
the
enemy
of
the
good
good
enough
right.
Now,
we
just
want
to
like
try
to
lift
all
of
our
instrumentation
up
onto
some
known
known
version
of
what
it's
submitting
so
that
we
can
start
building
schema,
schema
translators
and
things
like
that
in
the
collector.
C
As
we
start
producing
those
docs
I'll
create
a
like
a
help
wanted
issue
in
the
python
repo
once
we're
ready
to
go
and
I'll
try
to
just
include
a
link
to
to
all
of
those
relevant
things.
Once
they're
made
awesome
thanks
ted
for
the
info
comments.
Okay,
I'm
going
to
duck
out.
Thank
you
very
much.
All.
A
All
right
cool
yeah,
now
diego's
back
yeah.
E
E
A
No
worries
yeah
yeah,
so
yeah
we
don't
really
have
any
other
topics.
Dio.
Do
you
wanna
share
and
like
go
over
the
metrics
board,
yeah
sure.
E
Here
and
okay,
there
is
one
issue
I
would
like
to
discuss,
but
let's
take
a
look
at
the
board.
First,
all
right,
so
in
general,
great
progress
people
we,
I
think
we
moved
six
issues
into
done
this
week.
E
Thank
you
all
for
all
your
reviews
should
have
been
pestering
you
with
review
requests,
but-
and
I
know
that
you're
all
very
busy,
but
we
really
appreciate
the
time
that
you're
spending
reading
everything,
okay,
so
so
far
in
progress.
We
have
a
couple
of
issues
that
I
would
like
to
discuss.
First,
one
is
this:
one
is.
E
How
to
deal
with
conflicts
because
my
views,
I
think
I
literally
left
a
comment
here.
E
So
let
me
just
take
a
look
at
the
code.
There
is
a
part
of
the
spec
that
has
this
example.
E
Where
and
the
explicit
rocket
histogram
aggregation
should
not
be
used
within
asynchronous
instruments,
it
is
mentioned
as
an
example
there,
but
I
think
it's
also
something
that
we
should
check
and
I
just
added
it.
So
that's
the
the
reason
why
I
have
a
general
video-
and
I
don't
know
what's
about
this.
A
So
I
thought
the
my
understanding
of
like
the
issue
is
that.
A
Users
can
configure
a
view
to
be
a
certain
aggregation
on
any
type
of
instrument
that
could
possibly
cause
a
view,
conflict
and
them
setting
a
view
with
an
histogram
aggregation
to
change
an
async
instrument
into.
It
is
just
one
of
those
examples
right.
E
A
A
A
Sorry,
let
me
go
down,
can
you?
Can
you
open
up
the
code
view
for
this
metric
reader
storage?
This
can
can
is
isn't
this
what
you
want
to
see
no
like
without
the
comments
like.
Can
you
just
open
up
the
code
view.
A
Here,
no,
I
could
just
click
the
go
back
down
to
metric
reader
storage.
Go
to
view
file
the
three
dots
yeah.
Let
me
go
view
file.
A
And
go
back
go
down
to
the
okay,
so
that
go
up
here,
yep,
so
why
why?
Why,
like?
Let's
say-
let's
say
if
I
change
this
to
if
inst
is
instead
his
instance,
like
any
other
permutation
of
aggregation
and
instrument,
are
those
will
those
not
cause
conflicts.
E
A
E
Maybe
the
the
reason
why
I
added
it
here
is
because
it's
specifically
mentioned
in
spec
right,
so
you
can
take
a
look
at
that.
E
Okay,
I
don't
know
what
would
you
like
us
to
have
a
general
mechanism
that
finds
everything
that
is
conflicting
instead
of
having
to
rely
on
specific
checks?
Yes,
okay,
yeah.
I
would
also
like
to
have
that,
but
I
don't
know.
A
B
A
Want
to
first
understand
why,
like,
if,
if
like
why
this
specific
example
is,
is
called
out
and
checked,
but
like
not
any
other
permutation
of
instrument
and
aggregation,
you
mean
in
this
bag
or
both
actually
like
like.
Are
they
just
listing
one
example
that
is
possible,
or
the
only
example
that
that's
possible
just
one
example,
so.
B
Others
would
be
like
if
you
put
up
down
counter
with
a
histogram.
A
Right
exactly
so,
I
was
just
wondering
like
like:
would
this
pr
catch
that
okay,
I
haven't.
E
Actually
tried
to
cover
all
the
cases
in
this
pr.
I
pretty
much
just
found
that
one
in
the
spec
and
said
well,
since
it's
already
mentioned.
Let's,
let's
add
it
here,
we
can
add
more
checks
later.
I
guess
in
the
subsequent
pr.
A
A
Pr
that
this
is
the
the
one
and
only
check
that
we
have
to
this
is
just
yeah,
no
worries
yeah.
If,
if
you
could
just
add
a
to
do
then
then,
like
I,
I'm
not
trying
to
block
the
pr
or
anything
I'm
just.
I.
B
I
think
I
think
I
had
a
comment
on
here
also
like
it
would
be
nice
if
we
could
refactor
this,
because
it's
getting
a
bit
deep.
So
if
we
could
set
up
like
you
know,
this
is
the
place.
E
B
E
I
was
pretty
much
hoping
to
do
that
at
the
end
of
the
once
that
we
get
all
the
other
stuff
figured
out.
I
have
another.
E
E
E
B
No,
it's
it's,
I
think
the
other
way.
So
it's
okay.
B
So
I
think
I
think
this
is
covering
where
the
identity
is
overlapping.
So,
like
you
could
in
theory,
have
remember
there
was
like
two
things.
There
was
one
part
that
said
semantic
errors,
and
then
the
semantic
error
is
part
of
the
data
model,
says
metrics
in
the
same
meter
or
instrumentation
library,
with
the
same
name
but
different
properties.
Otherwise
is
a
semantic
error
and
then
there
was
a
separate
thing.
That
said,
there
has
to
be
a
single
writer
for
a
metric.
A
Okay
and
also
didn't
we
say
something
about
view
instrument
matches
not
having
the
name
property,
no.
E
A
E
All
right
so
just
to
make
sure
that
I
can
implement
this,
so
we
need
to
check
here.
A
Yeah,
that
is
true,
correct
all
right,
because
this
is
not,
it
would
be
a
property
so
because
you
have
name
and
description
already
as
properties
of
the
view
instrument
match
right
yeah.
So
it's
like,
I
think
it's
just
you
just
extend
that
into
either
like
a
like
identifier,
class
or
use
a
tuple,
or
something
like
that.
E
Okay,
the
other
thing
is
this:
intrinsic
data
properties,
which
are
where
applicable,
I
mean
this
is
not
just.
B
The
identity,
if
you
look
at
the
part
above
it
says,
identified
by
resource
scope,
metric
stream
name,
those
other
properties
are
all
identifying,
except
for
description
and
the.
B
I
think,
if
you
scroll
down
a
little
more,
it
says
yes
so
scale
or
bucket
count
of
exponential
histogram
or
bucket
boundary's.
Histogram
point
are
not
identifying,
so
it
would
be.
Basically
the
resource,
scope,
name,
data
point
type,
which
would
come
from
the
aggregation
and
the
unit
description.
Won't.
Yeah
description
is
not
identifying.
E
B
Okay,
I
think
you
probably
remember
like
an
earlier
prototype,
had
the
like
a
descriptor
metric
descriptor,
or
something
like
that,
and
I've
seen
that
in
a
few
of
the
other
implementations
as
like
a
way
to
make
this
comparison
a
lot
easier.
Okay,
yeah,
like
creating
a
class.
A
Are
we
are
we
able
to
since
we're
storing
like
a
bunch
of
view,
instrument
matches
and
that's
the
thing
that
determines
whether
or
not
something
is
a
conflicting
identity?
A
A
F
Okay,
okay,
yeah
yeah.
E
We
could,
instead
of
storing
the
instrument,
matches
in
a
list
and
store
them
in
a
set
so
that
we
can
make
all
one
comparisons.
Somehow
maybe
yeah.
E
Could
do
that
I'll
I'll
think
about
it
and
I'll
work
on
this
today?
Hopefully,
I
can
get
this
to
be
reviewed
by
the
end
of
the
day:
okay,
okay,
cool
yeah,
all
right.
A
E
Definitely
definitely
actually,
okay,
all
right.
So,
let's
see
what
else
do
we
have
here?
Okay,
these
two
pr's.
These
two
might
be
my
cpr's
okay,
so
I
was
talking
with
with
aaron
a
few
days
ago,
and
I
don't
have
this
idea,
which
I
agree
with.
I
think
it's
a
good
idea
about
refactoring
the
way
that
we
have
public
and
private
modules,
so
pretty
much.
E
What
aaron
wanted
was
that
only
the
very
specific
things
that
we
want
to
expose
in
in
our
api
are
actually
exposed
right
now,
our
modules
pretty
much
look
like
this.
So
if
this
is
a
public
module,
people
could
be
able
to
to
import
function
right,
it's
a
function,
but
they
will
also
be
able
to
import
match
because
match
is
here
at
the
same
level
as
function
here.
E
So
the
idea
is
to
make
all
these
modules
private,
as
they
are
right
now
and
then
create
public
modules
that
import
from
the
private
module
only
the
particular
things
that
we
want
so
in
this
way
match
won't
be
exposed
as
a
public
symbol,
which
is
great.
It
keeps
our
api,
smaller
and
because
in
theory,
if
we
wanted
to
implement
this
and
not
use
match
for
something
else,
it
in
theory
will
be
a
breaking
change.
B
E
B
I
have
been
playing
around
with
this
separately
also
because
I'm
trying
to
figure
out
how
sphinx
works
with
this,
like
I
did
some
reading
and
it
looks
like
it's
supposed
to
understand
this
correctly.
If
you
either
patch
the
underscore
underscore
module
special
variable
in
the
classes
or
if
you
put
them
in
the
underscore
underscore
all
list
for
the
module,
so
I
tried
it
and
sphynx
doesn't
doesn't
really
work
as
advertised.
B
I
got
a
bunch
of
errors,
so
I'm
trying
to
figure
out
how
to
make
it
work,
because
I
think
if
the
documentation
looks
like
that,
it's
gonna-
this
is
probably
not
a
very
viable
solution
and
I
just
wanna
make
sure
that
there
is
a
workaround
before
we
go
forward
with
this.
The
other
thing
is
there
was
like
any
comment
on
that.
First,
I
don't
know
if
you
found
a
way
to
make
it
work.
This.
E
No,
actually,
I
think.
E
Oh
yeah,
I
took
a
look
at
this,
which
I
think
is
the
exact
same
case
that
we
have
here,
and
this
was
supposed
to
fix
it
right,
because
if
you
put
it
in
all
correct-
and
I
tried
to
do
what
they
say
here-
that
you
change
the
I
don't
remember-
it
was
some
option
or
anyways.
I
I
tried
what
it
says
here,
but
it
made
no
difference
so.
E
Or
I
got
this
error,
I
don't
remember
right
right
now,
but
I
I
also
tried
to
fix
this.
I
could,
and
I
haven't
tried
it
yeah.
The
other
thing
that
it's
important
here
is
that
if
we
follow
this
approach,
should
we
do
the
same
thing
with
tracing.
B
E
E
What
I'm
trying
to
say
is
this
in
in
the
documentation.
We
don't
have
this.
We
don't
have
much
right,
so
some
people
may
argue
that
it
is
not
a
breaking
change
to
remove
much
here,
even
when
I
know
somebody
may
have
imported
it
already,
because
it's
not
part
of
the
documentation.
It's
not
part
of
the
api.
Once
again,
what
is
breaking?
What
is
not
it's
subjective?
E
B
Yeah,
I
mean,
I
think
I
think
it's
something
we
should
put
like
on
the
agenda
if
we
ever
do
make
a
breaking
change
but,
like
I
don't
see
a
huge
benefit
board
at
this
point
it
considering
we
could
bring
people,
I
don't
know,
and
unless
I'm
most
concerned
about
like
importing
match
as
I'm
concerned
about
like
the
the
like
span,
processor
is
imported
in
this
other
file.
B
E
Yeah,
that's
also
true,
that's
something
I
guess
we
can
fix
or
not
well
yeah.
We
will
have
to
use
aliases
or
something
like
that.
Yeah
anyways
yeah.
This
will
be
a
good
thing
to
have
it's
just
the
the
only
thing
that
is
blocking
us
right
now
is
this
documentation's
issue
right.
B
I'm
trying
to
go
through
it,
but
I'll,
let
you
know
if
I
get
it
working.
The
other
question
I
had
here
is
like
I
looked
briefly
at
the
actual
code:
can
you
can
you
open
the
code
sure.
B
I
was
a
little
confused,
I
think
github
kind
of
mangled
the
diff
here,
because
it
thinks
that
this
file
was
completely
deleted
and
then
that
one
was
completely
added.
But
I
don't
know
about
that
triple
leading
underscore
thing.
What
I
was
thinking
was
to
make
like
a
internal
folder,
and
then
you
can
move
that
just
that
everything
into
that
internal
folder
and.
E
Yeah
yeah
sure
I
was
just
the
algorithm
I
applied
was
just
add
an
underscore
to
the
name
of
the
existing
modules,
or
this
ended
up
with
three
other
scores.
E
Okay
right,
but
but
yeah
that's
pretty
much
the
everything
I
did.
I
just
created
a
new
private
module
for
for
every
public
one
there
was
by
okay.
So
we
have
that
one.
We
can
discuss
that
online.
A
E
A
I
had
another
question
on
that.
Pr,
so
is
this:
is
this
effort
so
that
we'll
eventually
remove
underscore
metrics
like
I
was
a
bit
confused
that
why
adding
an
underscore
would
fulfill
that
example
that
you
have
in
the
description,
because.
A
E
Yep,
okay,
that
makes
sense.
Okay,
all
right
great
okay,
same
here
with
the
sdk
here;
okay,
what
else
yeah
there
is
this
other
issue
that
I
do
not
also
completely
error,
so
I
don't
know
if
you
could
maybe
explain
a
little
bit.
This
is
the
comment
where
you,
that
is
your.
E
B
Yeah
this
was
this
was
basically
like.
I
noticed
this.
The
permicas
exporter
is
now
doing
this
grouping
because
it
has
this
metric
family
concept
and
I
think
the
otp
exporter
is
also
doing
the
grouping.
I
don't
know
what
other
so
like
the
google
cloud.
One
does
not
need
to
do
this
grouping.
I
don't
know
about
layton,
what's
up
with
azure,
but
basically,
if
we're
gonna
have
to
do
this
in
like
four
exporters,
then
we
might
as
well
just
implement
this
in
the
sdk.
E
Okay:
okay,
first
question
is
this:
is
this
a
a
a
bug
fix
or
an
enhancement.
B
B
Yeah,
so
if
we
release
with
what
we
have
then,
then
we're
gonna
leave
it
as
it
is
okay,
we
could
provide
like
a
util
to
do
the
grouping
or
something
like
that.
But
if
it's
such
a
common
use
case,
we
could
just
implement
it
off
the
bat.
E
E
B
No,
not
that
specifically,
what
I'm
trying
to
say
is
the
metrics
could
come
in
looking
closer
to
the
otlp
format,
which
is
already,
which
would
already
be
grouped
by
instrumentation
library
or
whatever.
It's
called
no
instrumentation
scope.
And
then
you
would
have
a
metric
object
and
then
it
would
have
each
point
with
a
different
label
set
or
different
attribute
set
right.
E
B
E
Okay,
so
you're
talking
about
changing
this
class.
B
Yeah,
so
basically
these
attributes
yeah
the
attribute,
would
be
moved
into
the
point.
The
description
would
be
moved,
or
rather,
let's
see
there
would
be
basically
whatever
is
in
the
otlp
definition.
That's
linked
above
there.
This
one.
B
B
E
Okay,
all
right
yeah,
I'm
just
a
little
bit
concerned
about
the
how
complicated
this
change
may
be
to
do.
Do
you
feel
like
it's
complicated,
because
my
goal
for
this
week
is
to
have
a
release
candidate
by
the
end
of
the
week
and,
like
I
like
to
have
this,
but
also.
B
Right
I
mean
that's,
why
I'm
bringing
it
up
right
like
I
wanted
to
be
ergonomic.
I
don't
want
to
rush
this
and
have
have
something
that
you
know
a
bunch
of
people
don't
like.
F
Yeah,
I'm
not
sure
what
okay.
E
All
right,
let's,
let's
try
to
discuss
this
discussing
this
offline.
I
think
maybe
I
can
get
this
done
today
or
tomorrow,
so
that
we
can
include
it
in
the
release
campaigns.
B
So,
specifically,
what
I'm
trying
to
say
is
the
prometheus
exporter
has
code
to
do
something
like
this.
The
otlp
exporter
is
code
to
do
something
like
this.
I
don't
know
a
lot
of
other
open
source
back-ends
like
what
they
would
want
to
do.
I
can
tell
you
for
google
cloud.
We
don't
need
to
do
the
the
grouping.
B
I
was
trying
to
say
leighton
like
what
do
you
have
to
do
or
do
what
you
have
to
do
for
light
steps
back
in
in
terms
of
this
like
white
stuff,
except
otlp,
so
I
suppose
you're
using
that.
But
I
think
are
you
planning
to
build
an
exporter
latent.
B
All
right,
maybe
let's
just
discuss
it
offline,
but
I
wouldn't
like
jump,
jump
to
start
implementing
this
diego.
E
Okay,
yeah,
I
I
also
see
your
point,
but
I
also
think
this
is
not
critical
in
the
sense
that
that
I
mean,
though
the
words
that
can
happen
is
that
we
will
have
some
repeated
code
in
the
exporters.
A
E
If
we
decide
that
we
don't,
we
will
end
up
with
some
repeated
code
in
the
explorers.
A
I
don't
think
it's
just
repeated
code
like
like
the
thing
that
actually
is
exported
would
be
different
right.
Oh.
A
I
thought
would
it
not
be
flattened
or
what
whatever
like,
if
they
would
have
printed.
B
Out
or
maybe
let's
just
follow
up
on
the
issue,
I
think
that
might
be
easier
right.
Yeah.
E
All
right,
okay,
move
on
to
the
next
okay,
all
right.
So
this
is
the
the
issue
that
we
have
right
now
in
in
progress.
I'm
sorry
it's
gonna
spawn,
but
I
don't
know
if
you
have
some
status
on
this
issue.
B
E
B
Yeah
so
right
now,
I'm
just
going
to
focus
on
metrics
and
we
can
try
to
try
to
fix
it
in
tracing
in
like
a
separate
release,
but
basically
here's
sort
of
the
prior
art
right
so
java.
All
these
asynchronous
methods
are
returning,
something
that's
like
a
promise
future
thing
and
that
method
has
a
join
function,
which
sorry,
sorry,
that
class
is
a
joint
function
which
lets
you
specify
optionally,
a
timeout
for
how
long
it
should
wait.
B
So
that's
how
they're
implementing
this
javascript
doesn't
do
anything
special
and
it
doesn't
look
like
there's
a
way
to
really
cancel
promises
in
general,
so
they
haven't
really
implemented
that
spec
requirement.
I
suppose,
go
if
anybody's
familiar
with
it.
It
just
uses
the
context
which
the
the
code
that
receives
the
context
has
to
you
know,
pass
it
on
and
and
respect
the
cancellation
that
it
says.
B
So
if
you
were
to
just
completely
ignore
it,
then
it
would
also
block
dotnet
accepts
a
timeout
parameter
and
then
whoever's
implementing
the
exporter
should
just
respect
that
so
based
on
that,
like
most
of
them,
what
they're
doing
is
they're
just
saying:
okay,
this
shouldn't
block
and
I'm
going
to
pass
the
timeout
all
the
way
down
to
the
user
like
the
exporter
code
or
whatever
is
the
blocking
component,
so
they're
not
doing
like
with
the
with
the
exception
of
java
they're,
not
doing
anything
special.
B
So
what
I
would
propose
is
just
adding
timeout
parameters
and
passing
them
to
the
exporter,
because
most
of
the
exporters
are
going
to
either.
You
know
like
use
some
underlying
transport
which
accepts
a
timeout
or
they
can,
you
know,
run
their
thing
in
a
separate
thread
and
cancel
the
thread
after
a
certain
amount
of
time.
But
I
don't
know
if
we
need
to
provide
like
a
general
mechanism
for
this.
Besides,
just
saying
hey,
please
respect
this
timeout.
So
that's
what
I'm
planning
to
do.
E
Okay,
yeah,
I
am
I'm
okay
with
that,
the
probably
the
the
specifics
of
how
to
implement
the
timeout
don't
see
that
necessarily
as
a
part
of
open
telemetry.
I
guess
it
should
be
concerned
with
spanish
and
traces,
not
necessarily
with
a
timeout.
E
There
are
even
third-party
solutions
already
available
around
there.
Okay,
the
problem
that
I,
I
think
you
you
have
with
passing
a
timeout
is:
is
this
right?
It's
been
backwards
compatible
in.
E
Okay,
right,
just
out
of
curiosity,
is
there
also
an
environment
variable
related
to
this
demo.
Configuration.
B
E
All
right
so
just
to
make
sure
that
I
understand
what
you're
planning
to
do
is
to
introduce
the
timeout
parameter
here
in
metrics
and
just
that
right
and
the
specific
exporters
or
whoever
receives
that
timeout
should
be
responsible
to
respect
that
or
use
it
somehow
yep.
That's
that's
fine!
Okay,
yeah!
I
think
I'm,
okay
with
that,
and
also
you
want
to
introduce
this
fix
for
tracing
in
a
separate
issue,
right,
yeah,
okay,
so
supply
later.
A
Is
there
any
other
configurable
thing
that
can
be
passed
down
to
exporters,
how.
A
Of
to
add
this,
I
don't
know
does
that
that's
a
separate
topic
like
so
timeout
like
would
configure
like
exporter
export
behavior.
Is
there
anything
else
that
could
possibly
be
a
configuration
for
an
exporter.
A
I
don't
know
I'm
just
asking
like
like.
I
guess
this
could
be
solved
in
the
future
if
we
do
the
rx
skateworks
thing
but
like
if,
in
the
future
like
we
want
to
pass
another
configuration
down
right,
we
would
have
to
like
either
add
another
keyword
and
then
add
more
documentation,
saying
hey
this
is
available
or
do
the
whole
or
if
we
were
stable
already,
then
we
gotta
do
the
whole
type
type
error
thing
as
well
right.
So
I'm.
B
Saying
if
we
add,
if
we
add
star
r,
star
keyword,
args
to
the
interface
definitions,
so
like,
for
instance,
in
the
metric
exporter,
if
we
add
that
ahead
of
time,
then
it
will
never
be
a
breaking
change.
B
A
E
E
Okay,
do
you
think
you
can
have
it
implemented
by
tomorrow.
B
Yeah
I'll
try
to
put
a
pr
out.
I
guess
we
should
probably
talk
about
yeah,
sorry
that
is
there
anything
else
for
this.
No.
B
Yeah
yeah.
A
B
E
Yeah,
well,
I
will,
I
think
we
we
may
still
have
to
discuss
something
regarding
this
issue
that
we
mentioned
about
the
metrics
format
and
stuff,
but
but
I
would.
D
E
To
have
everything
any
other
issues
done
as
soon
as
possible,
so
that
if
we
solve
that
we
can
cut
an
rc,
maybe
if
not
tomorrow,
hopefully
next
week
or
something
so,
do
we
have
an
rc
before
our
release,
so
so
yeah,
I'm
just
trying
to
to
have
all
the
all
the
stuff
that
we
have
here
merged
as
soon
as
possible.
So
implementation
for
this
tomorrow
will
be
great.
A
Hey
aaron,
so
the
rxk
orcs
thing
is
already
kind
of
too
late
for
tracing,
but
you
think
we
should
have
this
as
like
a
a
standard
for
like
any
other
interfaces
that
we
implement
moving
forward,
or
at
least.
B
B
Yeah,
that's
yeah,
that's
sort
of
what
I'm
potentially
saying
here.
That
would
only
really
be
needed
for
something
that
we
expect
third
parties
or
users
to
implement
so
right
for
like
metrics.
That
would
be
any
methods
on
metric
reader
or
methods
on
metric
exporter,
correct
yeah,.
B
A
A
Okay,
that
sounds
good,
diego,
but
that
that
will
kind
of
block
the
rc
just
a
heads
up.
If
we
want.
E
E
Yeah
in
metrics
yeah:
well,
that's
something
that
yeah!
If,
if
you
open
a
issue
today,
I
can,
I
can
try
to
implement
it
right
away
today.
It
should.
E
E
So
I
I
I
can
do
that.
I
can
in
fact
let
me
open
an
issue
here,
reference,
a
new
issue,
yeah
I'll
use
that
to
add
arcs
and
kw.
A
Arcs
all
right,
I
have.
Oh
sorry,
are
we
finished
with
this
yeah,
so
your
current
check
instrument,
names
and
units
pr
that
you
just
opened.
A
E
A
No,
no,
not
it
has
nothing
to
do
with
duplicate
that
we're
talking
about
if
it's
invalid
or
not,
based
off
of
the
that
link
that
you
put,
I
can
go
up,
go
to
the
issue.
A
Yeah
so,
like
you
know,
they
have
to
follow
ascii
and
stuff.
The
unit
has
to
be
you
know
not
null
and
stuff,
and
if
you
go
down,
I
believe
the
description
also
has
to
have
some
sort
of
certain
properties.
A
So
I'm
pretty
sure
that's
what
you're
referring
to
right
for
this
issue,
like
the
instrument,
has
to
be
valid
right.
So.
E
The
instrument
name
has
to
evolve.
A
E
A
So
what
about
that?
Well,
in
your
pr
you're,
just
checking
name
and
units.
I
was
wondering
like
why
you
just
only
chose
those
two
I
mean
melody.
You
mean
we
should
also
check
the.
E
Well,
I
mean
we're
using
strings
which
the
python
strings
support
more
than
122
characters.
E
A
No,
it
says
it's
it's
made
aside,
so
it's
not
porn
but
like
I
think
it's
just
good
to
identify
that,
like
yeah,
we
did
consider
what
it
means
for
a
description
to
be
valid
and
we
chose
not
to
do
it
right.
A
D
E
A
That,
in
the
pr
description,
sure
yeah
and
as
long
as
like
the
first
bullet
point
is
met
too,
like
that's
a
valid
statement,
so
I'm
pretty
sure
we
do
do
this.
E
Okay,
yeah
all
right,
yeah
srikant.
Thank
you
for
your
review.
If
someone
else
can
take
a
look
at
it,
it's
pretty
easy
as
well.
Nothing
works,
but
I
have
to
fix
that
nice
all
right,
that's
pretty
much!
It
so
get
a
few
pin
issues.
Let's
try
to
look
at
them
as
quick
as
possible.
E
Looking
for
us,
they
are
not
big
they're.
Just,
I
think
quite
minor
considerations.
The
other
one
I'm
more
concerned
about
this.
Is
this
one.
It's
about
the
refactoring
of
the
metric
format.
I
can.
I
can
work
on
that
today.
Aaron.
Will
you
be
available
via
slack
to
answer
my
questions
probably
have
a.
B
Bunch
of
them
yeah
sure
I
mean
I,
I
think
we
need
to
discuss
this
one
like
decide.
If
you
want
to
do
it,
I
don't
think
just
jumping
on
it
is
necessarily
the
way
to
go.
So
if
you
really
want
to
do
an
rc
without
this,
we
find
it's
not
like
a
big
problem
in
in
our
discussions,
and
we
can
just
you
know
close
it
without
doing
it,
but
no.
E
Yeah
all
right,
let's
move
this
conversation
online
because
I
think
we're
our
team,
okay,
cool,
yeah,
all
right!
Thank
you
very
much,
we'll
see
you
next
week.
All
right
see
you
guys.