►
From YouTube: 2022-06-09 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
A
C
D
A
I
guess
we
can
get
started
as
usual.
Please
add
your
names
to
the
attendees
list.
Could
any
topics
issues
prs?
You
want
to
bring
up.
A
All
right,
okay,
I
guess
we
could
first
get
started
first
topic
of
the
agenda.
Aaron
metrics,
auto
instrumentation.
C
I
I
sort
of
just
stream
of
consciousness
that
stream
of
consciousness
put
a
few
things
in
here,
while
I'm
working
on
the
getting
started,
documentation
the
it
I
I'm
playing
around
with
it
off
of
maine,
and
it
looks
like
it's
working
for
the
most
part,
but
there
are
a
few
things
that
are
missing.
C
The
main
things
are
the
so
so
for
tracing.
We
have
the
batch
span,
processor
parameters
available
so
like
export
timeout
and
the
export
interval.
There's
no
way
to
configure
this
right
now
from
what
I
can
tell
so
somebody
please
correct
me:
if
I'm
wrong.
C
Is
it
available
on
the
command
line,
or
is
it
just
the
environment
variables
right
now.
E
C
Yeah
I'm
playing
around
with
it
and
I
didn't
see
it
in
the
list.
I'm
pretty
sure
it's
the
next
one,
I'm
pretty
sure
we
don't
have,
which
would
be
the
view
configuration.
C
So
you
know
right
now
our
view
configuration
is
just
through
code
with
the
data
classes,
the
the
spec
has
no
like,
like
we
have
for
some
samplers
and
stuff
there's
no
generic
text
version
that
we
that
we
should
expect
for
view
configuration
since
it's
sort
of
language
dependent
for
the
given
sdk,
so
we
this
is
like
the
main
way
to
configure
instrumentation
for
metrics,
though
so
I
don't
know.
C
If
anybody
has
some
ideas
or
has
thought
about
it,
but
the
view
configuration
can
get
kind
of
stored,
it
can
be
pretty
big.
It's
not
something,
that's
easy
to
parse
or
anything.
So
some
some
possible
things
would
be
like
having
an
expression
that
we
eval
to
create
the
view
data
classes.
Obviously
that's
not
ideal.
People
could
could
accidentally
eval
something
I
don't
know
if
anybody
else
has
some
ideas,
but
I'm
happy
to
create
issues
for
this
if
no,
if,
if
we're
sure,
nobody's
working
on
it
yeah,
I.
A
Think
when
the
I
think,
when
the
there's
a
pr
up
for
adding,
I
think
that
was
got
merged
for
adding
the
metrics
to
auto
instrumentation,
and
I
was
looking
at
like
the
things
that
we
can
configure
like
just
comparing
that
with
tracing
like
the
view,
seems
pretty
pretty
complicated
right
like
I
was
just
under
the
assumption
at
that
time
like,
which
is
why
I
didn't
suggest
it
that,
like
we're,
only
configuring
things
that
are
like
that
are
like
auto
instrumentation
is
like
the
like.
This
simple
use
case.
A
I
guess
I
was
thinking
like
like
a
config
file,
might
work
or
something
like
some
sort
of
json.
E
Yeah
that
that's
a
good
idea
like
we,
we
just
like
always
brought
this
up
in
the
past,
like
we
wanted
to
like
there
are
some
things
that
you
know.
There
is
no
way
you
can
configure
them
with
env.
You
know
argument
yeah,
so
we
should
be.
E
You
know
going
towards
a
direction
where,
if
they
should
be
able
to
have
you
know
some
sort
of,
let's
say
young
like
take
the
inspiration
from
django
settings
file,
and
you
know
something
like
that:
json
file
or
some
something
similar
where
they
can
create
these
complicated
settings
with
the
code
itself
that
that
we
can
support.
F
F
Yeah,
sir,
no,
let's
just
mention
that
the
actually
the
topic
of
configuration
has
been
like
a
big
topic
of
discussion,
since
I
can
remember
the
for
the
same
reason.
I
believe
that
when
we
were
working
with
the
instrumentation
in
racing
chemical,
it
was
also
necessary
to
find
a
way
of
doing
more
configuration
and
then
we
can
and
the
config
file
was
discussed,
and
it
was
also
discussed
if
we
are
going
to
support
several
configuration
mechanisms
like
cli
arguments
and
integration
file,
which
one
will
write,
rule
and
kind
of
stuff
right.
F
So
it's
it
wasn't.
F
I
think
we
didn't
reach
an
agreement
then,
but
I
think
we're
pretty
much
finding
out
the
same
need
to
do
it
now,
but
probably
we'll
be
gonna
face
the
same
issues
again,
so
I
don't
know
if
the.
If,
if
we
should
start
this
into
more
detail,.
A
C
Yep,
that
sounds
good.
I
agree
with
what
everyone
said.
The
only
thing
I
would
add
is
for
views.
Specifically.
There
was
some
discussion
of
having
like
a
language
agnostic
view
configuration.
C
So
if
we
had
something
like
a
like
a
config
file
and
then
something
was
later
introduced
into
the
spec,
we
would
either
have
to
continue
to
support
the
the
old
config
to
make
it
backward
compatible,
or
you
know,
make
a
make
a
breaking
change
there.
C
So,
specifically
like
there
was
this
discussion
about
wild
cards
and
globs,
and
then
we
ended
up
specifying
it
so
that
we
wouldn't
have
to
worry
about
like
language,
reg
x's
like
re2
versus
pcr
and
stuff,
like
that,
so
I
think
I
kind
of
like
the
settings
file
idea.
So
it's
something
that's
just
like
plain
python
code,
since
this
is
essentially
making
some
some
data
class
instances.
C
You
know.
The
only
thing
I
did
want
to
say
is,
I
don't
think
like,
like
views,
are
sort
of
an
advanced
topic,
but
it's
also
intended
to
be
the
configuration
mechanism
for
reducing
cardinality.
So,
like
our
system,
metrics
instrumentation
right
now,
it
has
a
bunch
of
config
parameters
that
it
accepts.
C
I
think
those
are
those
sort
of
predate
the
view
specification
and
we
would
prefer
to
use
views
instead
for
stuff
like
that.
So
if
somebody
doesn't
care
about
some
hyper-specific,
you
know
label
on
some
metric,
then
they
do
need
a
way
to
to
turn
it
off
and
use
this
like
the
intent
mechanism.
So
I
do
think
it's
important,
but
yeah
I'll
open
up
issues
for
that.
C
C
Yeah,
I
was,
I
was
wondering,
also,
could
we
get
do
we
have
any
update
on
the
I
saw
there
was
a
request
instrumentation
pr.
I
was
wondering
if
there's
anything
any
work
being
done
for
back
end
for
like
server-side
instrumentations.
A
So
I
think
there
was
a
a
draft
pr
or
something
up.
E
Yeah,
there
are
no
server
side
prs
matrix.
C
Yeah.
Okay,
so
I
mean
this
is
stuff
that
I
encountered
when
I
was
trying
to
write
the
documentation
for
getting
started.
I
think
for,
like
our
staple
release,
it'd
be
great
to
have
at
least
something
so
the
getting
started
guide
makes
sense
right.
C
A
Okay,
I
was
gonna,
say
something,
but
I
totally
forgot
all
right:
okay,
so
yeah,
let's
not
talk
about
the
metric
is
so
for
the
second
one.
We
should
mark
the
scope
of
metrics
rc2,
so
I
guess,
first
of
all,
the
kind
of
discussion
that
we
need
to
have
is:
are
we
planning
to
have
another
rc,
or
are
we
going
to
just
do
a
stable
release
immediately,
as
well
as
what
will
constitute
as
the
issues
that
we
need
to
solve
for
this
next
release?
A
A
So
I
guess
after
the
issues
in
pr,
so
if
you
guys
want,
please
add
your
shares
and
issues
you
want
to
be
reviewed
or
you
want
to
bump
up.
A
Yeah,
I
think
one
of
them
I
did
add
for
prs:
it's
recons
http
otlp
log
exporter.
It's
been
out
for
a
while,
so
I've
already
approved
it.
If
we
can
just
get
one
more
approval
and
then
take
a
look
at
it,
that'd
be
great.
A
So
does
anyone
have
any
other
doesn't
look
like
there's
any
other
issues
or
pr's?
If
so,
if
that's
the
case,
we
can
go
through
metric
stuff.
If
that's
all
right
with
everyone.
A
A
So
there
is
yeah,
why
is
the
formatting
like
this.
A
There's
this
automatic
release
workflow
as
well
that
was
created.
I
don't
know
how
many
have
taken
a
look
at
this,
but
I
have
made
a
lot
of
comments
and
there
was.
I
did
approve
it,
but
there
was
some
recent
changes,
so
I
would
have
to
test
this
again,
but
probably.
A
This
will
make
it
much
easier
for
maintainers,
but
I
don't
think
we
kind
of
want
this
yet
at
least
to
block
our
next
metrics
release,
so
just
something
to
keep
in
mind
to
get
eyes
on
this
too,
especially
for
the
maintainers,
so
yeah,
okay
cool
other
than
that.
Let's,
if
anyone
know,
unless
there's
any
other
issues
or
prs,
I
believe
we
should
talk
about
what's
exactly
needed
for
our
rc2
okay.
So
right
now
I
haven't
really.
A
We
haven't
really
triaged
all
of
the
things
that
we
need,
but
I'm
hoping
that
all
the
things
that
are
marked
as
metrics.
It's
like
the
comprehensive
list
that
was
returned
by
rc1.
A
So
if
that's
the
case,
I
guess
we
can
go
through
these
one
by
one
to
see.
If
we
need
this
for
the
for
the
release,
let
me
check
we
don't
have
a
label
for
that,
so
I'll
probably
just
create
one
real,
quick.
E
A
Okay,
so
I
believe
just
like
all
the
bugs
are
needed
for
ga.
A
I'm
I'm
leaning
towards,
like
all
of
the
examples
we
need
deals.
We
know
this
will
be.
We
need
those
as
well.
So
you
know
everyone
just
stop
me
if
you
disagree,
so
I'm
just
gonna.
Do
this
real,
quick.
A
A
Okay,
anyways
I'll
do
this
later,
but
so
does
everyone
agree
that,
like
we
just
need
all
of
this
like,
and
we
want
to
point
out
things
that
we
don't
need
for
the
release.
A
We
don't
need
the
examples
for
our
ga,
I
mean
how
do
I.
F
E
A
C
C
F
I
have
been
working
so
yeah.
I
have
been
working
with
the
system,
metrics
instrumentation
and
I
have
found
a
few
blocks
as
I
have
been
doing
so
I
don't
know
if
anyone
else
has
had
a
chance
to
actually
try
to
use
it
in
a
more
integration
test,
lightweight
like
running
train,
trying
to
run
a
funny
full
example
with
experimentations,
or
something
like
that.
A
F
Yeah,
because
I
imagine
that
will
be
likely
for
us
to
find
more
bots
as
we
do
this
yeah
and
the
more
that
we
we
try
it
out
the
more
blocks
that
we
find
also
taking
into
consideration
that
finding
boxing
instrumentation
should,
in
theory,
I
think,
not
affect
the
release
of
this
table,
but
finding
box
in
the
sdk
or
api.
I
guess
correct.
G
A
Okay,
so
right
so
in
my
opinion,
right
now,
we're
still
getting
we're
still
finding
kind
of
like
issues
that
are
coming
in
for
metrics,
and
my
understanding
behind
the
purpose
of
rcs
is
like
until
like
we
get
a
reasonable
like
reduction
or
not
a
lot
of
new
issues
that
are
coming
up.
That's
like
when
we
can
be
fairly
confident
that
our
rc's
can
be
released
as
stable.
A
That's
my
understanding,
and
it
doesn't
seem
like
the
case
right
now,
so
I'm
advocating
for
another
rc
once
we
get
that
amount
of
you
know
bugs
to
a
reason,
amount
of
level
that
are
coming
in.
Does
anybody
else
have
any
other
opinions
of
that
all
right?
It
looks
like
we,
scott
aaron
yeah.
F
A
Okay,
okay,
that's
that
sounds
good.
E
F
That
this
is
a
bit
artificial
that
I
would
like
to
deliver
to
the
community,
something
in
that
time
frame,
because,
if
not,
I
think
they
will.
They
can
be
concerns
that
not
a
stable
release,
not
gonna,
come
if.
A
People
are
kind
of
expecting
it
too
right.
So
my
question
is
diego
with
this
kind
of
like
velocity
like
originally.
I
did
remember
that,
like
you
really
wanted
to
get
at
least
a
stable
release
hour
and
rc
out
by
kubecon
right
is
the
same
kind
of
desire.
Still
there
like.
Are
you
still
going
to
be
fully
kind
of
driving
this.
F
Yeah
actually,
right
now
I
am
pretty
much
focused
on
on
using
metrics
and
and
using
the
sdk
and
trying
it
out
with
this
instrumentation.
That's
that's
what
I
have
to
do.
The
release
of
metrics
is
more
important,
of
course,
but
I
feel
like
right
now.
It's
just
a
matter
of
us
using
this
and
finding
bugs
and
fixing
them
so
I'll
I'll
be
pretty
much
doing
the
the
same
that
I'm
doing
right
now
for
the
next
few
weeks.
F
I
guess
which
is
pretty
much
using
the
the
sdk
finding
box
and
fixing
them
as
soon
as
possible.
If
your
question
is,
if
I
will
be
dedicating
more
full
time
to
doing
that,
the
answer
is
yes
for
your
question
of
how
argent
community
wise
this
is.
I
don't
have
much
of
an
answer.
I
think
the
the
more
important
goal
was
having
something
for
the
for
the
kubecon.
We
achieved
that
I
see
yeah.
A
Okay,
awesome,
that's
great
all
right,
so
I
think
if
that's
the
case,
what
what
does
everyone
think
about?
Should
we
have
like
a
separate
ga
tag
with
rc2
rc2,
actually.
A
Okay,
I'll
I'll,
create
that,
and
secondly,
do
you
think
it'll
be
worth
it
to
add
a
project
board
for
this.
F
Yeah
yeah,
I
think
it's,
it's
not
a
big
expense
to
have
a
project,
and
it
helps
a
lot,
at
least
at
least.
A
I
think,
in
my
opinion,
it
does
too
yep
yeah,
okay,
cool
yeah.
That
makes
sense
to
me
in
terms
of.
Does
anybody
have
any
opinions
here
in
terms
of
like
going
through
these
issues
and
seeing
if
we
need
them
for
rc2
or
not?
A
B
H
B
F
I'll
say
that
for
rc2,
let's
focus
on
everything
that
has
a
bug
label,
okay,
and
I
think
that
in
any
case,
since
we
are
releasing
the
the
rc2
in
in
a
week,
let's
just
try
to
fix
as
many
bugs
as
possible
and
then
then
we
can
decide
if
we,
if,
if
a
month
and
a
week
from
now,
do
we
need
another
rc
or.
A
G
C
A
You
know,
what's
the
am
I
am,
I
missing
something.
There's.
A
Did
did
you
add
the
metrics
label?
Maybe.
A
Oh,
oh,
I
see,
I
see
what
you
mean.
Okay,
do
we
want
to
go
through
them
to
see
if
we
need
them
for
us
a2?
Is
that
what
you
mean.
A
A
Okay?
Okay,
I
guess
we
could
start
with
the
first
one
that
aaron
just
sneaked
in.
C
Yeah,
I
would
say
this:
one
is
additive.
A
I
think
this
is
properly
labeled
right
now,
yeah,
okay,
I'm
just
going
to
assume
that
silence
means
everyone
agrees
to
like
kind
of
streamline
this
okay.
So
this
this
is
definitely
rc2
as
well.
It
is
a
bug,
so
I'm
just
going
to
add
that
here
example
for
system
metrics.
I
believe
that's
correct,
exactly
I'm,
just
assuming
all
of
the
examples
are
just
going
to
be
needed
for
ga,
because
we're
trying
to
minimize
oops.
What
am
I.
B
A
A
All
right
bug,
okay,
so
let's
do.
A
Interesting
yeah,
I
remember
I
was
talking
a
lot
about
this.
Is
this
like
because
we
don't
even
have
this
for
tracing
like?
Is
this
absolutely
needed
for
rc2?
You
think
aaron?
I
know
it's
important
and.
C
Lucky
yeah,
I
mean,
I
would
say
the
fact
that,
like
nobody's
really
complained
about
this
over
a
year
out
from
the
tracing
unstable
release,
I
would
guess
that
it's
not
a
huge
issue.
I
mean
just
from
just
from
looking
at
the
actual
problem.
I
would
think
it's
a
huge
issue,
but
I
don't.
A
C
A
Mid
max
fields,
histogram,
I
think
you
have
a
pr
out,
but
it
was
closed
because
the
proto
wasn't
out
yet
yeah.
Would
this
be
fine
for
rc2?
You
think.
F
Yeah
yeah,
add
it
other
label
and
I'll
check
it
out.
If
it's
low
hanging
fruit,
then
there's
a
vr.
I
can
show
you
just
finish
that
yeah.
C
C
So
the
spec
is
saying
essentially
the
if
you've
misconfigured
the
exporter.
The
exporter
should
report
this
right.
C
The
way
that
it's
specified
is
that
I
believe,
if
I
remember
right,
the
metric
reader
is
in
charge
of
all
this
configuration.
We,
I
think
we
provide
a
way
for
the
exporter
to
notify
the
periodic
exporting
metric
reader,
but
somebody
can
implement
a
metric
reader
which
doesn't
respect
that
or
there's
also
like
some
environment
variables.
I
don't
know
if
those
would
override
the
defaults
or
whatever.
A
What's
what's
the
mechanism
in
and
how
the
exporter
informs
the
reader
that
it
needs
to
be
changed?
C
Changed
it
there,
there
were
a
few
spec
changes,
sort
of
very
late
in
the
before
the
release.
A
C
Go
ahead.
Sorry,
so
I
said
prometheus
specifically,
is
a
metric
reader
right.
Yes,
no,
the
exporter
interface
is
for
push
exporters,
so
I
don't
think
this
applies
to
prometheus,
because
it's
in
charge
of
its
own
configuration,
the
only
other
exporter
we
have
is
otlp
which
can
support
both,
in
which
case
it
wouldn't
be
misconfigured
right.
A
Well,
it's
what
so,
but
just
because
it
could
support
bose.
Why
does
it
mean
it
can't
be
misconfigured
for
otp.
D
A
H
Cool
we
can
move
right
along.
E
I
believe,
like
we
decided
to
not
to
include
so
these
kind
of
checks.
Are
you
know,
error
reporting
some.
You
know
miscon
some
steps
like
this.
We
didn't
want
to
include
an
rc1
yeah,
since
they
are
not
really
major
issues.
So
I
guess
what
we
can
do.
Is
it's
fine
if
we
target
you
know
this
for
the
ga
so.
F
There
was
like
some
like
a
big
feature,
feature
to
be
understood.
You
know
a
little
bit
of
a
wide
sense,
that
is
about
view
configuration
management,
resolution
and
reporting
right
right,
including
printing,
a
view
recipe
if
something
goes
wrong
with
the
view
configuration
so
that
the
user
knows
how
to
fix
that,
we
intentionally
did
not
add
that
feature
to
our
rc1.
A
H
E
F
Never
I
think
we
never
agreed
on
anything
about.
There
is
the
specification,
doesn't
kind
of
specification
says
we
have
to
invoke
for
slush
on
this
object,
but
in
the
definition
of
the
those
objects
inspect
force,
flush
does
not
show
up.
F
I
will
agree
to
close
this
issue
until
it's
a
well-defined
inspect
because
right
now
it's
it's
contradictory
aspect
says
one
thing,
but
it
doesn't
include
that
method
in
the
expected.
F
All
right,
it's
just
the
fact
that
this
doesn't
seem
like
an
issue
that
should
be
should
exist
primarily
on
the
python
repo,
but
on
the
spec.
I
think
it
would
be
better.
F
I
can
do
that
if
you
want.
Let's
do
this,
assign
this
issue
to
me
and
I'll,
take
care
of
closing
this
one
and
open
an
issue
in
this
way.
A
A
Could
you
just
kind
of
like
comment
that,
like
oh
will
be,
instead
of
closing
it
just
like
comment?
What
you're
doing
that's
fine.
A
F
Yeah,
philosophical
issue:
since
we
don't
do
the
same
for
tracing-
and
this
is
something
that
we
have
been
doing
for
forever
in
tracing
changing-
this
will
be
completely
breaking.
E
F
F
Well,
all
right
yeah
that
there
will
be
another
possibility
that
they
can
inform
that
they
cannot
instantiate
directly.
I
don't
know
how
to
do
that.
I
mean
how
to
control.
F
A
C
E
Yeah,
so
there
is
this
exception
drawn
in
our
underscore
new
open
school
in
the
span
class.
If
you
go
look
at
it
yeah
also,
we
should
probably
have
something
like
that
in
tracer
and
meter
instances,
but
I
don't
know
if
that
will
be
a
breaking
change.
Yeah,
like
people
have,
I
I
wouldn't
expect
people
to
instantiate
tracer
instances,
because
it
requires
some
parameters
but
yeah.
You
never
know
what
people
do
lots
of
weird
stuff
in
the
world.
F
A
Well,
actually,
just
taking
a
look
at
the
spec
is
the
question
like
neometer
instances
are
always
created
to
the
meteor
provider.
Like
does
that
mean
that,
like
we
have
to
enforce
this,
or
is
this
just
like
a
like
a
promise?
It's
like
if
you're
not
using
our
apis,
there's
like
some
unknown
behavior,
we
don't
promise
anything.
F
A
Like
was
there
a
reason
why
we
guarded
fans
from
instantiation,
pretty
sure
that
was
like,
like
we
thought
that
that
was
a
we
wanted
to
prevent
users
from
doing
that
ourselves
as
a.
B
A
F
Well,
it's
I
don't.
A
Know
yeah
we're
getting
two
gray
area
about
this
right
now,
but
if
anything,
so
I
guess
the
question
is
right
now,
whether
or
not
in
general,
we
want
to
protect
users
from
doing
anything
stupid
at
all,
which
is
the
question,
and
if
the
answer
is
yes
like,
we
have
to
do
this
by
by
stable
yeah.
If
the.
E
F
F
A
Like
if
we
take
this
on
we're,
gonna
like
open
up
a
huge
other
can
of
worms
of
things
that
we've.
F
F
Yes,
sorry,
that's
a
that's
the
thing.
A
F
E
E
F
Correct,
I
think
the
I
I
understand
that
it
it
just
doesn't
make
much
sense
to
stop
the
user
from
creating
meters
directly,
but
not
doing
the
same
thing
for
everything.
F
F
A
A
F
A
Yeah,
but
like
realistically,
like
like
that,
takes
time
right
and
like
like
languages
like
java,
have
implemented
things
that
are
definitely
not
defined,
designing
this
defining
the
spec
right
for
for
velocity
reasons,
because
customers
need
it
right
and
and
because
they
feel
like
it's
the
right
behavior
right.
A
Like
you
know
be,
like
oh
you're,
doing
this
wrong
because
you're
not
following
the
spec
right,
it's
like,
I
don't
know
yeah,
that's
that's!
The
whole
purpose
of
spec
right
should
be
better
yeah.
Okay,
so
in
terms
of
like
moving
this
forward,
should
we
well?
If
anything,
it
is
a
ga
thing
if
we
decide
to
do
it,
so
it's
not
an
rc2
thing.
H
C
Yeah,
so
I
mean,
can
you
hear
me
right
by
the
way?
C
In
java
to
bypass
a
private
constructor,
so
I
think
maybe
a
decent,
a
decent
thing
to
do
would
be
remove
the
constructors
for
these
things
from
our
documentation.
C
A
Do
you,
I
think
I
think
we
could
just
like
leave
this
and
just
like
prioritize
other
tasks
that
make
sense.
Oh.
D
F
A
F
A
C
C
C
No,
no
so
we've
done,
we've
done
the
first
part,
which
is
multi-col.
Sorry,
we've
done
multiple
callbacks
for
an
instrument,
but
we
haven't
done
multiple
instruments
for
a
callback.
Yet
I
think
this
would
be
additive
and
if
I
remember
right
this
spec
just
this
is
like
a
may,
I
remember
right,
but
we
should
definitely
double
check
that.
A
C
H
C
C
Yeah
it'll,
basically
just
be.
The
only
thing
is
remember
that
other
issue
about
you
know.
Exporters
should
be
aware
of
the
metric.
Sorry
be
aware
of
the
aggregation
types
they
support.
If
we
pass
this,
for
instance
like
prometheus
exporter,
it
might
not
know
what
to
do
with
it.
So
that's
that's
the
only
thing
in
terms
of
breaking
changes,
but
I
would
say:
that's
that's
up
to
the
individual
exporters
to
maybe
defensively
check
if
they
can
support
something
right.
A
Yeah
exactly
awesome:
oh
I
haven't
looked
at
examples.
B
A
C
C
E
Way,
I'm
inclined.
F
Yeah,
it's
just
testing
yeah,
okay.
I
guess
it
will
be
kind
of
nice
to
have
that
for
ga,
but
I
think
we
should
just
add
this
at.
A
Least,
yeah:
add
visibility,
cool
erin.
Any
idea
update
about.
E
C
The
callbacks
are
issued
after
the
time
instrument.
Creation
may
be
associated
with
multiple
instruments.
Okay,.