►
From YouTube: Implementations Sync: 2021-04-08
Description
Meeting notes: https://bit.ly/38pal2Z
A
B
A
A
B
At
least
there's
bad
just
something
like
that
right
that
could
unlock
some
use
cases,
even
if
we
don't
get
to
the
run
image
part
of
it,
which
is
what
folks
are
mostly
after.
I
think
right.
It's
getting
apt
packages
on
the
run
image,
but
use
getting
app
packages
dynamically
for
for
just
building
is
also.
You
know,
a
pretty
sizable
task
that
delivers.
A
A
Would
allow
the
code
to
evolve
and
not
leave
other
features
out,
so
we
talked
about
making
a
feature
branch
for
stack
packs,
but
that
makes
it
difficult
to
constantly
be
re-raising
that
branch
off
of
new
stuff
that's
merged
in.
I
feel
like
if
we
hit
it
behind
a
feature
flag.
At
the
very
least,
we
could.
C
B
B
Oh,
no,
I'm
saying
I
think
we
could
probably
block
it
like
you.
Don't
get
stack
pack
code
unless
your
unless
stack
packs
exist
on
your
stack
with
a
with
a
group
tunnel
or
whatever
right.
So
I
think
it's
effectively
guarded
by
that
now.
Obviously,
if
we
want
to
protect
our
users
from
using
a
feature
that
is
not
yet
finished,
we
can
add
something
to
kind
of
front
end.
B
B
I
think
because
I
I
don't
want
to
get
in
a
situation
where
we
have
like
such
different
code
and
build
that,
like
you
know
as
soon
as
you
turn
it
on,
it
affects
images
that
don't
even
have
anything
to
do
with
stack
packs
like
I'd
like
to
be
able
to
make
sure
we're
catching
any
of
those
type
of
errors.
As
soon
as
we
start
writing
code
in
builder
detector.
B
C
A
It
might
be
worth
just
restating.
You
know,
like
the
current
agreement
that
we
we
have
is
that
you
know
stack
packs.
Will
ship
info
in
the
next
set
of
apis,
so
anything
that
we're
discussing
here
would
you
know,
have
to
be
kind
of
a
conversation
that
we
have
with
the
community
and
yeah.
So
I
just
brought
it
up
as
something
that
occurred
to
me,
but
it's
just
worth
stating
again
what
we're
aiming
for.
D
So
so
I
think
because
of
that
there
there
is,
that
hurdle
or
like
that
high
risk
that
there
would
be
a
lot
of
maintenance
burden
and
then,
on
the
other
side
right
the
the
worst
case
right.
Is
you
complete?
Some
of
the
work
from
these
stack
packs
merge
that
into
main
and
for
some
reason,
let's
say
the
the
work
in
its
entirety
isn't
completed
right,
but
for
some
reason
you
still
want
to
be
able
to
release
something
right
and
like
let's
say
you
bump
it
out
to
the
next
version.
D
That
seems
more
achievable
in
a
sense
than
having
to
maintain
a
rebase
right
like
you
could
always
like
you
know,
jesse,
depending
on
the
architecture.
Right
like
there
should
be
very
specific
entry
points
in
which
you
could
just
block
those
off
right.
I
know
that
there
was
the
idea
or
intention
of
when
we
had
like
the
multi-supported
api
versions.
D
We
had
like
the
deprecated
the
supported,
and
I
believe
there
was
an
experimental
I
don't
believe
experimental
went
in,
but
that
was
more
or
less
the
idea
right
like
that,
was
an
experimental
mode
that
you
could
also
get
into.
So
you
could
like
gate
it.
You
know
through
other
means,
via
like
the
experimental
stuff
you
could
do.
What
is
that
thing
called?
I
know
in
go.
You
could
add
tags
to
code.
D
That
would
basically
guard
that
off
as
well
per
build
and
so
like
there's
different
mechanisms
in
which
you
could
essentially
remove
the
functionality
as
long
as
it's
architected
well
with
a
strategy
of
or
thinking
that
you
might
want
to
guard
it
off
at
some
point,
and
that
seems
like
a
lot
less
of
a
burden
than
having
to
maintain
this.
Like
separate
branch.
C
C
It
was
not
a
good
idea,
so
I
agree
that
it
like
feels
very
easy,
but
probably
it
won't
be,
but
I
think
it's
very
important
to
keep
it
like,
as
you
said
like
separate
somehow
in
the
main
brand
just
in
case
it
will
take
us
like
longer
time
than
we
expected
and
we'll
decide
to.
I
mean
make
another
release
without
stop
stack
backs
so
just
skip
the
option
like.
B
A
A
A
D
So
it
sounds
like
right
now,
you're
at
the
step
of
just
identifying
what
the
pieces
of
work
are
right
then
I
would
assume
we'd
want
like
a
t-shirt
size
like
estimation
of
like
these
are
the
big
ticket
items.
These
are
the
tiny
little
bits
and
that
might
help
generally
gives
give
us
a
better
understanding,
right,
yeah.
A
Do
we
want
to,
is
there
anything
more
to
say
at
this
time
about
stack
packs,
or
should
we
move
on
to?
Essentially,
I
think,
there's
I
say:
release
planning,
but
we
we
just
shipped
and
the
next
release
is
all
stack
packs
with
a
few
exceptions
which
might
be
worth
looking
at
here:
sports
backpacks
and
then
some
of
these
other
ones.
We've
got
windows
chores.
This
is
part
of
stackpacks
part
of
stackpacks.
A
B
B
A
B
D
B
D
So
so
I
think
this
is
where
my
concern
comes
in
it,
and
I
definitely
hear
the
side
of
trying
to
get
stack
packs
done
right.
But
at
this
point
in
time
it
seems
like
the
strategy
is
that
nothing
feature-wise
right
is
is
going
to
be
released
by
the
life
cycle
without
stack
packs.
So
in
essence,
asset
packages
right
are
essentially
blocked
by
stack
packs
and
whatever
that
time
frame
may
look
like
right.
We
haven't
done
the
exercise,
but
assuming
three
to
six
months.
D
That
means
whoever
wants
you
know
I
I
know
sam
put
in
some
p
rfcs
for
other
things
like
it
seems
like
again,
a
high
risk
to
expect
that
we'd
be
blocking
anything
from
going
in
for
stack
packs,
which
again
I
I
totally
understand,
and,
and
I
stand
by
what
we're
trying
to
achieve.
But
at
the
same
time
I
think
that's
what
bring
this
idea
of.
A
Especially
because,
like
we
just
said
right
actually
cash,
the
work
for
that
is
so
minimal
right.
It's
like,
I
don't
know
about
process
specific
working
directories,
and
I
know
that
the
sid
is
the
said.
Stuff
is
complex,
but
I
think
this
is
something
that
we
we
should
continue
to
have
the
conversation
right
like
I
guess.
B
B
B
It
could
be
wrong,
but
I
do
think
we'll
as
long
as
we
continue
to
have
this
discussion
and,
like
you
said
we
could
kind
of
weave
through
and
and
bump
it
to
to
a
different
spec
version
or
a
feature
flag
or
something
like
we'll
have
to
constantly
weigh
that
of
like
okay.
If
we
really
want
these
features
out,
it's
been
two
months.
B
B
Kick
acceptance
test
out,
like
I
can't
imagine
anyone's
going
to
get
to
build
an
acceptance
test
with,
with
the
amount
of
work
stack
taxes
on
there
unless
someone
just
really
wants
to.
I
think
it's
like
a.
If
someone
gets
to
it
that
that's
cool,
I
know
what
he
said
previously.
We
would
try
to
get
acceptance
tests
in
every
release,
but
I
worry
that's.
A
A
A
We
definitely
already
discussed
the
first
one:
support
stack,
build
packs
and
the
other
one
is
it
possible
to
export
a
tar.
Ball
might
be
a
left
we,
we
did
discuss
it
last
week,
but
I
think
there's
still
conversation
to
be
had
I'm
not
sure
if
we
want
to
have
it
now
or
what
would
be
the
right
way
to
move
that
forward.
D
I
do
have
some
interest
in
in
this
particular
topic
because
of
the
build
kit
effort.
I'm
trying
to
you
know,
help
push
or
drive
that
through
I've.
I've
recently
reached
out
to
eric
to
see
whether
or
not
he'd
be
able
to
show
up
on
one
of
the
working
groups
or
office
hours,
so
we're
still
pending
there,
but
no
matter
what
I
think.
D
We've
gotten
a
decent
amount
of
findings
from
the
stuff
that
he's
done,
that
we've
identified
right,
that
the
exporter
will
need
some
work
in
order
for
build
kit
to
to
be
functional,
and
this
ties
directly
to
that.
So
I'm
not
entirely
sure
like
where
it
falls.
I
feel
like
the
build
kit
effort
definitely
falls
on
the
platform
side
of
things.
You
know
you
could
consider
it
another
platform
integration,
but
the
request
for
the
lifecycle
to
export
to
ocilla
yeah
in
oci
layout
right.
B
B
The
same
a
similar
situation
where
a
creator
is
not
going
to
immediately
be
able
to
do
stack
packs,
and
so
I'd
like
to
understand
like
how
that
relates
to
build
kit
as
well.
I
think
bill
gets
a
little
more
flexible
and
how
it
you
know
it's
apis
at
a
little
lower
level,
so
probably
be
able
to
do
it.
But
I'd
have
to
I'd
like
to
understand
that.
D
D
B
I
won't
say
I
won't
have
time
to
do
it,
but
it's
just
hard
to
commit
completely,
because
I
know
my
you
know.
My
time
is
needed
for
some
of
the
stack
stuff
as
well
and
so
yeah,
and
also
I'm
just
worried
about.
Like
you
know,
I
think
that
would
have
to.
I
guess
I
guess
it
could
happen
in
a
patch
release
if
we
like,
if
it
was
like
a
library
change
right,
because
the
whole
point
of
bill
kids
is
that
it's
basically
referencing
lifecycle
as
a
library.
Isn't
that
right.
B
B
A
Cool,
so
one
other
thing,
I
I
don't
believe
we've
at
least
I
haven't
discussed
this
with
emily
and
I
feel
like
I'd,
want
to
get
her
thoughts
first,
because
I'm
sure
she
she
has
some
and
that
might
guide
you
know
what
else
we
do
next
right.
So
I
think
that's
something
that
we
can
do
now
right.
We
can
talk
to
her
about
it.
B
D
B
A
B
Natalie's
running,
we
had
a
meeting
just
before
this
meeting
to
do
the
board
that
you
saw
that's
in
the
google
doc
and
I
think
we're
going
to
do
another
session
of
that
and
then
from
there
we'll
push
them
into
github
and
presumably
t-shirt
size
them
either,
and
that's
the
next
meeting
or
or
a
follow-up
after
that
attack
them
all.
I
guess
cool.