►
From YouTube: 2021-03-04 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
C
C
I
think
we
can
probably
get
started.
I
apologize
for
the
the
short
agenda
today.
I
didn't
have
as
much
time
this
morning
to
prepare
for
this,
as
I
normally
like
to.
C
Screen,
okay,
so
from
my
perspective,
the
only
thing
that
I
have
to
talk
about
is
the
the
api
release
candidate.
I
I've
been
sort
of
copying
the
timeline
as
we
go
week
to
week
and
crossing
off
things
that
are
done,
but
the
api
tasks
are
are
essentially
all
completed.
C
C
One
thing
that
I
wanted
to
talk
to
the
group
about
particularly
bart
and
valentine
is:
do
we
want
to
release
a
package
1.0.0
dash,
rc1
version
as
our
release
candidate,
or
should
we
just
label
the
existing
0.18
package
as
our
release
candidate,
the
advantage
to
using
the
0.18
as
a
release
candidate
is
that
it
may
provide
some
more
upgrade
safety
for
users.
If
we
have
breaking
changes,
they
won't
automatically
be
upgraded.
C
If
we
release
the
1.0.0
rc1
package,
I
believe
npm
will
automatically
update
them
to
1.0
when
we
release
it.
So
if
there
are
any
breaking
changes,
they
would
automatically
get
those
braking
changes
which
may
not
be
desirable,
but
on
the
other
hand,
in
order
to
install
a
pre-release
package
with
like
the
dash
rc1
tag
on
npm,
you
need
to
do
that
explicitly
anyways.
So
maybe
that's
not
so
much
of
a
problem.
C
C
B
C
I
have
volume
now,
okay,
I
can
hear
you
so
I
apologize
for
that.
Okay,
my
head.
I
think
the
wrong
speaker
selected.
A
C
Yeah,
so
we
need
to
release
the
rc.
The
the
question
I
was
asking
is:
how
do
we
specifically
want
to
do
that?
So?
Do
we
want
to
release
a
new
rc
version?
That's
1.0.0-rc1,
or
something
like
that.
Or
do
we
want
to
just
say
the
version
we
have
0.18
is
the
release
candidate
and
put
it
on
the
readme
that
this
is
our
release
candidate
and
things
like
that.
A
C
Okay,
so
I
can
prepare
that
today
it
should
be
easy
to
do
because
there
have
been
no
code
changes.
She'll.
C
I
prefer
1.0
rc,
I
think
more
explicit
about
what
we're
trying
to
do
and
less
confusing
for
people,
because
we've.
C
Dot
something
for
a
long
time,
so
people
following
the
project
that
don't
join
these
meetings
and
don't
necessarily
check
the
readme
may
not
know
that
anything
is
really
different.
But
if
we
release
a
1.0
rc
version,
I
think
that
that's
more
clear
what
we're
actually
trying
to.
A
A
C
A
C
Other
than
that
aaron,
I
see
you
added
a
question
about
peer
dependencies
down
here.
You
want
to
elaborate
on
that.
B
Yeah,
it
looks
like
you
actually
opened
this
issue,
but
so
I've
noticed
a
lot
of
times.
Users
will
have
mismatched
versions,
because
right
now
I
think
the
dependencies
for
like
context
and
things
are
just
specified
as
dependencies,
so
npm
will
try
to
resolve
them
by
installing
multiple
versions
and
then
users
sometimes
end
up
with
mismatched
like
context
versions
and
more
than
one
like
context,
instance
or
con
or
like
various
globals.
B
C
Yeah,
I
think
you're
right.
This
is
something
I
opened
this
issue
in
january
to
sort
of
placehold
it
for
myself
and
I
was
going
to
tackle
it
when
we
started
after
the
api
release
candidate
when
we
started
looking
closer
at
the
sdk,
but
I
believe
you're
right.
I
think
the
sdk
when
it
depends
on
the
api,
should
probably
use
the
api
as
a
peer
dependency,
not
as
a
regular
dependency
and
then
when.
C
Instrumentations
depend
on
it
depend
on
the
sdk.
I
believe
it
should
also
be
a
peer
dependency,
and
that
way
npm
will
ensure
that
everybody
has
the
correct
version
and
that
you
know,
if
you
have
the
tracing
package
installed
on
your
end
user
application.
If
you
have
tracing
17
and
some
instrumentation
uses
tracing
15,
then
it
will
log
to
the
user
that
they're
using
in
compatible
versions,
rather
than
just
installing
both
versions
and
having
them
fail
when
they
try
to
interact
with
each
other.
B
Right
yeah,
I
think
you
brought
up
a
good
point
in
there
that
npm
won't
actually
install
peer
dependencies
and
I
think
with
npm.
Seven,
that's
changed
so
it
will
install
peer
dependencies
automatically
for
you.
So
if
so,
if
the
user
puts
like
a
specific
exporter
or
something,
it
should
automatically
install
the
api
and
sdk
versions
that
they
need,
and
then
I
think,
with
more
recent
versions
of
npm
7,
it
will
complain
if
you
have
mismatched
peer
dependencies
that
can't
be
resolved
correctly.
B
C
Okay,
that's
good
to
know:
do
you
have
a
link
to
that?
Is
that
open
source
so
that
I
did
you
mind,
dropping
it
into
the
document.
C
B
Yeah,
so
I
think,
with
the
most
recent
version
of
npm,
it
will
actually
complain
so
like
if
you
installed
this
exporter
and
you
tried
to
install
telemetry
0.18,
it
should
complain
that
it
can't
satisfy
the
peer
dependencies
and
but
it
wasn't
quite
working
right
with
like
the
initial
release
of
mpm7,
but
I
think
that
is
sort
of
like
their
goal.
Overall.
C
B
So
I
don't,
I
think,
that's
because,
like
I
was
mentioning,
I
don't,
I
might
be
able
to
remove
it.
Actually,
that's
a
good
point,
I'll,
try
that
and
see
see
if
I
can
still
if
it
will
install
those
dependencies
just
for
development
as.
B
Yeah,
in
that
case
it
might,
it
might
just
work
it
might
be
from
before,
because
I
npm
7
just
came
out
as
I
had
this
mark
just
pure
even
before
npm
7
was
like
generally
available,
but
since
then
these
might
be
obsolete.
Now
it's
a
good
point.
C
Yeah,
that's
but
you'll
you'll
still
need
it.
So
I
was
just
wrong,
but
for
that
particular
one
it
shouldn't
matter
whether
you
have
the
peer
defendancy
or.
B
C
The
the
biggest
issue
with
asking
people
to
use
the
apis
of
your
dependency
is
that
packages
that
build
in
support
for
the
api
will
not.
We
won't
be
able
to
ask
them
to
do
that,
so
the
the
sdk
dependencies
for
like
the
the
tracing
and
s
pen
core
packages.
C
I
think
we
can
tell
our
users
to
use
those
as
peer
dependencies
but
the
api
package
we
can't
so
in
the
api
package,
we
have
a
different
workaround
where
we
register
globals
in
order
to
get
around
that
to
ensure
we're
only
using
one
api
package.
But
it's
worth
noting
that
the
the
api
package
doesn't
work
the
same
way
as
the
spk
packages
do.
C
Yeah
exactly
so
that
a
library
that
that
builds
in
open
telemetry
can
has
the
option,
I
guess
to
mark
us
as
a
peer
dependency
if
they
want
to,
but
it
should
also
work
if
they
mark
us
as
a
regular
dependency.
C
C
That's
all
I
really
have
on
the
agenda
for
today
is
an
update
on
the
the
rc
timeline.
C
So
I
guess
I
will
prepare
an
rc
for
the
api
today
and
once
that's
released
I'll
update
the
core
repository
to
point
to
that,
instead
of
pointing
to
the
0.18
version,
so
hopefully,
by
the
end
of
the
week
we
should
be.
You
know
the
the
latest
version
of
all
three
reba
should
be
pointing
at
the
release
candidate
for
the
api,
and
we
can
focus
more
on
the
sdk
release
candidate.
C
No
I've
been
spending
a
lot
more
time
on
the
api
recently,
so
the
sdk
has
kind
of
not
been
in
the
forefront
of
my
mind
in
recent
weeks,
but
I
know
the
plugins
is
a
major
part.
Those
all
need
to
be
migrated
instrumentations
and
most
of
that
work
is
done
now,
there's
only
a
few
left,
but
I'm
sure
there
will
be
other
things
like
this
peer
dependencies
issue
that
comes
up
so
the
sdk
rc
I
expect,
will
probably
follow
a
week
or
two
behind
the
api
rc.
C
C
I
think
they
also
want
us
to
have
you
know
the
release
candidate
out
for.
C
C
Time
is
that
okay,
or
are
you
blocked
on
something
okay?
C
That
was
all
I
had
for
today.
I
know
short
meeting
again,
but
does
anyone
have
any
other
questions
that
they
want
to
bring
up.
A
Okay-
and
I
guess
one
thing-
we
still
have
forgotten
about
this
meta
package-
for
the
plugins
and
instrumentations.
C
The
so
the
you're
talking
about
like
the
auto
installation
of
the
packages.
A
Yeah
something
we
could
consider
the
the
sooner
we
talk
about
this
one.
I
mean
the
better:
it's
basically
how
we
want
to
present
this
and
include
this
in
the
register.
Instrumentation
there
all
differently,
because
after
we
remove
the
plugins,
we
won't
have
the
auto
instrumentation
for
nothing
except
you
have
to
provide
each
plugin
one
by
one.
C
Yeah,
so
I
I
think
we
have
two
possibilities
for
that.
We
could,
we
could
add
the
instrumentations
as
an
optional
peer
dependency
on
the
node
and
web
packages,
or
we
could
do
it.
The
other
way
around
where
we
have
the
meta
packages,
export
some
register
function
or
something
like
that.
A
C
Yeah,
I
think
that's
a
totally
acceptable
solution,
at
least
to
begin
with.
I
know
that
the
specification
has
talked
about.
They
want
to
have
sort
of
a
unified
strategy
for
instrumentations,
and
I
know
that
ted
has
started
some
work
on
that.
C
So
I
don't
know
if
we
should
wait
for
them
or
not.
I
don't
know
if,
like
the
auto
loading
mechanisms,
are
something
that
they
want
to
specify,
but
I
think
most
of
the
languages
already
have
their
own
auto
loading
mechanisms.
C
C
Yeah,
I
I
think
that's
a
great
idea.
Is
there
an
issue
open
for
that.
C
Does
anybody
have
any
objections
to
releasing
the
the
api
release
candidate?
Is
there
anything
that
I'm
not?
Thinking
of
that?
Now
is
the
time
to
speak
up,
if
you
think
something
needs
to
be
changed
for
the.
C
Rc,
okay,
then,
I
will
assume
that
the
current
state
is
okay
and
we'll
move
forward,
yeah,
so
bart
you're
going
to
create
a
draft
for
the
the
meta
packages
yeah.
C
I
know
that
the
mongodb
instrumentation
pr
is
already
open.
You
already
took
care
of
the
happy
one
you're
still
working
on
koa
right.
A
A
You
cannot
convert
it
because
it's
not
the
plugin,
it's
not
the
instrumentation,
it's
just
a
class
which
extends
from
the
react
yeah.
So
there's
nothing
to
do
with
either
plugging
an
instrumentation
effect.
C
C
A
C
C
Okay,
then,
I
will
talk
to
you
all
next
week.
Hopefully
we'll
have
a
draft
of
the
medic
packages
by
them
to
talk
about
also.