►
From YouTube: CNB Team Leads Sync - 15 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).
D
C
The
effort
there
and
I'll
I'll
link
those
pr
so
that
people
can
look
at
them.
There's
some
actions.
I
think
on
one
of
them
and
also
docker
files
phase
one
is
moving
ahead.
I
just
put
up
a
pr,
that's
still
in
draft,
but
basically
almost
there
and
I'm
hoping
to
get
feedback,
maybe
tomorrow
in
the
working
group
on
the
spec
changes,
because
I
feel
like
just
forcing
everyone
to
look
at
your
pr.
It's
really
the
only
way
to
get
feedback
on
it.
B
D
C
Think
I'm
I've
noticed
that
pr
sort
of
they
unless
you
really
advertise
them,
they
just
sit
there.
So
I
want
to
advertise
mine,
but
I
also
think
it
could
benefit
from
some
like
concurrent
discussion
anyway.
I'm
I'm
hopeful
that
that
could
be.
You
know
in
a
place
where
we
could
ship
it.
You
know
assuming
we're
able
to
get
the
specs
ready,
awesome.
E
Cool,
I
could
go
next.
I
typed
in
a
couple
things
as
well,
so
right
now
we're
working
pretty
heavily
on
updating
our
ubuntu
deliberate
pipelines,
some
versions,
sort
of
kind
of
became
problematic
as
github
changed
some
of
its
runners,
so
we're
changing
strategy
there
and
we're
in
we're
adding
jamming
jellyfish
to
the
release
of
the
ppa
four
pack
on
that.
E
B
Just
wanted
us
to
kind
of
think
that
we
even
can
get
the
information
for
I'm
just
wondering
cause.
There's
like
gonna,
be
an
infinite
set
of
things
distributions
we
could
or
could
not
support
in
the
long
run
right
it's
like,
and
I
think
we've
made
a
bet
that
it's
worth
distributing
in
all
of
these
mechanisms.
E
So
we
know
that
at
least
people
are
trying
to
install
it
on
linux,
david
and
I
are
having
the
discussions
right
now
about
what
we're
trying
to
set
forth
as
far
as
what
we
will
continue
to
support
right,
the
level
of
support
for
the
different
variants
of
ubuntu
releases
and
whether
or
not
we
want
to
align
with
lts
or
not
and
stuff
like
that,
so
those
conversations
are
going
on
for
now.
I
think
we're
just
trying
to
keep
it.
You
know
at
the
bare
minimum.
E
D
B
E
I
think
one
of
the
things
that
we're
trying
to
solidify
is
the
I
think,
there's
two,
basically
how
it's
going
to
be
persisted
on
the
file
system,
the
directory
structure
of
where
the
things
are
going
to
live,
then
the
other
one
is
that
sort
of
the
poc
or
the
spike
on
sort
of
like
partial,
oci,
layouts
right
like
we
just
need
to
manifest
so
ballpark
figure,
I
would
say
we're
definitely
still
probably
about
at
least
two
weeks
out.
Okay,.
E
D
E
B
D
A
Okay,
we
have,
we,
I
think,
are
progressing
on
the
dot
profile
stuff.
Oh
dan
mccooser
created
the
initial
pr
just
scaffold
the
whole
thing,
including
the
release
and
delivery
pipelines
using
pipeline
builder,
and
I
think
gabe
from
bloomberg
is
going
to
help
out
with
the
implementation,
nice
and
I
think,
we've
had
a
few
more
years
last
discussions
on
the
lip
cnb
side,
specifically
on
the
s
bomb
bits,
and
now
that
I
am
on
eastern
time
zone.
B
A
B
C
Question
about
the
platform
and
the
build
pack
apis.
Actually
I
think
last
time
I
guess
the
discussion
over
the
last
week
has
concluded
in
you
know:
docker
files
we'll
just
go
out
in
the
next
api,
but
we'll
use
the
lifecycle
release
candidate
as
a
way
to
get
feedback
and
that's
good
to
me,
but
I
did
wonder
if
it
makes
sense
to
bundle
it
together
with
the
shell
removal
stuff,
because
I
could
be
wrong,
but
my
like,
I
know
the
life
cycle
changes
that
are
needed
for
that.
C
Like
I
don't
I
don't
even
know
if
they've
been
started
like
you
know,
so
that's
one
thing
and
then
the
profile
build
pack
like
would
take
some
time
to
get.
You
know,
approved
and
adopted,
and
all
of
that,
so
I
I
wonder
if
it
makes
sense
to
break
them
out
into
separate
apis,
and
I
it
also
might
make
it
easier
for
platforms
that
want
to
test
docker
files
to
not
have
to
like
update
their
builders
as
well.
A
C
Oh
sorry,
sam,
I
I
glossed
over
that
you.
I
think
we
we
talked
about
this
in
the
last
working
group,
but
basically
yeah.
My
understanding
was
wrong
of
what
a
pre-release
api
meant.
I
thought
it
was
going
to
mean
that
I
didn't
have
to
support
old
versions
of
it,
but
that's
not
true,
so
it
adds
no
value
to
me
and
therefore
we'll
still
do
the
platform
like
experimental
features.
D
B
D
B
We
should
ship
profiles
and
system
build
packs.
At
the
same
time,
it's
like.
I
know
we
need
to
ship
those
things
in
order
for
salesforce
to
feel
good
about
the
argument,
handling
and
sell
changes,
but
given
that
you
don't
need
to
adopt
those
changes
without
upgrading
the
api
like
do
they
need
to
ship,
do
they
actually
need
to
ship
at
the
same
time,
or
can
they
just
be
like
you
know,
lined
up
to
go?
I
feel
like
it's
the
question,
but
I
don't
know
if
it's
a
question
that
any
of
us
here
can
answer.
D
A
B
D
B
A
B
A
A
Because
we
we
expose
those
double
hyphens
with
the
launcher
right
now
to
an
app
developer,
yeah
and
removing.
That
is
a
huge,
huge
breaking
change
that
the
app
developer
would
never
know
what
to
do
with
like
they're,
never
exposed
to
build
pack
apis
or
the
fact
that
their
build
packs
are
on
a
different
api
or
they're
using
a
different
buildback.
So
we
need
to
make
sure
those
changes
are
handled
very
carefully.
B
D
A
B
B
A
C
A
This
this
whole
rocket
syntax
is
new
as
an
app
you
app
developer,
facing
change
so
like
when,
when
a
launcher
like
someone
is
using
the
launcher
directly
with
the
shell
mode,
they
would
have
expected
a
different
behavior,
which
would
now
be
gone
and
the
the
bit
that
replaces
it
like
this
new
environment.
Variable
syntax
is
something
that
we'll
have
to
make
the
app
developers
aware
of.
A
D
D
C
B
B
A
A
A
So
I
think
whichever
platform
ends
up
adopting
this
new
dockerfile
stuff,
but
I
think
it's
going
to
be
very
difficult
for
k-pac
to
do
it
with
all
of
its
freeways
features
to
like
support
the
dynamic
switching
of
base
images
unless
it's
well
defined
how
rebase
works
so
whoever's
doing
it.
I
would
like
them
to
take
that
scale
level.
Rebase
thing
into
account
when
they
figure
out
stack
removal.
B
D
D
A
How
would
you
know
like
so
for
things
like
kpak?
How
would
you
know
which
image
to
switch
like
the
way
it
happens
in
kpac
right
now
is
that
you
have
a
builder
registered
with
one
run
image
and
when
you
change
the
reference
to
that
random
image.
For
that
builder,
everything
that
was
built
by
that
builder
gets
rebased,
but
that's.
B
Well,
I
mean
kpec,
it's
not
really
looking
for
image
updates
that
way
the
happens
differently,
but
in
general
it's
the
idea
that,
like
here's,
where
the
run
image
lives
when
it
gets
updated
rebase,
but
if
you
don't
know
that
the
run
image
is
actually
your
base
image,
you
don't
know
what
your
base
image
was
or
where
to
find
new
versions
of
it.
It's
kind
of
like
who
knows
what
happens.
D
B
B
A
D
A
The
reason
I'm
bringing
up
k5
is
because
that's
the
only
platform-
that's
operationalized
freebase
at
this
point,
there's
no
other
like
factory
base.
I
have
like
it's
all
our
dog
and
it
needs
someone
to
manually.
Do
it
so
either
way
you
needed
to
know
what
was
your
neuron
image?
So
now
you
just
you
need
to
know
it.
B
B
But
it's
about
like
the
scaling
properties
of
different
systems
and
how
much
you're
trading
off
like
complete
certainty
and
security
and
a
100,
accurate,
s-bomb
versus
an
escape
hatch.
And
I
think
it
matters
a
lot
to
red
hat
because
they
want
to
put
they
need
to
consume
language
run
times
from
rpms.