►
From YouTube: Implementations Sync: 2020-10-15
Description
* Status Updates
* Release Planning
* Creating issues for docs
* Imgutil NewImage constructor param ideas
A
A
A
A
B
B
B
C
I
didn't
do
anything
this
week
on
life
cycle.
The
pr
still
outstanding,
I'm
sure
there'll,
be
some
feedback
coming
in
sound
like
you
know,
some
folks
have
already
started
looking
at
it.
So
I'll
I'd
look
to
kind
of
start,
re-implementing
that,
on
top
of
whatever
version,
that
is
that
we
want
to
implement
it
on
as
soon
as
we
understand
how
to
guard
that
code
with
the
experimental
stuff.
A
A
I
put
this
here
to
ask
for
help
because
I
had
sort
of
said
that
I
would
create
some
issues
around
that,
but
I
feel
like
my
to-do
list
is
spiraling
a
little
bit
out
of
control
and
the
number
of
things
I've
said
I
would
do
is
exceeding
the
number
of
things
I
can
do.
I
was
wondering
if
I
could
get
someone
here
to
volunteer
to
think
about
what
sections
of
what
content
we
need
in
terms
of
docs
and
make
placeholder
issues
for
it.
B
I
tossed
this
one
in
here
and
again
it
might
overlap
a
little
bit
with
more
pack
use
cases,
but
since
I'm,
a
juice
tool
is
consumed
by
both
and
we're
making
new
images
and
life
cycle.
I
forgot
to
bounce
the
idea
off
here
we're
looking
to
make
it
easier
for
a
new
image,
util
image
to
have
default
properties
set
on
it,
potentially
through
the
constructor,
rather
than
through
a
whole
bunch
of
setters
after
you
make
a
new
empty
image,
this
matters
off
for
windows,
but
will
definitely
matter
a
lot
for
arm
and
alternate
architectures.
B
For
a
little
more
background
through
so
for
a
local
image
it
gets
set,
it
gets
the
operating
system,
architecture
and
the
os
version
set
from
the
daemon.
But
that's
not
true
for
a
remote
image
or
a
moto
image
always
gets
linux,
x86
no
os
version
and
I
feel
like
covering
just
making
it
easy
to
override
those
defaults
feels
like
a
good
set
to
start
with.
But
I
don't
know
if
y'all
would
want
to.
A
A
One
of
my
dreams
for
new
image
is
that
from
base
instead
of
taking
a
string
that
is
a
base.
It
takes
a
image
and
I
think,
because
of
some
of
our
limitations,
we
might
have
to
make
that
such
that
you
know
on
local.
It
can
only
take
local
and
on
remote
it
can
only
take
remote
like
maybe
someday.
We
can
be
clover
and
let
you
create
from
other
ones,
but
I
think
starting
with
enforcing
that
is
fine.
A
Yeah,
I
want,
I
feel,
like
ggcr,
designed
their
interface
perfectly
and
we
designed
ours
less
than
perfectly
and
it'd
be
nice
to
be
able
to
move
closer
to
their
interface
like
an
ideal
world.
I
wish
we
could
drop
image,
util
and
just
use
gcr,
but
the
problem
is
their
demon
implementation,
the
performance
problems.
There
are
not
something
we
can
live
with.
B
A
For
we
didn't
use
the
daemon
as
an
image
store
like
as
a
target
destination.
When
we're
creating
images,
we
could
delete
image
hotel,
which
was
an
aspiration
that
I
know
how
the
airhead
at
one
point
in
time,
but
I
think
we're
a
long
way
doing
that
it'd
be
like
an
rfc,
a
lot
of
discussion
that
would
happen
there
and
it
probably
worth
fixing
imagery
till
because
we're
not
close
enough
to
living
in
the
world
where
we
can
get
rid
of
it.
B
Yeah,
I
feel,
like
that's
good
context,
for
knowing
what
we
want
to
work
toward,
and
that's
in
that
sense,
because
I
was
thinking
for
a
sec.
What,
if
we
added
another
kind
of
image,
that's
on
disk
image
util
as
opposed
to
on
demon
local,
but
that's
kind
of
doubling
down
tripling
down
on
mg2
rather
than.
A
But
it
might
be
worth
it
I
feel
like
we
might
actually
need
an
on
disk
image.
I'm
surprised
that
peck
is
doing
a
bunch
of
on-december's
things
without
that
right
yeah.
I
guess
for
a
while,
because
I
wanted
to
get
rid
of
it.
We
didn't
invest
in
improving
it
and
getting
rid
of
it
has
not
happened
nearly
as
fast.
We
thought
it
would.
It
might
be
worth
you
know
it
might
be
worth
doubling
down
like.
A
B
Okay,
cool
yeah!
Thank
you
again.
That's
also.
That's
that's
good
context.
Okay,
so
with
that
in
mind,
we
can
potentially
yeah.
Of
course,
question.
I'm
sorry,
you
can
feel
free
to
like
shut
me
down.
Oh,
but
can
you
just
help
me
understand
how
image
util
is
solving
the
performance
problems
that
gtcr
has
like
what
are
we
doing.
A
A
A
About
it
yeah
john
johnson,
the
problem
is,
you
have
to
be
sort
of
context,
aware
to
know
when
you
can
cheat
so,
unfortunately
be
nice.
If
you
didn't
have
to
load
the
layer,
if
the
demon
already
had
the
layer
that
make
a
lot
of
sense.
That's
what
happens
in
the
registry.
That's
not
true!
In
the
docker
dmn
in
the
docker
daemon,
it
uses
the
chain
id
to
decide
whether
it
needs
to
load
the
layer.
A
A
A
But
they
did
have
some
ideas
around
solving
the
base
image
problem.
I
think
that's
the
bigger
one,
the
previous
image
problem
we
could
get
around
with
caching
in
other
ways,
but
it
hasn't
it's
a
couple
issues
I
think
I
mentioned
them.
I
linked
to
them
in
the
in
an
image.
Little
issue
that
micah
created
about
this
doesn't
seem
like
they're
going
to
make
progress
on
it
soon,
but
we
could
try
to
fix
it
in
ggr
cr4.
Then
that's
probably
a
lot
of
work.
C
Do
we
think
there's
room
to
sort
of
introduce
like
some
hooks
into
ggcr
somewhere
to
kind
of,
like
you
know,
image,
resolution
or
layered
resolution
hooks
or
something
that
they
would
just
go
up?
And
you
know
I
don't
know
like?
Is
there
some
sort
of
small
change?
We
could
that
you
think
they
would
allow
through?
That,
would
give
us
that
flexibility.
So
we
could
get
rid
of
image
util
in
a
lot
of
places.
A
B
Maybe
this
is
getting
further
off
the
the
core
issue,
but
do
we
know,
does
this
overlap
with
the
desire
to
use
a
lot
of
the
cnb
tools
without
a
demon
like
if,
if
we
were
to
introduce
on
disk
version
of
the
image
just
can
it
help
us
decouple
more
from
the
demon
in
general?
Or
is
it
really
just
a
speed,
optimization.
A
A
B
A
I
think
we
could
use
vanilla
juice
here
for
both
tarballs
and
registries,
and
then
I
guess
what
we
do
in
the
demon
case
is
spin
up
a
local
registry
and
then
pull
into
the
demon
to
get
it
there.
In
the
end
right,
I
feel
like
we
need
a
proposal
to
describe
exactly
what
we
want
to
do
there
and
take
votes
on
it
to
be
a
big
change.
A
C
A
C
A
B
A
C
If
I
was
ready
to
start
in
on
stackpacks,
do
we
do
we
like
the
idea
of
doing
multiple
pr's
that
are
guarded
by
experimental
like
one
for
the
detector
one
for
builder,
or
we
want
one
pr
with
like
very
explicit,
commits
like
I
don't
know
what
we
want
our
commit
and
merge
strategy
to
be
here.
So
I'd
like
to
kind
of
have
some
input
here
before
I
go
off
and
do
something
that
we
don't
like
still
so
unlikely.
As
far
as
like.
C
A
C
C
A
A
C
All
right:
well,
maybe
we
bring
that
up
today
in
working
group,
so
joe
kind
of
knows
what
what
the
what
the
plan
is
there,
because
I
think
he
was
thinking
that
the
experimental
stuff
would
kind
of
mean
that,
even
if
we're
there's
no
consensus
yet
it
would
kind
of
allow
us
to
push
forward
with
a
experimental
version
of
what
we
hope
to
accept.
But
even
though
it's
not
accepted.
So
if
that's
not
what
we
want
to
do,
if
we're
not
comfortable
merging,
even
experimental,
unapproved.
B
A
Yeah
at
one
point
that
was
my
understanding
to
you,
but
as
the
experimental
api
rmc
has
finalized,
I
feel
like
that's
sort
of
not
what's
described
there
right
if
we're
using
the
unstable
or
experimental
feature
clause.
In
that,
then
those
features
are
still
documented
in
a
particular
api
version
that
we
release.
C
All
right
yeah,
we
can
bring
that
up
in
working
group
just
to
make
sure
that
terence
and
joe
have
the
same
understanding.
I
have
been
kind
of
checked
out
on
the
experimental
stuff.
Stackpack
has
really
taken
all
the
all
the
energy
out
of
that,
so
I'm
just
kind
of
waiting
for
a
decision
there.
So
I
can
wrap
everything
in
some
experimental
code
that
doesn't
exist
yet
yeah.