►
From YouTube: 2020-09-28 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
Chickens,
I'm
like
no.
I
have
had
enough
tickets,
I
buy
my
eggs
at
the
store,
that's
cool
yeah,
we're
doing
a
lot
of
plant
carving,
which
has
gotten
a
lot
seener.
Now
that
we've
set
irrigation
up,
but
that
was
really.
B
A
B
A
A
Yeah
sure,
actually
we
got
matt
here
as
well.
My
computer's
almost
done
rebooting
so
I'll
be
able
to
switch
switch
to
a
regular
screen,
but
in
the
meantime
we
can
get
rolling.
I'm
not
sure
if
anyone
put
anything
on
the
agenda,
because
no,
you
can't
really
talk
and
look
at
things
at
the
same
time
on
the
stupid
phone.
A
My
other
question
is:
has
anyone
written
any
code
samples?
I
know
that
was
a
thing
we
discussed
last
week.
Was
you
know
code
samples
to
prove
something?
Is
there
isn't
a
concern
in
a
certain
language
right
now.
A
A
Is
there
a
specific
issue,
that's
been
created
on
this?
It
might
be
a
thing
to
do
as
well.
If
you
don't.
C
C
A
I
pasted
the
paste
it
into
the
meeting
notes.
People
want
the
link
so
yeah.
Would
you
mind
summarizing,
what's
been
going
on
in
this
thread
and
where
it's
gotten
to.
C
Yeah,
so
basically
bogdan
thinks
that
there
are
too
many
places
where
you
can
get
or
set
the
active
span,
and
that
should
be
decreased
to
one
single
place.
So
basically
he
says
we
should
move
those.
We
should
remove
tracer
active
span
and
tracer
with
spam
to
activate
the
span,
and
we
should
have
only
one
method
in
module
level
or
static
class
right.
That
has
only
just
one
method:
that's
basically
what
he
wants
and
he
doesn't
even
want
an
overload.
C
A
That
actually
seems
pretty
great.
That
seems
pretty
future
proof
to
me.
I
certainly
like
it
being
separated
from
I
feel
like
when
the
tracers
became
name
tracers,
that
all
got
hella
confusing
and
like
attaching
behavior
to
those
things
now,
I
think,
confuses
people,
so
I
definitely
agree
with
you
there.
I
think
it
would
be
make
a
lot
more
sense
to
people
if
they
didn't
have
to
touch
that
thing
to
get
the
active
span.
C
Yeah
so
well,
one
of
the
things
that
came
up
on
that
is
that
he
grant
mentioned
that
he
would
like
to
see
some
code
some
actual
code.
You
know
so
that's
yeah
so
so,
of
course,
spoken
was
trying
to
provide
some
examples,
but
it's
like
examples
that
he
cooked
on
the
fly,
but
we
need
actual
more
actual
stuff
and
probably
the
test
bed
that
we
ported
from
open
tracing
could
help
there,
and
we
also
need
to.
A
Right
so
I'm
trying
to
think
we
had
a
couple
of
things
in
open
tracing
right,
including
we
had
tests
and
examples
for
various
contexts
and
scope
related
things,
at
least
in
java.
I'm
not
sure
if
we
had
that
in
python
as
well.
Is
that
what
you're
talking
about?
Are
you.
C
C
Yeah
yeah
so
yeah,
so
that's
one,
that's
one
of
the
things
we
need
to
actually
prototype
them,
even
if
it
means,
even
if
it
means
delaying
ga
well
with
the
condition
that
nothing
else
gets
added.
You
know
we
just
respect
the
previous
agreement.
It's
like
a
free.
You
mean
right
that
this
is
going
to
be
the
exception.
I
mean
we
have
minor
editorial,
mostly
editorial
changes
that
still
can
come
up
come
in,
but.
A
That's
all
I,
I
think
it's
fine.
What
you
can
say
is
there's
now
a
freeze
to
new
issues
being
labeled
required
for
ga
tracing.
You
know
no
right
like
we
just
can't
make
any
more
of
those
but
we'll
clear
out
the
existing
ones.
So
I
think
that's
fine
to
announce
that
spec
freeze
from
that
perspective,
but
yeah
we
do
need
to
actually
freeze
the
damn
specs,
so
people
can
implement
all
this
and
okay.
This
is
totally
gonna
change,
implementations
and
probably
break
people's
production
code.
When
we
do
this,
especially.
C
A
A
Oh,
it's
not
this
one
here,
I'll
post
the
this
link,
I
just
posted,
is
this
the
one
you're
talking
about?
I
added
it
to
the
agenda.
C
C
C
I
remember
that
in
open
tracing
we
have
a
tracer,
sorry,
a
shortcut
in
the
tracer
for
active
span
and
for
activating
span.
The
good
thing
is
that
we
clearly
documented
that
that
this
method
and
tracer
it's
a
shortcut,
and
this
is
the
calling
behind
the
scenes
this
class
with
these
parameters.
C
C
A
Believe
yusuki
was
asking
for
something
like
this
in
python.
Right
like
what
it's,
the
independent
of
cleaning
up
context
propagation.
I
think
there
were
already
requests
for
simplifying
how
you
get
the
active
span
rather
than
having
to
make
a
tracer
every
time
you
want
to
grab
it.
So
I
think
that's
work
was
already
in
flight,
so
don't
know
it
feels
like
a
good
cleanup,
yeah
yeah.
C
B
I
don't
think
I
have
really
doubts.
Where
was
it
I'm
trying
to
find
him.
B
Oh
yeah,
it
would
I
mean
in
this
particular
issue.
My
main
thing
was,
I
didn't
think
it
actually
showed
there
were
multiple
places,
but
I'm
happy
with
the
having
a
separate
and
not
using
requiring
a
name
tracer
to
get
get
the
span
out
of
the
context
stuff
like
that.
I
think
this
is
a
good
move
forward.
B
B
C
A
B
C
C
A
You
know
you've
just
unpacked
some
kind
of
trace
context,
and
you
only
have
that
information
yeah
and
you
want
to
differentiate
between
that
thing
versus
one
you've
made
locally.
That
seems
like
a
very
under
the
hood
thing.
It
doesn't
seem
like
I'll
look
into
that
doesn't
seem
like
a
thing.
We
end
users
should
care
too
much
about.
B
C
B
B
D
Yeah,
so
I'm
just
kind
of
looking
at
like
his
comment
that
I
think
it
describes
the
current
state
of
java,
which
looks
very
unique
to
me.
I
don't
know
if
this
stuff
is
specced
or
not,
but
if
it
is
like
it
definitely
has
not
made
it
into
ruby
and
javascript.
C
Yeah
basically
yeah
in
java,
it's
a
little
bit
different
because
we
have
repeated
stuff,
but
we
were
supposed
to
be
cleaning
after
and
the
other
problem
is
that
pogden,
if
I
remember
correctly,
he's
not
very
familiar
with
any
of
any
of
the
other
implementations
of
context
propagation,
so
yeah.
D
Yeah
so
like
I
agree
that
that
looks
like
it's
a
mess.
I
think
it's
been
merged
into
the
spec,
so
so
I
yeah,
I
think
that
definitely
needs
to
be
cleaned
up
a
bit
so
right
now
like
in
ruby
anyways,
I
think
we
have
like
two
additional
methods
that
seem
to
have
smoothed
over
all
these
context.
Things
they
are
tracer
current
span
takes
a
context
optionally
or
it
just
retrieves
the
span
from
the
current
context
or
there's
tracer
context
with
span
which
will
insert
the
span
into
a
context.
D
I
don't
know
me
and
the
other
maintainer
kind
of
went
back
and
forth
on
those
a
little
bit
and
I
feel
yeah
like.
I
think
there
are
several
proposals
as
to
where
these
things
should
live
and
it
looks
like
java
is
throwing
them
on
kind
of
like
a
separate.
You
know
as
like
static
members
on
some
separate
name,
space.
D
I'm
just
thinking
about
there's
kind
of
like
this
future
proposal
that
maybe
we
remove
span
someday
and
everything
kind
of
goes
through.
Tracer
anyways,
the
tracer
just
operates
on
a
contacts,
and
if
you
have
like
you
know,
you
know,
tracer
dot
span
set
attribute.
It's
still
on
tracer,
like
all
the
things
that
deal
with
span
live
on
tracer,
and
I
feel
like
that
really
makes
a
lot
of
sense
to
me.
I
don't
know
why
we
need
to
introduce
this
new
name
space
for
these
methods.
D
That's
not
tracer,
I
would
say
the
one
thing
I
think
ted
mentioned
at
the
beginning,
that
I
agree
with
it's
a
little
weird.
These
name
tracers
mess
it
up
a
bit.
I
could
see
them
at
a
bare
minimum
if
they're
not
bound
to
any
trace,
or
instance,
just
meaning
like
static
methods
on
on
a
tracer
and
it
solves
the
oh.
I
have
to
get
a
tracer
to
do
this.
You
can
just
call
them
yeah.
B
I
agree
with
that
too,
and
I
mentioned
that
my
last
comment
on
this
thread
is:
it
feels
like
implementation
bleeding
into
the
spec
and
the
actually
in
the
early,
the
laser
implementation
it
is
like
tracer's
set
attribute,
because
I
mean
tracer
isn't
a
object
in
itself:
it's
just
a
module,
but
because
the
span
is
being
read
out
of
a
context
and
then
operate
it
on
in
these
default
operations.
It's
just
done
through
the
tracer.
So
I
think
that
is
the
right
is
a
good
way
forward.
D
Yeah,
I
feel
like
anything
spam
blah,
blah,
blah
and
tracer
is
the
place
for
that
yeah
unless
it's
spam-
and
I
don't
feel
like
this-
this
is
a
span
concern.
C
A
Yeah,
and
if
these
things
literally
don't
interact
with
the
name
tracer
concept
in
any
way,
it
would
be
super
great
not
to
force
end
users
to
have
to
generate
a
tracer
in
order
to
do
anything
with
making
active,
spans
and
stuff
like
that,
the
name
tracer
thing
is
like
okay
for
someone
writing
an
instrumentation
plug-in.
It
doesn't
look
too
crazy
when
you
do
it
there.
A
It
is
super
obnoxious
and
confusing
to
try
to
use
that
thing
if
you're
just
trying
to
instrument
your
application
code-
and
you
want
to
add
an
event
or
you
know
an
attribute
or
get
a
piece
of
baggage
or
something
like
that
like
having
to
name
an
object
and
build
it
and
then
go
use
it
just
for
that
one
liner
sucks
it
not
only
sucks.
That's
like
the
first
place
where
end
users
get
truly
confused
by
the
api,
like
new
new
application
developers,
because
the
whole
naming
a
tracer
thing
messes,
with
their
getter
setter
pattern.
A
Tracer,
but
I
never
said
a
tracer
like
what's
happening
here,
do
what,
if
I
call
it
the
wrong
name,
does
it
break
you
know,
so
I
would
love
to
just
get
all
of
that
out
of
people's
hair,
so
that
application
developers
just
don't
have
to
think
about
that
stuff.
I
would
even
be
fine
with
there
being
a
default
tracer.
That's
always
around
called
application,
or
something
like
that
that
application
developers
use,
rather
than
forcing
them
to
always
make
a
tracer.
C
Things
yeah
either
way.
I
think
we
really
need
to
really
research
sometime
this
week
to
prototype
this.
Yes
right
since,
since
this
is
something
that
may
break
stuff
more
really
neat,
we
really
really
need
prototypes
in
many
languages.
B
Actually,
one
thing:
that's
not
clear
to
me
from
this
is
if
it
looks
like
he
has
the
utils
class
in
the
api,
and
it
has
the
key.
So
is
the
api
where
the
context
key
should
be
living
is
every
I
mean.
I
guess
you
can't
have
multiple
sdk,
I'm
just
thinking
about
if
they
could
override
each
other
in
a
context.
Well,.
C
B
A
So
how
do
we?
How
do
we
roll
forwards
with
this?
Besides
chatting
on
that
that
issue
thread,
we've
got
this
maintainers
meeting
coming
up
in
30
minutes,
so
that
would
be
an
opportunity
to
to
propose
some
wider
action.
If
we
want
to
get
other
maintainers
involved,
it
seemed
like
maybe
recreating
something
like
that
test
bed
or
something
similar
enough
to
that
in
languages.
A
That
wanna
ga
might
be
helpful,
but
I'm
interested
to
hear
from
you
guys
what
you
think
might
be
a
good
plan
action
here
to
get
the
rest
of
the
maintainers
involved.
C
Yeah
like
big
example,
creativity,
big
examples-
you
know
not
like
simple
for
the
snippets
that
show
tv
cases
great,
I
I
can't
I
can
do
the
prototype
myself,
because
probably
both
them
will
be
too
busy
doing
that
in
java.
C
A
Yeah,
I
just
want
to
make
sure
we
get
enough
maintainers
thinking
about
this,
so
that
we
don't
come
up
with
a
thing
and
then
surprise
everyone
and
then
get
like
more
feedback
and
keep
passing
it
out.
It's
been
great
yeah
avoid
that.
C
A
D
One
thing
I
think
that
was
going
to
happen
from
the
ruby
side
was
the
other
maintainer.
He
works
for
shopify,
and
they
have,
I
guess,
a
kafka
instrumentation
that
they
wrote
internally.
I
think
they
wrote
it
using
census
or
something
it's
using.
Something
not
not
open
tracing
are
not
open
telemetry
and
he
said
it
was
pretty
exotic
and
they
had
to
rely
on
a
lot
of
like
manual
propagation.
D
So
he
was
going
to
just
try
to
rewrite
that
using
open
telemetry
off
of
my
fork
for
the
prototype
just
to
make
sure.
A
A
A
D
A
A
Side
effects,
but
we
don't
you
know,
we've
done
all
this.
A
lot
of
thought
and
effort
into
you
know:
transactions
like
http,
but
you
know
one-way
protocols
I
feel
like
we
haven't,
put
a
lot
of
work
into
and
it's
still
kind
of
confusing
how
you
should
be
approaching
things
like
rabbit,
mq
and
kafka
and
stuff
like
that.
D
A
Yeah
yeah,
I
think
message:
queues
are
a
whole
ball
of
beeswax.
My
my
experience
with
them
is
there's
like
the
problem
is
there's
no
one
good
answer,
because
there
tends
to
be
one
way
to
use
something
like
http,
but
there's
many
ways
you
might
be
using
something
like
rabbitmq
or
kafka,
and
so
there's
not
one
size
fits
all
solution
to
how
you
should
be
instrumenting.
That
thing.
D
A
Yeah,
but
you
also
then,
are
left
with
the
issues
of
having
to
to
sort
out
all
the
propagation
yourself
and
stuff,
because
it's
often
not
nearly
as
simple
to
write
a
plug-in
that
does
it
for
you,
like
batch
processing,
comes
to
mind
of
like
pulling
out
batches
of
messages
like
it's
hard
to
encapsulate
that
with
something
baked
into
open
telemetry
for
getting
the
context
out
of
those
things
and
doing
something
with
them
other
than
you
know.
Just
writing
your
own
bespoke
extract
stuff,
so
yeah
through
your
thoughts.
A
Okay,
I
feel
like
we
have
some
next
steps.
It
sounds
like
bringing
that
thread.
The
issue
thread
to
a
close
and
getting
stuff
baked
into
the
spec.
That
way
is
probably
the
the
most
straightforward
way
to
resolve
this.
A
Yeah
anyone
else
have
anything
else.
You
want
to
talk
about
right
now,
or
should
we
get
30
minutes
back.
D
Can
I
borrow
like
three
minutes,
I
think
yeah
you
got
to
give
them
back
later,
okay,
sure
yeah.
So
this
is
slightly
since
this
is
a
context
meeting
and
my
question
is
about
b3
I
figured
I
could
like
take
this
one
in,
and
mainly
I
was.
I
was
working
on
some
stuff
in
js
the
other
day
and
realized
that
its
implementation
is
very
unique
compared
to
the
rest
of
open
telemetry,
which
is
kind
of
like
a
slightly
problematic
thing.
D
It
interoperates
on
the
important
points
and
that's
kind
of
what
I
realized
so
like.
I
have
spec
issue
1004
basically,
and
so
the
important
points
are
span
id
trace
id
and
the
sampled
flag.
As
long
as
you
get
that
right,
stuff
works
for
as
far
as
open
telemetry
is
concerned,
the
things
that
get
weird
are
the
parent
span
id
and
the
debug
flag,
because,
like
most
implementations,
just
want
to
be
able
to
extract
the
context,
turn
it
into
a
span
context.
D
Stick
that
in
the
current
context-
and
you
know
for
open
telemetry,
we
have
room
for
for
a
you
know:
a
parent
span
id
or
a
span
id
in
b3
nomenclature,
a
trace
flag
for
sampling,
but
not
debug.
A
Right,
so
is
you
know
how
different
is
debug
behavior
or
do
we
respect
it?
That's
a
good
question.
D
So
so,
ultimately
I
just
wanted
to
like
I
don't
know,
I
don't
like
I
as
I
go
through
this.
I
don't
think
we
can
be
b3
purists.
I
think
we
can
at
best
make
sure
that
we
just
don't
mess
up
b3
and
use
it
as
kind
of
a
way
to
propagate
the
things
that
matter
for
otel
the
things
that
kind
of,
like
you
know
make
me
feel
slightly
guilty
about.
This
is
like
I
work
in
the
w3c
distributed
tracing
working
group.
We
have
like
this
test
suite,
for
you
know,
trace
contacts.
D
Luckily,
I
don't
think
the
b3
folks
have
that
if
they
did,
we
would
never
be
able
to
pass
it,
and
that
was
kind
of
like
the
thing
that
was
going
through
my
mind
as
I
was
opening,
but
I
think
I
just
want
us
to
agree
that
we're
going
to
implement
this
kind
of
80
of
b3
that
works
for
the
most
part
and
write
that
down
somewhere,
mainly
so
open
pr's,
or
they
have
questions
they're
like.
Why
are
you
doing
this
this
way
or
why
isn't
parents
fan
id
there
or
why
did
you
delete
this?
B
A
No,
it's
it's
like
a
zipkin.
I
believe
zikan
has
actually
changed
his
behavior
on
this,
but
that
comes
from
them.
Wanting
the
client
and
servers
fan
ids
to
have
the
same
id.
That
was
just
how
zipkin
works
or
used
to
work.
Is
they
try
to
to
marry
the
client
and
servers
fan
ids
together?
It's
like
a
single
fan
concept
thing,
so
they
have
like
a
couple
different
id
types
based
on
whether
or
not
you're
trying
to
do
that
versus
whether
or
not
you're
doing
the
you
know
open,
telemetry
style
of
like
you.
A
Just
every
span
has
its
own
id
and
you
just
get
your
parents
fan
id.
So
the
reason
why
they
have
parent
span
id.
If
you
see
that
in
there
that
means
you're
supposed
to
name
your
new
span,
the
same
span
id
as
it's
handing
you.
So
it's
giving
you
your
span
id
and
if
you
wanted
to
know
who
the
parent
of
this
on
the
client
side
was
it's
telling
you
that
too.
A
But
it's
also
telling
you
you
should
use
this
fan
id
as
your
span
id
and
then
I
can't
remember
if
we
just
don't
put
the
parent
id
or
if
we
just
put
the
span
id,
but
I
think
what
the
way
you're
supposed
to
do.
It
is
just
grab
the
parent
id
and
ignore
the
stan
id,
but
we
should
make
sure
we're
doing
that
correctly
everywhere.
B
A
B
A
Yeah
I
mean
in
theory,
you
should
just
be
able
to
go
to
the
b3
specification
and
do
it
from
there,
because
there
is
one
I
don't
know
if
you've
looked
at
it,
but
it
it
also
is
a
little
fuzzy
on
some
of
these
exact
points.
A
A
Complaints
about
what
what
we're
doing
wrong
that
would
be
wise.
I
think.
D
Yeah,
so
I
think
most
of
what
you
were
saying
was
right.
The
the
one
thing
I
will
clarify
is
that
the
parent
span
id
is
literally,
it
is
kind
of
the
grandparent
id
of
the
operation
on
the
other
side.
So
you
see
so
this
span
id
is
the
effect
of
parent.
In
the
case
where
you
do
want
to
like
share
the
same
on
each
side,
you
can
take
that
as
long
as
there
is
this
kind
of
oh
right,
yeah.
D
Yeah
and
and
the
parents
fan
id
is
optional
so,
like
it
looks
like
zipkin
knows
that
you're
not
always
going
to
have
a
grandparent,
you
know
so
like
it
will
work
right,
yeah.
The
whole
reason
I
bring
this
up
yeah.
I
guess
it's
actually
sounds
like
it's
actually
an
issue
for
other
folks,
which
is
great
but
yeah.
I
if,
if
anybody
has
opinions
on
this,
I
think
I'm
more
than
happy
to
write
these
down.
D
I'm
just
trying
to
get
like
some
consensus
that
we
can
totally
just
forget
about
parents
fan
id,
because
that
will
make
our
lives
easy.
If
that
is
true,
yeah
yeah
number
two,
we
could
technically
support
this
forcing
a
debug
trace,
but
I
don't
think
it's
like
an
open,
telemetry
feature.
I
just
want
to
convert
that
thing
over
to
like
a
positive
sampling
decision
for
for
open
telemetry
sampling.
True.
A
D
A
A
A
A
little
weird
yeah,
don't
sam,
don't
sample
in
debug
mode,
is
a
little
confusing
right.
A
Sample
yeah
yeah
that
that
makes
sense
where
we,
if
we
see
a
debug
flag,
then
we
convert
it
to
sampling.
The
trickier
bit
is
actually
when
we
inject,
is
there
a
way
to
recover
whether
debug
your
sampling
was
set.
B
We
should
do
that
because
we're
not
going
to
have
to
be
able
to
set
the
parent
thing
either.
So.
A
A
Yeah
wait,
but
you
don't
need
to
send
that
right.
The
things
we
need
to
send
are
sampling
and
debug
bit
right,
like
yeah.
A
Zipkin
systems
will
understand
how
to
handle
getting
b3
without
apparent
span
id,
but
it
would
change
their
behavior
to
not
propagate
sampling
or
debug
correctly
yeah.
I
feel.
D
D
A
All
implementation
details
the
only
thing
where
you're
gonna
look
at
this
stuff.
More
detailed
is
like
this
sampling
api,
for
example,
and
the
span
processor
api
like
for
sampling.
They
do
want
to
dig
into
trace
state,
for
example,
when
making
sampling
decisions.
A
I
don't
totally
know
how,
like
the
b3
stuff
fits
in
with
that
that's
an
area
where
maybe
we're
you
know
we're
exposing
this
w3c
model
to
people
and
that's
helpful
for
them
to
write
their
sampling
plugins
right
because
they
actually
are
storing
stuff
like
sampling,
priority
and
things
like
that
in
there.
But
I
don't
know
that
we've
actually
thought
through
what
if
people
are
using
a
different
protocol
and
there's
stuff
in
that
protocol
that
they
want
to
use
in
these
plugins.
B
B
We
actually
don't
allow
that
or
don't
support
it.
It
wouldn't
be
a.
D
B
A
Yeah,
that
would
maybe
be
a
thing
we
could
literally
ask
the
zip
king
community
is
like
everything's
easy
to
support
except
the
debug
flag.
It
would
be
a
weird
one-off
to
try
to
support
it
right
now.
How
much
do
you
guys
care?
Do
you
not
use
this,
or
do
you
use
it?
D
C
D
A
D
D
Cool
yeah,
no,
I
I
think
we've
discussed
what
I
had
to
discuss
here.
I
I
just
asked
if
anybody
has
opinions
and
wants
to
drop
them
on
this
issue,
that's
fine
and
maybe
I'll
just
bring
this
up
at
the
maintainers
meeting,
so
that
was
kind
of
the
thing
that
spawned
this,
as
I
was
just
like,
going
through
all
the
implementations
and
being
like
okay,
this
is
all
working
a
little
bit
differently.
D
We
just
need
to
make
sure
that
we
agree
on
the
hotel
variation
of
b3
because
I
don't
think
supporting
it.
Outright
is
probably
going
to
work
very
well.
A
If
it's
going
to
be
useful-
and
this
is
one
of
those
edge
cases
but
to
a
certain.
B
A
B
D
A
Right,
like
yeah,
I
I
don't
think,
that's
a
requirement
for
ga
and
we
could
certainly
add
support
for
that
later,
and
it
will
just
be
some
crap.
We
pack
on
potentially
the
trick
is
to
do
it
without
our
api
up
or
forcing
extra
overhead
doing
things
like
checking
trace
date,
or
you
know,
class
checking
or
some
crap.