►
From YouTube: Implementations Sync: 2020-09-17
Description
* Status Updates
* Release Planning
B
B
A
A
A
B
A
A
A
B
The
problem
is
we're
statically,
compiling
in
libsy
or
muscle
lib
seams
with
the
run
on
alpine,
and
we
need
to
install
the
specific
dependencies
we
need.
First,
if
you
want
a
pr
to
make
it
faster,
all
right
happily
accept
it.
I
don't
think
there's
a
big
technical
barrier
to
making
it
faster.
If
like
no
one's
done
it
yet
just
work.
Yeah
yeah.
A
B
C
B
C
No,
I
think,
no
issues.
I
think
the
implementation
has
been
fairly
smooth,
we've
run
into
issues,
but
it's
mostly
our
own
things
with
like
the
runners
on
github
actions
and
stuff
like
that,
but
I
think
micah
did
bring
up
some
potential
changes
to
life
cycle
related
to
permissions
or
something
as
a
result
of
this,
but
I
think
it
was
determined
that
we
can
address
them
via
pac
rather
than
a
life
cycle
change.
B
A
A
We
need
it's
always
duplicated.
Tech,
like
every
platform,
has
to
do
basically
at
least
a
few
of
the
same
things
with
like
you
know,
mounted
folders
and
stuff
that
makes
making
sure
ownership
is
correct
before
you
do
it,
and
you
have
to
do
things
like
know
what
user
id
up
front
to
do,
and
you
know
you've
got
to
kind
of
inspect
it
at
one
time
to
do
that.
B
Once
upon
a
time,
we
had
such
a
thing,
but
it
and
we
used
in
at
that
time
it
was
k
native
build,
but
the
precursor
to
tecton.
We
ended
up
removing
it
because
we
made
changes
to
the
point
where
the
only
thing
it
was
doing
was
troning
directories
and
it
seemed
like
overkill
to
have
a
you
know,
a
binary
that
we're
shipping
that
this
does
the
equivalent
of
two
trunk
commands.
So
we
just
switched
out
for
the
trunk
commands
in
the
template.
A
B
B
A
Yeah,
the
breakout
is
probably
going
to
get
overloaded,
but
I
kind
of
at
least
wanted
to
mention,
like
caching
like
it
seems
like
it's
going
to
be
a
pretty
hard
problem
to
solve.
I
think
just
because
even
the
simplest,
like
stack
pack
example
of,
like
you,
know,
apt-get
install
packages,
you
know
if
you
wrote
one
today,
you'd
probably
run
you
know,
apt-get
update,
which
is
going
to
update
the
sources
list
and
thinking
about
a
cache
scenario.
A
If
we
use
the
snapshot
as
the
cache,
then
when
you
come
back
like
you
know,
you're
gonna
have
to
you're.
Probably
gonna
want
to
do
an
apt-get
update
again
to
see
whether
you
need
to
do
anything
on
the
on
the
next
build
and
that's
going
to
change
the
snapshot.
So
you
won't
be
able
to
use
the
snapshot
from
before
so
there's
no
way
to
immediately
at
least
apparently
to
like
communicate
like
okay
yeah.
I
you
know
there
are
going
to
be
changes
to
that
source
list
of
other
packages.
A
You
probably
don't
care
about,
but
if
you
were
just
trying
to
install
like
ffmpeg
or
something
then
you're
gonna,
you're
gonna
bounce
out
in
the
build
and
be
like.
Oh,
I
don't
need
to
do
anything.
You
already
have
this
version,
but
now
we
have
to
create
a
new
snapshot.
I
think
because
the
source
file
has
changed.
B
I
think,
if
we're
talking
about
like
the
package
index
and
cache,
I
thought
at
one
point.
There
was
an
idea
that
you
could
specify
paths
within
the
snapshot
that
wouldn't
be
included
in
the
exported
layer,
but
could
be
cached
so
like.
Maybe
we
would
take
a
single
we'd
use
the
mechanical
implementation
to
create
a
tar.
That
is
a
snapshot
the
way
we're
doing
now.
But
then
we
ourselves
could
read
through
the
tar
and
sort
things
in
it
into
either
a
cache
layer
or
a
launch
layer.
A
I
do
know
that
there's
exclude
somewhere
in
there.
That's
that's
meant
to
exclude
from.
I
thought
it
was
from
everything,
but
I
guess
to
your
point,
you
know
maybe
exclude
needs
to
be
specific
for
whether
it's
the
launch
layer
or
the
cache
layer,
because
you'd
want
to
keep
the
sources
for,
but
you
know
yeah,
you
wouldn't
want
them
in
the
launch,
but
you
put
them
in
the
build
cache
or
whatever.
Next
time.
B
B
We
haven't-
I
talked
about
this
as
a
group
yet,
but
in
my
mind,
even
though
I
know
the
snapshot
generates
one
layer,
I
want
us
to
like
manually
split
it
into
multiple
layers,
and
so
then,
after
that
we
can
think
about
them.
Like
we
do
our
normal
layers,
we
can
say:
oh
we're,
restoring
it.
I
mean
there'll,
obviously
still
be
differences
given
restores
root
and
stuff
like
that,
but.
A
C
B
A
Oh
well
so
yeah,
I
was
thinking
the
life
cycle
right
now,
the
it's
implemented
in
the
builder
part,
and
it
just
does
a
like
in
each
group.
It
takes
a
single
snapshot
if
it
could
just
call
snapshot
twice
once
for
with
two
different
path
sets
like
at
the
same
time.
So
a
single
right.
I
wonder
if
we
can.
A
B
A
A
B
A
Yeah
exactly
right
now
for
the
build
only
things
it's
taking
snapshots
needlessly.
I
think,
because
there's
just
no
yeah,
I
I
guess
the
the
problem
is,
I
think
he
was
building
it
out
at
first
to
do
the
run
image
extend,
but
we
just
haven't
got
there
yet,
and
so
I
guess
you
won't
yeah,
and
I
guess
we
don't
even
need
snapshots
yeah
with
no
cash.
We
just
never
need
snapshots.
Is
that
right.
B
B
A
B
B
A
Yeah,
we
haven't
got
anywhere
near
that
yet
because
we're
just
talking
about
the
restore
phase
of
the
build
right
now
and
that's
already
complicated
by
the
fact
that,
even
if
we
store
all
these
top
guitars
for
cash
like
restore,
can't
actually
do
and
restore
them.
The
builder
is
going
to
have
to
do
it,
because
it's
the
thing
that
runs
his
route
unless.
B
A
A
B
B
A
B
A
A
B
A
B
A
Yep
that
makes
sense
yeah.
I
think,
when
I
get
to
start
storing
cash
I'll
have
to
figure
out
I'll
get
deeper
into
where
we
need
to
store
things,
but
I'd
like
to
keep
the
layers
directory.
What
I
was
talking
about
right
now
that
the
current
implementation
just
stores
a
tarball
on
the
layers
root,
but
I
actually
think
I
want
to
make
like
a
known
snapshot
directory
that
we
put
the
put
the
tar
balls
in
just
like
you
do
for
the
other,
build
packs
so
that
you
know
everything's
in
the
same
directory
structure.