►
From YouTube: 2021-05-03 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
B
A
All
right,
let's
get
started
so
welcome
everybody
to
the
weekly
maintainers
call
as
usual,
we're
going
to
start
with
a
sig
check-in,
starting
with
the
specifications.
Do
we
have
anyone
from
the
spec,
sig
or
tc?
Who
wants
to
talk
about
this.
A
Okay,
we'll
keep
going.
I
don't
see
anything
for
php,
so
java
planning
to
release
1.2
later
this
week
with
minor
improvements
and
bug
fixes.
Thank
you.
Do
we
have
any
updates
for
job
instrumentation.
A
A
D
Mean
it's
pretty
self-explanatory.
The
issue
has
had
quite
a
bit
of
conversation
on
that
pr
over
the
course
of
the
last
week.
It's
something
that
people
probably
remember
from
the
spec
call
last
week.
That
was
where
it
initially
came
up
and
it
seems
to
have
been
more
contentious
than
I
had
anticipated.
I
thought
it
would
be.
You
know
a
quote
easy
change,
but
it
doesn't
seem
to
have
not
everybody
agrees.
D
I
guess,
but
I
did
want
to
mention
that,
like
this
has
already
been
implemented
not
only
by
javascript
but
by
ruby
and
python,
and
I
don't
there
might
be
others
also.
D
E
I
think
I
can
I
I
think
I
have
more.
I
have
some
context
sure
in
that
I
mean
I
think
there
is
a
general
issue
that
that
people
don't
think
that
this
is
something
that
actually
belongs
at
the
instrument
that
the
instrumentation
is
not
what
should
be
directing
this,
and
if
we
have
to
add
this
to
the
api
that
is
essentially
saying
this
is
something
this
is
an
instrumentation
concern
and
I
believe,
there's
a
fairly
strong
opinion
that
this
should
not
be
an
instrumentation
concern.
E
A
E
G
F
A
G
A
Great,
it's
like
cutting
the
monthly
release
this
week,
cool
all
right,
so
that
takes
us
to
javascript.
Otherwise,
three
remaining
api
issues
from
the
spec
review,
including
the
above
and
five
remaining
sdk
issues.
Three
aprs
daniel
sounds
like
we're
pretty
close.
A
A
I
I
was
wondering
nah,
we
said
next
week.
You
guys
are
doing.
A
A
A
Dot
net:
nothing
significant
to
report
study
metrics
work
this
week,
cool,
go
working
towards
release
candidate
three
remaining
items:
to
do:
that's
minus
eight
wow
three
down
from
six
in
progress
280
with
13
recently
done
that
is
getting
pretty
close
as
well:
fantastic
yep,
chugging
along
nice
thanks
doug
c
plus
last
week,
integration
of
baggage
resource
instrumentation
libraries,
1.0
rc,
milestone,
is
planned
for
may
end.
Excellent,
19,
open
issues.
21
closed,
ask
still
looking
for
c
plus
developers.
I
E
So
far
we
haven't
been
doing
that
exactly,
but
we
have.
I
have
been
calling
out
in
the
release
notes
when
we've
been
doing
updates
that
are
related
to
this
by
specification
release,
so,
for
example,
when
the
the,
when
there
are
updates
to
the
semantic
conventions
I
put
in
the
release,
notes
that
we've
updated
our
spanking
conventions
for
this
release,
et
cetera,
there
hasn't
been
any
effort
right
so
far
to
say
this
release
is
strictly
compliant
to
spec
version.
Xyz,
though,.
I
A
All
right,
thanks
riley,
any
updates
for
ruby
or
swift.
A
G
Yep,
so
I
was
dealing
with
writing
down
my
proposal
about
how
we
can
solve
the
problem
of
of
maintainers
bottlenecking
that
seek
maintainer,
don't
have
capacity
to
review
all
pull
requests
for
instrumentation
yeah.
We
talked
about
this
last
last
few
weeks,
yeah
yeah.
So
now
I
have
the
first
draft
of
my
proposal,
which
I
think
covers
the
majority
of
topics.
G
J
G
F
G
A
G
G
G
J
J
No,
I
don't
think
so,
based
on
my
understanding,
no
because
it
still
has
a
name,
a
version
like
the
instrumentation,
it's
just
more
or
less
some
specs
terminology
and
proto
message,
name
which
will
be
backwards
compatible.
So.
A
G
D
B
J
I
see
so
I
mean
we
can
have
solutions
if
you
already
open
did
use
instrumentation
library,
we
don't
break
the
api
and
we
just
say
this
is
equivalent
of
telemetry
source
and
that's
it.
I
think.
J
Let's
re
recapturing,
this,
I
think,
is
more
or
less
the
confusion.
More
is
on
the
collector,
where
where
people
did
not
seem
to
understand
that,
in
case
of
as
an
example
in
case
of
a
scraper
from
for
metrics
from
redis
that
is
actually
equivalent
with
this
instrumentation
library.
In
my
opinion,
or
maybe
I'm
wrong,
maybe
correct
me
if
I'm
wrong,
but
for
me
if
redis
exposes
metrics
on
slash,
ready,
slash,
debug
or
whatever
is
the
end
point,
and
you
are
scraping
that
that's
actually
an
instrumentation
library.
J
Okay,
I
I'm
open
to
that,
but
conceptually
do
you
think
the
example
that
I
give
you
matches
to
the
instrumentation
library.
J
Okay,
so
besides
the
name
change,
should
we
at
least
clarify
that
this
should
describe
the
telemetry
source
or
or
or
it
can
describe
the
telemetry
source
in
this
case,.
D
Yeah,
I
think
what
you're
saying
is
because
the
telemetry
is
not
coming
from
a
library
right,
it's
coming
from
something
else.
I
I
think
yes,
it
can
be
used.
The
name
is
unfortunate.
You
know,
like
I
said
I
think
telemetry
source
is
a
better
name,
and
if
we
were
still
very
early
in
the
process,
I
would
say
go
for
it,
but
this
late-
I
just
I
think,
might
be
too
late
for
you.
J
Okay,
I'm
fine,
I'm
fine
to
not
changing
it,
the
name
but.
G
G
J
But
what's
the
difference,
for
example
when,
when
you
record
metrics
for
grpc,
when
you
write
a
grpc
interceptor
that
records
metrics
and
the
metric,
for
example,
is
using
the
async
version.
So
let's
assume
grpc
has
a
queue
and
you
are
exposing
that
q
as
a
metric.
But
the
queue
is
already
the
queue
size
is
already
calculated
by
grpc.
G
But
you
can,
you
can
have
different
instrumentation
libraries,
which
assign
different
labels
to
to
that
metric.
I
can
have
elementary
source
in
your
example,
sounds
to
me,
like
instrumented
library,
not
instrumentation
library,
so.
J
It's
already
redis
exposes
on
the
debug.
Not
it
does
not
expose
otlp.
It
exposes
some
numbers
saying
number
of
requests
completed
whatever
so
does
not
expose
otlp.
It
exposes
some
numbers
in
those
numbers.
J
G
C
Yeah,
I
see
the
nikita's
point
also
that
source
is
confusing
of.
Is
it
like
the
root
source
right,
there's
kind
of
layers
of
where
it's
coming
from
and
source
kind
of
sounds
like
the
root
source.
G
J
We
all
agree
that
we
should
use
the
same
message
or
the
same
thing
to
describe
both
these
scenarios.
The
name
may
not
be
telemetry
source
forget
about
the
name.
The
name
was
me
trying
to
be
too
clever.
Probably
I
failed,
but
but
my
biggest
problem
is
the
fact
that
in
the
collective
right
now
we
do
not
annotate
all
these
metrics
with
the
instrumentation
library.
J
J
Okay,
okay,
I
will
again,
this
was
just
a
idea.
I
will
follow
up
with
the
maybe
an
issue
or
something
to
clarify
that
the
proposal
of
the
instrumentation
library
should
be
used
in
the
case
of
of
a
redis
receiver
or
host
metrics
receiver
or
whatever
component,
that
gets
data
and
produces
data
in
okay.
E
We
exposed
a
public,
a
public
member
variable
in
the
zip
code
exporter
that
we
didn't
intend
to
that
would
have
been
found
during
the
pr
process.
If
I
mean
obviously
it
was
in
the
pr,
but
it
would
have
been
something
that
was
highlighted
a
little
more
clearly
if
we
had
had
something
like
this
in
place,
so
we
just
wanted
to
call
that
out.
Let
people
know
that
this
is.
This
is
something
that
could
be
really
useful.
E
A
H
H
Not
yeah,
I
would
have
to
be
done
with
the
module
level
as
just
the
getting
the
makefile
to
to
work
around,
invoking
it
properly
for
each
module
and
figuring
out
where
the
module
route
is
for
each
package.
As
the
the
thing
I
haven't
worked
through
yet,
okay.