►
From YouTube: 2021-06-16 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
B
I
created
the
api
release
after
the
meeting
last
week.
I'm
sure
most
of
you
have
seen
it
by
now,
but
we
did
release
the
version
1.0
and
the
world
does
not
appear
to
have
ended.
So
that's
good.
B
I
did
see
that
there
was
a
possible
issue
related
to
a
circular
dependency,
but
for
whatever
reason
it
only
seems
to
be
affecting
certain
people.
I,
like
the
azure
sdk
people
were
the
ones
that
brought
it
up
initially,
but
it
doesn't
appear
to
be
affecting
anyone
or
everyone,
but
it
is
a
real
issue,
so
I
did
did
create
a
pr
for
that.
So
I
would
appreciate
it
if
people
would
review
it.
Let
me
put
it
into
the
document
here.
B
It
has
been
around
for
a
while.
So
I'm
not
sure
why
we
just
caught
it
but
yeah.
Let's
get
this
merged
and
we'll
release
1.0.1
once
we're
done
along
the
same
lines,
we
have
the
version
0.22
release
proposal
for
the
core.
This
uses
the
api
version
one
I
can
see.
Some
people
have
already
reviewed
it,
but
I
would
appreciate
the
more
eyes,
the
better
and
hopefully
release
that
this
afternoon
and
then
do
contrib
as
soon
as
we
can.
After.
B
B
So
when
they
go
to
use
the
source
maps,
it
doesn't
map
back
to
the
ts
file.
It's
not
something
that
I
was
actually
aware
of.
I
thought
you
didn't
need
the
original
source
code
to
use
source
maps,
but
I
don't
know
if
it's
a
bug
with
the
loader
that
they're
using
is
anyone
else
more
familiar
with
this
issue
or
have
any
idea
how
we
can
fix
it
without
publishing
the
ts
files.
C
Sorry
I
came
in
a
bit
late,
so
I
missed
the
context,
but
in
source
maps
you
can
tell
it
to
embed
the
source
code
in
the
map
file
itself.
B
Yeah
that
so
that's
what
I
thought
typescript
did
by
default.
Do
you
know
if
that's
a
flag,
we
need
to
enable
in
the
ts,
config.
C
Yes,
it
is
a
flag,
inline
source
map.
I
think
it's
called.
B
I
will
oh
yeah
there
you
go.
B
So
I
will
open
a
pr
for
that
at
least
see
how
much
bigger
it
makes
the
package,
because
I
think
it
probably
will
make
it
a
little
bit
bigger.
B
Okay,
the
next
issue
is
es
module
interrupt.
This
user
opened
an
issue
just
saying:
why
are
we
using
on
low
dash
dot,
merge
and
mixing
it
with
imports?
B
B
It
doesn't
seem
like
they're
necessarily
having
a
problem,
except
that
they
do
mention
that
roll-up
causes
errors.
I
guess
I
have
two
questions.
One
has
anyone
successfully
used
roll-up
and
is
there
a
config
that
that
they
can
use
to
get
this
working
or
two?
Yes?
And
yes,.
C
Used
it
like
yes,
yeah,
so
the
intern
I've
got
working
at
the
moment
if
we
are
using
roll
up
and
we
found
a
flag
that
perfect,
because
we
hit
this
exact
same
issue
as
well,
but
we've
now
got
through
it
as
of
two
days
ago.
So
what
was.
B
C
Can
comment
on
this
one?
Was
it
two
two
seven
nine
I'm
gonna
have
to
go
hunt
for
it
because
it
was
it's
on
the
interns
machine
who's
also
over
on
the
east
coast
with
you
so.
B
Yeah,
that's
fine.
Can
you
just
comment
on
this
issue
when
you
find
it.
C
B
Okay
and
then
do
you
think
that
that
flag
is
the
correct
way
to
solve
this,
or
do
you
think
we
should
enable
yes
module
internet?
B
C
Yeah,
it
causes
the
module
to
get
dragged
in,
so
it
does
bloat
the
size
of
the
thing.
B
B
B
That
was
more
or
less
why
we
didn't
do
it
in
the
first
place
like
I
said
it
was
easy
to
just
you
require,
I
guess
when
you
find
the
the
flag
that
you
used
for
roll
up.
What
can
you
comment
on
this
issue
and
if
that,
if
that
solves
the
problem,
then
that's
good
enough
for
now.
I
really
don't
want
to
enable
something
that
changes
module,
load
behavior
unless
we
have
to.
B
Okay,
next
issue
here
is
performance
concerns
for
the
collector
auto
shutdown,
something
to
do
with
an
event
listener.
On
the
unload
event,
now
I
admit
to
not
being
a
browser
expert,
so
I
don't
really
understand
why
this
would
have
a
performance
concern
other
than
maybe
it
just
gets
fired
a
lot.
B
Does
anyone
else
have
more
context
on
this
issue?
Now
again,
it
looks
like
you
commented
on
this,
and
there
was
a
related
issue
also
where
we
talked
about
the
unload
event
for
the
the
force
flushing.
C
Yeah,
so
I
I've
done
a
lot
with
the
unload
event
yeah
effectively.
C
I'm
not
quite
sure
what
the
performance
issue
is,
but
in
terms
of
the
unload
event,
we
should
definitely
not
shut
down
the
sdk,
because,
just
because
we've
handled
the
unload
it
doesn't
mean
someone
hasn't
hooked.
The
unload
events,
because
there's
several
of
them
after
us
and
still
want
to
send
out
some
some
data.
C
B
C
Yeah,
we
should
just
go
into
a
force,
flush
mode.
It's
really
what
we
should
do
and
only
shut
down
when
people
tell
us
to
shut
down.
B
Yeah,
okay,
I'm
going
to
assign
this
to
bart,
even
though
he's
not
here,
but
he
wrote
this
code
in
the
first
place.
B
B
Unload
and
then
the
last
thing
I
have
here
is
that
we
have
a
specification
issue.
According
to
the
spec,
the
readable
span
should
show
the
the
dropped
counts
for
attributes
event
and.
C
B
B
D
Yeah
exactly
like
so
as
I
understand
we
merged
what
will
be
1.0,
but
it's
published
under
next
instead
of
the
latest,
and
I
was
wondering
whether
we
have
like
steps
that
need
to
be
done
before
we
can
publish
one
point
told
and
what
could
those
be.
B
So
what
we
do
is
we
release
with
the
next
tag
for
the
api,
so
we
can
make
the
updates
in
core.
So
once
the
core
is
released,
we'll
make
an
updating,
contrib
and
once
that's
released.
We
will
then
apply
the
latest
tag
across
all
three
of
them.
At
the
same
time,
this
just
means
that
if
the
user
installs
like
npm,
install
open,
telemetry
api
and
core
and
a
couple
of
instrumentations,
then
they
are
guaranteed
to
get
compatible
versions.
Unless
they
explicitly
say
I
want
next
or
some
specific
version.
D
B
Nothing,
the
release
is
the
release.
Pr
is
here,
just
need
reviews
and
then,
once
that's
done,
we'll
do
contrib.
D
Well,
eventually
that
as
well,
I
guess,
but
I'm
just
wondering
like
since
last
week
it
seemed
that
we
are
like
we
don't
have
any
blockers
on
releasing
api.
I
was
wondering
whether
like
there
actually
is
or
has
something
you
know,
bubbled
up
or
or
what's
what's
the
status
on.
B
That,
no
I
mean
it's
officially
published,
you
can
use
it
using
the
next
dis
tag.
If
you
want
today,
it's
just
that
we
won't
publish
it
as
the
latest
tag
until
the
core
and
contrib
are
published,
that
use
it.
D
Yep,
that
does
make
sense
and,
as
I
understand
core
and
contrib
basically
do
not
have
any
blockers
either
and
will
be
published
soonish.
Or
do
you
have
a
gut
feeling?
When
might
those
be
published.
B
Yeah
I
mean-
hopefully
core
will
be
done
today.
I'd
like
to
at
least
make
the
pr
for
contrib
today,
you
know
getting
both
of
those
released
in
one
day
sometimes
doesn't
always
work
out,
just
because
we're
waiting
on
reviews,
but
I
don't
know
of
anything,
that's
blocking
it,
so
it
just
depends
on
how
quickly
we
can
get
them
reviewed.
B
B
We
haven't
really
talked
about
it
because
we've
been
focusing
on
the
tracing
so
much,
but
now
that
the
api
1.0
is
out,
I
think
it's
probably
time
to
start
investing
some
effort
in
this.
I
know
that
our
metrics
api
is
way
behind
the
current
specification.
B
I
don't
know
where
the
other
sigs
are
at
in
terms
of
metrics
implementations.
I
know
it's
kind
of
all
across
the
board.
There
are
definitely
some
like
go
that
track
it
pretty
closely
and
then
there's
others
like
us
that
haven't
been
for
a
while,
I
think,
there's
a
lot
somewhere
in
the
middle
in
terms
of
like
a
road
map.
B
I
I
really
don't
have
much
to
say
to
you
other
than
this
is
something
that
I
want
to
start
working
on
soon,
where
it
says
he
thinks
it's
in
a
prototyping
phase
for
sdk
yeah,
that's
correct!
So
as
they're
writing
the
the
sdk
specification,
they
do
have
a
couple
of
sigs
that
are
working
on
prototypes.
B
I
think
python
is
one
of
them.
I
think
go
is
one
of
them
and
we
are
not
currently
one
of
the
prototypes
that
they're
using
just
because
we
didn't
have
bandwidth
to
do
it
at
the
time
and
in
the
prototyping
phase,
things
break
all
the
time
and
you
end
up
having
to
re-implement
things,
and
I
just
didn't
want
to
deal
with
that
headache
at
the
time,
but
I
think
the
sdk
specification
is
supposed
to
be
done
in
the
next
couple
of
months.
B
I
don't
know
who
will
sort
of
lead
that
effort.
We
haven't
really
had
anyone
step
up
to
say
they
want
to
do
the
metrics
work.
Yet
I
haven't
had
time,
but
if
it
gets
to
the
point
where
it
needs
to
be
done
and
no
one
else
has
stepped
up,
I
will
do
it.
But
if
somebody
does
want
to
step
up
before,
then
they
are
more
than.
B
B
Do
you
have
any
questions
based
on
that
answer?
I
know
it.
It
isn't
really
much
of
an
answer
beyond
we're
getting
to
it,
but
I
don't
know
if
you
were
hoping
for
more
than
that.
D
No
but
but
I
do
hope
for
like
some
kind
of
announcement
or
maybe
a
tracking
issue
or
anything
that
would
be
helpful
for
people
to
you
know,
keep
up
to
date
with
the
progress
I.
D
It's
it's
way
too
early
for
that
still,
but
I'm
definitely
interested
in
any
progress
or
for
helping
with
the
progress
eventually
when
we
get
there,
I
just
don't
feel
that
I
would
be
suitable
for
you
know,
taking
the
burden
or
or
like
leading
the
effort,
but
I'm
definitely
interested
in
the
progress.
Okay,.
B
So
I
have
looked
through
the
the
api
specification
a
little
bit
and
it's
quite
a
bit
different
than
the
old
one
was
so
I
think
it's
going
to
require
essentially
a
ground
up
rewrite,
but
I
will
at
least
create
a
tracking
issue
for
that
and
we
can
try
to
break
down
the
work
into
smaller
pieces
so
that
people
can
take
it
as
they
have
time.
D
B
Thanks,
so
that
was
everything
we
had
on
the
agenda.
Is
there
anything
else
that
anybody
wants
to
bring
up
or
concerns
that
people
have.
E
Yeah
open
an
issue
in
hotel,
js
and
valentin
moved
it
to
js
api.
It's
about
this.
I
found
that,
where
record
exception
doesn't
comply
with
the
spec,
let
me
drop
it
in
chat,
I'm
not
sure
if
that's
like
something
that
needs
to
be
in
the
spec
v1
label
or
not,
or
if
it's
small
enough
that
it
doesn't
matter.
B
Okay,
for
now
I'll
just
apply.
I
think
we
have
yeah
specification
label
and
is
this
something
that
you
want
to
work
on
or
no.
E
Oh
yeah,
I'm
happy
to
pick
it
up.
I
guess
one
question
I
have
is
with
the
js
api
and
the
js
repos.
How
do
you
usually
propagate
those
changes
that
are
like
api
changes.
B
So
at
this
point,
api
1.0
is
released,
so
all
changes
need
to
be
made
in
a
backwards
compatible
way.
So
what
we'll
do
is
we'll
just
update
the
api
in
a
backwards,
compatible
manner
and
publish
it,
and
then
we
will
update
the
core.
You
know
the
the
point
of
use
to
make
use
of
that
once
it's
published.
B
Yeah
in
a
in
a
situation
where,
theoretically,
we
have
some
change
that
couldn't
be
made
in
a
backwards
compatible
way,
we
would
probably
want
to
get
guidance
from
the
tc
on
whether
we
wanted
to
make
a
major
version
bump
or
just
document
it
as
a
discrepancy
with
the
specification,
or
in
some
case
I
guess
we
could
deprecate
the
old
api
and
maintain
it
but
create
a
new
method
with
a
new
name
that
is
specification
compliant.
But
at
this
point
all
changes
moving
forward
must
be
backwards,
compatible.
B
B
Okay,
thanks
for
bringing
that
up-
and
I
assigned
that
to
you
all
right-
that's
okay,
right.
F
One
quick
thing
so
now
that
we
have
the
api
1.0
release.
Will
we
need
those
npm
next
and
latest
tags
for
api
releases
going
forward
or
is
the
carat
dependency
just
going
to
stay
in
all
the
sdk
packages.
B
Yeah,
so
all
of
the
sdk
packages
depend
on
carrot
versions
of
the
api,
so
if
we
make
releases
in
a
backwards
compatible
way,
I
don't
see
why
we
would
need
to
use
the
next
tag.
B
F
B
B
Yeah
yeah,
so
if
we
have
some
version
of
the
of
the
sdk
say
we're
down
the
road
version
0.32
of
the
sdk,
and
we
want
to
take
advantage
of
some
new
feature.
That's
been
added
to
the
api
in
a
backwards
compatible
way
right.
So
we
add
a
new
method
to
the
api.
We
want
to
be
able
to
take
advantage
of
it
in
the
sdk.
B
We
will
definitely
have
to
bump
the
carat
version
in
the
sdk
bump
the
dependency
version
of
the
api
in
order
to
use
that
method,
so
that
effectively
changes
the
minimum
version
of
the
of
the
api
that
the
end
user
will
have
to
install
and
use.
C
B
You
know
the
end
user
would
have
to
use
a
slightly
older
version
of
the
sdk
if
we
update
the
sdk
to
take
advantage
of
new
apis
yeah,
that's
something
that
they
talked
about
when
they
came
up
with
the
versioning
scheme.
I
know
that
ted
swo
did
a
lot
of
work
on
that
at
the
time,
and
I
I
think
that
was
just
a
limitation
that
they
decided
was
acceptable
in
order
to
allow
us
to
move
forward
and
implement
new
apis
yeah,
okay,
cool,
so
yeah.
B
The
the
short
version
is
that
we
will
eventually,
on
the
the
sdk
bump,
the
minimum
version
of
the
api
up
when
we
try
to
use
new
new
apis
that
are
added
to
it.
But
we
should
try
to
do
that
as
little
as
possible
because
we
do
want
to
be
as
flexible
as
possible
for
our
end.
B
C
B
Okay,
well,
I
would
appreciate
if
people
would
please
review
the
prs
that
we've
we've
talked
about
here,
especially
the
release
ones,
and
I
will
talk
to
you
all
next
week.