►
From YouTube: 2021-08-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
B
A
E
First
thing
is
short.
I
just
wanted
to
say:
welcome
to
amir
bloom
to
approvers
he's
been
already
very
active.
We've
been
really
happy
with
the
work
that
he's
been
doing
so
welcome
to
the
team.
F
Valentine
do
you
want
to
talk
about
this
next
item
here
yeah.
I
think
I
think
it
will
really
short
too.
It's
just
the
the
pr
that
I've
been
open
for
few
weeks
now
about
the
renaming
of
the
sdk.
I
believe
it's
the
only
big
thing
that
we
needed
to
to
be
able
to
release
drc
for
the
sdk
so
yeah
we
we
already
approved,
I
mean
daniel
and
sorry.
I
forgot
your
name,
I'm
really
tired,
alright
yeah,
but
yeah
yeah,
but
sorry
so
yeah.
F
We
are
really
approved
between
containers.
So
if,
if
people
want
to
to
verify
that
it's
correct,
it
would
be
really
helpful
because
there's
a
lot
of
change
and
we
might
have
missed
something
so
yeah.
If
you
have
time
it
will
be
good.
E
E
There's
a
lot
of
changes
and
basically
it
touches
everything.
So
if
we
merge
any
pr's
before
this
merges,
there
will
be
conflicts,
so
we're
hoping
not
to
do
that.
So
this
is
high
priority.
B
Yeah
sure,
going
through
the
issues
on
one
of
the
repos
I
I
kind
of
figured
there
is
many
that
are
really
old
and
probably
out
of
date
and
like
even
the
reported
people,
probably
don't
care
that
much
or
in
many
cases
they
don't
care
that
much
anymore.
B
So
it
would
be
worth
for
the
jean
of
the
project
to
actually
start
closing
them
after
them
being
open
for
a
certain
amount
of
time
like
thinking
that
they
are
not
relevant
or
you
know
no
one's
actually
interested
in
dealing
with
those,
even
if
they
are
relevant.
Sometimes
it's.
We
can
always
reopen
the
issue.
So
so
I
was
wondering
what
shall
it
take
to
set
up
something
like
a
bot
that
causes
old
issues
or
stale
issues
or
prs.
E
I
have
nothing
against
this.
I
know
it's
something
we've
talked
about
in
the
past
and
have
sort
of
decided
not
to
do.
But,
honestly,
I
don't
remember
the
conversations
we
had
that.
Well,
I
don't
remember
if
anyone
felt
that
strongly
about
it
or
if
it
just
fell
through
the
cracks
or
something
like
that,
I
have
no
problem
with
it,
but
does
anyone
else
have
problems
with
this.
E
Well,
one
of
the
one
of
the
issues
is
that
sometimes
just
because
an
issue
has
been
open
for
a
long
time
doesn't
mean
it's
not
relevant
but
yeah
like
you
said
when
something's
been
open
for
months,
sometimes,
even
if
it
is
relevant,
it
just
means
nobody's
working
on
it
and
it
can
always
be
reopened.
B
Yep
agreed:
do
you
have
any
recommendations?
How
we
could
you
know
step
forward
with
this
or.
E
The
github
stale
bot
is
that
different
than
the.
C
E
E
Yeah,
I
wonder
if
they
stopped
using
it,
we
should
probably
do
you
know
whatever
the
spec
is
doing.
E
E
B
Delete
branch-
well,
it's
just
like
I
skimmed
over
the
options
and
I
just
whatever
stood
out.
I
just
put
down
as
I'm
like
a
short
note.
It's
it's
nothing
that
I'm
you
know
really
strict
to
it
or
or
there.
The
options
I
brought
out
are
nothing
special,
but
it's
just
just
something
that
stood
out
for
me
and
the.
A
B
Does
it
delete
the
branch,
then?
Yes,
it
does
if
the
vr
is
closed,
but
again,
just
like
with
the
opening
the
issues
and
pr's
you
can
like
bring
the
deleted
branch
back
as
well,
but
it
doesn't
list
when
you
are
pulling
the
repo
it
doesn't
list
there
anymore,
which
is
useful,
especially
for
for
vrs
that
are
already
closed.
E
E
E
But
would
you
be
willing
to
open
an
issue
for
this
and
you
know
sort
of
summarize
the
differences
between
the
two
and
make
a
recommendation
for
us.
B
Guess
separately.
B
A
Yeah
really
sorry
to
interrupt
you.
But
it
looks
like
you're
far
away
from
the
microphone,
because
it's
yeah.
D
Talk
loudly
so
is
there,
I
guess
my
first
question
is:
I
know
that
we
discussed
previously,
but
is
the
instrumentation
api
going
to
be
included
in
the
1.0
release
of
the
sdk.
E
D
No,
no
okay,
and
so
then
I
guess
I
was
wondering,
as
far
as
other
components
that
are
not
instrumentations
in
the
contrib
repo
I
listed
just
like
the
learning,
independent
versioning
and
potentially
adding
code
owners
like
we
had
discussed
previously,
as
kind
of
like
the
things
that
would
be
blockers
for
bringing
them
to
1.0
is.
Does
that
sound,
correct
and
things
that
that
we'd
be
able
to
contribute
to
get
those
components
to
1.0
after
the
stk?
E
E
But
we'll
talk
about
that
in
a
minute.
So
yes,
that
definitely
does
need
to
be
done.
E
Yet
because,
if
we
want
to
say
we'll
accept
almost
anything
and
contrib
and
whoever
contributes
it
is
responsible
for
maintaining
it,
we
would
either
have
to
add
all
of
those
people,
as
you
know,
give
them
right.
Access
on
the
contrib
repo,
which
is
obviously
not
ideal
or
code
owners,
will
not
be
able
to
apply,
which
is
also
not
ideal.
So
I'm
not
entirely
sure
what
we
can
do.
We
may
be
able
to
set
up
a
github
action
to
automatically
assign
people.
E
You
know.
Maybe
we
can
put
like
an
ownership.txt
file
in
the
root
of
each
package
or
something
like
that
and
automatically
assign
using
a
github
action
or
something
along
those
lines,
but
the
code
owner's
file
is
not
going
to
work.
Unfortunately,.
D
Right,
okay,
yeah!
I
I
knew
the
right
limitation
so
yeah.
I
guess
I
was
just
going
to
see
if
there
was
any
updates
on
that
or
undo
stance
so
yeah,
but
that
makes
sense
yeah
with
with
components.
E
At
like
zero
dot,
whatever,
I
think,
I'm
fine
with
with
the
current
status
quo,
not
because
I
like
it,
but
because
it's
what
we
have
and
it's
too
late
to
to
say
no,
but
I
think
in
order
for
any
component
to
go
to
1.0,
I
want
to
require
a
person
to
stand
up
and
say
I
will
be
responsible
for
this.
D
Got
it
okay,
yeah,
I
yeah,
obviously,
there's
no
straightforward
solution
to
that
other
than
an
ad
hoc
basis,
kind
of
for
the
first
few
components
but
like
I
guess,
if,
like
a
propagator
component,
for
instance,
like
did,
have
defined
owners
and
the
sdk
went
to
1.0,
then
would
it
be
valid
to
to
elevate
the
owned
contrib
component
to
1.0
as
well.
E
D
Cool
and
just
one
last
question:
what
what
is
the
blocker
on
the
instrumentation
1.0?
Is
it
still
the
otep
for
the
instrumentation
api
or
something
else?
It's
the
stability.
E
Guarantee
of
the
generated
telemetry
so
that
it's
obvious
at
least
it's
obvious
to
me-
I
don't
think
it
was
even
like
everybody
necessarily
agrees
with
this.
But
if
you
change
a
required
key
or
a
required
attribute
key,
that's
a
breaking
change,
less
obvious
than
that
is
what
happens
if
you
change
the
values
like
the
possible
values
or
something
along
those
lines.
Is
that
considered
a
breaking
change
or
not?
E
And
I
don't
think
any
policies
around
those
have
been
solidified,
okay,
cool
so
until
we
can
determine
what
will
we
guarantee
in
a
stable
version
release?
You
know,
if
you,
if
you
install
1.0,
we
should
be
able
to
explicitly
document.
These
are
the
things
that
will
definitely
not
change.
Unless
we
go
to
2.0.
A
With
regards
to
the
api
for
instrumentation,
there
is
open
pr
which
basically
tries
to
create
some
specification
around
the
instrumentation
api.
D
Right,
yeah,
so
that
that
one
was
opened
by
honorable.
I
I
think-
and
I
I
don't
know
if
that's
is,
that
directly
related
to
the
like
semantic
convention,
stability,
or
is
it
just
like
a
uniform
way
to
create
instrumentations?
D
D
E
E
E
I
forget
who
I
then
maybe,
but
essentially
it
is
a
purpose
built
for
what
we
were
just
talking
about:
releasing
individual
components.
E
It
will
in
the
api,
since
there's
only
one
package-
that's
kind
of
it,
but
in
the
sdk
repository
it
will
only
release
components
which
have
been
changed
and
it
will
update
their
versions
based
on
the
conventional
commit
specification,
so
any
commit
that
has
the
fixed
prefix
will
cause
a
patch
version
change
any
commit
that
has
the
feet.
E
Prefix
will
cause
a
minor
version
change
and
an
exclamation
point
or
a
breaking
change.
Footer
will
cause
a
major
version
change.
E
A
E
Anything
with
chore
will
not
cause
a
version
change,
so
we
we
use
chore
for
a
lot
of
things
now,
but
we
should
probably
get
better
about
using
feet
and
fix
where
it
makes
sense,
because
chores
should
be
things
like
documentation
and
things
like
that.
That
don't
require
version
changes.
E
E
The
reason
for
that
is
that
the
release
please
action
is
not
able
to
update
the
version
ts
files,
it
modifies
the
package
json
directly
and
does
not
run
like
the
npm
version
command,
which
means
the
the
post
version
script
that
we
use
to
update
those
ts.
Files
does
not
get
run
so
that's
worth
keeping
in
mind.
E
D
So
would
the
would
the
tool
update
like
dependencies
when
they're
upgraded
so
like
when
the
core
sdk
is
updated
with
the
other
packages
which
depend
on
the
core
sdk
also
have
that
version
automatically
updated?
Yes,.
E
But
yeah
it
uses
it
actually
uses
learner
to
build
its
own
dependency
tree
for
that.
So
yes,
the
plugin
for
that
is
documented
at
the
bottom,
but
it's
called
the
node
workspace
plugin.
E
Well,
right
now
it's
the
core
repo.
I
will
also
do
it
for
contrib,
but
I
want
to
make
sure
that
I
want
it
to
be
reviewed
only
in
one
place.
I
don't
want
to
open
two
pr's
and
have
to
make
all
every
change
twice
when
people
have
questions
and
concerns,
and
things
like
that.
E
The
other
thing
is
that
if
you
look
at
the
action
itself
right
now,
it
doesn't
have
any
automatic
publishing,
so
it
will
create
the
release,
but
will
still
require
a
maintainer
to
go
manually,
check
out
the
tag
and
publish
it.
E
E
So
I
know
that
people
probably
don't
have
much
to
say
about
it
right
immediately,
because
it's
a
big
change
and
I'll
give
you
guys
time
to
to
read
it
and
comment
offline,
but
I
I
believe
that
this
is
probably
the
right
way
to
go.
Unless
people
have
concerns
about
it.
E
E
E
It
will
update
to
use
4318,
but
hasn't
done
that
yet,
and
it
will
support
both
for
some
time,
and
I
think
that
we
should
wait
until
the
collector
changes
its
default
port
before
we
merge
this
pr.
But
beyond
that,
it
is
ready
to
be
reviewed.
G
Hey,
I
commented
on
the
bottom
that
the
collector
already
merged
the
pr
to
update
to
the
next
port,
but
obviously
it's
not
released.
Yet.
However,
they
do
what
seems
like
monthly
releases,
so
probably
one
by
this
week,
but
as
I
mentioned,
if
we
really
wanted
to
be
safe,
we
can
stay
with
five
five,
six,
eight
one
for
a
bit
while
they
support
both
of
them
and
then
you
know
make
the
switch
once
I
guess.
A
few
versions
have
passed
so
that
it
doesn't
break
people
as
badly.
A
E
Six,
eight
one
in
the
repo
there's
a
lot
of
results,
so
I
agree
it
needs
to
be
updated.
E
That
is
all
we
had
on
the
agenda
for
the
day.
The
the
important
one
is
the
sdk
renamed.
Please
take
a
look
at
it.
I
am
going
to
merge
this
before
the
end
of
the
day,
unless
somebody
gives
me
a
good
reason
why
I
should
not.