►
From YouTube: 2020-11-12 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
A
A
So
alex
won't
be
able
to
join
the
meeting
today,
so
I'll
be
kind
of
taking
his
place.
Yes,
you
told
me
earlier
yeah
if
folks
can
add
their
names
to
the
atom.
Please
please.
C
A
B
A
B
B
Yeah,
I
don't
know
if
aaron
is
joining
us
today,
but
it's
okay.
We
can
start
cool
anyways,
so
not
much,
not
much
news
this
week
from
the
maintainers
or
the
specs
meetings.
There's
not
much
mentions
of
what
we
have
to
do
for
rc2.
B
For
those
of
you
who
don't
know
like
rc1
has
was
finalized
last
week
and
we
have
pretty
much
all
of
the
you
know,
issues
and
features
done.
I
think
there's
two
of
them
left
that
are
still
in
pr's,
but
I'm
not
too
worried
about
that
as
rc,
one
was
kind
of
like
an
internal
milestone
anyways
in
terms
of
the
ga
timeline.
B
Our
understanding
from
before
was
that
there
is
a
blog
post
that
was
shared
by
morgan,
saying
that
ga
for
open
telemetry
would
include
both
tracing
and
metrics.
B
So,
like
I've
been
talking
with
the
rest
of
the
maintainers
across
the
other
languages
and
we're
all
just
as
confused
and
like
we
don't
even
know
we're,
not
sure
what
is
the
plan
for
this
as
of
right
now
so
at
least
for
python,
I
believe
we
should
just
keep
tackling
our.
You
know.
You
know,
closing
our
issues.
B
You
know
putting
putting
out
our
prs
related
to
the
issues
that
we
have
open
because
they're
all
at
least
the
ones
that
are
marked
for
ga
are,
you
know,
definitely
the
ones
that
we
want
to
be
finishing
so
yeah.
We
don't
have
like
a
lack
of
things
to
do
or
anything.
So
that's
it
for
that.
B
Also,
I
wanted
to
talk
about
the
there's
some
progression
and
contributions
in
terms
of
metrics.
I
saw
a
couple
of
prs
put
out
by
you
know
as
far
as
chevnik
and
a
really
good
job
guys-
and
you
know
this
is
a
leading
up
to
you-
know
that
your
your
your
your
tasks
that
you
guys
are
need
to
be
finished
by
the
end
of
this
month
for
the
prometheus
red
exporter.
B
So
I
understand
that
and
I've
been
trying
to
keep
up
with
the
reviews
for
that,
but
you
know
if
we
could
have
more
reviews
for
those
that'd
be
great
if
you
guys
want
to
outline
those
pr's
link
them,
please
put
them
down
here.
So
I
see
you
guys
already
kind
of
did
that
so.
A
Yeah
sorry
later
yeah,
by
the
way,
I
think
I
owe
you.
B
Yeah
sure
no
worries
thanks
theo
yeah,
so
that's
it
for
the
metric
stuff.
Another
thing
I
wanted
to
say
about
it,
though,
however,
is
the
xdk
specs
is
still
like
in
discussion
right
now.
I've
I've
saw
that
there's.
B
I
guess
for
the
specs,
like
the
tracing
specs
gave
us
a
lot
of
freedom
in
terms
of
how
we
implement
things,
but
the
metric
specs
do
not
like
you
have
to
follow
the
specific
pipeline.
You
know
things
have
to
be
named
a
certain
thing,
so
me
personally,
I
don't
really
like
it
like
this,
but
you
know
it's
it's.
B
I
guess
something
we
have
to
adhere
to,
but
with
that
being
said,
there
might
be
future
changes
that
will
completely
erase
this
progress
that
we've
made
such
as
some
of
the
naming
stuff.
So
I
just
want
to
give
you
guys
a
heads
up
the
people
who
are
working
on
metrics
that,
like
anything,
is
subject
to
change
really
until
the
specs
is
frozen.
So
just
want
you
guys
to
keep
aware
of
that.
B
B
Cool
nice,
so
oh
yeah,
so
daniel
has
you
know,
moved
all
of
the
instrumentations
to
the
new
repo.
Now
you
know
everything
is
deleted
from
the
core
repo.
I
believe,
there's
still
like
a
couple
of
little
build
infrastructure
tasks
that
we
gotta
do
that
are
open
daniel
wanna.
You
wanna
talk
about
that.
A
little
bit.
D
Sure,
like
the
the
ones
that
I've
noticed
is
specifically
the
most
important
one.
Is
this
pr
that
alex
labeled
as
release
required?
It's
just
to
get
that
last
task
that
we
mentioned
where
the
contributor
tasks
run
on
core
prs,
and
so
I
know
you
mentioned
in
the
ghetto
chat
that
there
was
an
error
with
the
lin
tests.
This
pr
fixes
that
so
I
guess
the
better.
The
sooner
we
get
this
one
merge,
the
more
we'll
be
confident
that
pr's
aren't
breaking
core
repo
core
contrib
packages,
yeah
nathaniel.
A
Lydon,
none
of
you
noticed
but
same
thing
happens
when
euron
talks
minus
edox,
so
I
don't
know
if
you
notice
that
yeah
this
one
should
fix.
All
of
that.
I
love
that
all
right.
Okay,
perfect.
B
D
C
B
So
this
this
pr
just
to
rewrite
it's
every
time
like
once
this
goes
in
every
time.
I
make
a
pr
in
the
core
repo.
It
will
once
you
do
this,
like
change
the
environment.
To
this,
it
will
also
run
tests
from
the
from
the
contrib
repo,
but
pulling
your
current
branch
right.
D
Yep,
so
by
default
right
now
it
works
like,
if
you
just
say
master
it
just
clones,
the
repo,
the
contributor
master
and
runs
them
and
passes.
But
let's
say
you
have
a
feature
that
needs
to
update
contrib2.
If
you
don't
change
that
part,
then
the
test
will
flag
hey.
This
is
going
to
break
and
trip,
so
the
workflow
would
be
you
open
the
pr
to
fix
contrib.
You
point
this
pr
and
core
to
that
pr,
and
then
you
can
prove
like
look
all
the
tests
pass.
B
B
I
think
in
terms
of
the
workflow
like
will,
will
both
prs
ever
be
green,
though,
like
I'm,
assuming
that
since,
like
the,
if
we
make
a
pr
like
a
feature
pr
in
the
contrib
repo
right,
that's
going
to
be
red,
because
the
actual
thing
that
we
need
from
core
isn't
in
yet
right.
B
So
when
you
pass
in
the
core
repo
shot
it
it
only,
it
tests
everything
based
off
of
a
certain
pr
right
or
like
a
certain
commit,
I
guess,
yeah,
and
it
has
nothing
to
do
with
like
master
or
anything.
It
will
test
everything
on
that
pr.
D
B
So
I'm
thinking
like
if
it
does
do
a
baseline
master
and
that
breaks
because
it
doesn't
exist
in
master
like
there's,
no
way
to
circumvent
that
right,
like
we
just
have
to
make
it
so
that
it's
just
a
warning
or
something
like
that.
Does
that
make
sense.
D
B
So,
for
example,
yeah
like
if,
if
I
have
I,
if
I
need
to
create
something
on
the
main
repo
like
the
core
repo,
which
also
changes,
something
which
I
also
need
to
change,
something
that
contrib
revo,
but
it
doesn't
exist
yet
in
master
right,
so
those
baseline
tests
will
always
fail
because
you
know
it
doesn't
exist
yet
in
master,
but
it
does
exist
in
your
pr.
So
your
shot,
your
contributor
shot
tests
would
pass.
B
So
I'm
thinking
like
there's
no
really
any
good
way
to
circumvent
this,
like
this
master
test,
except
just
having
it
so
that,
like
we
only
like
it,
doesn't
the
to
be
able
to
merge.
The
pr
doesn't
depend
on
this
master.
It's
just
a
sort
of
sanity
kind
of
thing.
B
D
B
B
A
B
Way
we
can
like
kind
of
convey
this
message.
Yeah.
A
And
also
nathaniel,
f,
I've
just
executed
a
test,
and
I
see
that
this
error
is.
This
is
still
happening.
A
B
A
My
fork,
I
just
I
run
toxin
minus
you
length
and
failed,
and
I
did
the
same
thing
with
the
core
repo
in
a
new
in
a
new
folder
and
it
passed
it
works
in
the
in
the
core,
repo,
so
yeah,
something
to
take
into
consideration.
I
guess.
B
Do
you
can
you
write
the
your
observations
down
in
the
issue?
Yeah
I'll?
Let
him
here
nice
thanks.
I
don't
want
to
take
up
too
much
time.
You
guys
can
talk
about
this
offline
for
the
meeting.
If
that's
fine.
B
Yeah,
nice
so
yeah
back
to
what
I
was
saying.
Yeah
like
we
have
to
find
a
way
to
like
easily
let
people
know
I
would
suggest
just
like
modifying
the
contributing
md
or
something
in
both
in
both
repos
to
just
explicitly
exactly
just
say
what
you
just
told
me
totally.
D
B
I
think
I
think
try
to
cover
all
the
use
cases
that
could
be
possible.
Yeah
that'd,
be
great
sure.
B
Oh
yeah
and
yeah,
it
would
be
great
if
we
could
get
more
reviews
on
this
we're
trying
to
get
this
in.
So
we
can
actually
have
confidence
that
our
stuff
is
passing
so
so
yeah.
B
Oh
is
aaron
on
the
call.
Oh
nice
thanks,
erin
yeah
cool,
all
right.
We
have
what
we
have
next
libraries,
I
use
url
of
three
propagation.
Okay.
Nathaniel.
Do
you
want
to
talk
about
this.
D
Sure
yeah
thanks,
so
I
I
was
just
doing
some
tests
and
I
noticed
that
like
if
you
use
a
library
that
uses
the
requests
library
there
is
instrument
there
is
propagation.
So
if
you
need
something
to
be
stored
in
the
header
before
that
request
is
sent
off,
it
correctly
injects
into
the
header
by
calling
the
global
propagator,
but
for
other
libraries
like
the
aws
sdk
for
photocore,
it
doesn't
inject
it
into
the
propagator
because
it
uses
the
urlub3
module
directly.
D
D
So
I
try
to
add
instrumentation
for
url
lib3
and
I
think
it's
possible,
but
at
the
lowest
level,
since
it's
called
by
so
many
different
paths,
it
sometimes
doesn't
get
everything
we
need
it
to
get
so
in
the
http
attributes
spec.
It
talks
about
like
adding
the
url,
the
port,
the
host
things
like
that.
D
But
if
you
can
see
here
like
in
the
http
url,
it
requires
that
it
be
the
full
path
of
the
link.
But
when
you
use
url
connection,
it
actually
creates
a
connection
object
and
has
like
it
splits
everything
up.
It
splits
the
uri.
It
spits
the
host
it
even
splits,
the
https
versus
http
scheme
and
so
there's
no
easy
way
to
set
all
those
attributes.
D
So
I
was
wondering
asking
you
guys
opinion
versus
if,
if
I
want
to
get
propagation
with
a
library
like
boto
core
which
uses
url
of
3,
would
I
be
better
off
instrumenting
this
library,
even
though
we
couldn't
get
most
of
the
attributes,
the
goal
would
be
just
to
get
the
propagators
at
least,
or
should
I
just
you
in
like
put
the
propagators
into
the
boto
core
library
itself
it
and
like
have
it
intercept
its
creation
of
the
headers
and
inject
it
using
a
pro
global
propagators
that
way.
B
So
I
think,
in
terms
of
the
attributes,
I
think
there
are
also
other
libraries
that
don't
have
access
to
http
url
and
it's
that's
like
a
common
scenario
so
like
we
actually
have
to.
B
Instead,
as
you
said,
the
reason
why
these
are
not
mandatory
is
because
you
can
pass
in
like
components
of
the
entire
url
as
attributes
and
that
the
user
will
recognize
this
themselves,
so
we
don't
actually
have
to
build
it
right.
We
just
pass
in
the
pieces
that
can
form
the
actual
entire
url
right,
like
the
scheme,
which
is
the
part
after
the
http.
You
know
net
pure
name
that
port.
So
as
long
as
like
some
subset
of
these
are
available,
I'm
pretty
sure
you
can
form
the
entire
url.
D
B
If
they're
not,
then
then
yeah,
we
there's
that
that's
strange
because,
like
whatever
library
is
like
it
has
to
have
a
way
to
to
form
this
right
like
if
it's
an
http
library.
D
B
You
have
to
have
access
to
the
like
if
you're
talking
about
like
a
client
yeah,
you
have
to
know
what
what
endpoint
you're
you're
hitting
right
like.
D
Definitely
definitely
I
I
guess
sorry
what
I'm
saying
is
that
like
it,
it
always
knows
it.
Just
sometimes
does
it
in
different
ways
like
the
same
parameter
is
used
for
like
either
the
full
url
or
sometimes
it
uses
the
parameter
for
just
the
target
and
then
gets
the
host
from
somewhere
else
on
the
ski
room
somewhere
else,
so
it's
just
not
as
consistent.
B
I
guess,
as
I
would
like
to
see
like
where
to
get
it
right,
yeah
I
I
guess
it
would
just
be
on
us
then
to
like
handle
those
use
cases,
because
as
long
as
the
data
is
there,
like,
you
know,
we
can't
really
say
like.
Oh
it's
it's
kind
of
complicated,
so
we
don't
want
to
it's
not
like
a
one-to-one
mapping.
We
still
have
to
kind
of
populate
these
fields.
D
B
It's
a
problem.
Second
question
that
I
have,
I
guess
is
so
does
that
mean
that
you're
gonna
be
recommending
people
to
use
the
your
lib
instrumentation
instead
of
photocore
or
is.
D
So
if
you
want
to
insert
a
header
into
the
call
that
botocore
is
going
to
make
to
the
aws,
then
you
would
do
that
through
the
propagation
like
creating
a
custom
propagator.
But
at
no
point
during
the
flow
of
you
using
botocore.
B
D
B
D
B
D
D
Okay
thanks,
I
like
that's,
that's
really
helpful.
That's
what
I
was
hoping
to
get
your
guys's
opinion
on,
because
even
one
other
thing
I
was
worried
that
that
you
are
a
liberty
if
some
because
a
request
uses
url
of
three
underneath.
Yes,.
B
D
B
Just
undocumented
behavior,
you
know
like
we
don't
want
people
sharing
the
same
code
path
that
is
instrumented
twice
so
yeah.
B
All
right
nice,
because
moving
on
does
anybody
else
have
any
other
topics
they
want
to
talk
about.
Before
going
to
the
prs
we
gotta,
we
gotta,
we
gotta
get
a
crapload
of
pr's.
Oh
yeah,
yeah,
okay,
cool.
B
Let's
just
go
on
right
ahead,
so
I
think
I
I
listed
a
bunch
of
pr's
from
you
know
like
older
to
newer
this
one
from
away.
Is
it
way
in
the
call?
B
Oh,
it's
in
the
call.
Yet
you
know
if
this
has
been
out
for
a
while-
and
I
saw
that
diego
made
a
comment
on
this
already
so
yeah.
Oh,
if
you
could
address
that
that'd
be
great
yeah
and
I
would
get
I
think
I'll
get
alex
to
review
this
as
well,
because
he's
assigned
to
this
so.
H
Okay,
I
think
oh,
it
looks
like
diego-
has
added
some
comments
yeah,
so
I
took
care
of
the
major
comments
that
diego
had,
which
was
mainly
to
replace
hardcoding
with
entry
points
system.
So
that's
there.
I
haven't
looked
at
these
comments
yet
but
looks
like
looks
like
nothing,
major
I'll,
take
a
look
after
the
call
and
try
to
get.
A
Yeah,
it
is
just
a
typo
away,
so
it's
just
one
character
fix
once
you
do
that
I'll
move
this
again.
Okay,
all
right!
Thank
you.
B
A
Okay,
yeah,
what
I
mean
is
that
what
we're
doing
there
is
that
we
are
adding
this
string.
That
is
basically
celery
right
and
this
is
going
into
the
core
instrumentation.
So
I
think
that
we
should
strive
to
keep
the
core
instrumentation
part
of
the
of
open,
telemetry,
python,
agnostic
and.
A
Separate
from
the
instrumentation,
so
this
will
probably
mean
that
because
some
instrumentations
may
require
some
kind
of
hook
or
some
function
to
be
executed.
B
A
B
Awesome,
can
you
maybe
add
an
issue
for
this
or
a
way
out,
an
issue
for
this?
If
we
identify
this,
as
I.
B
B
B
Add
a
raise
support
for
a
reaction
all
right,
so
this
is
just
one
of
the
rc
rc2
tasks,
I
guess
or
just
the
tasks
labeled
in
the
matrix.
I
haven't
taken
a
look
at
it
too
much,
but
it
should
be
pretty
straightforward.
B
I
think
right
now,
it's
just
reviewed.
It
just
needs
more
reviews,
pretty
straightforward.
B
Yeah,
just
what
is
this
nonsense?
Okay,
yeah?
It's!
If
we
could
get
people
to
look
at
that,
I
think
alex
and
aaron
are
assigned
to
it
already
so
nice.
B
Next,
oh
yeah
same
thing:
it's
a
it's
another!
Zip
can
explorer
one
so
not
much
to
be
said
there.
Okay,
so
this
vr
is
one
of
mine,
thanks
aaron,
for
taking
a
look
at
this.
Basically,
this
is
part
of
the
we're
trying
to
have
a
consistent
way
of
recording
exceptions
and
setting
spans
when,
like
an
error,
is
thrown
within
instrumentation
or
like
pretty
much
whenever
like
within
the
span
right
now,
we
have
two
methods
of
handling
the
exception.
B
I'm
sure
I
think
diego
made
these
changes,
but
one
of
them
is
because
users
can
use
start
span
and
the
span
itself
is
the
context
manager,
whereas
we
can
also
use
start
as
current
span
or
as
use
span
is
the
context
manager.
So
there's
two
different,
like
logical
paths
and
two
different
ways
to
actually
capture
exception
information,
so
we
kind
of
just
want
to
be
consistent
for
that.
So
like
this
is
the
first
part
of
this
issue.
B
The
second
part
I
will
be
going
through
all
the
instrumentations
and
making
sure
that
we're
doing
the
same
thing
for
each
of
them,
but
for
at
least
this
part,
I'm
just
making
so
that
the
start
current
span
and
star
span
all
have
the
same
parameters
in
order
to
to
to
execute,
because
they
should
be
pretty
much
the
same
execution
path
as
well
as
adding
this
exception
that
escaped
span
attribute
when
we
do
record
exception.
This
means,
when
an
exception
has
like
left
the
scope
of
the
span,
not
on
purpose
but
due
to
the
exception.
B
B
All
right,
this
is
diego's
pr.
Oh
my
god,
thanks
for
adding
this
holy
like
we
were
waiting
on
this
for
so
long.
Do
you
want
to
talk
about
this
for
a
bit.
F
Yep,
basically,
the
specification.
A
Says
that
we
gotta
have
fields,
method
or
something
that
returns
all
the
keys
that
are
used
by
the
code
of
inject
to
add
stuff
into
the
carrier,
so
the
I
think
that
if
I
understand
this
specification
correctly,
the
idea
behind
this
is
that
you
can
query
this
fields,
method
or
function,
and
then
you
can
know
what
inject
will
use
so
that
you
can
remove
those
keys
from
a
carrier
if
you're
going
to
use
it
if
you're
going
to
pass
it
to
inject
more
than
once
or
if
you
want
to
do
something
with
carrier,
and
you
don't
want
to
mess
with
inject,
which
may
do
or
may
have
done.
A
So
I
later,
if
you
can
go
back,
please
yeah.
Thank
you.
Yes,
I
added
this.
I
already
have
a
review
from
alex.
I
left.
I
left
the
file
there
that
should.
A
Yeah
yeah
and
the
rest
is
just
there's
an
important
comment
that
I
want
to
make
here.
I
base
myself
in
the
go
implementation,
but
if
I
understand
they
go
into
picture
correctly,
they're
returning
the
these
fields
that
inject
uses
as
a
list,
but
I'm
doing
that
as
a
set.
A
I
think
it
is
a
common
mistake,
but
to
use
a
list
when
you
want
to
represent
a
bunch
of
things
where
the
order
doesn't
matter.
You
should
all
only
use
a
list
if
the
order
matters.
This
is
not
the
case,
so
I'm
using
a
set,
that's
different
from
the
go
specification,
but
I
think
this
is
right,
of
course,
which
I
mean
if
you
have
a
different
opinion,
but
I'll
explain
that
in
the
comments
so
that'll
reviewers.
A
A
There
the
go,
implementation
does
not
have
duplicate
fields,
but
they
still
use
a
list.
I
mean
they
kind
of
remove.
A
But
still
create
a
list
and
that's
that
that's
interesting.
I'm
no
go
expert,
but
I
think
that's
what
they're
doing,
but
in
our
case
we
should
use
a
set
also,
I
think
the
algorithmic
complexity
of
looking
into
sadisol
one
and
looking
at
listis
of,
and
so
this
is
very
performing.
B
Yeah
like
if
they're
going
to
be
removing,
duplicates
like
it's
not
a
single
pass
anymore.
I
guess
right.
Yeah,
they're,
just
going
to
check.
E
B
E
B
Okay,
cool
yeah
that
that
sounds
that
makes
sense
to
me.
I
can
take
a
look
at
this
yeah.
A
I'll
be
fixing
those
issues
that
cool
thanks.
J
B
Do
you
want
to
just
address
what
this
is
for
those
people
who.
J
Don't
have
context
yeah,
so
you
know
diego
opened
some
issues
wanting
to
make
the
metrics
sdk
like
more
in
line
with
the
with
the
spec,
and
so
one
thing
that
the
spec
currently
has
is
like
the
need
for
like
an
accumulator,
which
we
already
have
is
just
called
the
meter
which
implements
the
you
know,
meter,
api
or
meter
interface
in
the
metrics
api,
and
so
since,
like
you
know,
I
had
like
a
table
and
then
I'm
like
this
is
a
lot
of
things
that
the
accumulator
doesn't
go
and
also
does
a
lot
of
the
things
that
is
defined
for
the
accumulator
in
the
spec.
J
A
I
think
I
owe
you
a
review
so
I'll
be
I'll,
be
doing
that
today
and
I'll
be
chiming
in.
I
think
it
is
important
for
us
to
be
specification
compliant,
but
before
I
make
a
statement,
I
like
to
read
the
rest
of
the
comments.
J
J
B
Should
look
at
the
specs,
not
the
go
implementation,
we
can
use
the
implementation
for
implementation,
detail
ideas
like
if
what
they're
doing
is
cool
and
like
we
think
it's
efficient,
but
in
order
for
like
the
actual
source
of
truth,
and
also
if
it
won't
bite
us
in
the
ass
in
the
future,
because
if
we
implement
a
certain
thing
in
a
certain
way
that
goes
doing,
but
it
doesn't
follow
the
specs,
then
it
will
us
over
yeah.
A
Right,
yeah,
you're
right.
In
fact,
I
think
I
should
fix
my
issues
to
say
that
the
specification
says
that
there
is
an
accumulator,
because
it
does
the
specifications.
B
Yes,
yes,
I
agree
that
so
this
is
a
valid
issue.
It's
just.
We
should
be
following
because
the
spec
says
so
not
because.
B
Cool
thanks,
diego
and
in
terms
of
as
for
what
you're
talking
about
yeah
so
yeah.
This
is
this.
This
is
like
the
only
thing.
This
naming
thing
that
I
feel
like
is
a
bit
of
a
nonsense
kind
of
thing.
It's
like
I'm,
not
exactly
sure
why
they're
introducing
this
whole
new
terminology,
where
meter
implementation
makes
so
much
more
sense
right,
like
if
everything's
just
a
meter,
you
know
like
everyone
knows
what
a
meter
is
and
also
the
same
thing
with
tracer
right.
We
have
a
tracer
sdk
implementation.
B
It's
also
called
tracer
right,
so
I
don't
know
why
we
don't
follow
the
same
mechanism
for
that,
and
it
looks
like
aaron
has
made
a
comment
here,
and
you
want
to
elaborate
about
what
you're
talking
about
here.
C
Yeah,
that's
actually
I'm
linking
to
your
comment
leighton
but
yeah.
Basically,
I
think
the
I
think
the
accumulator
and
like
the
sdk's
implementation
of
the
meter
api
are
separate
conceptually,
but
they've
been
done
together
in
the
go
sdk
and
sort
of
in
the
python
one
as
well,
whereas,
like
I
think
john
has
john
watson.
Who's
working
on
java
said
that
they're
separate
and
he
was
also
pushing
for
having,
like
the
accumulator,
be
a
separate
making
the
specification
more
like
conceptual
rather
than
like.
You
have
to
right.
C
C
B
C
Mean
I
have
looked
at
the
go
code
for
this
like
a
month
ago,
and
I
thought
it
was
a
little
confusing
to
me
because,
like
you
said
coming
from
tracy,
I'm
expecting
it
to
just
be
like
a
subclass
of
trace
or
something
that
was
the
trace
trace.
Sorry,
tracer
interface,
so
I
do
agree.
It's
a
little
confusing
and
even
if
like,
even
if
you
just
rename
it
and
then
we
still
call
it
meter
like
we
don't
update
the
documentation.
C
Yeah
yeah,
so
I'm
not
trying
to
say
as
far
that
we
should
like
close
your
pr
by
any
means.
I
think
I
think
it's
important
and
definitely
like
a
an
inconsistency
that
we
have.
I
guess
we
have
to
decide
whether
or
not
we
want
to
separate
out
the
accumulator
behavior
from
the
from
the
meter
behavior,
so
that
we
can
have
two
separate
things
to
keep
them
in
your
name
or,
if
that's
not
important
to
us.
B
It's
this
is
the
downside
for
like
being
a
language
that
have
implemented
something
before
the
specs
has
come
out.
It's
like
all
of
us
are
doing
something
a
certain
way
like
theoretically,
like
none
of
us
would
have
made
anything,
and
then
java
would
be
wouldn't
be
so
insistent
on
like
not
changing
the
way
that
they're
doing
things
right
yeah,
but
it
is
what
it
is
right
now.
B
So
I
guess,
like
the
golden
truth,
like
the
thing
that
we
should
be
thinking
sticking
to
is
like
we
should
always
follow
what
the
specs
is
doing
right
and
we
always
have
room
to
like
change
it
back
later.
So
I
think
for
now,
like
at
least
you
know,
while
the
metric
spec
system
flux,
we
can
still
go
ahead
with
this
change,
and
this
is
a
great
table
by
the
way.
This
is
a
this
makes
a
lot
of
sense
like
to
why
we're
doing
this,
at
least
for
now.
B
C
C
Can
I
make,
can
I
make
one
other
possible
suggestion,
and
this
is
not
I'm
not
saying
we
should
do
this.
I
just
want
to
just
throw
this
out
there,
but
what
if
we
called
it?
Something
like
a
meter
accumulator
so
that
it's
clear
that
it's
doing
both
the
sdk?
C
Sorry,
it's
implementing
both
the
meter
api
and
doing
the
accumulator
like
implementation.
Maybe
that
would
get
rid
of
the
confusion
from
people
who
are
like
getting
an
instance
of
this
and
like
what
the
hell
is
accumulator
right.
B
B
So
if
get
meter
is
already
the
function
and
if
we
introduce
something
called
the
meter
accumulator,
it
would
still
be
like
meter
underscore
accumulator
equals
meter
right
like
it
doesn't
really
like.
We
have
some
hybrid
thing
now,
which
will
clear
up
the
confusion
about
what
an
accumulator
is,
but
it
still
doesn't
clear
up
the
confusion
about
like
how
I
get
it
right
and
how
that
maps,
to
the
object
that
I'm
creating
so.
G
B
Yeah,
we
just
don't
know,
I
don't
want
to
add
like
any
more
overhead
or
work.
C
A
E
C
C
I
think
we
could
also
leave
it
as
meter
and
add
a
comment
that
says
this
implements
the
accumulator
like
conceptually,
because,
like
that
they're
really
the
sdk
spec
isn't
saying
like
you
have
to
have
a
class
name.
This
is
saying
you
have
to
have
this
conceptual
thing
right.
B
Too,
that's
why
I
thought
too,
but
like
it
seems
like
it's
so
explicit.
You
know
exactly
like
yeah
like
I.
I
always
thought
that,
like
specs
are
supposed
to
be
like
that
right,
they're
supposed
to
be
just
conceptual
stuff
like
the
tracing
stuff,
the
tracing
sdk
specs,
does
a
really
great
job
with
this,
because
they
just
name
the
components
that
we
need
and
that
we
implement
it.
However,
we
want
right
like
we,
we
we
talk
about
the
relationships
and
stuff.
B
It's
just
that
tracing
is
a
lot
more
like
it
makes
it
it's
a
lot
easier
to
build
like
it
makes
a
lot
more
sense.
B
You
know
each
component
does
the
specific
thing
and
like
metrics
is
like
the
api
and
sdk
were
completely
made
up
by
by
josh
really
right
so
like
only
he
has
an
understanding
of
why
we
need
these
components
and
they
work
in
a
certain
way
and
stuff,
and
he
pretty
much
what
he's
doing
right
now
he's
trying
to
persuade
the
community
and
like
this
is
how
we
have
to
do
metrics
right
now,
which
is
why
we
need
it
to
be.
He
needs
it
to
be
so
explicit,
like
this
look
at
this.
C
Well,
I
mean
look
at
this.
It's
also
like
he's
done
it
in
go
right
and
then
go
you
can't.
As
far
as
I
can
tell
you
can't
just
subclass
something
you
basically
just
do
something
else
that
implements
that
interface
right.
So
in
terms
of
like
composing
behavior,
you
can't
just
subclass
something
to
get
so
so
I
think
that's
the
reason
that
a
lot
of
these
things
are
implemented.
C
A
H
A
Trying
to
fix
this
issue
of
the
timestamps
in
the
metrics,
I
had
to
go
and
look
for
inspiration
from
what
goal
was
doing
and
that's
a
pretty
common
use
case
to
take
a
look
into
the
implementation.
That
already
has
the
feature
that
you
want,
and
I
noticed
there
how
hard
it
was
to
map
concepts
when
the
names
are
not
matching
so
right,
at
least
at
least.
We
should
strive
to
document
somewhere.
A
This
thing
that
we
have
in
python,
be
it
a
modular
file,
a
dictionary
or
whatever
represents
this
concept
in
the
specification.
B
Right,
I
actually
have
no
problem
with
changing
the
names
to
match
what
goes
doing
like,
like
you
said
it's
very
complicated
to
you,
know,
go
back
and
forth
and
like
map
these
certain
things,
so
I'm
like
pretty
indifferent
about
the
names.
I
don't
really
care
about
those
it's
kind
of
just
stuff
like
I
don't
know
if
things
are
supposed
to
be
explicitly
like.
Oh,
this
is
what
you
have
to
do
it
or
if
this
is
like
what
aaron
said.
B
There's
concepts,
for
example
like
this
metric
descriptor
thing
right,
I
would
I
would
I
wasn't
planning
on
adding
something
like
this
right,
like
python
can
have
like
many
like
you
know,
key
value
arguments
and
like
optional
parameters
and
like
we
don't
usually
have
in
a
class
to
encapsulate
like
a
bunch
of
optional
parameters
right
so
like
I
wasn't.
B
On
having
this,
but
this
is
like
other
languages-
don't
have
this
and
I
don't
know
if
this
is
him
like
or
the
specs
outlining
like?
Oh,
you
have
to
have
this
concept,
or
else
like
you
know,
people
should
know
what
a
descriptor
is,
and
if
you
don't
have
it,
then
your
implementation
is
wrong.
Right,
I
don't
know,
but
that
stuff
it
should
be
specific
to
the
language
or
like
specific
to
the
implementer
like
we.
F
A
I
think,
of
course,
it
will
not
make
sense
for
all
the
languages
to
have
a
101
mapping
from
the
concepts
that
are
defined
in
specification
to
the
actual
code
objects
like
classes
or
whatever
right,
but
I
think
we
should
have
a
one-on-one
mapping
of
documentation
through
the
concepts
that
are
here
right
and
with
that
I
mean
this
thing
represents
an
accumulation
of
this.
Other
thing
represents.
B
B
I
actually,
I
actually
prefer
more
to
have
all
of
us
just
change
all
of
our
names
to
to
match
what
the
specs
is
right
now,
even
if
it's
like
gonna
change
in
the
future,
even
though
we
think
it's
wrong
pythonically
and
then
once
the
metric
specs
is
finalized
and
any
discrepancies
we
may
have,
then
we
just
do
another
pass-through
and
change
it
then,
because
that
way
we
don't
have
to
always
have
to
keep.
You
know,
oh
okay,
I
have
this.
I
have
a
batcher
here.
What
does
that
actually
mean
in
the
specs?
B
B
Yes,
yeah:
don't
try
to
introduce
anything
pretty
much
like
the
reason
why
we're
pushing
metrics
quickly,
right
now,
even
before
the
specs
is
finalized,
because
we
have
like
us
certain
customers
or
use
cases
that
we
need
to
light
up
this
entire
pipeline.
So
as
long
as
like
an
end-to-end
thing
can
be
done
like
I
don't
care
what
these
are
called
right
now.
Does
that
make
sense
like
we
need
a
prometheus
right
exporter
and
we
need
like,
oh,
like
certain
aggregations
to
be
there.
B
C
G
All
right
cool
sounds
good.
Nice
is
this
synchronous
and
asynchronous
instrument.
The
metric
and
observer
on
the
python
side.
B
Yes,
it
is
for
those
yeah.
Once
again,
I
don't
really.
I
don't
really
care
what
it's
called
synchronous
or
asynchronous
or
whatever
counter
up
down
counter
observer
like
it
doesn't
really
matter
to
me
like.
If
someone
wants
to
change
it,
go
ahead
like
you
could
create
vr,
but
like
right
now,
it's
doing
exactly
the
same
thing,
and
I
don't
have
a
strong
opinion
about
that.
So
yeah,
okay,
cool,
we
have
10
minutes
left
yeah.
We
should
have
enough
time
it's
some
flight
attributes
for
both
core
right.
D
It's
more
just
like
a
plug.
I
wanted
to
talk
about
getting
this
the
core
instrumentation
before
kind
of
looked
through
all
the
possible
params
that
you
could
be
providing
for
the
apis,
but
I
we
I
don't
know
if,
like
so
in
this
pr,
I
mostly
just
rely
on
certain
attributes
being
populated
in
the
photocore
library
classes
and
instances
and
then
just
pull
them
out.
D
So
the
things
that
are
key
and
important
to
hopefully,
every
instrumentation,
just
gets
pulled
out
like
aws
url,
like
the
time
that
it
was
done
like
bucket
name
or
cue
name
or
table
name
if
they're
there.
So
this
is
just
a
quick
plug
to
ask
for
reviews
on
my
pr
please
to
people,
look
at
it
and
see
if
this
is
something
that
they
would
want.
It
mostly
deletes
code
that
we
don't
need
on
the
on
the
voter
core
instrumentation
so
and
it
just
adds
a
bunch
of
tests.
B
Hey
so
nathaniel
we
do
something
similar
for
the
pretty
much
every
instrumentation
has
like
http
dot,
whatever
right
for,
like
the
http
instrumentations
and
like
for
exporters
right.
Some
people
might
not
care
about
that
right.
So
I
actually
don't
mind
having
a
lot
of
stuff
populating
the
span
attributes
because
it's
like
just
a
superset
like
it's
available.
If
you
want
this
data,
then
yes,
if
you
can
keep
it,
if
you
don't
want
it,
I
feel
like
they
should
handle
that
on
the
exporter
level,
but
that's
just
my
opinion
right.
So.
B
D
Thanks
but
yeah,
just
if
anyone
had
time
to
review
this
that'd
be
really
helpful.
B
Yeah
sure
looks
like
owie
and
alex
are
assigned
to
this,
so
I
think
they'll
just
get
to
it
when
they
have
the
time.
D
Sure
not
all
of
it's
just
removing
it.
Some
stuff
like
in
the
pictures
that
I
provided
there
below
the
I
changed
the
span
kind
to
client
so
that
instead
of
you
see
here
that
there
was
a
call
to
s3
and
it
didn't
get
at
least
on
the
x-ray
side
change
to
a
separate
client,
because
the
span
kind
was
consumer,
I
think,
but
reading
the
specific
specifications.
I
think
it
fits
the
description
of
a
client
span.
So
yeah
now.
G
Change
I
I
added
other.
I
tried,
I
renamed
the
other
metrics
experts
to
exporters
to
be
consistent,
and
then
I
realized
that
it
was
named
metrics
to
distinguish
it
from
the
hispanics
folder.
So
I'll.
Just
remove
that
change
and
simplify
it
down
to
just
changing
metric
record
record.
B
Right
yeah,
I
think
the
metric
recorder
export
record
is
good,
like
that
makes
sense
to
like
we
talked
about
before.
We
just
want
to
match
everything
that
the
specs
is
doing
so
to
cover
our
bases,
but,
like
you,
do
bring
up
a
good
point
also
because,
like
in
the
specs,
it
says
exporter
right,
like
it
explicitly
says
exporter,
but
it's
like
like.
I
feel
like
that's
wrong.
Like
you
know,
it
doesn't
really
tell
us
much
because
this
is.
G
B
J
J
During
the
the
course
of
this
sig,
so
I
got
some
good
the
hell.
I'm
excited
it's
not
even
in.
J
C
B
Yes,
okay
yeah,
so
this
is
kind
of
the
out.
So
I
don't
know
as
far
if
you
follow
the
conversation
between
me
and
yusuke,
but
pretty
much.
It's
like
you're
renaming
the
record
class
to
accumulation
which
is
fine,
and
so
it
might
be
a
bit
out
of
a
scope
of
this
pr.
But
if
you
take
a
look
at
accumulation
here,
it
says
it's:
a
like
a
container
for
instrument,
label
set
resource
and
aggregator,
and
we
don't
have
resource
currently
today
and
I
think
yusuke
outlined
that
somewhere
in
the
specs.
B
It
says
the
accumulator
must
provide
the
option
to
associate
a
resource
with
the
accumulations
reproduces,
so
I'm
assuming
the
accumulations,
must
have
a
resource
inside
them.
So
currently,
today
are
the
processors
you
pass
in
the
what's:
it
called
the
resource
into
the
meter
provider
and
then
a
meter
provider
just
creates
a
processor
with
the
resource
attached.
So
right,
it's
assumed
that
it's
never
going
to
change
or
anything
right.
So
it's
either
a.
B
We
can
make
a
change
to
the
specs
to
remove
this
resource
thing,
because
why
would
we
have
this
if
the
resource
will
never
change,
but
based
off
these
comments,
I
think
they're
trying
to
think
about
in
the
future
whether
you
know
it.
It
could
be
like
extendable
and
stuff
like
that,
if,
like
different
meters
have
different
resources
and
stuff,
you
know
I.
C
Mean
it's
technically
associated
right
like
you
can
get
it
through
the
processor.
I
believe
right
yeah,
so
I
mean
technically
we
do
meet
that
requirement
right.
B
Right,
but
I
don't
know
if
like
because
like
if
we're,
if
we're
saying
like
we
have
to
strictly
follow
what
the
specs
are
saying,
then
the
resource
would
be
attached
to
the
accumulation
and
then
in
that
case
we
don't
need
the
resource
to
be
part
of
the
processor
anymore
right.
C
B
B
Resource
as
part
of
the
accumulation
like
we
just
take
that
right,
so
we
don't
need
the
resource
to
be
part
of
the
processor
anymore,
which
is
the
change
that
I
am
I'm
voting
for.
You
know
just
take
out,
take
it
out
of
the
processor
but
either
way
like.
Maybe
we
need
a
more
discussion
for
this,
but
either
way
it's
like
kind
of
outside
of
the
scope
of
this
pr
so
yeah,
that's
that,
which
is
why
I'm
okay,
with
every
with
this
rename
change
right
now,.
B
Cool
makes
sense,
cool
cool.
I
swear.
Do
you
understand
what
we
just
talked
about
about
this
potential
change?
Yeah,
I
think
so
yeah.
I
think
I
followed
okay
cool.
Could
you
make
an
issue
outlining
that?
So
we
don't
forget
about
this
all
right.
Okay,
all
right
sounds
good
yo
and
I
don't
know
what's
going
on
here,
like
you
guys
see
like
this.
No,
like
merge
thing
right
now,
so
I
pretty
sure
I
can.
B
And
squash
it
yeah
so
anyways
yeah
I'll.
Take
a
look
at
that
after
I
think
we
have
like
one
minute
left
so
we'll
just
go
through
this
issue.
Real
quick,
just.
J
Real
quick,
this
is
just
while
I
was
working
on
a
fork.
I
found
out
that
if
you
pushed
an
open
pr,
it
runs
test
twice
under
like
triggers
and
stuff,
and
so
instead
of
like
you
know,
22
checks
or
you
have
like
42.
J
So
I
was
just
wondering
you
know,
if,
like
I
had
a
proposed
solution
and
nathaniel
also
had
a
a
solution
that
he
was
thinking
of
like
both
work.
I
was
just
wondering
if
you
know
people
were
okay
with
me
being
compared
for
this
or
if
they
leaned
one
way
or
another,
for
how
they
wanted
to
change
the
choice.
B
J
No,
no,
so
it's
like
okay,
if
you
have
an
open
pr
and
you
let's
say
you
push
and
you
change,
the
workflow
will
trigger
twice
until
under
two
new
triggers
one
under
the
pull
request
trigger
and
then
it'll
trigger
again
under
push,
because
the
way
push
is
set
currently
is
that
it's
always
triggered,
except
on,
like
a
release,
branch
right.
B
Right
because
I
think
it's
only
triggered
on
push
to
master.
J
Oh,
no,
that
that's
the
change
I'm
I
want
to
like
propose
and
there's
also
a
chore
listed
by
alex.
I
see
where
he.
B
J
To
do
this
as
well,
but
then
there's
some
discussion
about
how
some
people
like
they
don't
like
opening
up
prs
on
their
fork
and
they
just
want
stuff
to
run
and
therefore
just
just
when
they're
pushing
so
there's
like
an
alternative
solution.
So
I'm
just
wondering
you
know
if
people
had
any
thoughts
either
way.
D
B
B
Okay,
yeah.
I
I
haven't
taken
a
look
at
this
fully
but
I
think
that's
a
good
idea.
We
don't
want
to
have
two
tests
running
or
two
blocks
running
yeah,
so.
B
All
right,
nice,
it
looks
like
we're
out
of
time.
If
no
one
else
has
anything
pressing
to
talk
about.
I
will
see
you
guys
next
week
thanks.
Everyone.