►
From YouTube: CNB Sub-Team Sync: BAT - 17 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
Extreme
sas
updates.
I
think
we,
I
can
repeat
what
we
gave
in
the
team
lead
saying,
but
we've
started
working
on
the
profile
buildback.
A
I
think
daniel
put
in
the
first
pr
to
scaffold
the
repository
with
the
dueling
that
we
agreed
and
I
believe
one
starts
morriston.
I
think
it
looks
good
and
we
should
be
able
to
move
it
and
we
can
proceed
with
the
implementation.
We
had
a
brief
discussion,
I
think,
with
a
smaller
group
last
week
and.
A
I
don't
think
it
will
take
a
lot
of
time.
The
idea
was
to
start
out
with
a
bash
based
exec
d
implementation,
so
the
build
pack
would
be
written
in
go
but
the
exact
d
that
will
convert
the
profile
script
into
an
exact
d
interface
with
itself
be
written
in
blast
just
to
avoid
any
inconsistencies
and
to
make
sure
that
the
profile
buildback
is
roughly
compatible
with
the
lifecycle.
A
We
did
discuss
a
few
edge
cases,
but
I
think
we
can
discuss
that
in
the
agenda
today
and
I
believe
we
planned
on
using
the
current
head
for
lip
cnb,
which
includes
the
2.0
changes
to
try
out
the
profile,
build
pack
and
then.
B
No
just
yeah
keep
an
eye
on
the
profile
build
pack,
it's
just
a
kind
of
example
of
how
things
are
gonna,
look
and
then
yeah,
there's
some
pr's
that
are
open
on
lip
cmd.
So
thoughts
on
those
are
appreciated.
B
I
definitely
would
like
to
talk
about.
I
don't
know
if
it's
on
there
about
the
the
templating.
A
A
A
I
also
had
a
really
small
agenda
item
about
like
the
timing
of
this
meeting.
I
know
ryan
is
here
today,
but
I
think
this
is
way
too
early
for
you,
so
I
just
wanted
to
confirm
quickly
like
if
this
works,
or
should
we
think
about
trying
to
schedule
it
a
bit
later.
The
only
issue
is
like
it
gets
fairly
late
for
london
and
there's
like
only
a
couple
of
hours
where
everyone.
D
I
I
don't
think
you
should
move
the
meeting
on
my
account
this.
This
one
is
like
the
7
a.m
is
usually
when
I
try
to
start
working,
but
sometimes
you
know
things
happen
in
the
morning
and
I
end
up
getting
in
a
little
bit
later
so,
like
I
try
to
be
able
to
make
this
meeting
and
yeah,
sometimes
you
know
life
happens,
so
I
wouldn't
move
it
on
my
account.
A
And
I
think
that's
pretty
much
it
for
the
agenda
today
and
I
think
one
last
thing,
which
is
the
format
of
this
meeting.
I
haven't,
had
a
chance
to
attend
one
of
these
bad
things,
since
we
introduced,
like
a
format,
change
in
some
of
the
other
sub
team
meetings
where
the
agenda
was
provided
ahead
of
time
and
advertised
and
if
there
was
no
gender,
the
meeting
was
cancelled.
A
So
I
also
just
want
to
talk
about
that
format
and
whether
we
want
to
try
it
out
for
this
meeting,
but
I
think
that's
pretty
much
it
for
the
agenda.
I'm
gonna
start
sharing
my
screen
again.
A
A
C
Yeah,
so
just
to
make
sure
that
people
are
all
on
the
same
page.
C
Currently,
if
you
do
pack
bill
packing
you
what
it
does
is
it
generates
you,
a
a
beautiful
new,
build
pack
using
some
shell
that
are
scaffolding
for
a
build
pack,
that
you
can
then
use
to
structure
your
own
build
pack
on
top
of
and
the
current
scaffolding,
and
that's
the
term
that
that
I've
been
using
to
describe
this
stuff
is
a
bash
shell
script,
scaffolding
which
is
great,
and
we
use
it
all
over
the
documentation
to
introduce
people
to
build
packs.
C
C
So
what
we
want
to
do
with
this
rfc
is
take
the
scaffolding
and
not
have
it
effectively
internally
impact
the
way
it
currently
is,
but
to
give
it
its
own
egg,
get
a
repository
or
repositories
somewhere
so
that
we
can
make
changes
there,
and
ideally,
one
provides
more
different
programming
languages,
implementations
of
bill
pack,
scaffolding
so
right
now
the
basic
one
is
bash,
but
lib
cmb
are
kind
of
a
golden
binding
to
this
is
in
goal
line,
so
it
would
make
sense
to
provide
a
goal
line
scaffolding,
but
also
then,
to
allow
other
projects
to
provide
scaffolding
for
build
packs
in
the
framework
or
languages
of
their
choice.
C
So
you
could
imagine
that
and
aiden
in
six
months
time,
with
too
much
time
in
his
hands
might
provide
a
haskell
bindings
to
lib
cnb,
and
you
could
then
write
your
high
school
scaffolding
and
then
you
could
write
your
bill
back
in
high
school
and
be
cooler
than
everybody
else.
C
So
that's
the
the
basic
proposal,
there's
kind
of
I
think
two
open
questions
on
it.
The
first
one
is
something
that
javier
commented
on
yesterday,
and
that
is
that
the
proposal
has
gotten
about
81
different
comments
at
this
stage.
C
So
does
it
make
sense
to
reduce
the
scope
of
the
proposal
to
simply
provide
a
new
way
of
replicating
the
old
functionality,
so
just
provide
the
the
bash
bill
pack,
scaffolding
at
this
stage,
and
then
the
other
comment
I
think
is,
is
what
daniel
and
I
have
been
discussing
on
it,
and
I
I
don't
know
daniel
if
you
got
a
chance
to
read
my
response
to
your
comments
yesterday,.
C
C
Well,
daniels
wrote
some
nice
questions
on
it.
There
should
be
a
lolish
thread.
B
C
So
if
you
were
to
change
the
pack
source
code
in
some
way-
or
you
were
to
change
the
apis,
that
pack
supported,
then
you
would
change
the
the
templates
in
sync
with
them
and
you'd
ship,
the
templates
with
pack
one
of
the
issues
there
is.
If
there
is
a
an
issue
with
templates,
then
we
have
to
ship
a
new
version
of
pac
and
particularly
if
the,
if
we
start
to
scaffold
other
programming
languages
by
default.
C
I'm
thinking
golang
in
particular
because
of
libcnb
that
scaffolding
might
be
more
complex
than
the
the
bash
scaffolding
and
there
could
be
issues
in
it
that
we
have
to
correct
and
we
might
want
to
correct
those
issues
without
shipping,
a
new
version
of
pack
and
by
decoupling,
the
skype
project,
scaffolding
from
pac.
C
It
allows
us
to
ship
new
templates
or
new
scaffolding
without
shipping
pack,
but
it
also
then
breaks
that
link
between
the
api
versions
that
pac
supports
and
the
api
versions
that
the
templates
might
support
or
the
scaffolding
might
support,
and
that
is
to
say
that
I
might
have
an
older
version
of
pack,
if
you
think
pack
version
0.25
or
something
which
doesn't
support
api
version
0.9,
and
maybe
the
templates
do
something
that
are
0.9
e.
C
I
suppose
the
question
is
then
becomes.
Does
pak
tell
the
project
scaffolding
that
it
wants
templates
of
a
certain
api
generated
or
yeah?
That's
what
how
do
we
handle
that?
How
do
we
manage
that?
Decoupling
between
pac
and
the
particularly
the
official
scaffolding.
C
It
practically
doesn't
matter
right
now.
The
only
thing
that
happens
is
that
in
your
build
in
the
tumble
file,
the
build
pack
api
version
gets
written
in
there,
but
I'm
imagining
places
in
the
near
a
future,
particularly
post
1.0,
where
we
might
have
changes
in
the
code
that
might
be
kicked
out
by
the
project.
Scaffolding
that
have
been
introduced
by
changes
in
the
project.
Spec.
B
E
There's
no
distribution
api
right.
What
do
you
mean
that
there's
no
such
thing
as
a
distribution,
api.
E
Okay,
I
I
guess
I'll
I'll
take
that
back.
Yes,
there
is.
E
Yes,
but
that
is
for
the
packaging,
I'm
assuming-
and
I
I
haven't
looked
at
this
part
of
the
pack
in
a
while,
but
I'm
assuming
we
do
actually
parse
out
the
build
pack
tamil
for
certain
parts
of
it,
and
I
think,
if
the
build
pack
api
change
is
and
therefore
the
build
pack
tunnel
structure
changes.
I
think
a
really
good
example
is
the
removal
of
stacks
right.
E
Where
now
you
have
targets
instead
of
make
sense
or
stacks
sorry
that
becomes
problematic,
potentially
right
like
that,
could
be
one
of
those
sort
of
like
potholes
you
hit
in
this
scenario,
but.
E
E
E
That
scenario
right
I'm
understanding
it
now
aiden,
but
that
scenario
is
that
you
use
a
template.
You
point
to
a
template
and
you
specify,
let's
say
oh
10
worldpack
api
and
that's
the
one
that
doesn't
have
stacks
anymore
right
and
now,
when
you
try
to
do
something
with
that,
buildpack
right,
it
no
longer
operates
with
the
current
version
of
pack
that
you're
using.
C
A
C
Do
we
get
packed
to
pass
the
versions
of
the
api
that
it,
the
current
pack
that
you're
using
supports
to
the
scaffolding
framework
and
and
get
it
to
generate
something
that
is
appropriate
to
the
the
api
version
that
you
want
to
target,
or
is
this
overthinking
the
problem
and
frankly,
it's
unlikely
to
come
up
in
practice.
A
But
there
are
also
other
tools
that
are
used
to
package
up
the
actual
bill
pack.
So,
for
example,
pacato
uses
jam
to
package
up
the
build
packs
and
like
if
you
are
coupling
the
packaging
of
the
build
pack
to
the
same
version
of
pack
that
scaffold
it.
The
repository,
which
I
don't
think
is
always
going
to
be
the
case.
A
E
E
Cool,
so
I
agree
with
effectively
the
sentiment
that
it's
somewhat
overthinking
it
or
over
complicating
it,
because
the
worst
case
scenario
is
you.
D
E
A
Yeah-
and
I
think
this
also
gets
to
the
point
where,
like
packs
of
two
purposes
right
now,
like
it's
the
entry
point
for
a
bunch
of
dev,
tooling
related
to
the
project,
it's
also
a
platform
that
like
runs,
builds
and
packages
things
so
like
it.
It's
like
an
all-in-one
thing
and,
like
the
more
you
try
to
couple
all
of
these
things
together
the
more
difficult
it's
going
to
be.
A
B
So
re
rewinding
this
thread
a
little
bit
like
the
conversation
started
originally,
because
what
I
was
asking
about
was
there
are
certain
fields
that
you
could
maybe
call
common
across
a
lot
of
templates
like
the
build
pack
api.
You
know
if
you're
going
to
generate
a
new
build
pack,
you're,
probably
going
to
have
to
set
the
build
pack
api,
and
so
the
question
was
kind
of
along
the
lines
of
like
you
know.
Don't
repeat
yourself.
B
Is
there
a
way
that
we
can
have
that
question
asked
like
stand
but
as
like
a
standard
question
and
not
have
to
have
every
template
author?
Have
that
information,
because
you
know,
presumably,
as
a
template
author.
If
I
want
to
ask
that
question,
then
I
have
to
have
a
list
of
the
api
versions
in
there,
so
they
can
select
from
that
list.
A
But
isn't
that
the
point
so
like
if
you're
using
a
golang
template-
and
you
have
lip
cnb
and
like
you-
would
always
have
to
provide
a
range
of
versions
like
you
can't
you,
you
will
have
to
update
your
template
to
use
the
new
version
of
libsynb
if
you
want
to
support
a
new
api
and
there
might
be
templates
such
as
support.
One
api
like,
for
example,
like
let's
say,
picado
wants
all
of
its
build
packs
scaffolded
using
the
new
template
to
be
on
buildback
08.,
like
what
what's
wrong
with
just
skipping
that
prompt
entirely.
B
Yeah
I
mean,
I
guess,
that's
true,
you
know
we
could
just
have
it
like
hardcoded
in
the
template.
You
know
to
whatever
we
want
it
to
be.
I
guess
I
was
and
I
could
be
making
a
problem
out
of
nothing
too.
You
know
I
don't
know
how
many
templates
we
will
end
up
with.
If
that
you
know,
is
actually
an
issue.
A
I
think,
even
if
you
you
do
have
to
like
select
like
you,
do
have
to
provide
an
api
that
the
template
is
only
going
to
support
a
range
of
apis
like
if
you're,
making
a
complex
enough
template
like
the
simple
bastion
played
fine.
It
was
so
simple
that
you
could
always
just
go
with
one
api
version
like
any
any
api
version.
B
Yeah
yeah
now
I
get
what
you're
saying
I
think
on
like
on
the
picato
side
with
the
pack,
because
we
kind
of
build
on
top
of
libsy
and
me
we
have
less
of
that.
But
now
I
I'm
fine,
I'm
fine
to
to
disregard
this.
If
it
makes
things
more
complicated,
that's
you
know.
I
don't
want
to
do
that
at
this
point
I
was
just
more
of
a
curious
curiosity.
You
know,
don't
repeat
yourself
kind
of
thing.
C
Oh,
I
I
I
like
the
question
and
I
I
think
I'm
leaning
towards
what
javier
was
saying
that
maybe
what
we
need
to
do
is
just
focus
on
getting
this
working
for
a
single
template.
Url,
and
maybe
we
have
you
know
we
we
iterate
on
that
from
there.
So
if
I
focus
it
down
on
just
running
a
single
template
that
that's
provided
as
as
the
default
and
then
a
way
of
updating
that
in
future,
then
I
I
suspect,
once
we
get,
I
think
this
rfc
is
there
or
thereabouts.
C
People
generally
are
happy
with
it.
They
generally
like
the
direction
it's
going
in.
If
we
can
provide
the
update
the
rfc
and
provide
a
proof
of
concept
implementation,
then
I
I
think
we
can
argue
about
the
details
after
that.
How
does
that
sound
to
people.
A
Yeah,
I
am
generally
happy
with
the
rfc.
I
think
the
the
format
looks
fine.
A
The
the
only
thing
I
would
like
to
see
addressed
here
is
like
what
we're
going
to
use
if
you're
diving
into
implementation
details
right
here
and
if
you're
going
to
write
your
own
thing
where,
where
that
specific
library
would
live,
given
your
proof
of
concept
that
exists
right
now,
I
think
the
amount
of
code
there
is
fairly
low
and
I
would
also
believe,
fairly
low
maintenance.
So
I
don't
know
if,
like
javier
wants,
it
impact
itself
as
a
separate
repository
owned
by
the
buildbacks
project,
or
we
want
it
in
some
other
organization.
B
Yeah
I
was,
I
was
curious
about
the
and
I
don't
know
if
this
needs
to
be
in
the
rfc
or
not,
but
the
repository
format
for
the
templates.
It
is,
I
think,
a
question
came
up
around
like
do.
We
want
to
be
able
to
have
multiple,
you
know
templates
in
a
single
repository
or
like
as
libc
and
b
could
we
have
a
slash,
scaffold
folder
that
has
our
scaffolding
in
it.
You
know
or
something
like
that.
So
I'd
be
curious.
C
Yeah,
so
the
idea
was
that
we
could
have
multiple
templates
in
a
single
repository
or-
and
I
I
think
again
going
on
what
javier
was
saying
and
javier
I'm
not
trying
to
put
words
in
your
mouth.
So
please
correct
me
if
I'm
wrong,
if
we
just
focus
on
having
like
what
you're
saying
down
your
single
template
single
repository,
make
this
work,
get
it
at
the
door
and
kind
of
iterate
from
there,
then
that
that
sounds
like
a
better
direction
to
take.
E
Yeah
because
I
I
think,
ultimately,
the
part
that
maybe
I'm
getting
a
little
bit
confused
about
in
in
some
of
the
existing
rfc
is,
it
brings
about
a
lot
of
different
details
right.
It
talks
about
what
the
bow
structure
format
is
going
to
be,
whether
it's
going
to
use
text
frameworks
or
not
it
talks
about.
It
doesn't
really
talk
about
the
url
format
right
like
whether
or
not
we're
doing
subdirectories
or
not.
E
So
I
think
if
we
want
to
focus
on
just
the
functionality
of
what
we're
trying
to
provide
and
and
really
only
focus
on
that,
then
you
know
future
iterations,
future
rfcs
that
say
hey.
We
want
to
provide
a
standard.
You
know
for
lea
lib
cnb,
that's
in
its
own
rfc
right
and
that's
what
the
structure
is
going
to
be
and
so
forth.
C
A
C
A
E
You
know
that's
a
funny
question.
I
I
don't
know
that
I
have
a
strong
opinion
on
that
right
because,
as
long
as
the
project
itself,
like
let's
say
it
remains
on
aiden's,
you
know
name
or
whatever,
we
could
always
fork
it
if,
for
some
reason,
aiden
disappears
and
doesn't
want
to
work
with
us
anymore
right.
So
I'm
not
too
concerned
there.
So
yeah,
I
don't
have
a
strong
opinion.
A
E
E
And
if
we
do
that,
I
guess
there's
more
to
talk
about.
If
that's
the
route
we
want
to
take
right.
If
it
stays
on
aiden's
repository,
then
that's
fine.
I
don't
think
there's
anything
to
discuss
if
we
want
to
say
hey
we're
gonna
bring
this
new
tool
called
scaffold
into
the
project.
Is
that
its
own
rfc?
Is
that
part
of
this
rfc
and
then
do
we
need
to
talk
about
who's,
going
to
sort
of
what
team
it
falls
under?
Does
that
make
sense
yeah?
E
A
C
A
E
E
I
guess
I
don't
even
know
what
that
effectively
looks
like
right
to
ever
say
that
that
would
be
a
true
statement
because
to
me,
like
the
you
know,
the
current
version
and
whether
it
supports
subdirectories
or
not
like
that,
could
be
a
final
state
right
and
as
long
as
you
can
make
templates
of
other
languages,
you
might
need
additional
tweaks
in
the
future.
But
that's
true
for
either
cases.
A
I
think
the
the
main
difference
for
me
is
like
let's
say
we
use
a
library
like
ggcr.
We
know
that
we
are
getting
into
it
with
like
here's
the
list
of
features
we
it
supports
and
okay
we're
going
to
use
all
of
that
and
anything
it
doesn't
support.
We've
added
support
for
that
in,
like
image
util
or
back.
A
E
Yeah,
I
think
the
definition
of
vp
might
be
different
right.
So
for
me,
I
don't
like
using
the
term
mvp
for
this,
because
I
think
the
functionality
should
be
fully
fleshed
out
in
this
rfc
right.
The
part
that
I
want
to
exclude,
or
I'm
proposing
to
exclude,
is
all
the
different
language
templates
yeah.
B
Sure
so
we've
been
exploring
this
on
the
piketto
side,
primarily
because
we've
got
a
lot
of
spring
boot
and
java
users
that
are
getting
m1
laptops
and
are
having
trouble
with
their
build
packs.
B
What
we
did
to
kind
of
as
a
stop
gap
was
put
some
tools
together
that
allowed
people
to
build
their
own
builder,
so
they
would
essentially
go
through
and
recompile
the
build
packs
so
that
they're
compiled
for
arm
64
and
then
it
would
repackage
things
into
an
image
that
is
compatible
with
arm64
and
then
just
rebuild
everything
takes
like
10
minutes
or
so
and
not
a
big
deal.
B
B
Pac
will
only
package
it
for
the
current
architecture,
and
so
I
opened
an
issue
with
pac
after
talking
a
bit
with
javier
about
that,
so
that
that
is
kind
of
out
there.
If
that's
something
that
that
other
folks
think
they
would
would
be
important.
Maybe
you
know
thumbs
up
that
issue.
You
know
or
add
feedback
as
well.
The
other
one
that
came
up
was.
B
I
can
never,
I
don't
know
the
exact
term
for
it,
but
it's
like
a
manifest
image
or
a
multi-arc
image,
that's
kind
of
a
blocker
for
us
on
the
page
side,
because
we
we
don't
want
to
have
to
publish
our
images.
As
you
know,
hyphen
you
know
arm
64
or
something
like
that.
You
know
we
want
to
be
able
to
have
our
single,
consistent
image
name
and
then
just
have
the
client
pick.
Whatever
is
correct,
so
we
will
need
to
do
that
before
we
can
publish
like
official.
B
You
know
paquetto
images
that
support
it.
So
I
opened
up
another
pack
issue
for
that
and
so
again,
if
that's
something
that
that
is
a
feature
that
that
you
think
you'll
need.
Definitely
you
know
thumbs
that
thumbs
up.
That
too
or
add
comments,
but
aside
from
that
you
know,
building
you
know
multiple
architectures.
You
know
it
really
wasn't
that
bad.
You
know
the
existing
tool
set
supports
it.
You
know
we've
got
pac
compiled
in
you
know
for
arm64.
B
A
B
That
that
is
something
we've
avoided
so
far.
We
have
not
been
publishing
these
to
the
registry
and
that's
a
good
point.
That's
actually
something
I
didn't
I
didn't
consider,
but
but
yeah
I
think
the
registry
is
gonna,
have
to
probably
have
some
additional
support
as
well.
You
know
it
would
be
nice
to
be
able
to
go
to
the
registry
and
see
you
know
what
supports
you
know,
x86.
What
supports
arm
that
sort
of
thing.
A
Here's
the
difficult
thing
so
like
let's
say
you
have
one
buildback
normal
for
your
arm
version,
another
one
for
your
x86
version.
Would
you
expect
the
name
to
be
same
with
the
other
properties
of
buildback
download.
B
Right
now,
the
way
that
we're
building
it
is
so
picketto
stores
dependency
information
in
buildpackton
metadata.
We
are
just
updating
that
to
point
our
arm:
64
compatible
binaries,
and
that's
it
we're
not
changing.
You
know
what
I'd
have
to
double
check.
If
we're
changing
the
id,
I
think
we
actually
are
because
right
now,
it's
packaging
them
with
the
dash
arm64
hyphen,
but
I
think
ideally
we
would
not
want
that.
We'd
want
everything
to
appear
to
be
the
same.
A
A
A
think
as
of
right
now,
if
you
build
two
different
images
in
pack
and
publish
it
using
docker,
you
might
be
able
to
publish
the
appropriate
images.
If
pack
just
supported
the
platform
option
in
docker
to
be
passed
from
pac
build,
you
might
be
able
to
build
two
different
images
with
the
same
name
and
then,
if
you
do
docker
push,
you
will
get
the
proper
index.
I
believe,
because
docker
push
will
populate
all
the
required
things.
B
A
B
B
Okay,
yeah,
I
don't
know
that.
I
don't
know
that
for
build
and
dash
dash,
publish
that
that's
an
issue,
because
I
I'm
assuming
that
users
are
going
to
build
for
whatever
they're
on
you
know,
for
whatever
architecture
they're
running
on.
So
it
would
just
be
like
a
single
architecture
image.
D
Moon
pattern
tends
to
be
like
the
common
pattern
tends
to
be
like
someone
wants
to
build
arm
64
for
their
like
workstation,
that
they're
working
on
actively
like
working
on
something
and
then
they
maybe
are
probably
building
x86
in
production,
but
like
that
image
is
built
like
by
a
ci
system.
That's
right
in
the
cloud
somewhere
and
so
like
in
each
case,
you
have
two
different
systems,
doing
the
build,
not
that
they
would
like
build
both
their
like
dev
image
and
their
production
image
on
their
laptop
and
then
somehow
push
them.
B
Yeah,
okay,
yeah!
It's!
Basically
when
we
package
you
know
so
pack
build
pack
package
needs
to
be
able
to
support
that,
and
then
pack
build
sorry
pack,
builder
packet
or
pack
builder,
create,
I
think
it
is,
would
have
to
support
it
as
well.
That
way,
so
so
from
a
build
pack
consumer
standpoint,
they
don't
have
to
care
about
the
architecture.
The
system
just
picks
whatever
is
appropriate,
but
the
image
that
gets
published
when
they
do
a
build
would
be
for
a
single
architecture,
whatever
they're
running
at
the
time.
A
So
so
there
are
probably
two
separate
issues
for
the
higher
level
multi-arc
support.
One
is
like
just
being
able
to
package
the
build
packs,
so
a
consumer
can
use
the
same
set
of
build
packs
to
build
regardless
of
the
platform
they're
running
it
on
and
then
for
the
build
step
itself
being
able
to
do.
Multiple
arc
builds
for
like
different
platforms,
but
using
the
same
machine.
B
B
Okay,
cool
yeah.
It
sounds
like
we're
on
the
right
track
with
the
issues
we
have
opened
and
maybe
just
need
to
get
some
a
conversation
going
around
the
registry
to
see
what
has
to
change
there
so
that
we
can
advertise
it.
B
A
B
I
think
that's
up
for
debate
yeah,
I
think
that's
a
and
that
I
mentioned
that
on
the
the
issue
I
opened
with
pac
is
that
I'm
not
totally
sure
what
the
best
direction
there
would
be
like
like
right
now
we
we
are
packaging,
individual
architecture,
specific
images,
so
we
could
make
a
third
call
to
pack
that
then
combines
them
or
we
could
try
to
like
pre-compile
all
our
build
packs
first
and
then
pass
everything
into
pack
in
one
go,
and
it
would
just
do
you
know,
quote
the
right
thing:
yeah,
I'm
not
really
sure
what
what
the
interface
there
should
look
like.
E
E
Yeah,
I
I
think
I
don't
know
yeah
like
for
sure.
I
don't
know
that
I
would
be
the
the
appropriate
person
to
even
start
beginning
to
you
know,
write
the
rfc
I
feel
like.
I
would
need
somebody
from
first-hand
experience
on
packaging
build
packs,
so
maybe
from
the
potato
team
or
bloomberg
team
to
start
thinking
through
the
ux
of
what
they'd
like
to
see.
A
E
B
Try
try
doing
a
java
native
image
build
and
then
then
you'll
see
the
problem
yeah.
I
I'd
be
happy
to
help.
You
know
with
an
rfc.
If
you
want
to
collaborate
on
that.
You
know
I've
got
some
experience
with
our
ci
and
we
could
pull
in
someone
else
from
pocketo
too.
That
you
know
is
experienced
with
the
ci
systems
to
make
sure
that
we're
implementing
it
in
a
way
that
be
easy
to
automate.
E
B
It's,
I
would
say,
like
medium
term
like
arm
64,
is
on
the
pacquito's
2022
road
map,
so
we're
trying
to
have
something
this
year.
B
A
And
I
think
we
have
the
last
agenda
for
this
meeting
then,
which
is
the
format
of
this
meeting.
I
know.
Sometimes.
This
meeting
also
serves
as
like,
like
a
forum
for
buildback
authors
to
like
use
as
sort
of
an
officers
which
is
sort
of
overloading
this
meeting
anyway.
But
but
people
be
comfortable
with
like
having
a
free,
decided
agenda
which
is
like
where
we
ask
for
the
agenda
items
a
couple
of
days
before
the
meeting,
and
then
we
have
time
boxed
agenda
items
on
the
meeting
day
itself.
E
I
I
have
no
opinion,
but
I
will
throw
in
my
sort
of
rather
small
experience
that
I've
had
with
this
strategy,
which
we
employ
in
platform
and
office
hours,
and
I
I
feel
like
just
in
general.
This
project
might
not
be.
It
hasn't,
built
a
habit
yet
of
setting
up
an
agenda
ahead
of
time.
So
just
keep
that
in
mind
that
meetings
might
become
more
scarce
and
maybe
that's
a
good
thing,
but
that
is
a
side
effect
that
we're
seeing
elsewhere.
A
I
think
we
can
try
it
for
a
couple
of
meetings.
If
it
doesn't
work,
we
can
always
fall
back,
but
I
think
for
the
next
meeting,
I'm
gonna
ask
for
agenda
items
a
couple
of
days
before
I'll
also
try
putting
it
on
our
slack
channel
center
too.