►
From YouTube: 2021-09-02 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
How
are
you
pretty
good,
yeah
just
busy,
as
always
how
it
goes.
B
A
B
No
right,
it
really
doesn't,
although
I
think
that's
self-imposed,
I
always
find
fun
and
interesting
things
to
work
on
I'd.
I
get
paid
for
them
or
not.
Sometimes.
C
We
had
some
weird-
I
think
hurricane
effects
out
here,
not
like
a
lot
of
rain
for
the
last
few
days
lost
some
of
the
warmth.
B
We
could
use
some
rain
out
here
in
the
west
coast
yeah
it's
not
as
bad
as
it
was
last
year,
but
there's
definitely
still
fires
yeah.
B
Yep
yeah
like
two
weeks
ago,
that
was
me,
so
I
totally
get
it
cool.
I
think
we
are
six
participants.
Almost
three
minutes
in
we
could
probably
get
started
here,
I'll
figure
out
how
to
share
my
screen.
B
B
We're
definitely
getting
to
the
point
where,
as
you
can
see
in
the
agenda,
we
want
to
talk
a
little
bit
about
the
next
release.
The
last
thing
that's
on
here-
I
don't
know
if
no,
I
don't
see
david
on
here-
was
this
documentation
pr.
I
think
I
was
looking
to
just
merge
this.
It
looks
like
robert
and
I
have
approved
it.
I
did
put
in
a
bunch
of
fixes-
maybe
that's
not
a
valid
approval,
to
say
that
I
approved
at
this
point.
B
So
maybe
we
need
another
approval
on
this,
but
yeah.
I
think
that
the
idea
here
is
just
to
get
some
to
get
this
merged.
It's
the
last
thing
in
the
project
board
that
we
need
to
actually
get
merged.
I
think
there's
some
follow-on
pr's
that
I
wanted
to
do.
I
addressed
all
of
the
remaining
outstanding
issues.
It's
building.
If
you
have
a
little
bit
of
time,
if
I'm
boring
you
in
this
meeting
or
after
the
meeting,
please
take
a
look
at
it.
B
It's
the
last
thing,
and
otherwise
there's
just
this
one
remaining
task,
but
the
idea
is
to
get
the
our
the
last
rc
or
a
next
rc
out
to
try
to
evaluate
the
next
release.
B
I
think
there
are,
there
have
been
some
discussions
about
how
to
best
do
that.
I
don't
know
if
I
captured
them
in
this
issue.
B
No,
I
did
not
nothing
in
this
issue,
so
the
idea
was
there's
a
few
people.
I
definitely
know
some
leaders
in
hotel
that
we
can
reach
out
to
you
to
get
some
definitely
some
forms
or
some
sort
of
feedback
documentation
and
then
solicit
it
from
a
few
community
members.
I
know
that
there's
a
few
people
that
we
want
to
reach
out
to
that
are
in
the
community
and
ourselves
so
asking
everyone
on
the
call
to
maybe
you
know
talk
to
anybody
in
the
company.
B
That's
using
this
platform
and
give
us
some
feedback
on
this.
I
think
that
was
the
initial
idea
other
than
that.
I
think
it
was
just
organic.
We
were
looking
to
see
you
know
adoption
rates,
which
I
don't
think
we
can
actually
see
very
easily.
Maybe
we
can
check
with
google
because
they
own
the
vanity
url
to
see
if
we
can
just
package
down
those
statistics,
but
other
than
that.
I
think
it
was
just
like
a
matter
of
time
and
then
trying
to
brainstorm
ideas
on
how
to
do
that.
B
So
no
there
wasn't
a
really
great.
I
think,
answer
to
that
problem.
I
don't
know
if
there's
a
really
the
thing
is,
I
talked
to
ted
about
this
as
well,
and
ted
young
overlay.
Stephanie
was
pointing
out
that,
like
it's,
it's
one
thing
to
like
be
super
methodical
and
create
all
this
documentation
on
how
to
get
feedback
and
then
nobody's
gonna
fill
it
out,
and
so
it's
it's
one
thing
to
just
create
it's
the
other
thing
to
actually
get
feedback.
So
I
think
it's
more
about
just
finding.
B
I
think
targeted
individuals
to
start
that
feedback
discussion.
I
think
once
we
actually
have
a
release
for
them
to
evaluate
so
I've
already
kind
of
done
that
with
bogdan
and
tigran
and
a
few
people
here
in
splunk,
but
I
know
we
can
probably
do
that
more
comprehensively,
as
a
community
I
think,
is
the
idea
and
for
anybody
else
is
something
else
they
want
to
say
on
that
topic.
C
C
B
Yeah,
that's
a
a
really
good
point.
It
was,
I
think
I
think
it
was
either
aaron
or
david.
I
can't
remember,
brought
this
up
in
a
recent
pr
that
we
just
merged
around
the
refactor
of
the
getting
started,
documentation
and
that's,
I
think,
kind
of
a
blind
spot
right
now
in
our
documentation
as
to
like
you
know,
we
do,
I
think,
a
sufficient
job
and
kind
of
describing
tracing
but
really
the
context.
Propagation
stuff
is
a
black
hole
for
knowledge.
B
If
you're,
if
you're
new
to
this-
and
I
think
that
honestly,
there
was
a
really
good
additional
doc.
I
think
that
aaron,
I
think
it
was
you
who
recommended
this,
where
it's
essentially
just
like
go
through
the
exact
like
you
know
an
example
workflow,
where
you
have
two
services
talking
together
and
like
how
does
that
look
in
open
telemetry,
like
walk
through
the
instrumentation,
walk
through
like
what
that
actually
means
in
global
context
or
local
context
of
propagators
so
yeah.
I.
B
C
Yeah,
I
think
the
parts
are
there
to
do
it
all
correctly.
If
anything
I
I
guess
it
might
be
like
there's,
there's,
probably
not
more
than
we
need,
but
it
the
the
abundance,
was
a
little
confusing
so
yeah
as.
B
B
Yeah,
I
agree
it's
it's
a
little
bit
confusing
just
because
like
it's,
it's
it
handles
the
80
case
and
then
that
20,
with
all
the
other
edge
cases,
are
we
tried
to
handle
those
as
well,
and
I
think
that
handling
all
those
other
edge
cases
makes
the
80
a
little
bit
more
complex.
You
know
like
like
you're
saying
like
it
probably
is
just
useful
for
the
global
propaganda.
But
why
do
you
pass
a
propaganda
all
this
instrumentation?
Why
wouldn't
it
be
using
the
global
like?
Why
is
it
separate
it's
like?
B
C
E
That's
yeah,
it's
certainly
a
thing
it's.
I
know
one
of
the
things
that
we've
discussed
that
amazon
as
a
way
to
deal
with
x-rays,
different
propagation
scheme,
and
if
we
want
to
have
things
like
amazon
services,
participate
in
x-ray,
traces
and
in
hotel
traces
the
customers
are
using.
We
may
need
some
mechanism
for
deciding
on
the
fly
which
propagators
to
use
for
downstream
requests.
A
But
I
mean
I
think
our
first
goal
should
be
getting
like
the
80
percent
and
then,
if
we
want
to
have
discussions
about
like
capture
discussions
about
those,
those
should
be
in
somewhat
separate
documents.
Right,
remember
like
the
first
use
case
of
this
should
be
our
primary
users
and
then
also
supporting
everybody
else.
A
B
Yeah-
and
I
think,
if
that
should
structure,
how
we
you
know,
lay
out
big
website
docs
like
you,
definitely
should
be
targeting
the
80
there,
but
I
also
think
that,
like
the
instruction
that
stephen
harris
is
talking
about
like
yeah,
that
should
probably
be
better
documented
like
why
you
would
want
to
pass
those
additional
propagators
to
that
instrumentation
right
like
why?
B
Wouldn't
you
want
to
use
the
globals
here
or
something
like
that,
but
yeah
for,
like
the
main,
getting
started
like
main
entry
point
on
opensumtree.io
all
those
stocks
they
should
essentially,
just
honestly,
they
shouldn't
try
to
explain
the
edge
cases
they
should
just
gloss
over
them.
As
though,
if
you
look
at
for
these
edge
cases,
you
will
have
to
look
into
the
docs
elsewhere.
B
This
is
an
entry
point,
for
you
know
the
80
and
like
go
look
at
the
project
if
you're
going
to
get
more
involved,
but
that's
how
I
kind
of
framed
what
I
was
writing
for
the
getting
started
for
the
tracing
stuff
but
yeah.
I
definitely
think
that's!
That's
the
goal
cool
go
ahead.
Aaron.
I.
A
Was
just
going
to
say,
I
posted
in
chat
the
godev,
what
is
used
by
and
I'm
just
kind
of
looking
through
it.
I'm
like
there's
400
packages,
it
looks
like
most
of
them
are
like
somebody's
name
plus
something
that
they're
doing,
but
there's
actually
a
couple
of
really
interesting
ones.
In
there,
like
I
see,
build
kit
has
some
dependencies
on
there.
I
see
own
cloud.
Has
some
project
ocis
not
sure
what
that
is,
but
so.
B
This
is
actually
really
interesting
because
I
definitely
have
been
looking
at
this
in
the
past.
In
fact,
when
we
first
released
the
first
rc
I
was
looking
at
this
and
it
was
nowhere
near
460
known
imports,
keep
in
mind.
This
is
only
the
public
imports
by
the
way
like
yeah.
There
are
probably
a
lot
of
private
things
that
are
getting
hidden
here,
because
they're
just
not
exposed
but
yeah.
B
I
agree
this
is
this
is
actually
I
feel
like
there
was
like
a
hundred,
and
most
of
them
were
just
forks
of
like
the
contributor
or
something
like
that
yeah.
This
is
kind
of
cool.
Actually
looking
through.
All
of
this,
it's
almost
like
open
cemetery
might
be
a
popular
thing,
man
who
would
have
thought
yeah
right
yeah.
This
is
really
interesting.
I
don't
know.
Do
you
know
if
this
is
for
what
version?
I
do
not
know.
I
guess
it
doesn't
say
yeah
all
right.
A
I
just
went
to
the
I
just
went
to
the
latest,
one
which
it
looks
like
it's
version,
two
0.20.
B
Yeah,
I
guess
it
doesn't
really
make
a
difference.
Yeah,
I'm
with
you
on
that.
That's
definitely
not
the
best!
Well
cool
yeah.
I
think
this
is
probably
worth
looking
through
as
well.
There's
definitely
some
some
names
in
here
that
I'm
seeing
and
are
getting
reminded
of
a
few
months
ago
talking
to
people
but
yeah.
This
is
really
cool.
B
That
would
be
really
useful
to
try
to
find
this,
which
is
something
in
and
of
itself.
Maybe
we
could
talk
about
in
a
second
I'm
getting
really
distracted
this
15
minutes
of
just
kind
of
rambling
at
this
point,
so
maybe
we
can't
focus
back
on
the
agenda,
so
we
got
through
the
project
boards.
B
I
think
that
we
could
probably
get
some
support
to
get
this
merged
today.
That
said,
we're
in
line
to
get
a
release
candidate
out
of
the
rc3.
I
was
thinking-
I
don't
know
if
anybody
has
any
other
prs.
If
you
do
please
post
them
here
in
the
agenda
doc,
but
this
is,
if
you
haven't
seen
it
yet.
I
refactor
the
sdk
spam
creation.
It's
entirely
hidden,
it's
a
private
change.
It
might
be
worthwhile
to
try
to
get
this
out.
B
There's
only
one
outstanding
issue
I
had
here,
which
I'm
sorry
aaron
if
you're
ready
for
someone
but
yeah.
So
I
didn't
quite
understand
this,
and
maybe
we
could
talk
about
this
in
just
a
second
and
I'd
like
to
better
understand
like
what
what
the
suggestion
was
here
but
other
than
that
this
looked
like
it
was
almost
ready
to
go
and
it
concluded
a
lot
of
optimization
for
memory
usage
as
well
as
speed
if
you're
not
recording
a
span,
which
is
a
common
situation.
B
If
you
have
any
sort
of
like
sampling.
That
is
not
always.
So
I
think
that's
probably
a
useful
thing
to
try
to
get
out.
It's
pretty
simple.
It
helps
the
workflow.
It's
definitely
worth
taking
a
look
at,
but
we
can
kind
of
come
back
to
that
aaron.
Sorry,
I
don't
need
to
like
never
snipe
you
there,
but
any
other
pr's
that
you
think
we
should
try
to
get
merged.
I
think
before
rc3
I
think,
would
be
ideal
to
try
to
get
those
listed.
I
don't
know
of
any
others.
B
The
only
other
one
I
was
thinking
was
that
the
spam
clock
pr,
but
I
that's
totally
one.
I
think
we
can
get
after
the
main
release.
That
being
said
time
frame.
If
we
decide
that
to
not
include
this
in
the
rc,
I
would
like
to
get
it
out
this
week.
Ideally
tomorrow
I
could
probably
be
the
author
of
it
if
it
goes
out
tomorrow.
B
Next
week
is
also
an
opportunity,
but
I'd
love
to
hear
the
community's
ideas
on
like
time
frame,
and
I
guess
anthony
or
myself
being
the
author
on
that
one.
E
So
I
will
volunteer
to
do
it.
I
don't
know
if
you've
seen
the
prs
coming
through
in
the
build
tools,
the
go,
build
tools,
repo,
but
I've
been
going
through
some
of
the
pr's
on
the
multi-mod
tool
that
eddie
left
at
the
end
of
his
internship.
E
He
had
a
very
large
change
set
that
he
broke
down
into
several
successive
prs
and
so
I've
been
going
through
and
getting
those
up
to
date
and
I'm
at
the
last
one
now
which
adds
the
ability
to
point
at
another
repo
and
sync
modules
against
its
versions,
which
will
help
us
in
contrib
updating,
go
updating
the
core
repo.
E
So
I
would
like
to
use
this
as
a
test
for
for
that.
B
Yeah,
that's
super
exciting.
I
have
they've
been
sitting
in
the
background
of
my
periphery,
but
I
will
prioritize
looking
at
these
pr's
after
this
yeah.
That
sounds
like
a
great
opportunity
to
just
get
a
pr
or
to
get
a
release
out,
as
well
as
to
validate
some
of
these
changes,
so
cool.
That
sounds.
E
B
E
I'll
start
on
it
as
soon
as
we're
ready
like
if
we
can
get
2213
either
merged
or
we're
not
going
to
merge
it
in
this
meeting,
then
I
can
start
right
after
this.
B
Okay,
yeah
yeah,
that
sounds
good,
okay,
cool.
I
think,
if
that
all
makes
sense,
the
only
thing
of
the
time
frame
is
the
contrib.
Pr's
are
going
to
be
a
nightmare
for
the
dependable
if
we
don't
get
that
updated
by
the
end
of
the
week.
So
I
maybe
just
we
don't
do
a
release
till
next
week.
If
we
don't
think
we
can
get
it
out
this
weekend,
I
guess
is
the
only
concern
sure,
okay
cool.
I
think,
with
that
we
can
kind
of
go
back
to
this.
B
A
So
go
ahead.
The
context
of
this
is,
I
was
just
kind
of
reading
through
this
code,
that
block
of
code
that
I
highlight
goes
through
a
lot
to
create
a
new
span
context
with
with
the
appropriate
parent
span
context,
and
then
that's
used
to
create
the
span
at
the
you
know
just
below
what
I've
highlighted
and
then
it
returns
back
and
in
the
methods
that
it
returns
to
which
is
like
start.
I
think
right
there.
A
The
next
thing
you
do
is
actually
pull
that
span
contacts
out
to
get
to
use
for
the
other
portions
of
this,
and
I
was
just
of
the
opinion
like
why
don't
we
extract
that
logic
out
so
that
we're
creating
one
common
span?
Context
that's
shared
between
the
the
two
methods
and
this?
This
actually
is
the
work
of
creating
a
new
span
from
a
span
context
yeah.
So
maybe.
B
A
B
B
A
A
Oh
so
we
do
span
from
context
which
is
p,
and
then
I
have
to
double
get
back
into
where
I
was
reading
this
from
so
sorry,.
B
Yeah
no
worries-
I
was
just
a
little
confused
on
that
one
and
I
didn't
see
it
so
I
definitely
would
love
to
make
further
optimizations
to
make
it
cleaner,
but
yeah.
I
just
didn't,
understand
it.
B
Okay,
I
think
that
that's
probably
enough
to
not
waste
too
much
of
everyone
else's
time,
but
yeah.
F
B
Cool,
I
appreciate
the
deep
dive
awesome.
Nothing
else
is
on
the
agenda,
so
I'm
gonna
stop
sharing
the
screen
and
we
can
go
to
the
free
form.
If
anybody
else
has
any
other
topics,
they
wanted
to
talk
about,
didn't
make
it
to
the
agenda.
B
Okay,
I've
seen
a
lot
of
head
shakes
josh.
How
is
the
metrics.
F
For
progress
going,
so
it's
going
good!
Thank
you
for
merging
the
histogram
gauge.
You
know,
instrument
renaming.
I
have
one
other
open
pr
and
I'd
like
to
suggest
that
if
there's
a
near
release
candidate,
that's
going
to
be
taken,
we
should
wait
until
after
the
release
candidate
for
this
fairly
substantial
refactoring
only
because
it's
not
necessary,
except
for
the
sdk
of
the
metrics
sdk,
to
move
forward,
and
I
don't
think
we
should
risk
a
rc
delay
for
tracing.
B
Okay,
that's
a
yeah,
that's
a
good
point
to
make
it
our
build
tools.
Anthony
can
correct
me
on
this
one.
If
I'm
wrong,
we
have
them
structured
so
that
all
of
the
experimental
metric
stuff
doesn't
actually
get
released
with
the
release
candidate.
So
it's
completely
independent.
It
should
be
as
far
as
my
understanding
of
that
is
so
I.
B
E
We
we
can,
we
can
hold
off
on
doing
a
0.23
release
of
metrics
if
you
think
that
that
would
be
bad.
My
my
thinking
had
been
just
to
release
a
new
version
of
all
of
the
things
to
get
anything
that's
been
in
the
interim
out,
but
if
you
want
us
to
hold
off
on
releasing
the
metrics
packages,
we
can
do
that
as
well.
There's
no
need
to
hold
off.
I
just
know
it's
work
and.
B
Okay,
cool
and
then
the
yeah,
the
the
open
pr
that
you
have,
I
think,
is
trying
to
think
of
which
one
it
is.
F
This
is
like
taking
the
metric
descriptor
apart,
so
that
there
aren't
instrument
options
in
it
so
that
partly
to
in
order
to
get
the
sdk
api
package
to
contain
this
descriptor
struct
that
doesn't
have
options
so
that
the
options
would
stay
in
the
api
and
the
api
sdk
api
struct
moves
into
this
new
package.
This
is
part
of
pulling
stuff
out
of
the
api,
but
it's
also
part
of
this
call
to
streamline
the
otlp
exporter.
F
So,
whereas
before
you,
the
metric
sdk
handed
you
a
long
list
of
unordered
metrics
that
belong
to
a
variety
of
resources,
instrumentation,
libraries
and
so
on,
I
in
my
previous
refactoring,
I
pulled
the
resource
out
of
that,
and
now
this
is
to
pull
the
instrumentation
library
out
of
that
and
what
we're
left
with
is
otlp.
Exporter
has
a
two
level
reader,
so
you
can
say
I
would
like
to
see
each
instrumentation
library
one
at
a
time
and
then
for
each
interpretation.
F
You
can
say
I'd
like
to
see
what
my
list
of
metrics
one
at
a
time-
and
I
haven't
one
of
the
issues-
open-
is
kind
of
a
longer
term.
There's
there's
still
some
grouping.
That's
happening
inside
of
the
otlp
exporter
that
we
can
continue
to
improve,
but
this
will
at
least
enable
that
to
finish
the
sdk
api
creation,
which
is
the
package
full
of
those
interface
packet
types
for
the
sdk
to
the
api.
F
So
far,
we've
got
one
type
in
that
package
and
the
next
type
would
be
the
metric
descriptor,
and
I
mean
we
could
have
a
separate
talk
about
the
size
and
how
to
do
to
approach
complex
refactorings
in
this
group.
But
this
is
a
viable
approach
and
I
did
make
efforts
to
keep
it
easy
to
review.
It's
not
small,
but
it
shouldn't
be
too
hard
to
review.
D
This
is
21.97.
Is
that
one
that's.
F
That's
fine
there's,
so
many
optimization
problems
in
in
trying
to
get
refactorings
through
and
and
one
of
them
is,
is
that
risk
and
one
of
them
is
like
end
to
end
time
and
one
of
them
is
turn
around
time
on
each
pr.
So
if
I
had
instant
turnaround
time,
I
could
refactor
and
be
confident
that
the
overall
thing
would
get
done
quickly
and
in
a
small
pr
fashion,
but
it
takes
three
or
four
of
them
and
it's
it's
definitely
more
work,
but
the
but
the
wait
times
are
the
hard
part.
So
I
don't
know.
F
Debate
over
my
entire
career,
it
never
goes
away
right
now
I
gave
you
a
pr
that
is
definitely
large,
but
I
because
I'm
sympathetic
to
that,
I
I
did
it
twice
the
first
time
I
saw
all
the
carnage
and
then
I
tried
to
do.
I
did
it
again
like
trying
to
keep
it
as
neat
as
possible.
F
And
I
wrote
a
good
pr
description
too,
but
I'd
also
be
happy
to
to
like
let
anyone
working
on
the
project
like
focus
on
trace
focus
on
rc2.
This
can
wait.
I'm
also
trying
to
get
a
light
stepper
to
do
the
review
and
I
hopefully
will
have
alex
boaten
do
that
he
just
got
back
so
it'll
be
a
couple
days.
It.
F
F
Yeah
so
he's
going
to
try
to
become
more
involved
in
this
group
overall,
but
he's
also
becoming
trying
to
become
a
collector
maintainer,
which
he's
just
recently
added
as
a
prover
and
that's
a
ton
of
work.
So
I
don't
expect
him
to
be
too
involved
here,
but
he
speaks
go
and
lightstep
wants
him
to
help.
B
E
Yeah
on
on
the
bright
side,
though,
we
did,
on
tuesday
finish,
moving
all
of
the
components
out
of
collector
core
and
indicatrib
and
released
a
new
version
of
the
collector
with
everything
in
its
new
place.
We
are,
I
think,
very
close
to
being
able
to
release.
It
probably
won't
be
a
1.0
rc
of
the
of
the
collector
core.
E
B
Nice,
that's
really
exciting.
Did
you
do
you
have
a
status
update?
I
know
that
there
was
a
move
to
try
to
use
the
underlying
implementations
based
off
of
this
library
and
the
collector
has
that
already
been
achieved.
E
For
tracing
yes,
foreign
metrics,
the
they're
waiting
until
the
metrics
api
has
been
stabilized.
So
there's
there's
some
work
going
on
to
enable
utilizing
the
I
think
enable
utilizing
the
open,
telemetry
metrics
api,
but
make
it
optional.
Do
you
want
to
use
that
or
the
open
census
api?
B
F
Yeah,
I
I
I
don't
blame
them.
I
think
that
after
this
you
know,
hopefully
this
year
we
can
get
something
finished
and
then,
after
this
year
the
collector
can
begin
to
use
it.
I
was
just
having
a
discussion
about
z
pages
with
some
people
at
lightstep
who
are
because
they
were
looking
at
the
sampling
stuff
and
asking.
Why
is
it
this
option
to
keep
a
span
and
not
sample
it?
F
What
would
that
ever
be
used
for-
and
I
know
that
that
exists
in
the
collector,
because
bogdan
cares,
but
it's
an
extension
that
you
couldn't
use
for
your
sdk.
It's
just
a
note
I
feel
like
there
could
be
more
sharing
between
the
collector
and
hotel
go.
I'm
sure
there
are
reasons
why
it's
not
yet,
but
one
day,
maybe.
B
Yeah,
that's
a
yeah.
There
was
a
large
discussion
on
that
one
in
the
spec
repo.
If
I
remember
correctly
as
well.
Okay,
I
think
we're
all
the
way
through
the
agenda
got
a
metrics
update.
We
have
a
plan
for
the
rc,
hopefully
in
the
near
term.
Any
user
stories
that
anybody
has.
I
know
steve,
is
not
on
the
video
anymore
but
I'll
open
it
up.
B
Okay,
well,
I
think
that's
it
for
the
meeting,
then,
unless
somebody
wants
to
wave
and
get
my
attention,
because
I
can't
hear
you
but
cool,
I
guess
we
can
edit
early
thanks
everyone
for
joining.
If
you
have
anything
to
talk
about,
please
hit
us
up
with
slack
and
we'll
see
y'all
virtually
or
next
week
in
the
next
meeting.
Alright
bye.