►
From YouTube: Kyma Prow Migration WG meeting 20190104
Description
Meeting notes: https://docs.google.com/document/d/1ljEAoCBJXlxx_ATPyvKZ1KoyFOSIBzEAOkN-2H-HhUY/edit
B
Okay,
thank
you.
Thank
you,
Mike
them.
So
let's
have
a
look
on
our
board,
so
I
think
the
most
important
one
is
this
epic,
with
switching
official
CIA,
so
currently
Kim
is
using
arrow
instead
of
Jenkins
and
here
and
we
disable
all
Jenkins
jobs.
So
we
decided
to
do
not
remove
Jenkins
file
so
far,
because
we
want
to
have
a
safe
graph
if
there
will
be
any
kind
of
problem.
B
Here
you
can
see
in
this
command
that
we
implement
release
jobs
for
every
component
or
every
tool,
so
it
is
pretty
great
and
in
addition
to
that,
we
implement
some
jobs
that
are
really
specific.
So,
for
example,
we
implement
kima
artifacts
job
generated
to
young,
face
that
our
artifacts
for
the
release
we
implement.
B
Okay,
that's
all!
Maybe
one
more
thing
here.
You
can
see
that
we
have
in
progress
to
issues,
release
proud
job
for
github
release.
I,
think
Magda
is
working
on
that
and
Creed
release
pipeline
for
tangent
artifacts,
and
she
is
working
on
that
and
you
have
only
one
to
do
issue
about
making
chimera
lists
more
robust,
but
I'm
not
sure.
B
To
get
rid
of
that
problem,
and
today
I
heard
that
this
IP
I,
you
probably
want
to
be
implemented
in
this
release,
and
so
here
probably
we
we
are
going
to
remove
that
that
issue
from
the
epic
and
we
we
need
to
think
what
to
do
with
this
job.
So
correcting
me,
how
is
doing
that
cleanup
manually
and,
as
you
probably
know,
our
working
group
is
going
to
be
closed
quite
soon.
B
So
probably
we
want
to
have
human
resources
to
implement
that,
and
maybe
we
just
postpone
that
periodic
job
for
later
implementation
and
about
next
parity.
So
in
the
next
week
we
are
going
to
validate
how
are
releasing
procedure.
Releasing
my
plan
is
working
on
prowl
and
finally,
we
want
to
release
and
came
an
inversion
0.6
using
prowl.
That's
all
and
thank
you.
A
Okay,
so
maybe
I
have
one
really
quick
one
cause
when
I
started
to
working
on
on
that
release.
Github
job
at
some
point,
I
noticed
that
we
also
have
implementation
of
generating
change
lock.
To
be
more
specific,
we
have
to
change
locks,
one
is
it's
called
big
one
and
it
was
appended
with
every
release
and
and
at
the
beginning
it
was
plants
to
be
checked
in
by
drink
pipeline
run,
run
and
another
one
is
a
smaller
one,
which
is
specific
only
to
that
to
that
release,
and
it
is
part
of
body
of
github
release.