►
From YouTube: 2021-12-22 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
B
A
This
week,
but
but
in
general
you
know
people
are
going
home
and
back
home
and
visiting
their
friends
and
not
doing
the
same.
C
I
think
we
can
probably
get
started.
I
think
valentine's
not
going
to
join
us
today.
So
hello
to
everybody,
I
thought
I
saw
someone
new
on
the
call,
but
it
looks
like
they
dropped
off.
We
scared
them
away
with
our
video.
C
Sounds
good,
okay!
First,
you
all
obviously
probably
know
this,
but
it's
a
holiday
week
so
likely
a
slow
week
in
changes
and
things
like
that
across
all
of
open,
telemetry,
js
included.
But
just
be
aware
of
that,
I
did
release
the
1.0.4
api
this
morning.
C
No
real
substantive
changes
there
other
than
a
bug
fix,
but
what
it
does
mean
is
that
there
are
a
handful
of
changes
that
we
were
waiting
to
make
because
we
want
them
to
go
into
1.1
and
we
wanted
to
make
this
release
before
we
did
that.
C
So
there
will
be
a
small
handful
of
changes
to
the
api
in
the
coming
couple
of
weeks
and
if
you
are
thinking
if
you've
been
thinking
of
any
features
that
you
would
like
to
be
added
into
the
api
as
a
minor
update.
C
Now
is
the
time
to
bring
that
up,
because
I'd
like
to
make
one
make
a
single
1.1
release
for
for
these
features,
rather
than
doing
a
new
release
for
each
feature,
so
bundle
them
together
a
little
bit-
and
I
hope
to
you
know-
do
that
in
the
next
couple
of
weeks.
Here.
C
You
know
rules
in
there,
but
I
sort
of
view
it
as
a
a
living
document
that,
as
we
have
questions
or
as
we
resolve
questions,
we
will
add
those
to
that
guide
so
that
hopefully,
people
who
are
on
boarding
in
the
future
won't
have
the
same
questions
over
and
over.
There
are
a
few
things
like
using
two
equals
when
we're
checking
for
null,
and
some
things
like
that
that
we
constantly
rehash
over
and
over
so
nice
to
have
those
things
documented.
C
A
lot
of
them
are
already
in
the
linting
rules.
Anyways.
You
know
there
is
going
to
be
some
overlap,
but
there's
also
some
things
that
are
not
easy
to
automatically
check
with
wanting
roles.
So
I
I
view
it
as
a
start,
but
just
be
aware
that
it's
there.
B
We
want
to
include
the
style
guides
for
instrumentations
as
well
in
this
document,
or
is
it
general
javascript
instrumentations
has
a
lot
of
undocumented
conventions
that
are
common
across
all
the
different
packages.
B
And
how
to
patch
things
and
how
to
call
functions
which
are
patched
and
stuff
like
that.
C
Some
of
those
things
I
mean
they
definitely
should
be
documented,
but
I
think
that
that
is
a
separate
document,
because
that's
more
of
like
a
developer
guide
to
creating
instrumentations.
C
One
thing
that
also
yeah
and
then
we'll
talk
about
it
in
january,
but
I
would
like
to
move
the
the
instrumentations
that
are
in
the
core
repo
into
the
contrib
repo
and
then
rename
that
to
be
the
instrumentation
or
something
like
that.
But
we
can
talk
about
that
later.
That's
a
not
a
fully
formed
thought
at
all,
but
yes,
I
do
believe
that
we
should
have
that
developer
guide
and
I
think
it
should
be
in
the
contributor.
C
The
auto
instrumentation
span
status
here
I
responded
to
this
once
I
saw
that
rano
also
did.
This
is
sort
of
a
general
question
about
this
is
specifically
about
https,
but
my
I
wanted
to
talk
more
generally
about
all
of
the
instrumentations
when
we
have
a
request
that
and
the
span
status
is
not
set
by
the
auto
instrumentation.
C
This
is
true
of
all
of
the
auto
instrumentations,
and
that
is
essentially
what
rono
mentioned
on
the
ticket
here,
but
I
just
wanted
to
be
sure
that
we're
all
on
the
same
page,
that
that
is
that's
what
we
want
and
that
that's
what
the
spec
requires
before
I
close
this
issue.
B
C
So
it
is
stated
that
way
it's
so.
It
says
that
the
the
span
status
is
unset
unless
the
application
developer
sets
it
specifically
as
okay,
I'm
not
saying
that
we
should
set
them
as
okay,
I'm
wondering
if
we
should
expose
a
way
for
the
application
developers
to
mark
them
as
okay,
because.
C
I
guess
that's
that's
a
very
complicated
question,
maybe
that's
something
that
we
should
bring
up
in
the
instrumentation
sig
or
or
in
the
specification
just
to
clarify
that,
because
I
would
argue
that
the
auto
instrumentation
in
most
cases
does
know
enough
to
to
market
as
failed
or
succeeded
in
most
cases
or
success
yeah.
I
agree.
D
D
C
Yeah
and
there's
some
instrumentations
where
certainly
they
know
that
it
succeeded.
Database
ones
are
other
very
obvious
ones
in
the
spec.
I
believe
that
they
just
wanted
to
make
sure
that
unset
was
the
default
in
the
sdk.
I
think
that
that
was
more
more
along
the
lines
of
the
sdk
itself
should
never,
you
know,
make
any
value
judgments
on
the
success
or
failure
of
a
spam,
but
the
instrumentation
is
a
little
bit
different.
It's
probably
something
that
we
should
bring
up
in
the
instrumentation.
C
Does
anyone
here
regularly
attend
that,
if
not
then
I'll
reach
out
to
them
on
slack?
I
guess
so
I
I
won't
close
this
yet
until
we
have
a
an
answer
there.
Damn.
B
B
C
Actually,
don't
use
the
span
status
field
at
all
and
we
calculate
our
own
definition
of
of
success
or
failure
based
on
the
attributes.
Most
of
the
time.
A
I
feel
like
I,
I
have
heard
the
discussion,
so
it
has
confused
me
as
well,
leaving
it
on
set
and
most
of
the
time,
but
then
I
heard
a
discussion
why
it's
useful,
of
course,
I've
long
forgotten
how
it
went,
but
but
at
that
point
I
do
remember
myself
resulting
to
okay
yeah.
That
makes
sense,
so
I
will
now
leave
it
on
set
in
in
the
future
instrumentations
I'm
implementing.
A
C
Yeah
I
mean
there's
several
reasons:
there's
there's
the
obvious
answer
of.
There
are
plenty
of
people
who
don't
use
http
status
codes
correctly
and
just
return
200
for
everything,
whether
it's
a
success
or
not,
and
things
like
that
and
then
there's
also.
C
It
was
nothing
there
was
no
network
failure
or
anything
like
that,
or
you
could
argue
that
it
was
a
failure,
because
you
made
a
bad
request
and
it
was
a
failure,
and
I
think
that
only
the
application
developer,
who
makes
the
call
or
or
you
know,
has
read
the
documentation
and
things
like
that-
can
really
know
what
anything
means
and
the
the
interpretation
doesn't
have
enough
context.
C
Okay,
there
is
a
pr
open,
it
was
a
draft
yesterday,
but
now
I
guess
it's
not
a
draft
anymore
for
the
metric
reader
and
the
metrograder
interface.
It's
not
a
huge
pr,
but
it's
not
small
either
and
it's
the
next
important
part
of
the
the
metrics
sdk.
C
Prolific
in
the
metrics
these
days,
so
I'm
not
100
sure
what
he's
working
on
at
the
moment,
but
he's
probably
cooking
something
up.
If
I
had
to
guess
but
yeah,
please
review
that
pr.
If
you
have
time.
C
I
don't
know
if
anyone
has
noticed,
but
our
documentation
is
actually
pretty
out
of
date
or
was
until
this
morning
the
auto
generated
docks
in
the
api
repo
and
the
sdk
repo
were
failing
to
update
so
that
the
github
actions
workflow
was
failing
because
of
a
combination
of
issues,
type
doc,
updated
and
the
the
options
have
changed,
but
also
the
cncf
has
applied
a
set
of
branch
protection
rules
that
were
not
there
when
the
workflows
were
created.
C
So
the
word
flow
was
not
able
to
push
to
the
the
git
repo
either.
So
I'm
working
on
on
getting
this
fixed
and
getting
the
exemptions
that
we
need
from
the
cncf
in
order
to
get
exemptions
to
advance
the
branch
protection
rules.
But
that's
all
just
taking
time.
I
did
manually
update
those
things
or
update
the
documentation
this
morning,
so
it
is
up
to
date
for
the
most
recently
released
packages,
but
just
so
that
people
know
right
now.
This
is
a
manual
step,
but
I
am
looking
into
it.
C
This
next
entry
is
is
fairly
obvious,
most
or
all
of
you
already
know
that
bart
stepped
down
as
a
maintainer,
and
we
just
haven't
done
the
cleanup
in
the
repositories
to
remove
them
from
the
lists
and
things
like
that.
So
that's
what
these
prs
are.
I
did
also
remove
him
from
the
maintainers
github
team
or
whatever
it's
called.
C
He
is
still
an
approver
and
he
is
still
a
little
bit
active.
I've
actually
seen
him
making
some
comments
on
prs
and
stuff
like
that
over
the
last
couple
of
weeks,
but
he
is
no
longer
a
maintainer,
so
we
are
removing
him
from
those
lists.
G
I
did
okay,
sorry,
I
should
have
put
my
name
on
it.
Yeah,
I'm
just
relaying
and
ask
really.
A
co-worker
of
mine
has
been
doing
a
lot
of
docs
updates
for
this
main,
like
doc
site,
and
he
mentioned
that
he
hasn't
been
getting
a
lot
of
js
approvers
to
like
stamp
the
js
prs,
and
I
guess
they
ask
is
do.
G
Does
this
group
want
to
approve
them
like
I'm,
not
sure
how
they
you
all
usually
engage
with
docs
like
they've,
been
merging
them
because
I
think
there's
just
a
docs
approver
that
looks
at
it
make
sure
it's
good,
but
I'm
sure
they
would
prefer
someone
from
this
group
to
kind
of
give
a
final
thumbs
up
that
this
is.
The
changes
are
good.
C
Yeah.
Okay,
of
course,
I
I
agree
that
we
are
definitely
the
correct
people
to
do
that.
I
think
we
have
the
most
context
and
things
like
that.
A
lot
of
the
docs
in
that
repo.
I
had
the
same
issue
with.
I
wrote
a
lot
of
those
to
begin
with,
and
it's
just
hard
people
have
a
million
different
things
they're
looking
at
and
it's
another.
That's.
G
C
I
would
say
definitely
at
any
time
they
could
add
links
into
this
document
and
just
so
that
we're
aware
that
they're
there
that's
the
easiest
way
to
make
us
all
aware.
Obviously
you
can
also
tag
the
javascript
approvers
team.
I.
C
Oh,
I
see
it
here
yeah,
so
I
probably
did
get
a
notification
for
this.
I
just
I
can't
check
now
because
I
actually
just
cleared
out
my
notifications,
but
I
have
to
say
I
get
I
don't
know,
but
I
get
like
300
a
day,
so
it's
really
really
hard
for
me
to
pay
attention
to
all
of
them.
C
Sure
I
don't
have
a
lot
of.
I
have
some
some
rules
in
my
email
that
that
bubble
up
the
important
ones
but
the
documentation
repo,
is
not
in
that
list.
For
yes,
though-
and
I
probably
should
add-
mentions
to
that
one-
so
that's
a
good
call
out
there,
because
I
definitely
don't
remember
seeing
that
in
my
email
but
yeah
that
adding
links
to
this
doc
is
definitely
the
best
way
to
get
my
attention.
C
I
would
say
anything
in
this
documentation
I
am
up,
or
in
this
doc
I
am
a
hundred
percent
likely
to
see
anything
on
slack.
I
am
eighty
percent
likely
to
see,
and
in
my
doc
in
my
notifications,
it's
50
yeah,
so
I
suppose,
depending
on
on
the
level
of
involvement,
that
they
are
trying
to
get
from
us
that
that's
my
general,
like
I
expect
most
people
in
this
call
probably
feel
similarly.
G
G
A
C
Yeah-
and
I
was
I
was
not
added
as
a
reviewer
on
this,
so
I
do
have
like
a
a
filter
that
I
regularly
check.
That's
prs,
that
are
that
need
reviews
from
me,
and
this
obviously
would
not
have
shown
up
on
yeah.
G
G
Okay,
that's
good,
it's
good
to
know,
and
I
think
maybe
it's
somewhat
related,
but
to
to
the
point
of
calling
bart
from
maintainers
are
all
of
the
js
approvers
actually
active,
js
approvers,
because
I
think
it
might
look
like
oh
there's
like
20
of
them
and
nobody's
looking
at
this.
It
might
be
like
an
optics
thing
too,
because
I'm
like
no
they're
actually
really
busy.
C
Yeah,
so
I
can
probably
we
should
probably
go
through
that
because
I
guarantee
you
there
are.
C
Members,
so
bart
is
still
an
approver,
but
if
he
is
not
active,
you
know
we'll
remove
him.
Matt
ware
definitely
still
does
come
around.
Sometimes
oliver
I
haven't
seen
in
a
really
long
time.
We
could
probably
remove
him.
C
John
is
active
in
other
parts
of
open
telemetry,
but
not
as
much
in
js.
So
I
can
reach
out
to
him
to
ask
him
mark.
I
have
not
seen
in
a
while
mark.
D
Left
yeah,
he
was
on
my
team.
He
yeah
he
left
a
long
time
ago.
So
when
I
became
active,
it
was
because
mark
had
left.
I
backfilled
his
position.
C
Okay,
so
I
would
say,
mark
and
mayor,
we
can
definitely
remove
john
and
oliver.
We
can
most
likely
remove
and
I
will
reach
out
to
matt
to
see
if
he
wants
to
continue
to
be
an
approver
on
the
js
repo
he's
not
super
active
in
js,
but
he
does
come
around
every
now
and
then
other
than
that
I
mean
the
list
is
mostly
up
to
date.
Here.
G
C
Do
you
think
it
was
that
sufficiently
addressed
them
to
win?
Oh.
E
I
I
added
that
I
opened
up
this
vr
some
time
back.
One
of
the
outstanding
comments
is
about
the
collection
reset
and
josh
updated
the
spec
part
of
that.
It's
mostly
an
in
internal
implementation
part
whether
or
not
we
want
to
reset
it.
There
is
a
wire
I
was
going
to
ask
like
if
anyone
else
has
followed
that-
and
you
know
any
like
my.
What
I
was
thinking
is
to
you
know,
update
this
to
rename
it
to
only
color
and
then
to
make
it.
E
C
I'm
having
a
hard
time
hearing
you
do
you
mind,
do
you
mind
repeating
that?
I'm
sorry.
Can
you
hear
me
now
clearly
yeah
just
what
what
was
the
the
the
takeaway?
What
was
you
you
said
your
your
plan
is
to
do
what.
E
To
make
this
only
a
color
and
the
reset
is
an
implementation
detail.
Internal
implementation,
detail
that
we
don't
want
to.
You
know,
make
it
public.
C
Yeah,
I
believe
we
do
not
want
to
expose
reset,
so
I
I
would
say
that
that
is
in
implementation,
detail
and
that
as
long
as
it's
not
exposed
on
the
api-
and
you
know,
if
I
don't
know
if
you
want
to
make
it
even
a
private
method
depending,
I
can't
remember
the
exact
implementation
right
now
that
that's
fine.
E
C
Yeah,
so
I
think
that
is
just
a,
I
think,
that's
a
bug
in
the
spec.
I
think
that
somebody
only
copied
a
part
of
that
implementation
and
I
would
say
that
we
should
probably
use
the
use
the
full
implementation
that
I
linked
here
from
wikipedia,
because
if
we
don't,
then
you
end
up
with.
C
So
the
the
point
of
of
the
of
the
sampling
algorithm
is
to
have
you
have
a
certain
number
of
buckets
that
fill
up
right
away,
and
then
you
replace
some
of
those
buckets
and
the
more
buckets
you
have,
the
more
likely
they
are
to
be
replaced.
But
then,
once
you
have
a
lot
of
exemplars,
it
becomes
less
and
less
likely
that
they
replace
previous
buckets.
C
And
if
you
implement
it
in
the
way
that
the
specification
suggests,
then
you
actually
end
up
with
not
all
of
the
buckets
full
or
at
least
no
guarantee
that
they'll
all
be
full
and
you
could
potentially
have
many
fewer
exemplars
than
you
would
expect
using
the
same
like
list
in
memory.
E
Right,
no,
that's
kind
of
starting
off
with
the
random
random
buckets
doesn't
make
sense
once
once
you
get
it
filled,
then
then
randomizing
makes
sense,
I'll
I'll,
update
that
and
we'll
see.
If
we
they
just
still
continue
to
keep
the
same
algorithm,
we'll
we'll
change
it.
Otherwise,
we'll
go
ahead.
The
wikipedia.
C
I
I
would
implement
what
what
we
believe
to
be
the
correct
algorithm
and
if
they
do
comment
on
that
issue
or
or
update
the
spec,
to
make
it
clear
that,
for
some
reason
we're
supposed
to
use
what
I
think
is
the
wrong
one.
Then
we
can
always
go
back
on
that,
but
I
think
for
now
we
should
do
what
we
what
we
think
to
be
correct.
C
Okay,
all
right,
I
will
still
be
here
next
week.
I
am
working
the
week
between
christmas
and
new
year.
Yay,
I
don't
know
who
else
is
working,
but
I
don't
expect
it
to
be
a
very
long
meeting
I'll
join
just
to
see
if
anyone
has
questions,
but
I
probably
will
not
plan
on
talking
about
anything
too
important.
C
Okay,
thank
you,
everybody
for
your
time.
I
appreciate
it
and
for
those
that
I
don't
see,
have
a
good
rest
of
your
year
and
I'll
see
you
later.