►
From YouTube: OCI Weekly Discussion - 2021-02-17
Description
OCI weekly developer's call recording from 17 Feb 2021. Notes/agenda here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#February-17-2021
E
A
B
A
Are
you
talking
about
yeah
intermittent
I'm
on
my
own?
Well,
so
so
you
know
what,
as
long
as
I
get
power,
everyone
wants
in
a
blue
moon,
I'm
okay,
it'll
thaw
out
the
pipes
enough
to
you
know
get
the
water
in.
We
got
tanks
of
water,
so
we're
we're
going
to
be
okay.
We
got,
I
got
lots
of
wood
to
burn,
but
my
neighbors
just
across
the
street
right
there
they
got
no
power
for
the
last
24
hours.
G
F
A
G
A
B
C
C
You'll
see
that
okay,
I
had
a
proposal
for
this
is
issue
821
for
adding
a
new
or
two
new
standard
annotations,
one
to
specify
the
digest
of
the
base
image
and
one
to
specify
the
a
human
meaningful
name
of
the
base
image
at
the
yeah
anyway,
I'll
I'll
keep
going.
The
name
I
went
with
bassrep
name
is
because
it
matches
the
existing
image.
Rep
name.
I
am
not
at
all
tied
to
the
names
of
each
of
either
of
these
things
at
all.
C
If
anybody
has
a
better
alternative,
I'd
love
to
hear
it,
the
the
basic
motivations
are
sort
of
in
three
levels,
from
very
simple
to
a
bit
more
complex
to
maybe
crazy
complex.
I
don't
want
to.
I
want
to
make
it
clear,
I'm
not
specifying.
I
don't
intend
to
specify
behavior
of
things.
This
is
literally
just
to
reserve
these
two
names
of
annotations
in
the
spec,
the
main
ident.
The
main
motivation
is
to
be
able
to
identify
images
based
on
specific
vulnerable
base
images.
C
So
if
I
based
an
image
on,
you
know
my
cool
os
version,
6
and
then
version
6
turned
out
to
have
a
terrible
vulnerability
in
it.
I
would
like
to
be
able
to
scan
and
find
that
vulnerability
scanners
currently
tend
to
work
by
identifying
identify
vulnerable
layers
and
then
finding
images
that
specify
those
layers.
C
I
think
there
are
that
works,
I
think,
or
or
even
going
further
in
finding
specific
files
inside
of
layers,
but
basing
on
images
is,
I
think,
a
slightly
better
way
to
handle
that,
but
that's
also
like
the
simplest
and
not
the
most
complex
case,
a
little
bit
more
is
to
be
able
to
identify-
and
that's
just
using
the
digest.
So
so,
literally,
just
like
my
cool
image
at
sha,
blah
blah
shout
out
bad
shot.
The
second
use
case
is
to
be
able
to
identify
out
of
date,
face
images.
C
You
know
def
and
so
that's
out
of
date,
and
I
can
you
use
that
information
to
either
notify
users,
hey
you're,
built
on
an
old
thing
or
show
a
little
badge
in
a
ui
or
automatically
rebuild
if
I
have
source
the
source
there's
an
annotation
for
where
the
source
lives.
Now
again,
I
don't
intend
to
specify
that
things
should
do
this,
but
with
these
two
pieces
of
information
they
can
do
this
and
then
the
third
one,
which
is
a
bit
more
leveled
up,
is
even
aside
from
so
so.
C
The
downside
of
rebuilding
automatically
is
that
you
need
to
go
find
that
source
and
you
need
to
spend
compute
to
rebuild
that
source
and
what,
if
the
source,
isn't
there
or
doesn't
build
anymore?
You
know
1000
issues
with
that.
We
can
actually
do
something
in
just
with
registry
apis
to
rebase
the
image.
C
If
we
know
that
that's
safe,
it's
not
always
going
to
be
safe,
it's
very
often
not
safe,
but
if
you
build
your
image
in
such
a
way,
you
can
cut
out
the
old
base
image
layers
put
in
new
base
image
layers
and
produce
an
image
that
is
valid
and
can
be
you
know,
rolled
out
validated
and
rolled
out.
You
can
either
you
can
notify
or
you
can
automatically
rebuild
or
you
can
automatically
rebase
in
the
wild.
There
are
people
doing
rebasing
at
scale.
Build
packs,
for
instance,
is
a
heavy
user
of
rebasing.
C
I
don't
know
if
any
of
them
are
here
on
the
call.
I
talked
about
a
couple
of
them
offline.
I
don't
know
if
any
of
them
here,
but
they
have
an
annotation
that
that
is
not
these
two
bits
of
information.
It's
a
lot
more
information
and
it's
like
a
json
object
inside
the
annotation
value,
but
it
essentially
boils
down
to
these
two
pieces
of
information.
C
What
what
is
the
digest
of
the
image
you
were
based
on
and
what
new
image
should
I
look
for
for
new
bases
and
if
it's
out
of
date,
then
you
can
rebuild
or
sorry
rebase
build
text
gets
away
with
this
because
they
specify
very
heavily
how
the
top
layers
work
and
how
what
they
can
depend
on
in
the
low
layers,
etc.
There's
also
a
tool
that
john
and
I
wrote
called
crane
and
one
of
the
commands
in
crane
is
to
rebase
use
it.
I
can
just
do
the
demo
yeah.
C
Let's
just
do
the
demo,
because
there's
other
stuff
in
the
agenda-
and
you
don't
need
to
keep
hearing
me
talk.
So
I
have
this
image,
which
is
based
on
ubuntu
1604
for
the
purposes
of
this
demo,
let's
say
that
it
was
based
on
latest
at
the
time
I
built
it
four
years
ago
and
since
then,
you
know
latest
has
turned
into
2004
or
whatever.
I
can
run
this
image.
C
C
C
I
could
do
this
live
if
you
want.
I
don't
know
if
you
are
interested
in
watching
me
type
forever,
but
in
in
crane
at
least
the
old
bass
should
be
specified
by
digest
and
shouldn't
be
the
tag
it
supports
tag,
but
it
probably
shouldn't
to
be
saved
if
it
finds
out
that
original
is
not
actually
based
on
old
bass.
C
If
the
lower
layers
of
this
image
don't
match
the
layers
in
this
image,
it
will
fail
and
say,
like
hey,
you're
wrong,
go
fix
your
life
if
original
is
already
based
on
new
base,
if
ubuntu
latest
and
ubuntu
1604
point
to
the
same
thing,
nothing
happens,
there's
nothing
to
do
and
you
can
specify
the
same.
You
can
push
to
rebase
me
to
tag
over
it.
If
you
want
to,
I
don't
know,
if
that's
interesting
in
general,
I
think
people
shouldn't
do
that,
but
nothing
stops
you
so
now.
C
After
calling
this
command
this,
this
only
does
registry
api
operations.
It
doesn't
compute
anything
but
digests.
Really.
When
you
docker
run
this
image,
it
will
tell
you
that
it's
now
based
on
2004,
because
it's
reading
files
from
the
new
base
image
at
etsy.
Oh
it's
release,
like
I
said,
none
of
the
none
of
rebasing
is
guaranteed
to
be
safe.
C
Don't
do
this
unless
you
know
what
you're
doing
that
is
also
not
part
of
what
I
am
proposing
in
the
specification
of
anything
like
this
is
just
to
be
able
to
say
I
can
annotate
images
with
these
two
bits
of
information
that
make
it
standard
to
say.
I
was
based
on
this
at
the
time
I
was
built,
and
this
is
what
I
should
be
based
on.
If
it
is
changed,
go
do
that.
A
A
A
C
A
C
C
Does
this
in
production
already
with
their
own
sort
of
non-standard
purpose-built
annotation,
and
I'm
proposing
basically
specifying
these
two
new
things
with
these
with
these
semantics,
I
don't
again,
I
don't
think
anybody
from
build
packs
is
here,
but
I
talked
to
them
before,
and
they
seem
largely
on
board
with
this
and
would
love
to
have
us
back
for
it.
Instead
of
doing
their
own
thing,
you
will
have
to
take
my
word
for
it.
A
C
F
This
maps
maps
pretty
well
to
like
what
people
are
doing
in
real
life
right
now.
But
you
know
the
data
structures,
don't
necessarily
mean
that
a
base
image
is
a
thing,
so
I
could
see
this
being
like.
Oh
well,
this
isn't
a
perfect,
perfect
abstraction,
but
I
think
it's
a
useful
abstraction
that
everyone,
you
know
understands
what
it
is
and
what
it
would
mean.
B
I
was
trying
to
so
one
I
was
thinking
about.
The
multi-stage
builds,
which
is
the
build
pack
stuff,
is
interesting
because
they
do
a
build
environment
right.
It's
it's!
It's
not
that
they're,
because
we've
looked
at.
How
do
we
patch
images
across
all
of
azure
and
critical
situations
and
there's
always
these
problems
of
overlays?
B
You
know
the
things
that
come
in
just
because
you're
putting
something
underneath
doesn't
mean
that
somebody
but
didn't
put
the
file
on
top
of
it,
that
you
can't
actually
resolve
so
there's
some
interesting
experiments
around
and
inserting,
above
which
I
don't
want
to
get
into
too
much.
But
the
the
point
is
that
the
just
defining
the
base
is
is
interesting,
but
it
is
hard
to
compare
with
the
build
packs
because
their
build
environment
is
very
tailored
to
that
type
of
situation.
B
I'm
the
thing
that
I
tease
apart
is
the.
How
do
I
correlate
this
with
some
of
the
s-bomb
work,
because
john
mentioned
this?
Also,
like
you
know
what
compiler
are
you
version
using
and
if
you're
trying
to
figure
out
the
security
vulnerabilities?
It's
not
just
the
base
image
that
you're
based
on
because
you
might
be
based
on
some
runtime
from
node
or
java,
but
the
node
or
java
based
image,
you're
dependent
on
is
actually
based
on
debian
or
ubuntu,
and
it's
got
installability
so
being
able
to
know
that
whole
tree
is
important
and.
A
B
I
just
I
it's
I'm
worried,
I'm
wondering
about
how
complete
it
is
and
how
reliable
it
would
be,
because
you
can
declare
what
you
want
as
a
base.
But
there's
nothing
saying
you
couldn't
stick
some
other
value
in
there
when
you're
really
based
on
something
completely
different.
There's
no
real
verification
of
it.
C
Right
right,
that's
a
good
point.
I
I
don't.
I
part
of
the
reason
it
is
not
a
solution
to
every
possible
problem.
Is
I
wanted
to
propose
the
smallest
possible
change
in
in
the
hopes
that
it
would
get
approved
it?
It
certainly
does
point
to
future
work
to
be
able
to
you
know
if
if
many
people
want
to
be
able
to
annotate
with
like
a
like
a
bill
of
materials,
you
know
information.
Then
then
absolutely
that's
a
direction
that
you'd
want
to
go.
I
just
don't
I
don't
want
to.
C
C
A
C
Right
and
well
in
in
the
rebase
case,
especially
like
rebasing,
is
not
safe
in
99
of
the
cases.
So
so
you
need
to
be
really
really
careful
about
how
you
build
like
how
you
build
the
upper
layers
and
what
they
depend
on,
ideally,
nothing
about
the
lower
layers.
But
again
that's
that's
one
of
the
three
motivations
and
the
other
two
are,
I
think,
a
bit
more
straightforward,
just
to
be
able
to
put
a
little
badge
in
the
registry.
Ui
that
says
hey.
C
B
B
But
I
I
get
that
that's
kind
of
like
an
additional
benefit,
not
what
you're
really
focused
on
the
the
thing
that
I
worry
about
is
just
what
kind
of
expectation
can
be
really
had
from
this
I
mean
this
is
this
is
like
getting
into
the
art
of
what
the
vulnerability
scanners
are
really
doing,
and
what
does
it
really
like
to
be
able
to
say
it's
out
of
date?
Okay,
that's
interesting
to
say
it's
vulnerable.
It
could
be
one
day
old
and
it
might
be
vulnerable
and
it
could
be
one
year
old
and
it's
not
so.
C
Yeah,
the
annotation
doesn't
say
you
are
vulnerable
right,
like
some.
Some
other
tool
needs
to
bring
its
own
information.
Combine
it
with
this
information
to
tell
whether
you're
vulnerable,
certainly
vulnerability
scanners
can
get
they.
They
can
either
index
by
the
contents
of
a
layer
or
the
digest
of
a
layer
and
say
this
layer
is
vulnerable,
and
you
can
you
clearly
very
obviously
contain
that
layer.
They
can't
tell
whether
some
layer
on
top
of
it,
you
know,
deleted
that
file,
that
made
it
vulnerable
or
patched.
E
A
D
A
F
C
Yeah,
I
guess
I'm
less
worried
about,
like
you,
said,
less
worried
about
malicious
attack
vectors
leaking
in
through
here,
there's
already,
basically,
free
form
text
field
annotations.
If
you
wanted
to
to
do
something
weird,
I
think
the
more
likely
scenario
of
this
failing
is
that
somebody
bases
on
an
image
that
has
this
annotation
and
doesn't
update
their
annotation
to
say
that
they
are
like
that.
C
B
I
think
it
just
depends
on
what
expectations
are
or
set
on
this
right.
It's
it's
certainly
interesting
like
we.
We
do
this
kind
of
information.
We
track
this
metadata
internally.
When
somebody
builds
with
acr
tasks,
we
track
what
they
reference
and
what
the
digest
is
and
if
there's
an
update,
we
we
automatically
trigger
a
build
if
they've
asked
us
to
and
we
we
also
track
the
other
base
images
in
the
multi-stage
docker
file
and
they
opt
in
to
any
of
those
being
tracked.
So
I
think
it's
interesting.
B
I
don't
want
to
squash
the
ideas
of
like
hey.
Let's
get
some
innovations
going
and
see
what
can
build
on
it.
I'm
just
wondering
what
what
is
the
expectation
of
these
values,
because
it
could
be
an
attack
vector
like
many
things,
could
be
to
be
fair,
like
even
an
s
bomb,
because
if
you
put
this
in
the
manifest,
then
you
built
the
image
if
somebody
builds
an
s
bomb
with
an
with
their
image,
they
put
the
s-bomb
in
there
and
that
all
we
can
do
is
sign
it
and
say
yep.
B
It
came
from
that
authority
and
as
long
as
that
authority's
key
is
still
valid.
They
could
also
lie
right.
So
there's
nothing.
It's
always
that
that
secondary
check
you
go
to
the
airport.
They
look
at
your
passport.
You
know
they
scan
it
to
see
if
it
was
re.
You
know
on
your
block
list,
but
they're
not
going
to
ask
you
to
prove
how
did
you
get
this
passport?
B
C
C
Point
if
the
digest
doesn't
match
it's,
it's
very
quick
to
be
able
to
verify
that
you
can
you
you
pull
the
manifest
of
the
thing
at
the
digest.
You
said
it
is
you
compare
the
layers
if
the
layers
aren't
right,
then
you're
wrong
and
any
tooling.
That
would
automatically
do
anything
automatically.
Based
on
this
would
be
able
to
say,
like
I
don't
know
what.
B
B
B
C
C
B
Should
have
that
minor
detail,
but
my
question
was
more
of,
is
it
just
say,
ubuntu,
meaning
we're
assuming
it
came
from
dark
red,
but
we
could
expand
it
to
docker,
io
library
as
javascript
or
are
we
saying
it's
just
ubuntu
and
I
might
have
actually
been
pulling
a
from
statement
from
my
private
registry.
So
what
I'm
getting
at
is
I'm
actually
somewhat
suggesting
that
the
ref
name
actually
is
the
fully
qualified
from
statement
wherever
it
is.
B
So
if
it's
from
docker
hub
guess
it
should
say
docker,
io
library,
if
it's
ubuntu,
that's
copied
to
my
private
registry,
where
my
team
builds
from,
then
it
should
say
you
know,
you
know
acme
rockets
dot.
You
know
registry.rockets.ubuntu
whatever
you
know
where
I'm
going
with
it.
In
other
words,
it
should
be
the
fully
qualified.
So
I
can
run
that
again
or
I
can
actually
query
that
registry.
C
C
C
F
I
think
if
it
is
semantically
the
location
with
from
which
it
was
pulled,
it
is
most
useful
because
digest
tells
you
what
it
is
and
the
ref
tells
you
where
it's
from
originally
and
so
with
those
two
pieces
of
information
you
can
do
whatever
you
want.
You
can
go,
look
up
if
the
tags
moved,
you
know
it.
It's
the
most.
A
F
F
C
B
C
E
B
And
that's
you
know,
but
anyway
I
I
I
guess
I
came
around
full
circle
on
it
and
it's
like
it,
overlaps
with
some
of
the
s
bomb
stuff,
but
we
don't
know
when
that's
going
to
fully
land
and
it's
a
much
more
complicated
environment.
This
does
has
have
some
interesting
information
that
people
can
leverage.
I
think
if,
if
we're
going
to
define
it
in
the
open
containers
name
space,
then
I
think
we
just
have
to
finish
up
exactly
what
we're
saying
those
two
properties
should
should
have
when
they're
used.
B
C
B
E
C
B
B
A
B
B
But
just
because
it
says
yes
or
no
doesn't
mean
they
didn't
implement
the
api
right
or
wrong
so
like
in
the
notary
client,
when
it
goes
and
asks
for
what
you
know
what
signatures
apply
to
the
hello
world
image?
It's
just
going
to
make
the
api
call.
It's
got
no
reason
to
go
experience.
You
support
this
api.
Hey
api,
give
me
the
results.
So
when
the
thing
says,
don't
know
what
that
api
is
clearly,
the
registry
doesn't
support
that
capability.
I.
A
See
so
each
each
extension
should
have
some
level
of
specification
around
it,
explaining
what
the
apis
are.
What
the
context
is
that
sort
of
thing
yeah
that
that
makes
sense.
Otherwise
it's
just
an
experimental
extension,
and
I
think
he
was
talking
about
having
you
know,
one
layer
set
of
layers
that
were
more,
you
know
more
specific,
more
defined
than
others
and
others
would
be
just
you
know
a
simple
extension,
I'm
doing
a
work
in
progress,
test,
right
kind
of
thing,.
F
I'd
I'd
worry
about
feature
detection,
so
we
have
to
be
very
careful
about
the
semantics
of
new
apis
because
old
registries
don't
know
about
them,
and
so,
if
say
like,
you
define
a
404
as
a
reasonable
response
to
some
request.
That
indicates
something
useful
like.
Oh,
this
link
doesn't
exist,
or
this
has
no
links
you
have
to
under
like
that
may
be
what
the
intended
response
is
from
the
registry.
F
But
the
registry
also
might
just
be
returning
a
404
because
it
doesn't
support
that
and
if
you
say,
return
a
501,
if
you
don't
support
that.
Well,
we're
not
going
to
be
able
to
change
every
registry
that
did
return
to
501..
So
I
think
this
is
useful
beyond
feature
detection.
For
that
reason,
but
I
generally
agree
that
it's
nicer
to
you
know
just
try
to
use
the
api
and
if
it
works
it
works
or
not.
B
So
from
like,
we
would
I
like
to
there's
a
separate
conversation,
we're
having
around
the
discovery
apis,
but
I
figured
this
is
a
good
way
to
test
this
model,
because
there's
so
much
wrapped
into
the
artifact
manifest
conversation
and
the
reverse
link
api
conversation
regardless,
like
what
I
would
love
to
see,
I'd
love
to
see
it
in
distribution.
Right
like
I,
just
love
to
be
able
to
know
that
all
distribution,
whether
or
not
they
support
them,
just
like
catalog
management
or
the
other
things.
B
There's
a
interesting
set
of
questions
of
what
extensions
are
clearly
extensions
that
are
unique,
maybe
to
a
specific
registry
or
to
a
specific
company
right.
A
company
might
plug
in
something
that
only
that
you
know
acme
rockets
would
use,
but
then
there's
a
set
of
features
that
I
just,
I
think
we
agree
we'd
like
to
add,
and
we
just
we
have
to
figure
out
how
to
agree
on
what
what
we'll
add
so,
rather
than
one
way.
B
So
whether
or
not
it
stays
in
artifacts
or
not,
is
a
good
question,
but
at
least
it
helps
us
test.
This
extension
api
was
kind
of
the
the
thought
process
and
then
the
detail
that
I
had
there
is.
I
couldn't
tell
from
this
whether
we're
saying
we
want
to
do
underscore
extension
in
the
root
of
v2,
so
that
we
can,
you
know,
do
something
where
it's
you
know.
B
B
F
The
this
concept,
I
don't
think
the
proposal
is
that
you
have
the
entire
api
path
after
the
extension,
but
like
a
hard-coded
identifier
for
a
feature
like
one
or
two
like
a
pep
we'd
have
like
an
oci
enhancement
proposal,
and
if
you
implement
oep
number
three,
then
this
would
somehow
be
surfaced
that
way
not
like
you
just
try
the
api.
Does
that
make
sense.
A
H
B
H
H
This
is
the
microsoft
way,
and
hopefully,
people
like
it
and
eventually
that
could
get
merged
into
distribution
if
enough,
if
it
kind
of
catches
on,
but
I
don't
know-
and
I
john
we
were-
there-
was
some
discussion
about
this
last
week
like
is
there
some
way
for
us
to
test
these
things
out?
Is
there
some
server
implementation
that
could
provide
a
way
to
like
play
around
with
some
new
features,
but.
F
A
F
H
But
if
it
if
we
can
agree
on
like
what
the
contract
is
with
this
plug-in
system
or
extension
system,
then
that
might
be
the
perfect
thing
because
it's
like
I
don't
want
to
call
your
code
throw
away
code
but
like
for
people
to
play
around.
But
I
don't
know
I
don't.
I
don't
really
know
what
I'm
talking
about
here.
So.
F
No,
no
you're
making
a
good
point.
I
mean
it's
a.
It
would
be
nice
if
there
was
an
easier
way
to
experiment
with
this
stuff,
and
I
agree
and
I'd.
If
someone
wants
to
forget
and
use
that
in
conversations
we
can
you
know
it's
a
useful
tool.
I
don't
know
like.
I
want
it
to
be
an
official
thing,
but
as
a
pattern
like
forking
this
in
memory,
implementation
is
totally
reasonable.
H
So,
let's
use
manifest
lists
as
an
example
and
I'll
just
I'll
I'll
use
zot
as
a
example
project.
Just
because
I
think
zot
is
relatively
new
code
base
that
compared
to
like
distribution,
which
a
pr
might
take
like
two
years
to
get
in
like
if
you
could
somehow
start
the
server
and
point
to
a
directory
of
binaries
that
expand
the
capabilities
of
the
server.
H
Or
capabilities
that
you
wouldn't
have
otherwise
and
then
to
remove
the
capability,
you
just
remove
that
binary
and
there's
like
a
contract
between
I'm
over
using
the
word
contract,
but
there's
like
a
contract
between
the
way.
The
binary
interacts,
where
the
plug-in
binary
interacts
with
the
octa
binary,
and
you
can
only
do
so
many
things
so
kind
of
like
advanced
version
of
swagger
like
if
we
could
say,
expose
like
certain
endpoints
in
a
way
that
I
don't
know
it's
not
fully
fleshed.
H
B
I
can't
think
of
any
of
the
cloud
registries
that
be
willing
to
run
arbitrary
customer
code,
like
that.
That's,
like
the
most
scary
thing
possible
so
like
each
one
of
us
will
say
we
want
to
support
a
certain
extension
if
somebody's
written
source
that
we
might
use,
then
we'll
of
course
evaluate
it
and
look
at
it
and
if
we
come
to
it,
we'll
we'll
deploy
it.
B
What
we're
trying
to
solve
here
is
what
namespace
should
extensions.
Should
I,
if
I
have
an
api
that
I
want
to
be
generally
useful,
it
may
not
be
in
distribution
and
it
it's
more
useful
than
just
acr
the
acr.
We
have
a
bunch
of
acr,
slash
extensions
that
we
have
for
actually
for
our
discovery,
apis
and
other
things
that
we
we
do
that
aren't
in
distribution.
H
H
And
then
you
know,
whichever
project
wants
to
provide
what
I'm
describing
just
for
as
a
playground
experiment
they
would
expose
those
endpoints
under
the
underscore
ext
and
you
know
acr
might
in
a
production
way
implement
that
in
the
best
way
possible,
but
I'm
just
I'm
I'm
kind
of
like
coming
at
it
from
the
like.
Let's
play
around
with
some
stuff
for
fun
at
angle
and
not
like,
I
have
customers
angle.
F
I
I
I
think
I
agree,
like
I'm
happy
to
debate
with
steve
endlessly
on
prs
about
things
abstractly,
but
it's
it's
useful
to,
I
think,
have
an
implementation
to
play
with.
So
people
can
say:
oh
yeah,
this
works
for
my
use
case.
I
wrote
a
client
and
it
it
does
this
versus
like
I'll.
I
will
literally
talk
about
software
until
I
fall
asleep
abstractly
and
that's
not
particularly
useful.
H
B
B
In
addition
to
underscore
catalog,
we
should
probably
note
as
a
reserved
space,
so
if,
if
folks
are
fine
with
the
understood,
ext
and
I'll
ping,
vincent
and
justin
cormack,
just
for
two
that
I
know
that
reference
that
had
conversations
about
this
and
and
if
john,
I
think
you
were
the
other
one
that
was
active
on
this
and
derek
if
everybody's
good
with
the
understory
ext,
then
I'd
like
to
start
moving
forward
with
that.
So
I
just,
but
I
don't
want
to
move
forward
in
a
place
that
people
are
surprised.
F
B
F
F
B
I
guess
part
of
it
is
I'm
I'm
challenging.
Do
we
really
do
the
kept
thing
or
just
put
names
in
that
are
meaningful,
so
that
I
can
say
like
there
is
a
this
pr
had
a
simple
table
that
people
could,
you
know,
put
pr,
you
know,
put
their
submit
their
name
going:
hey
yep,
I'm
trying
to
put
this
extension
in
so
oci
dash,
artifacts
and
then
a
quick
just
quick
link
to
maybe
the
spec
yeah.
That's.
A
And
use-
and
you
just
found
the
reason
right,
because
you
you're
basically
having
a
catalog
into
the
extensions
right
there.
You
know:
what's
the
table
and
yeah,
you
could
use
alphanumeric,
I
think,
for
he
wanted
to
use
numbers.
We
could
ask
vince
why?
But
I
believe
so
you
could
have
you
know
just
a
small
little.
These
are
the
ones
we
support.
Yes
or
no
kind
of
kind
of
thing
you
know,
use
feature
gates,
like
john,
was
talking
about
right
using
the
kep
process.