►
From YouTube: CNB Team Leads Sync - 29 June 2022
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
Thank
you,
sam,
not
seeing
any
new
faces,
so
let's
jump
right
into
team
lead
updates.
I've
noticed
natalie
filling
out
the
implementation
section.
Do
you
want
to
give
us
a
rundown
of
the
updates
natalie.
B
Sure
not
a
whole
lot
of
like
speed
change.
I
guess,
but
we've
been
moving
forward
with
docker
files
phase
one
it's
basically
implemented
in
the
life
cycle,
but
we
have
to
now
formally
agree
on
the
spec
and
the
rfc
to
get
it
out
there.
B
B
B
So
if
I
could
just
ask,
I
think
I'm
still
waiting
on,
I
know
for
the
dockerfiles
rfc,
I
think
terence
and
joe
joe
has
approved
recently
terence
approved
a
while
ago.
It's
stephen's
rfc.
B
I
guess
we
can
assume
his
approval
and
I
think
emily
could
take.
I
don't
even
know
what
we're
like.
What
are
the
voting
rules
like
you
know
at
this
point,
is
it
lazy
consensus
or
not,
but
or
is
it
the
old
core
team
sam?
Should
you
also
be
like
included
in
the
you
know:
unanimous
vote
it
just
everyone,
please
look
at
it.
That's
all
that's
true.
C
A
I'm
happy
to
read
through
it
one
more
time
because
I've
been
building
out
the
pse
and,
if
that's
going
well,
I
have
trust
that
it
means
that
what's
in
there
is
reasonable
and
I
think
that's
in
a
lot
of
ways,
some
of
the
intention
of
moving
to
this.
It's
like,
I
feel
less,
like
I'm
the
person
who
knows
what
the
right
answer
here
is
than
I
used
to.
D
Like
the
current
state
of
the
rfc
doesn't
include
all
the
spec
changes
and
the
stack
removal
and
a
bunch
of
other
open
questions
and
then
at
some
point
we
remove
the
the
gen
packages.
Stuff
are
all
those
updates,
like
they're
all
done.
B
B
I
honestly,
I
don't
think
we
can
really
like,
given
that
we
sort
of
has
this
phased
implementation.
I
think
it
would
be
impractical
to
try
to
describe
all
of
the
spec
changes
for
all
phases,
but
we
did
try
in
that
pr
that
I
closed
so
I've
kind
of
said.
You
know
I've
really
done
as
much
as
I
can
for
now.
D
I
mean
I'm
happy
to
approve
it
and
what
is
it
but
like
that,
rfc,
I
think
in
general
we
spoke
about
like
rfcs
having
the
spec,
at
least
from
the
end
user,
facing
changes
up
front
so
like
this
is
part
of
the
old
rfcs,
but
I
think
in
the
future.
Whenever
we
write
rfcs,
I
think
we
shouldn't
have
to
debate
what
the
spec
would
be
in
the
spec
players.
D
C
Yeah,
I
I
kind
of
agree
with
that,
but
I
also
feel
like
the
scope
of
this
rfc
is,
is
so
large
that
it
has
to
be
phased
and
so
like
the
way
I
was
reviewing
it.
The
way
natalie
laid
it
out
was
really
nice
because
it
was
like
here's,
the
rfc,
with
the
spec
prs
and
I'm
fine
with
whatever
order
we
merge
those
things
in
but
like
having
it
all.
C
That
way
was
like
exactly
what
I
would
have
wanted
granted
like
yeah
there's
some
things
that
need
to
be
done,
like
I
guess,
like
stack,
removal
right,
isn't
a
part
of
the
spec
changes.
I
think,
but
I
can't
imagine
like
trying
to
swallow
all
of
that.
D
Just
to
proved
it,
I
think
I
also
asked
someone
from
the
k
pack
site
to
look
at
the
dockerfiles
bit.
The
only
piece
of
feedback
I
got
was
in
order
to
implement
like
something
equivalent
to
rebase.
D
One
idea
was
that
we
could
just
run
the
extensions
and
run
the
extensions,
and
the
extensions
could
spit
out
whether
things
need
to
be
rebuilt
or
whether
just
rebased,
because
the
extensions
are
probably
the
only
component
that
actually
know
whether
they
can
be
or
cannot
be,
and
so,
like.
The
the
extension
generation.
D
That's
at
least
is
fairly
inexpensive,
like
just
generating
the
dockerfiles
so
like
if
they
could
say
that
hey
this,
like
run
those
things
again
and
post
that
if
I
need
to
trigger
a
full
rebuild
or
just
a
rebase
like
that
is
something
like
a
extensions
could
signal.
Somehow
that
was
probably
the
only
piece
of
feedback
I
got
in
terms
of
how
this
would
be
implemented
in
the
reality.
D
A
A
A
D
E
I
can
give
a
quick
update
on
the
platform
side
of
things,
so,
basically,
after
the
pac
release
or
soon
thereafter,
we
got
reports
of
some
issues
with
specifically
an
incompatibility
on
a
bug
for
the
life
cycle
that
you
know,
thankfully,
had
already
been
patched.
E
Outside
of
that,
there
were
some
pipelines
that
needed
maintenance
for
pack
in
preparation
for
the
release
and
after
the
release
there
are
there's,
probably,
I
believe,
still
one
that
needs
to
be
resolved.
So
that's
still
something
that's
underway,
and
then
the
only
other
thing
that
I'm
currently
aware
of
is
the
google
summer
code
mentorship
with
the
cash
flags
for
pac.
That
is
fully
underway,
that
that
was
delayed
a
bit
because
of
some
issues.
But
that's
now
you
know
going
at
full
throttle.
C
Yeah
a
couple
updates
so
for
learning.
If
you
haven't
seen
aiden's
video
in
the
learning
team
channel,
I
recommend
it's
a
rough
cut.
I
recommend
giving
it
a
view
unless
you
have
a
new
version
of
that.
Even.
C
Yeah,
I
mean
not
rushing
you.
I
just
thought
it
was
worth
taking
a
look,
we're
mentioning
for
distribution
I
mentioned
in
the
channel,
but
there
was
a
there's.
A
namespace
created
called
gcr
that,
as
sam
kind
of
pointed
out,
was
probably
a
mistake
because
that
same
user
created
a
different
name
space
with
their
personal
name
right
after,
like
minutes
after
that,
so
I
was
looking
at.
We
already
have
yank
for
build
packs,
so
I
was
looking
at
the
concept
of
yanking
a
namespace.
C
D
What
they
did
was
they
started
out
with
the
build
pack
that
had
gcr
as
its
namespace
thinking
that
the
the
namespace
there
would
potentially
also
be
reflected
in
the
registry
or
like
they
somehow
got
confused,
and
they
tried
to
register
the
bill
pack
and
when
you
register
a
build
pack
with
a
new
namespace.
It
automatically
registers
a
new.
D
C
Yeah,
I
mean
it's
like
by
design
right,
because
that
way,
it
just
happens,
and
it's
not
like
a
thing
you
have
to
think
about,
but
given
that
that
is
somewhat
inevitable,
I
think
some
ability
to
to
prune
them
or
yank
them
would
be
a
nice
companion
to
that
convenience.
D
What's
interesting
is
the
the
model
we
take
versus
the
model
like
something
like
artifact
uptakes
in
terms
of
namespace
or
package
registration
for
them.
It's
more
like
you,
sort
of
maintain
all
the
metadata
in
your
own
repository
and
you
associate
like
an
organization
with
the
namespace.
Essentially
so,
like
you,
you
control
the
metadata.
So
if
you're
in
control
of
the
google
github
organization,
then
you're
in
control
of
what
goes.
C
Yeah
that
I
feel
like
there's
a
reason
that
that
there
was
something
that
prohibited
us
from
doing
it.
That
way,
but
that
is
like.
C
C
Cool,
so
I
think
that
covers
all
the
sub
teams.
D
That
there's
a
yeah,
just
I
think,
daniel's
put
in
a
pr
profile
and
that's
just
waiting
approvals.
I've
been
away
the
last
two
weeks,
so
I
haven't
had
a
lot
of
time
to
catch
up.
C
Cool,
I
added
an
item
for
the
kubecon
north
america.
Maintainer
track
is,
I
don't
know
if
we
I
haven't
caught
any
discussions
on
that.
So
if
we
already
have
my
my
apologies
for
being
out
of
touch,
but
I
think
the
submission
is
due
july
11th,
I
think
I'm
going
to
be
there.
So
I'm
happy
to
to
do
whatever,
but
I'm
I
don't
necessarily
need
to
be
the
speaker.
D
C
So
we
get
one
session
like
a
normal
maintainer
track
session
and
then
there's
a
contrib
fest
session
that
is
90
minutes
in
person
only
designed
to
provide
projects
with
the
space
and
resources
to
tackle
outstanding
technical
debt,
security
issues
and
outstanding
impactful
feature
requests.
All
in
90
minutes
sounds
great:
oh
there's
only
nine
slots
for
that.
D
C
C
C
B
B
B
Yes,
please-
and
I
also
noticed
this
issue
sam-
that
you
made,
which
is
to
like
explicitly
call
out
that
our
api
versions
can
contain
alphanumeric
like
pre-released
indicators,
but
we
don't
plan
on
doing
that
anytime
soon.
Do
we
want
to
wait
because
there
was
some
concern
about
adopting
our
own
schema.
C
D
E
Yeah,
I'm
pretty
sure
you
had
an
account.
I
invited
you
a
while
back
but
yeah.
E
You
cannot
read
me
as
well
somewhere
on
the
the
docs
read
me:
has
a
link
to
team
up.
I
believe,
but
sam's
got
it.
C
Okay,
I
think
we're
just
about
done.
Is
there
any
more
to
add
to
the
agenda
for
tomorrow.
B
The
other
topics
that
have
come
up
recently
were
the
the
launcher
stuff,
like
shell
removal,
and
I
don't
know
if
sam
I
mean
last
time,
we
put
it
on
the
agenda,
but
we
cancelled
because
thing
wasn't
there,
but
maybe
we
can
bring
it
up
again
and
the
other
things
I
would
suggest
are
those
two
new
rfcs
that
I
mentioned,
because
it
seems.
B
I'll
I'll
open
them.