►
From YouTube: 2020-09-21 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).
C
A
A
B
No
I'm
actually
on
the
road
I'm
trying
to
get
all
the
way
down
to
san
diego
to
visit
my
dad,
while
I'm
staying
quarantined
the
entire
way.
So
I'm
in
an
airbnb
moment.
B
I
wanted
to
get
this
meeting
kicked
off
because
I
think
it's
important
tristan.
Thank
you
for
filling
out.
The
agenda
we
could
probably
just
get
rolling
here
would
be
my
guess.
I
think
this
is
probably
the
crew
and
then
maybe
bring
some
of
this
to
the
maintainer
and
spec
meetings.
Next
to
be
like
hey
here's,
what
we're
thinking,
let's
get
some
more
interest
rolling.
B
I
personally
did
not
have
an
agenda
beyond
that.
We
should
explore
this
and.
A
D
D
My
first
question
is:
is
the
main
point
of
this
context
being
used
to
start
the
span
instead
of
a
span
context
or
a
span
in
order
for
that
context
to
be
passed
to
the
span?
Processor
specifically
on
start
is
that
was
that,
like
one
of
the
original
goals.
B
I
think
there's
two
goals.
Sorry
go
ahead,
yeah.
A
I
think
the
my
main
goal
there
was
mainly
to
have
yeah
more
possibilities
later
to
use
the
context
for
other
stuff,
like
maybe
we
automatically
associate
the
package,
maybe
optionally,
or
something
like
that
and
edit
the
spam
processor
parameter
mostly
because
I
think
it
it
may
make
sense,
and
then
it's
the
the
only
thing
that
that
actually
improves
immediately
if
we,
if
we
just
remove
the
other
creation
options.
A
D
B
There
is
just
this
funny
thing
about
spans
and
tracers,
where
it's
like,
not
quite
the
cleanest
separation,
because
a
span
itself
is
kind
of
a
context
pulled
out,
but
but
it's
just
the
main
thing
of
if
you're
saying
this
flow
of
work
is
jumping
threads
or
otherwise
doing
something
where
automated
context
propagation
might
lose
it
starting
span
is
kind
of
the
only
moment
we
currently
have
in
the
api,
where
you
know
that
the
work
is
moved
somewhere
else.
B
D
B
Own
yeah-
and
you
know
in
the
past,
if
you
really
roll
the
time
back,
we
had
like
a
concept
of
like
context,
snapshots
way
back
in
the
day
in
open
tracing
sure,
specifically
for
this,
if
you
were
saying
like,
I
want
to
move
my
work
from
one
thread
or
another,
you
took
a
snapshot
of
like
you
know,
hey
save
my
game
here
and
then,
when
you
started
the
new
context
in
the
new
thread,
you
would
resume
the
snapshot.
I
don't
know
if
we
need
something
like
that
anymore.
B
We
eventually
decided
we
didn't
need
that
open
tracing,
but
in
languages
like
java,
you
have
a
scope
which
is
sort
of
like
an
equivalent
version
of
this
just
the
place
where
you're
setting
up
a
closure
to
let
all
this
context
get
set.
D
A
Yeah
right
that
was
that
originally
originally
in
this
pr
that
the
context
would
be
stored
by
the
tracer
on
the
span
and
then
you
could
query
it
in
end
from
the
span
but
yeah
like
we,
we
discussed
in
the
elastic
meeting
in
this
backseat
meeting.
We
should
start
with
a
smaller
change
of
just
not
storing
the
context,
just
moving
the
api
to.
A
D
Yeah
I
mean
by
current
context,
I
mean
I
guess
I'm
in
for
that
span,
which
maybe
isn't
the
current
current
context,
but
maybe
it
has
to
be.
Maybe
that's
the
only
on
end
uses
the
current
context.
Then
you
can't.
B
D
Yeah
we
don't
like
in
the
erlang
elixir
implementation.
We
don't
have
methods
on
spans,
so
there
is
no
on
end
that
just
acts
on
a
span.
It's
similar
to
start
that
you're
calling
it
within
the
context.
B
D
B
C
Is
one
of
the
things
that
I
keep
coming
back
to
as
as
we
play
with
these
apis
is
that
in
languages
where
start
span
returns
like
a
span
object
like
I
find
like
half
the
time
you
actually
want
to
stand,
because
the
thing
that
you
want
to
do
is
like
add
some
attributes
or
do
some
stand
related
stuff,
but
I
feel
like
half
the
time
you
actually
want
a
context
like
if
you,
if
you're
manually,
managing
context
like
if
you're
explicitly
managing
things
you
you
want
a
context.
C
So
like
that's,
that's
one
reason
why
I
think
just
operating
on
a
context
would
improve
things,
but
in
lieu
of
that,
having
like
a
few
convenience
methods
to
either
take
a
stand
and
stick
it
into
a
context
or
given
a
context,
pull
the
current
span
out
of
it,
like
those
are
ways
to
kind
of
work
through
all
this,
it's
not
completely
terrible.
B
Yeah,
we
can
certainly
add
convenience
functions
right
in
all
these
languages.
It's
easy
enough
to
add
convenience
functions
that
operate
on
a
context
or
if
the
context
is
automatic,
then
you
know
they
just
operate
without
needing
to
pass
them
anything.
It's
just
a
question
for
me.
The
question
is
like:
is
it
so
dangerous
that
we
should?
B
That
should
be
the
only
way
to
do
it,
or
is
it
just
fine
to
just
have
convenience
methods
and
I'm
kind
of
guessing
convenience
methods
right
now,
including
maybe
some
convenience
methods
for
passing
work
from
one
thread
to
another,
or
something
like
that?
B
B
Is
another
example:
that's
more
where
you're
manually
doing
all
this
context
stuff
and
there's
really
you
get
back
both
the
context
and
span
and
there
is
actually
no
need
for
the
span
object
ever
except
you're
going
to
pay
a
price
grabbing
the
span
out
of
the
context
every
single
time.
You
want
to
do
something
on
it
like
that.
That'll
come
with
like
overhead
and
you
wouldn't
have
the
overhead.
C
B
D
D
That
then
end
users
are
going
to
use
and
they
want
to
start
a
span
and
when
something,
if
something
crashes
or
throws
an
exception,
they
want
to
make
sure
they
end
the
span
they
started
and
reset
the
context
to
what
it
was
before,
so
not
to
have
anything
that
the
user's
code
might
have
done
with
starting
spans
affect
where,
where
it
ends
at
after
it
throws
the
exception-
and
this
has
been
the
big
pain
point
we've
had
and
so
part
of
it
like.
D
The
easiest
has
been
also
returning
a
context
variable,
as
we
usually
keep
that
in
the
process
dictionary
which
is
like
a
thread
local,
but
if
we
also
return
it
because
we
can
return
multiple
values,
then
you
have
that
and
you
can
reset
you
can
attach
that
at
the
after
an
exception
is
thrown.
So
that's
basically
been
the
solution.
D
We've
had
of
returning
the
context
as
a
variable
as
well
that
you
can
use
to
attach
and
try
and
hopefully
keeping
it
to
a
minimal
usage
close
to
like
end
users
who
are
using
the
web
server
install
the
extension
that
does
tracing
and
anything
they
do
doesn't
have
to
do
this
special
contact
stuff.
They
just
start
in
spans
in
the
process.
Dictionary.
A
I
think
that's
kind
of
what
java
also
does
when
you
set
a
span
as
active,
which
is
a
two-step
process
in
java,
because
when
you
start
the
span,
a
context
is
not
really
a
part
of
of
that
just
return.
It
creates
a
new
span
object
and
if
you
want
to
put
that
in
a
context,
you
will
usually
call,
I
think,
it's
tracer.with
span
and
that
returns
the
scope
that
ted
already
mentioned
and
in
the
scope
it
stores
the
previous
context.
So
when
you
close
the
scope,
it
restores
the
previous
code.
B
D
Yeah,
so
the
issue
I
had
with
that
is
related
to
baggage
as
well
that,
if
an
exception
thrown-
and
you
reset
the
context
to
the
one
from
before
now
all
the
baggage
is
gone.
So
you
reset
to
the
right
span
parent
span
that
came
before,
because
you've
attached
the
context
that
you
were
returned.
B
D
Well,
I
guess
even
without
a
exception
like
the,
because
one
of
the
worries
is
that
people
just
don't
end
their
spans,
so
people
want
to
make
sure
they
end
the
right
span
and
not
someone
else's
span,
and
so
they
attach
they
set
a
specific
context
that
they
stored
from
the
parent
and
then
so
they
lose
everything
and
they
want
to
lose
all
the
spans
that
might
be
opened,
but
they
don't
necessarily
want
to
use
lose
the
baggage
so
yeah.
I
don't
know.
B
Where
bad
use
comes
from,
though
I
don't
know,
maybe
in
practice
like
you
just
need
the
baggage.
When
you,
how
do
I
put
it
when
you
start
a
span,
you
need
all
the
prior
baggage.
When
you
continue
to
add
baggage,
you
can
actually
go
the
other
way
right.
If
adding
baggage
or
manipulating
baggage
involves
the
entire
context.
B
D
B
That
would
be
there
like,
let's
say,
you're,
saying:
you've
got
a
thing
that
says
I
wanna
I
wanna
attach
the
pizza
baggage
called
project
id,
and
so,
when
you
start
a
span
you're
like
if
there's
project
id
added
but
from
any
point
onwards,
it's
more
like
when
I
add
baggage,
if
the
baggage
is
called
project
id
also
added
to
the
span.
So
you
just
move
those
processors
over
to
baggage.
B
D
B
A
E
D
B
D
D
That
one
question
I
was
also
asked
is
people
who
want
someone
wanted
the
baggage
to
apply
to
all
the
spans
within
a
trace
within
that
process,
but
that
wouldn't
work
in
this
case
if
you
were
adding
it
later.
So
if
later
in
the
http
stack,
the
project
id
is
parsed
out
from
a
header
and
set
his
baggage.
D
B
D
Yeah,
that
would
make
sense
to
me
that
it's
up
to
the
exporting
that
the
baggage
is
associated
with
a
trace
and
not
trying
to
add
it
to
parents.
A
Would
it
be
probably
associated
with
with
a
trace
and
and
the
resource
like
if
you
just
associate
with
a
trace,
a
trace
goes
across
different
processes,
but
maybe
that
makes
sense
too.
I
don't.
I
don't
know.
B
In
reality,
you
know
one
way
to
use
baggage
is
like
a
correlation
where
you're
saying
I
want
to
use
this
value
specifically
as
an
index
on
this
span
as
an
attribute
or
on
this
metric
as
a
label
and
being
selective
and
then
there's,
maybe
some
other
way
where
people
like
look
just
anytime,
I
set
baggage.
I
want
to
be
able
to
find
any
trace
where
that
baggage
was
active.
B
Something
like
that,
and
for
that
second
case,
I
think
we
should
provide
something
more
elegant
than
a
bunch
of
processors
that
are
constantly
digging
through
all
of
these
things,
like
stapling.
Ever
that's
pretty
inefficient
way
to
do
that
second
use
case,
but
we
can
also,
I
think,
ga
without
something
like
that.
That's
just
the
thing
we
figure
out
how
to
do
under
the
hood.
Every
time
you
add
baggage
to
a
context
it
you
know,
yeah.
D
A
D
D
B
We
we
would
definitely
like
that,
not
the
append
feature.
I
think
that
gets
too
into
the
weeds
of
like
how
it
gets
done,
but
I
think
people
definitely
want
to
be
able
to
like
query
by
baggage
right
they
want
to
if
they
set
up
baggage
to
like
project
id,
they
want
to
be
able
to
query
by
project
id
and
they're
kind.
D
B
Yeah
but
anyways
these
all
get
back
to
like
wow
the
more
we
allow
access
the
context
everywhere,
like
the
more
future
proof.
We
make
this
api
like
that.
That
definitely
keeps
becoming
a
truism,
any
api,
where
it's
like,
there's
just
no
context
available
that
thing's
gonna
be
painful
in
the
future.
B
D
Yeah
I'd
say,
though
yeah
and
from
like
the
code
samples
I
was
suggesting.
The
big
one
is
a
name
is
for
languages
that
can't
return
multiple
values,
how
you
go
into
another
thread
or
process
or
co-routine,
and
attach
that
context
after
you
started
an
inactive
spam
is
the
one
I
don't
know
how
that's
going
to
work.
D
B
A
For
example,
in
java
you
would
there
are
different
ways
to
do
it.
One
is
you,
can
there
is
a?
Can?
There
is
a
method
called
tracing
contextuals
dot,
I'm
not
sure
it's
also
called
with
span
or
something
where
you
pass
in
a
parent
context
in
a
span,
and
it
get
gives
you
back
a
context
that
contains
that
span,
and
then
you.
A
To
another
thread,
or
you
can
just
make
the
span
active,
like
tracer.twift
span
and
then
grab
the
current
context.
These
are
the
two
things
you
can
do.
D
A
If
you
do
yeah,
if
you,
if
you
do
that
exactly
you
can
have
to
make
it
inactive,
although
if
you
use
the
first
method,
I
described
it
just
returns,
you
back
context,
but
that
context
is
not
active
on
the
current
thread.
Again,
it's
just
a
an
object
that
sort
of
dangling
around
and
yeah.
A
D
C
Yeah,
the
helper
methods
that
we're
using
that
solve
these
use
cases
there's
a
tracer
context
with
span
if
you
have
a
span
but
would
like
to
insert
it
into
a
context
and
by
default
that
will
kind
of
derive
your
context
off
of
the
current
context.
C
So
the
current
context
would
be
the
parent,
but
you
could
pass
in
some
random
context
if
you
wanted-
and
I
guess
the
other
way
around-
we
still
have
tracer
current
span,
but
it
it
optionally
takes
the
context
to
extract
the
current
span
out
of
and
both
of
those
have
worked
pretty
well
for
us.
I've
kind
of
peeked
out
what
java
has
and
they
have
a
slightly
different
system,
there's
a
context,
utils
class
that
does
all
the.
D
Scope,
which
makes
some
of
this
stuff
easier
than
languages
that
don't
like
for
ruby
and
python
and
javascript,
I
think,
are
all
similar,
and
when
you
end
the
span
does
the
previous
con.
How
does
the
context
know
that
the
now
active
span
is
the
one
that
was
started
that
was
running
active
before
you
ended
the
span.
A
C
Ours
are
all
kind
of
context,
based
basically
all
the
things
that
allow
you
to
set
the
active
context.
They
they
run
a
block
in
that
active
context,
so
they're
all
kind
of
like
block
scoped
and
like
if
an
exception
did
happen
like
that,
would
get
rescued.
That
context
would
be
deactivated
and
then
the
exception
would
be
re-raised,
so
we
kind
of
like
we
don't
have
like
manual
attach
and
detach.
C
D
I
believe
we
exposed
it
and
yeah.
I
worry
about
that.
Instead
of
requiring
passing
anonymous
functions
every
time
you
want
to
start
a
span
which
we
probably
should
do,
but
I
don't
think
people
will
be
happy
with
that.
So
I
don't
know
I
feel
like
in
ruby.
This
is
not
too
bad,
like
it
kind
of.
Is
that's
common
right.
It's
just
common
to
you,
go
into
a
block
and
for
the.
C
A
I
think
in
the
python
built-in
context,
so
that
exists,
since
I
think
python,
3.7
or
3.8,
and
it's
also
a
closure
passing
style.
If
so,
if
you
want
to
set
the
context
as
active,
you
can
only
do
that
within
some
block,
but
I
don't
know
how
far
the
python
implementation
deviated
from
that
other
telemetry
python
implementation
deviated
from.
That.
B
Hey
cats,
unfortunately,
I
have
to
jump
off
this
call
and
hit
the
road
y'all
can
keep
talking.
Of
course,
I
just
want
to
say
good
conversation,
but
unfortunately
I
have
to
get
on
the
road
cool
yeah
thanks
for
facilitating.
Thank
you
yeah.
This
is
great.
It
does
sound
like
some
action
items
for
like
investigating
these
some
of
these
code
samples
and
situations
in
a
couple
different
languages.
It's
like
the
appropriate
next
step.
B
I'd
rather
be
recommend
bringing
that
up
at
the
maintainers
meeting
at
you
know
in
30
minutes
asking
the
maintainers
to
just
give
it
a
shot
to
do
some
of
these
code.
Samples
make
sure
it's
all
kosher,
especially
that
bit
about
exceptions
potentially
like
how
does
non-local
return,
potentially
muck
up
the
active
context.
C
A
I
think
often,
if
you
like,
if
you
use
an
implicit
parent,
you
don't
call
set
parents
yourself,
then
the
current
context
in
onstart
should
actually
be
the
parent
context.
Yes,
that
would
work,
but
if
you
explicitly
yeah
it's,
I
think
it
is
required
for
the
set
parent
case
and
also,
if
you
say,
I
think,
that's
also
a
special
case
of
said
parent.
If
you
say
this
should
be
a
root
spend
and
there
should
be
an
empty
context.
A
D
E
C
So
I
think
for
me
the
thing
that,
like
I
think
this
is
okay,
but
the
thing
that
kind
of
confuses
me
or
I
have
trouble
with,
as
I
think
through.
This
is
like
the
situation
where
you
well
in
general,
when
you
start
a
span,
you
aren't
exactly
starting
a
new
context.
C
It's
like
you
need.
You
need
to
do
this
separately,
and
if
you
don't
do
this
separately,
you
you
can
run
a
span
completely
with
some
other
context
like
as
the
current
and
never
never
actually
attach
it
to
a
specific
context,
and
I
think
that's
okay,
I
in
some
ways
I
think
it's
probably
like
a
feature,
but
it's
just
I
don't
know
it's.
A
A
C
C
It's
just
a
little
bit
unusual
that,
like
most
fans,
will
spans
in
the
middle
or
further
up
the
trace
will
have
had
like
an
explicit
context
that
they
kind
of
ran
in,
and
these
other
ones
can
kind
of
like
share
their
parents
if
they
want
to
in
some
ways
it's
like
a
slight
optimization
and
that
you
don't
have
to
like
create
a
new
context.
If
they're,
nothing
has
really
changed.
Anyways.
D
C
A
Yeah,
I
don't
think
I
don't
know
if
we
can
discuss
this
here,
but
one
thing
I
would
be
interested
in
I
in
my
mind
I
don't
really
have
a
concept
of
what
baggage
is
so
to
speak.
I
mean
it's
some
key
value
pairs,
but
for
what
you
would
use
it
as
opposed
to
say,
span,
attributes
or
metric
labels,
or
is
it
just
supposed
to
be
a
like
convenience
api
that,
at
the
same
time
said
span,
attributes
and
metric
labels.
D
Well,
baggage
can
be
yeah
different
things
because
I
know
there's
a
paper
on
how
wechat
does
overload
that
basically
uses
baggage,
but
I
don't
know
if
they
call
it
that,
but
it's
a
way
to
propagate.
I
guess
the
key
value
pairs
because
attributes
don't
get
propagated,
so
you
can't
do
any
logic
on
them
later.
A
D
Yeah
yeah,
but
for
what
yeah
for
where
it
goes
for
just
analyzing
and
looking
at
spams,
I'm
not
really
sure,
except
for
maybe
like
that
stuff,
like
the
user
id,
if
you
can
associate
it
with
the
whole
trace,
but
right
now
we
don't
really
have
that
capability.
So,
but
if
we
start
exporting
package
then
we
will.
C
About
baggage,
I
found
this
article
I
think
it's
it
was
written
by
yuri
yuri
shiguro
a
while
ago,
and
I
think
I
think
his
use
is
kind
of
maybe
overlap
ever
so
slightly
between
baggage
and
context
in
in
and
correlations,
if
we
even
discern
between
those
any
longer
we've
kind
of,
I
think,
we've
waffled
back
and
forth
whether
they're
a
different
thing
or
not.
It's
like
they
definitely
have
the
same
shape.
The
data
has
the
same
shape
the
semantics,
maybe
they're
different,
but
whatever
the
case.
C
This
provides
a
number
of
kind
of
real
world
use
cases.
D
A
A
Okay,
then
see
you
thanks.