►
From YouTube: CNB Core Team Sync - 23 Feb 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
And
we
can
move
on
to
outstanding
spec
prs.
I'm
gonna
try
to
make
this
real
fast,
like
a
lot
of
people.
We
need
to
goad,
aren't
here
to
be
shamed
which
reduces
some
of
the
value
of
this,
but
oh
steven's
here
now.
So
that's
at
least
one
more
person.
A
Removing
legacy
bomb
for
platform
09,
I
think
this
one
natalie
is
asking
for
more
guidance
about
what
to
spec
or
not
spec.
Coming
out
of
that
last
working
group
meeting
where
we
decided
to
keep
the
compat
version
in
a
file.
A
My
two
cents
would
be.
We
could
put
something
in
the
build
pack
spec
in
terms
of
what
to
name
the
extension
where
you're
using.
I
guess
you
don't
need
to
do
anything
on
the
extension,
though,
like
it's
interesting,
because
we're
not
specking
any
of
this
on
the
platform.
Side
and
it'd
be
weird
to
add
this,
I'm
in
favor
of
not
adding
it
anyways,
because
it's
deprecated
functionality
right.
B
A
Yeah
I
mean
this
is
getting
back
to
it
in
a
lot
of
ways.
One
of
the
reasons
I
thought
it
was
better
just
to
take
it
out,
but
I
feel
like
you,
sam
and
terence,
had
feelings
that
we
shouldn't
just
be
removing
it.
I'm
happy
basically
any
proposal
that
someone
has
for
a
way
to
move
forward
with
this
I
would
take,
and
I
would
also
take
a
proposal
that
is
we
take
it
back.
We
don't
want
a
way
to
move
forward
with
this.
We
just
want
to
strip
it
out.
A
B
Out
I'll
write
out
what
we
can
do
with
this,
so
that
it's
compatible
with
all
the
other
stuff.
A
Looks
like
this
has
enough
approvals
to
merge.
I
did
leave
some
comments,
things
that
I'm
happy
to
approve
whether
this
wording
change
is,
you
know,
adopted
or
not
natalie.
So
if
you
just
want
to
take
a
look
and
either
accept
or
reject
them,
I
think
we're
in
a
place
where
we
can
merge
it.
C
D
As
a
quick
refresher
on
this,
what
becomes
un
reproducible
with
this
like?
What's
the
extent
of
that
lack
of
reproducibility.
C
C
B
A
This
doesn't
make
it
not
reproducible
you're,
just
like
setting
this
value,
you
can
set
it
to
the
same
thing
every
time.
If
you
want
to
as
well,
I
mean
the
only
reason
people
want
to
set.
It
is
so
that
they
can
make
it
somewhat
reflect
the
time
they
built
it
right,
but
just
calling
it
out
that
this
is
not
about.
A
I
know
there's
been
a
couple
situations
recently
where
people
ask
me
why
the
literal
image
digest
was
not
the
same
from
two
identical
builds.
So
I
think
some
people
do
care
about
the
image
reproducibility.
I
would
say
the
people
who
care
a
lot
about
that
are
a
minority
compared
to
the
people
who
are
like.
Why
was
it
built
in
the
past.
C
Yeah,
okay,
I
think
there's
president
like
tools
like
jib
and
co
right,
I
think
jib
is
zeroing.
The
creation
dates
we're
setting
it
to
the
specific
date
in
1980,
that's
safe
to
send
two
or
whatever
it
is
the
do.
We
know
what,
if
they're
still
doing
that
and
do
we
know
what
ko
is
doing,
because
I
think
prior
art
here
is
helpful.
C
Okay,
I
looked
at
the
spec
and
I
thought
the
spec
as
it's
currently
written
doesn't
prohibit
this,
and
then
I
asked
in
the
slack
channel
if
it
should
have
an
rfc
and
no
one
said
anything.
So
I
open
the
spec
pr
we're
talking
about
two
different
things,
though
one
is
whether
we
should
do
the
creation
date
by
default,
and
I
think
that
would
require
an
rfc.
C
This
is
just
free
feature
to
allow
you
to
set
the
creation
date
right
manually,
which
is
a
new
feature
to
say
it
needs
an
rfc,
but
you
know,
I
think,
that's
like
I
mean.
B
B
C
I'm
still
curious,
if
there's
prior
art
for
that
default
behavior.
If
we
know
what
what
jib
and
co
are
doing,
if
they're,
if
they
both
decided
that
they're
always
going
to
set
the
creation
date
right,
we're
just
you
know
the
only
tool
that
behaves
this
particular
way,
then
I
think
that
suggests
to
me
that
we
should
consider
it
is.
The
team
sounds.
D
B
D
To
be
bluntly,
honest
natalie
did
what
she
was
supposed
to
do.
She
asked
if
anyone
wanted
an
rfc.
No
one
said
yes,
and
then
she
went
ahead
and
did
the
work
like.
I
don't
think
we
get
to
go
back
and
change
history.
At
that
point,.
B
B
D
Like
the
rfc
process
was
never
intended
to
encapsulate
every
single
change
that
might
ever
be
made
to
any
spec
or
any
implementation,
while
in
practice
it
has
degenerated
to
that.
That's
not
why
we
did
it,
and
I
think
this
was
the
process
working
as
designed
that
people
can
make
a
good
judgment
about
whether
or
not
something
needs
to
go
through
rfc.
D
It's
communicated
and
asked
for
feedback,
and
if
nobody
feeds
back
that,
they
think
this
thing
is
a
big
enough
thing
to
go
to
rfc,
like
I
don't
think
we
get
to
then
come
in
at
the
end
of
the
process.
After
people
have
done
good
work
and
say
nope,
actually
we're
going
to
retroactively,
say:
yes,
you
needed
to
do
that,
and
it
may
end
up
with
a
completely
different
result
than
all
the
work
that
you
did
here.
E
E
At
least
you
know
that's
my
thinking
like
we
didn't
even
really
have
to
make
the
spec
part
of
this
might
have
needed
to
go
through
rfc,
but,
like
I
don't,
I
think
we
could
have
done
this
feature
without
even
having
a
spec
change
for
this,
because
this
is
the
spec
is
not
documentation
for
how
life
cycle
behaves
it's
for
our
things.
We
want
to
keep
and
expose
to
everyone.
Like
you
know,
I
don't
know,
there's
plenty
of
things
it
does.
That
is
not
documented
here.
It's
a
blurry
line
already
between
this.
A
I
agree
that
that
strongly
in
theory,
I
feel
like
the
problem
we
run
into
in
practice-
is
there's
no
life
cycle
documentation
in
the
level
of
detail.
That
is
a
stand-in
like
where
we
would
put
something
like
this.
If
we
didn't
go
in
this
pack,
maybe
we
can
table
this
sort
of
process
discussion
for
now
and
keep
going
with
the
roundup
of
the
open
pr's.
A
Do
you
see
this
question?
I
knew
the
answer
to
this
at
one
point,
but
I
can't
remember
anymore
whether
I
think
most
tools
that
use
this
particular
source
date-
epic.
They
are
by
default
using
the
real
creation
time,
and
this
is
a
way
to
do
to
set
it
to
something
reproducible
rather
than
sort
of
freezing
it,
for
the
opposite
reason
is
what
I
remember.
C
A
A
C
A
B
I
updated
my
cosine
rfc
to
extracted
out
of
the
export
phase
into
now.
What's
an
optional
container
binary,
whatever
I
don't
know
where
that
is
supposed
to
go,
but
whether
it
will
be
part
of
the
lifecycle,
repository
or
a
new
repository
altogether,
but
it's
currently
structured
as
a
standalone
binary.
B
That
platforms
can
optionally
use
still
is
very
much
a
gray
area,
because
whether
this
is
a
new
phase,
whether
this
has
to
abide
by
different
platform
apis
and
stuff.
I
am
not
yet
sure,
but
it
decouples
it
from
export.
At
least
so.
Single
binary
takes
in
some
same
inputs
and
gives
back
an
appropriate
output.
A
A
A
B
C
B
A
C
A
A
A
And
replacing
positional
arguments
with
mvars
has
been
a
final
comment
period
for
a
long
time.
There
was
a
last
minute
discussion
about
the
names
I
think
we
agreed
in
slack
to
duplicate
the
names.
Well
then
doing
the
platform
mvars
as
a
larger
refactoring.
Oh
yeah,
joe,
did
a
good
job
copying
that
here
and
it's
all
been
addressed
in
the
spec
it
looks
like
so
I
think
this
is
also
something
that
can
merge.
C
E
C
A
B
A
C
Yeah,
I
think
we
should
put
an
s
bomb
on
the
front
yeah.
I
thought.