►
From YouTube: 2021-09-01 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
I
hope
that
bart
joins
the
call
today,
because.
D
C
Okay,
so
I
tried
to
make
this
agenda
item
as
as
explicit
as
I
could
and
detailed,
but
the
short
version
is
that
the
release,
please
automation,
that
we've
added
may
not
work
for
the
core
repo
it,
I
think,
still
will
probably
work
for
contrib,
but
in
core
we
have,
I
guess,
different
requirements
that
release.
Please
doesn't
really
support.
C
Another
issue
is
that
it
will
allow
the
versions
to
drift
apart
from
each
other
which,
in
the
sdk,
I
think
we
want
to
keep
them
locked
together,
if
at
all
possible.
Is
that
before
I
move
on?
Is
that
clear
to
everyone?
What
what
the
issue
is,
or
is
anyone
confused
by
that.
E
C
D
It's
not
will
what
were
you
gonna
say.
D
C
Essentially,
we
want
all
of
these
stable
sdk
packages
to
have
the
same
version
at
least
the
same
major
and
minor
so
like
the
tracing
package
and
the
otlp
exporter
and
the
core
package,
and
everything
should
all
have
like
1.0,
together
or
1.1
together
and
then
all
of
the
experimental
modules,
I
think,
should
also
keep
the
same
minor
version
just
to
make
it
easier
to
maintain
the
repositories
so
they'll
all
be
zeroed
at
26
and
then
they'll
all
be
zeroed
at
27..
C
So
you're
right,
metrics
is
one
of
those
instrumentation
is
another.
That's
not
going
to
1.0.
I
can
add
metrics
here
just
to
make
that
more
clear.
I
guess.
C
So
my
proposed
solution
is
to
essentially
treat
this
as
two
learner.
Evos
one
will
contain
all
of
the
1.0
or
stable
packages,
and
then
another
one
will
be
nested
inside
the
repository
as
an
experimental
directory
with
its
own
learner.json,
its
own
changelog
file
and
its
own
set
of
packages.
C
I've
been
experimenting
with
this
locally
on
my
machine
and
it
seems
to
work.
Lerna
doesn't
seem
to
mind
having
a
nested
monorepo,
you
know
it.
It
just
treats
it
as
some
directory
that
it
doesn't
have
control
over
just
like
it
would
any
other
directory
that
that
it's
not
managing
and
when
you're
you
know
seeded
into
the
experimental
directory.
C
It
just
thinks
of
it
as
that's
the
the
mono
repo.
It
doesn't
look
into
the
root
or
anything
like
that.
So
it
seems
to
work,
but
I
am
hoping
to
get
people's
thoughts
here.
I
don't
know
if
anyone
has
used
release
please
before
and
has
a
way
to
solve
the
problem
without
doing
this
by
still
using
release,
please
or
if
somebody
knows
of
a
different
release,
automation
tool
that
we
could
use
that
would
handle
that
for
us
or
do
people
think
that
this
is
a
reasonable
solution.
C
I'd
like
to
solve
this
sort
of
as
quickly
as
possible,
because
we've
been
trying
to
release
the
1.0
now
for
weeks
and
to
have
the
the
release
tooling
being
the
thing
that
holds
it
up
is
quite
frustrating.
F
Well,
I
don't
know
about
release,
please
I
never
use
it
before,
but
could
we
just
like
have
two
different
learner
configuration
and
different
packaged
lists
inside
them
and
avoid
having
like
a
dedicated
folder
for
for
experimental
stuff
like
we
can
still
use
the
package
like?
It
is
the
layout
that
is
today,
but
just
having
two
different
lana
definition.
Could
we
do
this.
B
C
Seem
to
that
that
was
my
first
thought
was
to
just
have
two
leno
files,
but
it
doesn't
seem
to
allow
you
to
specify
a
specific
learner.json.
It
only
looks
for
a
file
name
to
learn
about
json,
so
we
would
have
to
rename
the
file
or
something
like
that
before
running
commands.
C
That
would
be
possible,
but
I
just
think
I
settled
on
the
experimental
directory
just
because
I
thought
it
was
slightly
easier.
You
know
to
to
not
have
to
deal
with
renaming
files
before
running
commands
in
the
ci
and
stuff,
like
that.
F
C
F
Well,
I
think,
there's
a
oscillations
have
trade
off.
I
think
I
would
prefer
I
personally
need
to
have
like
three
different
learner
json,
so
we
keep
the
current
layouts.
So
it's
keep.
It's
stay
consistent
with
the
country
people,
but
I
don't
actually
I'm
not
against
using
an
experiment
objective
if
it's
easier.
G
Could
we
keep
everything
else
the
same
and
just
create
like
core
under
the
packages
which
is
actually
excluded
from
the
root
learner.json,
but
includes
all
the
packages
that
have
to
be
versioned
the
same
so
still
nested,
but
not
using
the
experimental
folder
for
everything
else,
but
leaving
everything
else?
The
same.
Does
that
make
any
sense.
C
H
But
we
can,
we
can
have
like
a
list
of
the
core
packages
and
the
experimental
packages
and
if
it
is
an
npm
script,.
C
C
It
would
we
would
just
have
to
make
sure
that
we
keep
that
list
up
to
date,
which
I
don't
think
is
necessarily
a
problem.
We
don't
add
packages
that
often
so
it's
not
like.
We
would
have
to
do
it
all
the
time
or
anything
like
that.
It
might
make
it
slightly.
C
C
C
E
So
I
just
dropped
the
links
in
the
chat
for
app
insights.
I
created
a
script
to
effectively
go
and
find
all
the
package
jasons
and
update
them
based
on
the
version
like
this
is
the
public
version.
I
I
have
an
internal
version
which
effectively
looks
at
the
path
and
excludes
based
on
path
this
one,
because
our
reactor
react
native
plugins
are
different
versions.
It
has
two
separators
for
those
but
yeah.
E
You
can
just
say
if
you
look
back
at
the
readme,
your
npm
run
said
version
patch
and
it
will
actually
find
all
the
package
jsons
and
update
them.
It
does
keep
a
version.json
local,
which
I
use
this
on
the
internal
version
for
optimizations,
because
we
embed
versions
in
our
ts
files,
so
our
internal
version
will
go
off
and
actually
find
version
numbers
embedded
in
ts
files
and
update
them
too.
I
don't
think
this
version
does
that
it
doesn't
do
release
notes
so
yeah.
E
C
Yeah,
I
mean
I'm
probably
okay,
with
still
using
learn
a
changelog
to
update
the
change
log.
That's
not
a
problem.
It's
been
working
for
us
just
fine.
C
C
I
assumed
nev
that
this
also
would
have
the
same
problem.
That
release.
Please
does
where,
if
you
update
the
version
of
core,
it
won't
change
like
the
the
trace
package
that
depends
on
por
right.
E
Probably
helped
about
meet
myself
before
I
talk
this
uses
fs
to
effectively
rummage
the
entire
repo
final
package
jsons
so
because
I
think
such
as
a
mono
repo,
it
just
updates
everything.
It
doesn't
update
external
dependency,
so.
C
So
I
guess
we
have.
We
have
four
suggested
solutions
here.
Does
anyone
feel
like
one
of
them
is
better
than
another
for
any
particular
reason,
or
I
think
one
is
too
complicated
or
what
problems
do
we
sue.
C
Okay,
I
agree,
it's
definitely
the
simplest
and
it
is
probably
the
lowest
barrier
to
try
it
and
if
it
doesn't
work,
we
haven't
dumped
that
much
work
into
it.
D
If
we
wanted
to
do
a
similar
pattern
and
contrib
of
having
stable
packages
versus
experimental
packages,
and
so
the
component
owner
for
contrib
packages
would
just
move
their
component
to
stable
once
it
was
ready.
C
I
think
for
contrib
we
should
probably
still
use
release
please
or
something
like
that,
because
in
contrib
packages
don't
depend
on
each
other,
there's
no
like
interdependent
modules.
So
it's
not
a
problem.
If
you
know
that
the
dependencies
aren't
updated
and
I
think
because
the
versions
are
gonna
drift,
a
little
bit
more
in
in
contrib,
using
a
tool
like
that
that
deals
with
that
will
help
us
to
release
more
quickly.
C
D
Yep
that
that's
actually
totally
fair,
that
makes
sense
for
independent
releases.
C
H
G
C
H
E
H
Like
like
we'll
test
it
with
a
different
version
of
what
it
will
actually
use,
eventually
in
production,
yeah,
so
yeah.
So
if
we.
H
In
core
and
changes
in
experimental,
and
then
we
release
only
experimental
when
it's
used
it's
going
to
use
an
older
version
of
core,
not
the
one
that
is
tested
against
in
the
in
the
same
branch.
I
hope
I'm
clear.
H
So
I
think
we
we
need
to
test
how
it
behaves
in
this
situation.
C
So
I
think
yeah
so
you're
saying
if
we
use
the
scope
solution
and
then
only
release
the
stable
packages
or
no
only
release
the
experimental
packages.
E
I
think
this
is
fundamentally
why
we
split
the
api
into
a
separate
repo
to
avoid
that
problem
right.
So
it's
not
an
easy
issue.
C
C
E
Does
owner
wire
up
the
package
json
dependencies
to
the
current
line
of
the
repo,
or
does
it
have
its
own
folder
for
each.
E
Okay,
so
app
inside
uses
rush
so
that
as
long
as
the
version
in
the
mono
repo
is
the
same
as
the
version
dependency,
it
actually
describes
a
steam
link
to
the
markets
that
are
built
from
their
invoice.
C
E
Suck
it
down
yeah.
Is
there
a
way
to
tell
a
learner
not
to
create
a
sim
link?
I
know
in
rush,
we
can
say
you
know
effectively,
don't
use
the
the
local
version,
always
fetch
the
the
published
version,
because
that
might
help
with
the
experimental
not
ideal,
because
it
blows
out
mode
modules,
but
it
will
stop
any
breaking
issues.
C
Yeah,
I
think
you
can.
I
don't
know
I
I
I
can't
say
with
certainty
that
you
can,
but
I
think
so.
E
A
Right
easier
to
keep
to
separate
files,
then
we're
not
stable
and
learn
experimental
because
then
it
for
sure
it
would
not
be
insulting
conversion.
At
all
I
mean
you
will
still
be
able
to
develop
this
locally,
just
make
small
change
and
and
that's
it
so
let
it
down
with
bootstrap
for
you.
If
you
need
to
make
a
change
and
test
it,
but
by
default
it
it
will
be
installed
from
the
npm.
C
C
What
about
the
api?
I
didn't
press
that
I
mean.
A
C
The
scope
solution
is
the
simplest
one,
but
I
think
there's
there's
just
too
much
risk
that
we
accidentally
release
some
change
in
an
experimental
package
that
depends
on
some
change
in
the
stable
packages
that
isn't
released
yet,
but
it's
definitely
simpler
than
than
this.
One.
G
Can
can
you
please
explain
the
main
difference?
I
understand
the
learner
files
are
located
in
different
places.
One
is
being
nested
inside
experimental,
the
other
one
is
on
the
root,
but
other
than
that.
C
G
G
C
I
mean
in
that
case,
maybe
we
should
consider
this
solution,
because
it
prevents
us
from
having
to
rename
the
the
files
in
the
ci
to
get
it
working.
We
just
change
directory
and
it
just
works.
H
H
H
J
Yeah,
so
for
this
multiple
learner.json
files,
would
you
still
use
release
please,
or
would
you
like,
how
would
the
release
automation
work.
C
No,
the
release,
automation
would
use
the
learn
aversion
command,
so
it
would
rename
it
to
release
the
experimental
version.
For
instance,
you
would
rename
learn
experimental
to
learn
a
dot
json
and
then
you
would
just
run
learn
a
version
miner
and
it
would
bump
the
minor
version
of
all
of
the
experimental
packages,
but
the
experimental
json
doesn't
contain
any
of
the
stable
packages,
so
they
would
be
left
alone.
J
J
I
feel
like
I'm
still
finding
broken
links
from
before
the
api
was
moved
to
a
separate
repo,
sometimes
just
because
we
have
like
across
the
open,
telemetry.io
website
and
and
a
few
other
places.
C
E
And
the
other
issue
would
be
virgin
history
like
if
we're
not
careful,
we'll
lose
history
when
we
move
it
from
experimental
back
to
stable
and
vice
versa.
So.
C
Yeah,
the
get
history
you're
saying
would
be
potentially
messed
up,
yeah
and
then
I
guess
speaking
of
links,
we
should
probably
not
discount
the
value
of
like
blog
posts
and
things
like
that
that
we
don't
control.
Those
links
will
never
be
updated,
and
if
we
move
the
packages
they
could
potentially
be
pointing.
You
know
we
could
break
a
bunch
of
those
links
which
could
be
frustrating
for
users
that
are
just
googling.
How
do
I
use
open
telemetry.
E
You
may
develop
something
that,
in
that,
in
your
experimental,
that's
using
unreleased
stable,
but
if
we
have
two
crons
that
that
actually
affect
you,
as
you
said,
for
the
release,
renames
learner,
experimental
to
the
learner
and
just
builds
it
using
the
release
stuff
that
will
hopefully
pick
it
up,
there's
always
a
chance
that
some
things
it
won't,
but
in
most
cases
that
should
pick
up
the
major
issues,
so
your
official
builds
will
fail,
but
your
local
documents
will
work.
E
C
Yeah
so
in
the
default
learner
json,
it
will
have
all
of
the
packages
in
that
packages
field
and
then,
in
the
experimental
we
will
have.
You
know
just
the
experimental
ones
listed
and
in
the
stable
one
we'll
have
just
the
stable
ones
listed,
probably
without
wild
cards
and
stuff
like
that.
J
Yeah,
so
so
one
other
question
I
have
is
so,
I
see
there's
some
instrumentation
in
the
open,
telemetry
js
repo,
like
a
few
things
that
probably
will
never
be
considered
like
part
of
the
sdk
right
do
eventually,
when
those
are
stabilized.
C
Obviously,
this
potential
solution
doesn't
necessarily
allow
for
that,
although
I
suppose
we
could
have
them
not
listed
in
either
the
experimental
or
the
stable
package,
and
only
listed
in
in
you
know
the
main
learner.json
and
allow
them
to
be
versioned
entirely
independently.
C
I
know
that
we
we
kept
there's
only.
I
think
three
there
might
be
four
instrumentations
in
the
main
repo
and
we
kept
them
there
because
we
deemed
them
as
like
high
value
or
you
know
whatever
you
want
to
call
it,
but
we're
definitely
in
a
much
more
mature
state
now
than
we
used
to
be.
G
C
J
C
I
suppose
we
should
have
that
conversation.
Let's
see
api
metrics
is
definitely
not
the
instrumentations
are
definitely
not.
J
Like
the
api
metrics
package,
so
basically
what
we're
doing
with
the
multiple
learner
json
files
is
making
multiple
separate,
mono
repos
and
if
basically
those
one
there's
like,
I
don't
know
five
instrumentations
in
the
api
metrics.
If
those
are
the
only
five
that
that
don't
like
fit
and
and
we're
saying,
potentially
we
could
move
them
out.
That's
another
option
too,
but
again
like
I,
I
value
the
links
a
lot
in
the
blog
post
and
stuff
like
that.
So.
C
I
think
for
now
keeping
them
in
the
same
repository.
C
Is
probably
what
we
should
do,
at
least
for
the
metrics
api
and
and
experimental
sdk?
The
the
instrument
and
the
instrumentation
base
would
stay
in
the
js
repo,
the
instrumentations
themselves.
Maybe
we
could
talk
about
moving
to
contrib
but
in
any
case
we're
going
to
have
to
have
a
set
of
experimental
packages
in
the
core
repo
anyways.
So
they
may
as
well
just
be
included
in
that
for
now,.
H
So
as
part
of
releasing
the
core
packages,
we
will
also
have
to
update
the
package.json
files
of
the
experimental
packages
somehow
right.
So
if
we
bump
the
version
currently
leona
is
taking
care
of
updating
all
the
dependencies,
but
since
learner
is
now
splitted,
we
will
have
to
do
it
in
some
other
way.
C
Yeah,
I
think
we'll
do
it
the
same
way
that
I
do
the
the
contrib
ones.
I
made
a
script
that
essentially
looks
in
the
monorepo,
finds
all
of
the
packages
and
then
updates
all
of
the
you
know.
It
looks
in
the
core
and
and
lists
all
of
the
packages,
and
then
it
goes
through
the
mono
repo
and
updates
the
versions
of
every
every
package
using
the
released
version
and
we'll
probably
just
do
the
same
thing.
H
C
C
I
think
you
know
we've
been
talking
about
this
for
a
while
now
are
there
other
suggested
solutions
that
anyone
think
of
anything
else,
or
should
we
should
we
go
with
at
this
point?
It
seems
like
we're,
leaning
towards
the
multiple
learn
adjacent
files.
C
Because
at
this
point
we're
talking
about
the
details
of
of
how
it's
implemented,
it
sounds
to
me,
like
we've,
pretty
much
reached
consensus,
that
this
is
the
the
way
to
go.
Though.
C
Okay,
I
don't
hear
anyone
saying
no,
I'm
gonna
pick
on
bart
and
valentine
and
make
you
say
yes
explicitly
since
you're,
both
maintainers
and
I
want
to.
I
just
want
to
make
sure
that
you're
that
you're,
okay.
A
C
Okay,
then,
I
will
try
to
make
a
pr
to
do
this
today.
It
shouldn't
be
that
big
of
a
change,
so
hopefully
it's
nice
and
easy
and
easy
to
review.
C
C
Beyond
that,
I
didn't
have
anything
else
on
the
schedule
today.
Is
there
anything
that
anybody
had
been
hoping
to
talk
about
at
today's
meeting.
D
Just
one
other
tangential
question
for
the
contrib
repo:
I
know
that
there
was
the
issue
with
release.
Please
and
the
automation
bot
being
blocked
by
the
cla
signing.
Has
that
been
resolved.
C
Yes,
so
the
cncf,
easy
cla
team
is
allowing
us
to
allow
list
certain
branches
to
be
exempted
from
the
there's.
There's
two
problems:
one
is
that
there's
a
branch
protection
rule
that
prevents
us
from
updating
any
branches
on
the
repo.
C
So
because
all
changes
must
go
through
the
pull
request
process,
but
in
order
for
a
release,
automation
to
create
a
pull
request,
it
needs
to
first
create
a
branch
and,
if
that's
blocked,
then
you
can't
create
a
full
request
to
begin
with,
so
we've
been
given
the
ability
to
exempt
branch
prefixes,
so
we
could
say,
like
anything,
that's
like
release.
C
You
know
that
starts
with
release.
We
can
create
those
branches
and
update
that.
C
The
second
problem
is
that
the
github
actions
bot
once
it
creates
the
pr
has
not
signed
the
cla
and
is
not
exempted
that
I'm
still
waiting
on,
but
my
work
around,
for
that
is
just
to
use
my
personal
github
token,
which
you
can
actually
see
if
we
look
at
the
broken
pr
on
the
core
repo.
C
D
Okay,
cool-
and
we
would
just
do
that
for
now,
while
that
gets
decided
by
cncf.
C
Yeah,
that's
what
we'll
do
for
now.
It's
definitely
not
ideal,
and
cncf
knows
that
this
is
the
solution
that
we,
you
know
that
this
is
our
temporary
workaround
and
they're,
okay
with
it,
but
they
also
know
that
we
don't
want
to
do
this
long
term,
so
they
are
working
on
a
more
long-term
solution
for
us.
I
think
they
are
going
to
allow
us
to
exempt
the
github
actions
bought
from
the
cla.
C
But
another
solution
that
they
were
talking
about
was
creating
an
automation
user
that
they
would
create
and
control
and
generate
a
token
for
me,
and
I
would
use
that
so
instead
of
having
all
of
github
actions
exempted,
it
would
be
only
those
which
run
using
this
token
for
their
for
their.
C
Exactly
but
that's
all.
C
D
Okay
thanks:
I
can
note
that
in
the
the
meeting
notes-
yeah
yeah-
I
was
talking
and
not.
C
No,
I
just
haven't
had
time
to
do
it.
I
can
do
that
today.
I
did
the
one
thing
I
think
that
would
block
it
would
be
when
this
is
not
necessarily
blocking
it,
but
we
can't.
C
If
we
release
version
25
right
now,
the
aws
lambda
instrumentation
is
still
only
pointing
at
the
24
version,
so
each
version
would
become
25,
but
the
version
of
core
that
it
depends
on
is
version
24..
So
that
version
is
out
of
step,
and
I
suppose
the
whole
point
of
of
the
contributory
bow
is
to
allow
us
to
release
some
of
those
packages
without
affecting
others.
C
But
I
had
been
hoping
to
do
that
with
release
please
so
that
we
could
release
only
those
packages
which
are
changed
if
that
makes
sense.
Obviously
that's
taking
time.
So
I
suppose
I
will
it's
kind
of
up
to
you.
Do
you
want
us
to
release
the
whole
contributory
bow
and
have
your
version
be
slightly
out
of
step?
Or
do
you
want
me
to
hold
back
the
release
of
your
package.
D
You
can
go
ahead
and
release
our
instrumentation
as
as
point
25,
if
that
really,
whatever
is
easiest
on
your
end,
even
if
it's
releasing
ours
is
0.25
depending
on
0.24.
We
just
ended
up
using
the
0.24
version
anyway
for
our
latest
distribution.
While
we
were
figuring
out
this
bug
and
it'll
get
back
up
to
date
for
the
0.26
release
once
we
fix
it
this
week,
so
it
shouldn't
be
a
big
deal.
D
D
Still
investigating
this
week,
yeah
we
we
did
a.
We
did
that
release
yesterday,
so
kind
of
was
consumed
with
that,
but
we'll
be
investigating
the
rest
of
this
week.
H
G
Referencing
something
someone
brought
up
while
we
were
discussing
the
first
point
about
having
like
blog
posts
and
stuff
pointing
to
packages
or
files
in
github
repo.
Does
that
mean
we
have
no
chance
in
removing
the
open,
telemetry
prefix
in
the
folder
names
ever.
C
It
doesn't
mean
there's
no
chance;
it
just
means
that
that
is
one
reason
not
to
do
it.
If
we,
if
we
decide
to
do
it,
then
that
we'll
have
to
you
know
accept
that
that's
a
consequence
of
it.
You
know
we,
we
accepted
that
consequence
when
we
originally
created
the
contrib
repo,
and
we
accepted
that
consequence
when
we
created
the
api
repo.
C
People
should
be
when
they
make
blog
posts
linking
to
specific
versions
of
the
repo
anyways.
You
know
anybody
should
know
that
if
you
link
to
maine
name
might
change.
That
said,
it's
probably
not
always
the
case
yeah,
I
wouldn't
say,
there's
no
chance.
I
would
just
say
it's
one
more
thing
to
think
about
when
we
decide
to
maybe
do
that.
C
G
C
C
Okay,
we're
we're
near
the
end
of
time.
Does
anyone
have
another
discussion
topic
for
today.
C
Okay,
thank
you
everybody
for
your
time
and
thank
you
for
for
talking
through
this
with
me.
This
is
kind
of
a
hairy
issue,
so
I'm
glad
I've
had
people
to
help
me
through
this.
So
I
definitely
appreciate
it.