►
From YouTube: CDF - SIG Interoperability Meeting 2020-12-10
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
C
B
D
D
D
We
can
add
our
names
to
participants
list
and,
while
that
happens,
I
can
talk,
walk
you
through
the
agenda.
It's
as
usual.
We
start
with
action.
Item
reveal
and
then
a
logistics
topic
like
upcoming
meetings.
As
you
know,
our
next
fitting
falls
on
christmas
eve
december
24th,
and
we
will
cancel
that
and
then,
when
are
we
meeting
next
time,
it
could
be
january,
7th
or
14th
which
we
can
discuss,
and
I
want
to
touch
the
white
paper
topic
as
well,
because
we
passed
the
date
we
thought
of
finalizing
the
paper
end
of
november.
D
And
after
that,
the
topic
events
in
cicd
workstring
to
become
a
separate,
seek,
and
I
see
some
members
of
the
work
stream
in
the
meeting.
So
we
can
have
a
discussion
on
that
topic
and
then
we
can
continue
talking
on
standardized
metadata
and
there
are
some
updates
to
the
document
we
created
for
it,
both
from
me
and
I've,
seen
james
stretch
and
also
into
the
jenkins
x
example
there,
and
then
the
presentation
demo
on
ortelius
has
been
on
the
backlog
for
a
while
and
steve
asked
me.
D
C
D
Yeah
so
good,
let's
start
with
action
item
reviews.
So
the
first
action
item
is
on
me
and
I
was
supposed
to
ping
cameron
which
I
did
few
weeks
ago
and
he
said
he
will
come
back
to
me
for
their
contribution
to
white
paper,
but
I
hung
her
back
from
him
so
and
we
are
getting
kind
of
late
with
the
white
paper
anyways.
We
can
perhaps
close
this
action
item
and
you
know
if
we
go
out
without
spin
case
study,
which
would
be
bad,
but
we
have
to
cut
this.
E
So,
just
very
quickly
no
real
progress
on
the
white
paper
itself.
E
I
think
we're
just
working
with
the
creative
team
on
the
annual
report
as
priority
first,
so
I
I
do
expect
the
we'll
get
around
to
it,
but
in
the
meantime,
I
think
it's
fine
to
wait
if
the
spinnaker
folks
do
want
to
add
that
in
okay.
E
Yeah,
that
being
said,
I
think,
when
we
do
get
around
to
both
from
our
side
and
with
the
creative
team
to
focusing
on
it,
we'll
probably
heavily
edit
it
and
then
yeah
there'll
just
be
no
options
for
anything,
but
tweaks
after
that,
so
okay,
they
can
take
their
chances.
D
Okay,
so
we
covered
two
action
items
we
already
gave
update
on
the
creative
team,
so
I
I
keep
both
of
them
open
and
the
next
action
item
is
on
ramen
and
I
don't
see
ramen
in
the
meeting,
so
we
keep
it
open
as
well
and
it
takes
time
to
get
approval
internally
in
this
type
of
thing.
So
it's
fine.
We
can
make
that
and
tracy
reagan
and
steve
the
I
keep
the
action
item
on
you
as
well
open
until
we
have
the
presentation,
demo
nortelius.
D
So
we
track
that
james
stretch
and
thanks
for
metadata
example,
I
think
it.
I
wrote
it
wrong.
I
put
it
jenkins
techton,
but
it
was
actually
jenkins
x,
yeah.
B
F
On
the
on
the
artelius
demo,
we're
looking
at
january
then
for
one.
D
And
the
next
action
item
is
on
events
in
cicd
workstream
to
provide
input
to
standardized
metadata
topic
based
on
their
discussions,
and
I
haven't
seen
anything
on
the
document
yet
so.
A
Now
I
can
comment:
maybe
yes,
unfortunately,
we
have
had
other
things
to
discuss,
so
we-
maybe
we
forgot,
actually
to
talk
about
that,
but
we
had
it
in
the
agenda,
but
you
know
they
came
to
that
action
to
that
agenda
point.
So
no,
we
haven't
okay.
D
Yet
we
keep
it
open
and
you
have
one
month
to
come
back
at
this
one
month.
So
those
were
all
the
action
items
still
good.
We
closed
one
of
them
and
the
next
topic
on
the
agenda
is
upcoming,
sig
meetings.
So,
as
I
mentioned,
while
I
was
talking
about
agenda,
the
next
meeting
is
scheduled
for
december
24th,
which
we
are
not
going
to
have
that.
So
the
proposal
is
to
be
coming
on
january,
7th
or
if
it
is
too
early
for
people
to
you,
know,
come
back
from
vacation
mode.
D
B
Well,
I
know
the
the
events
team
they
had
folks
working
that
week.
I
believe
they
weren't
back
until
the
9th
or
something
like
that.
A
Yeah,
so
we
would
not
have
the
meeting
the
fourth
of
january
that
monday,
but
instead
the
18th
of
mandarin
january
that
week,
so
we
will
skip
one
meet.
We
will
by
the
way,
have
the
meeting
21st
of
december,
which
is
the
monday
of
the
christmas
week.
So
we
will
only
skip
one
meeting
anyway.
D
D
B
D
D
E
Fatty
just
on
the
meetings,
just
a
slight
tweak,
I
just
like
to
ask
for
as
well,
because
we
have
our
end
user
council
on
the
second
second
thursday
of
the
month
and
the
interoperability.
One
is
at
the
moment
every
other
week,
which
is
fine
until
we
get
to
months
with
five
weeks.
E
So
I'd
like
to
just
formalize
that
we
have
the
interoperability
sig
on
the
first
and
third
week
of
the
month
and
so.
E
We
they
always,
they
will
never
overlap.
Does
that
make
sense
yeah
and
then
we
all
get
a
week
off
when
there's
five
weeks
or
we
can
schedule
special
working
sessions
in
in
that
extra
week
as
needed.
D
So
no,
this
confuses
me
a
bit
because,
like
when
I
look
at
the
calendar,
it's
actually
when
we
first
started
the
sig
interval
meetings.
We
agreed
to
run
the
meetings
every
second
week,
even
weeks,
but
seventh
of
january
is
and
not
even
week,
it's
odd
week
like
first
week
of
the
year.
So
what
you
are
suggesting
chris
tracy
is
like
we
need
every
first
and
third
week.
Yes,
correct!
Okay,
what
about
the
months
with
five
weeks
so.
D
Okay,
but
then
you
will
fix
that
invitation
yeah,
because
I'm
good
at
invitations.
Yes,.
D
So
sig
intervals
means
first
and
third
week
of
every
month,
every
month,
okay,
now
yeah,
please
subscribe.
A
F
F
If
so,
for
example,
if
the,
if
the
first
of
the
of
the
month
is
on
a
tuesday,
you
would
have
the
first
meeting
would
be
on
the
third,
because
that
would
be
the
first
thursday
of
the
month
would
be
on
the
third.
If,
if
the
month
is
beginning
on
a
tuesday.
D
Okay
but
yeah,
I
added
that
like
on
the
meeting,
so
please
update
it
if
you
can
clarify
it
further,
like
first
and
third
thursdays
of
every
month,
and
if
you
have
like
extra
thursday
for
any
given
month,
we
then
chat
on
slack
or
something
to
decide
what
to
do
and
can
I
action
you
tracy.
D
Okay,
so
the
next
topic
is
wrapping
up
the
white
paper
we
already
like
crazy.
You
already
mentioned
the
like
plan
on
it
anything
else.
You
want
to
add
there
or.
E
D
D
So,
as
you
know,
ci
cd
workstream
was
established
around
may
june
this
year
as
a
work
stream
within
sig
interoperability
and
few
people
who
are
interested
in
working
on
this
topic
came
together
and
started
working
on
it
and
they
are
doing
great
work
and
there
are
discussions
within
the
work
stream.
Whether
should
this
work
stream
become
a
top
level
seat
next
to
interoperability
or
not,
and
we
just
want
to
get
feedback
from
broader
sake
on
this
topic
and
then
it's
on
to
you,
emil,
andrea,
andreas
and
others.
A
Actually,
I
know
the
goal
as
well
if
we
should
actually,
in
fact
be
the
sig
of
our
own
within
the
events
group
and
the
reason
I
guess
there
are
multiple
reasons,
but
one
is
of
course
to
be
more
visible
in
the
in
the
cdf
as
such,
and
it's
called
this
is,
I
mean
event
handling-
is
considered
a
an
important
concept
that
should
be,
it
should
be
investigated
further
and
it
should
we
should
try
to
leverage
and
attract
more
people
by
by
making
it
to
zig.
A
I
guess
those
are
the
the
main
points
for
it.
Then,
of
course,
there
is
some
a
question
on
on
how
this
one
should
relate
to
the
secret
on
right
now.
Interoperability,
because
currently
it
is
a
sub
group
too.
That's
sick
and
still,
I
believe,
event
handling
is
the
most
sense
at
least
a
way
to
perform
interoperability
between
between
tools
and
systems
in
a
crcd
environment,
so
that
the
question
remains
to
be
cleared
a
bit.
I
guess
so.
We
can
have
clear
scopes
in
in
our
different
cities.
A
If
so,
and
I
guess
the
there
will
be
a
discussion
on
the
toc
in
the
city
of
early
january,
I
believe
on
this.
Yes,.
B
B
This
up,
when
I
was
looking
at
it,
you
know
there
is
the
community
at
large,
even
over
on
the
cncf
side
is
having
more
discussions
around
events
and
templating,
and
I
just
feel
like
we
as
the
cdf
really
need
to
be
seen
as
the
thought
leaders
so
making
this
particular
conversation
more
visible,
I
think,
is
pretty
important.
B
In
other
words,
we
you
know
we
should
have
some
of
the
folks
from
you
know.
We
should
make
sure
that
the
captain
folks
are
even
though
they're
in
the
cncf
that
they
can
cross
pollinate
over
to
the
side,
and
I
don't
know
if
they
would
cross-pollinate
with
interoperability,
but
I
think
that
they
would
be
attracted
to
events.
D
Okay,
anyone
else
like
this
makes
a
lot
of
sense
to
me
like
personally,
and
the
question
emil
brings
up,
like
the
relation
between
the
events
in
cicd,
seek
and
interpret
this,
if,
like
events,
become
its
own
seek,
and
what
I
think
is
like
events
is
one
way.
One
approach
to
address
interoperability,
issues
and
events
is
like
it's
a
trend.
It's
like
important,
both
within
cncf
and
other
communities
like
we
like
events
in
city,
workstream,
already
found
like
similar
initiatives
both
within
captain
tecton
and
eiffel
and
cloud
events
is
there.
D
So
it
makes
a
lot
of
sense
but
like
where
to
draw
to
like
draw
the
line,
because
not
everyone
is
using
events,
so
we
still
need
to
have
like.
We
still
need
to
work
on
this
metadata
topic,
maybe
in
like
kind
of
dependent
and
independent
at
the
same
time,
because,
as
I
said
like
some
people
may
be
using
rest
api
for
this
type
of
stuff
and
not
events
so
where
to
draw
the
line
and
how
these
two
seeks
could
continue.
Collaborating.
E
So
maybe
I
can
ask
a
question
first,
if
the
those
folks,
so
what's
the
current
scope
like
beyond
cloud
events,
what
sort
of
things
are
you
you
looking
at
in
that
work,
stream.
A
A
We
have
not
yet
at
least
started
looking
into
the
transport
layer
or
the
infrastructure
where
events
should
be
sent,
and
neither
have
we
looked
into
how
to
actually
produce
those
events
in
different
languages,
the
libraries
and
needed
to
how
to
consume
them,
but
rather
what
would
the
protocol
look
like?
So
we
have
very
much
focused
on
on
the
protocol
part,
which
is,
of
course
very
related
to
metadata,
because
the
protocol
is
is
what
contains
the
data
and
for
the
protocol.
A
E
Okay,
yes,
so
that
makes
sense
to
me
and
yeah.
I
think
that
the
general
scope
is
standardizing
events
coming
from
cicd
systems
unless
there
might
be
some
overlap
with
the
metadata,
but
that
doesn't
really
matter.
I
think
that
sounds
good.
H
Yeah,
I
think
that
there's
also
some
architectural
implications.
So
it's
one
of
the
things
that
we
were
discussing
is
reasons
whether
events
should
be
more
descriptive
or
prescriptive,
so
like
say
sending
events
to
ask
another
system
to
do
something
or
just
sending
events
with
information
and
they're
receiving
parties
deciding
how
to
act
based
on
those,
and
so
we
are
having
some
discussion.
We
didn't
really
come
to
a
conclusion
on
that
as
well,
but
it's
one
of
the
topics
that
we
are
covering.
E
Okay
and
yeah,
that
seems
just
right
in
scope.
For
for
what
I'd
imagine
needs
to
be
sorted
for
for
better
standardization.
D
So
we
reach
out
to
more
communities
at
the
same
time,
working
under
cdf
unreal
as
well,
and
just
to
note
we
are
not
here
to
approve.
We
are
just
having
a
discussion
so
like
the
workstream
members
can
go
and
you
know
create
whatever
proposal
or
charter
and
bring
it
to
talk
level
and
if
talk
approves,
it
becomes
sick.
So
this
is
just
brainstorming
and
finding
out
how
we
can
continue
the
work.
We
start
with
the
interoperability
when
we
have
the
events
sit
in
place.
E
Well,
I
think
we
already
had
a
charter,
so
just
taking
that
and
taking
that
to
the
talk
saying,
do
it
like
a
talk
to
sponsor
and
just
highlighting
the
repeated
meetings.
I
I
don't
think
there's
a
lot
of
process
around
it.
E
D
D
Okay,
so
you
answer
extreme
anything
else,
you
want
to
add
or
any
questions
about
the
next
steps.
A
Well,
just
to
comment,
I
guess
the
the
proposal
then
to
create
it
needs
to
contain
information
on
exactly
how
to
limit
the
scope
of
that
sig
towards
the
interoperability
zig
and
whatever
happens
with
the
metadata
group.
I
mean
there
has
been
discussions
also
if
the
metadata
group
should
be
a
sub
group
onto
the
events
instead
of
the
interoperability.
A
If
we
see
that
metadata
is
mostly
handled
within
events,
so
so
I
mean
such
issues
at
least
need
to
be
sorted
and
written
down
somewhere.
So
so
it's
clear
when
making
a
decision
on
having
a
signal,
not
what
the
focus
should
be
on
these
different
things.
B
So
emile
you're,
suggesting
we
tweak
the
charter
just
a
bit
to
clarify
that.
A
E
I
don't
think
we
have
to
be
too
precious
about
it
like
they
can
be
overlap
as
long
as
we
keep
talking
to
each
other,
and
this
we're
just
not
wasting
time
doing
having
different
types
of
discussions.
But
it's
fine
to
have
the
same
discussions
in
different
places.
As
long
as
we
we
keep
syncing
up
every
now
and
then
and
the.
J
C
D
Okay,
then
there
is
no
action
here
like
once.
The
proposal
for
the
music
ends
up
on
top
repo.
Then
please
invite
everyone
from
this
cig
as
well.
So
those
people
can
comment
on
the
proposal
like
non-binding
comments
or
walls
or
whatever,
when
it
goes
to
main
list
and
so
on,
and
then
we
keep
those
comments
on
github
and
mail
list
as
historical
purpose,
so
others
joining
the
six
could
get
the
idea
how
this
thing
happened
and
what
is
the
history
behind
it.
D
So
before
I
ask
james
to
talk
about
jenkins
x,
I
can
perhaps
talk
about
what
updates
I
made
to
the
high
cambridge
document
so,
and
I
did
this
this
morning,
so
I
don't
expect
any
many
of
you
to
see
this,
but
I've
seen
this
yet
so
some
basic
introduction
paragraphs
there
like
what
are
we
talking
under
this
standardized
metadata
thing
and
scope?
D
Question
is
here
because,
like
there
are
at
least
two
questions
like
one
question
is
like
what
do
we
mean
when
we
say
metadata,
because
if
you
look
at
different
tools
and
technologies,
some
consider
only
the
commits
as
the
thing
to
focus
on
when
it
comes
to
metadata.
But
if
you
look
at
end-to-end
pipelines,
the
things
I
listed
here
could
be
considered
as
metadata
like
commits,
relate
metadata,
artifact,
metadata,
test,
metadata
list,
metadata
and
etc,
etc.
D
And
finally,
some
of
the
questions
here,
like
types
of
metadata,
the
means
to
produce
consume
transport
metadata,
which
touches
the
ions
work
stream.
How
that
metadata
is
used,
and
perhaps
one
of
the
more
important
things
analysis
of
extinct
force
in
order
to
not
reinvent
the
wheel
and
then
the
list
of
exiting
efforts.
D
K
Thank
you,
I'm
hoping
that
the
brief
example
I
I
added
is
fairly
self-explanatory,
but
we
we
did
this
release
custom
resource.
I
think
it
was
like
two
and
a
half
years
ago
and
we
kind
of
figured
everything's
a
custom
resource
and
kubernetes,
so
we
went
straight
for
the
custom
resource
definition.
K
I
think,
as
we
start
exploring
this
idea,
we
probably
don't
want
to
start
there.
We
should
maybe
just
start
with
files.
You
know
like
a
file
format
and
a
schema
to
keep
it
really
nice
and
simple
whether
this
metadata
gets
materialized
as
a
custom
resource
or
not,
is
a
kind
of
a
secondary
concern
really
on
the
jks
project.
We've
been
kind
of
pretending,
everything's
a
custom
resource,
whether
it
is
or
is
it
isn't.
K
In
other
words,
we've
been
using
kubernetes
style,
versioning
and
schemas
and
structure
for
any
file,
so
that,
if
you
know
it's
like
there's
an
api
version
of
a
kind
and
so
forth,
so
it
gives
us
a
way
of
versioning
everything
and
everything
looks
like
a
custom
result,
but
whether
it
actually
gets
installed
into
a
kubernetes
cluster
as
a
custom
resource
doesn't
really
matter.
It's
kind
of
irrelevant,
but
anyways
we
went
with
the
custom
resource,
so
it
looks
and
feels
like
a
custom
resource.
So
kubernetes
people
will
look
at
this
and
go
oh.
K
I
thought
what
would
be
interesting
at
some
point
is
getting
as
many
examples
as
we
can
find
so
get
some
ebay
examples,
some
orteria,
some
whatever
I
had
a
little
look
at
tecton
chains.
K
Let's
just
basically
try
and
find
any
examples
we
can
get
and
then
look
at
similar
things.
You
know,
for
example,
list
the
git
coming
versus
artifacts
versus
issues
versus
logs
and
whatnot,
and
just
look
at
scenarios.
I'm
guessing
most
of
this
stuff
is
going
to
be
similar.
There's
only
so
many
ways
you
can
describe
a
git
commit
or
commit
sure
or
an
artifact
or
a
checksum
or
whatever.
K
So
I'm
kind
of
hoping.
We
can
at
least
find
some
similar
things
and
and
start
somewhere
with
something
really
obvious
and
similar
like.
Let's
have
a
canonical
blob
of
yaml
for
what's
the
git
commit
show,
what's
the
git
repository
url
and
that
kind
of
stuff,
as
we
delve
into
more
and
more
detail,
there's
probably
going
to
be
some
variations
like
describing
tests
is
an
interesting
one,
because
there's
not
much
of
a
standard
for
that.
Yet
there's
lots
of
people
use
junit
xml
everywhere,
which
is
an
option.
K
There's
a
thing
called
to
tap
test
any
protocol.
I
only
found
out
the
other
day
because
I
was
doing
a
little
linter
step
in
kubernetes
and
I
I
stumbled
on
it.
Let
me
post
a
link
in
the
chat
there's
this
thing
that
I
stumbled
on
the
other
day.
I've
never
heard
of
it
before
in
the
in
a
couple
of
decades
in
it,
but
anyways
there's
a
thing
called
tap
that
describes
test
results.
K
It's
like
a
wiki
notation
for
test
results,
which
another
reason
I
found
this
was
the
the
super
limiter
that
github
uses
in
its
data
actions
uses
tap
to
describe
all
the
lint
errors
you
get
anyways,
but
I'm
I'm
going
for
the
attention,
but
I
just
figured:
let's
collect
all
the
results
we
can
find
or
all
the
metadata
we
can
find
put
in
the
big
document.
We
all
knew
a
little
bit
and
then
we
could
just
try
a
straw
man
brainstorm
idea
of
what
we
could
standardize
on.
K
Maybe
eventually,
if
this
gets
far
enough
ahead,
we
could
have
an
official
cdf
resource,
custom
resource
or
whatever
it
is
whatever
we
call
it
a
metadata
custom
resource
or
something
could
be
a
thing.
Maybe
it
could
just
be
some
schema
documents.
That
would
be
good
too.
I
mean
we
could
make
this
consumable
in
lots
of
different
ways.
It
shouldn't
really
matter
what
technology
you're,
using
or
using
crds
or
files
or
urls
and
message
buses
or
cloud
events
or
something,
let's
just
start
with
schemers
really
like.
K
Another
lesson
I've
found
from
jiggy's
x
in
kubernetes
is,
if
in
doubt,
have
different
documents.
So
if
we
can't
agree
on
everything,
let's
have
one
document
for
test
results.
One
document
for
artifacts
one
document
for
git,
something
because
it
might
be
we
reach
agreement
on
git
commits
and
shares
quicker
than
we
agree
on
test
results
versus
issues
is
another
one.
How
do
we
describe
issues
that
are
resolved
in
jira
or
github
or
servicenow
or
whatever?
K
That
could
take
a
long
time
because
they're
all
totally
different,
those
things
get
commits
are
pretty
standard
I
mean
get
is
get
it
doesn't
change
that
much
but
going
through
all
of
these
different
things,
test
results
and
issues
those
could
get
take
as
a
while.
So
maybe
we
should
split
the
metadata
up
into
chunks
and
work
on
the
chunk
in
parallel.
K
So
then,
and
then
each
one
could
have
its
own
release
skins
right.
So
we
could
have
git
metadata,
artifact
metadata
issue,
metadata
test
result
metadata
and
we
could
maybe
treat
them
as
separate
schemas
for
a
while
and
give
them
their
own
life
or
whatever
anyways,
I'm
rambling
a
bit.
But
this
sounds
really
interesting.
Let's
do
it
and
let's
work
together
and
get
as
much
metadata
as
we
can
and
the
examples
we
can
see
how
we.
K
D
D
No,
it's
it's
like
it's
great
like
because
when
I
was
putting
those
things
there,
I
was
like
overwhelmed
with
number
of
things
like
this
is
not
completely
it's
definitely
so
you
can
extend
the
list
and,
as
you
say,
if
we
try
to
you
know
tackle
all
these
things,
we
will
not
be
able
to
solve
anything.
Maybe
we
just
take
commit,
for
example,
like
again
repeating
what
you
just
said,
commit
is
like
commit,
like,
should
be
simple
and
quick
to
agree
on
something
famous
last
words.
K
Just
as
a
random
brain
fart,
how
about
we
spun
up
a
new
cdf,
open
source
project
on
github,
and
we
just
started
with
a
bunch
of
types
or
strokes
or
whatever
for
the
lower
level.
Things
like
git
commits
release,
meta
artifacts
test
results
whatever,
and
we
just
try
some
things
out
and
we
could
automatically
generate
like
json,
schemas
and
html
documentation
for
what
the
structures
look
like
and
we
could
just
play
around
for
a
little
while
we
don't
have
to
decide
anything.
K
L
Thing
about
doing
that
as
well
is
because
you
said
there's
so
many
tools
out
there
for
generating
you
know:
reverse
generating
schemas
or
docs
as
well
and
having
nice
clear.
So
it's
kind
of
starting
from
that
point.
It's
kind
of
a
nice
way
to
then
keep
iterating
on
it,
and
just
you
know
it's
and
then
you
can
see
the
differences
and
people
can
comment
and
that's
how
things
get
done.
So
it
makes
sense
to
me.
B
I
I
think
the
ortelius
team
would
be
interested
in
participating
in
that
as
well.
Considering
we
already
are
storing
a
lot
of
this
metadata
where
right
now
that
the
team's
looking
at
what
additional
metadata
we
should
be
tracking.
L
And
what
would
be
really
interesting
is,
as
a
result
of
that
I
mean
maybe
getting
a
bit
far
ahead,
but
I'll
be
yeah.
The
end
goal
is
interoperability
right
so
having
some
interoperability
with
otilius
and
jenkins
x
and
then,
of
course,
anything
anybody
else
as
well,
and
that's
really
quite
exciting,
but
getting
a
bit
ahead
of
myself.
B
Yeah,
because
I
mean
what
artelia's
is
goal
is-
is
to
be
that
central
cmdb
for
lack
of
better
more
sexy
word
for
every
for
any
for
any
microservice,
but
actually
can
be
done
for
any
type
of
component,
and
we
have
really
have
been
working
on
what
what
metadata
is
going
to
be
important?
I
even
down
to,
should
we
be
tracking
the
metadata
about,
let's
say
a
spinnaker
or
an
argo,
pushes
out
new
information,
new
key
value,
key
value,
pairs
or
information
about
the
cluster
itself.
B
Should
we
be
tracking
that
so
there's
a
lot
of
metadata
to
manage
it's
a
and
where
do
we
draw
the
line?
I
think
that's
where
we're
where
our
head
is,
is
where
do
where
do
we
stop.
F
And
just
to
give
a
a
starting
point
for,
like
you
said
you
know
what
is
a
shaw.
You
know
those
things.
One
of
the
things
we
should
look
at
is
the
spdx
cncf
project
and
I
threw
the
links
under
existing
efforts
because
they
lay
out
in
their
specification
a
lot
of
those.
F
F
So
you
know
what
is
a
package
and
this
gets
down
to
like
a
node.js
package
or
python
module.
You
know
at
that
level,
but
when
we
look
at
a
doing
this
for
a
deployment,
what
we
should
be
really
looking
at
is
rolling
up
this
information
all
the
way
up
to
a
release
at
that
level,
so
it
gets
into
what
is
a
version
number?
What
is
a
file?
You
know
those
types
of
things.
F
A
Yeah,
I
would
also
like
to
throw
in
the
the
example
that
that
we
use
with
the
nerdson
where
we
we
have
these
eiffel
events,
which
we
and
there
we
talk
about
events,
but
whatever
we.
We
still
include
metadata
in
those
events
and
and
we
handle
concepts
like
activities
and
artifacts
and
test
results
and
those
things
in
there
as
well.
So
I
will
add
a
link
to
to
the
specification
and
the
vocabulary
that
is
used
in
eiffel
as
an
example.
That
could
be
thought
of
when
looking
into
these
questions
further.
F
And
I
don't
recall
who
made
the
comment,
but
I
think
the
idea
that
we're
we
start
at
a
a
small
subset
and
then
we
just
keep
on
extending
it
to
cover
more,
is
going
to
be
the
easiest
approach.
So
if
we,
if
we
can
all
agree
what
a
git
sha
is,
you
know
and
start
there
and
then
you
know
extend
out
to
something.
F
D
Okay,
I
think
we
are
heading
somewhere
like
okay.
I
just
to
you
know,
increase
the
ambition
they
were
like
shock
commit.
We
discussed
like
maybe
in
part
that
since
james,
you
proposed
that
maybe
artifact
is
kind
of
simple
yeah
for
container,
which,
for
example,
how
many
things
you
can
talk
about
when
it
comes
to
container,
which,
like
yeah,
probably
a
lot,
but
you
know
so.
My
question
is
like:
should
we
have
the
art
imperative
shy
as
well?
K
I
guess
there's
also
lots
of
metadata
already
there
right,
there's
well,
there's
gonna
be
there's
gonna,
be
commonality.
F
Between
a
file
like
a
jar
file
artifact
and
a
container
artifact,
there's
gonna
be
some
commonality,
so
there's
gonna
be
a
parent
that
they're
gonna
branch
off
into
their
more
unique
characteristics.
But
I
think
if
we
don't
start
at
the
top,
I
think
we'll
we'll
miss
the
relationships
you
know
just
starting
at
the
top
could
be
name
and
version
number,
and
that
could
be
the
the
top
level
part
of
of
what
we're
going
to
call
an
artifact
or
whatever
you
know
that's
going
to
be.
F
J
D
D
Okay,
then
git
commits
that
is,
like
obvious,
everyone
seems
to
agree
that
we
can
start
with
that.
An
artifact
could
be.
We
can
start
with
terminology,
at
least
without
dealing
with
the
details
and
just
name
and
version
like
steve
mentioned
so
and
the
other
thing
james,
you
proposed
to
have
a
repo,
a
separate
repo,
which
makes
a
lot
of
sense.
We
can
put
examples
in
a
folder
where
everyone
can
see
them
easily
and
then
we
can.
We
can
have
separate
files
on
commit
artifact
whatever.
D
So
I
want
to
ask
tracy
like
do.
We
need
to
ask
talk
to
for
this,
or
can
we
just
get
a
repo
created
for
this
work?.
E
Yeah,
I
can
help
create
that
just
let
me
know
what
you
want
to
call
it,
and
just
in
general,
with
the
toc
and
the
cdf
repos
we're
just
organizing
everything
into
github
teams.
So
we'll
have
a
let's
say:
interoperability,
team
and
I'll.
Add
in
everyone
on
this
call
and
then
I'll
give
them
access
to
that
repo
and
yeah.
They
can
all
go
crazy.
L
It
would
be
fun,
I'm
not
sure
I
agree
with
what
I'm
about
to
say
now,
but
it's
all
we
I'm
sure
there'll
be
some
some,
maybe
alarmed
people
once
they
see
standardizing
ci.
E
L
F
So
spdx
is
software
package
data
exchange
identifier.
So
that's
what
it
stands
for
so
software
package
data
exchange.
So
the
concept
behind
it
is,
you
can
go
in
and
ask
a
package
for
its.
Basically,
it's
data
exchange
payload
and
it
returns
a
json
of
what
it
is
made
up
of
all
that
metadata.
F
D
So
I
want
to
do
like
I
want
to
assign
stuff
to
others
like
who
wants
to.
You
know
drive
the
this
commit
discussion
when
we
get
repo
who
wants
to
start.
E
D
Anyone
on
our
truck
or
should
we
have
an
artifact
as
well
like
dave,
since
you
mentioned
rosetta
stone,
you
want
to
start
a
metadata
artifact
file
as
well
with
what
you
just
said
like
what
do
we
call
what
we
mean
when
we
say
artifact.
D
D
I
think
this
these
two
a
good
start
and
we
have
about
one
and
a
half
months
or
one
month
until
our
next
meeting.
So
hopefully
we
can
add
some
information
there
and
I
will
continue
asking
christie
to
bring
tecton
example
as
well
and
tracy
steve
if
you
can
bring
or
tell
us
example
to
that
repo
when
we
have
the
repo.
That
would
be
great.
So
we
can
see
what
are
you
doing?
What
techtune
is
doing
and
emil?
You
all
also
mentioned
eiffel
and
we
can
move
the
jenkins
sex
example,
but
it
is
released.
D
D
Great,
so
I
suppose
we
are
done
with
this
topic.
Anyone
wants
to
bring
up
another
topic
for
last
five
minutes.
E
I'll
just
mention
no
there's
a
end
of
year,
close
out
2020
cdf
virtual
party
next
tuesday.
I
think
it's
in
the
cdf
calendar,
but
yeah
I'd
just
like
to
invite
everybody.
If
you
want
to
just
come
along
and
say
goodbye
to
2020
and
to
celebrate
everything,
we've
done
this
year.
D
Okay
and
what
was
date
tracy,
I
can
capture
that.
B
B
It's
the
15th
at
noon,
east
coast
time.
Thank
you,
tracy,.
D
Okay,
so
do
we
get
beer
and
the
stuff
as
well?
What
or
tell
us
did
this
beer
and
whatever
donuts.
E
B
D
Okay,
I
think
before
we
end,
I
am
really
happy
that
we
have
this
group
or
team
of
people
who
are
really
working
on
a
tricky
subject,
and
I
think
we
had
a
lot
of
achievements
this
year
like
even
though
we
haven't
created
any
standards
we
identified.
Fifth
trends
at
this,
like
events
is
a
trend
and
we
start
metadata
thanks
to
james
and
we
have
white
paper
which
will
hopefully
be
published
soon.
D
We
contribute
some
blog
posts,
we
have
rosetta
stone,
so
we
we
have
done
a
lot
of
things
this
year,
and
hopefully
this
will
be
a
good
foundation
to
continue
our
work
we
started
and
who
knows
in
2021,
we
may
have
cd
the
x
and
have
some
specifications
to
continue
pushing
this
area
further.
So
thanks
everyone.
Thank
you
all
and
talk
to
you
in
a
month
and
merry
christmas
and
happy
new
year
in
advance.