►
From YouTube: 2022-05-11 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
Okay,
can
you
see
it?
I'm
actually
sharing
the
right
one,
this
time
right,
yep,
yep,
okay,
all
right!
Well!
The
first
first
topic
here
is
the
various
community
topics.
B
The
first
is
that
I'm
sure
everyone
here
is
aware,
but
kubecon
is
next
week
I
will
be
attending,
I'm
not
sure
who
else
from
here
will
be
attending.
I
think
amir
said
he
would-
and
I
think,
there's
probably
some
others
for
those
that
don't
know
there
is
a
community
meeting
at
kubecon
on
tuesday.
B
B
I
guess
we'll
move
on
I'll
I'll.
Add
it
to
the
doc
when
I
find
it
later,
I
just
don't
have
it
immediately
and
then
we
also
have
the
community
day
on
june
20th.
The
workshop
submissions
are
officially
closed,
so
I
will
remove
that
for
now
again
I'll
be
there
and
I
hope
to
see
as
many
people
as
possible
there.
I
will
not
be
there
for
the
for
the
community
meeting
the
tuesday
of
kubecon,
because
I'm
not
flying
in
early
enough,
but
a
lot
of
other
people
will.
B
Okay,
there
are
two
metrics
issues
that
I
wanted
to
talk
about.
The
first
is
that
the
prometheus
exporter
needs
to
be
updated
to
reflect
the
latest
spec
changes.
B
There
are
a
handful
of
small
issues
like
the
prometheus
exporter,
does
not
currently
support
resources
and
there's
some
name
changes
and
things
like
that.
Supporting
the
unit
feature,
I
guess
for
now.
This
issue
has
been
assigned
to
legendas,
but
he's
been
working
on
other
things,
so
if
people
are
looking
for
things
to
do,
this
would
be
a
great
place
to
start.
B
There
are
some
other
issues
in
here.
I
guess
I
will
mark
these
as
up
for
grabs.
B
B
Okay
and
then
there
is
a
new
issue
for
moving
the
sampler
sampler
to
the
sdk
package.
There
was
an
api
issue
for
this
before.
B
B
This
is
something
that
I
am
generally
supportive
of.
I
don't
think
it's
super
important
or
high.
B
C
C
We've
been
working
on
a
prototype
for
collecting
events
as
using
the
log
signal,
and
part
of
that
is,
is
exporter
the
exporter.
So
I
might,
I
might
start
working
on
that,
but
I
want
to
see
like
if
there's
any
plan
in
this
group
to
work
on
that
in
near
future.
B
Yeah
so,
as
far
as
I'm
aware,
nobody
has
started
working
on
this.
Yet
at
all.
I
think
the
the
sentiment
has
always
been,
let's
finish,
metrics
and
then
logs
will
be
next,
so
it's
always
been
kind
of
just
something
that
we're
going
to
do,
but
no
one
has
started
working
on.
If
you're
you
know,
if
you're
willing
to
work
on
it,
then
that's
great.
It
is
some,
certainly
something
that
will
need
to
be
done,
but
I
don't
think
there's
been
any
log
sdk
work
at
all
in
javascript.
B
B
Probably
very
soon
I
would
say
there's
a
couple
of
small
metrics
issues:
left
we
don't
support
exemplars,
we
don't
support
batch
callbacks.
You
know
multi-instrument
callbacks
I
mean
and
there's
obviously
some
like
documentation
an
example
work
to
do
and
stuff
like
that.
B
But
beyond
that,
I
think
logs
is
going
to
be
sort
of
the
next
major
push
and
because
metrics
is
such
a
complex
topic.
There's
really
only
a
couple
of
people
that
that
do
a
lot
of
the
metrics
work
anyways.
So
I
think
there
are
probably
free
hands
for
for
working
on
logs
or
if
there
aren't
now,
then
there
will
be
in
the
very
near
future.
B
Okay,
a
couple
of
weeks:
okay,
the
for
those
that
don't
know
at
kuncon,
open
telemetry,
will
be
announcing
like
sort
of
a
project-wide
metrics
availability
announcement.
B
B
If
anyone
does
know
of
anything
that
would
prevent
us
from
from
being
a
part
of
that
announcement,
please
let
me
know
so
that
we
can
hopefully
address
it
this
week,
if
possible,
but
yeah
that's
the
plan
and
then
once
once
that's
done,
it's
really
just
metrics
cleanup
and
then
logs
will
be
the
next
thing
I
believe
logs
and
like
developer
experience
are
probably
our
next
two
areas
of
focus,
because
right
now
setting
up
the
sdk
and
the
instrumentations
and
stuff
is
also
kind
of
frustrating
for
new
users.
B
I
don't
have
any
other
topics.
As
usual,
we
have
the
list
of
prs,
both
old
and
new,
that
need
to
be
reviewed.
Svetlana.
You
had
last
week
a
question
about
the
otlp
traces
exporter
variable,
but
we
decided
to
move
it
to
this
week.
Do
you
want
to
ask
your
question
now.
D
B
D
What
were
the
issues,
but
I
do
have
a
different
question.
I
guess
about
the
prs
waiting
for
review
the
one
about
the
timeout.
I
saw
your
your
two
comments
about
it
today
and
I
guess
the
first
question
is
you
asked
why
I
used
request
aborted
for
one
set
of
note
versions
and
request
destroy
on
another,
and
I
guess
the
reason
I
did
that
was
because
request
dot.
Abort
was
deprecated
in
version
14.
So
I
not
too
sure
if
we're
okay
using
a
deprecated
method,.
B
Yeah,
I
would
prefer
not
to
use
a
deprecated
method.
Are
you
so
it
was
deprecated
in
14.
Is
what
you're
saying?
And
yes,
yes,
okay,
I
was
just
saying,
can
you
can
you
add
a
comment
in
the
code
that
explains
that
just
say,
abort
was
deprecated
in
version
14,
and
that
would
be
good
enough.
D
Okay,
perfect
and
then
the
other
thing.
Your
question
was
why
we
didn't
add
time
out
to
the
beacon
cent
beacon.
D
C
B
Okay,
yeah,
that's
a
good
enough
answer
for
me.
I
guess
I
know
that
beacon
is,
is
mostly
used
for
like
making
sure
that
things
still
send
when
you
close
the
page
and
stuff
like
that.
So
I
know
it's
a
fairly
restricted
api,
so
it
doesn't
surprise
me
that
much
that
there's
no
way
to
do
it.
D
All
right
I'll
just
make
that
comment
after
the
call
and
the
pr
should
be
good
if
anyone
else
wants
to
look
at
it.
Yeah,
okay,.
B
I
do
yeah,
I
think,
is
from
my
perspective
that
one's
essentially
ready
to
merge
when
it
gets
a
couple
of
reviews.
The
other
one
that's
ready
to
merge
is
this
null
ports
at
options.
Actually,
the
tests
are
failing
right
now,
because
I
made
a
change
in
the
github
web
editor
that
I
thought
was
a
quick
change,
but
I
broke
the
broke
the
build,
so
I
have
to
fix
that,
but
I'm
going
to
merge
this
one
also,
but
everything
below
that
is
definitely
a
neither
of
reviews.
B
B
Okay,
I
guess
let's
just
cancel
next
week's
meeting.
I
think
most
of
the
segment
will
probably
do
the
same.
So
I
don't
think
it's
too
much
of
a
problem.
A
Just
a
really
quick
question
out
of
curiosity:
I'm
not
sure
if
I've
missed
it
is
there
like
a
minimum
number
of
approvals.
We
look
for
on
a
pr
before
we
think
it's
okay
to
merge,
because
I
think
there's
ones
that
maybe
I
haven't
said
hey.
I
approve
on
this
because
I
didn't
know
if
it
was
necessary,
but
if
that's
something
that
we
seek
say
two
or
three
or
something
of
community
members
to
approve
it,
I
can
try
to
be
more
diligent
on
on
doing
so.
B
Yeah,
so
generally
we
try
to
do.
I
I
mean
it
depends
on
the.
I
think
it
is
documented
somewhere
hold
on.
Let
me
I
think
it's
in
the
contributing.
B
B
Yeah
merge
requirements,
so
we
have
three
approvals,
including
the
approvals
of
at
least
two
maintainers.
In
practice,
we
actually
tend
to
not
necessarily
require
two
maintainers.
If
there's
three
or
four
reviews,
then
one
maintainer
is
fine,
at
least
for
changes
that
aren't
really
big.
B
We
don't
follow
these
very
strictly,
but
I
would
say,
in
general,
more
reviews
is
always
better.
So
if
there's
a
pr
that
only
has
two
reviews
or
three
reviews,
it
may
just
be
waiting.
If
it's
a
you
know
a
moderately
big
change.
Sometimes
we
just
wait
for
a
couple,
more
reviews
or
just.
D
B
Sure
that
nobody
has
an
objection
if
it's
changing
an
api
or
something
like
that,
so
the
more
approvals
we
get
even
from
people
who
are
not
officially
on
the
approvers
list
definitely
helps
us
to
see
that
okay.
This
is
something
that
people
feel
generally
good
about
and
approve
the
idea
and
stuff
like
that.
But
probably
we
should
get
better
about
adhering
more
strictly
to
the
merge
requirements.
B
I
think
rano's
not
here
today,
but
he
typically
merges
most
of
the
pr's
in
the
contrib
repo,
and
I
think
he
does
it
here
more
strictly
to
the
policy,
but
it's
a
a
lower
bar
in
contrib.
I
think
there's
only
two
approvals
and
only
one
of
them
needs
to
be
maintained.
So
I
think
that's
a
a
smaller.
B
Or
an
easier
bar
to
cross,
but
in
the
main
repo.
I
think
we
should
just
get
better
about
following
the
actual
requirements,
but
I
guess
to
answer
the
spirit
of
the
question.
It
is
always
helpful
to
have
more
reviews
on
any
pr,
but
if
you're
trying
to
figure
out
where
to
spend
your
time,
if
something
already
has
two
or
three
approvals,
then
if
you
only
have
so
much
time
to
spend,
then
maybe
look
for
one.
That
only
has
you
know
zero
or
one
or
two.
B
Okay,
I
guess
that's
it
for
today.
Anyone
else
have
a
question
before
we
drop.
B
Okay,
well
for
those
of
you
who
will
be
in
valencia,
you
can
reach
out
to
me
on
slack
if
you
want
to
meet
up
I'd
love
to
meet
people
in
person,
if
possible,
and
if
not,
I
will
talk
to
you
in
two
weeks.