►
From YouTube: 2020-11-05 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
All
right
damn
looks
like
we
got
a
full
house
today,
so
cool,
let's
start
by
a
few
guys,
don't
mind
just
filling
out
the
attendees
list,
so
we
know
who's
new
and
stuff.
A
A
Looks
like
ted's,
not
here,
so
that's
fine.
Do
we
have
any
new
people
in
the
call?
Who've
never
joined
a
sick
before.
A
Okay
anyways,
we
could
just
start,
then
did
anybody
add
this
open
tracing
bridge
topic
yeah.
I
did
oh
that
was
you.
B
Okay,
sorry,
I
totally
forgot
to
put
my
name
next
to
it.
Yeah
I
just
I.
I
just
noticed
that
the
there's
a
discrepancy
and
the
in
the
name
that
we're
using
compared
to
what
all
of
the
other.
Well
it
it's
in
there's
an
inconsistency
in
the
naming
of
the
open
tracing
bridge.
So
javascript
calls
it
open,
open,
telemetry,
color
package,
open,
telemetry,
shim,
open
tracing.
B
We
call
ours
like
open,
telemetry,
instrumentation,
open
tracing
shim.
I
think
right
and
go
calls
it
the
bridge
open
tracing
package,
and
I
guess
I
just
wanted
to
to
call
out
that.
Maybe
we
should
be
consistent
here,
because
this
actually
caused
some
confusion
in
the
migration,
because
it
just
got
thrown
into
the
rest
of
the
instrumentation
packages,
which
I'm
I'm
not
sure
if
it
counts
as
an
instrumentation
package,
but.
A
Yeah,
that's
true,
so
go
is
naming
it
something
different
than
js.
B
Yeah,
the
official
name
in
spec
is
called
like
the
open
to
open
tracing
bridge,
and
I
know
there
was
some
discrepancies
early
on
on
what
this
thing
should
be
called,
but
yeah.
So
I
guess
my
question
was
just:
should
we
keep
the
name
what
it
is?
Should
it
be
called
like
open
tracing
bridge
like
open,
telemetry,
bridge,
open
tracing
or
or
like?
What
do
we
want
to
do
with
it?.
A
Yeah
so
name
it
naming
is
always
a
not
not
a
strong
suit
for
for
developers.
I
feel
so.
The
thing
that
caused
the
confusion
was
that
the
fact
that
there
was
instrumentation
in
the
package
name
or.
B
B
It
just
ended
up
getting
moved
along
with
the
rest
of
the
instrumentation,
because
it
was
part
of
the
instrumentation
folder
and
it
just
seems
it
just
seems
strange
to
have
like
one
thing:
that's
going
to
be
left
in
the
instrumentation
folder
in
the
core
repo
which
that's
true,
you
look
at
it.
It's
not
really
instrumentation.
A
Yeah
so
me
personally,
I
I
don't
mind
like
changing
like
removing
the
instrumentation
from
the
the
bridge
because
you're
right,
it's
not
exactly
an
instrumentation,
but
as
for
like
the
specific
like
whether
we
call
a
shim
or
bridge,
you
know,
I'm
kind
of
I
don't
have
a
strong
opinion
for
that
really
depends
on
what
you
know.
If.
C
A
D
D
A
A
So
so,
if
whether
we
use
shimmer
bridge
now
would
be
the
time
to
change
it.
B
B
E
B
B
A
Again,
zero
here
so
okay
cool.
So
I
think
action
items
for
this.
So
we
know
that
we're
gonna
be
removing
instrumentation
from
the
package
name
and
I
guess
we
could
bring
it
up
as
a
quick
discussion
topic.
Maybe
in
the
maintainers
meeting.
B
B
A
All
right
cool,
so
I
think
ted
was
supposed
to
join
the
meeting
today,
but
he's
not
here.
So
I
guess
we
could
skip
over
this
unless
if
someone
else
added
this,
but
I
guess
we
could
skip
over
this.
B
Topic,
yeah.
I
think
I
think,
if
you
look
at
the
list
of
asks,
maybe
we
can
just
kind
of
quickly
go
over
it.
I
can
give
a
tiny
bit
of
background
on
this.
Essentially
he's
just
been
putting
together,
like
a
dock,
for
people,
to
kind
of
follow
steps
in
each
different
language
to
try
and
to
try
and
get
an
idea
for
how
like
how.
B
Well
the
usage,
from
a
user's
point
of
view,
goes
to
what
the
usability
is
like
in
different
languages,
and
I
think
one
of
the
only
asks
here
is
whether
or
not
there's
people
that
wanted
to
run
through
these
steps
for
a
language.
But
then
the
very
top
ask
is
specifically
around
calling
a
version
to
be
tested
in
the
user
research
doc,
and
I
guess
like
for
us,
we
should
probably
just
put
whatever
the
latest
version
is,
which
is
0
15
b
0.
A
Yeah
or
if
we
ever
decide
to
like
do
the
rc.
I
think
that
would
be
a
good
candidate
too.
B
A
Yeah
makes
sense:
okay,
yeah,
I'm
okay
with
that,
is
there
any
like
timeline
for
this
is
like?
What's
the
what's
the
do,
you
have
an
idea
for,
like
the
plan.
A
Okay,
please
let
the
version
to
be
tested.
Please
run
through
the
exercise.
Please
recruit
one
to
two
people
each
to
try
the
exercise.
Okay.
I
can
present
this
to
like
my
colleagues
and
stuff,
because
I
think
some
pms
are
interested
in
this
research
doc
as
well.
A
I
guess
the
thing
that
we
gotta
just
say
it's
like.
Oh
we're,
gonna
be
doing
version
0.15b.
Is
that,
like
a
safe
thing
to
say,.
A
Yeah,
I
think
I
think
0.15
b
is
fine.
We
could
just
say
that
like
consistently
say
0.15.
F
A
Right
sounds
good
nice
yeah
so
like,
if
you
guys
are
interested
and
I'll
just
like
walk
through
the
document
and
see,
if,
like
any
people
that
you
know,
want
to
try
it
out.
So
all
those
like
forms
for
studies
too
wow.
This
is
pretty
well
organized.
C
B
A
Keep
forgetting
guys
talk
so
he's
from
night
stuff,
so
yeah
cool.
So
I
was
gonna
ask
this
about
ted
for
ted,
but
since
it's
not
here,
we
could
just
move
on.
I
guess
another
thing
we
can
yeah
talk
about
afterwards
after
stuff
yeah
cool.
Next
up.
We
got
this
big
ass,
nathaniel's
topic,
so
yeah
you
could
just
hand
it
down.
A
You
could
pretty
much
just
update
us
on
the
progress
of
what's
going
on
doing
some
some
awesome
work
here,
we've
been
trying
to
follow
along
so
we'll
just
go
over
it.
Real
quick.
D
Sure
thanks,
yes,
so
we're
really
close
there.
We
have
everything
working
and
I
spent
a
lot
of
time
last
night
trying
to
get
all
the
lint
tests
to
fix
on
the
contributor,
and
I
found
a
way
to
do
it.
So
it's
just
nine
lines
that
were
causing
problems.
I
don't
know
why
they
aren't
well,
partly.
I
have
an
idea
why
they're
not
caught
in
the
main
repo,
but
I
just
decided
to
disable
those
nine
lines
and
then
added
some
improvements
there.
D
So
if
we
merge
this,
hopefully
really
quickly,
because
they're
not
too
complicated,
they're,
pretty
small,
then
we'll
have
fully
passing
tests
on
the
contributor,
we'll
be
able
to
start
developing
just
fine
and
that
pr
already
there
thanks
to
aaron
for
already
approving
it.
It
just
needs
a
second
review
and
will
be
fully
moved
over
it'll
remove
all
those
packages.
D
I
guess
the
only
other
like
serious
callout
I
had
was
that
if
we
can
move
the
removing
one
and
then
the
last
link
I
put
of
all
the
prs,
it
shows
how
we
can
trigger.
If
you
click
on
the
very
last
one
below
don't
need
pat
anymore,
I
I
went
ahead
with
aaron's
suggestion
of
why
don't
we
just
download
the
contrib
in
this
repo?
D
So
once
both
are
green,
you
could
merge
them
both
at
the
same
time,
and
it
would
it
would.
It
would
be
good
to
go
in
terms
of
testing
and
making
sure
nothing
breaks
on
the
other
side.
So
this
pr
just
adds
tests
to
here.
The
other
one
removes
packages,
and
I
don't
know
I'd
appreciate
if
we
could
move
these.
D
I
mean
merge
these
like
sooner
than
later,
because
I
know
there's
stuff
pending
in
the
core
repo,
but
I
guess
every
time
something
gets
merged
into
the
instrumentation
when
I
have
to
go
and
update
it
in
the
contrib
repo.
So
if
we
remove
them,
it
sends
a
signal
that
we're
fully
moved
over
right,
all
right,
cool.
A
Awesome
yeah
so,
in
terms
of,
like
you
know
the
the
the
planned
out
workflow
like
alex,
and
I
talked
about
it
this
morning.
We
are
kind
of
stuck
in
this,
like
limbo,
state,
where
there's
like
a
handful
of
prs
or
elected
instrumentation.
I
think
there's
about
like
10
open
right
now,
yeah
and
they
do
pertain
to
instrumentations
that
have
already
been
moved
to
the
contrib
repo.
A
So
and
we
don't,
we
don't
want
to
ask
you
to
like
you
know,
change
like
manually.
You
know
like
move
all
those
over
again
so
right
now
the
plan
is,
I
don't
think
we
want
to
be
yet.
What's
it
called
deleting
the
all
the
what's,
it
called
the
the
instrumentations
right
now
before
these
ones
are
merged.
A
So
I
think
the
priority
for
us,
like
as
a
sig,
would
be
to
focus
on
these
10
pr's
and
we
really
need
to
get
them
in
before.
We
do
any
more
work,
because
a
lot
of
people
are
blocked
and
stuck
in
this
transition
phase.
A
And
it's
another
thing
like.
We
don't
really
want
to
ask
the
people
who
opened
up
these
pr's
as
well
like
this
guy
who,
who
was
doing
this
since
august,
to
like
open
up
a
new
pr
in
the
country,
people
so.
A
D
To
move
it
to
the
country
by
the
way
in
the
conversation
he
said,
he'd
be
more
than
happy
to
go
over
and
do
it?
Oh
really
yeah
I
mean
like
it's:
it's
not
a
big
change
right.
It's
just
cherry-picking
your
commits
and
moving
them
over
to
that
side
and
then
merging
them.
There
yeah
like
most
of
these
pr's,
don't
have
even
a
single
approval.
I
think
so.
B
A
Yeah,
okay.
Does
anybody.
B
D
D
A
D
A
A
All
right,
awesome,
cool
cool.
All
right,
I
will
address
that
to
you
looks
like
yusuke
has
proved
this
already,
but
I
guess
we
can.
How
do
we
handle
the
ones
that
have
been
approved
already
like?
Do
we
just
need
more
approvers
on
that
side,
then.
A
Sure
yeah,
I
think
it's
fine,
so
is
it
cool?
If
I
close
this
right
now,.
B
A
A
A
A
And
we'll
be
active
for
the
the
rev,
the
reviews,
it
should
be
pretty
straightforward,
since
a
lot
of
these
are
approved
already
so.
A
A
It
to
the
contributor
okay
awesome,
let
me
just
mark
it
just
to
for
completion.
I
guess
yeah.
A
B
A
Alex
you're
so
fast
all
right,
all
right.
This
db
statement
parameters
thing
is
this
person
in
the
call
right
now
it's
in
draft
mode,
what
the
hell!
Okay,.
A
Okay,
we'll
just
leave
this
one
for
now
then
cool
the
boto3
x-ray.
One.
D
C
D
A
A
Add
an
environment
variable
interesting,
okay.
We
could
just
leave
these
ones
for
now,
because
they're
they're,
not
in
the
call
and
the
last
one,
would
be
this
one.
A
F
A
A
A
We'll
be
addressing
them
directly,
but
I
think
we
can
go
ahead
with
the
deletion
pr
now
then
that's
awesome,
yeah,
so
yeah
I'll
we
can.
We
can
take
a
look
at
that
after
the
meeting
yeah
so
like
the
only
things
that's
left
is
making
sure
that
the
issues
that
correspond
with
those
pr's
are
cleaned
up
in
the
issues.
D
A
Could
deal
with
that
after
all,
right
sounds
good?
Is
there
anything
else
you
want
to
talk
about
the
in
terms
of
the
you
know,
anything,
that's
blocking
you
or
like.
D
A
Yeah,
okay,
so
does
anybody
have
any
more
questions
or
comments
about
specifically
the
contribution.
E
Yeah,
just
one
more
so
for
that
last
pr,
nathaniel.
E
Yeah,
I
see
you
copied
the
yaml
did.
Were
you
able
to?
Were
you
able
to
find
the
github
documentation
about
like
how
you
can
set
up
a
workflow
that
you
can
reuse
across
repos.
D
Yeah
I
I
did.
I
looked
at
the
one
for
checkout,
it's
you.
Basically,
you
have
to
make
a
pr4
workflows
from
what
I
saw.
I
mean
sorry,
a
repo
for
workflows
and,
like
honestly,
it
just
looked
really
complicated.
Like
the
the
git
checkout,
one
was
32
000
lines
long
and
it
was
all
in
one
line,
one
file
and
so
yeah.
I
just
I
just
said
this-
isn't
much
we're
not
doing
like
too
many
things
here
that
it
would
be
complicated.
So
I
just
copied
it
over.
E
Yeah,
it's
just
yeah.
It's
just
that
if
we
change
the
contrib
one,
it
has
to
be
changed
in
the
core
one
two,
so
you
have
to
make
two
pr's.
If
you
update
the
ci.
D
E
B
Okay,
cool
sounds
good,
alex
for
the
approval
and
the
remove
pr
yeah.
It
looks
like
there's
only.
It
looks
like
there's
only
like
a
conflict
that
needs
to
be
resolved.
No,
I.
G
F
G
D
G
Awesome
hey.
I
was
just
curious.
How
do
you
know
what
if
a
component
should
be
on
the
contrib
repo
or
in
the
main,
repo.
D
So
I
think
the
way
we're
sorry
the
way
we
were
doing
it
was
everything
that's
set
in
the
specs
that
needs
to
be
in
open
source.
Sdk
stayed
there
so
like
the
shim
and
the
exporters
like
jager
and
dated
and
open
senses
and
stuff
anything.
D
That's
like
you
know,
python
specific,
there's,
a
popular
python
package
that
you
know
we
want
to
add
instrumentation
for
that
be
added
in
the
contrib
repo,
because
it's
like
you
know
this
is
the
community
trying
to
add
support
for
open
telemetry
to
a
range
of
packages
and
then
everything
the
corey
was
like
stuff.
The
community.
The
hotel
community
has
decided.
We
need
to
have.
B
Yeah,
basically,
all
the
instrumentation
will
go
in
the
control
repo,
and
the
only
exporters
that
are
left
in
in
the
core
repo
will
be
the
like
the
stuff
that
has
an
open,
open,
spec,
an
open
source
spec
for
for
it.
So,
like
things
like
jaeger,
zip
can
we'll
we'll
stay.
We'll
stay
in
here,
like
the
some
of
the
propagators
will
also
stay
in
this
repo,
but
then
like.
If
there
is
custom
propagators
that
you
know,
vendors
are
supporting
or
whatever
those
are
all
going
to
contribute.
Well,.
A
So
we
we
think
it's
going
to
be
most
likely
in
the
contribution,
but
like
it's
more
going
to
be
better
outlined
when
a
leader
releases,
her,
like
you
know,
plan
for
vendor-specific
components,
it's.
A
Going
to
be
in
the
contribution
right,
yeah
like
you
can
like
ping
her
to
see,
if
there's
any
updates
for
that,
but
I
haven't
heard
anything
yet
so
yes.
B
A
Yeah,
it's
less
about,
I
think
it's
less
about
like,
because
we're
definitely
less
strict
about
what
goes
in
the
contribution.
It's
just
like
it's,
it's
just
what
like
more
on
the
maintainers
now
right,
so
we
still
kind
of
have
to
be
careful.
What
goes
in,
like
some
random
company
comes
and
adds
their
you
know
their
own
propagators
and
their
own.
A
You
know
conventions
and
then
like
just
they.
Never
they
never
maintain
it
or
anything.
So
that's
the
kind
of
stuff
we
want
to
avoid
yeah
cool
nice
cool.
We
can
just
keep
moving
on
then
aaron
performance,
load,
testing
and
concurrency
testing.
Oh
my
god,
okay
aaron,
you
want
to
you,
want
to
go
over
this
real,
quick.
E
Yeah,
so
I
think
we've
talked
about
this
a
few
times
the
concurrency
testing
specifically,
but
we
also
know
how
many
performance
testing
for,
like
our
python
core
sdk
and
apis
yeah,
and
so
we,
I
was
talking
with
my
colleagues
also
about
how
what's
the
best
way,
we
can
do
these
concurrency
tests
and
probably
rather
than
like,
try
to
reproduce.
E
You
know
like
race
conditions
and
stuff,
like
that,
it's
probably
easier
for
us
to
just
have
some
bloat
tests
and
you
know
like
monitor
them
to
make
sure
like
have
it
run
a
bunch
of
spans
or
a
bunch
of
metrics
and
stuff
like
that
and
see
if
it
hits
any
any
race
conditions,
or
you
know
like
deadlock
or
something
like
that,
and
that's
probably
a
decent
way
to
verify
stuff
and
then
also
be
able
to
check
for
like
progressions
in
our
repo.
E
This
is
like
a
core
library
that
we
want
to
make
sure
it's
really
fast
for
other
users,
so
I
think
they've
already
done
this
in
java,
they
have
some
load
testing.
I
haven't
done
a
lot
of
research
into
it
yet
like
what
framework
to
use
but
it'd
be
great.
If
we
have
it
report
npr's
kind
of
like
code
coverage
and
if
we
could
also,
I
would
run
every
pr
if
it's
not
too,
like
overwhelming
for
the
you
know,
github
actions
or
whatever
we
don't
want
to
run
too
long.
A
No,
not
one
because
not
many
people
use
it,
but
two
now,
like
all
of
all
our
customers.
No
one
has
complainable
performance
yet
so,
and
I'm
not
sure
if
that's
an
indicator
of
our
software
being
good
or
like
it's
just
something
that
they
don't
care
about
as
much.
E
A
Yeah,
like
amongst,
like
like
my
colleagues
that
are
also
working
on
open
telemetry
and
like
our
internal
sdks,
we've
been
trying
to
come
up
with
like
consistent
benchmark
tests.
It's
just
the
efforts
only
just
started,
and
I
don't
know
we
don't
really
have
much
guidance
on
it
yet
like
what
is
acceptable
for
like
do,
we
do.
We
have
like
standards
across
all
languages
or
it's
like.
We
have
to
meet
a
certain
threshold,
and
it's,
of
course
I
think
I
feel
like
it
is
different
across
languages.
So.
A
A
E
A
Okay,
so
I
think
I
think
what
we
should
do
is
maybe
open
up
a
new
issue
and
then
just
link
that
concurrency
test
issue
to
the
new
one,
and
maybe
close
that
one
just
saying
like.
Oh
we'll,
we'll
be
solving
this
via
this.
E
E
A
We
plan
to
have
it
for
all
of
them,
like
our
internal,
like
azure,
monitor
sdks,
that
people
are
using
right
now
that
we
recommend
and
as
well
as
you
know,
our
future
open
telemetry
offering
okay
cool
yeah
like
we
want
to
have
both
of
these.
A
Awesome
nice
cool
thanks
for
that
next
thing,.
H
So
my
question
was
now
that,
like
summary,
the
story
metric
type
is
added
back.
How
would
you
suggest
that
we
go
about
adding
a
summary
aggregator
in
the
python
sdk,
because
you
know
you
need
to
like
store
some
metrics
to
calculate
a
quantile
so
like?
Would
you
guys
be?
H
Okay
with
you
know,
just
having,
like
an
instance
variable
in
the
aggregator
class
that
just
like
stores
the
raw
metrics
over,
like
I
know,
10
minutes
or
5
minutes
or
whatever,
and
that's
how
you
calculate
the
various
quantiles
or
I'm
just
wondering
if
you
guys
had
a
conversation
about
this
before
or
have
an
idea,
and
our
like
primary
motivation
for
this
is
because
of
our
prometheus
remote
right.
H
Exporter,
like
you
need
a
summary
metric
type
to
fully
support
that
sorry
thing
about
building
one
out,
but
we
can
unsure
how
to
like
go
about
doing
it.
H
Is
that
is
that
different?
Sorry,
I'm
not
right.
I
think
if
my
designing
is
correct,
the
histogram
aggregator,
like
just
counts,
like
the
number
of
times
like
a
metric,
falls
like
within
a
certain
bucket.
Yes,
but
like
for
the
summary
aggregator,
would
you
be
wanted,
like
you
would
you're
calculating
like
like
a
quantile.
A
H
Okay,
so
in
the
go
sdk
they
have
the
metric
type,
but
I
don't
think
they
have
like
an
aggregator
built
out
and
neither
does
java,
because
I
think
they're
waiting
for
like
the
spec
to
figure
out
whether
they
wanted.
H
A
Okay,
so
I
guess
there
is
a
plan
to
add
some
sort
of
summary
aggregator
or
something
that
could
support
summary.
A
H
A
Are
change
yeah
but,
like
the
question
is
like
do
you
have
urgency
for
this?
Like
do
you
need
this
to
be
supported
or
something
for
something
to
succeed?.
H
Right
so
like
for
our
like
prometheus
from
our
right
exporter,
like
one
of
the
prometheus
like
data
types,
is
a
summary
metric,
which
is
why
this
was
added
back
into
the
proto
is
because
I
think
one
of
open,
telemetry's
goal
is
to
like
fully
support
prometheus,
like
yeah.
H
Our
only
like
kind
of
pressing
issue,
but
I
guess
we
could
black
box
it
and
just
assume,
like
you
know,
assuming
you
get
a
seven
metric
type
dizzy.
A
Yeah
yeah,
I
think
yeah
I
think
personally
like
if
I
think
you
would
just
I
don't
think,
you're
blocked
on
this,
like
you
could
just
in
the
meantime,
it's
like
just
assume
that
it's
going
to
be
implemented,
because
if
it's
in
proto,
I'm
pretty
sure
it's
going
to
be
implemented.
Even
if,
if
it's
not
that's
like
on
open
telemetry
right
that,
like
the
worst
case
scenario,
it's
like
we
don't
support,
summary
aggregation,
but
that's
like.
H
A
C
Maybe
what
something
else
that
you
can
do
is
that
you
can
implement
this
aggregator
there
and
add
it
as
part
of
the
exporter
package.
Since
it's
going
to
be
a
separate
package
that
probably
is
going
to
leave
in
some
repo-
and
maybe
you
can
monkey
batch,
the
aggregate
aggregation
to
be
added
to
the
rest
of
the
aggregations
for
the
when
the
exporter
is
installed
and
when
all
the
specification
process
comes
along,
then
we
can
move
the
implementation
of
this
aggregator
to
the
new
vehicle.
C
H
Okay,
right
right,
yeah,
no
yeah,
thanks
for
that
suggestion!
Now,
if
you
can
do
that.
E
Real
quick
question:
so,
if
you're
calculating
percentiles
like
you
have
to
store
all
the
points
forever
right.
H
Right
so
in
prometheus,
or
at
least
in
like
what
they
said
like
what
a
lot
of
prometheus
clients
do
is
that
they
only
store
like
the
last
10
minutes
with
the
data
and
that's
where
they
calculate
quantiles
client
side.
So
I
was
thinking
we
could
do
something
similar,
but
there
might
be
like
performance
implications
right.
E
Yeah,
so
I
think
I
don't
know
if
you've
seen
this
in
the
spec,
but
one
thing
that
they're
working
on
is
implementing
like
a
sketch
data
type
and
using
that
potentially
for
the
value
reporter.
So
I
don't
know
if
you're
familiar,
but
I
think
they
want
dd
sketch
to
be
the
default
and
datadog
is
offering
to
potentially
chip
in
implementations.
And
it's
like
a
much
more
memory
efficient
way
to
collect.
H
E
Yeah,
if
you
look
in
the
in
the
spec
repo
there's
an
issue
open
for
value,
recorder,
aggregator
and
you'll
see
a
lot
of
discussion
in
there
and
there's
also
some
pr's
open
in
the
which
one,
the
proto
repo,
I
think,
to
add
the
data
types
for
for
a
sketch.
G
F
E
One
other
thing
I
was
going
to
ask
was
I've
heard
also
there's
some
discussion
around
sending
raw
data
points
over
otlp
without
any
aggregation
and
then
letting
the
collector
do
this
for
you,
which
obviously
wouldn't
really
be
in
the
python
sdk
or
like
you,
wouldn't
implement
a
python
exporter
or
aggregator.
For
this,
I
think
I
think
alolita
was
across
that
or
was
knows
about
it,
but
I
think
that's
been
sort
of
pushed
off
and
if
datadog
is
willing
to,
you
know,
contribute
a
implementation
for
all
these
languages.
A
Awesome,
I
guess
erin
like
I
guess,
real
quick.
I
I
don't
know
if
you've
been
following
the
metrics
discussion
recently,
but
do
you
know
like
the
reasoning
behind
like
having
dd
sketches
to
default
for
valley
recorder
like
if,
if
a
majority
of
people
use
value
recorders,
just
for
simple,
like
you
know,
aggregation
of
like
the
summary
aggregation?
A
Sorry
not
the
summary,
like
the
min
max
some
count,
which
is
what
it
is
today
right:
yeah
yeah,
because
if
we
use
dd
sketch
as
default,
it's
like
a
lot
of
overhead
for
features
that
a
lot
of
people
don't
want
or
necessarily
want.
E
Yeah,
so
I
think
the
idea
is
that
the
dd
sketch
can
support
both
right
so,
like
all
you
need
to
attach,
is
the
min
and
max
which
it
already
gives
you,
I
think,
within
one
percent,
but
if
you
actually
like
want
to
collect
the
minute
max,
that's
pretty
easy
to
do
so.
Then,
besides,
that
you
have
a
histogram,
so
you
can
calculate
like
the.
Maybe
it
gives
you
a
medium,
but
you
have
count
and
and
potentially
sums
you
can
calculate.
E
So
I
think
I
think
the
idea
was
that
it
can
support
it
as
well,
but
you're
also
getting
that
additional
stuff
that
you
want
yeah
and
I
think,
there's
also
some
discussion
around
like
the
converting
from
delta
to
cumulative.
So
like,
apparently,
I
think
dd
sketch
can
be
converted
from
delta
to
cumulative,
whereas
with
like,
min
and
max,
if
you're
just
getting.
E
A
Okay,
yeah,
that
makes
sense
and
from
the
discussion
description
it
sounds
like
it's
pretty
performance
friendly.
So
I
don't
think
the
overhead
will
be
that
bad
yeah.
Okay,
that
sounds
good
nice
cool.
Does
anybody
else
have
any
other
topics
before
we
go
into
the
pr's.
A
D
Hey
thanks
so
yeah
like,
like
I
mentioned
one
of
the
the
big
points
or
one
of
the
big
things
that
we
really
really
wanted
to
get
in
was
our
aws
sdk
extension,
since
it's
already
in
the
net
repos
and
in
the
java
repos.
So
now
that
the
contributor
is
much
more
farther
along,
it
would
be
really
great
if
you
guys
could
just
give
it
a
review.
D
I've
added
tests
for
everything,
I've
added
kind
of
name
spaces,
and
it
is
still
pending
on
alolita's
dock
of
where
things
are
going
to
go,
but
I
mean
just
for
now
would
be
really
appreciated
since,
like
the
other
peoples
have
it
to
get
this
one
in,
because
we
have
a
deadline
coming
up
to.
C
D
D
A
Cool
all
right
thanks,
so
as
for
added
a
note
about
what
we
were
talking
about.
If
anyone
is
interested
in
the
dd
sketch
conversation
but
cool.
D
So
this
pr
all
it
adds
is
most
of
them
are
just
test
changes
and
stuff,
but
what
it
adds
is
the
ids
generator
that
are
needed
to
be
able
to
use
open,
telemetry
python
with
x-ray
and
the
propagator
that
you
would
also
use
to
get
things
to
go
along.
So.
A
Right,
okay,
cool
sounds
good
yeah,
we'll
we'll
take
a
look
at
this.
We
still
have
to
like
thanks
so
much
kind
of
set
up
the
the
review
process
for
the
contrib
repo
but
yeah.
We,
I
think,
you'll
get
traction
on
this.
So.
D
Great
thanks
so
much
guys
yeah,
it's
I
think,
like
we
have
a
deadline
to
have
at
the
start
of
december,
so
I
mean
we're
almost
done
the
migration
and
then,
if
we
have
a
chance
to
look
at
this,
that
really
help
us
on
our
side.
A
Cool
all
right,
let
me
assign
myself
to
this,
actually
take
a
look
at
it.
Sweet!
That's
awesome,
how
many,
how
many
reviewers
are
needed
for
a
pr
in
the
country,
repo.
A
B
Yeah,
maybe
we
can
add
that
as
an
item
for
next
week,
but
I
I
think
we
had
talked
about
like
making
the
restrictions
around
merging
a
little
bit
looser
in
the
contrib
repo,
so
that
we
can
get
people
approved
more
quickly.
All.
A
Right
sounds
good,
okay
sounds
good,
nice
next
up.
D
C
C
D
A
D
Case
right,
actually,
that's
how
dot
net
does
it
because
they
came
into
a
weird
bug.
Where
say
you
have
aws
instrumented
and
they
actually
also
instrument
the
http
client
on
that
aws
sdk
instrumentation
calls,
so
they
were
seeing
double
spans
right.
D
A
Awesome,
okay
sounds
good,
looks
like
that's
all
the
discussion
topics
we
have
for
today.
Does
anybody
else
have
anything
they
want
to
bring
up
it's
important,
pr's
issues,
okay,
cool!
If
that's
the
case,
then
just
get
the
eight
minutes
back
and
I'll
see
you
guys
next
week.