►
From YouTube: CNB Sub-Team Sync: BAT - 1 Jul 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
Okay,
just
a
reminder
that
there
is
a
document
attached
to
this
meeting
which
has
an
agenda.
Please
add
any
agenda
items
there
and
also
sign
in.
A
Okay,
let's
get
started
zoom
controls
and
use
tube
stream
done
new
faces.
I
don't
see
any
sas
updates.
I
have
mostly
been
away
for
the
last
couple
of
weeks,
so
I
don't
have
a
lot
to
update
on
anyone
else.
A
B
C
I
so
last
time
we
spoke
about
this,
it
was
suggested
to
simplify
things
quite
a
bit
and
I
hope
I've
done
that
at
this
stage,
and
I
hope
that
means
that
I've
addressed
some
of
the
the
the
the
outstanding
comments
on
it.
So
let
me
see
if
graph
sees
I
mean,
I'm
not
quite
sure
what
we
want
to
do
at
this
stage.
Do
we
want
to
go
through
the
rfc
or
do
people
want
to.
C
The
last
time
is
simplified
things
quite
a
bit,
there's
an
rfc
and
there's
kind
of
a
implementation
that
goes
along
with
it
again
we're
not
committed
to
this
implementation.
But
the
pull
request
on
the
implementation
removes
the
the
idea
of
collections,
which
was
one
thing
that
was
complicated
in
the
rfc.
C
So
now
the
rfc
says
that
the
what
we've
got
to
do
with
pack
build
pack
create
is
either
your
pack
build
pack
crate
which
will
create
for
you
a
repo
or
a
scaffolded
project
that
uses
the
existing
bash,
build
pack
stuff
or
you
can
pass
in
a
template,
url
and
that
can
be
used
to
create
something
that
might
exist
in
the
future.
C
And
we
could,
in
the
future,
then
write
an
rfc
to
propose
a
lib
cmb
based
go
line
or
go
implementation
of
a
project
scaffolding,
so
that's
been
taken
out
of
the
rfc
now
and
will
move
to
a
future
rfc
and
given
that
the
whole
thing
becomes
much
more
straightforward
that
we
there
is
an
example,
implementation
of
the
bash
project.
Scaffolding.
C
If
I
go
into
my
repo
and
if
I
go
into
the
bash
example,
what
we
now
have
is
top
level
prompts.tumblefile,
which
prompts
for
the
necessary
things
to
create
a
bash
scaffolding.
You
can
see
that
these
pretty
much
map
one
to
one
to
the
existing
pack
build
pack
new
parameters,
so
this
is
the
the
path.
This
is
the
api.
C
This
is
the
bill
pack
id
that's
passed
in
positionally
impact,
pullback
new
and
bill
pack,
stacks
which
is
again
passed
in
and
it
creates
a
new
build
pack
with
the
necessary
bits
templated
out
and
it
creates
the
either
the
build
or
the
detect
and
the
detect
scripts
that
we
currently
have
inside
of
inside
of
back.
So
it's
taking
those
scripts
out
of
back
as
embedded
things
and
putting
them
into
our
separate
repo
that
we
can
then
maintain.
C
I
suppose
that's
where
the
where
the
rfc
is
at,
I
suspect,
there's
one
other
thing
that
people
want
to
see
before
we
think
about.
I
I
don't
know,
maybe
even
approving
the
rfc,
and
that
is
do
we
want
to
maintain
a
a
bunch
of
buildback
scaffolding
in
a
single
repository
in
multiple
subfolders.
Or
do
we
want
to
maintain
them
as
separate
repositories?
C
And
I
suppose
that
would
be
the
question
because
if
that's
not
yet
covered
in
the
the
rc.
D
Okay.
Sorry,
if
you
don't
mind,
I'm
gonna
jump
in
here,
because
I
think
this
ties
to
one
of
the
questions
that
I
brought
up
to
whether
this
sort
of
functionality
would
support
a
repository
with
multiple
sort
of
like
subdirectories
right
of
different
languages
templates,
and
I
think
you
replied
in
a
comment
that
it
would
but
the
rfc
I
don't
still
see
that
clearly
being
spelt
out
yeah.
So
I
think
that's.
D
Maybe
one
of
the
sort
of
like
additional
clarifying
points
we
could
add
is
there's
probably
been
a
lot
of
things
that
we
might
have
cleared
up
in
conversations,
but
I
don't
think
they've
I've
seen
those
updates
actually
in
the
rfc
right.
So
I
think
what
what
I'm
sort
of
waiting
for
is
for
the
rfc
to
be
updated,
with
the
resolutions
of
the
conversations
to
more
explicitly
call
out.
D
You
know,
for
instance,
this
this
question
and
then
I
did
still
see
sort
of
what
what
the
source
code
would
look
like
for
something
like
go
and
then
the
other
example
where
you
have
like
bash.
I
don't
think
I
saw
that
repository
anywhere
on
the
rfc,
so
I
know
now
I'm
just
kind
of
throwing
a
whole
bunch
of
lit.
You
know
items
at
you,
but
maybe
there's
something
that
we
could
do
to
better
communicate
the
intentions
here,
as
opposed
to
having
these
conversations
or
having
conversations
and
comments.
D
I
think
what
I'd
personally
like
to
see
is
the
rfc
having
all
this
information
as
someone
reading
it
from
scratch
and
not
having
any
context,
because
that's
ultimately,
what's
going
to
be
presented
to
the
rest
of
the
voting
members
right,
I
don't
think
that
they
should
be
expected
to
have
the
context.
I
think
they
should
be
expected
to
just
read
a
single
document
and
then
be
able
to
approve-
or
you
know,
debate
from.
C
That
makes
sense
yeah,
so
the
rfc
should
then
we
want
to
see
repositories
with
multiple
sub
directories,
so
the
the
rfc
should
then
explicitly
call
that
one
out
and
again
just
go
back
make
sure
the
rfc
is
readable
from
start
to
finish,
with
all
the
necessary
information
that
it's
a
standalone
document,
get
that
that's.
D
Yeah
makes
sense
and
then
just
to
add
to
that
for
for
maybe
driving
again.
That
clarity
is,
we
have
some
comments
that
are
still
unresolved
right,
like
literally
on
the
github
result,
sort
of
state.
D
D
Yeah,
so
other
than
that,
the
only
real
clarifying
point
is,
if
you
were
to
run
the
pac
pack,
create
right.
I'm
envisioning
now
with
new
information
that
by
default,
that
would
point
to
a
single
repository
somewhere
that
is
managed
by
us
and
inside
of
there.
It
would
have
subdirectories
one
for
bash,
maybe
one
for
go
in
the
future
and
and
so
forth,
and
those
subdirectories
within
that
would
then
be
displayed
to
the
user
as
a
prompt
to
then
be
able
to
select
from
those
directories,
as
templates.
C
No
so.
C
So
that
was
what
we
had
and
I
I
thought
we
decided
that
that
was
just
too
much
at
the
moment
and
to
take
the
idea
of
project
templates
for
other
programming
languages
out
of
this
rfc
and
treat
them
as
some
kind
of
future
problem.
C
So
right
now,
each
project
template
is
its
own
repository
and
I
suppose
the
the
question
is:
how
would
we
want
to
manage
them
in
the
future?
C
Do
you
want
any
different
repositories
in
somewhere,
like
github
one
for
bash
one
for
golang,
one,
for
maybe
some
of
the
others,
or
do
you
want
a
single
repository
and
to
manage
these
things
as
as
subdirectories,
and
then
the
question
would
be
by
or
the
assumption
I
have
right
now
is
that
by
default
it
would
choose
the
bash
project
template
create
for
you
a
a
bash,
build
pack.
C
D
D
And
I
know
we're
going
to
clean
this
up,
but
this
is
kind
of
where
my
mind
came
from
right
like
so,
it
says
how
it
works
that
first
sort
of
prompt
right
if
you
choose
between
the
go
bash
or
go
template
right,
so
that's
still
yfc
and-
and
I
think
I
had
a
question
about
you-
know
again
the
the
subdirectories
and
stuff.
So
I
could
still
see
this
prompt
being
you
know
again
the
way
I
expressed
it
is
something
acceptable
to
me
if
we
want
to
go
that
direction
right.
D
If
we
want
to
say
hey,
we
can
just
have
one
repository
with
different
subdirectories
for
each
different
sort
of
template
that
we
want
to
present
the
user
with.
Then
that's
where
you
would
get
this
sort
of
list
of
templates
that
you
could
choose
from
yeah
for
get
go
and
then
the
default
template
url
would
could
be
our
own
managed.
You
know
repository
with
a
whole
bunch
of
different
templates.
D
There
that's
sort
of
a
suggestion
I
have
or
an
idea
that
came
to
my
mind,
based
on
all
this
or
trying
to
piece
this
together,
but
yeah
interested
to
hear
other
opinions.
E
I
like
having
the
menu,
put
the
different
project
templates
as
an
option
I
was
thinking
like
you
could
potentially
just
have
a
url
that
directly
referenced.
Even
you
know,
with
multiple
templates
in
a
project
somehow,
but
this
just
seems
friendlier
and
when
you're
trying
talking
about
a
new
bill
pack,
author
trying
to
write
a
build
pack
like
reducing
friction
so
just
having
it
in
the
menu
seems
like
the
easiest
way
to
do.
That.
C
Yeah
apologies.
I
thought
I'd
cleaned
up
this
section
of
the
document,
but
I
may
not
have
pushed
the
commit.
F
And
then
would
we
want
some
sort
of
auto
way
to
select
things
that
are
out
of
the
project?
I
feel
like
it's
it's
cuspy,
because
we
have
things
like
suggest,
builders
and
suggest
stacks
that
point
to
things
that
are
outside
the
project.
So
you
can
imagine,
like
you
know,
we're
not
literally
implementing
suggest
templates,
but
it's
similar
in
that
we
could
pre-populate
this
list
with
things
that
we
could
include
things
that
aren't
maintained
by
us.
Is
that
something
that
people
are
imagining.
A
D
So
if,
if
pocato,
for
instance,
right
had
their
own
sort
of
template
repository
right
in
their
docs,
it
would
be
as
simple
as
saying
just
from
pac
buildpak
create
template,
url
and
then
their
repository
and
they
get
the
exact
same
functionality.
But
now
we
don't
have
to
they
don't
have
to
maintain
the
list
of
other
templates
in
our
repository
right.
I
think
it
makes
it
more
friendly
for
them.
A
Yeah,
we
could
potentially
include
like
pack
config
options
to
change
the
default
repository
so
like,
if
you're
in
the
picato
project
and
using
this
command.
Often
enough
you
can
be
like
this-
is
the
default
you
should
use
rather
than
prompting
me
for
whatever
prompting
me
for
the
bill
patch
project
when
you
use
the
pocket
one
as
the
default,
but
that
that's
just
a
config
option
on
backswing.
E
I
kind
of
think
that
goes
along
with
the
number
of
like
language
bindings.
You
know,
libraries
that
we
support.
You
know
like
right
now
the
docs
are
bash,
you
know,
so
that
makes
sense
and
we
have
libc
and
b.
So
you
know
a
go.
Lib
cnb
template
makes
sense,
but
I'm
not
sure
I
could
see
much
beyond
that
because
there's
nothing
else.
You
know
in
terms
of
languages
that
the
project
specifically
supports
right
now,.
F
I
kind
of
agree
with
that.
Yes
sort
of
asking
it
as
a
leading
question,
because
I
feel
like
this
is
going
to
be
the
list
for
a
long
time
like.
Maybe
we
would
accept
another
language
binding
someday,
but
I
would
need
convincing
to
feel
like
that's
a
good
idea.
Just
given,
like
you
know,
I
think
we
should
do
fewer
things
well,
rather
than
like
everything
but
kind
of
maintain
it.
So
I
need
like
a
big.
D
That
does
seem
like
a
separate
question
or
unless
you're
trying
to
get
that
answered
as
part
of
this
rfc
of
like
how
we
would
accept
different
templates
to
the
cnb
managed
one.
F
Yeah,
I'm
just
sort
of
I
don't
I'm
not
trying
to
see
anything
change
here.
It's
just
asking
some
of
these
leading
questions
to
see
if
it
changed
anyone's
mind
about
questions
like
one
repo
or
mini
in
a
repo.
It's
like,
I
think
how
many
there
are
likely
to
be
in
any
given
case
whether
it's
our
case
or
you
know
the
case
of
a
project.
Maintaining
several
templates
could
change
like
the
balance
of
trade-offs
in
the
ux,
but
I'm
I'm
personally
happy
to
go
either
direction,
not
just
just
poking
around
yeah.
D
I
think
the
only
added
complexity
right
is,
if
we
support
the
multiple
multiple
templates
in
a
single
repository
would
be
the
logic
on
determining
whether
it's
a
single
template
in
a
single
repository.
If
or
if
it's
multiple
templates
in
a
single
repository
like
what
do
you
consider,
I
don't
know,
maybe
it
and
you
could
you've
thought
about
this
right
but
like
what
would
you
consider
a
template?
D
Is
it
all
the
directories
instead
of
a
repository
or
is
it
you
go
in
there
and
you
would
like
traverse
the
directory
top
level
directories
and
you
check
to
see
if
they
have
a
prompts
tamil?
I
think
that's
what
I
would
like
to
see
also
as
part
of
this
rfc,
if
we
want
to
support
the
multiple
templates
in
a
repository
like
the
logic
behind
it,
because
we're
gonna
want
to
document
that,
for
others
that
might
want
to
leverage
this
feature
like
the
vacato
team
or
maybe
even
heroku,.
C
Yeah
that
was
so
yeah
the
the
current
implementation
does
precisely
what
you
said.
It
looks
at
the
repository
if
it
finds
the
top
level
prompts
that
tunnel.
It
treats
it
as
a
template
if
it
if
it
finds
a
if
it's
pointed
at
a
url
and
if
it
finds
only
subfolders.
If,
if
any
of
those
has
a
prompts
that
timeline,
it
treats
it
as
a
effectively
a
collection
of
templates,
so
each
subfolder
is
its
own
template.
C
But
I
can,
as
you
said,
all
this
needs
to
be
self-contained,
so
I'll
go
back
over
this,
and
I
will
make
sure
that
that
stuff
is
documented.
E
I
had
a
question
on
earlier
mentioning
you
had
mentioned
that
the
lib
cnb
template,
I
guess,
has
been
removed
from
this
initial
proposal-
did.
E
A
I
think
we
removed
it
from
this
rfc
something
because
this
rfc
doesn't
prescribe
what
the
actual
templates
contain
like
this
rfc
is
just
about
providing
a
tool
that
can
scaffold
repositories
based
on
the
template
and
the
actual
template
for
the
ellipse
and
b1
should
probably
be
owned
by
the
back
team.
For
example,
this
is
a
platform
team
rfc
right
now.
Okay,.
D
Yeah,
I
think
one
of
the
reasons
why
I
definitely
advocated
to
remove
it
was
the
sort
of
bike
shedding
in
the
opinions
on
the
template
itself
or
something
like
lip,
cmb
or
or
go
in
general
right.
D
D
The
the
implementation
that
we're
talking
about
now
will
support
a
maybe
more
complex
template,
so
we
can
maybe
do
them
in
parallel
right.
We
can.
We
can
maybe
even
start
talking
about
the
code
template
as
a
separate
rfc
and
maybe
that'll
influence
the
drc
we're
talking
about
now,
but
I
would
probably
still
keep
them
separate.
E
Okay,
yeah,
I
I
mean,
I
think,
I'm
fine,
you
know
from
reducing
the
the
scope
and
reducing
the
bike
shedding
for
sure,
like
that
makes
sense.
E
I'm
it
kind
of
makes
me
wonder
then
do
we
do
we
really
need
an
rc
per
template,
or
is
that
too
much
overhead
and
could
and
could
we
just
treat
the
actual
templates
more
as
an
implementation
detail
and
discuss
it
on
a
pr?
You
know
that
would
contribute
that
to
the
templates
repo.
B
E
Because
I
think,
if
we're,
if
we
even
if
we
move
it
to
a
separate
rfc,
I
feel
like
we're
just
going
to
be
moving
the
bike
shedding
there.
But
if
we
have
a,
if
we
have
a
pr
and
discuss
it
there,
maybe
we're
a
little
closer
to
the
implementation
and
and
some
of
that
bike
shutting
could
be
handled
easier.
That
way.
F
I
guess
there's
a
part
of
me:
that's
similar
to
what
we've
called
out
with
system.
Build
packs
thinks
that,
if
we're
introducing
new
things
to
maintain
an
rc
is
a
decent
checkpoint
and
like
a
whole,
new
template
feels
like
a
bigger
decision,
but
maybe
some
of
the
details
of
what
goes
into
it.
Don't
if
it's
another
rc,
you
know
we're
saying
this
is
a
platform
rfc.
E
Yeah
that
that
would
make
having
a
bad
team
rfc
would
make
sense
to
me.
I
think
it
I
think
we
would
probably
want
to
keep
the
rc
limited
to.
Should
we
do
this
and
not
how
do
we
do
this
to
avoid
that
bike
shedding
just
transferring
over
there,
because
it's
kind
of
kind
of
that
could
give
people
the
chance
to
vote
and
say,
like
you
know,
do
we
need
a
template
for
this?
You
know
library
or
this
particular
functionality,
as
opposed
to
just
like
you
know
what
actually
goes
into
every
line
of
the
file
yeah.
B
F
C
Cool,
thank
you
yeah.
I
I've
got
to
go
away
and
make
that
or
seem
much
more
self-contained
spell
things
out
and
yeah
make
sure
the
implementation
matches
the
rfc
so
that
we
can
argue
about
that
as
well.
So
thank
you
very
much.
C
A
Yeah,
I
think
one
thing
that
came
up
was
like:
where
do
we
want
to
host
our
bill
packs?
Like
the
actual
repository
registry?
My
suggestion
was
jhcr.
E
A
A
I
know
other
projects
that
I
am
involved
with,
use
it
so,
like
I
wanna,
for
example,
use
it
to
host
their
images,
and
that
gets
like
that's
gotten
so
400
million
downloads
out
of
ghcr
no
limits
nothing
to
be
made,
and
it's
easier
to
manage
tokens.
There
is
no
way
that
you
could
leak
tokens
or
prevents
one
like.
It
also
allows
you
to
discover
the
packages
right
with
the
repository
one
less
thing
to
worry
about.
A
F
F
This
is
kind
of
the
decision.
We'd
want
to
make
with
all
of
our
images,
rather
than
just
on
this
one.
I
feel
like
there's
a
lot
of
value
in
predictability-
it's
like
if
I'm
if
this
is
where
I
know
to
go
this
organization
on
docker
hub
to
look
for
images
published
by
the
project
and
then
we're
publishing
new
images
and
they're,
not
there.
That
doesn't
feel
right
to
me.
I
feel
like
I'd,
rather
have
a
story
about
migrating
everything
than
making
a
different
decision
in
this
case.
A
I'm
finally
done
so
docker
hub.
It
is,
although
I
would
like
to
discuss
the
ghcr
at
some
point
in
the
future,
so.
E
We
have
in
in
the
pipeline
builder,
tooling.
We
have
the
capability
of
publishing
to
multiple
places,
so
it
will
publish
to
the
primary
and
then
basically
just
copy
the
images
to
other
registries,
because,
like
right
now,
picado
we're
we're
primarily
publishing
to
gcr.
But
we
also
are
copying
to
docker.
E
A
E
Yeah
we're
only
doing
it
in
pacquiao
because
it's
legacy,
but
okay
yeah
I
can.
If,
if
you
can
set
up
secrets,
I
can
wire
that
into
the
pipeline.
A
E
Yeah,
if
you
look
at
that
workflow,
you
can
probably
see
the
name
of
the
secret
it's
expecting
and
just
match
them
up.
Yeah.
E
A
A
E
Yeah
yeah,
I'm
151.,
there's
kind
of
this
disconnect
with
the
profile
build
pack
that,
where
the
logger
gets
created,
the
logger
gets
created
by
libcnb,
but
then
the
like
the
build
and
detect
functions
that
that
we
generate
then
have
to
go
and
create
their
own
logger.
It
doesn't
get
passed
down
through.
A
E
And
it
used
to
it
used
to
get
passed
down
through,
because
the
build
and
detects
were
struck.
So
you
could
attach
it
to
that
struct
and
then
retrieve
it,
but
we
switched
them
to
functions
with
the
with
the
v2
and
so
there's
kind
of
a
disconnect
in
how
you
would
do
that.
There
are
some
ways
you
can
make
it
work.
I
don't
know
that
they're
particularly
elegant,
so
I
had
proposed
that
pr
as
a
possible
way
to
get
around
it,
but
it
does
change
a
function,
signature
which
I'm
not
happy
about.
A
F
I
wonder
if
a
more
future
proofy
thing
to
do
here
instead
of
passing
this
one
thing
down
would
be
to
have
like
you
know
like
build
options,
that's
where
you
could
do
the
you
know
like
with
vlogger
kind
of
thing.
A
E
So
that
that's
kind
of
what
we
have
now
so
when
you
create
there's
like
a
couple
layers
here,
so
when
you
do
the
initial
step,
you're,
creating
a
main
method
thing
and
you're
passing
in
a
list
of
options
that
you
want
to
set
the
main
method
converts
those
options
into
this
config
object.
That's
a
struct
that
that
has
stuff
that
is
mostly
specific
to
libc
and
b,
but
that's
also
where
the
logger
gets
attached
and
then
that
config
option
object,
does
not
get
passed
down
to
the
build
and
detect
function.
E
E
I
think
the
latest
proposal
was
to
pass
just
the
logger
through
yeah,
but
we
could
potentially
pass
like
the
config
object
or
create
some
new.
Like
you
know,
I
can't
think
of
the
right
word
that
I'm
trying
to
think
of
at
the
moment,
but
you
know
some
carrier
object.
That
would
you
know,
pass
options
through.