►
From YouTube: 2021-12-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
B
A
Nice
to
see
you
all
fyi,
our
colleague
jacob,
is
joining
aaron.
We
were
just
talking
about
the
gometrix
sdk
fyi.
Everyone
bogdan
wants
to
join
and
talk
about
the
metrics
sdk.
He
sent
a
bunch
of
pr's,
but
it
turns
out
I'm
fairly
certain.
He
was
just
hoping
that
someone
was
working
on
metrics
and
if
we
are
he
will
he
will.
Let
us
do
our
work
he's
going
to
be
here
and
halfway
into
the
meeting
at
1
30..
D
B
Yeah,
I
know
that's
what
I
told
bogdan
when
he
told
me
that
he's
going
to
show
up
a
half
hour
in
I
don't
know
if
we
have
a
half
hour
worth
of
things
to
talk
about,
because
the
only
thing
on
the
agenda
currently
is.
Should
we
cancel
next
week's
meeting?
B
Okay,
so
maybe
we
we
may
just
I
mean
we
could
also
just
reconvene
in
a
half
hour,
but
I
don't
know
if
anybody
else
has
anything
else
to
talk
about.
A
A
It's
sort
of
a
communication
style
of
code
rather
than
words.
Basically
the
the
bulk
of
it
was
if
the
otel
go.
Sdk
had
settled
its
api
now
and
if
those
apis
were
interfaces
the
way
he
expected,
I
mean
there
is
an
interface.
It's
just
one
level
down.
He
could
start
using
those
interfaces
inside
hotel.
The
hotel
collector
without
the
hotel
go
sdk
because
he
could
implement
them
himself.
A
He
could
start
changing
all
the
hotel
code,
hotel
collector
code
to
use
those
interfaces,
but
not
actually
depend
on
the
hotel,
sdk,
and
that
would
accelerate
some
things
for
him
and
from
that
from
that
lens,
I
think
it's
it's
now.
Now
is
definitely
the
time
to
pin
down
our
discussions
about.
Is
this
the
api
we
want-
and
I
think
everyone
at
this
point
has
reached
the
conclusion
that
definitely
something
should
change,
and
my
my
opinion
at
this
point
is
that
the
asynchronous
interface
is
full
of
problems
in
just
terms
of
sheer
code
size.
A
A
That
shuffle
is
going
to
be
painful
alone.
I
think,
and
given
the
other
sort
of
currents
which
are
hey,
we've
looked
at
the
views.
Interface,
aaron
and
I
have
been
having
a
number
of
one-on-ones
to
talk
about
it,
the
views
back
and
what
has
to
change
and
if,
if
you're,
going
to
make
a
major
change
to
shuffle
interfaces,
just
eliminate
sdk
api,
for
stylistic
reasons
and
or
you're,
going
to
change
the
asynchronous
interface.
A
For
stylistic
reasons
now,
the
sdk
is
going
to
change
a
bunch
and
because
of
views
require
some
change
anyway.
Sdk
is
going
to
change
a
bunch.
It's
starting
to
look
like.
Maybe
our
shortest
path
is
to
erase
everything
and
start
with
new
prototypes.
Now
I
don't
say
that
lightly,
because
this
is
a
lot
of
code
that
I
wrote,
but
it
does
start
to
look
that
way
to
me,
and
I
want
to
say
I
don't
want
to
just
blindly
throw
stuff
away.
A
It's
certainly
valuable
code
in
places
and
I
would
keep
pieces
of
it,
but
in
terms
of
the
delta
from
where
we
are
to
where
I
think
we
might
want
to
be
it.
I
don't
think
that
anyone
wants
to
review
the
diff.
I
think
everyone
wants
to
review
a
completely
new
stripped-down,
no
baggage
attached
new
code
base.
A
The
weight
of
evidence
suggests
that
incremental
change
is
not
the
way
to
go
at
this
point,
especially
if
we
haven't
seen
the
end
state.
It
may
be
that
we
we
see
the
end
state.
We
look
at
a
prototype.
We
plan
an
incremental
path
to
get
there.
That's
fine,
but
sending
a
bunch
of
prs
first
is
not
going
to
work.
D
Yeah,
I
I
agree
so
one
of
the
things
that,
oh
I'm
very
sorry,
one
of
the
things
that
I
might
suggest
is
if
we
are
gonna
start
with
a
prototype,
potentially
look
at
just
doing
a
slim
down
version
of
it
like
what
is
the
very
smallest
bit
that
we
need
like.
We
don't
need
to
implement
every
single
meter,
type
type
or
instrument
type
yeah.
D
We
we
probably
could
get
away
with
doing
a
prototype
with
like
a
synchronous
counter
and
an
asynchronous
counter,
or
maybe
a
synchronous
counter
and
a
histogram
like
just
something
as
slim
as
possible.
Yeah
we
can
prove
this
all
out
and
that
a
both
helps
us
keep
our
code
changes
smaller,
but
also
we
can
start
seeing
like
the
patterns
from
the
noise.
A
A
I
don't
want
to
implement
12,
concrete
classes
that
implement
12
interfaces
once
and
then
have
to
do
it
again
inside
the
global
package.
So
if
we're
going
to
not
have
an
sdk
api,
I
totally
agree
with
you.
Let's
just
show
a
counter
and
a
gauge,
because
those
are
synchronous
and
asynchronous
or
whatever
and
and
and
go
from
there.
A
Although
I
do
think
that,
if
we're
going
to
consider
the
future
api
that
we
want
to
settle
on,
looking
at
godoc
is
the
way
to
go,
and
I
think
you
should
see
the
whole
thing
so
I've
been
I've
been
studying
that
a
little
bit.
I
could
try
and
pull
it
up
on
the
fly.
If
anyone
wants
to
see
that
prototype,
I
have.
D
I
I
agree
with
you
there.
We
could
always
just
stub
out
those
whatchamacallits
with
not
implemented
like
a
panic,
not
implemented
yeah.
A
D
I
I
also
think
that,
like
one
of
the
things,
that's
a
very
major
shift
from
like
the
trace
api
versus
the
the
metrics
api,
as
it
is
right
now
is
the
implementation
details
of
a
tracer
and
and
whatnot
are
all
solely
within
the
realm
of
of
the
sck
right.
A
D
Is
but
that's
also
kind
of
more
along
in
the
lines
of
what
we
I
would
expect.
A
a
package
that
lets
me
switch
out
components
to
do
is
to
provide
an
interface
that
it
sees
to
for
its
what
you
call
it,
not
a
concrete
implementation
that
has
an
underlying
interface
somewhere.
I.
A
You
all
win.
It's
cool,
I'm
just
showing
you!
This
is
the
prototype.
I
I
have
if
I
could
rewrite
the
api.
This
is
after
conceding
completely
there's
no
sdk
api
here.
This
is
the
the
metric
package
in
my
branch
and
as
far
as
subdirectories,
there
are
four
corresponding
with
the
cross
product
of
synchronous,
asynchronous
and
integer
floating
point,
and
I
still
have
this
unit
package.
So
the
idea
is
that
you
would
have
the
same
meter
provider
interface.
You
say
you
get
a
meter.
A
The
meter
has,
you
can
tell
it
which
kind
of
constructor
you're
looking
for
you
want
an
async
floating
point
instrument,
you
just
say
meter.async.64.counter
or
whatever,
so
that
here's
the
asynchronous
interface
instrument
constructors,
it's
a
little
bit
more
fluent
in
terms
of,
if
you're
going
to
say,
meter,
dot,
async
float64.counter,
to
get
a
float64
integer
to
get
a
float64
counter,
the
counter
type
and
the
gauge
type
and
the
up
down
counter
type.
These
are
asynchronous
instruments.
They
just
have
one
method.
So
here
are
three
interfaces.
A
A
A
You
execute
the
callback
and
in
the
callback
the
context
is
carrying
whatever
you're
going
to
do,
and
you
make
synchronous
observations
inside
your
callback.
So
to
me,
that's
a
good,
a
good
outcome.
It's
definitely
a
stylistic
choice.
Where
does
the.
A
I
left
that
out
totally
not
connected
with
my
sdk.
There
would
be
a
method
on
the
meter
that
says
new
callback
or
on
the
meter
provider.
Honestly,
the
sdk,
the
sd
specs,
pretty
pretty
vague
one
callback
can
but
you,
but
you
have
to
give
the
instruments,
so
I
think
it
should
be
on
the
meter,
not
the
meter
provider,
so
you
say
new
callback.
You
list
all
the
instruments
that
are
eligible
or
going
to
be
reported
from
the
callback.
A
You
give
a
function
of
a
context
that
returns
an
error
inside
that
function.
You
will
use
your
asynchronous
instruments,
the
ones
that
you
said
you
would.
This
deserves
much
more
exploration.
I
I
wasn't
really.
A
Obviously
it's
not
not
ready,
but
but
the
idea
would
be
that
it's
just
a
callback,
a
function
of
a
context
that
returns
an
error.
I
don't
know
it's
prone
to
misuse.
Potentially
I
mean
everything
is
prone
to
misuse.
Potentially,
I
do
a
lot
of
misuse
of
code
too.
So
anyway,
I
I
I
think
this
is
where
I
would
head
us,
and
I
obviously
this
is
premature.
It's
also
a
holiday
month,
so
we're
not
gonna
get
a
lot.
A
On
anyway,
I
think
what
I
would
propose
is
that
at
least
whitestep
has
now
realized
that
we
are
not
as
close
to
the
finished
sdk
as,
as
I
perhaps
hoped
we
were,
and
this
will
be
something
that
I'm
willing
to
work
on
in
the
coming
months.
C
So
I
think,
coming
at
this
from
the
collector
perspective,
two
of
the
things
that
are
super
important
for
the
collector
and
and
obviously
are
going
to
be
driving
blogden's
concerns.
Are
the
views
api
needing
to
have
that
so
that
we
can
have
histogram
boundaries
that
vary
per
instrument,
because
we
in
the
collector
have
realized
that
it's
obviously
not
going
to
work
for
us
to
have
a
single
histogram
boundary
for
all
of
the
histograms
that
we
have.
C
And
secondly,
how
do
we
configure
the
sdk
one
of
the
the
issues
I've
had
on
my
plate
for
a
while,
and
I've
got
a
pr
that's
been
sitting
around
for
a
while
in
part,
because
I
don't
have
a
good
story
to
tell
about
how
to
configure
the
go.
Sdk
is
moving
the
the
collector's
current
metrics
configuration
from
cli
flags
to
a
config
file
right
other.
C
C
So
without
views
and
without
configuration,
I
think
regardless
what
api
we
have.
The
collector
still
is
going
to
have
some
struggles
using
this
sdk.
A
Yeah
from
my
perspective,
api
is
really
a
small
part
of
this
whole
problem,
like
it's
a
stylistic
decision
that
we
need
to
make
and
the
the
really
hard
part
is
view
configuration
because
I
mean,
for
example,
aaron-
and
I
have
been
briefly
discussing
this
and
when,
when
aaron
pitched
me
an
idea,
it
was
like
there's
going
to
be
a
method.
You
call
to
like
configure
one
selector
of
a
view
or
something
like
that,
and
you
would
put
it
in
there
right
so
that
now
it's
a
programmatic
interface
is
my
point.
A
It's
not
a
yellow
file
and
anthony.
You
just
asked
for
a
yaml
file
which
is
like
taking
it
at
least
two
steps
further
and
the
metrics
sdk
spec,
like
everywhere
else
in
open
telemetry,
doesn't
have
a
spec
for
how
to
do
config.
C
Yeah
for
view
configuration
programmatic
without
yaml
is
probably
fine.
Our
current
open
census
views
are
defined
in
a
file
that
just
in
a
go
file
that
programmatically
creates
a
bunch
of
views,
but
I
think
sdk
export
pipeline
and
processor
pipeline
and
those
sorts
of
things
are
what
we
need
configuration
for,
and
that
applies
to
both
traces
and
and
metrics.
C
We
would
like
to
be
able
to
have
the
collector
configuration
have
in
it.
I
want
to
use
the
jaeger
exporter
for
traces,
and
I
want
to
use
the
open,
telemetry
x,
otlp
exporter
for
metrics,
and
here's
where
I
want
it
to
go
and
have
the
the
collector
be
able
to
build
up
an
sdk
using
that.
A
B
I
mean
I
don't
see
why
you
can
build
on
top
of
a
programmatic
interface,
some
sort
of
file
person.
Oh
sure,.
C
That
in
the
collector
I
I
just
wouldn't
want
to
build
that
intellectual,
because
it's
going
to
be
useful
elsewhere
and
I
don't
want
to
do
it
once
for
go
without
java
and
javascript
and
python,
and
everybody
else
also
being
on
board
as
to
here's,
how
you
should
be
configuring,
an
open,
telemetry
sdk
through
you
know,
yaml
file
or
json
or
whatever.
I
know
this
is
a
conversation.
C
That's
come
up
with
a
spec
before
in
maintainers
before,
but
we
need
broader
configuration
than
just
here's,
a
bunch
of
environment
variables
set
them,
and
hopefully
your
sdk
respects
them.
B
A
Though
the
the
discussion
that
aaron
and
I
had
was
like
literally
a
pseudocode
and
a
slack,
but
I've
started
with
the
prototype,
I
just
showed
you
go
doc,
for
it
would
have
a
an
internal
package
underneath
sdk
metric,
so
sdk
metric
internal
would
have
a
bunch
of
stuff
but
and
then
some
the
public
exposed
methods
would
be
like,
with
view
so
you'd,
say
new
meter
provider
with
resource
and
then
with
you
with
your
view
and
the
view
object
is
subject
to
design
still,
because
I
I
that's
just
not.
A
I
haven't
gotten
that
far
it,
but
it's
going.
I
mean
it's
going
to
be
very,
very
close
to
the
metrics
data
model
like
there
are,
there
are
attributes
getting
removed
and
then
there's
aggregation
being
applied,
and
there
are,
you
know
various
predicates
here
and
there.
A
A
This
this
view
and
metrics
is
roughly
the
equivalent
of
the
setting
up
a
processor
and
a
sampler
okay,
and
that
what
I
think
is
interesting
to
me
is
that
the
the
the
scope
of
the
project
open
telemetry
trace,
has
this
much
scope
for
view
configuration
of
trace
and
has
this
much
scope
for
view
configuration
of
metric
and
we
haven't
done
metric
yet
so
it's
still
very
experimental,
but
if
we
do
finish
metric
someone's
going
to
come
along
and
ask
for
it
for
trace,
but
for
the
for
the
moment
it's
just
options.
A
And
I
don't
know
exactly
what
the
words
or
the
the
methods
are
gonna
look
like
yet.
B
Okay,
yeah:
it's
I'm
with
you
on
this
idea
that,
like
if
things
are
going
to
change,
though
just
by
kind
of
backing
it
up,
I'd
want
to
have
it
motivated
that
that's
definitely
something
because
the
last
thing
we
want
is
something
we've
seen
where
we
decide
to
go
in
different
direction
that
we
realize
later
on,
that
that
was
not
the
best
idea
and
then
go
back
to
the
original
yeah.
I.
A
Could
see
an
intermediate
like
for
the
sake
of
the
project
like
there
are
people
using
this
sdk
and
the
only
thing
I
want
is
it
sends
otlp
and
I
have
an
interface
and
I'm.
I
know
that
the
interface
the
api
is
going
to
change,
but
I
I've
got
my
otlp
and
I'm
happy
with
it.
So
so
one
change
would
be.
We
we
review,
we,
we
discussed
motivation
for
changing
the
api.
A
Take
the
sdk
api
private,
take
the
number
package
private,
put
them
in
under
sdk
metric
or
inside
an
internal
package,
and
then
just
band-aid.
The
situation
like
yeah,
I'm
changing
the
api.
The
sdk
is
going
to
need
some
fixes
and
we'll
get
to
the
point
where
the
api
is
finalized.
The
sdk
is
still
a
mess,
but
it
produces
otlp
and
if
you
scrape
it,
you
can
get
prometheus
and
like
if
you
had
it,
working
it'll
still
keep
working
like
jacob's
using
it.
A
For
example,
then
we
can
release
that
and
then
we
can
fix
the
sdk
and
add
views
in
a
separate
work
piece
of
work.
But
there's
gonna
be
some
churn
in
there.
That's
just
like
the
cost
of
doing
business.
B
I
I
have
mixed
feelings
on
how
much
that
trade,
because
there's
a
lot
of
train,
I
think,
to
the
developers
as
well
as
to
the
users,
but
I
I
don't
know,
like
the
users,
there's
a
pretty
old
red
flag,
saying
that
it
isn't
really
tested.
It's
not
released
to
stable
this
alpha
code.
A
A
That's
what
we're
intentionally
gonna
break
at
this
point
like
we're,
gonna
we're
gonna
one
last
change
the
api
here,
if
you're,
if
you're
using
the
export
internal
export,
you
know
the
sdk
metric
export
or
the
sdk
export
metric,
whatever
it's
called,
if
you're
using
that
package
and
you've
got
a
custom
exporter
or
a
custom
aggregator
or
something
like
that,
we
probably
know
who
you
are
and
what
you're
doing
and
you
might
be
in
the
contrib
package
and
we
can
probably
take
care
of
those
situations
ourselves.
A
But
I
wouldn't
expect
that
we
need
to
do
any
changes
of
the
constructors
for
the
sdk,
meaning
you'll,
still
you'll
wire
things
up.
The
way
you've
always
been
doing
and
and
the
new,
the
the
constructors
for
the
controllers
and
the
processors
and
all
that
stuff.
Won't
change
in
this
particular
it'll
just
be
eliminating
the
sdk
api
directory
and
changing
the
api
and
mandating
the
connections
behind
the
apis.
B
A
It
is
definitely
relitigating
and
I'm
I'm
kind
of
being
slayed
by
aaron,
who
gave
me
a
little
bit
of
discussion
on
this
and
bogdan
coming
in
so
fiercely
against
it.
I
don't
care
to
fight
this
one
anymore.
A
D
D
I
don't
know
how
much
like
I'm,
not
a
big
fan
of
like
big
apis
that
are
just
you
know,
remove
sdk
and
change
our
sdk
api
and
change
it
to
metric
like,
but
we
can
at
least
verify
those
pretty
programmatically
which.
A
Hi
we
had
nothing
else
to
talk
about
in
this
hour
bowden,
so
we
just
started
talking
about
metrics.
I
guess
this.
I
may
I
give
a
summary
of
our
conversation.
I
think
so
we
talked
about
how
this
sdk
api
interface
is
one
below
the
user
level
interface
and
how
some
people
find
that
surprising.
I
think
you're
in
that
category,
bogdan
aaron
put
himself
in
that
category.
E
A
Put
inside
the
sdk,
yes,
that
that's
understood
the
the
other
sort
of
two
main
points
that
were
discussed
here
is
that
there.
This
is
like
the
chance
is
now
to
to
make
final
up
final
changes
to
the
the
metrics
api,
and
I
think
a
lot
of
us
have
looked
at
the
package
and
said.
Oh,
this
is
too
much
there's
too
much
here.
A
Let's
simplify
and
so
there's
a
like
moving
things
around
for
the
synchronous
instruments,
but
when
it
comes
to
the
asynchronous
instruments,
there's
like
a
lot
happening
there
and
we
need
to
reduce
it,
and
I
think
my
proposal
would
be
that
we
keep
the
the
batch
asynchronous
interface
but
in
any
case,
that's
a
change,
a
change
of
interface
for
the
asynchronous
instruments
that
we
might
be
considering.
A
The
change
is
going
to
be
large
and
it
gets
to
be
it's
worth,
considering
whether
we
should
just
start
from
scratch
and
keep
what
was
worth
keeping
and
and
just
like
look
at
a
new
prototype.
I
think
that's
what
we've
been
discussing.
I
don't
think
we
have
enough
evidence
either
way
right
now,.
A
Are
subject
to
debate
so
in
the
the
one
of
the
kind
of
performance
notes
that
came
has
come
up
here?
Is
that
the
like
the
runtime
metrics
package?
Has
this
read
memstats
call
which
is
very
expensive,
and
then
it
wants
to
output
a
bunch
of
bunch
of
asynchronous
metrics.
So
that's
that's
the
reason
why
I'm
motivated
to
keep
that
like
the
bulk,
the
batch
observer
interface,
but
I
don't
like
the
way
it's
been
done.
I
I
want
to
throw
it
all
away
and
I've
been
thinking
of
a
new
interface.
E
B
That's
a
statement
I'm
not
comfortable
with,
so
this
is
something
that
we
need
to
get
right
because
we've
talked
about
it
twice
already
before
in
the
sig
meeting
and
if
we
decide
to
go
in
a
different
direction
like
we
need
to
have
good
motivation
to
do
so.
B
So
I
I
would
like
to
be
very
sure
that
we
understand
why
we're
making
a
change
removing
an
api,
that's
based
around
structs
and
going
to
an
interface.
A
A
To
discuss
right
now,
I
think
tyler's
right
we
should.
We
should
not
be
so
hasty,
especially
because
we
litigated
this
once
already,
but
it
is
something
that
I'm
I'm
not
ready
to
fight
about
anymore.
So
we
can
do
that.
I
have
mentioned
two
other
issues.
One
is
a
desire
to
change
the
api
in
general,
especially
for
asynchronous
instruments
and
a
recognition
that
some
stuff
has
to
change.
On
the
on
the
sdk
side
and
one
of
the
people
here
jacob
is
my
colleague
at
light
staff.
A
He
has
tried
to
use
it
and
just
ran
into
problem
after
problem,
so
we
we've
got
some
problems,
recognized
on
the
sdk
side
and
when
you
start
looking
at
changes
on
both
sides
of
this
boundary
like
it's
starting
to
look
like
a
rewrite
to
me.
However,
just
before
you
arrived,
I
said,
but
rewrites
that's
dangerous
on
in
its
own
right.
We
can
find
a
way
to
be
incremental.
A
E
I
think
that's
right.
I
think
that
matches
with
the
current
state
of
specification
as
well,
which
is
api,
is
marked
as
stable.
So
I
think
we
should
have
a
goal
to
ship
our
api
into
the
same
one,
something
113
114,
whatever
it's
gonna,
be
the
next
version
of
the
the
the
api
package
that
includes
tracing.
So
I
think
one
of
the
gold
can
be
simply
as
let's
polish
the
api
as
much
as
we
can
make
it
the
the
best,
as
we
can
to
to
the
api
and
then
on
a
separate
track.
E
There
is
the
sdk
work,
which
is
which
can
be
done
incrementally
or
can
be
done
as
a
completely
derived.
Personally,
I
would
like
an
incremental
approach
more
because
we
keep
things
working
and
we
can
get
things
testing
more
sooner
than
later.
Instead
of
waiting
three
months
to
have
the
first
test,
we
can
continuously
testing
our
implementation
and
our
improvements.
A
Yeah,
I
that's
kind
of
the
reason
why
I
wanted
to
keep
the
sdk
because
it,
although
it's
imperfect
it
is
it
is
functional.
Basically,
I
think
we
don't
have
enough
work
done
yet
to
to
to
share
a
actual
proposal.
A
I
mean
I
put
up
a
go
doc
and
I
I
could
type
out
some
examples
of
what
I'm
saying,
but
I
don't
think
it's
ready
to
share
quite
yet,
but
I
think
the
consensus
in
this
group
is
that
we
should
begin
to
focus
on
finishing
the
api,
removing
the
sdk
api
if
tyler
agrees
or
not
separate
questions,
but
but
but
with
or
without
the
sdk
api.
The
asynchronous
interface
is
a
huge
problem
and-
and
it's
too
too
much
code
too
much
interface.
E
So
should
we
should
we
focus
on
the
api,
because
this
is
my
main
interest
fyi.
My
motivation
is
clear.
I
want
to
switch
to
use
this
one
in
the
collector
and
because
I
want
to
switch
it
the
way
how
we
will
expose
this
to
the
user.
E
A
E
No,
no,
we
don't
have
any
problem
yet
okay,
but
but
we
need
we
just
need.
As
I
said,
we
need
a
stable
api
in
order
for
me
to
to
be
able
to
to
start
recommending
these
to
the
users
and
that's
why
my
motivation
of
trying
to
clean
up
as
much
as
I
can
api
to
to
make
that
one
zero
or
not
one
zero,
whatever
it's
gonna,
be
because.
A
I
was,
I
was
showing
this
at
the
beginning
of
the
meeting
I
the
this
is
after
I
showed
you
yesterday
bogan.
This
is
the
one
where
I've
eliminated
sdk
api,
so
the
the
thing
I'm
I'm
concerned
is
more
of
a
stylistic
thing
is
that
I
so
here's
an
async
counter
and
its
method
is
observe,
but
it
has
the
same
signature
as
a
synchronous
instrument.
It
takes
a
context,
you
give
it
an
argument
and
some
attributes.
A
The
idea
is
that
there's
a
callback
that
you
just
execute
and
and
then
you
just
it's
like
using
a
synchronous
instrument,
so
definitely
stylistic,
I'm
gonna
make
this
proposal.
I
will
write
this
up
for
next.
You
know
the
next
meeting,
I'm
not
sure
when
the
next
meeting
is,
but
I
think
that
and
and
then
problem
is,
I'm
I'm
only
going
to
make
one
proposal,
because
this
is
the.
A
And
if,
if
we
need
to
have
a
debate
or
make
more
proposals,
other
people
should
be
doing
this,
so
I
don't
know
I
guess
I
would
like
to
starting.
Maybe
after
this
meeting
the
rest
of
the
day,
sometime
I'll
start,
an
issue
saying
consider
revising
asynchronous
interface,
which
is
really
just
to
focus
on.
What's
the
callback
structure
look
like
and
how
do
you
register
it,
which
is
different
than
the
like?
What
about
moving
things
around,
so
I
you
know,
I
created
this
package.
Async
64..
Is
that
the
right
answer?
E
Are
we
okay
to
to
exit
to
do
this
in
parallel
with
so
so
there
is
that
this
is
the
polish
of
the
car
things,
but
there
is
a
bigger
discussion
that
we
need
to
to
answer,
which
is
interfaces
versus
struts
correct,
like
I
would.
A
E
A
Yes
sounds
like
three
issues
at
this
point:
make
a
decision
about
sdk
api,
make
a
decision
about
the
form
of
the
interface
overall
and
then
making
interface
decisions
about
the
a-secrets
interfaces,
in
particular
related
to
callbacks
and
calling
conventions.
E
Should
we
have
three
different
issues
and
maybe
track
them
separately?
Yep.
E
A
E
Or
one
of
us
can
file
three
issues.
I
can
file
the
three
issues
and
link
them
to
the
main
one
that
I
created
as
one
zero
release
issue,
which
is
an
umbrella
for
for
everything
that
okay,
if
you
want
to
make
those
three
issues
I'll
be
glad
to
follow
up
with.
A
My
thoughts
on
each
one
of
them,
okay,
and
if
we
want
to
discuss
sdk
api
in
person,
we
can
do
it,
but
I'm
not
sure
I
feel
like
we've
done
this
before.
E
A
A
E
Okay,
let
me
let
me
tell
you
my
motivation
of
how
I
saw
this
as
a
user
when
I
started
using
this,
so
I'm
here,
like
literally,
I
tried
to
use
this
in
collector,
and
I
I
saw
this
and
confused
me
as
a
hell
like
why
the
heck
I'm
curious
about
impul
or
or
do
I
need
to
see
the
input.
That
was
one
thing.
The
other
one
was
even
though
sdk
api
may
be
documented.
E
E
To
be
honest,
I
understood
quickly
enough
that
hey.
This
is
not
for
me
as
a
user
of
this
api,
but
still
was
a
lot
a
lot
of
api
like
there.
There
was
a
lot
of
of
surface
there.
These
are
kind
of
my
main
two
pro
problems
with
the
current
approach
and
and
then
I
I
try
to
to
resonate
and
to
understand
why
structs
are
better.
E
Structs
usually
are
better
because
you
avoid
interfaces
for
for,
like
things
like
allocations,
you
can
avoid
and
avoid
multiple
things,
but
that's
not
the
benefit,
because
even
in
all
these
tracks,
you,
you
always
have
a
interface.
So
so
you
always
gonna
have
an
interface
function
called,
which
is
a
v
table,
lookup
and
stuff.
So
you
always
gonna
have
that
even
with
the
current
approach
and
you're
always
gonna
have
an
allocation
for
that
interface.
So
I
don't
see
also
the
performance
impact
here,
not.
A
A
performance
not
a
performance
thing,
though
this
was
about
reducing
the
code
impact
of
having
12
interfaces
that
have
to
be
implemented
at
least
twice
in
one
code
base,
and
I
say
at
least
twice
because
the
global
package,
which
you
you
honed
in
on
as
being
a
reason,
is
that
you
you
you
have
to
implement
each
instrument
once
inside
the
sdk
proper,
and
then
you
have
to
implement
this
deferred
thing
once
inside
each
for
the
global,
and
it's
that
cost
that,
like
that,
you
share
one
struct
gets
used
by
two
implementations,
even
in
your
one
code
base.
E
Perfect,
anyway,
tyler,
I
would
like
to
hear
your
opinion,
because
you,
you
have
a
good
point,
that
this
was
discussed
and
and
we
should
not
simply
remove
things
just
because
I
came
here,
and
I
I
found
that
very
confusing.
For
me.
B
No,
I
yeah,
and
I
I
don't
think
that
we
shouldn't
not
also
move
things
if
we
have
good
reason.
I
just
want
to
make
that
clear
as
well,
but
I
just
want
to
make
sure
that
we
have
clear
and
understand
like
what
that
reason
is,
I
think,
is
really
important
because
to
josh's
point
like
he
designed
this
api
with
the
anticipation
that
it
removes
a
lot
of
complexity
and
we
beforehand,
I
think
it's
three
implementations,
but
maybe
it's
just
two
implementations
that
we
have
within
our
code
base.
B
B
The
things
that
they
would
have
to
implement
also
gets
reduced
if
you
use
this
sdk
package,
so
I
think
there's
that
point
which
has
already
kind
of
been
made,
but
the
only
other
thing
that
I
would
probably
point
out
is
that,
while
performance
issues
are
not
probably
going
to
be
realized,
given
the
fact
you
have
to
make
an
allocation
for
the
interface,
the
versioning
could
be
the
s.
The
structures
can
be
extended
quite
well
in
backwards,
compatible
ways
and
the
api
that's
built
on
interfaces
it.
B
It
technically
can
because
we've
built
it
into
our
versioning
compatibility
guidelines
that
these
interfaces
are
going
to
break
essentially.
But
if
you
just
have
structs,
you
don't
have
to
make
those
kinds
of
like
backhand
things
it's
built
into
the
language
that
it
can
be
forward
compatible.
There's
another
point
that
I
would
probably
make.
E
Yeah,
the
other
or
the
on
the
other
side,
a
downside
of
having
implementation
shipped
into
the
api,
which
may
not
be
the
case
for
for
going
for
the
way
how
go
works,
but
in
in
other,
compiling
in
other
languages.
Maybe
a
problem
is
the
fact
that.
A
I
I
have
another
concrete
type
of
example
in
the
in
the
pro
category.
I
think
so.
There
has
been
a
discussion,
that's
tangential,
but
it's
also
related
about
performance
and
we
we've
removed.
Let's
say
we're
going
to
remove
the
record
batch
method.
The
record
batch
method
had
one
advantage,
which
was
that
whatever
cost
is
paid
to
to
manipulate
the
attribute
set
in
order
to
compute
uniqueness
is
paid
once
for
the
set
of
observations.
A
If
we
do
away
with
record
batch,
it
looks
like
it's.
It
may
raise
costs
for
a
particular
couple
of
use
cases
that
I'm
aware
of
and
jacob
on,
the
call
has
one
of
them,
and
maybe
that's
not
necessary.
I
guess
so.
One
thing
we
could
do
is
change
the
sdk
api
to
support
like
a
processed
attribute
set
and
then,
like
tyler,
said
we
can
change
the
api
of
each
individual
struct
to
offer
different
options
like.
A
But
the
user
api
does
not
change
because
you
just
added
a
method.
Instead
of
changing
an
interface.
B
It's
it's
thinking.
You
were
bogged
and
said
prior
to
that
one.
I
don't
want
to
dismiss
your
comment.
Josh.
I
think
that's
an
important
thing
and
I've
captured
it
in
the
notes,
but
the
functional
fix
to
code
could
require
an
api.
Upgrade
is
a
problem
if
people
have
instrumentation
and
it
has
an
api
version,
you
know
1.2
and
there's
a
bug
in
the
implementation
details
and
how
we
abstract
to
the
implementation
and
they
have
to
upgrade
the
api
to
1.3.
B
I
mean,
if
you
have
an
sdk
external
to
that,
there's
really
no
way
for
you
to
like
abstract
the
bug
fixed
right
like
you
can,
because
the
implementation
is
not
in
the
sdk
anymore.
An
sdk
author
has
no
control
over
that
anymore.
It's
just
purely
an
api
book.
B
C
I
don't
know
that
that
would
be
an
an
issue
for
us
is
your
assumption
that
if
say
an
instrumentation
library
is
using
api,
1.2
and
there's
a
bug,
and
it
needs
to
update
to
1.3
that
the
user
would
have
to
update
that
instrumentation
library.
I
don't
think
that's
the
case
as
long
as
we
maintain
api
compatibility,
the
application-
that's
including
that
will
or
can
say
I
need
api
version
1.3
and
the
go
module
dependency.
B
B
C
E
Anthony
the
problem
here
is,
if
I'm
having
an
alternative
sdk,
let's
assume
splunk
sdk,
which
is
different
than
open,
telemetry
sdk
you.
If,
because
you
have
implementation
in
the
open,
telemetry
api
you
if
I
have
a
user,
I
cannot
fix
only
on
my
sdk
thing.
I
have
to
come
to
to
this
api,
which
may
get
slower
releases
and
stuff
compared
with
with
my
very
agile
implementation
stuff.
So
so
you
are
tying.
You
are
tying
me
to
the
api
is
more
than
I
need
to
be
tied
as
a
sdk
provider.
E
Again,
I'm
not
using
the
open,
telemetry
sdk,
I'm
having
my
own
smarter
than
open,
telemetry
sdk,
whatever
reason,
but
I'm
just
saying
like
you,
you
are
connecting
me
to
to
this
artifact
more
than
I
need
to
be
connected
to
by
putting
implementation
into
the
into
the
artifact.
Does
it
make
sense.
C
Yes-
and
I
think
that
that
was
a
trade-off
that
we
had
decided
was
valuable
as
well,
because
it
also
saves
that
sdk
author
implementation
of
a
considerable
interface
surface,
we
don't
have
any
sdk
authors
around
to
tell
us
that
they
want
this
trade-off
or
not.
When
we
discussed
this
the
last
time,
we
thought
for
our
own
purposes.
C
That
was
a
good
trade-off
and
we
thought
it
would
be
valuable
to
sdk
authors.
I
think,
if
we're
coming
along
and
saying
that,
no,
maybe
that's
actually
bad
calculus,
that's
fine!
Let's!
Let's
have
that
conversation.
We
could
be
wrong.
We
could
have
been
wrong
when
we,
when
we
made
that
decision
initially,
but
I
think
that
that
was
in
order
to
provide
a
benefit
to
the
sdk
author
and
yes,
they.
They
then
have
to
take
the
flip
side
of
that.
C
E
Yeah
but
but
let's
assume
in
an
ideal
world
in
two
years,
api
will
get
super
stable
in
general,
like
very,
very
slow
releases
in
general,
because
everything
is
stable.
People
are
happily
using
the
api
most
of
the
changes,
and
improvements
will
be
on
the
sdk
side
correct,
so
so
somehow
that
that
doesn't
resonate
with
me
with
with
this
separation.
E
D
I
actually
take
exception
with
that,
because
the
open,
telemetry
specification
specifically
calls
out
that
they
can
add
methods
to
a
interface
list
as
an
acceptable
change
which
is
stable
for
them.
So
it
is
perfectly
acceptable
for
that
to
change,
but
our
interfaces
would
then
break
because
goes.
Compatibility
is
different.
D
So
if
we're
willing
to
live
with
that,
I'm
that
that's
sort
of
the
trade-off
that
we
have
there
is
the
api,
the
sdk
api
or
maybe
more
specifically,
the
metrics
api
is
not
necessarily
complete,
and
I
would
very
much
expect
like
views
to
be
specified
in
the
next
year
or
so,
and.
D
C
I
think
that's
one
of
the
benefits
we
get
out
of
having
an
actual
concrete
implementation
for
the
api.
I
I.
E
B
Fair
for
disease,
what
I
think
that's
a
good
idea,
yeah.
I
think
I
think
we
can
live
in
both
worlds.
Like
kind
of
like
what
you're
saying
I,
I
I'm
scared
of
a
large
amounts
of
computational
implementation
in
the
sdk
api
right
now,
for
that
exact
reason,
but
I
do
think
that
there's
benefits
to
having
a
struct
wrapping
things.
So
maybe
we
could
try,
like
I'm
also
not
sure,
but
I'm
pretty
sure
it
was
like.
It
was
open
census
that
had
this,
where
it
wrapped
things
in
like
a
concrete
implementation,
yeah.
E
We
had
this,
we
had
this,
but
one
of
the
main
reasons
I
was
talking
to
josh.
One
of
the
main
reasons
to
do
this:
merge
between
open
sensors
and
open
tracing
and
one
of
the
the
requirement
of
the
merge,
was
to
clearly
have
this.
What
they
called
big
hook,
essentially
to
be
able
to
replace
entire
implementation
in,
in
a
case
in
case
of
a
mistake
in
case
of
something
there
was
a
clear
need,
and
one
of
the
requirement
of
the
open.
The
telemetry
project
was
to
offer
this
big
hook.
E
They
call
it
big
hook,
because
essentially,
we
were
saying
in
open
senses
coming
from
what
is
that
we
offer
hooks
to
to
to
to
tune
different
things,
and
they
were
like
no.
No.
No.
We
want
the
big
hook
like
replace
everything
so
that
that
was
one
of
the
the
requirements
for
from
open
telemetry
which
somehow
us
coming
from
opposition.
We
we
accepted
it
and
we
have
to
embrace
it
and
and
move
forward
with
that
decision,
because
that
would
yeah.
We
may.
B
And
I
think
we
can
still
provide
that
kind
of
like
what
we
just
described.
We
can
provide
that
like
that
big
hook,
but
you
can
still
wrap
you
know
that
external
surface
and
the
concrete
implementation-
I
I
think,
there's
a
way
to
solve
this,
and
I
think
that
we're
kind
of
agreed
on
the
fact
that
maybe
taking
implementation
out
of
the
sdk
api,
everyone
on
the
call
at
lisa,
I
think,
is
agreed
upon
that.
That's
probably
a
good
idea,
if
I'm
not
mistaken,.
B
Yeah
agreed,
okay.
Well
said
we
do
need
to
come
to
some
sort
of
resolution,
even
though
things
aren't
fully
resolved.
Given
we
have
two
minutes
left
and
I
don't
want
to.
I
want
to
be
respectful
people's
time,
so
I
think
if
that
sounds
good,
I've
got
action.
Items
bogdan
is
going
to
create
the
three
issues
to
track
these
things.
I
I've
kept
a
minimal
amount
of
notes
in
the
the
go
notes.
I
don't
know
bug
if
it
would
be
helpful.
Maybe
those
are
useful.
B
You
can
reach
out
to
me
if
you
need
them,
but
I
think
that,
like
capturing
I'll
try
to
capture
also
that
what
we
just
said
that
we
should
try
to
keep
the
minimalist
implementation
sdk
or
remove
it,
and
then
I
think
talking
about
the
structs
wrapping
for
the
api.
We
can
continue
on
if
that
would
maybe
a
minimal
implementation
on
top
of
it.
But
I
think
josh
and
bogdan
both
have
two
proposals
coming
down
the
pipe.
I'm
not
mistaken,.
E
Nah,
I
don't
think
our
proposal.
I
think
our
proposals
are
orthogonal.
Jewish
proposal
is
more
or
less
to
tune
this
public
api
in
a
way
that
is
more
performant,
more
more
natural
for
users.
My
mine
was,
I
didn't
change
anything
on
the
api.
I
just
made
them
interface,
so
I
I
didn't
make
any
api
change
in
my
proposal,
so
mine
was
mostly
related
to
this
sdk
api
discussion.
B
E
B
D
We
we
can
have
a
talk
after
this.
Just
I'm
willing
to
say
I
just
don't
want
to
hold
anybody
else
up
so.
B
Yeah,
I'm
I'm
the
admin
on
this
zoom.
All
of
a
sudden.
I
don't
know
how
to
relinquish
that,
so
I'm
gonna
have
to
end
the
meeting
when
I
leave,
but
I
think
if
you
leave,
you
should
be
able
to
let
it
keep.
C
B
Or
oh,
really:
okay,
okay,
cool!
Well
then
I
can
do
that
as
well.
It's
also
recording
so
just
a
heads
up
on
that
one
I
mean,
but
yeah
you
can.
D
B
All
the
trash
you
want
about
me
after
I
leave
so
I'll.
Just
look
at
the
recording.
Well,
everyone
thanks
for
joining
and
we'll
see
you
all
very
quickly
cancelling
the
meeting
for
next
week
but
next
year.
So
thanks
thanks
all
all
yeah.
Thank
you.
E
D
So
what
I'm
trying
to
to
say
here
is,
I
don't
think
the
problem
lies
with
the
no
op
instrumentation.
I
I
mean,
like
that's,
that's
kind
of
a
somewhat
orthogonal
fix
to
that
the
test.
The
test
is
really
pointing
out
that
we
can
panic,
even
though
we
shouldn't
mostly
because
we
have
unchecked
typecasts
no.
E
So
so
what
I'm
trying
to
say
is
the
following,
because
we
have
structs
and
we
control
the
implementation.
We
guarantee
correct
based
on
the
right,
the
current
implementation,
because
this
this
cannot
come
from
nowhere
based
on
the
public
api.
This
is
our
implementation
correct
and
we
guarantee
that
for
a
specific
kind,
we'll
have
this
type.
D
Of
I'm
not
100,
convinced
of
that
I
I
was
looking
through
the
api
right
now,
but
if
what
is
the
cost
of
having
just
an
additional
type
check?
Just
so
that
we
can
guarantee
this
because
in
the
overall
larger
project?
That
might
be
this
the
case,
but
we're
not
like
we
don't
have
any
kind
of
documentation
that
that
is
actually
guarded
here
right
within
within
just
the
scope
of
this
package.
D
The
input
is
a
description.
The
output
is
a
interface
and
then
we
have
a
type
check.
An
un
unguarded
cast.
E
E
D
D
That
is
not
a
hundred
percent
all-encompassing.
E
E
D
But
like
I
would
probably
be
okay
with
that,
I
I
don't
know
if,
like
no
ops
should
return
something,
but
I
don't
know
if,
like
counter
is
the
appropriate
thing
or
counter
observer
for
the
async.
I
picked
one
got
one
up
at
random:
oh
yeah,
yeah.
C
D
C
D
Yeah,
like
we're
getting
way
way
into
the
detail
of
the
registry
and
how
the
registry
is
implemented,
and
what
I'm
saying
is
that,
like
the
test
is
on
the
registry
and
the
test
says
that
you
can
have
a
descriptor,
and
I
chose
the
no
op
as
as
an
option
one,
because
that's
a
pretty
easy
one.
I
could
have
just
did
a
new
descriptor
with
the
same
name.
E
If
you
do
a
new
descriptor
you'll,
never
hit
that
you
will
never
be
able
to
reproduce
that
bug,
because
if
you
use
the
public
api,
the
public
api
based
on
the
implementation
will
never
be
able
to
hit
that
bug.
So
you
have
to
write
your
custom
theme.
You
cannot
use
our
public
api
to
test
against
that.
E
D
I
get
that
like
I
get
this,
but
the
the
the
main
problem
I
see
is
in
the
future
like.
Realistically,
this
is
a
check
of
like
this
is
not
a
full
encompassing
check,
and
I
think
it
should
be
for
appropr
for
people
who
stumble
into
this
in
the
future.
Like
say
that
we
like
we
decide
that
our
descriptor
is
not
not
complete
enough
and
we
don't
update
the
the
compare
there
like.
D
E
E
Also
sorry,
one
last
thing
which
frustrated
me
just
and
I'm
very
direct
the
thing
that
frustrated
me
was
I
I
send
a
pr
that,
as
it
says,
just
improve
readability
and
stuff
and
as
a
result,
it
improved
readability,
because
you
saw
this
problem
much
clearer
and
you
block
it
for
an
existing
bug,
yeah,
but
I
mean
which,
which
personally
I
would
just
create
an
issue
or
ask
the
person
hey.
Can
you
create
an
issue
for
this?
Because
this
was
not
touching
that
logic
like.
D
D
E
D
But,
like
I
said,
did
I
actually
block
that?
If
I
did,
I
didn't
mean
to
I
just
I
think
yeah,
oh.
D
D
So
I'm
asking
like
hey,
this
doesn't
seem
like
it's
going
to
be
a
large
scope
increase.
Let's
fix
this
problem
right,
because
I
don't
I
see
this,
as
you
know,
reorganization,
not
as
adding
new
features
or
something
like
that.
So
if
we're
gonna
be,
you
know,
cleaning
up
our
space,
let's
clean
up
our
space,
let's
clean
it
all
up
right
sure,
but
like
I
I
I
could,
but
I
like.
I
really
do
think
that,
like.
A
E
D
So
so
so
we
have
guarantees.
So
my
my
argument
to
that
is:
we
have
guarantees
right
this
minute
by
the
time
we
change
this,
and
we
we
go
through
this.
I'm
not
100
certain
that
those
guarantees
are
going
to
still
be
there
and
we
don't
have
tests
in
any
way
shape
or
form,
and
I
don't
even
know
if
we
could
have
tests
to
say
that
the
only
way
to
create
this
is
through
internal
apis
right,
that's
sort
of
a
testing
of
something
that
doesn't
exist
versus
testing,
something
that
does
exist
right.
D
But
if
that's
the
case
like
there
needs
to
be
some
documentation
around
the
idea
that
if
you
misuse
this,
you
misuse
it
right
like.
But
it's
not
it's
not
very
apparent,
because
it's
fairly
simple
to
create
a
descriptor
that
that
would
internally
blow
up.
E
Okay,
so
again,
I'm
not
maintaining
this
code,
it's
whoever
is
maintaining.
I'm
I'm
just
gonna
give
that
to
you.
If
that's
the
case,
but
again
I
told
my-
I
told
you
my
problems.
I
don't
think
this
was
anything
related
to
so
so
it
shouldn't
be
anything
in
this
pr
related
to
that.
E
D
But
I
find
a
lot
of
that.
We,
we
have
a
lot
of
baggage.
In
that
sense,
I
I
100
understand,
and
I
I
don't
mean
to
push
that
off.
I
was
like
the
my
big
issue
that
I
had
with
the
flurry
of
prs
was
that
they
all
came
in
roughly
the
same
amount
of
time
together.
D
For
me,
I
don't
review
them,
as
you
know,
immediately
as
they
come
in
right,
I've
tried
to
batch
them
all
up,
and
I
saw
changes
that
were
somewhat
interrelated
and
somewhat
not,
and
I
couldn't
tell
how
independent
they
were
as
a
whole.
D
E
Don't
don't
get
me
wrong
because
I
identified
that
you
actually
had
a
bug
here,
which
I
believe
it's
still
about
the
the
fact
that
you
are
seeing
that
the
knob
asynchronous
instrument
returns
the
kind
histogram
which
is
unexpected
yeah.
D
I
want
to
say
at
least
thank
you
for
like
putting
some
code
to
paper.
I
guess
go
to
the
thing
and
starting
these
discussions
like
this
is
a
large
project
and
just
having
something
that
the
metrics
as
a
whole
is
a
large
project
and
just
having
some
kind
of
push
in
one
way
or
another
is
refreshing.
D
D
D
Oh
yeah,
I
mean,
I
also
found
that
I
think
you
commented
on
the
the
histogram
was
using
an
exact
type,
which
was
also
a
leftover
there's.
E
C
C
It
also
had
three
approvals.
The
the
purpose
of
the
the
24-hour
rule
is
to
give
people
a
chance
to
to
look
at
it
and
given
that
it's
coming
from
a
maintainer
had
approvals
from
the
other
two
maintainers
and
the
person
who
is
off
time
zone
from
us
had
viewed
it
overnight.
Oh
I
see,
I
think
I
thought
that
that
had
satisfied
the
give
everybody
a
chance
to
object.
If
they're
gonna
objection.
C
Yeah
in
in
the
processor
test,
it
looks
to
the
instrument
name
suffix,
to
decide
what
sort
of
aggregator
to
say
it
is
and
that's
why
that
was
failing
and
why
that
change
is
fixed.
D
I
I
was
confused
when
I
read
benchmarks
and
it
failed
very.
C
D
D
Yeah,
I
don't
think
we
run
benchmarks
on
on
anything
honestly
like.
I
know
we
do
test
and
test
race
and
coverage,
but
I
don't
know
if
there's
benchmarks
anywhere,
which
I
like
I
I'm
of
two
minds
on
in
particular.
D
While
I
would
appreciate
them,
we
need
some
way
of
visualizing
the
changes
and
make
them
impactful.
Otherwise,
there's
just
code
that
we're
executing
for
no
real
value
or
very
minimal
value.
D
D
D
So
the
if
you
look
at
the
pr
I
it
told
me
pretty
clearly
where
it
failed
is
that
it
failed.
It
failed
within
that
test
and
or
within
that
that
block
of
code,
where
anthony
highlighted
and
and
and
I
noticed
that
there
was
no
exact
like
it-
was
exact
and
there
was
no
longer
an
exact
and
I'm
like
something's
going
on
here.
Something
needs
to
change,
and
then
you
know
kind
of
doing
a
little
bit
of
sleuthing.
E
D
I
would
be
okay,
so
I
would
be
okay
like
if
merging
the
the
instrument
kind,
because
that
does
in
some
ways
shape
or
form,
makes
sense
and
then
fixing
the
bug
within
either
one
like
realistically
we're
talking
about
a
two-line
change
here.
So
if
it's
part.
E
D
C
No,
I
we
just
kind
of
echo
what
what
are
inside
and
thank
you
for
creating
these
prs
and
reigniting
this
discussion.
My
big
concern
was
that
they
appeared
with
little
or
no
context
and
or
no
understanding
of
where
they
were
driving
to,
and
that
makes
it
kind
of
hard
for
us
to
understand
how
we
should
evaluate
them.
C
So
now
that
we've
had
these
conversations,
we're
going
to
have
create
these
issues
and
get
a
better
sense
of
where
we're
trained
to
go.
I
think
it'll
be
easier
to
then
have
conversations
about
the
prs,
but
that
was
that
was
just
my
concern
as
I
saw
them
come
in,
but
I
think
we're
moving
past.
E
That
just
good,
but
anyway,
if
you
have
a
concern
like
this,
just
ask
me,
because
I
think
I
tried
to
explain
for
example,
why
here
you
asked
me-
and
I
gave
my
thoughts
on-
why
I'm
thinking
this
way
it
would
just
be
nice.
I
need
to
file
an
issue
or
something
because,
as
any
other
external
contributor
you
are
coming,
you
are
doing
some
contributions.
You
don't
know
what
exactly
the
maintainers
or
the
approvals
are
expecting.
E
Because
I
understand
it
was
on
me
coming
with
multiple
trs,
but
that's
it's
not
a
fault
to
produce
multiple
pr's.
It's
probably
the
fault
was
that
I
should
have
created
some
issues
initially
or
something
like
that.
So
tell
me:
what
should
I
have
done
to
help
you.
C
Sure
and
yeah,
I
think
if
our
contributing
guidelines
are
not
clear
in
you
know,
in
in
how
issues
should
be
created
and
and
pr
related
issues,
then
that's
something
I
think
that
we
perhaps
could
address,
but
I
think
it's
it's
also,
even
in
the
absence
of
an
issue,
if,
if
you
don't
have
an
issue,
but
you
are
going
to
create
a
pr
having
a
description
of
the
pr
and
what
it's
intended
to
do
and
and
how
it
relates
to
other
things,
you're
doing
would
be
useful
for
us,
which
I
I
hope
you.
D
I
I
was
going
to
bring
that
up
after
the
skull
of
something
that
we
need
to.
We
need
to
address.
E
Yeah,
so
so
I
even
though
I
didn't
read
to
be
honest,
I
didn't
read
the
contributing,
but
even
if
I
would
have
read
written
read
read
I
I
wouldn't
find
anything
useful
here
so
around
this
problem.
The
other
thing
is,
I
didn't
see
anything
so
I
looked
at
this
at
least
majority
of
the
issues
and
I
didn't
see
anywhere
documented.
E
What
is
going
on,
like
you
mentioned
how
this
in
how
this
is
correlating
with
what
is
going
on,
and
I
couldn't
find
what
is
going
on.
Does
it
make
sense?
What
I'm
saying
like
no
yeah.
C
Absolutely
and
that's
why
I
thank
you
for
kicking
off
these
discussions
again,
because
we
we
need
to
start
making
progress
on
this.
We
need
to
be
having
these
discussions
we
kind
of
weren't.
I
know
aaron
has
been
working
on
some
stuff
related
to
the
metrics
sdk,
but
I
don't.
I
don't
know
that
a
plan
had
been
laid
out
and
I
don't
know
that
we
had
asked
for
a
plan
to
be
laid
out,
which
is
a
fault
of
ours.
We
we
should
have
done
that
yeah.
That's
that's!
Absolutely
correct!.
E
C
Think
in
in
this
project,
as
we
moved
towards
trace
stability,
we
used
a
project
and
put
all
of
the
issues
attached
to
that
project.
I
I
think
I've
found
that
slightly
better
than
an
umbrella
issue,
with
a
bunch
of
checkboxes
for
other
issues.
E
C
A
project
or
a
milestone,
I
think,
would
be.
Should
I
either
one.
E
C
E
E
I
will
create
for
metrics
api,
and
then
we
have
one
we'll
have
a
separate
one
for
sdk.
Is
that
okay,
sure
that
works
as
well,
because
I
think.
D
E
D
E
D
Things
are
are
closing
up
here
at
the
end
of
the
year,
so
I
I
do
my
best
to
try
and
address
them
out
as
I
see
them,
but
I
don't
always
get
enough
time.