►
From YouTube: 2022-03-23 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
B
I
I'm
in
the
office
today
and
I
couldn't
find
a
a
real
meeting
room,
so
this
is
like
I
guess
this
is
a
room
that
can't
be
booked
in
advance.
You
have
to
just
show
up
so
specifically
for
stuff
like
this,
where
I
didn't
have
a
proper
room
yeah.
I
like
working
from
home.
B
Okay,
I
think
we
can
probably
get
started.
Let
me
share
my
screen.
B
All
right,
so
we
released
version
1.1.0
of
the
core
api
or
of
the
stable
part
of
it
anyways,
and
there
was
an
issue
with
the
release
where
the
esm
builds
and
the
es
next
builds
were
not
included
in
the
bundle.
B
So
legendicus
made
a
pr
to
ensure
that
those
builds
are
done
during
the
publish
process,
and
then
we
republished
a
1.1.1
release,
so
hopefully
not
too
many
people
are
impacted
by
that
it
only
does
affect
esm,
builds,
which
I
guess.
Hopefully
it
wasn't
too
big
of
a
problem,
but
it
is
what
it
is.
I
think
that
the
next
step
here,
one
now
that
we're
releasing
stable
versions
of
things.
I
think
our
our
releases
should
really
be
automated.
B
This
particular
one
would
have
happened
with
an
automated
release
anyways,
unfortunately,
because
it
should
have
been
a
part
of
like
the
build
step,
but
in
general
I
just
think
that
these
things
should
be
automated,
so
I
will
probably
be
working
on
that
in
the
next
week
or
two,
so
I
guess
look
out
for
that.
B
Rono
and
I
have
already
been
discussing
a
little
bit
of
this,
like
api
version
compatibility
issue,
trying
to
track
down
a
little
bit,
what
caused
it
and
how
to
solve
it.
The
short
version
is
that
our
contrib
packages
depend
on
the
carat
version
of
the
core
packages
which
depend
on
a
later
version
of
the
api
than
the
contrib
packages.
Sport
is
that
you
think
a
fair
way
to
describe
it
right
now.
B
It's
difficult
with
with
different
your
packages
from
different.
You
know
you
have
the
api
package
and
the
sdk
package
and
the
contrib
packages
are
all
kind
of
separate,
and
then
some
of
them
have
peer
dependencies
and
some
of
them
have
regular
dependencies
and
some
of
those
dependencies
are
pinned
and
some
of
them
are
not
pinned
or
with
carrot
or
with
tilde,
and
it's
keeping
the
dependency
graph
in
your
head
is
a
little
bit
of
a
struggle.
B
So
it
may
be
a
good
idea
for
us
to
actually
you
know
codify
that
that
dependency
graph
in
a
document
either
in
the
core
repo
or
in
the
contrib
repo
to
say
these
are
the
dependencies
we
have
between
these
packages
and
what
versions
they
should
allow,
so
that
we
can
avoid
issues
like
this
in
the
future.
B
I'm
happy
to
take
that
on.
Unless
somebody
else
feels
like
they
have
a
good
grasp
of
this
and
wants
to
do
it.
A
I
don't
get,
but
I'm
kind
of
working
on
this,
so
I'm
happy
to
give
it
a
go.
First,
if
you
don't
mind,
okay,
yeah.
B
So
why
don't
you
do
that
then,
and
whether
you
open
it
in
contrib
or
in
core
is
probably
fine,
I
would
say
core
is
probably
the
best
place
for
it,
and
then
we
can
just
link
to
it
from
like
the
contributing.md
in
contrib
to
say
if
you're
writing
a
module.
These
are
things
you
need
to
be
aware
of.
B
But
right
now
there
is
user
impact,
so
I
think,
in
terms
of
an
immediate
fix,
we
need
to
probably
update
all
the
dependencies
in
core
and
get
a
version
shipped
fairly
quickly
or
in
in
contrib
and
get
a
version
shipped
fairly
quickly.
Is
that
do
you
think
reasonable.
A
Yeah,
like
I
don't
know
how
to
fix
it
yet,
but
there
has
to
be
like
a
release
specifying
different
dependency
versions.
B
Yeah
I
mean,
I
think,
just
updating
to
the
sdk
1.1
in
all
of
the
contrib
packages
should
be
okay
right.
A
Yeah
that
would
fix
it,
but
that
would
also-
and
it's
it's
probably
the
the
most
like
foolproof
way
to
fix
it
right
now.
But
that
would
also
mean
that
all
the
users
have
to
bump
their
api
versions
as
well,
because
they
would
suddenly
like
that
older
apis
wouldn't
work
with
the
new
sdk.
So
we
kind
of
force
it's
kind
of
we
kind
of
force
them
into
somewhere
incompatible
update
because
they
shouldn't
need
to
update,
but
no.
B
B
A
B
So,
let's,
let's
try
to
get
it
at
least
working,
and
then
we
can
work
on
a
more
long-term
solution
from
there.
I
think
just
to
get
it
working.
We
should
probably
just
make
a
pr
that
uses
the
tilde
versions
of
the
of
the
core
just
to
be
as
safe
as
possible
or
even
pin
them
might
be
a
good
idea.
A
B
A
So
different
api
versions,
so
it's
tricky,
like
probably
the
best
way
for
now-
is
to
update
the
dependencies,
but
leave
like
a
looser
ranges.
So
it
would
be
a
similar
that
that
has
been
working
for
a
while,
but
forcing
users
to
update
and
then
figuring
out
how
to
better
specify
the
beer
dependency
ranges.
B
B
Yeah
because
the
patch
releases
have
been
okay
yeah.
So
do
you
want
to
make
that
pr,
since
you've
already
been
looking
into
this
issue,
then.
B
Okay,
thank
you.
Anyone
else
have
questions
around
that,
or
should
we
move
on.
B
All
right
last
week
we
talked
about
requiring
in
the
core
repo
users
to
manually
make
change
log
updates.
I
did
open
a
pr
for
that.
I
think
I've
gotten
a
couple
of
reviews,
so
thank
you
to
those
people
who
reviewed
it,
but
to
those
who
have
not
seen
it
yet,
oh
great
to
those
who
have
not
seen
it
yet.
Please
review
that.
The
short
explanation
of
this
is
that
we
will
be
requiring
all
prs
to
modify
the
change
log.
B
There
are
two
separate
change
logs
now,
one
for
stable
packages
and
one
for
experimental
packages
and
any
prs
that
do
not
need
to
update
the
change.
Log
will
be
able
to
apply
the
skip
change
log
label,
and
this
is
a
strategy
that's
being
used
by
the
collector
at
least
and
the
specification,
and
it
just
ensures
that
the
change
log
is
accurate
right
now.
B
We're
automatically
generating
it
from
pr
titles
and
pr
titles
are
not
always
that
great
from
that
perspective
and
labels
are
not
always
very
consistently
applied,
and
I
just
think
that
this
is
going
to
be
a
more
consistent
experience.
Moving
forward
for
the
change
log
in
terms
of
making
it
more
accurate
and
also
only
documenting
those
changes
which
actually
affect
users,
so
if
it
doesn't
work,
we
can
always
go
back,
but
I
also
believe
it
will
help
us
to
automate
the
releases,
because
the
change
log
is
probably
the
most
difficult
thing
to
automate.
A
Like
my
only
thought
is
about
syncing
those
changes
between
the
repos,
the
core
and
contrib,
should
we
eventually
maybe
want
to
do
that,
because
there
are
quite
a
few
increasing
amount
of
like
differences
working
in
country
and
core
with
regarding
to
the
tooling,
because
it
may
be
something
that
we
want
to
consider
for
doing
full
country
as
well.
At
some
point,.
B
We
can
consider
it
at
some
point:
the
contrib
release,
automation
is
significantly
more
advanced
and
it
updates
change
logs
per
package.
So
each
package
has
a
change
log
file
within
it,
which
that's
part
of
the
problem
with
the
core
repo.
Is
that
all
of
there's
only
a
single
change
log
file
right
now
and
the
automation
dumps
everything
into
a
single
file
and
then,
when
we
release
a
stable
version,
it's
not
clear
what
is
stable
and,
what's
experimental
in
the
change
log
and
stuff,
like
that,
I
understand
wanting
to
keep
it
consistent.
B
Updating
the
the
change
log
manually,
I
don't
think,
is
too
big
of
a
burden,
so
it
might
make
sense
in
contrib.
Also,
I
guess
my
my
short
answer
is
yeah.
I
would
consider
that,
let's
do
it
in
core.
First,
where
we
know
we
need
it
and
see
if
it
works,
because
people
might
hate
it
and
we
might
have
to
revert
it
anyways.
B
So,
let's,
let's
see
if
it
works
here
and
then,
if
it
works,
we
can
expand
it
into
contrib.
If
we
think
that
makes
sense.
B
C
Yeah
it's
in
decent
shape.
One
of
the
recent
things
I
got
into
was
some
of
the
linting
stuff.
C
B
Yeah,
I
think
this
was
something
we
decided
to
do
in
order
to
resolve
the
dependency
discussion.
We
were
having
last
week
right.
C
Yeah,
I
think
the
approach
that
I
took
still
probably
makes
sense,
even
if
it's
a
little
unconventional
it
kind
of
forces
that
to
be
updated
without
having
to
manage
a
lot
of
extra
tooling
around
it.
I
don't
know
I'm
open-minded
there,
though,.
B
Yeah
I
mean
the
other.
The
other
option
would
be
to
add
all
of
the
examples,
as
learner
sub
projects
also,
I
think
that
this
is
a
simpler
solution
to
that.
Amir
is
on
the
call,
though,
and
he
made
this
comment.
So
is
this
something
you
feel
strongly
about
here
or
is
it
just.
D
B
C
B
Just
actually,
maybe
just
add
a
comment
to
it
that
says
like
in
you
know,
you
know
in
your
application
import
express
instrumentation
here
or
something
like
that.
You
know
I
don't
know.
Yeah.
C
C
I
don't
know
it's
just
tough,
the
I
think.
If
we
were
to
switch
to
importing
from
a
package,
we
would
need
to
do
some
sort
of
ci
check
to
make
sure
that
the
version-
that's
in
the
express
instrumentation,
for
example,
matches
the
example
version,
which
isn't
it's
not
that
that
wouldn't
be
that
hard.
But
it's
just
a
different
approach.
B
Yeah
I
mean
lerna
does
handle
that,
so
what
you
would
do
is,
you
would
add
so
right
now
we
have
like
plugins
node
star
in
like
the
packages
list.
We
would
probably
have
plugins
node
star
examples.
B
Also
we'd,
add
it
as
a
as
another
line
in
the
learner
repo
and
then
it
would
add
any
examples,
folder
and
then
each
example
would
probably
have
to
have
its
own
package
json,
which
it
already
does,
and
then
you
would
put
private
true
on
that
to
make
sure
it's
not
released
to
npm
or
anything
weird
like
that.
D
C
Yeah
yeah,
so
does
it
work
to
do
like
how
there's
it
would
be
like
plugins,
node
star
and
then
slash
examples.
B
B
Just
a
basic
blob,
syntax
and
it'll
find
all
the
folders
that
match
in
any
any
instrument.
You
know
any
of
those
folders
that
are
missing
an
examples.
Folder
it'll
just
skip
them.
So
it's
no
problem.
You
just
have
to
make
sure
you
put
private
true
in
the
package
json,
so
we
don't
accidentally
release
it,
publish
it.
Okay,.
C
Yeah,
I
can
do
that
I'll
need
to
update
the
like
instructions
for
migrating
an
example
as
well
to
include
all
that-
or
at
least
parts
of
it.
B
Yeah,
I
mean
at
least
just
try
it
to
see
if
it
works
first,
because
if
it
requires
a
ton
of
work,
then
maybe
it's
not
worth
it.
But
if
it's
easy
and
then
the
biggest
advantage
to
that,
in
my
opinion,
is
that
an
end
user
would
be
able
to
just
copy
this
file
into
their
own
project
and
it
would
actually
run.
C
Yeah
that
makes
sense
I'm
on
board
with
that,
then
the
one
other
like
learner,
related
thing
in
here
as
well
was,
I
think
you
mentioned
a
different
way
to
run
the
like
example,
compiling
with
the
learner
command.
C
I
got
it
yeah.
I
see
now
that
that's
in.
C
Oh
now,
I
was
thinking
the
way
this
runs.
Maybe
I
missed
this.
I
thought
that
this
is
running
against,
like
a
matrix
of
all
those
paths.
C
C
B
We
actually
already
talked
about
this,
because
that
was
the
issue
above
so
I'll.
Just
remove
that
I
wanted
to
give
people
a
quick
update
on
the
various
metrics
pr's
and
issues
that
are
open
so
right
now
there
are
only
two
prs
that
are
open
in
the
core
repo
at
least
non-draft
prs
that
are,
that
are
metrics
related,
and
this
is
the
only
sdk
one.
So
it's
been
open
for
about
two
weeks
and
it
is
relating
to
the
the
shared
state
between
meters.
B
After
this
pr,
there
is
one
final
to
do
about
meter,
identity
and
conflict
resolution,
but
please
people
review
this
pr,
we're
getting
very
close
to
being
able
to
have
a
release
of
the
metrics
sdk.
So
this
is
one
of
the
one
of
the
last
issues
that
we
have
so
yeah.
It's
I
keep
harping
on
this,
but
metrics
is
still
a
priority.
B
There's
also
apr
to
update
the
prometheus
exporter,
which
I
suspect
is
significantly
more
straightforward,
because
it
doesn't
really
do
anything
fancy
with
the
sdk.
It
should
just
be
transformations
and
and
the
regular
prometheus
export.
So
please
review
that
as
well.
B
This
is
an
issue
not
a
pr.
So
it
is
currently
up
for
grabs
and
we
need
to
update
the
otlp
exporters
to
work
with
the
latest
metrics
sdk,
since
it's
significantly
different
than
than
what
the
last
released
version
was.
B
So
if
anybody
wants
to
volunteer
to
take
this
on,
I
would
appreciate
that,
if
not,
I
can
probably
handle
it.
I
don't
probably
have
time
this
week,
but
maybe
next
week
one
thing
that
this
does
depend
on
looks
like
this
may
have
actually
merged.
B
Yeah
yeah
yeah,
so
that's
done
so
this
is
ready
to
be
worked
on.
So
does
anybody
want
to
want
to
take
this
on?
Can
I
sign
this
to
somebody
today?
B
Can
you
comment
on
the
issue
so
that
I
can
assign
you
yeah
since
you're,
not
a?
I
can't
assign
people
that
aren't
members
of
the.
B
Should
already
be
there
so
yeah,
I
just
have
to
refresh
the
page
for
it
to
pick
it
up
there
we
go
okay
and
then
svedlana
support
for
node
versions,.
E
B
This
is
a
recurring
topic,
I
guess
you
would
say.
Currently
we
support,
I
think
we
say
we
support
8.5,
although
it
actually
8.11
is
the
lowest
version
that
it
actually
works
with.
So
we're
already
kind
of
lying
a
little
bit,
but
I
agree
like
we
should
start
dropping
older
node
versions
in
terms
of
how
we
decide
which
ones
to
do
you
know.
B
D
B
B
I
know
that
we're
not
supposed
to
do
major
version
bumps
of
the
api
for
now,
but
I
don't
know
if
there's
a
policy
around
the
sdk,
maybe
we
should
talk
to
ted
and
maybe
bring
it
up
as
a
more
general
spec
issue
to
say,
are
we
allowed
to
make
major
revisions
of
the
of
the
sdk,
and
this
is
the
reason
we're
thinking
about
doing
it?
B
If
not,
honestly,
I
don't
think
that
supporting
old
versions
is
that
much
of
a
burden
like
it
hasn't
really
caused
big
problems.
Yet
maybe
there's
a
problem
that
I'm
not
aware
of
that.
That
is
being
an
issue
but
yeah
as
far
as
I'm
aware,
supporting
these
older
node
versions
is,
is
just
not
that
big
of
a
burden.
So
if
the
the
spec
or
of
ted
says
that
they
really
don't
want
us
to
bump
the
major
version,
then
honestly,
I
would
say:
let's
continue
supporting
these,
and
maybe
we
can.
A
So
in
country
like
it
is
actually
a
significant
burden
because
many
of
the
libraries
we
are
instrumenting,
don't
use,
don't
work
with
older
versions
anymore.
So
we
basically
we
could
like
complicate
the
ci
even
further
by
kind
of
separating
the
the
instrumented
libraries
like
into
different
categories,
by
which
node
version
they
support
and
etc.
But
it
just
complicates
everything
even
further
to
me.
It's
it
makes
sense
because,
like
how
can
we
realistically
actually
support
old
versions
if
they
are
not
supported
by
by
nodes
themselves?.
A
A
So
eventually
we
would
essentially
be
in
a
situation
where
we
don't
really.
We
don't
actually
support
old,
node
versions
in
any
of
the
packages,
but
what
we
we
say
we
do,
but
we
can't
because
the
the
libraries
themselves
don't
support
those
node
versions.
B
Yeah,
so
each
package
would
need
a
configuration
somehow
for,
like
the
you
know,
old
version
of
mongodb
supports
node
8,
but
this
slightly
newer
version
supports
node
10
and
everything
newer
than
this
version
supports.
Node
12.
Is
that
what
you're
saying
and
you
need
that
for
every
module.
B
B
I
would
recommend
that
in
contrib
we
are
more
aggressive
about
dropping
old
node
version
support,
so
I
would
say:
dropping
eight
in
contrib
is
just
fine
and
then
also
dropping
support
for
the
modules
that
we're
instrumenting,
that
that
target
those
old
versions
of
node.
But
if
we
just
say
we,
we
only
support
instrumenting
on
you
know,
12
or
higher
or
14
or
higher,
on
on
these
packages
in
contrib.
I
think
that
that's
fine,
the
sdk,
I
think,
should.
B
Work
harder
than
contrib
to
to
maintain
backwards
compatibility
in
order
to
open
up
as
many
use
cases
as
possible
for
as
many
customers
as
possible,
and
then
the
api
again
should
try
even
harder
to
support
as
old
of
a
version
as
possible,
but
for
contrib
I
think
it.
You
know
if
you're,
auto,
instrumenting
and
those
are
all
experimental
packages
anyways.
I
don't
think
it's
as
big
of
a
problem
to
drop
support
for
old
node
versions
in
the
contrib
repo.
D
B
B
Yeah
yeah,
no
problem.
What
I
was
saying
is,
I
think
we
can
drop
old
versions
in
contrib.
I
think
that
that's
totally
fine,
if
those
modules
say
we
don't
support,
note
8,
I
think
the
sdk
maintaining
better
backwards
compatibility
makes
sense
that
way.
A
That's
that's
exactly
what
we
are
doing
right
now.
It's
just
like
kind
of
in
the
in
the
general
communication.
We
we
say
that
we
support
older
versions,
but
yeah.
B
B
E
I
I
did
wanted
to
say.
I
think
that
our
sdk
support
should
be
at
least
for
starting
at
8.12
instead
of
8.5,
because
of
that
node
bug
that
was
fixed
in
812
that
caused
timestamps
to
be
set
up.
E
Yes,
yes
and
I
linked
to
the
comments
about
that
bug
being
fixed
that
people
talked
about
in
the
node
issue.
I
linked
to
to
that
in
the
issue
I
opened
about
the
incorrect
timestamps.
B
Got
it
okay,
yeah,
I
think
8.12
is,
is
fine.
I
think
we're
already
only
testing
on
the
latest
version
of
eight
anyways,
so
yeah.
I
think
that's
fine.
E
C
I
have
a
quick
learner
question
on
the
same
topic.
We
don't
have
to
keep
anyone
enough.
We
don't
want,
but
if
anyone
wants
to
hang
out
and
chat
for
a
minute,
I'd
be
happy
to
work
through
it.
C
Basically,
I
was
thinking
through
the
change
we
were
talking
about
and
what
I'm
wondering
is,
if
you
were
to
make
a
change
to
the
express
instrumentation,
for
example,
and
you
know
say
like
it
was
going
to
bump
the
version.
How
would
the
example
get
the
version
bump?
At
the
same
time
like
in
theory,
an
update
to
the
example
would
have
to
come
in
a
subsequent
pull
request.
B
Because
that's
the
way
version
works.
If
the
example
depends
on
the
express
instrumentation
version,
that's
in
the
repository,
then,
in
the
examples,
node
modules
directory
there's
just
a
sim
link
back
to
the
directory
of
the
module
and
lerna
when
you
run
compile,
will
run
them
in
dependency
order.
So
it
compiles
your
dependencies
before
it
compiles
you
and
then
versions
are
actually
updated,
using
a
learn,
a
command.
So
it's
like
learn
a
version
minor
or
whatever,
and
then
it
updates
the
version
within
the
module.
B
But
then
it
also
updates
the
dependencies
of
the
of
its
dependent
modules
in
the
package.
Json,
that's
gotcha
that
this
is
essentially
the
problem
that
lerno
was
designed
to
solve.
C
B
No,
it
references
the
version
number
of
the
working.
You
know,
git
version
and
lerna
will,
instead
of
installing
from
npm,
we'll
just
link
the
local
one
cool
okay.
So
then,
if
you
make
a
change
within
the
instrumentation
that
requires
a
update
in
the
example,
it
would
actually
just
break
the
build
locally
and
in
the
ci,
and
you
would
need
to
update
the
example
to
get
that
pr
merged,
which
I
think
is
the
end
goal.
Anyways
perfect
cool.