►
From YouTube: OCI Weekly Discussion - 2021-06-30
Description
Recording of the OCI weekly developer's discussion from 30 Jun 2021; notes/agenda here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#June-30-2021
B
D
D
Well,
there
was
so
you're
all
kind
of
prepping
for
a
start
for
your
because
they
run
in
five-minute
increments,
and
there
is
one
really
good
start
that
apparently
too
many
boats
were
watching
the
next
thing.
We
knew
we
heard
a
crunch
and
one
sailboat,
because
they
have
bow
spreads
for
the
spinnakers
literally
harpooned,
another
boat,
so
that
was
a
little
interesting
and
literally
poked
a
hole
in
it.
So
that
was
the
worst,
but
no
sailboats
don't
tend
to
turn
upside
down
just
those
little
whalers
yeah.
F
D
D
A
A
A
That's
the
uk
and
europe,
and
we
really
don't
I
mean
like
we-
do
have
folks
in
asia.
That
would
benefit
by
being
later,
because
I
do
hear
that
you
know
there's
a
few
folks
from
china
and
japan
that
watch
the
recordings
and
feed
in
information
afterwards
and,
of
course,
alexa,
and
he
even
like
wakes
up
late
in
the
day
for
australia
time.
Even
so,
it's
not
any
help.
A
A
B
B
B
So
obviously,
everything
here
is
editable
changeable,
but
the
basic
idea
is:
this
is
sort
of
like
a
prototype
for
what
we
could
kind
of
have
for
different
specs
just
to
provide
an
interface
so
that
someone
who
just
really
wants
to
like
dig
into
a
spec
can
navigate
it
without,
like
jumping
between
repositories
and
links
and
kind
of
being
like
well.
Is
this
part
of
the
spec,
or
is
this
just
like
a
link
going
somewhere
else?
There
could
also
be
other
content
here
too.
B
A
B
Yeah,
so
in
each
of
these
folders
the
index
is
the
one
that
you
know
it
has
a
title.
I
gave
it
an
id,
I
guess
it
doesn't
need
an
id
and
then
you
define
like
the
permalink
and
that's
it
and
then
in
the
other
ones.
You
do
the
same
thing.
You
say
like
okay,
this
is
the
file
name
and
you
just
say
that
it's
a
parent
of,
let's
see
yeah.
So
the
key,
the
key
is
really
the
parent.
B
A
B
B
A
E
A
And
the
other
reason
I
was
asking
about
is
is
how
it
if
and
how
it
could
handle
some
of
the
redirects
if
it
was
actually
like
reading
any
of
the
any
of
the,
since
this
is
fetching
straight
from
the
markdown.
That's
on
the
other
repo.
If
there
was
marked
out
if
there
was
annotations
or
metadata
needed
in
the
spec
markdown,
that
would
make
it
do
something
in
the
situation
where
it's
actually
pointing
to
something
that,
if
you
click
that
link,
it
would
actually
go
to
github
versus.
B
Yeah,
that
makes
sense
so
the
way
that
it
works
now
is
that
relative,
if
it
finds
a
relative
path,
it's
going
to
say,
okay.
This
is
another
page
that
I
know
about
and
then
it's
going
to
link
to
a
page
within
there.
If
it
links
to
a
github
like
a
full
github
url,
it
is
going
to
go
to
that
github
url.
B
A
B
Well,
yeah,
so
I
guess
other
feedback
would
be.
Should
there
be
anything
else
here
you
know.
Should
this
thing
have
working
groups?
Should
it
have
a
place
where
you
can
put
things
that
are
under
development,
but
not
quite
ready?
It
could
just
be.
You
know
the
way
that
it
is
now
that
would
be
sort
of
the
simplest
thing,
but
it
could
also
be
a
place
where
you
could.
We
could
put
other
content
if
that
would
be
desired.
A
Yeah
it
you
know
some
of
these
jekyll
sites
that
get
compiled
into
like
a
github.
I
o.
I
know
I've
worked
with
a
few
projects
where
they're
very
useful.
It's
a
whole
thing
of,
like
you
know,
maintaining
it
making
sure
that
it
stays
like.
If,
ideally,
I
I
like
something
like
this,
especially
if
it
actually
hit
to
like
honor
versions,
like
branch
versions
in
the
past,
I
don't
know
how
it
could
do
that
nicely.
But
since
each
repo
that
you're,
you
know
each
child
repo
that
you
have
here
has
their
own
release
tags.
B
A
Because
my
only
hope
in
that
complexity
in
recommending
it
was
that
like
if
there
was
something
that
was
effectively
here's
the
permanent
url
to
the
rendered
documents
as
they
stand
effectively
to
me,
and
somebody
else
should
argue,
but
I'm
is
satisfies
the
thing
of
why
we
ever
generated
html-
and
you
know
pdfs-
is
that
somebody
could
have
something.
That's
like
you
know.
If
I
go
to
print
this
hangout
and
it
looks
like
a
certain
way,
but
it
in.
A
Well,
I'm
just
saying,
but
in
the
in
the
url
it's
like:
no,
this
is
actually
the
the
spec
as
it
was
it
b,
o
dot,
o
or
v
o
dot,
one
or
whatever
like,
and
it
looks
fine
and
great,
and
we
don't
have
to
like
make
this.
We
could
just
make
our
ci
say
that
yeah
it.
You
know
the
page
is
up
and
it
looks
fine
who
cares
about
pdfs
and
html
output.
A
A
A
A
I
A
A
A
You
had
there
were
a
couple
other
links,
I
think
in
one
of
in
the
email,
when
you
first
proposed
this
to
the
to
the
dev
list,
but
this
is
currently
just
the
poc
to
review.
It
would
look
like
its
own
repo
under
open
containers,
and
you
have
to
have
some
some
settings
set
for
the
for
the
open,
container's
work.
I
guess.
B
So
you
mean
what
would
it
take
to
move
it
over
or
to
implement
it?
There
is
that
the
question
yeah
so
that
that
would
be
pretty
easy.
You
would
just
basically
probably
template
it
or
whatever
pull
it,
push
it
somewhere
else,
and
then
you
would
just
change
the
base
urls
and
the
jekyll
config,
and
it
would
you
know
and
change
whatever
other
little
metadata
or
styles
you're
interested.
B
I
I
A
J
A
F
F
B
A
And
if
I
I
would
welcome
you
know,
like
I
know
you,
you
did
the
the
heavy
lifting
on
the
front
end
of
it.
I
have
not
touched
jekyll
in
10
years
easy,
but
would
love
if
anybody
has
experience
in
that
that
we
could
like
have
some
code
owners
mentioned
there
for
folks
to
either
take
ongoing
improvements
or
fixes
as
they
need
to
be.
So
it's
not
just
you,
you
know
being
called
every
time.
H
A
A
A
B
A
H
H
H
A
A
A
G
G
G
So
this
comes
up
for
say
a
multi-platform
image
if
you
want
to
have
the
base
of
every
child
image
and
also
point
to
the
the
base
by
tag,
should
the
child
digest
match
the
base
child's
digest,
or
should
the
child
digest
point
to
the
match,
its
own
architecture
or
whatever
right,
and
my
my
thinking
was
that
it
should
match
the
the
parent,
because
if
you
wanted
to
make
any
tooling
around
this,
that
says,
like
oh,
has
this
tag
moved.
Do
I
need
to
update?
Do
I
need
to
rebase
my
image?
G
A
Well
that
that
it
is
a
very
good
sticking
point
I'll
be
curious
to
see
the
wording
that
he
used
to
update
it.
To
me,
that's
also
even
it
this
effectively
brings,
I
like
to
keep
some
of
these
pr
conversations
as
narrow
as
possible
so
that
they
don't
just
grab
the
tablecloth
because
they're
running
by
right,
but
this
almost
pulls
in
the
conversation
that
we've
kind
of
touched
on
the
past
and
it
hasn't
ever
really
mattered.
A
So
we
have
ignored
it,
but
some
of
the
some
of
the
tools
over
the
years
have
effectively
transparently
pulled
through
that
initial
digest.
So
even
on
some,
like
the
pod
man
containers
image
logic,
if
you
fetched
a
multi-image,
you
know
even
a
specific
digest
of
a
multi-image,
it
would
only
it
would
like.
Then
it
would
fetch
and
validate
that
thing.
In
the
you
know
the
top
level,
but
then
it
would
silently
fetch
the
under
architecture
that
it's
interested
in
and
you
know,
validate
those
independently.
A
So
the
thing
that
you're
left
with
was
then
only
the
child,
even
though
in
the
handshake
it
validated
the
top
level,
but
then
you're
only
left
with
the
child.
At
least
it
was
one
of
those
like
silent
behaviors,
that
as
a
user,
you
never
care
or
never
see
it,
but
you're
now
left
with
effectively
something
different
than
you
start.
Yeah,
like
a
child
of
something
that
you
started
with
a
parent.
G
D
I
think
that
this
is
kind
of
like
the
latest
thing
in
some
ways.
It's
like
you
never
want
your
thumb
statement
to
really
point
to
latest,
because
that
always
is
a
interesting
floating.
But
even
it's
hard
to
say,
why
would
a
should
a
from
statement
point
to
a
multi-arc
image,
because
if
you
build
it
on
a
different
machine,
you
could
wind
up
accidentally
with
a
different
base.
But
if
you
are
pointing
to
an
index,
then
yeah
the
digest
should
match
the
index.
So
that's
a
really
good
qualification.
H
G
I'll
do
my
best,
so
I
think
there's
a
handful
of
things.
The
things
that
excite
me
the
most
are
one
is
just
having
some
metadata
about
the
the
lineage
of
your
image.
Right.
If
you
know
I
built
this
based
on
ubuntu
whatever
it's
it's
easier
to
write,
tooling,
to
look
for,
say
things
that
are
vulnerable
to
something.
G
If
you
know
that
base
image,
it
came
from
it.
It's
just
nice
from
you
know
like
a
supply
chain
perspective.
What
I
want
to
do
with
this
is
write
some
tooling
around
automatic
patching,
more
or
less.
So
if,
if
the
image
is
annotated
with
its
base
image,
I
can
detect
changes
to
that
base
image
and
rebuild
and
redeploy
things
automatically
without
having
to
do
anything
manually.
H
And-
and
you
wanted
to
be
able
to
do
that
without
having
the
original
patched
image
in
place,
you
want
to
be
able
to
find
the
image
that
was
dependent
on
the
base
image
and
then
then
look
those
up
without
because,
if
you,
if
you,
if
you
patch
a
layer-
and
you
know
which
layer
it
was
patched
from,
you
could
just
look
those
up
in
all
the
images
right.
You
have
to
do
a
reverse
lookup,
but.
H
G
Is
kind
of
pushes
some
information
rightward
so
that
I
could
write
tooling,
that
is
generic
across
an
image,
and
you
know,
maybe
you
don't
actually
trigger
a
patch
but
just
being
able
to
surface
the
fact
that
hey
this
was
built
from
an
image
that
is
no
longer
v2
like
v2
has
moved
on.
You
should
probably
bump
your
stuff
as
well.
D
Having
it
built
into
it,
really
it
does
help
I
mean
with
with
acr
tasks.
We
actually
do
the
space
image
update
notification
stuff,
but
we
have
to
you
have
to
actually
build
what
tasks
to
do
that,
because
we
grab
that
digest
at
build
time,
because
it's
not
captured
anywhere
else.
So
that
means
that
that
is
kind
of
captured
in
that
environment.
D
If
it's,
if
something
is
built
and
the
digest
of
what
it
was
built
against,
is
captured
in
it,
then
I
can
hand
it
to
something
else
and
that
other
thing
doesn't
need
to
actually
build
it.
It
can
just
like.
Oh
all,
I
have
to
do
is
just
check
whatever
registry
that
thing
is
coming
from.
Is
that
still
the
digest
that
matches
that
tag
is.
A
This
is
that,
because
of
like
flat,
flattening
or
otherwise
or
splashing,
or
otherwise,
you
capture
some
information
that
was
like
a
layer
at
some
point
during
the
build.
That's
never
captured
anywhere
else.
Is
that
because
it's
like
squash
to
the
late,
oh,
no,
no,
no,
never,
mind
it's.
Even
just
the
problem
is
lost.
A
H
Thrown
away
so
if
you,
so,
what?
If
you
have
two
images
that
are
base
images
the
same
digest,
but
they
have
separate
names
like
how
do
you
put
both
names
into
the
image?
That's
built
from
that?
Or
do
you
just
pick
it
from
the
lineage
that
you're
building
at
the
time?
How
does
that
work?
When
you
have
multiple
paths
to
the
same
content,
I
would
assume
the.
D
D
A
H
H
Necessarily
have
guidance
on
that,
because
we
assume
that
this
is
canonical
the
the
you
know.
Well,
I
don't
think
this
is
like
a
like
a
like
a
bad
thing
per
se.
I
think
it
introduces
quite
a
lot
of
problems
that
really
exist
in
the
build
system
itself
so
like
if
you,
because
really,
okay,
so
you're,
saying
okay.
Well,
we
want
to
like
look
at.
H
H
So
what
I've
seen
in
the
way
that
people
use
docker
images
when
there's
when
there's
several
of
them
and
they're
all
kind
of
interlinked
and
based
on
each
other
is
the
dependency
relationship
doesn't
exist
at
the
image
level,
but
really
it
exists
at
like
the
docker
file
level,
at
least
that's
what
I've
that's?
What
I've
seen
recently
does
that
make
sense.
D
A
H
Or
do
you
use
a
digest
to
figure
out
if
it's
vulnerable,
like
I
think
when
you
start
unpacking
these
unit
use
cases
this
like
like
this
proposal,
has
come
up
before
and
I'm
trying
to
think
of
you
know
why
we
didn't
do
it
before
or
like
what
made
it
difficult,
and
these
are
the
issues
that
came
up
it
was.
It
was
largely.
D
You're
here
for
jason,
because
you
know
he
obviously
has
some
thoughts,
but
the
conversations
we
had
at
the
time
about
this
was
because
all
these
things
came
up
just
recently,
and
the
s
bomb
was
a
good
example
and
the
thought
process
was
this.
This
is
an
a
small
step.
It
allows
a
very
scoped
set
of
work
that
can
be
done
and,
like
I
said,
we've
been
doing
this
with
task
for
a
while.
We
we
do
track
all
of
the
digest
in
a
multi-stage,
build
for
instance,
but
it's
an
optional
thing.
D
A
G
Yeah,
so
I
can
maybe
cover
that
a
little
more
like
personally,
I
have
at
this
point
five
different
tools.
I
use
to
build
container
images,
and
so
I
don't
really
want
to
solve
this
problem
within
the
build
tool,
if
I
can
avoid
it
so,
and
so
what
I'd
like
to
do
basically
is
express
the
dependency
graph
in
terms
of
an
image.
H
G
Yeah,
yes,
if
if
it
ends
up
that
like
we
as
an
oci
group,
think
that
this
is
too
hairy
to
actually
standardize.
That's
fine,
we'll
just
use
our
own
namespace.
I
think,
but
the
idea
was
that
this
seems
like
a
common
enough
use
case
and
enough
people
have
asked
for
it.
Then
maybe
we
try
again
and
see
what
people
think
and,
of
course,
I'm
happy
to
change
the
string
in
the
future
to
a
standardized
thing.
If
we
change
our
mind
in
the.
G
H
No,
I
just
think
these
things
always
like,
like
all
the
discussion
around
rough.name,
like
oh
just
a
simple
thing,
and
in
there
it
created
a
lot
of
questions
and
confusions
and
about
where
it
could
go,
how
it
would
work
and
like
I'm
good
with
lightweight
fields
but
like
as
long
as
that
confusion
doesn't
create
more
problems
for
people
than
I
than
I
don't.
I
don't
see,
but
I
mean
there's
going
to
be
somebody
who
asks
like.
Oh,
if
there's
this
situation
in
that
situation
and
there's
some
dilemma
that
they
have.
H
D
H
E
J
G
You
all
started
talking
about
the
thing
I
wanted
to
talk
about
as
soon
as
I
stepped
away.
So
I
don't
know
who
initiated
the
conversation,
but
this
pr
at
one
point
had
me
advocating
for
like
being
able
to
specify
multiple
things
as
dependencies,
because
you
know
the
base
image
is,
I
think,
the
simple
to
understand
thing
and
the
common
case,
but
really
what
I
want
to
express
is
a
dependency
graph
of
images,
and
you
can
do
that
by
having
your
base
image,
be
an
index
that
references
one
or
more
images
or
indexes.
G
H
Okay,
all
right!
Well,
my
I'm
good
with
with
it.
You
know
as
long
as
we're
going
to
take
on
the
or
just
remember
when
it
gets
complicated
and
you'll
be,
like
oh
remember,
steven
said
that
was
complicated,
but
that
would
get
complicated
and
then
on
the
other
portion.
Here
we
can
drop
the
ref
in
there.
It
should
just
be
based.name.
The
ref
was
is
just
for
like
the
image
ref
for
the
primary
image.
If
that
makes
sense
like
it's
not
like
a
type
thing.
H
G
G
H
H
D
That's
fair
because
we
we
did
because
the
ones
we
have
discussed
we
did.
We
did
scope
it,
for
instance,
back
to
your
from
statement
question
if
you
copy
the
ubuntu
image
from
docker
hub
to
your
private
registry,
and
that's
where
you
built
from
it,
would
it
would
actually
point
to
your
private
registry
and
then
because
that's
where
you
built
it
from
that's
where
you're
tracking
it
the
index?
One
is
a
great
update
and
I
think
you
know
what
landed
so
as
long
as
those
clarities
get
added
to
the
definition
of
it.
E
But,
wouldn't
that
be
a
tooling
specific
decision.
So
if
you
have
two
possible
places,
you
could
pull
the
base
image
from,
because
it's
copy
between
registries,
it's
up
to
the
tool
writer
to
decide
what
they
want
to
put
in
there,
whether
it's
which
you
actually
built
from
or
whether
you
want
to
let
the
user
override
and
put
a
public
value
in
there.
D
I
think
the
question
is:
how
do
you
make
it
generally
useful
because
to
I
think,
stephen's
point
if
you're
trying
to
do
this
within
a
particular
company,
then
use
your
company's
names
annotation
do
whatever
you
want,
if
you're
trying
to
put
something
up
for
a
public
consumption
for
some
other
company
to
use
some
other
user
to
use
with
some
other
tool
chain
that
there
has
to
be
some
consistency
to
it.
So
they
know
they
have
a
chance
of
success.
E
D
E
K
K
G
So
I
I
think,
you're
hitting
the
problem
that
jason's
update
to
that
pr
tries
to
address
where
it's
ambiguous,
like
which
digest
you
use
as
the
base
digest
exactly
yeah.
So
what
I
think
is
most
intuitive
and
useful,
and
I'm
open
to
people
disagreeing
with
that
is,
if
you're
pointing
to
a
tag
of
something
the
digest
should
be
the
digest
of
that
tag.
G
K
Way,
I'm
I'm
looking,
I
mean
basically,
I'm
kind
of
trying
to
figure
out
what
the
thinking
is
here,
because
I
think
we
have
gone
through
the
same
logic
of
being
able
to
detect
the
child
image.
The
image
itself
doesn't.
My
understanding
is
that
the
architecture
of
the
image
doesn't
stick
somewhere
without
looking
at
things
like
config.
The
manifest
doesn't
have
that
information.
K
The
problem
I'm
having
is
you
have
the
final
image
you
look
at
the
base
digest
you
have
to
walk
through
the
base
digest
and
if
it's
an
index
you
have
to
look
at
every
possible
manifested
index
references,
find
the
closure
and
then
kind
of
detect.
The
final
diagram
is:
is
that
is
there
any
thinking
around
that
or
we
can
just
assume
that
is.
H
H
So
I
can
go
like
I
can
go
on
my
kubernetes
cluster
or
whatever,
and
I
can
look
at
this
thing
running
a
particular
image
and
it'll
say,
like
you
know,
stevo's
great
app
image,
then
I
have
to
go
and
hunt
that
down
in
a
bunch
of
source
repositories
and
figure
out
where
that
docker
file
is
built
right,
so
ultimately
that
kind
of
that
kind
of
information
about
like
okay.
How
do
I
rebuild
this?
So
if
this
base
image
changes
and
has
security
updates?
H
How
which
images
do
I
have
to
build
rebuild
to
figure
that
out?
I
have
to
have
reverse
dependency
data
to
figure
that
out.
If
I
want
to
go
and
figure
out
like
okay,
I
need
to
update
this
image
because
something
changed
it
then
I
have
to
go
back
and
figure
out.
Okay,
I
got
to
rebuild
the
base
image
and
I
have
to
go
build
those
those
child
images
from
it.
The
knowing
this
image
name
will.
K
G
Ahead,
I
expect
this
would
usually
be
used
as
a
signal
or
even
a
trigger,
to
go
back
to
the
build
system
and
start
it
over,
and
you
would
need
out-of-band
information
to
know
like
how
do
you
restart
the
build
system?
How
do
you
trigger
a
new
build
or
which
build
system
right,
and
so
I
think
that
would
be
some
configuration
on
your
on
your
side.
If
you
can
map
between.
Oh,
this
image
is
stale.
What
do
I
need
to
do
to
resolve
that?
G
K
E
E
So
link
I
threw
out
there
and
I'll,
throw
it
in
the
notes
for
the
meeting,
but
one
of
the
pr's
I
set
out
a
while
back
was
whether
or
not
we
want
to
clarify
in
the
image
spec
that
the
annotations
that
we
define
in
there
are
they
designed
to
only
be
annotations.
Can
they
also
be
labels
on
the
image
because
most
of
the
tooling
out
there
today,
people
are
using
them
as
labels
they're,
not
using
them
as.
E
People
using
the
aura
open
containers,
image
annotations
we
defined
here
today.
I
think
almost
every
case
I've
ever
seen
is
someone
in
a
docker
file.
Defining
is
an
image
label,
and
so
that
goes
into
the
image
config
and
not
into
the
annotation
section.
So
I'm
just
wondering
if
there
needs
to
be
clarification
from
the
oci
site,
saying
that
this
should
only
be
used
as
an
annotation
and
don't
expect
it
to
work
with
any
tooling.
If
you
define
as
a
label
or
not.
E
A
Right
there
yeah
that's
literally
the
argument
against
that
annotations
dating
back
to
2014..
So
I
think
that's
that
comes
in
the
kind
of
like.
I
don't
remember.
If
there's
actually
what
kind
of
reviews
we
arrived
at
with
the
function
of
annotations
in
general
to
basically
say
these,
these
are
optional
and
if
you
choose
anything
in
here
to
basically,
if
you
break
anything,
if
you,
if
you
change
anything
in
here
and
it
breaks
a
tool,
then
effectively
you
screwed
up,
so
people
can
build
workflows
like
what
we're
describing
you
know.
E
Yeah
there
was
a
comment
on
the
issue
from
someone
that
said,
you
know
I
just
realized.
This
was
a
problem
because
harbor
was
looking
at
annotations
for
parsing
some
of
the
fields
as
it
should
that's
fortifying
annotations
here,
and
so
it
was
looking
at
the
annotations
and
it
caught
the
user
off
guard,
because
the
user
saw
it
and
thought
that
it
was
the
same
thing
as
a
label
and
they
were
to
find
labels
on
their
images.
A
All
right
the
it
was,
it
was
actually
a
good
discussion.
I'm
glad
that
john
and
jason,
you
know
put
that
on
the
discussion,
because
I
know
that
it's
jason's
been
me
a
couple
of
times
and
I
sit
down
and
start
on
it,
but
it
it
that
one
is
one
that
requires
more
discussion
while
listening.
I
did
like
last
week
last
week,
a
few
of
us
dialed
in
for
kind
of
a
grooming
of
the
distribution
spec.
A
I
don't
think
the
recordings
put
up
there
I
mean,
maybe
it
can
in
full
transparency,
but
it
was
very,
very,
very
informal
and
relaxed
and
banter,
and
those
are
very
useful.
Also
so
don't
feel
like
you
missed
anything
particularly
it
was
mostly.
It
would
have
just
been
observing
some
kind
of
cleanup
and
one
of
the
things
that
we
liked
more
or
less
proposed
to
yours
too,
but
steven
already
called
in
is
we've
had
so
many
issues
with
some
of
these
different
checks
that
we
have
and
it
varies
across
all
of
them.
A
Like
I
think
at
some
point,
we
had
three
different
dco
checks
and
a
couple
of
them
that
were
like
getting
things
out
of
sync
of
like
configuring,
who's,
the
actual
approver
in
some
tool
versus
inside
of
the
project
itself.
Like
just
read
the
read
the
code
owner's
file
and
if
it's
a
maintainer
in
that
file,
then
they
can
make
approvals.
A
A
So
I'm
not
actually
on.
I
don't
have
the
same
rights
on
this
one
to
do,
for
the
image
stack
as
I
did,
for
the
distribution
spec
but
I'll
I'll.
I
can
sync
up
with
amy
or
chris
on
that
later
to
switch
over
to
the
code
code
owners
piece
of
it,
but
there's
a
few
other
ci
stuff,
that's
good
to
just
kind
of
dust
off
and
make
sure
that
we're
using
github
actions
instead
of
travis.
I
think
we've
already
disabled
travis
in
here
now,
but
you
know
I.
K
A
Really
like
having
an
open
communication
chat
and
especially
with
maintainers
a
few
maintainers
on
the
call,
so
thank
you,
john
for
dialing,
john
poole,
john
johnson
sure
also
but
stephen,
so
I'll
ping.
Y'all
again,
I'm
glad
you're
here
for
the
other
other
discussions
as
well.
But
we
can.
We
should
do
another
grooming
like
that
for
the
image
spec
soon.