►
From YouTube: 2021-06-24 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
Good
morning,
enjoying
the
last
day
of
not
too
horrible
weather.
A
I
believe
that
well,
I
I
like
as
hard
for
me
to
believe
things
that
have
never
happened.
D
A
D
A
Do
you
like
most
portlanders,
not
have
ac
yeah?
We
do
not
have
any
ac
any.
B
B
E
E
B
So
there's
there's
some
weird
stuff
going
on
with
the
jet
stream:
that's
pulling
a
giant
heat
ball
off
the
ocean
right
onto
the
top
of
us,
so
yeah
the
I
mean
the
potentially
113
I
mean
the
people
have
said
up
to
maybe
potentially
120
degrees
on
sunday,
although
that
seems
remarkably
unlikely,
which
would
absolutely
be
the
highest
temperature
ever
recorded
in
portland
by
a
lot.
E
Yeah
wow,
I
know
we
dropped
to
like
50
degrees
fahrenheit
yesterday,
from
whatever
the
hell
is
going
on,
which
is
insane
for
us
in
june.
A
F
B
B
A
Yeah
those,
but
at
least
we
had
in
our
last
house
we
had
so
we
had
two
window
units
and-
and
it
was
nice
at
least
the
at
least
you
could
sleep
at
night,
yeah.
A
All
right
we
have,
we
have
topics
the
first
one.
Well,
let's
wait
and
see
if
nikita
shows
up
before
we
talk
about,
I
think.
A
So
we
will,
I
think,
matthias,
should
just
I'll
ask
honorable
this
evening
his
thoughts.
This
was
a
continuation
from
our
oh,
but
we
discussed
it
with
honorary
earlier
this
week.
So
yeah
we
just
wanted
to
keep
his
thoughts.
A
Yeah,
so
we
had
these
before
ga
and
after
ga
labels
right
and
so
we
went
ahead
and
deleted
those,
since
they
were
not
really
meaningful
anymore.
They
were
sort
of
targeted
for
our
1-0
release,
and
so
we
were
just
kind
of
wondering
what
should
we
do
with
these
ones
seemed
potentially
useful,
but
we
don't
really
use
them.
A
I
think
honorable
was
mentioning
the
collector
is
doing
a
decent
job
with
issue
triage,
but
they
have
a
dedicated
engineering.
D
A
A
So
anyway,
just
if
anybody
has
creative
ideas
on
how
they've
seen
issue
triage
work
well
in
a
decentralized
open
source
project
like
this
send
send
us
your.
B
Yeah,
so
analog
is
in
the
process
of
so
it
only
step
back.
Aws
has
some
sort
of
non-trivial
service
based
sampling
thing
in
the
bob,
so
it's
a
remote
sampler,
so
the
process
can
query
and
x-ray
some
sort
of
service
and
get
information
about
how
I
should
be
doing
sampling,
and
so
I,
when
I
originally,
we
talked
to
onorag-
and
I
talked
about
this-
I
don't
know
a
few
weeks
ago
I
was
like
yeah.
B
B
Where
there's
some
sort
of
centralized,
I
don't
even
know
what
centralized
reservoir
means,
but
anyway,
it
sounds
like
there's
some
fairly
non-trivial
code
involved
here
and
I'm
given
the
amount
of
complexity,
that's
already
in
there
and
that's
just
kind
of
to
pull
the
data
out
of
the
x-ray
service
to
provide
it
to
a
sampler.
B
Mostly
because
it
see
it
seems
like
at
the
moment
honorary
is
the
really
the
only
contributor
that's
going
to
be
able
to
maintain
that
code,
and
I
don't
think
that
I
feel
comfortable,
even
understanding
what
it's
supposed
to
do
or
how
it's
supposed
to
work
without
a
significant
amount
of
research-
and
I
don't
have
time
to
do
that.
So
I'm
I'm
just
not
sure
that
this
is
the
kind
of
thing
that
should
be
living
in
our
code
base
would
like
other
opinions,
but
that's
kind
of
where
I'm
heading.
At
this
point.
A
Yeah,
my
thought
is
that
it's
not
so
much
that
it's
a
single
cloud
vendor
it's
that
it's
a
single
apm
back
end
vendor,
like
we
have
stuff
for
aws
right.
We
even
that
benefits
like
splunk
customers
and
benefits
other
customers,
but
the
x-ray
stuff
is
not
going
to
benefit
any
anybody
else
in
the
ecosystem,
except
for,
if
you're,
using
x-ray.
As
your
back-end
monitoring
system.
B
So
I
don't
again,
I
don't
know
anything
about
this,
which
it
should
be
clear.
So
it's
you
wouldn't
there's
no
use
case
where
you
would
use
this
x-ray,
remote
sampling,
but
send
the
data
somewhere
else.
I
would
guess
not.
I
would
guess
that
you're,
probably
right
and
that
doesn't
make
sense.
I
just
I
don't
know
anything
about
it
at
all.
A
You
could
androg
mentioned,
you
know
somebody
could
set
up
x-ray
and
just
use
it
for
the
sampling,
but
he
said
that
was
was
very.
You
know
unlikely
that
somebody
would
that's
kind
of
weird.
It
would
be
a
weird
use
case.
B
Yeah,
so
that
I
think
that
is
a
even
stronger
argument
to
the
complexity
maintenance
thing.
If
this
is
a
single
apm
vendor,
it
should
be
hosted
by
them
and
not
hosted
in
maine
hotel,
and
I
think
that
if
there
were
if
they
wanted,
if
it
wanted
to
be
put
into
the
java
contrib
repository,
I
don't
really
understand
what
the
rules
are
over
there.
B
A
I
think
the
collector
contrib
is
a
good.
We
can
definitely
use
that
as
a
bench
as
a
guideline
I
mean
since
vendor-specific
stuff
lives
in
collector
contrib.
I
don't
see
any
reason
why
we
wouldn't
fender-specific
stuff
couldn't
live
in
the
java
contrib.
E
A
E
Know
so
it
it,
it
depends
on
the
component
and
yeah
like
you
can
have
a
compo,
like
the
google
exporter,
for
example,
lives
in
collector
contrib,
and
only
google
approves
that
sucker.
So
it's
now
we
have
more
than
one
approver
on
it,
but
we're
the
only
approver
for
that
portion
of
the
repo.
E
That
said
you
know,
bogdan
tigrin
can
do
whatever
the
hell
they
want
because
they
own
the
repository,
so
they
can
merge
anything
so
they're
still
like
maintainers
have
rights,
but
from
the
standpoint
of
like
code
owners
on
on
github,
it's
acceptable
for
our
company
to
own
a
piece
in
the
collector
contrib.
I
was
actually
going
to
ask
like.
Are
you
suggesting
to
push
this
into
java
contrib,
because
I
think
that
is
fully
in
line
with
the
contrib
model
that
I've
seen
other
places?
That's
not.
E
B
B
B
A
Yeah,
I
think
the
I
mean
the
java
contrib.
The
contributors
are
nice
and
I,
I
think
from
honorable
what
he's
mentioned
in
the
past
was
the
reason
why
and
why
people
generally
want
things
in
the
kind
of
official
hotel,
repos
versus
their
vendor.
Repos
is
for
discoverability,
and
given
that
the
collector
has
gone
down
that
road
already,
I
I
have
I
don't
mind
doing
the
same
and
just
you
know
doing
really
clearly
scoped
cone
odors.
The
way
that
collector
did.
B
I
thought
that
the
discovery
question
was
supposed
to
be.
I
use
that
you
know,
obviously,
maybe
it
isn't,
but
with
the
open,
telemetry
registry
or
whatever.
That
thing
is
on
the
docks
yeah.
The
registry,
like
I
thought
this
was
the
thing
where
discoverability
was
supposed
to
happen,
because
you
could
you
could
like
type
in
aws
and
find
all
the
aws
components
here
and
they
could
be
hosted
externally.
This
doesn't
have
to
be
things
that
are
just
hosted
in
yeah
or
x-ray
or
whatever.
B
B
Cool
but
we'll
follow
up
with
the
let's
follow
up
with
honorable
this
afternoon.
E
If
it
helps
I,
I
would
also
say
that,
like
not
having
an
open,
telemetry
java
seems
like
the
right
thing
and
to
the
extent
java
contrib
is
the
right
place.
I
think
that
matches
what
the
collector
does.
It
doesn't
match
the
existing
java
contrib
as
far
as
I've
seen
it,
which
is
there
anything
but
jmx
in
there.
A
B
A
We're
planning
we
have
plans
for
it,
we're
we're
planning
to
split
out
the
a
lot
of
the
instrumentation
out
of
the
java
instrumentation
repo
at
minimum.
We're
going
to
split
out
all
of
the
old
versions
of
libraries
that
we
support
on
into
the
contrib
repo
and
probably
some
others
that
are,
and
maybe
just
keep
the
like
most
popular
ones.
In
the
main
instrumentation
repo.
E
For
reference,
though,
just
if
it
if
it
helps
the
collector,
is
booting
a
lot
of
things
out
of
core
and
in
to
contribute
prometheus
was
a
shining
example
of
something
that
you
know.
Some
people
might
say,
belongs
in
core
because
it's
one
of
our
core
integration
components,
but
I
think
they're
kicking
that
into
contrib
interesting.
E
I
don't
know
what
that
means
for,
like
the
zipkin,
jager
and
trace.
I
don't
think
anything,
but
the
implications
are
interesting.
There.
E
Again,
yeah,
so
this
is,
in
my
opinion,
way
too
large
way
too
unwieldy
and
not
at
all.
What
I
would
like
to
have
contributed
as
a
big
cl
or
big
pr,
but
what
does
cl
stand
for
change
list.
E
E
God
yeah
no,
no
one
used
perforce
back.
In
the
day
I
mean
yeah.
E
Okay,
the
only
thing
I'm
really
happy
with
is
that
you
can
actually
do
github
linking
with
the
exact
same
keyboard
key
for
this
pr,
because
pound
and
three
are
the
same
on
my
keyboard,
and
it
is
three
three
three
three
that's
the
most
important
thing
I
want
to
call
out,
so
you
don't
want
to
change
to
a
different
pr
number
because
it
would
be
yeah.
So
so,
in
terms
of
splitting
this.
A
Up,
I
just
I
think
that
would
be
a
mistake
at
this
point.
That's
just
worse
pushing
over
this
same
one,
pr
over
and
over.
E
In
any
case,
so
the
important
point
there's
there's
a
component
of
this.
I
try
to
fragment
into
four
actual
commits
that
I
think
can
get
reviewed
relatively
independently,
but
unfortunately
there's
each
one
breaks
the
build
in
all
sorts
of
fun
ways
that
involved
a
lot
of
untangling
through
the
sdk.
E
So
the
first
bit
is
we
update
the
metrics
data
model
to
use
attributes
and
it
also
adds
a
cert.js
testing
of
the
metrics
data
model
so
that
that's
what
that
one
does
there's
two
components
to
it.
I
don't
know
how
much
everyone
wants
to
lean
into
a
certain
js,
but
I
ran
afoul
of
the
dash
wall
and
java
generic
arrays
being
totally
unsafe
in
the
type
system
and
always
issuing
a
warning,
and
I
was
not
happy
about
it,
but
that's:
okay.
E
We
can
go
back
to
philosophical
debates
that
led
to
scala
like
any
time
we
want,
but
java
generics.
Okay
anyway,
I
can
show
you
an
example.
E
If
you
want
to
see
what
what
the
warning
looks
like
but
effectively
when
you
want
to
interact
with
a
a
collection
of
points,
there's
a
convention
insert
j
where
you
do
this,
like
you
pass
in
a
lambda
that
has
a
nested
assert
for
that
collection,
and
then
you
can
have
a
bunch
of
asserts
that
are
in
any
order
right
and
that's
what
I
started
moving
some
of
the
tests
to
where,
when
we
switched,
how
things
hash
with
attributes
we're
breaking
so
that
was
rather
exciting,
but
anyway,
it
involves
a
lot
of
suppressed
warnings
for
unchecked
types
and
things
that
you're
not
gonna,
see
it
in
this.
E
In
this
pr,
you're
gonna
see
it
in
the
pr
that
that
updates
the
sdk
sorry
in
this
and
that
commit.
So
if
you
look
at
yeah
the
third
one
there,
okay.
B
E
That
doesn't
bother
me
all
that
much
but
yeah,
so
you
suppress
warnings
unchecked,
pretty
much
in
all.
Almost
all
your
tests
at
some
point
this
this
is
that
one
you're
looking
at
there
is
one
we
can
talk
about
in
a
little
bit
or
in
the
next
pr,
which
is
the
actual
api
changes.
E
A
E
And
drive
josh
sure.
E
E
E
Screen,
chrome,
tab,
okay,
so
this
first
one
I'd
say
the
most
important
bit
in
this
first
one
is
come
on,
come
on
all
right.
E
So
adding
these
assertions
so
effectively
for
every
metric
data
type
there's
these
has
things
that
make
it
a
bit
easier
to
interact
with
and
there's
this
abstract
iterable
thing
where
you
can
grab
your
nested
point
types,
the
in
terms
of
changes
to
the
actual
data
model.
I
think
they're,
all
at
the
bottom.
E
You
can
see
examples
of
this
here
where
we
switch
from
labels
to
attributes
everywhere
and
oh
yeah
to
support
the
testing
library
we
had
to
like
make
some
things
public
that
were
originally
packaged
private.
I'm
not
sure
why
this
was
packaged
private,
but
made
a
few
extra
things
public
and
the
other
thing
is
we
created
this.
E
E
E
B
So
so
as
a
as
going
to
be
that
guy
maintainer,
I
would
love
a
pr
that
just
changes
over
to
attributes
with
the
existing
api
kind
of
as
step.
One.
E
So
the
I
can
do
that
when
you
switch
to
attributes
that
broke
every
single
test,
because
they
were
relying
on
right,
they
rely
on
the
order
of
the
hash
of
labels,
have
a
first
pr,
which
is
to
add
the
testing
stuff.
That's.
E
What
I
try
to
do
with
this
commit,
so
I
can
take
this
commit,
as
is,
and
I
can
actually
flesh
this
out
to
be
a
separate
pr.
That's
that's
what
I'm
suggesting
I
is,
so
this
adds
exemplars
and
it
adds
it
flips
from
labels
to
attributes,
and
I
can
go
through
and
update
all
the
tests
to
pass
with
the
new
matcher
library
and
with
the
new
with
using
attributes.
E
As
my
as
the
first
pr-
and
I
can
fragment
that
out,
that's
why
I
tried
to
bundle
this
all
at
once.
So
if
you
want
to
take
a
quick
look
at
it
great,
if
you
think
this
was
enough
of
a
demo
of
it
for
me
to
split
this
into
a
pr,
I'm
happy
to
do
that,
because
that
is
that
that's
not
so
bad.
E
B
E
Okay
cool,
so
let
let
me
walk
back
and
just
talk
about
in
case
you
want
to
like
actually
review
pieces
of
this
before
I
try
to
stabilize
them.
This
second
commit
is,
is
just
changes
to
the
api
and
there's
still
some
cleanup
I'd
like
to
do,
but
I
think
it's
in
terms
of
high
level
changes.
It's
fine
for
review
the
effectively.
E
We
got
rid
of
a
few
random
interfaces
that
were
getting
used
and
tried
to
keep
all
of
the
major
ones,
so
yeah,
there's
now
a
histogram
instrument
that
abides
by
the
bounded.
You
know
contract
this
notion
of
bounded
synchronous
instrument
I
got
rid
of,
and
I
don't
remember
why
there
was
something
I
ran
into.
That
was
a
problem,
the
javadoc
plan
to
clean
that
up
a
little
bit,
but
otherwise
I
think
this
is
ready
for
review.
The
tl
dr
here
is
counter
long
counter
up
down
long
counter.
E
Double
counter
double
up
down
counter
all
remain
exactly
the
same,
with
the
caveat
that
we
add
a
method
that
takes
in
the
context
explicitly
versus
ones
that
use
it
implicitly.
So
we
have
both
and
the
javadoc
is
updated
to
say
that
context.current
may
get
used.
If
you
call
this
method,
that's
to
make
room
for
exemplars.
B
E
Yes,
I
confirmed
with
him
there's
there's
a
line
that
says,
like
implementations,
are
allowed
to
optimize
this
passing
of
labels
so
and
I'm
like.
Does
this
mean
I
can
have
this
label
binding
stuff
that
java
already
had,
and
he
said
yes,
I'm
like
cool,
so
I
added
all
the
label
binding
stuff
back
in
because
too
much
broke.
Otherwise,
right
yeah,
I
mean.
B
E
To
metric
aggregator,
so
it's
yeah,
I
agree,
I
think
binding
is
going
to
be
important,
given
the
way
things
are
implemented
right
now.
Okay,
so
found
long
up
down
counter
same
thing.
The
other
thing
that
I
did
change,
there's
now
an
interface
for
counter.
I
don't
remember
why
we
switched
to
this
instead
of
synchronous
instrument.
There
was
some
reason
I
merged
the
builders.
E
This
is
completely
superfluous.
We
did
discuss
this
I
think
two
weeks
ago,
so
we
can
remove
it.
If
we
want,
I
personally
really
like
it.
But
again
it's
not
me.
It's
us,
so
I'm,
okay
with
removing
it.
This
basically
counter
builder,
remembers
the
instrument
type
that
you're
recording
and
remembers.
It
also
blends
in
observe
the
observer
pattern
so
effectively.
E
You
have
this
set
description
set
unit
and
then
you
can
of
longs
or
of
double
at
any
point
in
time
to
switch
which
measurement
you're
going
to
be
recording,
and
I
think,
if
I
can
get
this
observable
instrument
builder,
every
gauge
and
some
and
up
down
some
that
is
observable.
That
is
asynchronous
if
you
will
has
a
build
with
callback
method,
and
this
observable
measurement
thing
I
I
forget
what
it
used
to
be
called.
I
think
it
was
like
observed
value
or
something.
E
This
is
a
way
that
you
can
report,
doubles
and
longs
with
attributes
in
context.
If
you
want
so
anyway,
if
you
up.
B
Bogdan
and
I
had
decided,
I
think
that
having
the
generic
types
on
the
observable
ones
was
totally
fine,
even
though
it
meant
you
had
to
box
all
the
numbers
to
send
them
in
right.
Just
performance
wise.
The
boxing
there
on
the
numbers
wasn't
such
a
big
deal
doesn't
matter
as
much
interesting.
They
were
unboxed.
E
Are
they
now?
They
are
unboxed
now?
Well,
okay,
that,
yes,
they
are
unboxed
in
the
strictest
sense
of
unboxed.
E
Well,
so
when
you
send
them
in
they're
unboxed,
but
they
might
get
boxed
internally,
there's
a
box
that
every
measurement
goes
into
because
we
attach
the
double
with
a
with
a
context:
okay,
so
there
there
is
a
box.
The
box
happens
to
have
an
unboxed
double
in
it.
E
Yes,
so
in
the
strictest
sense,
yes,
it's
unboxed!
Sorry,
if
I'm
anyway,
I'm
being
too
pedantic,
let's
focus
on
the
important
things
it's.
B
E
A
different
topic,
let
me
let
me
get
you
the
so,
based
on
what
we
talked
about.
I
didn't
go
all
the
way
of
just
removing
doubles
and
ins,
but
meter
changed
the
most
and
right
now.
Meter
has
four
methods
on
it,
and
it's
going
to
be
really
hard
to
see
this.
Oh.
B
E
And
it
defaults
to
the
thing
we
expect
people
to
use
right,
so
if
we
expect
counts
to
mostly
be
longs,
it
defaults
to
counts.
If
we
expect
up
down
counts,
to
mostly
belongs,
it
also
does
count
longs
and
for
histograms
we
expect
those
to
be
distributiony,
gaugey
things,
so
those
are
doubles
and
then
gauges.
We
also
expect
those
to
be
doubles,
so
they're
doubles.
E
This
is
the
one
I
was
kind
of
unsure
of
actually
if
it
should
be
double
or
long,
but
you
know,
hopefully
that's
an
easy
change
on
our
part
before
we
actually
mark
the
stable
and
the
fact
that
we
only
have
four
calls
is
actually
not
in
this,
like
like
not
by
the
definition
of
the
specification,
but
in
the
spirit
of
the
specification.
E
So
that's
something
I
want
to
talk
to
riley
about
and
kind
of
figure
out.
It's
based
on
the
discussion
we
had
at
the
last
sig,
though
so
just.
B
On
a
on
this
note
on
that
note-
and
I
have
no
idea
how
you
would
do
this,
but
remember
you
had
written-
you
had
written
those
example
like
that
sample
code
to
exercise
the
apis.
I
think
you
close
did
you
close
that
pr?
I
did
close
the
pr,
but
I
have
it
somewhere
yeah.
I
think
it
would
be
really
cool
to
see
that
that
using
these
new
apis
see
what
that
ends
up.
Oh,
like.
E
Hey
if
you
want
rsdk
uses
this
api,
so
let
me
let
me
show
you
oh
yeah.
This
is
me
updating
the
sdk
usage
of
our
apis
to
use
the
new
api.
I
think
that's
actually
yeah.
That's
the
logging
metric
exporter
test
here
is.
E
That's
all
labels
to
attributes.
I
don't
want
the
tests
I
want
here.
Grpc
span
exporter
right,
so
here's
an
example
where
we
switch
from
having
label
names
and
labels
of
to
having
attribute
keys
and
attributes
of,
and
then
this
is
what
the
meter
builder
kind
of
looks
like
now
I'll
talk
about
that
in
a
second
and
then
here
is
actually
building
out
the
the
counters.
So
before
you
call
long
counter
builder
now
you
just
call
counterbuilder.build.bind,
so
it
looks
almost
the
same
just
with
slightly
less
verbose
name.
Here
is
binding.
E
Your
span
counter,
so
we
do
meter,
you
know
counter
builder
build
and
then
we
bind
and
again
the
I
think,
there's
a
gauge
in
here
somewhere.
I
might
have
to
find
one
of
the
other
sdk
places
to
show
you
where
gage
lives.
B
B
E
I
can
show
you
the
test
case.
If
you
want
to
see
that
for
double
builder.
E
B
E
Oh
here's
an
example
of
a
gauge
builder.
This
is
why
I
was
saying
I
don't
know
if
gauge
is
the
right
thing,
and
this
will
show
you
what
the
of
long's
kind
of
thing
looks
like.
So
this
is
where
we
had
a
gauge
in
the
executor
service
fan
processor.
E
So,
instead
of
calling
long
value
observer
builder,
you
call
gauge
builder
of
longs.
You
set
your
description
in
unit
and
then
you
build
with
callback
the
reason
we
switched
to
instead
of
calling
set
updater
and
build
in
the
previous
implementation.
We
had
this
issue
where,
if
you
never
set
an
updater,
we
didn't
know
what
to
do
and
with
this
of
longs
of
doubles,
since
you
can
chain
those,
we
don't
want
to
take
in
a
callback
where
we
don't
know
what
the
type
will
be.
E
E
B
E
E
I'm
gonna
talk
real
quickly
about
probably
the
most
contentious
thing.
I've
done,
and
this
is
to
be
a
little
hard
to
show
here,
possibly
so
this
is
this:
is
the
sdk
changes?
E
Actually?
No,
I
have
to
do
one
more
api
change.
Sorry
and
that's
around
no
op
there
was
this
default
meter.
Okay,
the
default
meter
said
that
it
was
a
no
op
but
had
a
bajillion
asserts
on
it,
like
all
over
the
place
and
threw
exceptions
and
had
a
bunch
of
tests
to
make
sure
those
search
through
exceptions,
and
when
I
looked
at
the
spec,
we're
not
allowed
to
do
that.
B
That
stuff
should
not
be
in
there
we
had
to.
We
had
to
very
studiously
remove
all
that
from
the
tracing
sdk
before
we
went
1.0.
So
yes,
this
stuff
needs
to
be.
This
is
all,
I
think,
a
holdover
from
an
open
census
that
had
a
very
different
mindset
that
it
wanted
to
blow
up
as
quickly
as
possible
when
someone
used
the
api
incorrectly
and
we've
had
to
unwind
a
ton
of
that
work
and
make
it
so
that
the
apis
are
truly
will
not
yell
at
you.
B
B
E
B
B
E
E
Some
of
them
are
not
ported
back
over
yet
because
it
just
takes
a
freaking
long
time
to
do
that
and
I'm
yeah,
but
the
I
tried
to
preserve
what
we
had
as
much
as
possible.
I
do
think
we're
gonna
need
to
go
write
some
better
unit
tests
for
things
like
that
going
forward,
because
I
think
a
lot
of
the
previous
unit
tests
relied
on
the
api
asserts
yep.
B
E
Cool
okay,
so
no
op,
basically
actually
is
a
no
op.
Now
the
other
thing-
and
someone
can
correct
me
if
I'm
wrong
there
was
the
meter
provider
global-
was
doing
some
synchronization
shenanigans
that
I
think
were
basically
not
necessary.
E
This
matches
the
open
telemetry
go
code
to
try
to
synchronize,
auto
configure
setup,
but
we
aren't
doing
any
auto
configure
setup
and
I
think
it's
just
completely
superfluous
on
git,
so
I
got
rid
of
it
to
just
use
an
atomic
reference
for
now
and
everything
seems
to
pass
swimmingly.
So
I
yeah
from
what
I
know
of
my
multi-threading
code.
I
think
this
is
totally
fine,
because
there's
basically
there
would
need
to
be
something
legitimate
here.
E
That
does
fancy
logic
and
we
just
don't
have
it
so
I
got
rid
of
that
and
yeah.
B
E
Great
okay,
the.
E
Oh
yeah
there's
one
thing:
okay,
so
no
ops
are
now
actually
no
ops,
they
do
absolutely
nothing
and
then
meter
provider.
I
wasn't
sure
what
our
long-term
strategy
is
and
we
have
an
option
here.
Is
this?
Oh,
my
gosh.
E
Let's
look
up
that,
oh
man,
that's!
Let's
do
java,
give
me
the
right
thing.
Okay,
so
before
we
had
get
with
instrumentation
name
get
with
instrumentation
name,
instrumentation
version
in
this
one,
I
I
only
have
get
with
instrumentation
version
schema
where
I
can
mark
these
explicitly
as
nullable
and
then
a
meter
builder
that
allows
you
to
build
without
specifying
and
getting
default
values
from
what
I
understand.
E
The
default
implementation
of
meter
builder
calls
that
triple
for
now,
from
what
I
understand
of
the
direction
going
forward
for
the
trace
api
is
we're
leaning
more
into
meter
builder,
but
I
wanted
to
confirm
that
before
I
made
that
kind
of
a
change.
B
Yeah,
if
you
look
at
what's
currently
on
the
main
branch,
then
I
think
there's
a
meter.
We
don't
have
the
triple
being
a
public
public
on
the
interface
we
just
have
the
old
ones
that
are
there
that
we
didn't
want
to
get
rid
of.
Although
we
could
now
get
for
meter,
we
could
get
rid
of
the
double
one
even
and
we
could
rely
on
the
builder
for
everything
since
meter
meter
stuff
hasn't
been
stabilized,
yet
yeah
yeah,
that's
kind
of
what
I'm
asking
is.
Should.
E
B
B
So
how
do
you
feel
about
having
to
use
a
builder
for
that?
So,
I'm
speaking
to
trask
and
mate
ocean
company.
A
A
I
did
like
the
idea
of
like
just
going
through
the
builder,
because
you
have
these
various
optional
parameters
and
if
we
could
have,
if
we
could
redo
it,
we
would,
I
think
we
were
thinking
we
would
drop
the
the
existing
ones.
B
So
we
definitely,
I
think,
the
the
to
my
mind
at
least
having
four
non-non-open
telemetry
internal
users
having
to
get
with
just
the
name
seems
like
a
reasonable
like
making
it
super
easy
for
people
to
use
version,
but
then
anything
beyond
that.
A
B
But
for
people
who
are
doing
manual
instrumentation,
it
seems
like
just
being
able
to
say
here's,
my
name
of
course.
Most
of
the
people
don't
know
what
the
name
means
either.
So
I
don't
know.
Maybe
I'm
totally
wrong,
I'm
not
sure.
B
And
it's
better
than
nothing
actually
if
they
pass
in
the
class
that
would
be
super.
That
would
be
more
like
a
logger
right
and
then
they
would
be
like.
Oh
yeah,
it's
just
like
a
logger.
Of
course.
Some
logging
api
is
passing
a
string
like
doesn't
java
util
logging,
I
think,
doesn't
have
one
that
passes
into
class.
You
pass
in
a
string.
B
E
Yeah
yeah
all
right,
okay,
so
the
I
think
that's
that's
that's
most
of
the
main
changes
in
the
api,
the
sdk.
The
only
thing
I
want
to
call
out-
and
I
don't
know
if
I'm
going
to
be
able
to
do
it
by
looking
at
these
files
dude
can.
I
is
there
a
way
to
collapse
all
your
files
in
github
quickly
like
if
the
one
button
claps.
E
Okay,
let's
do
instrumentation
story
so
what
effectively?
What
we
did
here
was
I
split
apart:
aggregators
and
storage
or
in
instruments.
Maybe
it's
called
instrument,
storage.
E
I
think
it's
an
interface
so
there's
now
a
an
interface
for
instrument,
storage
that
you
can
grab
all
the
metrics
out
of
and
you
can
make
a
synchronous
instrument,
storage
or
asynchronous
instrument
storage
where
you
pass
in
an
aggregator
and
effectively.
This
is
me
trying
to
tease
apart
things
for
a
measurement
processor
view
api,
but
effectively.
I
just
kind
of
split
those
apart
and
try
to
minimize
aggregators
to
just
like.
I
know
how
to
take
in
measurements
and
make
a
metric,
and
that's
that's-
that's
all
they're
meant
to
do.
E
I
need
someone
who
understood
the
previous
implementation
to
take
a
good,
hard
look
at
this
sucker
and
what
I'm
doing,
because
I
don't
know
it's
not
I'm
about
60
convinced
I
moved
it
in
a
better
direction
and
about
40
percent,
convinced
that
we're
gonna
have
to
redo
this
anyway,
when
the
sdk
is
fully
designed.
So
so
does
the.
E
E
B
B
You
and
I
are
probably
well
you're,
probably
more
intimate
with
it
now
than
I
am
only
because
I
haven't
looked
at
it
in
like
six
months
so,
but
I
I
really
want
to
try
to
set
aside
some
time,
probably
next
week
to
kind
of
dive
into
what
you
have
here
and
I'll
just
check
out
the
pr
locally
and
start,
but
I
mean
my
usual.
The
usual
way
I
go
about
this
is
like
okay,
I'm
going
to
go!
Look
at
the
code.
Can
I
understand
what's
going
on?
B
Yes,
no,
like
that,
that's
kind
of
simple,
so
yeah,
and
if,
if
I
failed
at
that,
please
let
me
know
that
was
the
goal.
I
don't
think
we've
succeeded
at
that
with
the
current
implementation,
so
hoping
it's
at
least
not
worse,
but
we'll
we'll
see.
E
Yeah
one
of
the
things
I
also
did
because
the
current
implementation
was
lacking
a
lot
of
this.
Are
they
called
aggregators
right?
Is
it
an
interface
or
is
it
class?
I
forget
it.
E
With
life
cycles,
so
it
should
be.
If
you
look
at
what
an
an
aggregator
is,
it
should
be
a
lot
more
obvious
what
the
hell
is
going
on.
I
actually
the
notion
of
a
handle.
I
changed
to
be
like
this.
Is
your
synchronous
measurement
stream
handle
of
like
where
you're
storing
things,
so
I
changed
some
names
around
with
this
and
did
a
lot
of
javadoc
to
try
to
make
it
clear.
E
Basically,
the
way
I
operate
is
I
first
go
document
what
the
hell
things
are
meant
to
be
doing
in
my
language,
and
then
I
try
to
look
at
what
I
document
and
see
if
it's
in
real
people,
language
or
just
josh
language-
I
so
I
don't
know
if
I
made
it
all
the
way
there,
but
you
can.
Let
me
know.
B
Yeah,
I
will
definitely
start
digging
in
I'll.
Probably
what
I'll
probably
do
is
I'll,
probably
just
pick
one
type
of
instrument
and
one
and
just
see
if
I
can
follow
through
everything,
end
to
end
and
then
assume,
at
least
at
the
beginning,
that
everything
else
looks
the
same
way.
Kind
of
threaded
through.
E
Yeah
yeah
there's,
there's
still
a
few
wonky
decisions
that
I
wasn't
unable
to
correct,
but
you
were
asking
about
boxing
and
not
boxing
effectively.
There's
this
there's
these
box
classes
that
store
things
now,
mostly
because
we
are
actually
attaching
exemplars
in
aggregations
and
then
for
measurement.
There's
a
box
measurement
that
attaches
context
where
we
can
synthesize
exemplars
from.
E
B
F
B
B
F
B
So
artur
bush
introduce
yourself
who
are
you
that
you're
new?
I
don't
even
wreck
your
work.
F
Oh
no,
I
I
I
introduced
myself,
I
think
two
weeks
ago.
I
I
mostly
just
lurk
though
so
that's
probably,
why
but
yeah
just
to
do
it
again,
you're
from
abdomen
from
from
appd
yeah,
okay
got
it
got
it
got
it
all.
C
Attention
to
the
container
correlation
merged.
I
wonder
if
there's
any
steps
that
we
need
to
do,
because
I
think
we
got
john's
approval
and
that's
the
build.
B
Oh,
is
that
on
the
the
resource
for
containers,
that's
right,
yeah
we
can
get
that
merged.
I
don't
think
it's
a
problem.
I.
C
Just
there's
one
follow-up
I
wanted
to
ask
about,
which
is
that
there
actually
is
an
ecs,
that's
resource,
that's
doing
something
similar.
This
is
now
more
generic.
You
know
some
other
cases
like
rio.
Should
we
leave
the
other
one
in
place.