►
From YouTube: 2021-08-11 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
C
C
C
A
D
D
Okay,
I
think
we
can
probably
get
started.
Let
me
try
my
screen
here.
D
All
right,
so
the
first
thing
is:
we
merged
the
package
renaming
that
we
talked
about
last
week.
There
hasn't
been
a
release
yet,
but
I'm
going
to
try
to
make
that
release
pr
today.
D
So
just
so
everybody
knows
that's
coming,
there's
been
a
handful
of
the
the
core
sdk
packages
that
were
renamed
I'm
going
to
try
to
make
the
release.
Today
I
was
going
to
try
to
test
the
release,
please
workflow,
but
the
action
has
been
queued
for
a
while
and
does
not
seem
to
want
to
run.
D
D
The
idea
here
is
that
as
the
contrib
grows
and
we
have
a
lot
of
packages,
it
will
be
difficult
for
the
core
maintainers
to
maintain
them
all
and
to
mitigate
that
we're
assigning
ownership
to
those
that
contribute
a
package
right
now.
The
aws
packages
are
the
only
ones
that
have
owners
and
the
one
alibaba
package,
but
my
hope
is
that
this
will
grow
as
people
claim
ownership
of
the
packages
that
they
have
already
contributed,
and
I
think
we're
probably
going
to
require
ownership
for
new
packages
in
the
future.
D
D
Once
they
approve
it,
then
it
will
be
merged.
So
the
maintainers
and
the
regular
approvers
can
still
approve
and
merge
prs
if
the
if
the
owners
are
taking
a
long
time.
If
something
has
been
sitting
around
for
a
week
or
two
weeks
and
looks
like
it's
not
going
to
be
reviewed,
then
the
pr
heard
that
the
maintainers
will
probably
review
it
and
go
through
that
process.
But
if
you
want
something
merged
quickly
or
if
you
want
something
rejected
as
an
owner,
you
will
have
control
over
that.
D
A
D
D
And
we'll
talk
about
release
in
a
second,
I
saw
that
amir
and
will
added
a
few
questions
in
here.
So
I'll.
Let
you
guys
talk
about
the
questions
that
you
have
and
we
can
hopefully
address
some
of
them,
but
before
we
do
that,
does
anyone
have
any
questions
about
what
this
ownership
means
or
concerns
about
this.
D
Okay,
if
not,
then
I'll,
let
either
will
or
amir
take
it
away
here
with
with
this
next
item,.
A
Hi,
so
a
bit
of
a
background,
if
you
don't
know
we
at
a
spectro,
we
maintain
a
repository
with
about
10
instrumentations
and
we
decided
to
have
it
in
a
separate
repo
because
we
needed
a
velocity
like
the
time
from
the
time
frame
when
we
introduced
new
code
until
it's
released,
at
least
in
the
contributes
to
be
very
long,
and
we
needed
to
move
very
fast
and
they
had
the
fixes
and
features
very
fast.
A
So
those
instrumentations
been
sitting
there
for
like
a
year
and
a
half
but
will
from
aws,
approached
us
and
asked
if
it's
possible
to
upstream
it
to
the
country
repo
and
along
with
the
changes
that
daniel
mentioned.
We
think
that
now
it's
a
it's
a
good
time
to
move
those
instrumentations
to
the
contrib.
A
So
we
have
a
few
questions
about
the
process.
I
know
it's
an
it's
a
new
process
and
like
maybe
some
of
the
questions
are
not
the
dancer
is
still
not
clear,
or
we
still
need
to
discuss
or
see
how
it
goes.
A
It
can't
be
in
minutes,
but
I
think
we
can
live
with
a
few
days,
but
I
just
want
to
review
the
process
and
make
sure
that
I
understand
it
correctly
and
if
someone
has
other
opinions
or
so
it's
a
it's
a
good
opportunity
to
discuss
so
regarding
the
requirements
for
for
approvals.
So
as
far
as
I
understand,
if,
if
there's
instrumentation
with
a
component
owner,
we
need
a
just
a
single
approve
from
a
component
owner
and
then
the
pr
can
be
merged
right.
E
D
Was
my,
I
guess
assumption,
I
think
that
that
will
probably
work
for
most
people.
I
I
talked
to
will
about
that
initially
and
he
seemed
happy
with
that
also
and
if
we
need
to
change
that
in
the
future.
To
you
know,
if
some
package
authors
want
to
come
in
and
say
no,
we
need
two
people
to
approve
it.
We
can
talk
about
how
the
the
workflow
can
be
updated,
but
for
now
I
think
one
component
owner
approval
is
fine.
D
So
I
guess
no,
it
is,
is
my
assumption.
D
If
the
approver
or
if
the
owner
approves
it,
even
if
they're
the
only
one,
then
I
think
it
can
be
managed,
even
if
the
reason
we
had
multiple
approvers
before
was
because
we
have
a
large,
you
know
some
number
of
approvers
who
are
not
intimately
familiar
with
any
one
given
package
and
may
not
have
written
it.
So
it's
difficult
for
them
to
review
it
so
just
to
make
sure
that
things
don't
slip
through
the
cracks.
A
Okay,
cool
and
there's
a
question
here
that
we
wrote,
but
I
already
saw
the
answer
above
like
so
component
owner,
doesn't
have
to
be
approval
in
the
repo.
He
only
has
to
be
a
member
of
the
open,
telemetry
organization.
D
Yeah,
that's
actually
the
reason
that
I
made
it
as
a
separate
github
action.
Otherwise
we
would
have
been
able
to
just
use
the
code
owner's
file,
but
when
you
make
someone
an
approver,
they
get
right
access
to
the
repo
and
we
did.
We
wanted
to
avoid,
having
potentially
hundreds
of
people
with
right
access
to
the
repo.
D
A
I
see
okay
and
once
the
once
the
pr
is
approved
by
a
component
owner.
Then
it
needs
to
be
merged
into
a
main
by
a
maintainer
right,
and
that
would
happen
very
like
in
a
matter
of
hours
or
at
least
a
day
or
two.
D
I
would
think
hours
would
be
what
we
would
hopefully
expect,
and
I
guess
we
do
need
to
decide
whether
that
needs
to
be
a
maintainer
or
whether
it
can
be
a
regular
approver.
D
So
if
an
approver
is
looking
through
contrib
and
sees
you
know,
amir
has
approved
this
pr
and
he's
the
owner
should
have,
should
an
approver
be
able
to
merge
it
or
do
we
want
to
wait
on
maintainers
for
that.
D
In
general,
or
what
would
that
be
like
approvers
can
merge
prs
today
I
mean
they,
they
definitely
have
the
literal.
Like
permission.
The
button
is
clickable
and
things
like
that.
I
know
that
in
most
of
the
sigs
maintainers
merge
all
of
the
prs.
F
Yeah
we
also
talked
about
adding
a
a
label,
as
it
says
in
the
question,
and
we
kind
of
talked
about
offline
dan
about
you
know.
If
agent
owner
that
wasn't
the
author
of
the
pr
approves
it,
then
they
can
get
that
label
just
for
easier
triaging
and
merging
of
maintainers
of
approver
and
approvers
should
kind
of
go
through
all
the
labeled
issues.
G
Really
sorry
to
interrupt
you,
it's
hard
to
understand
you
you're
far
away
from
me
microphone
or
something.
D
I
I
think
I
understand
what
you're
saying
so.
I've
been
actually
working
on
the
the
action
this
morning
trying
to
make
it
a
little
bit
more
full-featured.
One
thing
that
I
was
doing
was
making
it
so
that
the
dependable
prs
will
be
ignored
so
that
people
won't
be
spammed
by
all
the
dependency
updates,
but
also,
I
think
there
will
be
a
few
different
labels.
One
will
be
like
approved
by
owner.
D
G
A
And
regarding
the
releases
so
understand
that
release,
please
will
create
a
pr
which,
which
is
a
one
pl
for
the
entire
repo
and
then
once
this
pr
is
merged
and
all
the
instrumentations
or
packages
that
have
changes
will
be
released
right.
A
D
That's
the
idea
and
they
will
follow
their
own
independent
versioning.
So
if
you
make
a
change
to
the
mysql
instrumentation
and
merge
it
and
then
merge
the
release,
only
that
one
would
have
a
version
change
and
only
that
would
be
released
and
it
will
follow
the
conventional
commit
specification
to
determine
whether
it's
a
minor,
major
or
patch
version
of
data.
A
D
So
we
have
a
few
options
on
that
I
mean
we
can
have
it
automatically
release
every
time.
I
think
before
we
do
that
we
want
to
do
it
manually
a
few
times
just
to
make
sure
that
the
it's
working
and
things
like
that,
but
I
would
say
I
will
probably
look
to
merge
it
at
the
very
least
once
a
week,
but
I
would
try
to
do
it
at
the
end
of
the
day
each
day,
if
possible,
assuming
there's
no
problems.
A
Good
like
it,
it
means
that
there's
no
like
if
something
is
merged.
It
really
is
it's
been
released
very
soon,
afterwards,
yeah
yeah,
that's
the
hope,
amazing,
okay
and
then
there's
another
issue.
It's
a
technical
issue.
Currently
our
instrumentations,
we
use
a
package
called
the
test,
all
versions
where
you
have
a
config
file
and
you
can
configure
a
range
of
versions
and
the
npm
command
npm
script,
and
then
you
will
run
the
tests
on
all
the
supported
versions.
A
So,
for
example,
if
we
stated
we
support
all
versions
above
2.3,
then
we
run
the
tests
on
all
of
those
versions
to
make
sure
they
all
pass.
So
this
this
workflow
was,
is
very
successful.
We
managed
to
find
a
lot
of
issues.
For
example,
if
someone
is
creating
a
change
in
pr,
and
this
change
is,
is
breaking
some
old
version,
which
is
not
the
latest,
but
it's
still
a
claim
to
be
supported,
but
once
the
pr
is
introduced
it's
not
supported
anymore.
A
Then
we
can
find
that
we
that
it's
not
supported
by
running
this
test
or
version,
and
so
I
wanted
to
ask:
what's
your
opinion
about
adding
it
at
least
to
the
instrumentations
that
we're
adding
if
the
the
one
problem
is
that
it
makes
the
test
runs
a
lot
longer
like
it
can
take
up
to.
A
A
A
D
So
it's
technically
I'm
sure,
not
a
problem.
We
do
have
a
couple
of
restrictions
like
we
would
have
to
make
sure
that
the
license
of
whatever
you're
using
for
that
is
approved
by
the
cncf.
But
if
it's
like,
apache
or
mit,
or
anything
like
that,
I'm
sure
it'll
be
fine.
D
We've
had
complaints
from
other
cigs
about
the
q
depth
for
running
actions.
We
share
it
with
the
entire
org,
with
all
of
the
other
sigs.
Also
we
share,
like
one
account.
The
one
paid
github
actions
account,
which
has
a
limited
number
of
concurrent
runners
and
things
like
that
and
the
js
sig
is
already
a
very
heavy
user
of
it,
since
we
test
back
a
bunch
of
node
versions
and
things
like
that
and
some
of
our
tests
are
pretty
slow.
D
D
So
as
an
alternative,
I
would
say
you
could
definitely
add,
like
you,
can
add
the
script
and
have
it
not
automatically
run
as
the
ci,
but
then,
as
part
of
your
approval
process,
run
it
locally
on
your
machine
or
something
like
that.
Would
that
be
a
decent
alternative,
or
is
that
too
cumbersome
for
you
or
I
don't
know
if
it's.
D
Like
if,
if
we
could
run
them
in
a
circle,
ci
account
that
that
especto
hosts
or
something
like
that
I
would
be.
I
would
be
open
to
that
if
the
tc
would
allow
us
to
do
something
like
that.
So
I
I
would,
I
would
merge
like
a
circle
config.
D
That
would
run
them
in
in
something
that
you
that
you
host
the
cncf
doesn't
pay
for
circle
anymore,
so
we
probably
wouldn't
be
able
to
host
it,
and
I
don't
think
you
can
have
external
github
actions
accounts,
but
I
know
you
can
have
posted
runners
so
there
there
are
some
mitigation
strategies
that
we
can
look
into,
but
I
don't
have
enough.
D
I
don't
have
enough
authority
or
context
to
say.
Yes,
we
could
definitely
do
something,
but
I'm
I'm
happy
to
help
you
look
into
it
and
figure
out
who
are
the
correct
people
to
ask
about
things
like
that.
F
What
about
like
a
nightly
run
for
the
test?
All
versions
like
like
a
20
minute
run
once
at
like
a
later
time
of
night,
when,
hopefully
there'll
be
less
ci
activity.
D
B
Sorry,
I
think
there
is
a
actually
like
a
growing
and
a
bigger
a
problem,
that's
already
bigger
than
what
we
are
discussing
and
the
one
that's
also
growing,
which
is.
We
are
adding
packages
to
the
country
repo
and
we
are
running
tests
for
all
the
packages
every
time
and
that
that,
if
I'm
correct-
and
that's
just
you
know
unbounded
to
to
grow,
maybe
we
should
do
something
about
it
instead
and
thus
bring
the
time
we
use
for
ci
down
significantly.
D
Yeah,
that's
that's
fine.
We
can
definitely
do
that,
but
I
think
any
any
package
that
gets
regularly
updated
and
has
20
minute
tests
is
somewhat
likely
to
have
other
sigs
annoyed
at
us
for
the
for
the
action
key
time.
D
So
I
do
think
that
we
should
only
run
for
changed
packages,
at
least
in
contrib,
because
they're
all
pre-independent
of
each
other.
D
I
don't
know
how
feasible
that
is
necessarily
in
core,
because
if
we
make
a
change
in
the
core
packet
in
in
one
core
package,
it
can
change
the
behavior
in
many
other
packages
because
they
depend
on
each
other,
and
I
know
that
there
are
ways
to
filter
by
dependent
packages
and
stuff
like
that.
So
it's
certainly
something
that
I'm
willing
to
look
into.
A
A
D
Let's
look
into
so
that
would
be
fine
if
you're
only
extending
the
test
time
by
a
couple
of
minutes.
I
think
it's
probably
not
a
problem,
especially
if
we
only
test
change
packages,
so
it
only
runs
when,
when
your
packages
change,
I
think
those
two
combined
would
be
would
be
probably
fine,
but
I
would
like
to
say
you
can
test
as
many
versions
as
you
want.
D
So
I
I
think,
if
you,
if
you
want
to
test
more
versions,
we
should
at
least
try
to
find
a
way
to
to
see
if
that's
possible,
like
I
said
with
potentially
an
externally,
hosted,
circleci
account
or
something
along
those
lines.
F
G
Right
but
but
basically
it
would
be
that
it
will
be
around
once
per
per
per
day,
something
like
this
maximum,
so
you
basically
make
pr,
and
after
the
next
day
you
see.
Okay,
all
the
tests
pass
it.
So
you
approve
the
changes
down
so
yeah.
F
A
G
D
Yeah
I
mean
there
is
a
a
significant
time
when
most
of
our
regular
contributors
at
least
are
not
working,
that
we
could
probably
utilize.
F
A
It
doesn't
really
matter
when
just
to
have
it
regularly
running,
so
we
can
catch
issues
if
we,
if,
if
they
exist
before
they
reach
customers
yeah,
because
we
had
an
issue
with
aws
sdk,
there
was
a
new
version
published
and
it
was
not
working
with
our
instrumentation,
and
so
it's
it
was
throwing
an
exception
and
crashing
the
code,
and
we
didn't
know
about
it
until
somebody
complained.
A
So
then
we
started
running
it
every
night,
just
to
make
sure
that
the
the
tests
pass.
Even
if
new
versions
of
the
instrumented
packages
are
released
and
we
did
catch
a
few
issues
with
those
daily
test
runs.
So
at
least
for
us,
it's
a
very
successful
workflow
that
we
would
like
to
maintain
in
the
country
as
well.
D
Yeah,
I
definitely
see
the
value
in
it
and
I
I
would
like
to
be
able
to
continue
doing
that
for
now.
I
think
we
can't
make
any
solid
decisions
on
it,
but
I
I
can
work
with
you.
You
know
on
slack,
to
try
to
figure
out
who
are
the
right
people
to
contact
to
figure
out
what
is
an
acceptable
load
on
rci
and
then
what
we
can
do
to
stay
underneath
those
limits.
A
Okay,
cool
amazing.
So
that's
all
I
have
to
say
I
think
we'll
start
migrating.
The
aws
sdk
instrumentation
in
the
following
days.
D
Yeah,
okay,
so
why
don't
you
look
into
that?
And
I
will
contact
the
tc
and
find
out
what
the
what
our
limits
actually
are
and
what
is
the
sort
of
acceptable
limit
for
a
single
sig
and
whether
the
cncf
would
have
any
problem
with
us
running
tests
in
an
environment
hosted
by
an
external
company,
because
you
know
the
cncf
may
say
no
to
that.
Also.
D
F
D
Okay,
so
we
did
merge
the
the
release.
Please
integration
in
the
api
package.
We
haven't
made
any
changes
since
then,
so
there
is
now.
I
would
show
you
what
the
release
pr's
look
like,
but
we
haven't
made
any
changes,
so
there
are
none.
D
Also
a
couple
of
people
have
already
approved
it,
but
I
would
like
you
know
as
many
people
as
possible
to
get
their
eyes
on
this,
since
this
is
a
pretty
important
subject,
I
don't
want
to
merge
it
with
only
a
couple
of
reviews,
so
I'd
like
to
have
as
many
people
look
at
it
as
possible
and
it's
fine
if
you're,
if
you're
not,
you
know
completely
sure
about
everything,
but
I'm
looking
for
the
more
eyeballs
we
get
on
it,
the
more
likely
we
are
that
somebody
finds
some
issue
with
the
process.
G
D
D
Okay,
well,
there's
some
problem
with
it.
So
I
guess
I
have
to
look
into
that,
but
hopefully,
by
the
end
of
the
day,
I'll
have
this
working
and
I'd
like
to
to
get
that
merged
in
and
once
that's
done,
I'll
move
that
over
to
contrib,
also
because
that's
an
important
part
of
getting
releases
out
quickly.
D
D
Okay,
then
I
guess
I
will
talk
to
everybody
next
week
and
amir
I'll
talk
to
you
on
slack,
so
we
can
figure
out
the
ci
issues.
Okay,
all
right!
Thank
you.
Everybody.