►
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).
A
A
First
of
all,
I
guess
actually
let
me
check
the
document.
Sorry.
I
just
wanted
to
say
something
on
my
behalf,
but
let
me
check
the
actual
doc:
okay,
yeah
no
agenda
items.
Yeah
in
case
you
didn't
see
that
I'm
hoping
that
he
will
probably
hear
where
he
slept
but
yeah.
We
need
one
more
approval
on
on
the
ot
one
seven
zero
and
we
need
one
more
well,
a
few
more
on
the
one,
six,
eight,
so
yeah,
that's
something.
B
Well,
here
we
are,
I
see
that
yuri
approved
the
pr
1889
1899
yesterday,
that's
good
progress.
There
are
some
questions
on
that
and
the
otep
both
all
from
atmar,
and
I
wanted
to
make
sure
we
discussed
those
and
then
hopefully
see
what
we
can
do
to
get
168
merged.
I
I
don't
like
having
open
oteps
when
you're
discussing
a
spec
change.
It's
it's
been
a
problem
in
the
past
and
I
don't
I'm
not
going
to
go
there.
It's
part
of
the
reason
why
I
didn't
want
to
respond
to
1899.
B
those.
There
was
a
question
about
the
name
of
the
field,
whether
it
should
be
head
or
parent.
That's
one
thing
we
can
discuss
and
then
there's
this
question
about,
reject
and
the
probabilities
at
the
extreme,
and
it's
probably
nobody
actually
cares
about
that.
But
it's
probably
worth
discussing
and
finishing
the
detail
here.
I
actually
feel
like
there
are
probably
some
bigger
questions
that
have
been
not
quite
surfaced
and
I
wanted
to
discuss
those
as
well,
which
maybe
that
could
be
third,
I
see
we
have.
B
No,
we
don't
have
yuri.
That's
not
that's
that's.
That
would
help
if
we
did,
but
I
didn't
intend
to
run
this
meeting.
So,
let's
see
admiral,
would
you
like
to
talk
about
the
naming
of
the
field
yeah,
I'm
going
to
bring
up
that
yeah.
C
I
mentioned
a
scenario:
if
you
have
a
multiple
probability
samplers
and
then
you
have
a
parent
sampler
so
and
the
question
is
which
to
which
sampling
decision
the
parents
temporary
first
to
visit
the
sampling
decision
of
the
head,
so
in
this
case
a
or
the
sampling
decision
of
b.
So
I
would
say
it's
always
the
cop.
It
always
copies
the
sampling
probability
of
the
the
direct
parent
right.
C
So
if
so,
so
the
typical
scenario,
if
you
want
to
have
head
based
sampling,
you
have
a
probability
sampler
at
the
beginning,
and
then
you
have
the
parent
samplers
for
b
and
c,
so
the
for
b,
the
parent
is
a
so
it
copies.
The
probability
of
a
and
c
would
get
the
copy
from
b.
So
it's
basically
it's
always
forwarding
the
parent
probability
and
and
of
course,
in
this
case
it's
also
the
head
probability,
but
I'm
thinking
a
step
further.
C
If
there
are
multiple
probability,
samples
involved
and
also
parent
samplers.
So
maybe
it's
so.
The
question
is
what
should
happen
then
right.
B
I
guess
this
sounds
like
it's
a
terminology
question
mostly.
I
think
we
agree
on
what
the
probabilities
are
in
those
cases
right
and
then
I
guess
I
had
been
thinking
of
the
word
head
as
being
like
the
leading
probability
in
effect,
so
at
the
moment
c
starts
it
has
a
head
is
what
I
was
thinking,
which
was
like
everything
ahead
of
it
sort
of
thinking
of
the
word,
but
I
I
we're
sort
of
making
that
up.
B
C
Same
thing,
probability
of
b
right,
so
the
parent
sampler
samples,
if
b,
is
sampled
right.
So
it
will
be
the
the
parent
probability
is
relevant.
I
mean
it's,
it's
just
a
naming
thing
because.
B
Yeah
like
it
goes
back
to
because
we
could
actually
just
remove
the
word
head
entirely,
and
I
that
was
an
option
that
I
thought
of
and
what
what
I
feel
like
as
we
came
to
this
after
having
discussed
tail
probability
or
for
a
long
time
and
how
it
seemed
like
the
same
concept
and
the
same
counting
logic
happening.
If
you're
going
to
do
tail
sampling
so
to
create
a
distinction
from
tail.
B
C
B
Yes,
that's
what
you
had
been
assuming
unless
I
see
that
I
see
the
misunderstanding
potential
for
misunderstanding.
So
maybe
head
is
not
so
great,
but
then
is
parent
right.
Is
that
always
I
don't
know
I
have
to
think
about
this
for
a
minute.
B
Naming
is
hard,
I
mean,
I
mean,
as
I
said
it,
the
word
initial
comes
to
mind
as
well,
so
this
to
me
is
the
kind
of
detail
that
shouldn't
be
debated
in
an
otec.
I
I
think
this
is
a
valid
question
like
what
should
we
name
it,
but
I
wish
we
could
merge
this
as
a
proposal
that
was
sort
of
completed
and
then
take
the
same
question
to
the
1899
pr,
because
I
want
more
reviewers
than
just
the
group
of
five
of
us
or
so
here.
B
Okay,
so
I
think
we
should
my
proposal
then,
for
this
topic
is
to
basically
copy
this
question
into
1899..
Okay,.
A
B
Okay,
so
that's
a
naming
question
we
know
naming
is
hard
and
always
contentious,
so
we'll
leave
this
behind
for
a
moment
and
then
why
is
this
not
doing
anything
is
github
broken
today.
B
Well,
anyway,
leave
that
I
will
try
to
press
that
button
later.
The
next
one
was
I'll
just
go
to
the
tab,
so
I
I
did
all
the
simple
edits
that
people
requested.
Oh,
why
is
this
resolved?
B
Oh,
I
accidentally
resolved
one.
So
I
made
up
this
idea
of
reject
because
I
I
thought
I
was
thinking
the
right
thing
and
you
you
made
a
proposal,
that's
sort
of
similar
but
different,
and
the
difference
comes
right
here,
I'm
okay
with
either,
but
I.
D
B
The
example
down
here,
but
this
formula
was
wrong
anyway,
wait
so
I
feel.
C
B
My
understanding
of
the
topic
is
that,
at
the
end,
if
you've,
if
you've
got
61
leading
zeros,
then
the
chance
of
having
62,
if
you
stop,
will
be
exactly
what
you
wrote
here,
which
means
the
adjusted
count
is
different
than
the
formula
would
say.
I
guess
which
is
okay,
but
it's
a
little
bit.
I
mean
we're.
Gonna
have.
C
There's
yes,
there's
one
one
mistake
I
have
to
think
about
it,
but
the
the
the
thing
is
that
you
do
not
need
this
rejection
mechanism.
So
basically
you
have
a
probability
distribution.
B
C
C
No,
not
this
one.
The
vistas
will
propose
the
same
yeah
exactly
this
one,
so
rejecting
meaning
that
you
repeat
this
right
and
so
zero
has
another
chance
to
get
selected
so
which
increases
the
probability
is.
B
I
think
you-
and
I
should
take
this
this
little
question
offline,
because
I
think,
okay,
your
solution,
I
think,
is
right
and
I
feel,
but
I
feel
like
I'm
like
in
my
head,
I'm
traveling
back
in
my
head
to
the
probabilistic
algorithms
class
that
I
took,
and
it's
been
so
helpful
to
me
in
my
career
but
like
in
the
simple
example,
is
if
you're
trying
to
choose
a
random
choice
out
of
three
and
you
have
all
you
have
is
a
fair
coin,
is
you're
gonna
you're
gonna
do
two
coin
flips
and
the
binary
value
will
be
zero
through
three
and
and
so
you
have
four
outcomes
and-
and
you
want
a
three
uniform
selection
you're
going
to
just
reject
one
of
the
one
out
of
four
and
repeat
the
experiment,
and
I
believe
that
that
gives
you
the
correct
probabilities.
B
C
C
If
this
decision
is,
is
true,
then
this
has
to
have
the
right
probability
and
if
you
do
it
with
this
rejection
thing,
then
the
probabilities
are
not
correct
because,
as
said
you're
repeating
and
the
the
value
r
is
not
chosen,
a
zero
is
not
chosen
with
a
probability
of
one
half
like
shown
in
this
example,
but
with
one
half
plus
something.
So
it's
it's.
It's
not
really
one
half,
okay,.
B
A
B
Paper
and
write
it
down
myself
because
I
feel
like
we're
so
close
and
and
this
detail
I
think
we
could
go
with
your
approach,
which
is
to
just
say
that
62
has
the
same
probability
as
61
or
whatever,
like
that,
that
solves
it
as
well,
but
just
a
different
special
case
if
it
so
now,
we've
talked
about
two,
I
want
to
say
fairly
minor
issues
that
are
related
to
naming,
which
is
never
easy
and
correctness
at
the
level
of
2
to
the
minus
63,
which
is
very
minor.
B
B
That
was
the
part
about
propagation,
and
I
think
this
is
the
one
that
has
a
lot
more
kind
of
contentiousness
still
in
it,
and
I
wanted
to
talk
about
some
things
that
are
maybe
not
openly
said
in
this
pr
or
maybe
not
kind
of
everyone's
on
the
same
page
about
for
this,
and
this
has
to
do
with
when
you're
not
sampled.
So
I
am
not
sampling
right
now.
B
B
But
this
was
a
scheme
where
we
were
not
using
consistent
sampling
decisions
in
a
world
where
you're
not
using
consistent
sampling
decisions
and
all
that
matters
is
your
head
probability.
Then
you
need
to
know
the
head
probability
when
you're
not
sampling
in
order
to
do
inflation
correctly
in
a
world
where
you
have
consistent
sampling
possibility.
B
This
is
sort
of
irrelevant.
You
don't
need
to
know
the
head
probability
when
you're,
not
sampled,
because
if
you're
going
to
change
that
decision,
you're
going
to
do
it
independently,
based
on
your
own
configured
sampling
rate,
so
I
don't
need
to
know
the
head.
If
I'm
on
the
sample,
I
can.
I
can
change
that
decision
and
set
my
own
probability,
and
I
doesn't
matter
what
the
parent
just
was
based.
What
the
negative
decision
of
the
parent
was
based
on.
B
I
think
everything
I
said
is
true,
and
it
sounds
like
an
opportunity
to
optimize
like
if
we
don't
sample,
then
we
don't
need
that
p
value.
However,
we
still
need
that
r
value
in
order
to
do
the
consistent
sampling.
Therefore,
the
only
potential
to
optimize
there
is
to
is
to
not
propagate
a
p
value
when
you're
unsampled.
B
This
sounds
like
a
source
of
complexity
that
I'd
like
to
kind
of
avoid
and
and
and
the
reason.
Why
is
that?
I
think
our
long-term
solution
should
hopefully
go
away
from
propagating
our
values
dedicated
in
a
dedicated
field.
I
would
like
us
to
move
towards
v1
of
w3c
which,
where
we
can
use
leading
leading
zeros
in
the
trace
id.
Hopefully
at
that
point
we
don't
have
an
r
value
needed,
and
at
that
point
it
will
become
a
useful
optimization
to
not
propagate
the
p
value.
B
The
reason
why
I'm
saying
it's
not
useful
now
is
if
we're
propagating
trace
state
with
an
r
value,
the
optimization
of
not
encoding
your
p
value
when
you're
unsampled
is
a
few
bytes,
whereas
because
you're
still
going
to
need
that
r
value.
B
So
I'm
I
want
to
openly
say:
there's
a
minor
optimization
here,
which
is
so
you
don't
need
a
probability
when
it's
zero
or
on
when
you're
unsampled,
I
I
didn't
say
zero
or
it's
unsampled,
but
it's
a
minor
optimization
and
it
just
leads
to
more
complications
in
the
future.
I
think
so.
That's
one
item
I
wanted
to
openly
like
air
any
comments.
B
That
wasn't
written
explicitly
in
this
text,
but
it's
been
on
my
mind
and
in
any
case
I'd
like
to
open
it
to
the
room
yuri.
I
see
her
unmuted.
Is
there
something
we
can
do
to
merge
this
or
is
there
more
to
discuss
or
is?
Are
there
should
we?
I
don't
know.
E
I
I
forgot
is
the
overall
propagation
of
randomness:
is
it
required
or
is
it
optional.
B
So,
in
my
opinion,
if
we
want
the
trace
id
ratio
based
sampler
to
do
what
it
was
originally
intended
to
do,
we
should
make
it
required
if
we
are
not
going
to
make
it
required.
B
My
my
employer
will
be
less
happy.
We
will
have
to
probably
create
like
a
new
type
of
sampler,
which
would
be
named,
I
think
probability,
and
it's
not
trace
id
ratio.
It
just
says
I'm
going
to
make
a
root
sampling
decision,
that's
probabilistic
and
I
will
not
propagate
my
r
value.
B
These
are
orthogonal.
If
you're
using
powers
of
two
probability,
you
could
still
propagate
a
p
without
an
r.
In
that
case,
I
was
hoping
that
we
didn't
go
that
way.
E
Well,
I
guess
what
I'm
asking
is
like:
if,
if
you
install
the
default
open,
telemetry
is
decay
right.
What
like
will
you
get
the
the
trace,
raise
trace
id
ratio
sampler
by
default
and
could
that
be
tied.
C
E
Requirements
to
propagate
our
value
versus
saying,
like
we
always
like,
because
you
may
be,
you
know
using
sampler,
which
is
different
right
like
or
like
classic
zipkin
style
sampler,
which
is
only
propagating
the
bit
and
not
counting
anything.
B
So
my
hope
was
that
the
four
built-in
samplers
specked
by
otel's
sdk
are
required
to
implement
the
the
features
in
this
pr
so
trace.
Eddy
ratio
would
always
set
p
and
r
parent
would
always
output
had
probability.
Therefore,
as
well.
If
the
entire
system
is
using
this
proposal,
then
every
every
node
every
span
will
know
its
adjusted
count.
B
And
that
in
in
the
longer
term,
when
we
can
adjust,
if
we
can
adjust
w3c
and
use
those
bits
and
even
extend
the
trace
parent
with
one
or
two
bytes
to
put
head
probability,
then
we
can
get
to
a
world
where
all
we're
doing
is
adding
three
bytes
to
the
the
trace
parent
and
the
the
always-on
behavior
will
be
costing
three
bytes
per
request
context,
and
I
think
that
that's
a
pretty
good
outcome.
B
I
got
some
that
was
last
week
and
I
didn't
realize
they
met
this
week.
I
heard
from
one
of
our
one
of
my
co-workers
that
it
was
discussed
again
this
week,
but
I
wasn't
present
this
week
now.
That
group
has
a
lot
of
dinotrace
influence
and
I
want
to
just
just
ask
mar
if
he
has
discussed
this
with
his
team.
C
B
When
I
discussed
it
in
the
group
a
week
and
a
half
ago,
initially,
there
was
a
sort
of
skeptical
like
position
from
one
of
the
engineers
there
who's,
not
someone
that
participates
in
hotel,
much
saying
who
really
cares
about
partial
chase
sampling,
and
it
was
sort
of
pointed
at
your
research
at
mar
and
saying
this
is
all
this
crazy
idea
that
we're
going
to
do
partial,
trace
sampling
and
I
I
hopefully
responded
correctly
and
saying
that?
No,
that's
not
what
we're
after
here.
B
That's
something
that
that
atmar
has
shown
us
how
to
do,
and
it
requires
having
a
fixed
number
of
probabilities.
But
all
we
want
to
do
here
on
light
step.
Side
is
count
spans
so
that
it
these
the
the
proposal
is
not
to
get
us
to
partial
trace
sampling.
It's
just
to
get.
B
B
C
B
The
history
here
is
that
dapper
had
probability
sampling,
it
had
inflationary
sampling,
it
had
propagated
probabilities
and
then
open
census
decided
after
years
of
experience,
watching
it
happening
inside
of
google
opencensus
decided
to
cut
that
out
and
and
to
move
towards
this
new
type
of
trace
ratio
sampler,
which
is
how
google
had
moved
in
the
intervening
years,
since
I
don't
know
2008
and
2016,
or
something
like
that,
so
that
the
the
proposal
for
open
census
was
get
beyond
what
had
been
done
in
the
past.
B
The
problem
that
we
I
think
ran
into
is
that
not
everyone
really
understood
that
the
mission
of
the
of
the
open
census
sampling
proposal-
and
it
was
really
tied
to
this
idea
that
you
know
when
your
choices
are
complete
in
my
opinion,
because-
and
you
had
this
count
of
your
children-
and
that
was
part
of
the
whole
solution-
is
that
you
can
count
your
children.
Therefore,
you
can
tell
if
a
trace
is
incomplete.
B
Therefore,
trace
id
ratio
will
work
for
you
and
then,
when
otel
came
along
and
tried
to
spec
it
out,
it
lost
that
it
was
just
a
root
tracer
and
we
lost
the
ability
to
count
children,
which
means
you
no
longer
have
ability
to
see
complete
traces.
And
so
here
we
are
trying
to
finish
the
sampling
project
and
we
have
a
defect
which
is
we
don't
know
how
many
children
there
are
and
people
have
sort
of
forgotten
what
we're
after.
I
think
this
ability
to
independently
control
sampling
rates.
B
And
so
in
some
sense
we
are
finishing
a
spec
that
has
never
really
been
deployed
in
the
world,
but
that's
just
because
all
the
other
examples
that
we
know
that
have
been
deployed
didn't
work
very
well,
and
this
one
seems
to
be
to
solve
most
of
those
problems.
I'm
talking
a
lot.
Someone
else
want
to
rescue
me.
C
I
mean
the
proposal
is
just
a
consequence
of
what
was
already
specified
right.
C
D
relationship
is
sample,
you
need
a
way
to
propagate
the
randomness,
the
common
randomness,
and
if
the
three
city
cannot
be
used,
we
have
to
introduce
something
else
right
and
the
other
thing
is
yeah.
We
also
want
to
extrapolate
or
count
or
estimate
the
number
of
cores
yeah.
C
So
I
mean
this
is
some
kind
of
natural
request
and-
and
you
can
only
do
that,
if
you
know
the
sampling
probability
and
therefore,
in
order
to
not
always
I
mean
for
for
for
parent
samplers,
you
can
also
yeah
compose
the
trace
and
then
you
figure
out
from
the
root
span.
But
this
is
not
visible
in
many
setups.
So.
B
And
but
that,
but
that
is
something
the
case
you
just
described,
which
is
where
there's
a
decision
at
the
root
and
then
the
parents
don't
know.
We've
covered
that
by
this
proposal
like
allowing
that
the
parents
can
write
unknown
and
the
root
could
not
write
unknown
and
then
a
system
when
it
assembles
a
trace
can
see
that
that
the
root
hasn't
known,
adjusted
count
and
the
children
don't,
and
therefore
we
can
do
something.
B
B
B
B
Essentially
it's
the
word
trace
state
plus
a
few
more
bytes
in
that
that
will
always
be
on,
and
that
will
all
the
four
built-in
samplers
will
produce
and
work
with
those
those
numbers
and
what
we're
doing
there
is
really
hoping
and
and
iterating
towards
a
future
where
it's
it's
a
a
new
trace
parent
that
can
do
the
same
for
three
bytes
instead
of
30
bytes.
B
But
I
think
that
hotel
has
to
show
that
it
wants
this
bad
enough
to
to
move
the
w3c
forward
and
so
doing
it
using
the
available
technologies
which
are
trace.
State
right
now
seems
like
the
right
solution
that
was
carved
out
by
the
w3c
for
us
to
do
this
sort
of
thing
and
the
fact
that
it's
expensive
is
just
a
thing
we
can
optimize
in
the
future.
E
Yeah.
This
is
why
I
was
asking
about
like
optionality.
If
we
could
design
it
in
such
a
way
that
only
people
who
are
willing
to
pay
the
cost
would
use
that.
B
Well,
we
can,
we
can
design
it
that
way
and
I'm
I've.
I've
already
stated
once
but
I'll
say
it
again.
It's
not
going
to
make
my
my
employer
super
happy,
because
that
means
that
anyone
who's
deploying
hotel
in
their
whole
system.
They
have
to
set
a
sample
option.
B
And
I
think
that
if
if
what
you're
saying
is,
is
you
you
don't
approve
until
until
we
see
more
evidence
that
everyone
wants
this
or
then
I
guess
the
next
step
would
be
to
explore
that.
But
I
I
I
don't
know
how
to
make
a
decision
like
this.
Are
we
being
I'm
worried
that
we're
being
sort
of
too
cautious
adding
an
option
might
mean
that
no
one
uses
this,
and
it
might
mean
that
lightsteps
sales
support
team
is
going
to
go
crazy,
telling
every
customer
to
set
some
option?
B
At
this
point,
I
think
I
need
to
think
a
bit
more
about
what's
possible
if
we
could
make
it
so
that
you
only
need
to
configure
your
routes
to
do
the
right
thing,
and
then
the
children
will
inherit
the
right
behavior
correctly.
That
might
actually
be
a
nice
compromise.
B
Opt
out,
okay,
all
right,
so
I'm
gonna,
I'm
just
gonna,
make
some
notes
here,
discussed
in
the
sampler,
the
sampling,
sick.
B
B
I
of
course
want
to
make
progress
and
I
can't
github's
not
working
I'll
click,
click
that
later.
Of
course,
I
want
to
make
progress,
but
these
are
fair
questions
for
us
to
be
evaluating
and
it
looks
like
we've.
People
are
bailing
out
of
the
meeting.
I
think
at
least
we've
finished
this
topic.
I
will
file
this
feedback
and
then
I'm
going
to
touch
1899
asking
the
hotel
group
to
please
consider.
B
I
will
try
to
call
out
this
question
about
cost
so
that
we
can
have
this
discussed
in
the
open
again.
I
still
wish
we
could
merge
my
otep
and
and
continue
discussing,
because
I
don't
like
leaving
things
open,
it's
hard
to
get
someone
to
reread
a
pr.
So
I
would
like
to
merge
this
and
and
and
treat
it
as
a
valid
proposal
that
was
accepted
as
a
valid
proposal,
so
that
we
can
keep
keep
sending
and
reviewing
new
documents,
but
it's
not
clear
that
that
will
happen.
B
In
any
case
should
we
discuss
new
topics
or
more
topics
batman.
I
know
that
you've
that
you
didn't
get
your
whole
wish
list
out
of
this
proposal.
There
was
something
about
when
you
are
skipping
spans
and
knowing
how
many
you
skipped
and
so
on,
like
you
can
see
how
hard
this
is
to
get
even
simple
things
done.
So
that's
one
reason
I
didn't
include
that
stuff.
B
Hoping
all
right,
so
I
have
like
essentially
three
notes
here
to
discuss
with
the
wider
group.
I
propose
that,
because
this
is
just
four
of
us-
that's
not
very
useful
to
discuss
it
in
this
group
and
I
will
propose
we
end
the
meeting
and
I
will
flood
1899
with
lots
of
information
following
this
meeting
hoping
to
drive
people
to
approve
this
otep
168,
merge,
170
and
then
figure
out
if
we
need
to
write
a
new
prototype
to
talk
about
opt-in
and
opt-out
and
so
on.