►
From YouTube: OCI Weekly Discussion - 2021-08-18
Description
Recording of the weekly OCI developer's call from 18 Aug 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#August-18-2021
B
Hello,
as
with
last
week,
if
there
are
maintainers
on
the
call,
I
see
derek,
I
would
be
interested
in
feedback
on
this
data.
Pr.
B
That's
all
I'll
say
about
that,
and
then
I
have
had
folks
reach
out
to
me
about
like.
Can
we
use
helm
with
this
experimental
oci
thing?
Is
it
okay
and
like
from
my
perspective
as
a
registry
operator
helm,
is
using
the
registry
api
in
an
acceptable
way
that
I
think,
is
fine,
but
I
think
customers
are
wary
to
use
something
that
is
marked
as
experimental
explicitly
and
when
I
went
digging
into
this.
I
found
like
this
thread
where
bacon
gobbler
said
they
would
like
something
to
be
blessed
by
oci.
B
A
A
Because
honestly
we'd
get
responses
from
various
maintainers
and
tob
members
that
have
not
stated
that
it
is
a
real
thing
or
not
and
with
you
know,
josh
kind
of
covered
this
in
his
podcast
a
while
ago,
so
they're
kind
of
caught
in
this
spot,
where
they're
trying
to
look
for
what
is
a
a
compliant
answer
to
this,
the
that
is
tied
up
in
a
couple
things
because
we
get
this
in
acr
as
well.
Is
this
okay?
This
is
a
helm
helmet.
A
I
thought
that
for
a
second,
I
was
wondering
if
you're
important
to
a
gcr
question,
we
get
this
from
azure
customers.
All
the
time
does
azure
support
this
thing.
You
know
with
the
things
that's
experimental.
It's
like
okay,
the
experimental
flag
is
on
the
helm,
cli,
it's
not
a
azure
cli.
We
don't.
We've
actually
been
trying
to
deprecate
our
azure
specific
cli
around
helm
because
we
created
this
standard,
so
it
didn't
have
to
be
unique
to
azure.
There
is
active
work
to
get
the
experimental
flag
removed,
I'm
noticing
this
is
commented
on
june.
A
I'd
have
to
read
this:
it
actually
references
the
hip
six
proposals,
so
I
believe,
because
josh
is
out
taking
some
time.
So
when
I
pinged
him
last
before
my
vacation,
he
was
still
actively
closing
down
the
issues
to
meet
hip
six.
A
B
Yeah,
I
mean
I've
found
docs
from
us
and
microsoft
and
amazon
of
like
how
to
use
this
experimental
feature,
and
so
that
seems
like
an
implicit
endorsement
that
like
yes,
we
think
it
is
fine
to
do
this.
If
they
I
mean,
I
know,
there's
probably
technical
work
to
be
done,
but
this
seventh
point
and
hip
six
is
like
they
want
an
official
blessing
of
some
kind
I'd.
I
would
say
like
by
the
power
vested
in
me.
B
B
A
A
Whatever
this
thing
is
zoom
and
then
I'll
paste
it
in
the
hack
dock
as
well,
but
that's
that
has
been
the
source
of
the
debate.
I
I'm
not
saying
I
agree
with
the
debate.
I'm
just
saying
and
I
think,
when
the
distribution
spec
doc
became
a
100
release,
there
was
a
lot
of
great
work
done
to
refer
to
things
as
artifacts.
Not
just
images
images
was
one
of
the
many
artifacts
I
I
was
surprised
to
see
this
still
being
a
question
honestly.
B
Yeah,
I
guess
I
don't
really
understand
what
it
means
to
release
like
a
bunch
of
markdown.
I
guess
that's
what
our
specs
are
as
well,
but
there's
also
like
code
in
the
specs.
You
know
like
there's
some
ghost
structs
that
you
may
want
to
use.
So
I
don't
know
I
like.
I
would
say
that,
given
the
1.0
of
distribution
and
image
spec,
the
artifact
stuff
is
a
composition
of
those
two
released
things
yeah,
I
I
don't
know
I
don't
know.
A
A
It
was
posted
in
july.
That's
when
josh
was
still
finishing
up
some
work
there
on
that.
So
I
don't
know
I
this.
I
mean
this
showed
up
what
five
minutes
before
the
call.
So
I'd
have
to
read
more
about
this
latest
rant
on
it's
a
circular
dependency
problem.
They
don't
want
to
depend
on
anything
in
oci
until
it's
released
and
then
the
release
stuff
says
well,
we
can't
really
adopt
it
until
there's
usage
and
there's
plenty
of
helm
usage
here.
So
I'm
not
quite
sure
what.
A
Did
this
actually
came
up
on
the
buildex
conversation,
because
there
was
a
debate
of?
Can
you
how
many
registries
support
index
that
has
blobs
in
the
manifest
collection
versus
the
the
artifacts
approach?
The
way
you
store
change,
the
config
media
type-
and
I
think
the
hub
is
still
has
a
too
much
of
a
restriction
which
justin
says
they're
still
working
on
finishing
that
up,
and
I
can't
remember
the
other
one.
Does
anybody
remember
where
that
issue
was
that
build
x
was
captured,
which
had
the
listing.
A
E
Issue
I
mean
working
is
a
little
ambitious
to
describe
that,
but
we're
aware
of
the
issue
and
it's
you
know
working
through
the
process.
A
A
A
C
C
A
A
So
look
it
just.
It
comes
back
to
what
we
talked
about
before,
like
not
having
something
as
a
release,
spec
as
minimal
as
whatever
that
means
has
caused
ambiguity
from
various
different
channels.
A
The
question
you're
actually
raising
around
go
modules
in,
and
I
think
I
saw
michael
here
yeah
ibm
michael
brown.
Well,
all
right,
that's
a
pivot,
so
I
want
to
be.
I
think
it's
a
good
question
I
actually
have.
I
want
to
tease
up
a
separate
item
for,
should
we
put
language
specific
code
into
a
spec
because
we're
having
that
exact
conversation
with
artifacts
and
the
conversation
I
had
with
michael
here
was:
there
was
a
versioning
problem
that
made
that
difficult
for
us
to
make
changes
and,
michael,
maybe
remember
what
the
details
were.
A
But
before
I
tangent
that's
that
was,
I
don't
know
what
people
want
to
do
like.
If,
if
we
wanted
to
put
a
vote
and
put
a
nod
into
that
issue
that
I
put
there
on
the
one
that
mike
matt
farina
opened,
what
else
do
you
want.
C
B
This
is
pre-distribution
1-0,
oh
on
the
9188
on
helmhelm
there's
like
a
conversation
about
well
distribution.
Spec
is
one
out,
and
then
they
say
it's
unclear
what
their
oci
artifact
is
1-0.
B
A
B
A
A
What
now
that
we've
shipped
things
this
way
where
the
distribution
and
image
specs
that
are
supposed
to
be
marked
on,
as
you
said,
do
have
go
modules
in
them,
which
makes
it
interesting
the
windows
image
issue
that
we
had
a
couple
months
a
month
or
two
ago,
I've
lost
track
of
time
where
there
was
a
case
changing
of
the
letter,
s
that
wasn't
caught
by
somebody,
because
they
had
to
re-implement
the
cl
the
api
and
the
interface
in
the
net
library
they
just
missed
it
like
just
humans,
are
part
of
the
process.
A
It'd
be
nice.
Maybe
if
there
was
multiple
languages
that
implement
the
various
specs
right
now
we
have
languages
in
a
particular
spec
and,
michael
again,
I
forgot
what
it
was
when
we
wanted
to
release
a
new
version
of
I've,
seen
myself
jiggle
all
over
the
place,
so
I'll
just
shut
that
off,
because
it's
just
weird
I,
the
new
version,
is
how
do
we
resolve
the
go
modules
in
a
released
version
way?
G
I
see,
I
see
your
question
yeah
generally,
you
would,
you
would
have
to
add
a
tag.
You
can
do
a
go,
sub
module,
yeah,
it's
it
wouldn't
be
easy
or
impossible.
A
The
as
we
release
a
new
version
of
distribution
as
we
release
a
new
version
of
artifacts
as
a
release,
new
version
of
image,
whatever
they
may
be,.
G
Yeah
they're,
usually
so,
if
they,
if
they
have
code
they're,
usually
associated
with
you,
know
the
the
subdirectory
where,
where
we
keep
the
you
know,
the
helpers
that
get
imported
by
the
the
various
clients,
if
you
were
to
go,
look
in
in
the
container
runtimes
run,
see
et
cetera,
you're
going
to
find
uses
of
the
the
of
the
image
spec.
G
A
G
By
path
yeah,
which
is
a
little
ugly
for
go
because
because
we
don't
have
support
for
generics
yet
and
go
so
if
you're
going
to
add
another
version,
they
would
literally
have
to
change
their
imports.
A
So
the
as
a
practice,
what
I
guess
I'm
trying
to
ask
is:
should
we
leave
like,
for
instance,
and
we
did
this
with
baraz
recently,
where
there's
or
as
dash,
go
there's
auras-pie
or
as
dash
rust.
I
think
there
was
somebody
was
wanting
to
start
on
that.
Do.
G
A
G
We
we've
typically
just
stuck
to
go
for,
for
you
know,
obvious
reasons
right
all
the
code
for
run
c
moby,
the
distribution
distribution
is
all
ready
to
go,
so
we
so
we
just
did
it
that
way
to
help
with
those
implementations,
and
then
I've
seen.
G
For
you
know,
programming
languages
like
rust
that
are
using
you
know
using
the
same
stuff
and
doing
the
same
kind
of
implementations
even
c
run.
That
has
some
libraries.
So
you
know
people
are
trying
to
maintain
this
kind
of
stuff
and
hopefully,
in
some
of
the
you
know
more
convenient.
G
You
know,
regroup
repositories
like
containers,
but
yeah.
We
don't
always
do
it
inside
of
open
containers.
We
just
haven't
had
the
time
to
support.
We've
had
a
lot
of
requests
for
it
it,
but
we
haven't
had
a
lot
of
you
know:
maintainers
want
to
come
on
board
to
make
to
keep
up
with
those
other
languages,
and
then
we
talked
about
language,
agnostic,
kind
of
implementations,
and
you
know
with
generators,
and
we
just
didn't
go
very
far
with
that.
Yet.
A
G
If
you
do
one
language
in
github,
they'd
like
you
to
pick
which
one
that's
usually
why
you
end
up
with
one
repo
per
language,
just
that's
exactly
what
I'm
saying.
D
H
A
F
I
think
the
person
was
on
here,
but
I
wanted
to
be
like
yeah.
I
think
that's
me.
So
there
was
also
the
reggie
client,
which
I
implemented
in
python.
I
I
guess
I'm
sort
of
the
the
weirdo
developer
out
there.
That's
like
excited
to
do
these
things,
so
I,
if
you
ask
if
it's
like
a
real
thing,
I
would
I
would
say
yes.
G
A
How
do
we
set
it
up,
so
we
can
do
this
kind
of
thing.
That's
what
I'm
more
asking
I'm
not
suggesting.
We
do
implement
12
different
languages.
What
I'm
saying
is:
should
we
factor
the
languages
out
so
that
the
specs
are
the
specs
that
get
released,
the
libraries
get
updated
when
they
should
be
updated,
whether
we
decide
that
they
have
to
be
updated.
To
really
suspect
is
an
interesting
question.
I
Yeah,
I
wonder
who
who
is
consuming
the
python
version
of
auras.
F
Yeah,
so
I
I
wanted
to
kind
of
comment
on
that.
So
one
of
the
things
that
I
would
like
to
improve
upon
and
at
least
like
the
hpc
community,
is
just
our
interaction,
not
just
with
oci
but
just
with
the
whole,
the
whole
ecosystem.
F
Ones
so
c,
plus
plus
not
very
much
like
rust
or
go,
but
you
know
kind
of
the
old-school
languages
like
fortran
that
he'd
seen
these
really
old
codes,
but
then,
when
it
comes
to
actually
research,
most
researchers
are
using
like
python,
small
subset
of
rr
or
maybe
julia,
and
so
the
reason
to
do
things
in
python
is
really
to
bring
in
that
entire
community.
F
I
think
there's
so
many
tools
here
that
people
in
the
hpc
or
scientific-
you
know
academic,
ecos
community,
don't
don't
even
give
a
second
look
at
because,
like
just
go,
isn't
in
their
tool
belt
of
things.
So,
if
anything,
I
think
it's
worth
a
try
to
create
all
these
things
in
python
and
then
you
know
hand
them
to
that
community.
Be
like
hey
look
at
this.
This
is
something
that
could
be
useful
to
you.
F
I
Yeah
so,
incidentally,
the
turn
community
has
been
thinking
about
rewriting
some
of
most
of
our
code
in
go
because
the
community
that
we
work
with
this.
I
I
G
I
Yeah,
unless.
I
I
D
I
Years
ago,
java
was
the
hotness
and
now
go
is
the
hotness,
but
there
are
still
people
that
are
using
java,
and
so
they
don't
want
to
miss
out.
I
G
I
But
you
know
that
is.
That
is
one
of
the
things
that
I'm
wondering
about
because
considering
that
we
now
live
in
this
country
containerized
world,
and
there
is
no
more
portability
issue
and
dependency
issue.
People
still
want
to
you
know,
work
use
the
thing
that
everyone
else
uses.
I
mean,
there's
still
like
some
homogeneity
in
the
connections
so
yeah,
I
don't
know.
C
It's
like
brings
me
to
a
question.
I
don't
know
niche
or
ness
or
both,
but
what
are
people
today
using
like
the
python
binding
stuff
like
that
to
talk
to
a
registry
for
because
that
is
like
mike
was
saying.
Usually
the
the
data
scientists
are
doing
the
data
coding
inside
of
the
containers?
They
don't
really
care
about
the
registry
at
that
point,
so
I'm
curious
about
the
use
cases.
F
I
think,
on
my
side,
the
use
case
is
more
sort
of
what
a
research
software
engineer
would
do.
So,
if
you
think
of
the
like
a
couple
of
three
different
groups-
they're
sort
of
like
the
linux
clinics
or
the
system,
administrators
they're,
the
ones-
arguably
that
are
like
you
know-
installing
selling
software,
where
they
they
use
modules
or
they
use
some
kind
of
package
managers-
that's
sort
of
their
thing-
they
may
make
containers
available.
F
Then
there,
of
course,
are
the
researchers
on
the
other
side
that
are
doing
everything
sort
of
in
those
languages,
but
in
the
middle
of
that
are
sort
of
like
the
research
software
engineers
or
the
rses
and
they're
figuring
out
like
okay.
I
have
this.
You
know
scientific
code
on
my
right,
it's
in
python
and
I
need
a
way
to
communicate
with
some
infrastructure,
that's
available
or
whatever
on
the
hpc
or
cloud
or
something.
I
need
to
write
some
like
binding
between
that.
So
I
think
I
don't
see.
I
think
I
agree.
F
I
don't
see
like
the
the
person.
Writing,
like
the
physics
simulations
to
be
thinking
a
lot
about,
like
you,
know,
registries
or
continue
runtimes,
but
I
think
the
people
that
are
trying
to
make
everything
work
together
are
going
to
be
interested
in
those
kinds
of
tools
that
kind
of
connect.
These
disparate
things.
C
And
it
might
be
well
I'll,
I'm
going
to
finish
this
point
up
now,
I'm
trying
to
uc,
but
it
might
be
that
you
know
if
we
provide
some
of
the
tooling,
we
get
it
working
nicely
and
go
that's
just
executable,
then
that
binding
might
just
be
shell
out
and
called
the
executable.
We
provide
to
do
it,
and
so
they
can
still
do
their
stuff
in
python
and
we
just
got
the
tools
over
and
go
that
we're
maintaining
for
them.
G
F
I
think
there's
probably
cultural
boundaries
too,
so
for
one
one
very
easy
example
is
look
at
singularity
and
c
and
python
and
bash,
and
it
was
converted
to
go
and
just
the
install
process
it
used
to
be
in
auto
configure
and
then
installing
with
go.
A
lot
of
linux
admits
were
very,
very
ordinary
about
that.
F
G
G
J
Yeah-
and
I
like
it
with
what
vanessa
from
from
sandiaside
too
from
the
labs
here
with,
is
it
the
op
side?
Was
it
the
scientist
side?
You
know
bridging
the
gap
right
now
in
some
like
current
work
with
devops
mlaps
and
the
data
scientists,
you
know
trying
to
draw
that
line
of
you
know.
This
is
conversations
I
have
with
in
the
amalops
community
too,
where
my
some
of
my
data
scientists
do
not
want
to
go
deep.
They
don't
have
to
worry
about
the
configuration
of
the
containers.
J
F
And
then
the
other
detail
add-on
to
that
is
like
let's
say
that
you
are
using
something
that
happens
to
be
go
and
there's
some
nasty
error
that
prints
the
console,
if
you're,
let's
say
you're
an
rse
or
your
scientist
and
you're,
there
are
languages
that
you're
comfortable
with
and
there's
a
degree
to
it.
You'll
feel
empowered
to
like
go
to
the
source
code
figure
out
what's
going
on
and
then
you
know
open
a
pr
an
issue
and
like
help
fix
it
versus
just
being
like.
F
Oh,
this
isn't
go,
I'm
just
gonna
like
not
use
this
anymore.
So
that's,
I
think,
just
increasing
your
contributions,
but
I
think,
as
probably
someone
listening
to
this
right
now
would
point
out
as
soon
as
you
choose
one
language
over
the
other.
You
know,
then
you
lose
the
other
group
that
was
more
familiar
with
the
first
language.
So
it's
a
double-sided
coin.
A
Yup-
and
I
just
wonder
like
there's
lots,
we
see
lots
of
different
language,
implementations
of
the
various
toolings
and
they're
in
random
places,
and
nobody
ever
wants
to
contribute
to
the
next
one.
It's
not
mine
where,
if
there
is,
if
they
were
in
the
body
that
owns
the
spec,
let's
say
wherever
the
right
foundation
is
depending
on
the
thing
you
know.
If
you
know
fred
wants
to
make
change,
he's
not
willing
to
build
it
up
himself,
but
he
sees
something
into
vanessa's
point.
A
If
there
is
an
error
that
change,
because
we
change
something
or
we
clarify
something
or
it
just
wasn't
right
in
the
first
place
like
a
capital
s,
then
somebody
else
could
just
make
that
pr
and
fix
it
as
opposed
to
having
to
maintain
multiple
branches
of
different
things
or
multiple
repos.
So
I'm
just
wondering
if,
if
there
is
language
specific
needs,
if
we
at
least
enable
the
opportunity
for
that-
and
you
know,
auras
is
the
interesting
one
like
the
rust
one
got
created,
it
was
dormant.
A
A
Should
we
like
the
question
I
kind
of
started
off
with,
should
they
just
be
separate
language,
specific
repos,
so
that
you
could
have
different
maintainers
that
own
those?
The
idea
is
that
vanessa
was
a
maintainer
on
the
python
repo,
but
she
may
not
be
on
the
spec,
let's
say
or
whatever
the
other
one
was
so
she's
now
empowered
to
own
that
if
somebody
else
wants
to
contribute,
they
can
make
a
pr
to
the
the
python.
I
I
just
want
to
talk
about,
like
the
the
python
use
case,
with
regards
to
like
working
in
a
predominantly
go
ecosystem,
so
we've
gotten
around.
I
You
know
that
thing
that
block,
usually
by
shelling
out
to
whatever
tools
are
there,
but
what
we
found
with
the
go
ecosystem
is
that
there's
a
lot
of
functionality
that
isn't
exposed?
I
I
I
I
think
there
are
some
other
stuff
that
is
kubernetes
related.
That
you
know
cannot
be
integrated
well
because
turn
is
written
in
python.
I
So
it's
it's
kind
of
you
know
we,
we
don't
have
a
choice
in
this
matter
and
I
and
perhaps
it
may
be
the
same
thing
on
python.
Although
python
is
way
more
forgivable
than
go,
is.
A
I'm
trying
to
understand,
if
you're
trying
to
say
that
turn
should
just
move
to
go
and
not
worry
about
python
anymore
or
it's
just.
It
would
be
helpful
if
there
was
two
because
different
audiences
use
different
tools
for
the
reasons
that
they
do
like.
I
don't
expect
the
ml
community
to
move
to
go
right.
They've
clearly
got
their
feet
dug
into
their
language.
I
would
just
be
happy
if
they
stop
generated
monstrous
images
and
we
can
figure
out
how
to
help
them.
Do
that.
I
I
mean
see:
that's
that's
part
of
the
problem
right,
the
the
monster
images
are
coming
because
the
the
modules
are
so
big
and
the
generally
ml
folks
are
not
interested
in
the
system
level
stuff
that
the
containers
do.
I
We
just
happen
to
write
a
tool,
a
system
tool
in
python,
and
that
might
be
because
I
am
historically
from
the
embedded
world
and
the
the
systems
like
the
os
installation
world
that
usually
works
with
c
and
python,
for
automation,
c4,
libraries,
python
for
automation
and
especially
with
build
tools.
So,
for
example,
yocto
project
is
written
in
python.
I
I
C
F
Liked
that
idea
you
have
about,
like
you
know,
being
able
to
make
python
bindings
from
go.
I
I
had
kind
of
thought
of
that
when
I
started
working
on
the
auras
python-
and
I
just
like
didn't
find
anything-
is
this
something
we
can
like
ask
google
put
in
like
a
feature
request
that
like
to
start
thinking
about
or
working
on,
because
it
seems
like
it
would
be
so
useful,
and
it's
that
middle
ground
thing
that
we
need.
D
G
A
So
if
we
talk,
I'm
still
trying
to
come
back
with,
do
we
create
separate
repository?
If
we,
if
you
were
to
create
the
thin
wrappers,
would
you
still
have
those
in
a
separate
repo?
Would
you
try
to
put
them
in
the
single
repo
like?
Would
you
have
the
distribution
spec
with
go
python
rest
in
the
same
repo
or
would
you
have
the
distribution
spec
be
the
markdown
files
and
the
language
is
marked
down?
If
you
will
and
then
there's
a
separate
repo
that
says
this
is
go.
There's
a
separate
repo
that
says
this
is
python.
I
The
easier
one
is
to
have
everything
in
one
repo,
but
it
it
depending
upon
what
oh
vanessa's
saying
no
way
no
way.
F
A
C
I
was
gonna
come
back
to
steve's
question,
though,
in
terms
of
where,
to
put
it,
I
don't
think
it
makes
too
much
sense
to
put
it
in
oci
just
because
we
don't
really
have
a
lot
of
implementations
other
than
run
c.
You
know
so
there's
no
main
that
they
would
be
dropping
in
to
have
that
wrapper
script
in
there.
F
Yeah,
it
could
be
that
there's
some
kind
of
product.
I
think
this
is
something
that
oci
has
been
kind
of
dealing
with
a
long
time.
There's
like
the
specs
like
markdown
and
then
there's
like
projects
that
are
actual
implementations,
and
I
guess
the
projects
that
are
sort
of
blessed
by
oci
belong
like
alongside
the
oci
specs,
but
for
projects
that
you
know
might
be
like
some
version
of
something
in
python.
Maybe
I
think
it
does
make
sense
to
have
them
separate.
You
know
they're,
not
like
official.
F
Oci
projects,
but
then
to
maybe
just
within
oci,
have
like
one
repo
that
serves
more
documentation
like
here's
all
the
python.
You
know
wrappers
or
whatever
for
this
that
we
have.
So
if
someone
does
make
a
project
and
they
want
that
visibility,
they
can
just
get
added
to
that
list,
and
then
it's
easy
also
for
someone
to
find
what
they're
looking
for.
C
G
A
A
Do
we
just
follow
the
if
it
is
a
bad
convention,
do
we
follow
it,
because
a
bad
convention
is
better
than
you
know,
differences,
or
is
this
something
that
it'd
be
a
nice
thing
to
clean
up
and
as
we're
doing
the
artifact
stuff,
like
literally
I've,
got
a
pr
from
avraham
to
check
in
some
go
modules
and
I'm
I'm
questioning?
Should
it
go
into
that
repo,
or
should
we
create
an
artifact
spec
dash
go,
and
I
think.
G
A
Well,
but
in
oraz
we
actually
did
split
those
out,
so
we
did
keep
juarez
the
repo
to
just
be
auras,
because
that's
a
cli,
maybe
you
don't
care,
it
just
happened
to
be
written
go,
but
we
did
refactor
things
to
have
or
as
cli,
sorry
or
as
libraries,
because
if
you
look
at
helm,
helm
is
actually
used
in
the
libraries
they're,
not
using
the
client
right.
They
use
the
libraries
we
just
built
this
or
as
client.
A
That
was
basically
here's
this
universal
test,
client
that
we
don't
expect
anybody
to
use
in
a
production
production
as
the
thing
for
their
specific
artifact.
It's
like
here's
a
file
api,
but
if
you
want
to
build
like-
and
I
demoed
this
this
morning
with
spdx,
it's
like
spdx
push
spd
xls,
you
know
xps
discover
and
it
used
well
used
a
bunch
of
things.
The
theory
is,
it
would
use
the
auras
libraries
and
reference
types
to
generate
s-bombs
and
push
them.
A
It
happened
to
be
written
and
go.
You
know
it
happened
to
use
the
go
libraries,
but
if
somebody
wants
to
write
it
on.net,
you
know
they
could
write
it.net
or
python
or
or
whatever,
and
the
idea
is
that
those
are
available.
So
we
did,
we
did
split
them
out
and
I
think
that's
helped
with
in
clarity.
It's
only
been
a
month
so
we'll
see
what
people
think.
F
Yeah,
so
I'm
just
a
general
reference,
so
that's
how
github
is
basically
github
has
a
restful
api
and,
of
course
everyone
writes.
You
know
a
client
in
their
favorite
language
and
so
kind
of
akin
to
what
I
was
saying
before.
Is
that
there's
just
a
page
that
they
have
on
their?
You
know
official
site
that
says
like
here's,
all
these
tools
and
all
these
languages
that
you
can
choose
from.
You
know
they
aren't
under
github,
but
they
are
available
and
it
has.
A
A
We
wait
for
vanessa
to
get
further
along
before
we
put
it
under
the
org
and
then
she
would
donate
it.
Maybe
first
it's
a
link
as
a
duck
link,
as
we
just
said.
But
what
do
you
think.
D
C
Yeah,
what's
been
me,
working
with
justin
toto
lately
is
that
they've
got
the
python
and
the
go-lying
implementations
and
they're,
just
not
in
sync,
and
so
as
a
user
of
that
when
you
have
something
that
has
two
different
implementations
that
are
following
two
different
versions
of
the
spec.
It's
just
hard
on
users.
A
C
I'd
I'd
rather
have
one
or
not
to.
F
I
think
in
some
ways,
though,
seeing
so
if
you
have
something
that's
sort
of
agnostic,
whether
that's
like
an
api
or
a
spec,
I
think
in
some
ways
seeing
this
desire
to
create
libraries,
different
languages
is
actually
like
a
a
sign
or
it's
like
a
progression
or
that
the
software
or
the
spec
or
whatever
has
reached
some
point
where
people
really
do
want
to
use
it.
It's
almost
like
a
sign
of
maturity
for
the
thing,
and
then
you
know
the
question
of
maintainership
like
yeah.
D
F
If
you
look
at,
for
example,
even
some
of
these,
these
github
clients,
what
happens
over
time?
Is
they
do
they
kind
of
explode
because,
like
everyone's
like?
Oh
there's,
not
a
get
out
kind,
I'm
going
to
make
one,
and
then
everyone
makes
one
and
then
it
sort
of
whittles
down
to
like
one
that
is
sort
of
better
than
the
others
that
people
tend
to
use.
So
it's
almost
like
this
organic,
like
growth
and
then
pruning
process.
F
So
I
think
I
I
it
almost
feels
like
it's,
not
something
we
can
just
decide
like
it
feels
like
we
should,
or
maybe
we
should
just
be
open
to
this
idea
that
it
could
happen,
and
we
should
support
it,
not
necessarily
saying
that
it's
a
good
or
a
bad
thing
and
just
see
where
it
goes
and
sort
of,
like
I
said
before,
the
worst
thing
that
happens
is
that
it
doesn't
go
anywhere,
but
I
think
I
think
it
would
be
bad
not
to
try
to
embrace
some
kind
of
effort
that
comes
sort
of
organically
from
the
community.
A
Especially
for
things
that
start
to
have
more
general
usage,
like
you
know,
when
the
image
stuff,
when
the
registry
of
image
spec
was
literally
just
container
images,
there
was
a
set
of
tools
that
you
know
michael,
was
kind
of
listing
earlier.
Now
that
we're
doing
it
more
generically,
I've
got
every
people
coming
out
of
the
woodwork
with
a
language
of
choice
and
like
we
have
an
entire
team's
two
teams
at
microsoft,
that
maintain
language
specific
apis.
A
For
so
that
we
never
lose
a
particular
community
of
developers
in
that
area.
So
I
agree
with
your
sense
of
maturity
aspect
so
when
it
reaches
it,
I
think
part
of
the
question
is:
when
is
it
when
it
reaches?
It
was
the
or
were
the
repos
structured
in
such
a
way
that
it
doesn't
look
weird
that
there's
like
this
default
language,
whatever
it
might
be.
I
don't
really
care,
let's
go
with
something
and
then
all
the
others
so.
G
Okay,
I
think
I
think
it
would
be
valid
for
to
use
code,
generators
and
validation
code
for
for
some
set
of
languages,
especially
for
you
know,
civilizations
and
civilization,
of
the
of
our
types
for
the
images,
for
example,
and
then
for
distribution
distribution.
G
Of
course,
we've
got
an
http
api
which
would
benefit
tremendously
if
people
want
to
write
clients
for
any
kind
of
artifact
kind
right
in
all
these
various
languages.
I
think
that
does
that
actually
make
sense,
I'm
in
a
container-
and
I
want
to
you-
know-
writing
javascript
and
I
wanna
pull
an
artifact.
It
makes
sense
right
so
so
I
do
think
this
is
a
good
idea.
I'm
I'm
not
trying
to
poo-poo
it.
It's
just
it's!
G
It's
a
lot
of
work
just
to
set
it
up
and
I
think
it
would
be
different
per
per
repo
based
on
how
we've
distributed
stuff
around
and
then
and
on
run
c.
It's
obvious
that
you
know.
We've
already
got
many
bindings
for
that,
and
that
would
be
in
there
in
their
project.
G
You
know
like
seagull
using
sorry,
but
but
you
know
some
similar
similar
tools.
It
could
be
used.
You
know
for
the
various
projects
to
add
additional
languages,
and
you
just
have
to
have
a
binding
library.
That's
built
and
tested
with
some
kind
of
container-based
integration
tool
set
in
inside
the
repo
should
be
doable
makes
a
lot
of
sense
wants
to
do
the
first
pull
request.
G
We
can
definitely
start
working
on
it.
Just
open
up
an
issue
in
your
favorite
repo.
I
think,
steve
and
and
well.
A
G
A
What
I
think,
I'm
hearing
just
to
kind
of
put
put
a
thought
out.
There
is
because
the
issues
are
language,
specific
repos.
If
there
are
multiples,
there's
a
problem
and
then
the
whole
model
repos
the
fun
part
of
it.
There's
you
need
a
set
of
maintainers,
which
is
they're
different
maintainers,
because
they're
good
from
passions-
and
you
want
to
enable
them
to
do
that.
A
Then
the
question
is:
does
it
stay
maintained?
So
I'll
uzora
is
a
perfect
example.
We've
got
two
repos
that
are
not
active
and
vanessa
will
talk,
so
you
know,
and
the
answer
would
be
like
hey.
If
you
want
to
do
this
great,
but
let's
do
it
in
a
place
and
get
it
to
a
stable
point
and
then
let's
move
it
over
because.
G
A
G
G
But
with
a
lot
more
people
involved
right
that
are
that
are
experts
in
this
field,
maybe
maybe
they
they'd
be
the
best
ones
to
volunteer
some.
G
A
And
I
I
think
the
code
generation
is
always
interesting,
whether
that
can
be
maintained
genetic
if
there's
a
tool
that
just
worked
I'd,
love
to
use
it,
but
even
at
microsoft,
where
I
know
those
teams
have
done
a
lot
of
investment
in
it.
It's
like
the
starter
and
then
there's
a
lot
of
tweaking
that
goes
on
and
there's
debates
whether
it's
really
worth
it
or
not.