►
From YouTube: CDF - SIG Interoperability Meeting 2020-10-29
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).
A
B
C
D
A
We
are
waiting
others
to
join.
Maybe
you
can
record
your
attendance
on
the
meeting
minutes
we
have
so
we
know
on
the
hack,
md
right,
yeah
yeah.
Yes,
I
will
do
and
I
put
the
link
to
chat
and
since
the
daylight
saving
times
ended
in
europe
things
a
bit
tricky
this
week.
So
we
will
wait.
Two
three
more
minutes
for
people
to
join
yeah.
A
A
A
No,
we
are
one
of
the
first
ones.
Always
this
week
between
the
daylight
saving
time
starts
or
ends.
It's
always
tricky
because,
like
europe
and
u.s,
they
are
not
synced
when
they
end
or
start
or
end
the
daylight
saving
time.
So
it
is
we'll
see
we
hope
we
get
more
people
so
yeah.
While
we
wait,
you
can
put
your
name
on
the
hackmd
document,
so
we
know
who
is
here.
B
F
A
A
So
as
usual,
we
start
with
action
item
review,
followed
by
reminder
on
data
save
time
again,
so
we
don't
miss
people
for
the
next
meeting,
because
us
is
ending
daylight
saving
time
this
weekend
and
a
quick
update
regarding
this
cicd
industry
workshop,
which
took
place
last
weekend
as
part
of
ieee
software
testing
conference.
A
Standardized
metadata
is
the
major
topic
which
we
started
talking
about
during
the
last
meeting,
and
we
can
spend
a
few
minutes
on
the
white
paper
because
it
is
better.
We
focus
on
metadata
this
meeting,
so
we
get
start
with
that
and
we
can
follow
up
the
white
paper
offline
as
well
and
then
for
the
second
half
of
the
meeting.
A
We
will
have
demo
from
james
rollins
and
james
stretcher
on
jenkins,
x
and
techno
integration,
and
if
you
have
any
topics
you
want
to
raise,
you
can
add
them
to
the
list
and
we
see
if
you
have
time
for
those.
A
So
the
first
action
item
is
on
your
tracy
to
come
up
with
proposed
time
flam
for
intro
white
paper.
Do
you
have
any
chance
to
think
about
this.
F
Yes,
so
what
we
did
is
just
have
a
sync
with
the
creative
team
and
they
just
gave
us
some
guidelines
as
to
what
they
need
to
kind
of
turn
it
into
a
cdf
templated
white
paper,
and
it
seems
pretty
forward
straightforward
for
this
one,
because
I
think
we're
not
planning
to
have
any
specific
infographics
or
maybe
a
couple
of
tables,
but
it's
it's
mostly
just
text.
F
So
with
that
in
mind,
I
think
they're
pretty
open.
I
would
suggest
we
aim
to
get
this
done.
Definitely
before
the
end
of
the
year
and
ideally
away
from
december.
So
I
think
we're
cdf
is
doing
annual
reports
and
things
like
that,
so
we
have
some
time
used
up
there
from
the
creative
team.
So
what
I'd
suggest
is
by
the
end
of
november,
we're
in
a
state
that
we
can
we'll
take
that
to
the
creative
team?
A
A
So
the
next
topic
is
daylight,
saving
time
as
I've
been
talking
about
this
last
five
minutes.
So,
as
you
know,
europe
already
ended
daylight
saving
time
last
weekend,
so
for
the
people
joining
from
europe,
the
meeting
happens
one
hour
earlier
and
the
us
and
canada,
perhaps
the
daylight,
saving
time
ends
this
weekend.
A
So
yet
another
change
for
the
people
coming
from
north
america.
So
like
how
it
happened
to
europe.
You
will
need
to
join
the
meeting
one
hour
earlier
than
what
it
is
now
because
we
agreed
to
stick
to
utc
3pm
at
the
very
first
meeting.
So
please
ensure
you
join
at
the
right
time,
so
you
don't
miss
the
meeting
and
I
use
this
time
is
website
which
kind
of
shows
three
p.m.
Youth
is
on
different
time
zones,
so
it
is
8
00
a.m.
F
A
F
A
Okay,
so
since
this
goes
one
hour
earlier,
then
there
will
be
one
hour
between
maybe
if
you
are
following
specific
time
for
end
user.
So
it's
all
this
time.
Zone
thing
is
like
confusing
me
twice
a
year,
but
anyway
you
have
the
link
there
and
the
reminder
will
be
in
the
meetings
and
agenda
as
well
next
for
next
time.
So
please
keep
an
eye
on
those
mails
and
the
next
topic.
This
cicd
industry
workshop
happened
over
the
weekend
and
let
me
open
the
link
and
I
found
out
this
workshop
thanks
to
email.
A
So,
in
the
end,
it
happened,
and
it
was
actually
a
great
luck
that
we
found
those
people,
because
there
are
many
people
who
are
talking
about
ci
cd
testing
from
academy
and
industry
perspective,
and
I
simply
presented
the
interval
topic
and
talked
about
continues
their
foundation
and
there
was
a
great
response
to
conduct
their
foundation,
especially
because
some
of
those
people
weren't
so
really
aware
of
the
existence
of
contingency
foundation.
Unfortunately,
but
in
dance
we
found
each
other
and
I
got
them
in
touch
with
tracy,
so
they
tracy
will
have
a
meeting
with
them.
A
I
suppose,
next
week
to
you
know
somehow
socialize
collaboration
idea
and
so
on,
and
in
addition
to
that,
they
asked
few
questions
or
raised
fifth
ideas.
One
of
the
ideas
they
they
raised
was
the
availability
of
maturity
model
for
companies
to
evaluate
themselves
from
continuing
their
perspective,
and
this
could
be
something.
Cdf
could
perhaps
take
a
look
at.
So
I'm
just
bringing
that
here
and
really
see
any
comments
on
that.
F
Sorry,
you
repeat
the
question
I
was
trying
to
send
some
links
to.
F
Okay,
yes,
so
a
couple
of
thoughts
on
that,
so
we're
about
to
spin
up
a
best
practices,
working
group
and
that's
on
my
backlog.
So
there's
a
charter
that
the
strategy
committee
and
the
board
level
is
pretty
happy
with
michael
galloway
from
netflix
is,
is
kind
of
captured
this
vision
and
the
summary
is,
you
know
we
want
to
base
things
on
the
accelerate
book
and
we
want
to
work
out
how
people
can
get
better
and
we
give
them
that
way
of
doing
it.
F
I
don't
want
to
call
anything
maturity
model
because
it's
got
all
sorts
of
bad
connotations,
but
in
this
general
idea
that
you
figure
out
where
you
are
on
different
things,
and
then
you
work
out
what
the
next
stage
is
to
improve
and
whatever
we
call
that
perhaps
not
maturity
model,
but
something
that
is
easy
to
understand.
F
A
Okay
thanks.
The
other
question
they
raised
was
like
what
we
have
been
talking
last
few
weeks
as
part
of
our
white
paper
and
as
part
of
our
meetings
like
they
don't
really,
you
know,
have
a
common
understanding
or
shared
understanding
when
it
comes
to
ci
continues.
Integration
contains
the
recontains
deployment
which
this
work
is
already
happening,
so
we
are
kind
of
in
line
with
what
other
people
may
be
thinking,
so
that
is
already
happening.
A
A
They
asked
like,
if
there's
any
standards
in
place
or
who
does
this
type
of
stuff,
and
I
again
highlighted
cdf
as
a
place
to
talk
about
these
things.
I'm
not
saying
like
cdf
is
a
standards
developing
organization,
but
they
could
join
and
take
part
in
the
effort
here.
What
we
get
in
that
remains
to
be
seen,
and
the
other
point
was
about
how
to
get
some
collaboration
going
on
between
academia,
industry
and
communities,
and
my
response
was
same,
come
and
join
cdf.
F
Yeah,
have
you
developed
them
as
a
general
point
for
academia?
F
You
know
just
invite
them
to
join
any
of
our
working
groups
and
if
they
want
kind
of
to
get
like
a
badge
of
honor
for
joining,
they
can
be
associate
members
of
cdf
and
all
they
have
to
do
is
say
why
they
want
to
join.
We
take
that
to
the
board.
The
board
gives
a
thumbs
up,
and
then
we
put
them
on
the
website
to
say
hey
we're
doing
that.
We
just
did
that
with
our
first
university,
which
is
a
university
in
china.
F
Actually,
so,
if
that's
of
interest
to
folks,
let
them
know
they
can
do
that
and
just
drop
me
an
email
with
a
contact
point
to
get
that
done.
H
F
H
Is
steve
when
you
talk
to
these
folks
and
at
the
universities,
one
of
the
things
that
we're
looking
for
on
the
artelia
side
is
open
source
projects
that
are
running
under
kubernetes
for
our
marketplace.
So
if
you
can
poke
around
on
that
topic,
that
would
be
great
sure.
A
And
these
people,
or
these
like
yeah,
these
people
seem
to
have
been
running
this
software
engineering
and
programming
languages
journal
club,
maybe
christie.
You
may
have
heard
this
because
it
is
driven
like
one
of
the
guys
who
are
organizing.
This
is
from
google.
I
think
tim
henderson
and
I
will
put
the
link
to
the
meeting
minutes.
You
see
there
are
lots
of
papers
here
and
it
is
like
public
papers
which
you
can
go
and
read
and
comment.
It
seems
they
are.
A
They
have
been
doing
this
for
quite
a
while,
and
some
of
those
papers
are
pretty
relevant
to
what
we
are
talking
about
in
the
sikh
and
we
didn't
come
with
their
foundation.
So
it
would
be
good
to
see
what
they
are
talking
about
and
they
have
a
google
group
as
well
where
they
are
like
announcing,
which
paper
is
available
on
that
google
site
and
collecting
feedback.
A
I
A
A
B
Hello,
I'm
ready
okay
I'll
share.
My
screen.
Stop
oh
yeah.
Okay,
I've
got
like
a
call.
I've
got
a
couple
of
slides
just
a
few,
and
then
I've
got
a
little
demo.
The
slides
are
really
just
for
a
bit
of
context.
I'll
put
the
slides
in
the
chat
as
well
just
in
case
there's
any
links
on
there.
People
want
to
noodle.
A
James
sorry,
we
are
on
actually
this
metadata
topic.
A
B
Okay,
I
don't
have
a
huge
amount
to
add
it's
only.
I
guess
I
need
to
write
up
a
proposal
and
describe
it
in
more
detail,
but
very
this
conversation.
The
last
couple
years
have
happened
between,
for
example,
chicken,
sex
people
and
spinach
people
in
the
drinking
community.
B
We
all
seem
to
be
doing
releases
and
we've
never
really
defined
the
common
metadata
from
what
our
release
looks.
Like
looks
like,
so
we
should
probably
just
start
a
spec
and
then
try
come
up
with
some
common
metadata
that
we
can
all
agree
on,
and
then
we
can
start
integrating
it
into.
You
know
protect
on
jenkins
jenkins,
that's
pretty
much.
What's
all
I
have.
E
When
you
talk
about
metadata
and
and
giving
it
to
other
services,
is
there
an
idea
of
how
to
transfer
this
metadata
is
just
how
the
metadata
is
structured?
That's
a
good
question.
So.
B
I
was
focused
initially
on
just
defining
the
metadata
first,
particularly
with
kind
of
after
using
kubernetes
for
a
few
years.
B
B
It
doesn't
have
to
be
a
cid.
It
could
be
a
custom
resource
in
cuba.
Yes,
it
could
just
be
a
blob
of
yammer.
It
could
be
a
message
in
a
message
book.
It
could
be
on
kafka,
it
could
be,
it
could
be
in
the
api,
seven
kubernetes.
I
could
just
be
on
the
file
system
or
something
but
start
with
just
the
data
first
and
then,
once
we
have
an
agreed
data
format,
we
could
make
a
rest
api.
Maybe
we
could
store
them
on
the
bucket.
We
could
you
know
whatever
in
the
jenkins
x
project.
B
We
went
for
the
crd
boot,
which
is
useful
but
then
actually
turned
out
to
cause
some
problems
because
a
custom
resource
into
your
like
a
kubernetes
application.
You
can
install
it
and
cluster
them.
B
It
doesn't
have
that
storm.
There's
now
a
fix
for
that
in
helm.
Where
you
can
say.
Oh,
they
install
this
resource.
If
you
have
this
custom
resource
in
your
cluster,
so
you
can
break
crds
into
health
charts
and
they
don't
install
if
the
crd
isn't
installed,
but
yeah
it
doesn't
need
to
be
a
custom
resource.
It
could
just
be
a
filing
git
somewhere
with
an
annotation
that
points
to
it.
It
could
be
just
a
url
so
somewhere
on
the
website.
It
could
be
a
message
bus.
B
I
think
all
of
those
are
useful,
but
I
figured
let's
just
start
something
with
like
just
a
spec
like
a
schema,
some
examples
that
we
can
start
make.
I
think
the
first
thing
is
to
start
generating
this
data
as
part
of
release,
pipelines
and
whatnot,
then
eventually,
tooling,
might
want
to
discover
that
metadata.
B
You
know
if
you've
got
a
promotion
tool
you
might
want
to
look
at
the
metadata
to
say
you
know:
do
you
really
want
to
release
1.2.3
it's
going
to
backwards,
a
good
portable
change
or
whatever
we
can
start
breaking
the
metadata
in
so
people
understand
what's
being
fixed,
what's
not
fixed
what
issues
there
are
what
you
know
we
can
release
notes
and
github
change
logs
and
whatnot,
so
I
thought,
let's
start
really
simple
and
small:
let's
define
some
metadata
first
see
how
much
is
common
between,
say,
spinnaker,
flagger
and
jenkins
x,
or
something
three
random
projects
and
then
just
see
how
many
other
people
are
doing
something
similar
and
does
everybody
else
want
to
join
in
and
has
got
different
ways
of
thinking
about
it?
B
There's
overlaps,
helm
kind
of
has
some
of
this
data.
In
the
challenger
I
mean
not,
everybody
uses
helm,
but
we
shouldn't
be
aligned
with
that.
There's
also
the
app
standard,
the
app
spec
as
part
of
kubernetes
that
we
should
kind
of
align
with,
but
this
was
not
intended
to
be
technological.
It
shouldn't
matter
if
using
helm
or
kept
or
cube,
ctl
or
spinnaker
or
jenkins,
but
we
should
be
able
to
come
up
with
a
lot
of
common
stuff.
B
Like
you
know,
there's
only
so
many
ways
of
saying
where
the
git
url
is
and
what
the
git
show
is
and
where's
the
url
to
the
pipeline
log.
If
there
was
one-
and
you
know
those
kind
of
things
so
which
we
should
be
able
to
cope
with
something
simple-ish
early,
I
would
have
hoped
and
then
just
see
what
happens
really
see.
Who
who
joins
in
and
uses
it.
G
Good
morning,
james,
I'm
just
struggling
a
little
bit
about
what
your
problem
statement
is.
Are
you
just
please
correct
me?
Are
you
advocating
for
a
an
application,
metadata
standard
or
a
release,
metadata
standard,
something
that's
closer
to
a
release,
metadata
standard.
B
A
bit
of
both,
I
guess
the
use
case,
is
yeah
bit
of
buff,
but
the
basic
idea
is:
what
can
we
bare
cases
of
applications,
so
the
consumers
who
are
doing
progressive
delivery
or
rolling
upgrades
or
using
some
type
kind
of
continuous
delivery
tool
can
use
that
metadata
to
understand
what
will
happen
if
they
go
forward
so
there's
any
kind
of
human
approval
or
any
kind
of
manual
process
involved
with
people,
it's
useful
to
give
people
information
to
help
to
choose.
B
For
example,
if
you
go
from
1.0
to
2.0
and
there's
a
million
backwards
breaking
changes,
you
might
want
to
not
want
to
click
the
approve
button
in
spinnaker
at
5pm
on
a
friday,
because
you've
said
your
upgrade
and
there's
backwards
on
compatibility
issues
and
there's
a
big
warning
in
the
release.
Notes
that
only
do
this
on
the
tuesday
or
whatever
right.
So
it's
more.
How
can
we
bake
in
that
metadata?
So,
if
there's
any
humans
involved
in
the
chain,
they
they
can
easily
find
information.
G
Let
me
let
me
give
you
so
what
what's
what's
been
one
of
the
things
that
I
like
about?
What
ebay
has
done?
G
They
did
this
years
ago
when
it
came
to
controlling
of
what
actually
gets
deployed
and
what
what
gets
released
is
that
they
created
the
concept
of
a
manifest
at
ebay.
You
don't
ever
we
don't
speak
of
deploying
software.
We
do
we
speak
of
deploying
manifests,
it's
the
manifest
that
has
in
it
everything
about
what's
being
deployed,
including
and
now
now
over
the
last
year
and
a
half
or
so
we're
also
including
in
them
we're
linking
with
the
manifest
things
like
all
the
information
about
the
quality
gates.
G
What
in
fact,
I
just
I
designed
this
about
a
about
a
year
ago,
and
it
were
fairly
good
way
through
of
implementing
it,
and
we,
I
came
up
with
a
badge
system,
meaning
the
quality
gates
has
the
quality
gates
itself
is
a
is
an
object
that
gets
associated
with
the
manifest
that
has
all
the
release
information
in
it.
That
includes
a
series
of
badges.
G
You
are
given
this
manifest
is
awarded
badges
such
as
unit
tests
pass
integrations
tests
pass,
our
security
scan
passes
our
dynamic
scans
pass.
I
mean,
there's
a
number
of
different
badges
that
gets
awarded
to
this.
To
this
manifest,
these
badges
are
examined
at
the
time
admission
controllers
are
about
to
allow
this
thing
in
to
get
deployed.
G
So
all
the
quality
gate
stuff
gets
wrapped
up
in
this
color
gates
object
which
is
associated
with
these
badges,
which
then
gets
all
associated
with
this
manifest.
H
So
that's
well.
This
is
steve
from
the
playhub.
H
We
have
the
ortelius
project
that
we're
looking
to
get
into
the
cdf,
and
one
of
the
things
that
we
are
doing
is
very
something
very
similar
where
we
have,
like
you
said
a
manifest
that
is
defining
what
a
release
looks
like
and
that
metadata
is
stored
in
a
database
and
what
ends
up
happening
is
you
have
a
manifest
per
version
of
your
application
and
when
you're
dealing
with
the
microservices
world,
you
end
up
with
many
many
versions
of
an
application
they
all
may
not
make
it
to
production,
but
when
they're
coming
out
of
the
ci
process
and
they're
being
independently
deployable,
we
still
have
to
associate
them
up
into
a
version
of
an
application.
H
So
that's
stuff
that
we
are
tracking
at
a
manifest
level
like
you're,
saying
james,
is
a
pointer
we're
using
pointers
to
the
data
instead
of
storing
the
data
itself.
So
you
know,
where
is
the
git
repo?
Where
is
the
the
docker
repo?
H
I
There
is,
I
know
that,
there's
a
there's,
a
tecton
project
called
chains
that
I
think
is
sort
of
related
to
what
you're
talking
about
and
there's
another
there's
another
tool.
That
is
similar
that
I
also
can't
remember
the
name
of
that
might
be
the
one
that
you're
thinking
of
it's
gone.
I
feel
like
it
was
something
yeah.
It
was
not
like
a
well-known
word.
It
was
like
one
of
those
like
greek
words
or
something.
H
B
H
And
then
one
of
the
things
that
we're
looking
at
doing
is
it
gets
really
complex,
really
quick,
but
if
you
want
to
have,
let's
say
you
have:
a
microservice
container
has
gone
out
to
the
to
the
qa
cluster,
who
is
the
owner
of
that
service
where's,
the
the
stackdriver
logs?
H
What's
the
pagerduty
link,
you
know
those
types
of
metadata
are
also
interesting,
but
when
you
take
that
same
service
and
it
could
be
consumed
by
you
know
if
it's
an
open
source
service,
it's
being
consumed
by
5
000
companies,
what
does
it
mean?
Then?
You
know
that
type
of
thing
when
you
try
to
to
look
backwards
at
it,
but
that's
some
of
the
other
information
I've
seen
people
want
is:
is
that
type
of
metadata
as
well?
H
G
I
mean
look
once
you
have
once
you
have
an
object
that
and
encapsulates
the
absolute
basic
data
about
what
is
being
released,
which
is
what
ebay
calls
on
man
and
manifest
a
release
manifest
once
you
have
that,
then
the
possibilities
open
up
to
connect
any
number
of
things
with
it,
meaning
you
don't?
G
You
don't
have
to
jam
it
into
the
release
manifest
you
can
just
associate
it
with
the
release
manifest
and
lean,
and
leave
a
leave,
a
mechanism
of
sort
of
a
customized
data
associated
with
this
thing
open
for
others
to
add
to
so
that
you
don't
have
you
don't
have
to
think
about
everything
right
now,
you
you
come
up
with
the
absolute
basics
of
what
everybody
agrees.
What
a
release
should
include.
G
Okay,
there
are
a
few
this
body
here
that
we
have
here
all
the
people
we
have
here
on
this
on
this
forum.
We
can
decide
what
that
is,
and
then
say
this
is
an
extension
mechanism
and
you
go
forward
from
there.
This
is
exactly
how
the
the
manifest
object.
The
release,
manifest
object,
got
done
at
ebay.
H
And
is
it
manifest
object
immutable
then.
G
Once
the
manifest
is
created
the
the
object
itself,
it
is
immutable
you
can,
you
have
to
create
a
new
one.
G
That
that
is
the
golden
rule.
You
don't
you
do
not
modify,
manifests
are
created
one
time.
It's
a
snapshot
of
the
the
particular
snapshot
of
the
code
base.
That's
what's
being
released.
G
Yes,
some,
so
let
me
let
me
do
this,
I
will
in
fact
we
you've
had
to
create
there.
There's
there's
the
the
the
the
manifestation
manifestation
of
manifest.
J
G
Really
they're,
getting
wrapped
up
in
words
here
of
the
previous
manifestation
of
that
is,
is
in
an
older
database
that
we
that
we
have,
I
can
grab
the.
I
can
grab
the
pieces
of
data
that
go
in
there.
It's
it's
a
combination
of
packaging
information.
G
What
do
I
need
to
get
this
piece
of
software
running
all
of
its
dependencies
as
well
as
everything
else
that's
associated
with
it,
as
I
mentioned
having
to
do
with
its?
You
know,
it's
git
repo
and
all
the
other
things
that
james
just
mentioned.
Let
me
grab,
in
fact
that's
already
internally.
I
think,
for
those
of
you
who
listened
to
my
talk
before
we
have
a
internal
implementation
of
of
kubernetes
at
ebay
is
called
test.io.
G
We
have
a
bunch
of
of
crds
tests
related
crds.
This
is
one
of
them,
so
the
the
release
manifest
is
one
of
them
I'll
grab
that
and
I'll
bring
it
to
this
forum
next
time,
so
we
can
at
least
see
it
this.
This
is
the
kind
of
stuff
we're
jamming
into
a
release,
manifest.
H
So
this
is
steve.
I
just
I
just
shared
my
screen
of
what
we're
capturing
in
artelias
coming
out
of
the
the
ci
process,
so
we're
looking
at
a
component
which
is
one.
H
This
is
the
email
service
component
that
we're
looking
at
and,
like
you're
saying
you
know,
where's
the
issues
where's,
what
charts
being
used
to
deploy
it.
This
is
done
on
a
jenkins
job.
One
was
built
where's,
it
pushed
all
the
the
sha
information
like
I
said,
we're
gonna
be
extending
this
out,
but
that's
some
of
the
basic
stuff
that
we're
looking
at
grabbing.
J
H
A
So
apologies
for
interrupting,
but
I
think
this
is
a
great
discussion
and
it's
a
great
start
because,
like
I
hear
like
a
consensus
here,
we
can
look
at
this
as
a
group
and
continue
exploring
what
is
available.
Like
mentioned,
what
steve
and
tracy
mentioned
from
or
tell
us
and
james
already
have
some
ideas,
so
we
should
definitely
continue
with
this,
and
the
question
I
want
to
ask
is
like:
would
it
be
good
to
like
identify
two
three
people
to
drive
this
topic
forward
like
how
we
are
doing
with
events
work
stream?
F
So,
at
the
risk
of
volunteering,
I'd
be
pretty
interested
in
helping
like,
let's
you
know,
list
all
these
prior
arts.
Let's
compare
things
and
I'm
just
happy
to.
I
guess
product
manage
it
a
bit.
That
being
said
not
for
the
next
kind
of
two
three
weeks,
but
if
we
can
keep
kind
of
looking
at
things
having
the
discussions,
I
think
I
can
get
to
a
place
where
I
can
focus
on
it
a
bit
more,
but
that's
going
to
be
a
bit
down
the
line
right.
B
Okay,
I
was
just
gonna
say:
should
we
start
with
a
little
discovery
dock,
where
we
can
all
give
examples
of
things?
You
know
we
could
have
the
ebay
example.
We
could
have
the
deploy
for
the
example.
We
could
put
the
chicken
and
just
kind
of
say,
here's
all
the
things
we're
doing,
which
is
kind
of
similar,
and
then
we
can
all
ponder
what
it
all
looks
like
and
then
start
thinking
what
a
straw
man
could
look
like
of
what
we
could
maybe
standardize
on
or
something.
H
A
Okay,
so
tracy
miranda,
james
stretch
and
steve
tyler.
I
put
your
names
there
and
I
can
create
a
heck
of
a
document
under
thick
group
like
next
to
events
or
this
meeting
minutes,
and
I
can
share
the
link
with
you.
So
everyone
can
collaboratively
edit.
That
document
and.
F
Besides
the
prior
arts,
everyone
mentioned
and
if
you
can
put
the
links
and
capture
them
there,
if
everyone
thinks
about
the
the
kind
of
problem
statements
like
what
are
we
trying
to
solve?
Let's
list
all
those
out.
So
when
we
come
to
scoping
it,
we
can
be
clear
about
which
problems
we're
trying
to
solve
and
address
for
users.
J
J
A
Okay,
so
sorry
now
I,
as
we
discussed
white
paper
at
the
beginning,
so
the
only
thing
I
want
to
highlight
here
is
like
do
we
have
anyone
who
is
interested
in
contributing
case
study
here?
I
think
oliver.
If
I
am
not
mistaken,
you
mentioned
you
could
do
that,
so
any
updates
on
it.
Yeah.
C
A
F
A
Okay,
thanks
tracy,
I
will
look
for
your
mail
and
then,
let's,
let's
spend
the
rest
of
the
time
for
james
techton,
techton
and
jenkins
sex
presenters.
F
One
more
thing,
I
think
one
more
thing
hold
it
jim.
Just
a
quick
question,
a
quick
comment:
I
saw
the
mention
of
waypoint
the
other
week
and
I
reached
out
to
the
folks
who
are
doing
it:
the
pm
for
that
gen
bride
and
used
to
work
at
clubby,
so
yeah
pretty
happy
to
sync
with
us.
I've
invited
she's,
gonna,
try
and
sync
with
the
the
team
there
and
see
if
they
can
get
one
or
two
folks
to
come
along
and
just
present
at
this
meeting.
F
Just
more,
you
know
what
are
they
thinking
in
terms
of
developer
experience
and
then
maybe
we
can
kind
of
see
how
some
of
our
efforts
tie
into
to
what
they're
doing,
because
it
looks
that's
kind
of
neat.
So
just
so,
you
know
once
they
get
back
to
me
I'll
connect
them
with
fatty
and
cara
to
get
them
scheduled,
but
I
I
let
them
know
about
two
dates
in
november
and
I
told
them
they
were
free
for
now.
So
that's
why.
A
B
I
might
turn
off
my
video
actually
just
because
kids
are
at
home
using
the
internet,
and
my
bandwidth
is
terrible.
Okay,
I'm
gonna
do
a
very
brief
background
of
how
jenkins
x
used
to
work
with
techdot
and
how
it's
going
to
work
with
text
on
pipelining
catalogue.
B
In
many
ways
this
has
been
a
constant
issue
with
cicd
going
back
the
last
kind
of
20
years
that
we
generally
want
to
share
pipelines
and
tasks
across
projects,
but
sometimes
you
want
to
change
them
and
everything
changes
all
the
time.
So
you
have
versioning
issues,
so
this
is
a
very
common
problem
that
tekton
is
trying
to
address
and
check.
His
ex
has
tried
to
address
and
before
it
jenkins
tried
to
address
and
pretty
much
every
ci
tool
at
some
point
tries
to
address
this
problem
of.
B
How
do
you
share
lots
of
complex
metadata
for
what
pipelines
are
and
what
tasks
are
across
lots
of
repositories?
And
how
do
you
change
them
over
time
and
what
happened
in
the
jenkins
ecosystem
was.
Eventually,
people
realized
that
copying
and
pasting
these
massive
jenkins
files
from
the
positive
repository
wasn't
all
awesome,
and
so
this
idea
of
pipeline
library
started
and
then
templating
happened
and
all
that
kind
of
stuff.
B
When
we
first
started
jenkins
x,
we
started
before
tech
time,
so
we
ended
up
making
this
little
kind
of
dsl
for
pipeline
steps
which
we
generated
to
make
jenkins
files.
And
then,
as
soon
as
ken
native
came
along
kennedy
build,
we
generate
kennedy
build
and
then
kinetic
bill
pipeline
came
along,
so
we
generated
that
okay,
language
and
one
of
the
aims
of
the
jenkins
x,
yaml
and
the
dsl
was
trying
to
make
pipelines
composable
so
that
you
can
inherit
pipelines
from
a
shared
library.
B
But
you
can
then
override
things
and
we
tried
our
best
to
make
something
that
kind
of
worked
and
we've
kind
of
decided.
It's,
maybe
not
a
great
idea,
so
we're
we're
moving
away
from
this
ejected
b3,
which
I'll
talk
about
in
a
second,
but
it
at
the
bottom
of
the
slide.
There's
a
little
example
that
we
can
kind
of
say.
I
want
to
override
this
step
in
a
pipeline.
B
We've
generally
decided
it's
not
awesome.
So
let's
do
something
else.
So
in
jenkins,
xb3
we've
taken
a
slightly
different
attack
that
we've
said
rather
than
trying
to
make
a
dsl
that
wraps
tecton.
Let's
just
use
tactile
so
techton
is
the
is
the
dsl.
Now
it
is
the
yaml
standard
for
defining
tests
and
pipelines,
and
the
main
reason
we
want
to
do
that
is
you
want
to
make
it
really
easy,
but
anybody
who
has
any
tectonic
tasks
and
pipelines
to
just
use
them
there's
no
need
to
wrap
them
up
I'll.
B
Do
any
kind
of
weird
things
to
them?
We
want
to
work
well
with
tech
and
catalog,
where
we
can
share
tasks
and
pipelines
with
their
catalogue
and
also
we
want
to
be
able
to
share
things
that
the
jenkins
ex
community
build
with
the
tecton
the
white
detector
on
the
ecosystem.
B
But
there
is
this
requirement
that
we
have
very
strongly
in
genesis
x,
which
I
know
the
tech
and
folks
have
been
looking
at
as
well
is
how
do
we
support
sharing
pipelines
and
tasks
across
repositories
but
being
able
to
change
them
right?
It's
all
very
well
sharing
pipelines
and
tasks,
but
then
what
happens?
If
you
want
to
change
step
four
of
the
pipeline.
That
does
something.
How
do
you
do
the
change
so
what
we
I'll
just
present?
B
Very
briefly,
what
we've
come
up
with
so
oh
by
the
way
these
are,
these
are
the
current
state
they
are
in
the
tecton
community.
We
can
share
tasks
across
pipelines,
so
task
sharing
in
tectonic
is
pretty
much
a
solved
problem.
You
can
share
to
referring
to
task
by
a
name
in
kubernetes.
You
could
have
a
name
called
git
clone
and
I
can
any
pipeline
can
reference
the
git
clone
task
by
name,
which
is
great
one
of
the
downsides
of
that,
though,
is
there's
only
one
resource
with
that
name.
B
So
then
you
have
to
put
the
version
in
the
name,
which
is
a
little
bit
kind
of
weird
in
kubernetes
and
there's
a
better
approach
in
tecton
now
called
bundles,
where
you
can
refer
to
a
task
via
a
container
image
and
tag,
and
hopefully
soon
the
good
repository
and
share
so
rather
than
referring
to
just
the
name.
You
can
use
a
name
and
a
version
which
is
a
really
nice
way
of
sharing
an
immutable
image
of
a
task
select
for
tasks
if
you're,
sharing
it
without
changing
it.
B
Sharing
on
pipelines
is
a
little
bit
hard,
because,
usually
you
want
to
change
them
right.
I
might
want
to
inherit
the
pipeline
for
doing
a
release
of,
I
don't
know,
go
or
spring
boots,
but
then
I
might
want
to
change
step
three,
because
I
want
to
add
some
more
memory
or
I
want
to
change
a
command
line
argument
or
something
now,
if
ever
you've
read
brian
grant's
document
on
declarative
yaml
for
doing
deployments
of
onenote.
B
This
kind
of
run-
pretty
true,
read
it
about
a
year
ago
and
it
kind
of
alarms
belts
went
off
when
I
thought
of
the
junkies
x,
dsl
and
google
have
made
an
open
source
project
called
kept.
It's
spelled
kpt
but
pronounced
kept,
which
is
basically
a
tool
for
copying,
yaml
files
between
repositories,
but
using
git
and
sha.
So
it's
like
a
versioned
copy
of
yaml,
keeping
a
reference
to
the
version
that
it's
copied
and
allows
you
to
upgrade
over
time
to
the
new
version,
but
also
to
keep
changes
and
merge
changes
locally.
B
So
we
kind
of
read
that
and
thought.
Well.
Why
don't
we
try
instead
of
having
a
dsl
birth
text
on?
Why
don't
we
just
use
tecton
and
use
kept
to
share
tecton
pipelines
across
repositories.
So
this
is
a
quick
demo
of
looks
like
now,
so
this
is
a
quick
demo
of
a
command
in
jigezek,
which
is
called
jx
pipeline
import
I'll
just
press
play,
so
you
can
see
it
work.
So
this
is
a
command
for
sharing
a
text
on
task
from
the
tekton
task.
Catalog
inside
your
repository.
So
it's
a
very
quick
demo.
B
It
does
a
git
clone
of
the
tecton
catalogue,
which
is
just
a
git
repository
with
folders,
with
versions
of
tasks
inside
it
gives
you
a
little
combo
box
thingy
that
lets
you
pick,
which
kind
of
task
you
want
to
pick
and
you
can
type
to
search
as
well.
So
we
type
a
little
bit
and
search,
and
we
pick
one
so
we're
going
to
use
one
of
the
ncf
build
packs
here
and
you
hit
return
and
what
it
basically
does
is
it
uses
the
kept
binary
to
do
a
git
clone.
B
It
also
does
a
lighthouse
thing,
which
I
didn't
talk
about
too
much
for
this
call,
but
it's
a
lighthouse
thing
that
then
enables
triggering
of
that
pipeline
task
whenever
you
pull
request
or
you
release,
so
we
decide
when
we
want
to
trigger
this.
Do
you
want
us
or
do
you
want
to
trigger
it
on
releases,
and
then
those
are
all
the
source
files
it's
created?
B
Now
we
just
show
you
the
source
files.
You
need
to
worry
what
these
look
like
for
those
who
know
tecton,
you
know
what
the
tecton
pipelines
look
like.
Those
who
don't
know
lighthouse,
don't
worry
about
that,
but
this
is
the
trigger
configuration,
which
is
a
lighthouse
thing
for
enabling
this
tecton
task
to
be
triggered,
and
then
this
is
the
text
and
test
that
we've
shared
from
git.
B
Now
the
main
thing
I
want
to
talk
about
and
show
you
really
is
this
idea
that
by
using
kept,
it
gives
us
another
tool
in
our
armory
for
sharing
techton
tasks,
all
pipelines
across
repositories
and
we've
been
finding
kept
very
useful
at
sharing
all
kinds
of
things,
not
just
text
and
stuff
we're
doing
it
for
help
chats
and
various
other
kind
of
things,
because
the
great
thing
is
we
could
then
share.
For
example,
I've
shared
the
build
pack
yama.
B
I
could
then
share
that
yaml
across
20
micro
services,
if,
if
any
of
those
micro
services
want
to
change
one
of
the
steps
in
that
task,
they
just
edit
the
yammer
get
its
version.
Each
micro
service
then
has
its
own
version
and
then
separately.
You
can
then
upgrade
those
versions
across
the
repositories.
B
B
It
can
be
used
in
conjunction
with
all
the
existing
tech
on
the
use
mechanisms
you
can
still
use.
You
know
immutable
tasks,
versioned
inside
gateway
inside
image,
bundles,
and
you
can
totally
use
that
if
you
wish
so
you
can
choose
to
use
that
for
class
or
you
can
copy
tasks
into
your
good
repository
where
I
see
kept,
having
its
biggest
use
is
reusing
pipelines,
which
is
something
that
the
tectum
catalog
hasn't
particularly
looked
at
terribly
much.
Yet
it's
it's
pretty
much
nailed
we're
using
tasks.
B
H
B
Yeah
well
not
automatically
it's
up
to
you
to
decide
when
to
upgrade.
So
let's
say
you
have
version
ones
of
your
pipeline,
you
can
too
and
then,
by
default,
nothing
happens
and
then
currently,
if
anybody
is
in
a
git
repository
that
they
wish
to
change,
you
run
this
little
command,
jx
github's
upgrade
and
that
will
upgrade
any
shared
pipeline
yeah.
B
Well
in
your
repository,
so
I
might
have
shared
a
linter,
a
container
image
task
and
a
pipeline
that
does
promotion
or
something
I
might
have
lots
of
different
shared
things
I
can
choose
which
thing
to
upgrade
when
and
kept
manages
handles
the
deltas
and
the
merge
conflicts.
If
there
are
any
merge
conflicts,
and
I
should
backtrack
slightly.
Tekton
has
a
composition
model
where
a
pipeline,
a
pipeline
run,
can
have
one
or
more
pipelines
and
a
pipeline
can
have
one
or
more
tasks
and
a
task
can
have
one
or
more
steps.
B
B
B
I
might
have
five
tasks
that
make
up
a
pipeline
and
I
might
choose
to
add
a
step
in
between
those
three
tasks
or
something
or
I
might
decide
to
remove
it
task
or
replace
a
task
or
configure
a
test
differently
or
change.
The
parameters
that
use
change
a
command
line
in
step.
Four
of
task
two,
so
we
find
pipelines
are
the
place
that
you
wanna
be
able
to
just
do
whatever
you
need.
B
Tasks
are
something
that
can
be
really
shared,
but
you
wanna
share
a
specific
version
of
a
task.
So
it's
a
it's
a
fascinating
area.
This
whole
thing
because
it
it's
tricky
right,
there's
lots
of
different
use
cases
and
requirements.
Sometimes
people
want
to
have
one
glo
global
view
of
a
pattern,
and
if
that
changes,
they
want
to
forcibly
push
that
pipeline
onto.
Oh,
my
goodness,
services.
Other
people
want
to
kind
of
take
change
when
people
are
ready.
So
you
know
when
you're
ready
upgrade
your
pipeline
to
the
ladies
version.
B
Where
are
we
going
with
jenkins
at
the
moment?
Is
we're
assuming
we
just
generate
pull
requests
to
push
changes
down
through
all
the
different
repositories
so
that,
if
you're
an
owner
of
a
microservice,
you
choose
when
to
merge
the
upgrade
pull
request?
Basically,
so
we
automate
the
purpose
generation
and
you
choose
when
to
consume.
B
The
pro
request,
a
little
bit
like
if
ever
you've
used
depend
about
on
github,
the
appenderbot
will
generate
pull
requests
when
all
your
dependencies
upgrade
we're
kind
of
seeing
pipeline
changes
as
like
that,
it's
one
of
your
dependencies,
your
dependency
has
changed.
Do
you
want
to
take
the
new
version
of
the
pipeline
or
not,
and
you
choose
when
kind
of
thing.
D
So
we're
having
kind
of
similar
discussions
not
totally
similar,
but
just
let
me
ask
you
if
this
is
something
that
could
potentially
be
used
to
solve
this
particular
use
case.
D
D
We
know
how
you
know
we
could.
We
could
assign
a
risk
value
to
what
we
call
a
domain
because
it
uses
a
domain
structure
and
we,
I
think
what
we
were
supposed
to
we.
I
think
we
should
be
on
the
the
agenda,
maybe
for
the
next
two
weeks
to
do
a
demo
over
tillius,
so
that
this
can
be
more
clear,
but
we
can
create
a
domain.
We
have
a
domain
structure
for
a
domain
driven
design.
We
could
assign
a
risk
value
to
a
domain.
D
So
let's
say
security
is
the
domain
and,
let's
say
the
microservice
impacts.
15
applications.
That's
going
to
have
a
very
high
risk
level.
Now,
if
we
go
at
a
lower
level
domain,
let's
say
a
website
and
that
website
the
microservice
we're
dealing
with
is
a
front
end.
It's
going
to
have
a
much
lower
level
risk
because
it's
not
impacting
anything
but
that
one
application
team.
D
D
So
the
workflow
has
to
have
can't
have
any
data.
The
workflow
has
to
be
completely
separate
from
the
data
right
because,
let's
say
well,
we
just
found
out
that
every
single
time
this
team
releases
their
front
end,
it
breaks
their
application.
We
know
that
and
it
we
increase.
We
can
increase
the
risk
value,
so
it
should
go
from
maybe
a
medium
level
security
process.
D
L
So
if
a
task
is
just
reused
around,
like
hundreds
of
pipelines,
do
you
expect
and
as
a
task
owner
is
the
onus
on
you
to
push
out
say
there
is
a
security
vulnerability
right.
So
you
fix
it
in
the
task
and
you
still
have
to
send
out,
like
hundreds
of
potentially
pull
requests
to
each
of
the
downstream
clients.
B
Yeah,
I
think
that's
a
great
question
and
this
doesn't
quite
exist
yet,
but
what
would
be
awesome
is
if
you
are
the
consumer
of
something
it
doesn't
matter,
if
it's
a
node
library,
a
girl
library,
a
text
on
task
or
whatever
you're,
using
a
dependency.
B
If
there's
a
security
fix
in
the
upstream
dependency,
you
should
just
get
a
pull
request.
That
says,
you
need
to
upgrade
this
right.
Security
fix.
If
it's
a
new
feature.
Well
you
to
do
your
own
pull
request,
but
when
it's
pushing
you
know
important
bug,
fixes
or
or
security
fixes,
I'd
rather
have
a
pull
request
myself
generated
on
all
my
projects
by
the
upstream
maintainer
or
whatever
or
the
ecosystem.
B
So
I
I
would
like
that
pull
request,
automation
to
be
a
thing:
that's
generic
we've
started
using
dependenbot
on
a
few
projects
and
dependable
kind
of
does
that,
but
it's
very
simplistic.
For
example,
it
doesn't
say
you
generate
so
many
pull
requests
that
you've
got
dependable
requests
everywhere.
You
look,
there's
a
million
of
them
everywhere.
What
would
be
really
nice
if
there's
a
way
of
saying,
stop
everything?
It's
a
security
update
from
dependable
forget
all
those
other
million
pull
requests
this
one.
B
B
You
should
probably
get
these
merged
slightly
to
where
so,
then
you
can
look
across
all
your
requests
and
say
I'm
going
to
merge
the
security
fixes
first
before
I
do
anything
else,
when
it's
we've
done
an
upgrade,
because
we've
added
some
features,
those
kind
of
changes
people
can
normally
make
their
own
mind
that
when
they're
going
to
take
them,
you
know
you
might
decide
to
take
a
new
version
once
a
week
once
a
month,
something
but
security
fixes
should
be
done.
You
know
quickly,
like
really.
L
Yeah,
so
is
there
a
way
to
specify
kind
of
a
tag
or
something
to
say?
Okay,
this
is
a
stable
version,
or
this
is
the
latest
version.
So
when
I
run
my
pipeline
just
pull
this
always
because
I'm
coming
from
screwdriver
world-
and
we
have
this
notion
of
templates
and
commands
where
you
can
share
solutions,
so
it
supports
version,
but
it
also
supports
tags
and
even
some
more
kind
of
format,
but
you
can
just
say
I
want
this
template
at
version
two.
So
any
patch
versions
or
just
gets
pulled
in
automatically.
B
Yeah
there
is
the
semantic
version
thing
you
can
click
into
this.
You
could
say
you
know
I'll
always
take
patch
versions
of
things
quickly,
but
you
know
major
versions.
I'm
going
to
really
think
about
ever
doing
that
or
you
know
I'm
going
to
slowly
upgrade
to
the
next
major
version.
When
I
choose
you
know,
I
might
schedule
it
every
six
months
or
something
but
patch
versions.
I
probably
want
to
take
them
reasonably
automatically,
but
even
with
touch
versions.
B
People
are
fixing
bugs
all
the
time
and
that's
fine,
but
I
might
not
need
a
patch
version
unless
I
particularly
want
one.
However,
if
a
patch
version
has
a
security
label
on
it,
this
is
a
patch,
but
it's
a
security
fix.
I'm
not
going
to
take
those.
So
I
think
we
we
almost
want
to
it's
going
back
a
bit
like
the
metadata
discussion
before
it'd
be
really
nice.
B
If
there
was
a
way
of
saying
this
new
version
has
a
security
fix
in
it,
you
should
just
upgrade
because
it's
secure
versus
this
has
got
a
bug
fix
in
it,
and
this
is
the
bug
fix
and
you
then
choose
is
that
bug
fix
relevant
to
your
use
of
that
tool
or
not
because
there's
a
lot
of
bug
fixes
you
don't
they're,
not
urgent,
right,
they're,
useful,
but
but
security
fixes
usually
are
fairly
urgent
and
it'd.
Be
nice.
D
J
B
A
Sorry,
we
are
two
minutes
over
time.
We
can
continue
the
discussion,
not
I
don't
want
to
interrupt,
but
just
to
let
everyone
know
we
are
like
the
meeting
is
normally
over
and
the
next
meeting
will
be
12th
of
november.
So
anyone
wants
to
stick
around.
We
can
continue
just
say
that
and
thanks
for
joining
yeah
james
sorry
for
interrupting.
D
H
Well,
on
the
monolith
side
you
have
to,
if
there's
a
security
fix,
you
have
to
go
and
recompile
and
and
bring
in
let's
say
we
have
log4j,
has
some
security
fix
in
it
that
you
have
to
go
and
rebuild
at
the
ci
level,
even
though
your
source
code
may
now
change
to
bring
that
new
library
in
at
the
microservice
level,
you're
going
to
have
to
do
more
than
likely,
you
have
to
rebuild
the
container.
H
If
it's
like
a
node,
you
know
if
it's
a
sub
dependency
at
that
level
to
bring
it
in,
because
the
containers
typically
don't
bring
in
you
know,
packages
on
the
fly.
Are
they
once.
D
D
You
create
a
lot
of
sprawl
when
you
do
that,
and
a
lot
of
you
create
a
pretty
tangled
hair
ball.
L
Yeah,
it's
quite
interesting
here
at
foreign
media.
We
have
this
mandate
that
even
for
your
bare
metal
operating
system,
you
have
to
upgrade
like
every
three
months.
You
cannot
have
a
stale
version
running
on
your
systems
because
that's
what
ultimately,
an
attacker
can
get
in.
So
we
have
this
mandate
from
our
security
teams,
like
even
your
oil
seems
to
be
upgraded
like
every
three
months.
You
cannot
just
been
to
one
thing
and
run
like
four
years
and
just
forget
about
it.
Unless
you
will
get
like
security
tickets
or
opened
against
you.
B
H
The
other
extreme
is
where
you
know:
you're
you're,
building
and
pulling
latest,
let's
say
python
packages
or
node.js
packages
that
you
all
of
a
sudden
are
introduced.
Some
weird
thing,
even
though
your
source
code
hasn't
changed,
but
that
this
seems
to
be
fewer
and
far
between
than
the
other
way,
whether
where
we
have
to
we're
missing
security
fixes,
instead
of
introducing
bugs.
D
So
I
do
have
to
jump
off.
I
I
told
steve
he
was
supposed
to
do
a
demo
today,
he's
probably
very
happy
that
that
we're
he's
not
because
he
wasn't
really
prepared,
but
we
do
want
to
do
one
for
next
week.
So
if
we
can
get
on
the
the
schedule
for
the
next
two
weeks,
if
there's.
D
We
have
a
lot
of
features
that
integrate,
like
we
have
already
built
in
integrations
with
things
like
jenkins,
for
example,
that
we
could
show,
but
on
the
discussion
that
we've
been
having
around
this
topic,
as
well
as
the
topic
of
having
a
the
manifest
topic,
would
that
be
of
more
interest?
What
what
road
should
we
go
down
for
you?
D
We
named
the
company
deploy
hub
because
not
that
we
do
deployments,
but
we
are
a
hub
of
deployment
information,
so
you
can
always
repeat
a
deployment,
and
anybody
can
then
do
the
deployment
like
helm
or
we
could
pass
it
off
to
spinnaker
for
that
matter.
So
I'm
I'm
wondering
what
you
guys
would
like
to
see.
K
E
G
I
I
would
prefer
to
see
the
the
manifest
related
features
that
you
have.
D
D
D
A
Thanks
for
joining-
and
I
will
thank
you
tracy
and
steve
before
the
meeting-
so
we
think
for
the
presentation
like
fifth
of
november
or
something.
A
Thanks
all
for
joining
yeah,
it's
not
the
12th
of
november
is
the
next
meeting,
and
I
put
the
link
to
the
meeting
minutes
for
the
metadata
hmd
document,
and
I
will
send
a
separate
mail
pointing
to
the
same
link.
So
you
can
just
start
putting
your
thoughts
there
and
continue
collaborating
thanks
a
lot.
Okay,
all
right.