►
From YouTube: 2021-06-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).
A
A
B
A
C
Gotta
use
my
computer
for
a
second
okay,
so
the
first
item
on
the
agenda
here
all
of
our
issues
from
the
spec
review
have
been
closed.
I
believe
that
includes
both
the
api
and
the
sdk.
So
if
anyone
knows
of
any
that
are
still
open,
please
let
me
know,
but
for
now
I
am
declaring
victory.
C
C
I'm
okay!
I
I
didn't
hear
you
but
okay,
nothing!
Okay,
yeah,
since
we
are
just
introducing
changes
to
the
api,
I
think
I'd
like
to
let
them
live
for
a
week.
We're
also
releasing
a
new
version
of
core
that
points
at
the
latest
api.
C
In
case
we
have
to
make
any
last-minute
emergency
fixes,
but
barring
that
I
do
not
expect
any
more
breaking
changes
to
the
api
that
does
not
affect
the
sdk,
so
we
can
still
make
breaking
changes
to
the
core
and
contributory
bows
and
it
does
not
prevent
additive
changes,
so
we
still
want
to
add
convenience
functions
and
things
like
that
they're
still
allowed
as
long
as
they're
backwards
compatible.
C
The
api,
when
78
is
merged
version
21
will
be
released.
I
expect
the
1.0
code
to
be
identical
or
nearly
identical
to
the
version
0.21
code.
C
C
C
Node
does
not
have
full
disk
access
on
most
people's
mac,
os
machines,
at
least
by
default,
unless
you
have
specifically
allowed
it
and
that's
what
was
causing
the
issue
for
now,
we
rolled
it
back
to
four
dot
x,
but
the
karma
webpack
folks,
I
guess,
are
working
on
it,
so
hopefully
we'll
be
able
to
update
that
again
in
the
near
future.
But
for
now
the
tests
are
working.
C
So
that's
the
api
stuff
for
the
sdk.
Before
we
go
to
1.0
or
before
we
go
to
maybe
even
the
rc.
I
think
we
should
think
about
renaming
the
metrics
packages.
Currently
we
have
metrics
api
and
we
have
metrics
when
we
roll
the
core
repo
to
1.0
in
its
current
state.
Those
packages
would
get
the
1.0
version
also,
and
they
are
very
experimental
and
clearly
not
ready.
C
C
B
I
haven't,
it
will
be
easier.
I
guess
if
we
simply
keep
it
zero,
because
it
will
give
us
possibility
to
release
like
with
every
change
we
could
release
like
you
know,
zero
something
again
again,
so
we
don't
need
to
change
the
version.
One.
C
C
You
know,
try
to
make
any
decision
without
doing
my
research,
so
I
guess
we
can
hold
on
this.
The
sdk
is
not
1.0.
Next
loop
anyways
for.
B
C
Yeah,
okay,
I
might
create
like
a
a
sample
project
repo
with
a
few
packages
in
it.
I
know
that
it's
for
sure
possible.
I
know
that
learner
has
a
mode
for
this.
I've
just
never
used
it.
C
C
He
was
the
one
that
wrote
our
current
contrib
release
automation
and
there
was
some
reason
we
didn't
do
that
will
do
you
remember
why,
or
was
it
just
because
it's
easy
or
not
to.
D
C
Yeah,
so
rano
is
saying:
if
we,
if
we
go
to
independent
versioning
mode
and
learn
for
the
core,
we
should
do
that
for
contrib
as
well.
Is
there
some
reason
when,
when
you
wrote
the
the
release,
automation
stuff,
that
you
did,
that
you
didn't
that
you
decided
not
to
do
independent,
versioning.
D
D
Yeah,
it
was,
I
mean
primarily
because
that
was
how
it
already
was,
but
also
I
know
that
there
was
some
discussion
with
some
of
the
other
cigs,
specifically
the.net
sig,
and
maybe
the
python
sig
2,
where
it
was
kind
of
discussed
like
the
degree
to
which
kind
of
contributors
would
own
and
maintain
their
components
and
whether
that
would
mean
that
they
would
also
be
in
charge
of
releasing
their
components
independently
of
all
the
other
components
in
the
contrib
repo.
D
D
Based
off
the
repo
alone,
what
the
version
of
all
those
packages
were,
so
I
think
it
was
just
kind
of
a
best
practices
thing
at
the
end
of
the
day,
but
I
I
don't
think
that
we
were
too
strongly
opinionated
on
it.
I
think
it
was
mostly
like
the
dot-net
maintainers
and,
I
suppose,
honorable
to
a
degree,
I
was
in
favor
of
keeping
everything
at
the
same
version
as
opposed
to
independent.
C
Okay,
so
it
was
really
just
a
matter
of
convenience,
then
I
guess
it
is
worth
mentioning
that
somewhere
in
here
it's
mentioned
that,
let's
see,
sdk
packages
must
version
together.
C
Each
contrib
package
may
have
its
own
version
number.
So
in
the
spec
they
say
that
our
sdk
packages
should
all
have
the
same
version
numbers,
but
I
don't
think
that
this
applies
to
the
experimental
packages.
There's
also
an
exception
down
here,
for
in
some
languages
experimental
packages
having
a
version
higher
than
0.x
isn't
advisable.
C
Experimental
signals
may
version
independently
from
stable
signals,
so
it
seems
like
this
is
allowed,
but
I
guess
I'll
look
into
what
it
takes
to
do
it
and
learn,
at
least
for
the
metrics
packages
and
rano
I'll,
take
a
look
at
it
for
contrib
2,
but
just
keep
in
mind
that
that's
not
a
super
high
priority
right
now,
so
it
may
have
to
wait
another
week
or
so.
D
If
that
were
to
happen
and
contrib
would
like,
we
still
want
to
be
releasing
all
the
packages
in
lockstep,
or
would
it
be
like
we
would
kind
of
separate
out
those
responsibilities.
C
No,
I
think,
if
in
contrib,
if
we
were
going
to
do
that,
I
would
say
every
pull.
Request
should
also
update
the
version
number
of
whatever
package
you're
modifying
right.
So
if
I
modify
the
mysql
instrumentation
for
a
bug
fix,
I
should
bump
the
patch
version
of
the
mysql
instrumentation
in
that
pr
and
then,
when
it
merges
it
would
automatically
be
released.
C
Okay
got
it
makes
sense
that
puts
a
little
bit
more
of
the
burden
on
both
pr
authors
to
make
sure
that
they
are
versioning
properly
and
on
reviewers
to
make
sure
that
that's
actually
done
in
a
consistent
manner.
So
it
is
a
little
bit
more
work
on
both
sides
there,
but
I
think
that's
the
only
way
we
would
be
able
to
independently
virgin
contrib
in
a
maintainable.
You
know
scalable.
C
I
actually
had
been
working
on
this
for
a
while,
but
I
was
looking
at
what
other
cigs
had
done
and
I
was
reading
the
spec
document
and
I
realized
that
I
had
been
mostly
just
rewriting
the
doc
that
was
already
in
the
spec.
So,
instead
of
doing
that,
I
just
linked
to
it.
C
This
doesn't
seem
to
be
an
issue.
The
the
specification
doesn't
require
us
to
have
our
own
versioning
doc,
and
we
don't
have
any
exceptions
from
the
specification.
So
just
linking
directly
to
that
dock,
I
think
is.
It
is
both
more
detailed
than
a
dock
that
I
would
write
and
it
is
definitive
because
it's
in
the
spec,
so
I
updated
this
pr
to
point
to
that.
There
were
already
a
handful
of
approvals
on
this
vr,
so
it's
quite
a
bit
different
now
than
it
was
before.
C
I
think
roano
made
this
pr
for
testing
on
node
16..
I
could
be
wrong
there,
but
the
tests
are
failing
on
node
16..
C
F
So
I'm
doing
a
bad
sub
job
at
communicating
this,
but
but
the
all
three
prs
for
adding
node
16
to
the
tests,
we're
kinda
in
like
work
in
progress
mode,
but
thanks
for
looking
into
this,
the
other
one
on
the
s.
No,
not
the
sdk.
The
contrib
also
had
some
issues,
but
I
haven't
had
time
to
look
into
them
either.
C
Yeah
I
haven't
looked
at
the
contrib
one
at
all,
so
I'm
not,
and
did
you
make
one
in
the
api?
I
had
not
seen
that,
but
it's
possible
that
I
just
missed
it.
F
C
C
C
It
does
seem,
like
the
author
is
a
little
bit
slow,
responding
right
now,
but
it
was
a
holiday
weekend.
So
I
think
we
can
give
them
a
little
bit
of
slack.
A
It
actually
occurred
to
me
after
we
talked
about
it,
but
the
open
tracing
shim
spec
is
still
experimental
as
well.
If
you're
going
to
mark
something,
if
metrics
are
going
to
be
a
different
version,
it
might
be
good
for
that
package
to
be
as
well.
C
The
shim,
the
shim,
is
required
by
api
or
by
specification
version
one
I
believe,
where
is
it
documented
anywhere
that
that's
experimental.
A
Yeah,
let
me
so
there's
an
issue
that
carlos
opened
that
I'm
kind
of
working
off
of,
and
somebody
asked
him
if
it
was
required
for
ga.
He
said
no,
it's
still
marked
experimental.
C
C
C
E
General
question:
yes,
that
came
up
internally
yesterday:
do
we
have
any
plans
to
add
on
some
sort
of
check
to
make
sure
we
don't
inadvertently
break
the
api?
I
know
from
my
internal
discussions
that
java's
already
got
this,
which
I'm
just
going
to
paste
the
request
in.
E
Also
got
one
as
well,
so
now
that
we're
you
know
on
the
on
the
verge
of
releasing
1.0,
you
know.
Do
we
want
to
try
and
get
someone
to
spend
some
time
to
do
something
similar.
C
I
think
it's
a
great
idea.
I
don't
know
of
any
tools
that
exist
in
typescript
to
do
that,
to
automatically
check
the
public
api
to
see
if
it
can
change.
I
know
in
in
languages
like
java
and
dotnet,
where
they're
compiled
and
they
have
strict
api.
It's
a
it's
a
little
bit
easier
for
tools
like
that
to
exist,
but
I
wouldn't
be
surprised
if
somebody
has
written
one.
I
just
I'm
not
aware
of
any.
E
Yeah,
likewise
for
the
stuff
I
do,
I
I've
implemented
api
extractor
and
I
effectively
manually
go
over
the
the
json
file
every
time
we
do
a
release.
It's
just
painful
at
the
moment.
C
Yeah,
I
I
do
sort
of
the
same
thing,
but
by
using
the
ts
dock
generator-
and
I
just
look
at
the
the
exported-
you
know
items
to
make
sure
that
we're
not
definitions,
right
yeah.
I
do
it
to
make
sure
we're
not
exporting
anything
internal
that
we're.
You
know
unintentionally,
but
it
could
be
used
for
the
same
thing.
I
hear
that
one
I
I
am
fully
in
support
of
this.
I
just
don't
I'm
not
aware
of
any
tools
that
do
this
specifically.
C
Are
you
willing
to
take
that
as
a
sort
of
a
research
topic,
and
you
know
try
to
come
up
with
a
if
not
an
exact
solution,
then
at
least
you
know
some
ideas
directions.
We
can
move
towards.
E
I
can
look
at
it,
but
at
the
moment
I've
been
like
overloaded
with
internal
stuff,
so
you've
probably
seen
I
haven't
been
that
active
on
the
reviews.
Okay,
I
am
trying
to
get
a.
C
Can
you
at
least
create
an
issue
then
in
the
api
repo,
and
so
we
can
check
it
just
so
we
can
track
it.
Yeah
cool.
F
On
a
similar
topic,
especially
making
the
changes
like
unifying
the
bins
bind
and
the
width
methods
on
the
api
yeah,
I've
realized
that
that
how
fragile
the
whole
system
is
in
its
current
state
or
you
know
it's
it's
very
cross-connected-
do
we
do
we
have
like
experience
or
workflow
in
regards
of
making
api
changes
in
the
long
run
because,
like
I
think
this
should
be
something
we
kind
of
at
least
I
kind
of
think
through
like
how
would
we
introduce
changes
to
the
api
additions
and
and
deprecations
and
stuff
like
that,
because
I'm
pretty
sure
eventually
we
need
to.
C
So
are
you
you're
saying
api?
The
change
is
made
in
the
api,
but
because
it's
not
released
yet
it's
hard
to
make
a
change
in
core,
because
there's
no
version
to
point
against.
F
Kinda
it's
what
I'm,
what
I'm
experiencing
is
that
basically
api
and
sdk
are
are
connected
in
a
way
that
they,
basically
they
need
to
be
released.
F
At
the
same
time,
they
are
kind
of
the
same
thing
in
a
way,
and
I
was
wondering
whether,
in
their
future,
we
would,
you
know,
have
the
same
problem
when
we
introduce
changes
to
our
additions
to
the
api,
because
we
cannot
remove
anything
at
that
point
right
once.
It's
ga
then
like.
How
would
we
in
general,
like
the
process
of
introducing
changes
to
the
api
kind
of
by
mapping
that.
C
Out,
if,
if
you
look
at
the
the
versioning
instability
dock
and
the
specification,
it
addresses
this
a
little
bit
so
the
api
breaking
changes
that
are
not
allowed
are
specifically
for
end
users,
so
users
that
call
the
api
should
never
be
broken.
Sdks
that
implement
the
api
may
be
broken
in
some
cases
on
minor
version
changes.
So,
for
instance,
if
I
use
sdk
version
1.2,
which
points
at
api
version
1.0
and
then
the
api
version
updates
any
end.