►
From YouTube: 2021-12-01 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
Yeah,
I
guess
the
links
will
change
somewhat
often.
So
that's
why,
in
the
specification
meeting,
for
example,
they
don't
put
the
link
directly
in
the
dock
anymore,
because
the
link
is
gonna
change
somewhat
often
and
a
little
bit
unpredictably
so
going
through
the
calendar.
I
guess
is
the
best
way
to
do
it
now.
A
I
I
clicked
on
the
one
there
was
in
the
dock.
There
was
a
there
was
a
meeting
link
and
I
clicked
on
that,
and
it
said,
like
the
meeting
is
starting
in
300
hours
and
I
was
pretty
sure
that
that
wasn't
right
so.
A
No,
so
it's
different
per
se,
but
they
might
actually
change
every
time.
The
calendar
I
guess
gets
modified.
The
links
are
all
regenerated.
A
I'm
not
entirely
sure
morgan
mclean
was
the
one
that
set
it
up.
So
if
you're
interested
maybe
reach
out
to
him
and
ask
him
but
okay,
I
guess
going
through
the
calendars.
That
is
the
easy
way
to
to
avoid
the
problem.
A
So,
first
of
all,
there's
a
slow
week
due
to
the
us
holiday.
I
know
not.
Everybody
here
is
in
the
us,
but
a
lot
of
people
are
so
there
wasn't
that
much
going
on
last
week.
A
But
one
thing
that
did
happen
is
there
were
some
versioning
issues
in
the
contrib
repository
because
we
updated
the
metrics
api
and
the
instrumentation
class
allows
you
to.
A
Configure
a
metrics
provider
or
a
meter
provider,
the
version
27
of
the
instrumentation
class
was
not
compatible
with
version
26
of
the
instrumentation
class.
A
So
anyone
that
used
the
version,
26
or
version
27
sdk,
couldn't
use
any
instrumentations
that
hadn't
been
updated
yet
which
was
most
of
them,
and
anybody
that
was
using
the
version.
26
sdk
couldn't
use
version,
27
implement
instrumentations,
which
was
only
a
couple,
but
it
meant
that
the
auto
instrumentation
node
and
the
auto
instrumentation
web
meta
packages
couldn't
be
used
because
they
depend
on
all
of
the
instrumentations,
and
some
of
the
instrumentations
were
on
version
26
and
some
were
on
version
27..
A
So
at
the
beginning
of
this
week
I
updated
all
of
the
instrumentations
to
point
to
version
27
of
the
instrumentation
class,
but
we
want
to
probably
talk
about
how
we
want
to
avoid
this
problem
in
the
future,
because
it
could
come
back
up
for
now.
It's
unlikely
to
come
back
up
for
at
least
the
short
term,
because
the
api,
the
trace
api,
is
stable
and
we're
preventing
the
metrics
api
from
being
released
until
it
stabilizes
a
little
bit.
So
maybe
for
the
next
month
or
so,
but
after
that
it
might
happen
again.
A
So
we
need
to
talk
about
how
to
keep
all
of
the
instrumentations
using
a
consistent
version
of
the
instrumentation
class,
at
least
until
the
metrics
api
is
declared
stable,
because.
A
A
So
I
don't
there's
trade-offs
to
both.
One
potential
solution
is
to
just
try
to
update
all
of
the
contrib
modules
as
quickly
as
possible
to
the
latest
instrumentation
class,
but
if
we
forget
to
do
it
or
if
there's
a
breaking
change,
that
requires
some
work,
it
could
potentially
result
in
the
same
issue
again.
A
You
want
to
have
any
thoughts
on
this,
or
was
anyone.
B
A
B
I
I
do
have
a
question
just
to
kind
of
clarify
is:
is
the
issue
that
there
was
a
breaking
change
to
the
instrumentation
class,
not
that
there
was
different
versions
or
when
different
versions
without
a
breaking
change,
caused
the
same
problem.
A
It's
just
because
there
was
a
breaking
change,
but
in
this
case
the
definition
of
breaking
is
really
really
loose,
because
if
a
new
method
is
added
to
either
the
metrics
api
or
the
trace
api,
that's
considered
breaking
in
this
case,
because
the
actually
no
it
wouldn't
be.
So
if
there's
a
breaking
change
to
the
metrics
api,
then
there's
a
breaking
change
to
the
instrumentation
class
so
because
we
were
iterating
the
metrics
api
and
making
breaking
changes
that
that's
why
it
happened
so
once
the
metrics
api
is
stable,
that
likely
won't
happen
again.
A
B
A
Yes,
so
at
the
very
least,
we
need
to
make
sure
that
when
we
update
the
meta
packages,
all
of
the
instrumentations
for
each
released
version
of
the
meta
packages
need
to
be
on
compatible
versions
of
the
instrumentation
class,
not
necessarily
the
exact
same
version,
but
at
least
compatible
versions.
A
B
Yeah,
it
sounds
like
I
don't
know.
One
possibly
pragmatic
way
to
just
work
through
this
is
to
recognize
when
the
interface
is
changing
in
in
the
instrumentation
class
and
just
make
sure
that
we're
we're
aware
that
that
this
this
will
have
an
impact
on
on
the
existing
instrumentation
kind
of
go
from
there.
A
Yeah
I
mean
once
the
the
metrics
api
is
stable.
It
shouldn't
be
as
much
of
a
problem.
We
probably
shouldn't
have
unstable
apis
as
part
of
the
instrumentation
class,
so,
for
instance,
it's
it's
too
late
for
metrics.
Obviously,
and
I
don't
want
to
remove
it
now
that
it's
there,
but
once
we
have
like
a
logs
api,
maybe
we
don't
add
it
to
the
instrumentation
class
until
it's
stable
just
to
prevent
this
from
happening
in
the
future.
A
I
guess
for
now,
since
the
metrics
api
won't
be
released,
at
least
for
the
near
future,
we
can
probably
move
on
from
this,
but
yeah.
I
I
think
that
the
solution
that
matt
suggested
or
just
be
more
careful
while
not
an
easy
thing
to
automate
is
probably
the
most
pragmatic
solution
at
this
point.
I
don't
know
if
I
want
to
invest
a
bunch
of
time
and
automating
a
solution
first
for
a
problem
that
will
go
away
in
a
couple
of
months.
B
Yeah,
I
think
that
sounds
good
and
I
think
ultimately,
like
there
was
this
that
version
and
stability
document
a
long
time
ago.
I
think
one
one
of
the
things
that
it
mentioned
was
that
a
stable
api
should
not
reference
an
unstable
api.
So
I
think
I
think
this
is.
A
A
I
guess
we
can
move
on
from
that.
I
did
update
all
of
the
instrumentations
to
the
latest,
instrumentation
based
class,
that's
been
merged
and
now
there's
a
release
ready.
So
I
would
appreciate
it
if
a
couple
of
people
could
take
a
look
at
that
just
to
make
sure
that
nothing
is
obviously
missing
from
it
and
I'll
probably
merge
that
today
and
release
that
today.
A
There
are
a
few
metrics
pr's
that
are
open.
Each
of
them
is
a
pretty
significant
pr,
they're,
not
easy
to
review
and
in
order
to
review
them,
it
probably
requires
a
fair
understanding
of
the
specification.
A
I
was
talking
to
legendas
about
that
this
morning
and
he
said
that
he
is
going
to
try
to
create
a
design
doc
similar
to
the
one
that
aaron
linked
from
python
to
describe
how
the
current
js
sdk
is,
is
working
and
what
the
plan
is
moving
forward,
which
should
help
with
reviews
of
those
prs,
but
that
he
just
started
working
on
that
this
morning
and
right
now,
it's
one
in
the
morning
where
he
lives,
so
he'll
probably
hopefully
have
that
by
the
end
of
the
week,
but
definitely
not
today,
aaron
abbott
asks.
A
A
C
No,
no,
I
guess
my
point
is
the
specs.
Is
that
there's
no
api
for
logs
there's
just
an
sdk,
so
you
essentially
use
whatever
idiomatic
logging
api.
There
is,
I'm
not
sure
if,
if
javascript
has
has
an
idiomatic
one
you
would
want
to
use,
but
there's
not
like
a
open,
telemetry
logs
api.
That's
specified.
A
A
A
Yeah
yeah
got
it
yeah.
So
I
I
guess
I
said
my
piece
about
the
design
doc.
I
don't
have
much
to
say
about
it
until
we
actually
have
a
document,
but
I
know
that
we
read
through
errands
together
and
the
the
python
document
and
that
helped
us
clarify
a
lot
of
our
thinking
on
the
aggregation
pr.
A
So
I
think
he's
planning
on
updating
the
pr
based
on
our
discussions
tomorrow,
but
that
a
design
doc
should
be
coming
in
which
should
help
with
those
reviews.
A
There's
also
an
exemplars
pr,
which
I
haven't
had
time
to
look
at
yet,
but
I
know
is
a
fairly
big
pr
and
there's
a
metric
streams,
which
is
a
draft
because
it
depends
on
the
aggregation
support
so
right
now.
I
think
that
the
two
prs
that
are
helpful
to
review
are
the
aggregation
and
the
exemplars,
particularly
the
aggregation
one,
because
I
think
it's
a
little
bit
further
along,
although
I
could
be
wrong,
there's
obviously
also
open
to
do
tasks
in
the
the
metrics
sdk
project.
A
Rono
is
running
on
the
call
it
looks
like
no.
I
was
just
gonna
ask
him
if
he's
ready
to
to
bring
this
pr
out
of
draft,
but
I
guess
I'll
reach
out
to
him
on
slack.
A
I
guess
I
do
quickly
want
to
mention
svetlana
from
new
relic
reached
out
to
me
earlier
looking
for
something
to
do,
and
I
believe
she's
going
to
be
working
on
like
examples
and
documentation
and
stuff
like
that.
A
A
Okay,
I
guess
I
will
give
everybody
their
time
back
and
thanks
for
joining
me.