►
From YouTube: 2021-08-26 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
I
thought
it
was
going
to
be
all
alone
for
this
meeting.
A
Kind
of
what
I
figured
yeah,
I
was
looking
into
that
as
well.
A
Yeah,
I
don't
think
we
actually
have
too
much
to
talk
about
at
this
meeting
anyways.
So
I
totally
think
that
that's
that's
pretty
fair,
but
I
do
want
to
get
a
check
in
yeah,
I'm
sitting
there.
Thinking
like
if
nobody
shows
up.
Do
I
just
like
go
through
a
meeting
agenda
that,
like
maybe
for
the
recording
or
something
like
that.
A
B
No
come
check
out
my
open
telemetry
music
yeah.
A
Exactly
right,
yeah,
it's
this
really
new
hip
thing.
A
Cool
actually,
it
looks
like
we're
getting
a
pretty
decent
turnout
at
this
point.
If
you
have
something
you
want
to
talk
about,
please
make
sure
you
add
it
to
the
agenda.
I
have
something,
but
maybe
I'll
just
kind
of
hock
it
and
then
we
can
probably
start.
Let
me
just
figure
out
how
to
share
my
screen.
A
Oh
man,
I
was
I
just
learned
today
that,
like
the
little
black
thing
that
sits
above
my
screen,
whenever
I
share
is
like
the
zoom
control
and
I
figure
out
how
to
move
it
this
week,
like
I
feel
I
don't
know,
sometimes
I
I
just
swear,
I'm
just
really
bad
at
technology.
A
Awesome
cool,
I
don't
think
anybody
else
has
joined,
but
please
make
sure
you
add
yourself
to
the
attendees
list.
We
can
jump
in
here
everything
to
talk
about
again,
bring
it
up
in
the
agenda
and
we'll
jump
in
as
normal
to
our
project
board,
definitely
slow
down
a
little
bit,
which
is,
I
think,
kind
of
normal.
A
Given
our
last
project
towards
the
end,
the
issues
get
harder
and
there's
fewer
things
for
people
to
actually
work
on
in
the
issue
or
and
directly
on
the
project,
so
that
makes
sense
just
to
kind
of
jump
in
and
talk
a
little
bit
about.
What's
going
on
last
time,
we
closed
these
two
issues
based
on
consensus
from
the
community.
I
haven't
heard
anything
back
from
bogdan
or
other
community
members
on
that
one.
A
Yet
so
I
think
that's
gonna
stick
still
working
on
getting
this
documentation
update
in
line,
I
think
there's.
I
definitely
responded
last
week
and
it
looks
like
david
has
as
well
and
there
hasn't
been
a
follow-on.
I
was
gonna
follow
into
my
stuff,
but
to
david's
stuff.
I
think
there's
a
valid
question
here.
So
still
working
progress
on
that.
So
it's
still
an
active
one
things
that
are
in
progress
right
now.
I
have
taken
a
look
at
this
issue.
A
We
talked
about
last
time
removing
the
package
import,
alias
requirement.
The
proposed
solution
here
was
to
do
a
rename
of
the
package.
Consensus
was
last
meeting
to
not
do
that
due
to
the
disruption
and
a
few
other
just
you
know,
I
think
global
understanding
and
context
of
how
that
package
has
used
issues.
A
However,
I
think
I
wanted
to
close
this
because
this
was
originally
brought
up
due
to
the
user,
referring
to
our
getting
started
docs
and
I
think
that's
a
really
important
point.
The
last
thing
I
I
think
we
should
be
doing
is
trying
to
make
it
hard
for
users
to
use
our
products,
and
so
we
want
to
make
the
aliases
I
think,
go
away
so
that
maybe
they
could
use
the
the
native
tooling
that
they
have,
I
think,
in
our
godot
or
getting
started.
It
doesn't
actually
say
to
use
your
tooling.
A
It
says
to
write
the
imports
manually,
which
no
one
does
so.
I
think,
like
that's,
pretty
reasonable,
to
try
to
not
do
that.
Just
for
the
confusion
side
of
things,
but
also
to
try
to
like
clean
it
up,
I
did
do
an
audit
of
all
of
the
docs
that
we
have
in
the
repo
and
the
only
places
in
the
getting
started
docs
with
the
website.
So
to
resolve
this,
I'm
working
on
a
revision
of
the
getting
started
docs.
A
I
also
noticed
that
in
the
getting
started
docs
it
is
referencing
metrics
here
and
a
few
other
things
and
I
think
there's
just
some
structure
issues
that
we
could
probably
try
to
fix.
I
would
like
to
target
these
on
the
stable
signals
and
and
add
things
as
they
become
stable,
so
I'm
trying
to
clean
this
up
and
try
to
make
it
a
little
more
concise,
I'm
still
working
on
a
pr.
So
I
can't
really
show
it
to
you,
but
I
think
there's
some
improvements
to
be
done
here.
A
Okay,
cool
the
other
one
is
related
to
this.
I
don't
know
if
josh
wants
you
to
assign
this
issue
to
you,
but
we
can
probably
get
into
that
josh
in
the
middle
of
last
week's
meeting
submitted
this
great
pull
request.
I
think
this
is
a
great
start.
We
had
talked
about
a
solution
where
these
new
creation
methods
are
not
going
to
be
returning.
Pointers.
A
Josh
went
ahead
and
implemented
that
in
a
few
of
the
cases
where
they
are
and
has
gone
back
and
done
a
really
great
analysis,
I
I
was,
I
totally
forgot
about
pprof
as
a
tool
here.
This
is
great,
I'm
loving
it
josh.
I
don't
know
if
you
want
to
talk
about
it,
I
could
probably
go
into
this
for
a
while.
C
So
I'm
happy
to
talk
for
a
sec.
I
always
find
myself
taking
longer
than
I
want
when
I
start
studying
this
type
of
problem,
so
you
can
see,
I
tried
to
cut
it
off
and
I've
cut
like
you
know,
off
a
longer
investigation.
C
Certainly
if
we
really
want
to
worry
about
memory
allocations,
we
should
talk
about
the
attribute
map
stuff,
which
is
like
half
of
our
problem
and
and
this
question
about
spam
config
seems
like
you're
debating
compiler
behavior,
and
I
I've
seen
odd
things
happen,
which
makes
me
think
I
should
spend
more
time,
but
I
don't
want
to,
as
I
said
so,
because
the
optimization
for
escape
analysis
is
global.
It's
possible
that
there's
a
test
artifact,
that's
changing
the
behavior
in
the
inside
the
benchmark.
I
think
I
I'm
not.
I
don't
want.
C
I
don't
want
to
say
more
much
more,
but
you
can
see
it
in
the
benchmark
and
you
can
change
it
in
the
benchmark
by
this
thing.
I've
done-
and
I
I
kind
of
don't
like
the
pattern
very
much
this
you
know
having
to
return
a
struct
value
modified,
and
I
wish
someone
else
would
help
this.
Who
does
have
time
or
feels
motivated
to
finish
the
investigation.
A
Okay,
great
yeah,
I
think
that's
kind
of
the
ultimate
thing
I
wanted
to
get
to.
I
know
anthony's
commented
on
this
as
well.
There's
definitely
some
confusion
around
this
and
I
don't
think
anthony.
I
think
your
comment
was
something
to
the
effect
of
like.
Is
this
worth
it?
I
think
that's
what
josh
is
also
wondering
about,
and
so
I
think.
D
I
wonder
I
wonder
if
it's
worth
it
one
because
I
mean
if
we're
saving
one
allocation,
but
we
have
to
go
and
change
every
option
again.
That
may
not
be
worth
it,
but
second,
I
just
don't
understand
how.
How
is
this
possible
right?
I
mean
we're
changing
it
to
a
place
where
we're
to
a
point
where,
instead
of
operating
on
a
pointer,
we're
receiving
a
value
making
a
copy
of
the
value
modifying
that
copy
and
returning
the
copy
many
times,
you
know
one
once
for
every
option
and
somehow
we're
still
getting
fewer
allocations.
D
B
Well,
it
would
make
sense
in
this
case
and
that
it
can
what
you're
called
it
can
do
tail
recursion
type
optimizations
and
then
just
allocate
it
once
on
this
on
the
stack.
A
Yeah
to
be
clear,
I
think
that
everyone's
on
the
same
page,
I
think
this
is
what
josh
was
also
saying,
like
there's,
there's
probably
some
optimization
at
the
global
level
of
like
escape
analysis
that,
like
we
don't
understand,
because
it's
a
compiler
level
thing
and
like
then
the
question
becomes
like
I
mean
theoretically,
everyone
can
use
a
different
compiler,
but
maybe
not
in
practice
and
so
like.
I
think
that,
like
yeah,
that's
something
we
want
to
understand,
but
what
I
got
from
josh's
statement
just
earlier.
A
Was
that,
like
we
should
do
exactly
what
anthony
said
is
we
should
understand
it
before
we
make
the
change,
and
somebody
else
should
do
that.
Well,.
D
I
I
think
josh
was
also
saying
that
you
know
we
we
may
be
kind
of
picking
around
the
edges
of
a
sack
when
we
should
just
be
dumping
out
the
stuff.
That's
in
the
sack
in
terms
of
looking
at
the
the
attribute
map.
A
Yeah-
and
I
definitely
think
that
that's
a
really
good
point
and
then
man-
it's
been
really
hard
to
not
get
nervous
by
that
attribute
map
or
the
eviction
list,
because
there's
just
I
look
every
time.
I
look
at
that.
I'm,
like
oh
man,
I
this
this
is
a
really
great
place
to
optimize
and
I
haven't
just
done
it
yet,
but
I
think
that
if
we
want
to,
we
could
probably
address
that.
A
I
you
know
my
first
thought
was:
should
we
do
that
in
this
stable
release?
But
the
thing
is:
is
that
is
all
abstracted
and
it's
all
unexported,
so
it
may
be
something
we
could
do
after
we
actually
get
stable
release
out.
The
thing
that
cannot
happen
is
if
we
change
the
function,
signature
after
the
stable
release,
so
I
think
that,
like
we
should
definitely
take
a
look
at
the
actual
weapon
we
should.
I
should
open
a
ticket
for
that.
A
C
C
Hopefully,
when
someone
explains
to
us,
why
can't
the
compiler
make
the
inference,
because
I
think
it
should
be
able
to,
and
it's
just
a
question
of
what
you
know
a
future
compiler
might
actually
change
this
behavior,
and
so
we
we
wouldn't
be
having
this
debate.
If
today's
compiler
did
the
optimization,
I
don't
see
how
the
escape
is
real,
but
compilers
are
hard
and
I
know
it
so
I
don't.
I
don't
want
to
I'm
not
and
also
like
someone
on
go
team.
C
C
I
can
see
a
pointer
that
doesn't
escape
with
my
eyeballs,
but
it's
allocating
it
on
the
heap
and
but
but
anthony.
Your
question
is
maybe
because
I
made
a
change.
The
compiler
can
much
more
easily
optimize
the
code,
therefore
we're
not
seeing
an
allocation
after
I
made
the
change
and
we
might
just
want
to
like
believe
the
benchmark
and
go
ahead,
because
the
benchmark
makes
it
really
easy
to
validate
that
we're
not
having
an
allocation
and
in
the
future
anyway.
I
don't
think
we
have
to
do
it,
because
it's
not
an
api
change.
A
I
do
think
that
the
the
change
that
we
need
to
consider
is
the
return
type
and
whether
it's
a
pointer
or
not-
and
I
think,
if
that's
the
thing
we
need
to
have
consensus
on
before
we
can
get
a
stable
release,
maybe
not
in
this
pr,
because
I
think
that
this
needs
to
be
applied
in
a
few
other
places,
but
the
the
config
types
from
sorry
I'm
trying
to
find
it
like
a
new
start
span.
Config
is
returning
not
a
pointer
but
an
actual
struct.
That's
the
thing
that
matters.
A
This
is
confusing,
but
this
is
the
part
that
this
user
facing
is
going
to
be
api
breaking,
and
so
we
need
to
understand
if
we
want
to
do
this-
or
not,
I
think,
is
the
key
thing
here
and
I
I
based
on
my
understanding
of
pointers
escaping
and
what
bogin's
asking.
I
think
this
is
a
good
change
to
that.
This
part
may
be
not
supported
at
this
point.
Maybe
we
could
hold
off
and
just
just
work
on
a
pr
that
actually
just
does
these
sort
of
changes,
I'm
wondering
what
people's
feelings
are
on
that.
C
D
C
Unless
the
next
version
of
go's
compiler
is
so
good
that
we
never
can
get
concerned
with
this,
because
it's
figured
out
how
to
prove
that
that
doesn't
escape
and-
and
I
believe
it
doesn't
escape,
because
every
implementation
of
an
option
pattern
just
takes
the
pointer
it
receives,
assigns
to
it
and
then
forgets
it.
Nothing
is
remembering
the
address
of
the
spam,
the
config
struct
from
those
options,
but
somehow.
C
A
C
A
Yeah,
I
think
I
I
might
understand
it
a
little
better
now
that
I'm
taking
a
little
look
given
the
fact
that
these
options
are
passed
in
as
arguments
each
option
that
is
being
applied
here
if
this
would
actually
take
a
pointer
and
and
operate
on
it.
There's
this
option
will
persist
beyond
the
lifespan
of
this
function
call
and
because
that
happens,
it's
undetermined.
Whether
I
think
that
pointer
that
you
pass
to
this
function
is
going
to
escape
this
function
or
not.
A
I
think
it
might
be
where
that's
actually
coming
from,
whereas
here
it's
definitely
not
the
case,
because
this
is
not
a
pointer
that
you're
passing
there's
there's.
Definitely
you
know
nothing's
going
to
escape
this,
because
it's
just
a
value
type
and
that
value
type
is
going
to
be
ephemeral
once
this
once
this
is
done,
this
is
done.
I
don't
know
if
they
can
find
another.
Oh,
it
might
be
more
helpful
if
I
found
it
instructive,
yeah.
A
So
something
like
here,
since
the
options
are
passed
in
from
outside
every
time
that
you
pass
a
pointer
here,
there's
nothing
that
says
that
this
option
doesn't
hold
reference
to
that
pointer.
I
guess
is,
is
the
problem
and
since.
A
Yeah
can
escape
this
function
then
that
doesn't
actually
it's
not
gonna
be
able
to
optimize
it
right.
The
reference
type
is
still
counted.
I
mean
in
theory.
This
is
never
used
again
from
the
caller,
but
it
doesn't
know
that
so
the
problem
I
think
comes
back
to
like.
Can
we
change
this
part
of
the
function?
Signature
and
leave
like
do
this
throughout
the
entire
thing?
A
I
don't
think
our
performance
benchmarks
are
going
to
be
improved
until
maybe
we
do
some
more
optimizations
or
we
better
understand
or
the
compiler
can
figure
this
out,
but
I
do
think
that
if
we
don't
change
this
now
we
put
ourselves
in
a
corner
and
we'll
never
be
able
to
return
anything
but
a
pointer
here
and
then
that
will
always
be
an
escape
pointer.
I
guess
is
my
point
on
this.
One.
C
So,
just
to
reiterate
we
as
long
as
we
change
the
config
to
a
concrete
return
from
these
new
functions,
we
can
wait
to
for
the
mechanical
change
which,
which
should
be
internal,
only
of
changing
every
apply
signature
to
take
and
return.
The
reason
why
it's
scary
is
you
have
to
like
you
can't
make
a
mistake.
A
You
mean,
oh,
I
see
you're
saying
so.
If
we
have
well
the
good
news
is,
I
don't
think
if
there's
any
new
events
or
new
config
methods
outside
of
this
trace
library
or
the
metrics,
otherwise
they
don't
need
to
be
exported.
C
Mistakes,
I've
seen
have
to
do
with,
like
the
caller
forgot
to
reassign
the
value
when
they
used
the
new
apply
function.
So
someone
who
was
just
calling
apply
with
a
pointer
started
calling
apply
with
a
struct
and
didn't
realize
that
they
were
actually
not
taking
the
new
value,
so
every
user
of
the
option
has
to
be
tested.
C
But
you
see
how
big
my
change-
it's
not
small!
It's
like
touches
like
lots,
lots
to
play
through
this
yeah.
B
I
mean
it
was
a
pointer
in
a
lot
of
places.
One
thing
that
it's
a.
B
Thing
bunch
of
functionalities,
so
my
question
is:
do
you
have
some
way
to
get
the
allocations,
pre
and
post
changes
so
to
iterate
like
it
looks
like
you
did
some
of
that
work
and
I
see
in
the
the
pr
you
say
like
afterwards:
there's
nine
allocations.
C
Or
did
you
just
sorry
the
the
benchmark
I
did
was
nine
before
and
then
during
the
meeting
last
week
I
made
a
quick
change,
just
the
interface
of
new,
to
return
the
concrete
type
thinking
the
compiler
would
do
the
rest
and
it
didn't
make
a
difference.
It
was
still.
C
C
So
that
brings
that
nine
down
to
seven
and
of
those
seven,
I
would
argue,
two
of
them
are
mandatory.
One
is
there's
a
context,
you're
allocating
for
your
test
and
and
you've
got
to
put
that
span
into
the
context.
So
there's
one
context
value
there.
There's
also
one
span
object
the
actual
span
in
the
sdk
trace
package.
So
that's
two,
the
other
five
are
like
you
need.
C
You
need
to
store
your
attributes
somehow,
but
but
it's
almost
like
the
worst
case
up
like
I
don't
know,
I
I'm
not
sure
this
is
the
organization
I
would
choose.
If
I
started
from
scratch,
it
came
from
open
census.
I
somehow
feel
like
it's.
You've
got
both
a
map
and
a
list,
and
it's
handling
eviction
and
it's
doing
least
recently
used-
and
I
just
feel
like
that's
not
not
semantic
that
I
care
for
for
in
a
telemetry
like
I
I'd
prefer
to
just
like.
C
Have
them
be
a
list
and
in
hotel
we've
had
this
spec
as
a
protocol
issue.
If
you
just
encode
a
map
as
a
list
of
key
values,
the
last
value
wins
semantic
is
kept
just
like
protobuf
concatenate
would
work
semantically
so
that
you
can
just
never
index
your
attributes
and
write
them
out.
However,
that
does
change
a
bunch
of
stuff.
C
D
C
A
Well,
I
think
the
you're
right,
I
think
it
is,
I
think
it's
still
an
active
issue
as
to
like
which
attributes
there
was
proposed.
I
think
in
order
there,
but
I'm
not
sure
if
that
made
it
in.
I
do
know
that
look
I've
looked
at
this
implementation
a
few
times
one.
I
know
that,
there's
a
built-in
implementation
to
the
actual
go
library
that
would
be
more
optimized
honestly.
I
think
that
a
second
pass
would
be
more
optimized.
If
we
wanted
to
build
our
own,
it's
not
the
most
optimized
eviction
queue.
A
In
fact,
it's
not
even
a
real
eviction.
Cue,
but
like
that's
neither
here
or
there.
I
think,
if
there's
a
few
things
that
could
actually
be
optimized
there,
just
by
changing
structure
types
but
then
yeah
performance
or
something
like
that.
I
think
that
we
could
look
at
behavior
and
see
if
we
can
try
to
get
away
with
things
like
that.
Another
thing
is
like
changing.
The
data
type
away
like
josh
is
saying,
like
it's
duplicate
data
that's
stored
in
there.
A
If
you
sort
it
once
and
then
you
had
like
the
functions
that
iterate
over
things
do
more
of
the
computational
load
like
does
that
reduce
the
memory
like,
I
think,
there's
a
lot
of
optimization
if
you
could
on
there
but
to
anthony's
point
like
it
is
all
encapsulated
in
the
span
and
it's
all
unexported.
So
it's
something
we
can
address
in
the
future.
A
Okay,
so
for
next
steps
on
this
one
josh-
I
it
sounds
like
I-
I
should
not
assign
this
issue
to
you.
I
imagine
we'll
just
the
next
person
that
wants
to
pull
something
can
pull
from
there.
I
hope
they're
on
this
meeting,
I'm
hoping
to
get
this
one
after
I
get
this
one
done,
but
I'll
try
to
maybe
put
a
little
bit
of
what
we
just
talked
about
into
this
issue
after
meeting
to
see
like
the
person
who
does
pick
this
up
is
not
lost.
A
Okay,
cool,
I
think
that's
it
for
the
project
board.
Coming
back,
we
don't
have
any
agenda
items
so
I'll
put
my
secret
one
that
is
hidden.
It
has
to
do
with
this
in
the
release,
I'm
guessing
once
we
get
all
of
this
flushed
out.
I
imagine
it
might
be
another
week
or
two.
A
It's
really
hoping
to
get
it
done
this
month,
but
I'm
just
not
seeing
the
progress
that
that
fast,
I'm
hoping
that
maybe
we
can
do
another
rc,
I
guess
is
my
next
question
for
rc3
is-
is
the
guess
unless
other
people
have
different
opinions,
I'm
guessing
there
isn't,
but
I
just
want
to
ask.
D
Okay
yeah,
so
I
think
eddie
had
some
outstanding
pr's
that
he
didn't
get
to
finish
in
the
release
helper
tool
that
will
help
us
when
we
come
around
to
do
that.
I
need
to
to
follow
up
on
those
as
well.
So
if
we
want
to
target
next
week,
maybe
for
for
an
rc,
if,
if
we're
able,
I
can
hopefully
get
around
to
those
by
then
I'm
still
wrapping
up
the
work
on
moving
collector
components.
A
Okay,
yeah.
Actually
I
think
that
timeline
sounds
ideal.
So,
let's,
let's
shoot
for
there.
I
mean,
like
I
said:
we've
gotta
clean
this
all
up
and
flush
it
out.
So
it'll
probably
take
me
that
long,
maybe
a
little
longer,
I'm
getting
asked
to
do
other
things
as
well.
So
that
sounds
good
all
right,
I'm
gonna
pause
here
we
can.
If
anybody
else
has
something
they
want
to
talk
about
on
the
agenda
ad
hoc
or
we
can
talk
about
user
stories
or
go
get
a
coffee.
A
C
I've
been
working
on
this,
his
instagram
stuff
for
the
hotel,
metrics
protocol
and
I've
got
golang's
math
big
package
out
in
front
of
me,
and
I
I'm
just
trying
to
solve
all
the
problems
before
I
finish
the
day.
So
it's
exciting
here
but
I'd
be
happy
to
end
the
meeting.
If
we're
done.
E
I
have
one
brief
user
story,
so
I
think
I
mentioned
in
the
past.
We
have
an
internal
metrics
back
in
which
I'd
written
an
exporter
for
a
long
time
ago,
and
I
now
have
somebody
who's
running
on
aws
lambda,
who
wants
to
export
both
the
cloud
watch
and
to
our
our
internal
metric
system.
So
anyway,
I
have
I'm
using
0.21.0
of
the
metrics
so
still
using
all
the
up
down
some
counter
observer
stuff,
which
I
know
is
all
going
to
change
but
they're
happy.
E
There
was
one
thing
I
I
was
caught
by,
though
I
think
in
one
of
the
upgrades
josh
had
added
this
with
memory
option
to
a
processor,
for
I
guess
prometheus
support
and
at
some
point
I
got
confused
and
I
thought
that
was
actually
needed.
Also,
if
you're
doing
a
delta
x
water,
which
I
realize
no,
it's
not
so
anyway,
they
were
getting
the
same
metric
reported
again
and
again
and
again,
because
that's
what
with
memory
does
and
so
no
I've
removed.
E
A
D
C
It
sounds
like
it
could
be,
a
bug
related
to
deltas
and
state
in
that
memory.
Option
probably
worth
investigating
thanks
for
those
yeah.
E
C
Yeah,
there's
I
mean
there's.
The
idea
was
that
you
have
a
configuration
of
the
sdk
where
you're,
where
you
prometheus
is
able
to
scrape
your
metrics
cumulatively
and
you're,
also
pushing
deltas
to
a
newer
vendor.
Let's
say
which
is
what
you
tried
to
do
and
it
should
have
worked
and
it
doesn't
so.
I
think
it
is
actually
probably
a
bug
you
shouldn't
be
exporting
deltas
because
you
have
memory
turned
on.
You
should
export
delta
deltas
because
there
was
actually
a
change,
and
I
I'd
have
to
dig
into
that.
Thank
you.
C
I
mean,
let's
see
you
know,
for
the
group
which
I
think
most
of
you
have
heard
me
already.
Tyler
was
there
earlier
today
the
hotel,
metrics
api
has
been
marked
stable
at
some
level.
We
are
very
close
to
that
and
we
just
need
to
change
the
names
of
the
instruments
to
be
close.
But,
as
you
all
know,
there
was,
there
is
an
opportunity
to
actually
change
the
api,
and
I
don't
want
that
to
get
ahead
of
tracing
and
1.0.
C
So
we
should
probably
just
let
the
metrics
api
not
get
in
the
way
of
tracing.
One
thing
we
could
do
to
make
it
less
confusing
to
users
in
the
interim
would
be
to
rename
value
recorder
to
histogram
some
observer
to
asynchronous
counter
and
so
on
there
there
would
be
four
or
five
changes.
It's
very
mechanical.
I
would
be
happy
to
do
that,
but
I
I
don't
know
I'm
worried
of
this
sort
of
blowback
of,
like
you
know.
Okay,
now,
are
you
now
we're
gonna
make
a
change
in
the
future.
C
D
D
E
I
thought
about
actually
writing
a
little
wrapper,
as
it
is
now
to
rename
the
instruments
without
changing
the
internal
hotel
code
right
at
least
to
make
it
easier
so
that
people
were
using
those
names,
even
though
they
aren't
currently
there
available
on
the
back
end.
I
don't
know
how
feasible
that
is,
or
whether
we
should
just
go
ahead
and
change
the
change
the
names
on
the
back
end,
so
people
are
more
used
to
those
names.
As
you
say,
I
don't
know
what
the
right
trade-off
is
there,
as
opposed
to
let's
just
roll
out
tracing
1.0.
E
C
What
I'm
hearing
is
that
we
should
probably
just
rename
to
avoid
further
confusion
and
continue.
It's
obviously
going
to
continue
being
marked
as
experimental,
but
we
would
at
least
have
histogram
counter
asynchronous
counter
rates.
It
goes
up
down
counter
standard
which
are
which
are
state
marked
stable,
as
names
go.
C
Been
done
in
the
java
yeah
we're
we're
all
kind
of
moving
forward
on
those
okay,
so
I
will
agree
to
do
that
renaming
it's
independent
of
all
the
other
things.
I've
got
in
flight
and
it
should
be
fairly
rote
to
review
like
straightforward,
renamings
I'll,
send
it
out.
A
Great
yeah
that
sounds
awesome
cool
anybody
else
have
some
user
stories
aaron.
I
saw
you
hit
them.
You
did
okay
last
we
go
once
go
on.
Okay,
I
guess
we're
all
done
for
the
day.
Thanks
all
for
joining,
really
appreciate
you
coming
and
talking
we'll
see
you
all
virtually
and
more
next
week.