►
From YouTube: 2021-11-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).
B
A
C
A
Okay,
I
think
we
can
get
started
so
we
don't
have
any
agenda
added.
So
if
you
are
in
the
call,
please
add
your
name
to
the
list
so
due
to
lack
of
agenda
I'll
just
ask:
are
there
any
questions?
Otherwise
I'll
give
a
very
quick
update
on
what
we
intend
to
do
in
the
next
two
to
three
weeks.
A
A
So
we
know
like
1.2
is
plot
only
on
two
things:
the
net
has
to
release
which
we
expect
to
happen
on
time
and
then
the
spec
itself
should
be
marked
stable.
So
I
looked
at
the
specification
repo.
It
looks
like
they're
targeting
number
30
now,
so
we
won't
be
releasing
1.2
earlier
than
number
two,
that's
our
earliest
date.
So
if
spec
moves
again,
then
we'll
have
to
adjust
accordingly
and
we
have
issues
which
are
marked
as
required
for
ga
that
are
the
ones
which
will
block
the
release.
I
might
do
like
one
more
review.
A
Maybe
some
of
them
can
be
like
easily
closed
because
it
might
be
like
already
covered
elsewhere,
but
the
critical
things
are
the
ability
to
forget
the
memory
management
like
we
have
an
active
pr
for
ability
to
forget
metric
point,
and
we
have
two
features
from
metric
views
which
are
not
supported,
like
ability
to
add
new
dimensions.
A
On
the
fly
and
exemplars
so
I'll
check
with
this
tech
again
like
whether
we
might
be
able
to
do
1.2
without
supporting
any
of
them
or
is
it
like
an
absolute
must
so
I'll
figure
that
out,
because
if
we
can
still
do
1.2
without,
like
one
missing
feature,
we
might
be
able
to
do
a
better
job
of
like
doing
cleaning
up
all
the
other
stuff,
because
features
means
like
we
have
to
introduce
new
code
path.
A
So
yeah,
we'll
figure
out
like
like
by
end
of
this
week,
whether
it's
specifically
about
this
because
that's
the
biggest
missing
feature
we
have
let
it
open
the
ability
to
add
additional
dimensions
from
context
and
okay
missing
the
thing.
There's
a
separate
issue
open
for
exemplars,
interesting,
it's
missing.
So
that
means
I
had
to
create
one
or
I
created,
but
did
not
tag
it
with
metrics
yeah,
either
way
I'll,
create
those
issues
and
triage
accordingly
and
mark
it
as
required
for
ga
or
not.
A
So
when
I
use
the
word
g,
I
really
mean
1.2,
because
I
just
using
the
tag
from
the
tracing
release
yeah.
So
that's
pretty
much
it
from
the
update
thing
yeah.
We
have
this
issue:
okay,
let's
oh
okay!
This
is
wait.
This
is
from
the
spec
okay
yeah.
I
recollect
we
had
a
discussion
about
this
few
weeks
back
and
the
agreement
was.
I
would
go
and
open
an
issue,
but
instead
was
gonna
open
based
on
our
offline
discussion.
So
what
is
the
final
thing
here?
A
Did
we
okay,
so
we're
still
waiting
for
some
clarity?
I'm
surprised
that
no
other
language
just
picked
it
up
or
no
other
language
owners
commented.
So
maybe
we
can
ask
that
in
the
metrics
channel
as
well
to
see
if,
like
they
are
implicitly
assuming
that
you
can
have
duplicates-
or
they
are
already
doing
the
thing
as
per
the
respect
which
really
has
put
here
so
anything
to
be
discussed
like
today
here
or
just
need
to
wait
for
aspect
to
clarify
yeah.
B
So
riley
commented
out
on
it,
but
I'm
not
sure
because
I
still
think
there
is
a
problem
with
this
or
maybe
I'm
missing
something
but
yeah.
B
So
I
I
asked
because
there's
there's
two
colleagues:
you
might
think
that
they
often
often
join
the
metrics
sig
meeting
and
I
ask
them
to
bring
this
up
there
as
well
to
see
what
they
say:
okay
about
it
yeah,
but
I
just
wanted
to
to.
Maybe
if
you
guys
are
also
confused-
or
this
is
also
something
that
you
think
maybe
also
commenting
out.
So
maybe
people
see
that
there's
more
visibility
on
it:
okay,
yeah
so.
A
You
know
I
was
just
saying,
like
my
major
concern
or
like
only
concern,
was
I'm
not
fine
with
this
pegasus?
It's
just
that.
It
may
not
be
obvious
that
if
you
are
not
using
views,
you
have
to
do
this
behavior
so
yeah
this.
This
is
like
somewhat
hidden
inside
the
view
part.
So
my
only
suggestion
was
to
if
it
is
the
intention
just
like,
take
it
and
move
it
outside
of
the
view.
A
So
that's
my
feedback
so
I'll
put
that
in
the
like
spec
issue
itself,
so
that
it's
not
lost
anywhere
but
yeah.
If
others
have
like
concerns
or
like
any
alternate
proposals
or
editorial
changes,
go
ahead
and.
B
Propose
it
here,
I
tried
to.
I
tried
to
write
it
in
a
way
that
is
clear,
but
I
already
got
some
feedback
that
it's
too
long
and
and
people
might
not
read
it,
so
they
just
they
just
keep
it
in
like
because
it's
too
long.
B
But
I
was
afraid
that
if
I
didn't
get
too
much
information
much
information,
then
it
would
it
mix,
because
we
already
had
the
long
discussion
on
slack
and
we
keep
coming
back
to
the
view
part
which
I
I
don't
think
it's
I
mean
at
least
from
what
I
read
from
the
spec.
I
don't
think
that
makes
sense
if
you're
using
views
and
even
if
you're
using
views,
there's
a
also
a
conflicting
part,
which
I
I
explained
below
somewhere
in
this
in
this
long
text.
B
B
Is
that
like,
for
example,
if
I'm,
if
I'm
creating
my
my
my
application
in
net
and
then
I
use-
let's
say
I
don't
know
mongodb
package
or
some
other
package,
30
30
party
library,
and
what
riley
was
mentioning,
is
that
if
everybody
followed
the
semantic
conventions,
meaning
that
they
will
not
come
up
with
their
own
like
metric
names
and
so
on,
things
should
be
fine,
but
I
don't
think
it
should
be
fine,
because
this
is
exactly
a
problem
right.
B
So
if
everybody
follows
the
semantic
convention,
let's
say
they:
they
they
name
something
that
they
think
it's
a
request
count,
for
example,
and
there
is
already
a
semantic
convention
for
it,
so
how
to
name
it,
then
everybody
will
follow
the
semantic
convention
naming
the
instrument,
for
example,
request.count
and
then,
as
soon
as
I
import
import
all
these
libraries.
In
my
in
my
application,
I
configure
the
the
meter,
then
let
me
to
provide
them.
I
will
have
all
of
them
dropped
right
and
and
also
for
application.
B
B
So
I
I
think,
there's
there's
some
stuff
missing
there,
but
I'm
not
sure
if
views
are
are
really
like
the
way
to
go,
and
it's
it's
on
the
responsibility
of
the
application
owner
to
configure
it
then
yeah.
D
B
A
Yeah
totally
makes
sense
by
the
way.
There
is
no
way
library
owners
should
use
views
because
they
only
are
expected
to
take
a
dependency
on
the
api,
exactly
yeah
exactly
yeah.
That's
not
the
expectation.
The
expectation
is
that
whoever
is
constructing
the
actual
sdk
they
would
have
to
figure
out
what
to
do
with
the
conflict
so
but
yeah,
let's
see
if
spec
is
willing
to
clarify
it
any
further.
Also
there
is
no,
I
mean
you
might
already
release.
A
The
spec
has
already
reached
the
state
of
feature
free,
so
this
would
fall
under
like
editorial
changes,
so
it
should
be
able
to
still
edit
it,
but
like
just
an
fa
like
since
it
is
under
feature
phase,
no
new
request
for
features
are
added
until
we
reach
stable,
which
is
right.
Current
expectation
is
end
of
number,
so
any
new
feed.
But
this
doesn't
look
like
feature.
It's
just
editorial
change
and
it
it's
all
like
a
bug
fix,
so
it
should
be
doable
if
enough,
people
agree
and
comment
on
it.
A
Yeah,
that's
it
and
like,
as
I
mentioned
earlier,
like
once
we
get
the
I
mean
I
like,
I
haven't
even
gone
the
actual
task
of
like
deciding
like.
When
do
we
do
this
actual
releases,
so
it
really
depends
on.
When
are
we
going
to
do
the
feature,
so
it
has
to
be
like
at
least
a
week
before
the
final
stable
one,
because
that
will
give
us
enough
time
to
validate
everything
is
working
but
yeah.
That's
pretty
much!
All
me.
A
I
created
the
like
dates
along
with
these
milestones
and
I'll
work
with
other
medias
to
see
which
items
everyone
is
picking.
I
know
that
like
alani
is
already
working
on
something
and
riley
and
michael
are
doing
the
prometheus
exporter
issue,
and
then
I
am,
I
hit
the
view.
The
remaining
view
feature
is
assigned
to
me.
So
that's
the
good
question
is
going
to
help
with
some
sdk
features
as
well.
A
So
that's
a
known
thing
and
if
anyone
is
still
like
willing
to
offer
extra
hand,
please
look
at
the
actual
issues
which
are
like
marcus
liquid
for
ga
sorry
michael
mentioned
this
earlier,
like
we
still
need
instrumentation
library.
So
if
you
just
want
to
like
work
on
instrumentation
libraries
totally
go
for
it,
it's
just
that
it's
not
a
requirement
for
us
to
release
one
point:
1.2,
you
can
still
release
it
with
or
without
instrumentation
library.
So
it's
not
treated
here
as
I
required
for
g.
A
I
think,
but
it
is
still
treated
for
a
matrix
thing.
So
if
you
want
to
just
offer
some
help,
writing
instrumentation
libraries,
that
is
also
like
welcome
yeah
all
right.
I
think
we
don't
have
anything
else
in
the
agenda,
so
I'll
go
ahead
and
like
work
with
the
pr
owners
to
make
progress
on
the
sorry
in
our
repo,
the
pr's
which
are
pending
in
matrix
and
to
offer
the
rest
of
the
features.
B
I
just
have
a
quick
question:
yeah
for
the
instrument
for
the
for
the
instrumental
library
that
you
mentioned
in
matrix.
Do
we
have
an
issue
to
track
what
is
missing
or
yeah.
A
B
B
I
could
also
take
a
look,
but
I
will
take
a
look
at
the
require
for
ga
to
see
what
I
can.
A
Yeah
that's
the
priority,
but
the
only
challenge
is
it
may
be
like
it
may
not
be
possible
to
like
split
them.
So
people
can
work
independently
because,
like
I've
already
asked
like
like
just
wait
for
allen
because
it
might
be
like
it's
in
the
same
place
or
so
you
might
be
just
right,
but.
A
Yes-
and
there
is
this
one
has
someone
assigned,
but
there
is
instrumentation
for
sacred
line
which
could
be
again
like
this
would
all
be
like
experimental
change,
because
there
is
no
not
enough
semantic
conventions
defined,
but
we
could
still
do
that
or
oh
actually,
that's
a
good
point.
I
haven't
created
issues
for
other
instrumentation
libraries
yeah,
that's
on
me,
so
let
me
go
ahead
and
create
issues
for
other
instrumentation
like
this.
A
We
might
need
for
like
readys,
grpc
asp.net,
so
yeah
you
can
go
ahead
and
create,
but,
like
I
said
it
won't
be
like
a
top
priority,
so
we
can
always
have
it
after
we
do
the
1.2,
but
I'll
just
do
the
creations
in
case
people
want
to
work
independent
of
other
issues
more
than
happy
to
all
right,
yeah
I'll,
create
the
issue,
and
then,
if
you
want,
if
you
are
taking
anything,
just
comment
on
the
issue,
so
it
can
be
offended.
D
Hey
question
these
new
instrumentations:
will
they
be
their
own
assemblies
or
will
they
go
into
like
the
existing
sql
instrumentation
projects.
A
Yeah
so,
based
on
what
we
currently
done
like
it
would
be
the
same
packages.
So
if
you
have
a
open
elementary
elementary.instrumentation.sp.net,
it
would
contain
both
tracing
and
metrics.
Of
course
you
had
to
enable
it
separately,
but
it
would
be
a
same
package.
It's
a
different
extension
yep,
exactly.
A
Provider
cool,
I
think
we
already
covered
like
a
couple
of
maybe
like
the
instrumentation,
I
mean.
E
D
E
Client
instrumentation,
but
I
didn't
exhaustively
cover
the
those
are
the
semantic
conventions
that
are
most
flushed
out.
Right
now
are
the
http
conventions,
but
I
didn't
exhaust
fully
cover
them,
so
I
can
create
a
couple
of
follow
on
issues
there
to
take
on
that
work.
Yeah.
I
have
a
number
of
to
do's
and
in
these
things
so
yeah
it's
totally
fine,
because
we
can.
A
This
is
the
my
primary
goal
was
like.
If
you
have
like
some
instrumentations,
then
when
you
get
started
with
metrics,
you
already
see
like
something
flowing
without
you
creating
your
own
instrument.
So
that's
the
like
main
goal
of
having
some
instrumentations
along
with
1.2.
A
So
we
will
just
wait
for
that
to
happen,
but
yeah
we
should
still
do
like
some
instrumentations
to
make
it
easy
for
users
to
get
started
yeah
and
they
can
already
see
like
we
do
not
have
a
separate
package,
it's
meter
provider
extension
and
tracer
provider.
So
we
can
stick
with
that
for
now
and
if
there
is
a
reason
for
us
to
split
that,
then
we
can
come
back
and
discuss
it
later.
Since
we
have
never
released
a
stable,
we
should
still
be
able
to
afford
to
make
those
changes.