►
From YouTube: 2021-06-17 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).
B
F
D
Do
you
want
to
share
the
topic
with
this.
B
Yeah
sure
so,
basically
I
am
an
outreach
intern.
I
got
accepted
for
the
may
2021
cohort
like
just
now,
so
I
started
working
on
the
project
and
as
a
part
of
the
project,
I'm
comparing
the
performance
between
open
tracing
and
open
telemetry.
B
So
I
am
required
to
write
benchmark
test
for
that
purpose
and
over
the
past
few
weeks
have
been
exploring
various
tools
to
write,
benchmark
tests
and
understanding
the
entire
process
of
performance
testing
and
now
I
finally
came
up
with
a
test
plan
and
I
consulted
with
my
mentors
as
well.
So
the
link
to
the
test
plan
is
yeah
provided
there.
B
D
B
D
D
Okay
cool,
so
this
is
probably
more
on
the
instrumentation
side.
It
sounds
like
yeah.
D
Issue
or
discussion-
oh
just
just
whenever
you
know,
whenever
it's
convenient
and
post
a
link
to
the
test
plan
and
say
you're
looking
for
feedback
and
that'll,
that's
gonna
be
the
best
way
to
get
it
in
front
of
everybody's
eyes
for
review.
A
B
So
we
presently
already
have
a
set
of
tests
which
are
for
open
tracing
which
were
done
by
my
mentor
during
her
internship.
So
under
the
current
set
of
tests,
I
basically
mentioned
what
tests
we
already
have
and
all
these
exist
only
for
open
tracing.
B
D
D
So
gotcha-
and
so
are
these
are
jmh
I
see
so
this
is
okay.
So
it's
a
little
bit
more,
like
micro,
benchmarking.
D
To
a
full,
app,
john
and
jason
were
mentioning
this
thing
called
iguanodon,
let's
see
if
we
get
iguana
iguanodon,
I.
D
I've
been
there
it's
a
tool
because
I
was
not
spelling
it
right,
a
tool
that
jason
wrote
on
that,
but
it
is
more
for
macro
benchmarking
of
taking
like
a
whole
spring
pet
clinic
a
whole
app
and
putting
load
on
it
and
measuring
the
agent
overhead.
D
B
Sorry
to
interrupt
you,
so
one
question
we
had
is
that
the
present
set
of
benchmarks
are
only
to
do
with
the
different
frameworks,
so
they're
all
testing
open
tracing
with
different
frameworks
like
jdbc
or
springboard
or
spring
cloud.
So
we
don't
have
any
other
tests
which
are
based
on
the
number
of
tracers
or
you
know
spans
or
anything
of
that
sort.
So
would
that
be
useful
to
add.
D
D
Because
I'm
I'm
sure
people
will
have
some
thoughts
about
like
the,
because
the
benchmarking
and
overhead
thing
comes
up
quite
often,
so
this
is
great
people
I
think,
will
be
very
interested
in
this
proposal.
D
Cool
is
there
anything
else
you
wanted
to
share
with
us
today
about
it
or
ask
today
about
it.
B
A
Awesome,
it
might
be,
it
might
be
interesting
to
think
about
where,
like
we
probably
want
this
code
not
to
disappear,
especially
if
it's
going
to
give
us
some
interesting
new
benchmarks
on
the
instrumentation
in
general,
so
it'd
be
it'd,
be
interesting.
We
should
think
about
where
we
would
like
this
code
to
live
long
term,
because
I
know
there's
been
you
know.
Iguanadon
there's
been
talk
about
moving
that
into
the
instrumentation
project
or
into
something
else
or
into
a
contrib
or
somewhere.
A
D
D
D
All
right,
josh.
H
Yeah,
although
so
I'm
in
pittsburgh,
which
wants
to
consider
itself
east
coast
but
all
of
the
actual
east
coast
cities,
don't
want
us
to
consider
ourselves
east
coast,
you
know
what
I
mean.
I.
H
So
pis,
I
would
say,
we
consider
ourselves
part
of
the
east
coast,
but
the
east
coast
cities
want
us
to
consider
ourselves.
Part
of
the
rust
belt.
H
We're
the
only
city
in
appalachia,
the
only
city,
if
you're
familiar
with
the
appalachia
region
and
all
of
the
fun
movies
about
it,
yeah.
But
that's
that's
where
we
are.
H
H
So,
technically,
if
you
look
at
appalachia,
it
cuts
across
and
doesn't
actually
hit
any
of
the
west
virginian
cities
and
cities.
I'm
talking
like
the
the
population.
You
have
to
have
more
than
what
200
000
or
something
I
forget
what
it
is,
but
we
are
so
so
effectively
we're
the
only
place
that
has
a
big
enough
population
to
consider
itself.
A
city
about
youngstown
is
youngstown,
not
in
appalachia
youngstown's
too
far
west.
It's.
H
Anyone
does
anyone
live
in
youngstown
anymore.
I
don't
know
anyway.
I
I
stopped
at
a
lot
in
arby's
there,
so
there
were
definitely
people
there,
hey
fyi,
west,
virginia
hiking
and
lakes.
Awesome
recommend
it,
but
we
should
probably
talk
about
java.
H
I've
heard
so
many
good
things
about
estonia
that
hopefully
we
can
visit
it
someday
anyway.
So
john
had
asked
me
to
look
at
implementing
the
new
api
against
our
current
thing,
so
I
have
a
working
prototype
of
all
the
synchronous
instruments
with
a
few
additions
and-
and
I
maybe
allowed
myself
to
experiment
a
little
too
much.
So
that's
what
I'm
going
to
run
by
the
the
group
here
of
of
where
things
are.
The
notes
document
has
all
of
my
like
specific
notes.
H
There's
two
topics
I
wanted
to
call
out
for
discussion
today.
So
if
you
look
at,
if
you
look
at
what
I
did
to
the
synchronous
instruments,
one
of
the
things
that
I
added
was
an
explicit
record
with
context.
H
So
I
don't
remember
why,
but
there's
effectively,
we'd
like
to
get
exemplars
hooked
up
over
time
and
exemplars
require
access
to
the
current
trace.
So
in
this
this
prototype
implementation.
Here
we
have
an
example,
our
sampler
and
we
actually
have
exemplars
wired
all
the
way
to
the
data
model.
In
java,
where
you
can
actually
sample
exemplars
and
histograms
and
get
them
generated,
what
I
did,
though,
was
looking
at
the
trace
api.
H
Looking
at
the
metrics
api,
I
added
an
explicit
context
that
gets
recorded
and
I
added
the
implicit
context
that
gets
recorded.
So
if
you
call
a
record
method
without
specifying
a
context,
it'll
call
context.current
for
you
and,
if
you
call
it
with
the
explicit
context,
we'll
use
that
instead,
because
I
felt
like
that
was
in
line
with
what
was
done
with
trace
where
all
of
the
trace
apis
there's
like
a
you,
know,
span.current
and
span.from
context.
H
So
if
you
want
to
see
the
api
there,
it's
under
that
I
can.
I
can
actually
get
you
a
link,
real,
quick.
H
So
that's
the
first
thing
I
wanted
to
talk
about
just
understand
like
are
we
comfortable
with
this
change?
Do
we
feel
like
this
is
going
to
be
weird
and
wonky
for
users?
What
what
do
we
think
and
is
it
worth
raising
this
in
the
api
sig,
to
talk
about
explicit
context
passing
so.
A
H
H
That
much
difference
I
hear
that
okay,
okay,
so
I
can
what
what
I?
What
I
need
to
do
then
before
I
send
that
out,
is
I'm
going
to
get
rid
of
the
old
implementation
right
now
the
branch
has
a
metrics
old
and
a
metrics
new
and
to
do
the
diff
you
have
to
do
it
in
your
head,
which
works
for
me,
but
probably
not
good
for
anyone
else.
So
I'll
get
rid
of
the
old
metrics
api
and
have
this
just
be
a
straight
up
replacement?
H
I
wanted
to
get
asynchronous
measurements
in
and
the
existing
exporters
like
merged
back
over
there's
a
few
other
changes
that
in
the
sdk
that
deserves
some
some
talk,
but
the
sdk
spec
is
completely
up
in
the
air
at
this
point,
so
I
don't
want
to
like
hit
you
guys
with
that.
I
just
want
to
hit
you
with
the
api
related
stuff
that
I
think
matters
yeah.
H
So
here,
if
you
look
it
it,
the
main
change
to
like
double
counter
is
there's
a
new,
add
method
that
takes
in
context
and
then
there's
the
an
updated
javadoc.
That
says,
for
the
original,
add
method
that
context.current
will
be
called
so
that
you
know
this
so
folks
who
aren't
using
context.current
and
the
context
thread.
Local
storage
know
that
they
have
to
explicitly
pass
it
and
folks
that
do
you
know.
A
Are
fine
so
josh
given,
given
that
you
want
you
want
really
focus
on
the
api
to
start
with,
I
actually
think
it'd
probably
be
better
to
do
it
not
replacing,
because
that
will
impact
all
the
sdk
as
well,
but
maybe
just
create,
create
the
new
module
still
is
draft
pr.
We
create
the
new
module
with
just
the
api
stuff
in
it
just
so,
we
can
kind
of
focus
on
what
that
looks
like
as
the
first
step.
H
So,
just
looking
at
the
api,
okay
yeah
in
this
branch
under
this
metrics
new
api
thing
has
all
just
the
api
changes.
Yeah.
H
So,
there's
only
two
major
changes
that
I
made
one
is
that
of,
I
guess
three
one
is
one.
Is
that
having
context
explicit
for
synchronous
instruments,
the
second
thing
is
actually
around
builders.
H
So
what
I,
what
I
did
to
kind
of
match
the
spec
a
little
bit
closer.
All
of
the
builders
when
you
say,
like
counter
builder,
comes
with
a
default
either
of
long
or
double
so
counters
default
to
longs,
histograms
default
to
double,
and
then
there's
an
of
longs
in
an
of
doubles
that
you
can
call
it
a
switch
to
the
other
one,
and
I
went
with
that
approach
just
because
I
like
I
have
no
great
justification
for
this.
A
H
And
you
kind
of
have,
if
you
allow
folks
to
call
of
doubles
and
of
longs,
you
have
to
make
sure
that
they
cannot
do
that
after
they've
passed
a
callback
for
type
reasons
so
effectively
for
this
one,
you,
you
can
switch
to
the
measurement
that
you're
using
for
of
doubles
and
of
longs,
and
then
you
say,
build
with
callback
and
you
force
them
to
pass
a
callback.
So
there
was
an
open
to
do
in
the
previous
api
of
like
what
do
we
do?
H
If
users
don't
provide
a
callback
and
now
they
can't
so
I
I
feel
like
that
makes
a
lot
of
sense
for
a
an
asynchronous
instrument,
but
those
those
are
the
only
three
changes
that
I
made
outside
of
getting
rid
of
instruments
that
aren't
specified
because
you
know
with
we
yeah.
The
new
api
is
less
flexible,
there's
less
instruments.
A
So
josh,
while
we're
in
here
just
exploring
the
api-
and
you
know
you're
talking
about
long
versus
doubles-
there
has
been
some
pushback,
especially
from
the
micrometer
crew,
that
it
definitely
makes
the
apis
way
more
complicated
have
to
worry
about
both
and
if
we
just
did
doubles
like
micrometer
does
it's
just
makes
a
much
simpler
api
to
use.
I
wondered
if
you
had
any
thoughts
on
that
topic.
H
Kind
of
so
the
the
only
the
only
reason
I
think
to
prefer
longs
in
in
some
situations
around
counters,
specifically
the
the
granularity
that
you
can
get
to.
You
have
more
bits
before
you
roll
over.
H
It's
possible:
do
you
know
what
I
did
to
histograms
by
the
way
when
I
implemented
them,
because
there's
only
a
double
histogram
in
otlp,
so
the
long
histogram
instrument
converts
everything
the
the
aggregator
converts,
all
longs
back
to
doubles
to
do
counts.
It
feels
like.
A
A
I
feel
this
way
as
well
that
there's
the
use
case
for
long
is
pretty
limited
for
for
long
specifically
for
the
extra
resolution,
not
resolution,
but
extra
size
you
get
out
of
long
is
pretty
limited
and
if
we
could
limit
it
just
to
counters
and
like
I
don't
even
know
what
the
usage
for
a
double
counter
would
be
because
it
that
feels
like
a
weird
thing
to
be
counting
fractions.
Not
that
you
can't,
but
I
mean
my
opinion.
H
I
I
I
feel
like
we
should
yes
for
now
I
kept
I
kept
the
divi.
I
I
let
myself
explore,
but
not
so
much.
You
know
what
I
mean
specifically,
because
I'm
copying
pasting
tests
and
updating
them
for
this,
and
so
there
was
a
lot
of
wonky
things
I
had
to
do
for
that.
I
I
will
say
like
when
I
implemented
histograms.
H
It
felt
weird
to
convert
all
longs
back
to
doubles,
but
the
other
thing
that
I'm
noticing
is,
I
don't
know
if
all
of
the
weird
concurrency
primitives
are
the
same
between
doubles
and
primitives.
That's
why
I'm
hesitant
so
far.
I
think
they
are
there's
long
adder,
there's
double
adder
we're.
We
have
the
same
kind
of
compare
and
swap
that
we
need
for
both.
A
But
you
know:
double
equality
is
not
long,
equality
yeah,
that's
for
sure
no,
the
other
means,
but
the
other
way
we
have
to
implement
both
of
them
everywhere.
So,
whether
they're,
equivalent
or
not
like
one
way,
we
have
to
implement
both
one
way.
We'd
only
have
to
implement
one
and
we
could
implement
whatever
is
optimal.
In
that
particular
case,.
H
Right
yeah,
so
one
thing
I
did
in
the
sdk
implementation,
you
can
take
a
look.
I
made
a
thing
called
a
measurement
that
has
a
long
measurement
and
double
measurement
and
all
of
these
apis
work
against
measurement,
and
then
you
cast
to
the
one.
You
know
that
you're
getting
or
you
instance
of
and
hope
that
the
jit
optimizes
you
away,
which
seems
to
be
the
case
so
far,
but
I
haven't
done
extensive
performance
eval
on
that.
A
My
main,
my
main
concern
is
making
is,
hopefully
helping
users
not
be
confused
with
an
api.
That's
so
complicated
that
it's
hard
to
understand
what
they're
supposed
to
do
like.
I
think
we
already
at
least
previously,
have
an
api,
that's
kind
of
difficult
to
understand,
which
instrument
to
use
and
then
having
to
layer
the
type
on
top
of
it
is
yet
another
decision
point
that
I
think
is
going
to
slow
people
down.
So
my
personal,
my
personal
goal,
is:
let's
keep
the
api
as
simple
as
possible
as
long
as
we
possibly.
H
I
I
hear
that
the
other
thing
that
we
could
do
as
an
fyi
is
that
the
async
builders,
instead
of
having
an
explicit
method
to
build
them
async,
you
could
just
say
counter
builder
and
then,
if
you
call
build
you
get
a
synchronous
instrument,
if
you
say
build
with
callback,
you
get
an
asynchronous
instrument
like
that.
Actually
I
actually
like.
A
That
better
and
that
build
with
build
with
a
callback
doesn't
have
to
return
anything
right.
It
could
just
exactly
it
returns,
void,
yeah
yeah.
I
think
that
would
be
fantastic.
In
fact,
that
was
kind
of
what
I
was
hoping
that
the
api
in
the
spec
was
going
to
end
up
like
whether
they're
not
really
different.
Just
one
of
them
happens
to
be
built
with
a
callback
and
be
handled
internally,
and
one
of
them
happens
to
be
something
you
can
call
directly
right
and.
H
H
A
H
My
opinion,
okay,
okay,
a
few
things
to
call
out,
though
that
I
think
are
completely
terrible.
So
I
implemented
histograms,
so
histogram
aggregation
exists,
but
I
wired
it
all
the
way
through
and
wrote
a
test.
One
of
my
one
of
my
restrictions
I
placed
on
myself
was:
I
should
be
able
to
take
the
existing
instrument
tests
and
copy
paste
them
into
the
new
implementation
and
they
should
work,
as
is
with
only
the
like
surface
changes
necessary
and
so
far
I've
been
able
to
do
that.
H
There
was
no
histogram
test,
so
I
wrote
one
but
for
histograms
there's
no
way
to
provide
buckets,
and
you
know
what
that's
really
an
api
concern,
the
more
the
more
I
look
at
it
because
the
the
buckets
that
you
should
default
to
are
really
kind
of
determined
by
where
that
instrument
lives
and
what
you're
instrumenting
so
anyway.
H
Sorry
my
family's
eating.
You
should,
if
you
look
at,
if
you
look
at
the
code
that
I
provided
there's
a
way
you
can
provide
a
default
bucket
when
you
instantiate
a
meter
provider
and
it's
used
for
every
histogram
and
the
default
one
that
I
created
is
absolutely
terrible.
I
know
it's
terrible
from
my
own
histogram
usage,
but
hey.
A
This
works.
This
is
the
purpose
of
riley's
hint
api
right.
This
is
what
he
wants.
The
hint
to
be
is
the
way
when
you
construct
histogram
like
here,
are
some
pretty
good
buckets.
I'm
going
to
be
measuring
this
thing
that
has
this
kind
of
range
in
it,
so
you
know,
do
your
best
use
mine
or
figure
out
something
better,
but
here's
the
info
about
it.
A
H
H
So
for,
if
you're
curious,
I
basically
tried
to
match
the
tentative
sdk
proposal
in
terms
of
like
raw
pieces
that
are
described
and
one
of
the
interesting
things
there
was.
I
detangled
the
aggregators
from
the
notion
of
instrument
storage
and
we
we
had
to
make
room
for
this
thing
called
a
measurement
processor.
H
I
can
walk
into
details
on
that
when
you
want,
but
I
feel
like
it's
like
that's
that's
a
discussion
for
the
sdk
sig,
because
the
way
it's
specified
today
was
a
little
bit
like
there's
some
optimizations
done
in
the
sdk
that
I
had
to
contort
myself
to
bring
them
back,
and
so
I
think
we
need
to
dive
into
that
a
bit.
A
Yeah,
this
is
something
I've
been
kind
of
not
recently
but
wrangled,
with
bogdan
in
the
past
that
I
think
what
we
have
is
again
kind
of
just
open
census.
A
That's
been
ported
over
and
I
think
we,
if
we,
I
think
that
we
need
to
if
we
want
to
keep
the
current
way
that
things
are
built,
we
need
to
push
on
the
sdk
spec
or
we
need
to
rework
things
to
match
what
the
sdk
spec
is
going
to
look
like
my
preference
is
that
one
it
will
probably
mean
we'll,
have
more
optimization
and
thinking
work
to
do
around
that,
since
it's
going
to
be
a
little
more
in
greenfield,
but
I
I
would
prefer
that,
but
would
you
be
willing
also
to
reach
out
to
bogdan?
A
H
Yeah
totally
can
do
charlie
can
do
the
the
the
tl.
Dr
that's
interesting
though,
for
java
is
we
try
to
highly
optimize
straight
from
instrument
to
concurrency
primitive
for
like
single
measurement
right
and
the
current
proposal
in
the
sdk?
Has
this
like
crazy
flow,
where
that
is
completely
broken,
and
I
think
that's
going
to
be
a
source
of
contention
that
we
have
to
figure
out
what
we
prefer.
H
A
So
I
mean
I
think
we
have
made
two-
maybe
three
two
options
at
least
one:
we
could
rip
out
all
the
metrics
from
the
tracing
sdk.
That's
one
option
until
we're
ready
for
to
have
something,
but
I
do
think
that
the
metrics
in
there
are
useful.
I
don't
know
honestly
whether
anyone's
using
them
in
production,
but
they
are
useful
metrics
about
how
the
sdk
is
behaving
for
our
performance
benchmarks
yeah.
We
do
actually,
yes,
they're,
really
good
for
performance.
So,
like.
H
A
A
So
if
we
create
a
second
api,
sdk
implementation
with
some
horrible
name
like
new
or
two
or
better
or
awesome,
we
can
wait
until
we're
comfortable
with
that
stability
and
being
something
that
will
work
end-to-end
as
well,
at
least
as
well
as
what
we
have
today.
Then
we
can
swap
over.
Since
I
mean
we're
using
alpha
already.
We
can
wait
until
we
we're
pretty
confident
of
stability
and
and
and
performance
and
then
swap
over
to
the
old
one.
It.
C
A
H
Yeah,
the
only
thing
I
want
to
call
out
is:
if
I,
if
I'm
writing
the
new
api
using
the
same
package,
it
broke
the
hell
out
of
my
ide
having
two
directories
with
the
same
package:
name,
it
can't
figure
out.
What's
going
on,
it
just
starts
barfing
all
over
the
place,
so
I
don't
want
to
continue
down
that
path.
So,
if
we're
going
to
keep
it,
if
we're
going
to
keep
both
of
them,
then
just
from
a
practical
standpoint
of
I
want
my
ide
to
auto
complete
ever
and
not
give
me
deprecation
warnings.
H
I
think
we,
I
think
we
need
a
solution.
There.
A
Yeah
I
hate
I
mean,
I
hate
the
fact
that
well
what
you
just
said,
like
it'd,
be
really
nice.
If
everything
just
was
like
hey
you're
using
this
one
or
using
that
one
and
have
it
be
friendly,
but
I
mean
I
think
in
an
ideal
world
we
would
rename
the
existing
one
to
something
legacy
or
bad
or
please
don't
ever
use
me.
You're
very,
do
there's
things
dot
com,
but
that
also
is
that's
a
kind
of
a
biggest
chore,
even
just
on
its
own,
so
yeah,
let
me
bring
well.
A
H
Great,
I
might
that
there's
a
chance
we're
playing
sand
volleyball.
So
if
we
get
tired
really
quickly,
then
I'll
be
back.
A
Anyway,
because
because
honorary
will
be
there-
and
it
would
also-
I
know
he
is
like
break
in
the
camp
of
break
all
the
things,
but
the
tracing
sdk
dependency
makes
it
more
complicated,
yeah
yeah.
A
So
I
always,
if
you
can't
make
it
I'll,
bring
it
up,
and
we
can
at
least
talk
us
through
a
little
bit
more.
H
I
have
one
last
thing
to
ask
which
I
I
mentioned
this
in
chat
on
the
the
metrics
data
model
right
now,
there's
a
bunch
of
tests
that
rely
on
equality
of
those
auto
values,
those
auto
values
have
collections
in
them
and
the
collections
are
effectively
maps
but
as
collections
of
attribute
data
points
and
then
when
I
added
exemplars,
it
gets
even
worse
because
there's
collections
underneath
there
and
those
are
random
order.
H
H
Just
as
a
general
thing,
I
updated
all
the
tests
to
guarantee
they
ignore
ordering
in
the
new
api,
because
otherwise
it
doesn't
work.
But
there's
still
this
fundamental
question
of
if
we're
providing
a
hash
code
and
an
equals
method
for
those
points,
and
we
ever
want
to
use
them
in
a
in
a
in
a
hash
map.
Should
I
go
update
their
auto
value
because
that's
going
to
be
fun.
A
Is
there
a
way
to
like
aside
from
just
writing
hand,
hand
rolled
equals
and
hash
code
to
coerce,
auto
value,
to
ignore
order
on
stuff,
or
is
that
going
to
be.
H
Just
android
so
we'd
have
to
we'd
have
to
for
hash
code.
We'd
have
to
do
something
to
make
sure
that
we
hash
things
in
the
same
consistent
order.
So
I
there's
there's
a
few
options
for
how
we
do
it.
One
is.
We
could
actually
on
creation
of
the
auto
values.
We
could
sort
things
on
the
way
in
just
just
to
make
sure
we
have
consistent
hashing
and
such,
but
that's
like
a
that's
a
performance
hit
right,
so
I
don't
know.
H
If
that's
worth
it,
I
did
notice
as
an
fyi
that
sometimes
attribute
keys
hash
differently.
That
was
fun.
H
H
H
A
Yeah
yeah
from
a
testing
perspective,
like
I
think,
we'd,
be
better
off
if
we
did
something
like
we
do
with
our
tracing
sdk
extensions
for
testing,
where
there's
some
fluent
tests
like
a
cert,
a
certain
j
test,
I
don't
know
what
they're
called
or
what
they're
called
in
the
search
a
but
assertion
framework
it
would
be.
A
H
A
H
Yeah,
I
guess
what
what
I
kind
of
want
to
call
out
is.
We
should
at
a
minimum
document,
all
of
those
auto
values
in
the
metrics
data
that
do
not
rely
on
hash
code
and
equals,
because
these
are
not,
you
know
well
formed
or
provided
it's.
It's
we've
designed
this
around
efficiency
and
immutability,
not
hash
code
equals.
A
Yeah
yeah
yeah.
No,
I
think
that's,
I
think,
that's
absolutely
a
good
step
and
I
think
that
would
be
a
that's
going
to
be
a
better
long-term
solution.
It's
like
don't
rely
on
this
stuff
and
here's
a
bunch
of
testing
stuff
to
help
you.
H
A
Cool,
that's
all
I
had.
Thank
you
thanks.
Josh,
that's
awesome
now
this
is.
I'm
super
excited
that
you're
digging
in
here.
It's
really
helpful
to
have
more
eyes
in
here
fresh
eyes,
especially.
H
Oh,
I
wrote
a
random
concurrency
primitive
for
exemplar
sampling,
so
it'd
be
useful,
as
somebody
who
knows,
concurrency
could
look
at
that
and
tell
me
if
I
effed
up
my
concurrency
or
sorry
whatever
the
my
old
martin,
fowler
concurrency
class
or
whatever.
A
A
I
tend
to
see
race
conditions
where
they
aren't
there,
so
I'm
kind
of
the
other
way.
I'm
like
I'm
scared
of
everything,
rather
than
expecting
we'll
we'll
see.
D
It
tends
to
be
pretty
good
at
reviewing
those
those
things.
H
All
of
the
I
I
don't
know
about
the
gc
stress,
but
there's
a
there's,
a
stress
test
in
all
of
the
instruments,
which
is
why
I've
been
focusing
on
not
changing
that
at
all
for
these
tests.
But
I
I
added
I'm
adding
a
component
to
stress
test.
This
example
stuff
anyway,
there's
the
there's
the
link
to
the
the
new
exemplar
list,
sampling
thing:
it's
literally
just
a
cast.
C
D
Yeah
mateusz
also
recently
wrote
a
tree
that
was
confusing
for
me
to
review,
so
maybe
you
could
give.
A
G
C
Well,
good
yeah
wikipedia
saves
it's
original
author
pronounced
that
as
a
tree,
but
then
some
authors
try
to
d
disambiguate
that
that
it's
not
true
and
start
pronouncing
it
that
as
a
try
but
original
pronunciation
by
the
author
is
tree.
So
sorry
for
the
confusion.
D
G
A
D
G
A
A
F
A
C
The
pleasure
is
all
mine
that
was
a
good
distraction
from
engineering.
A
Should
announce
the
release
in
cncf
slack?
Did
it
work?
I
I
haven't
well
if,
if
yeah
all
right
yeah,
I
think
so.
G
C
D
C
G
D
G
D
D
Just
real
quickly,
there
were
wow.
That
was
a
busy
a
lot
of
prs.
I
think
a
lot
of
cleanup
a
lot
of
changes
to
the
gradle
stuff
to
our
gradle,
build
moving.
Honor
has
been
moving
things
over
to
these
new
gradle
conventions.
D
Which
will
hopefully
have
some
payoff
in
the
future,
around
type
safety
of
our
files
and
modularity
of
the
build,
and
hopefully
performance,
of
the
build
in
particular,
which
is
something
we
struggle
with
in
this
big
mono.
D
Repo,
a
bunch
of
flaky
tests
and
new
releases,
a
new
instrumentation
release,
new
libraries
released
and
fixes
around
that
for
our
instrumentation.
D
Some
new
modularizing,
the
if
anybody
has
run
into
the
global,
ignores
an
additional
library
ignores
in
the
past,
which
is
a
big
central
place
where
we
put
random
classes
class
names
that
should
be
ignored
on
instrumentation,
whether
for
performance
or
for
other
reasons
that
has
been
converted
over
to
this
tri
tree,
try
by
mateos,
and
that
actually
has
some
good
performance
implications.
D
I
remember
from
the
datadog
repo
richard
doing
some
starting
doing
some
work,
similar-ish
work
of
optimizing
that,
but
the
real
benefit
is
going
to
come
later.
When
we
we
can
now
move
these
into
the
instrumentations.
D
We
can
break
it
apart
from
this
one,
a
huge
list
of
classes
and
put
those
into
the
instrumentations.
C
D
D
We
didn't
need
this
anymore
because
we
have
awesome
new
newish
smoke
tests
that
test
all
of
the
app
servers
now.
D
Anyway,
global
ignore
matcher
work.
D
A
bug
in
our
fork
join
instrumentation
that
was
causing.
I
think
I
don't
know
how
honorable
noticed
that,
but
it
was
causing
some
local
it
was
causing.
Oh,
it
was
a
sporadic
build
failure.
D
We
were
bundling
kotlin
standard
lib
inside
of
our
java
agent
distribution,
which
was
making
it
bigger.
So
now
it's
smaller
same
with
guava.
I
was
surprised
we
weren't
using
guava
anywhere.
Is
it
do?
Does
anybody
know?
Is
it
really
gone
from
our
agent
distro.
D
Awesome
so
another
drop
in
the
that's,
probably
a
good
meg
and
a
half
drop
there
in
the
agent
jar
file.
D
Size,
oh,
this
was
a
bug.
The
exporters
most
people
use
the
dash
all
jar
for
the
java
agent,
but
our
non-dash
all
was
the
same.
All
the
exporters
were
still
in
that,
so
that's
fixed
down,
and
hopefully
a
better.
It
seems
like
the
fix
here
was
a
lot
better
in
a
way
that
will
not
keep
breaking
on
this.
D
So,
like
a
google
google
cloud
or
is
that
what
you're
calling
it
now
did
we
lose
josh
here?
How
do
you.
E
A
H
Yeah
we
as
an
fyi,
we're
still
working
on
some
integration
tests.
We
have
an
issue
where,
for
some
reason,
in
the
class
loader
where
that
works,
we
can't
read
our
own
credentials,
so
I'm
trying
to
figure
out
how
that's
happening.
It's
been
pretty.
It's
been
one
of
those
really
really
weird
bugs
anyway,.
D
Yeah,
when
you
have
a
chance
check
out
now
that
one
three
is
published
check
out
the
new
extensions
mechanism,
this
is
the
where
this
is
the
going
forward
path
for
pulling.
C
D
All
right-
and
we
are
three
minutes
over
our
five
minute
cut
off,
so
let's
call
it
there
call
it
good,
yes,
jason
with
the
spicy
peppers,
all
right,
good,
seeing
everyone
yep
take
care.