►
From YouTube: 2022-12-14 Delivery:Orchestration demo - EMEA/AMER
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
Okay,
so
welcome
my
friend
December
the
14th.
This
is
our
emea
America's
timed
demo
and
let's
have
a
look
so
Myra
I'm,
going
to
hand
over
to
you
thanks
for
filling
in
the
agenda.
B
Yes,
yeah.
Thank
you
so,
just
taking
over
the
actions
from
the
previous
demo,
we
were
talking
about
how
to
unlock
the
maintenance
policy
from
the
release
environment.
So
the
maintenance
policy
is
not
blood
control.
These
environments,
effort
and
I
summarized
the
discussion
that
you
had
on
the
demo
so
basically
to
move
on
with
them
with
the
maintenance
policy.
Without
the
release
environments,
we
need
a
way
to
test
these
new
versions
and
for
the
current
stable
version.
B
Now
I
was
reading
the
process
about
backboarding
this
about
the
back
Port
q,
a
testing
process,
and
it
is
a
bit
blurry
from
my
perspective,
I'm,
not
sure
if
I
understand
in
the
process
correctly,
but
it
seems
that
it
is
only
waiting
for
that
pipeline
to
be
green.
It
doesn't
the
quality,
doesn't
do
anything
else
other
than
waiting
for
that
Pipeline
and
then
just
if
that
pipeline
is
green,
then
it's
signing
off
and
that's
it.
C
C
B
C
B
D
B
Yes,
okay,
should
it
be
in
both
sides,
should
it
be
for
the
mercho
classes
March
and
on
the
stable
branch,
so
the.
C
Thing
is
that
when,
if
two
it's
unlikely,
but
two
maintainers
are
merging
to
different
back
ports
on
the
same
stable
branch,
the
way
the
merge
request
result
pipeline
works
is
such
that
each
one
will
be
tested
independently,
because
this
is
not
the
merged
strain
is
as
merge
results.
So
both
take
the
target
branch
on
the
current
state,
apply
the
merge
on
it
and
run
a
pipeline
on
the
merge
result.
C
And
then,
if
you
hit
merge,
basically
it
will
merge
again
so
which
means
that
if
they
were
pushed
at
the
same
time,
they
will
be
running
not
one
on
top
of
the
other,
but
just
each
one.
On
top
of
the
stable
branch,
okay,
yeah.
B
C
B
This
table
branch
is
that
yeah.
It's
just
that
my
concern
about
having
it
on
this
table
Branch,
but
not
on
the
merch
request
is
that
if
it
fails
it's
going
to
fail
on
the
stable
branch,
which
is
after
the
merge
which
might
be
too
late
for
developers
to
act
on
it.
So
I
would
prefer
to
for
the
failure
to
show
up
on
the
merge
request
before
merging
into
a
staple
Branch.
B
C
D
A
Few
points
where
you're
asking
like
would
it
be
enough
for
Quality
to
sign
off
if
we
did
this
or
how
does
that
work?
I
think
it
would
be
good
either
on
the
issue
you
already
have
or
on
a
on
a
separate
issue,
but
to
actually
us
to
get
to
like
this
is
the
process
we
want
to
use
to
be
able
to
test
these
versions,
and
then
we
can
talk
to
Quality
and
basically
be
like
here's
our
proposal.
A
You
know
how
like
so,
they
know
it's
coming
and
also
if
they
have
any
like
alternative
ideas,
they
want
to
include
yeah.
B
Who
yeah
I
was
thinking
about
that?
Who
will
be
the
best
person
to
touch
in
quality
about
this.
A
So
for
now
I
we
don't
have
anyone
named
I
would
suggest
Vincy
and
ask
her
to
direct
it
to
someone
appropriate.
B
B
D
D
B
B
I'm,
assuming
you
are
already
seeing
my
screen
and
if
not
please
say
something
so
I
have
been
working
about
pushing
the
patch
release
information
to
the
delivery
metrics,
and
this
is
basically
for
the
information
to
appear
on
the
release.
Manager,
dashboard
and
release
managers
have
like
a
way
to
tell
like
okay,
there
is
enough
pressure,
so
we
can
start
a
patch
release.
B
Now,
when
I
was
implementing,
this
I
noticed
that
there
is
actually
no
merch
request
merch
into
the
stable
into
the
stable
branches
that
hasn't
been
published,
and
that
is
explainable
because
we
don't
have
like
a
patronizing
progress,
not
a
security
release,
so
everything
that
is
on
the
stable
branches
has
been
published,
and
there
was
no
straightforward
way
for
me
to
test
this.
So
what
I
did
is
was
to
prepare
a
March
Quest
and
merge
it
into
a
stable
branch.
B
Please
note
that
this
is
stable
branches
out
of
the
policy
like
it
is
not
going
to
affect
any
battery
security
release,
and
it
is
just
like
a
documentation,
change
very
simple,
like
not
intrusive
at
all
or
not
disruptive
at
all,
and
it
was
actually
a
merch
request
that
got
like
the
peak
into
15.3.
So
there
it
is
so
I
merged
this
and
now
I
can
show
you
the
code
that
I
am
preparing,
because
this
one,
which
is
already
in
review
and
I,
think
unless
you
already
did
some
comments.
B
So
first
of
all,
I
had
to
modify
release
tools,
so
it
actually
consider
15.3
to
be
inside
the
policy
right
now.
It
is
outside,
but
I
have
to
modify
it
and
the
code
is
also
only
analyzing
projects.
It
is
only
analyzing
the
gitlab
project.
It
is
not
analyzing
Omnibus,
not
literally
not
pages,
to
make
this
test
as
succeed
as
possible.
B
Okay,
so
this
is
a
lot
of
debugging
information
that
we
can
ignore.
The
result
that
we
are
interested
in
is
basically
this
one,
and
it
is
fetching
the
merch
requests
based
on
severity
for
each
versions.
We
can
see
that
we
don't
really
have
anything
for
15.5.
The
same
results
is
for
15.4,
but
we
do
have
something
for
15.3,
which
is
an
S4
and
well.
We
can
see
that
this
merch
request
that
it
was
this
one.
B
So
you
should
reflect
the
new
change
and
there
we
go
so
we
have
one
S3
for
15.3
that
hasn't
been
released,
not
published,
and
this
can
count
as
a
patch
pressure.
Now.
This
information
is
basically
a
ruby
object
and
the
next
step
is
to
push
that
Ruby
Arch
object
into
the
release
pressure
into
the
delivery
Matrix,
which
is
what
this
class
is
doing.
It
is
just
basically
sending
all
that
information
into
the
metrics,
and
then
it
should
appear
like
well.
B
A
What
are
the
next
steps
that
you
have
so
I
guess
like
how
many
steps
away
from
having
this
data
usable
in
delivery
metrics?
Are
we.
B
Yeah,
it
is
some
other
of
merging
that
merge,
request,
enable
that
feature
flag
and
start
testing
right
now,
since
we
don't
have
any
data
on
15.5,
not
15.6
or
15.4,
it
will
be,
it
will
show
a
zero,
but
as
soon
as
we
start
merging
something,
whether
it
is
not
batch
release
or
a
security
release,
the
numbers
will
start
to
increase
and
they
will
show
up
like
in
a
metric.
A
Do
you,
what
is
that
sort
of
thing
like
what
are
we
sort
of
thinking
we'll
be
able
to
have
this
patch
release
pressure
like
running
alongside
our
existing
metric
yep?
Sorry
like
when,
when
do
we
think
we'll
be
able
to
start
seeing
that.
B
Well,
as
soon
as
this
is
merged,
and
then
we
can
start
implementing
or
we
can
start
expanding
the
release
manager
dashboard
to
show
the
new
widget.
B
I'm
not
sure
it
really
depends
on
how
the
what
all
the
reviews
and
on
the
implementation
details.
Okay,.
A
Right
it'd
be
great
to
get
it
up
because
I
think
as
soon
as
we
can
start
seeing
that
it's
running
in
parallel,
then
we
can
like
really
start
sort
of
building
from
there.
B
So
regarding
the
maintenance
policy
station,
we
have
agreed
that
it
will
be
unblocked
from
the
release
environments,
meaning
that
we
are
not
going
to
use
the
release
environments
on
the
first
iterations.
They
are
no
longer
like
a
requirement.
They
will
be
some
sort
of
a
nice
to
have,
but
that
point
us
in
an
interesting
discussion
about
how
developers
will
know
when
their
merge
request
is
going
to
likely
to
reach
customers
or
they
are
going
to
be
patch.
B
B
The
problem
is
going
to
be
for
the
last
two
previous
versions,
because
they
are
not
going
to
be
deployed
to
any
environment.
They
are
going
to
be
tested
to
the
maintenance
policy.
Now
I
have
some
ideas
about.
How
can
developers
know
when
the
patch
release
is
going
to
be
available,
and
it
is
basically
about
reusing
the
same
tooling
that
we
have
now.
The
patch
release
can
be
broadcasted
with
Slack,
and
we
can
also
expand
the
chart
of
release
check
to
support
patch
releases.
C
But
doesn't
it
already
supported
patch
releases,
I
mean
if
you
the
the,
if
I
remember,
you
gave
him
a
merge,
request
right
and
he
check
if
it's
inside
any
tag,
so
maybe
wrong
here,
but
it
already
support
the
current
patch
releases.
So
because
what
we
have
here
is
not
back
I
mean
we
have
a
backboard
Mr,
so
it's
a
different
Mr
with
a
different
shot.
So
we
need
to
verify
but
I'm,
expecting
the
chatops
check,
release,
merge
request.
B
A
As
a
super
short
term,
so
this
I
think
this
is
still
a
there
may
be
environments
I
think
it's
a
very
much
an
unknown
but
I
think
as
a
if
we
need
it.
Another
short-term
option
could
be
to
just
make
an
announcement
right.
We.
A
This
so
notify
to
say
you
know,
patch
release
for
15.4
is
going,
you
know,
is
being
prepped.
It
goes
next
week
whatever
like.
If
we,
if
we
really
had
to
okay.
C
Look
at
any
case,
isn't
the
change
log
already
enough
or
the
the
automated
blog
posts
right,
because
it
goes
into
each
one,
merge
request.
So
if
the
question
is
did
my
if
the
question
is
when
my
major
request
was
shipped
yeah,
that's
hard,
but
if
it's
more
the
battery
it
was,
how
did
it
actually
included
mine?
You
can
go
on
the
blog
posts
and
it
should
be
a
link
to
your
in
the
short
term.
Obviously
right
so
we
want.
B
A
A
Before
we
move
on
to
the
next
topic,
just
generally
around
the
maintenance
policy,
roughly
do
you
have
a
rough
idea,
Myra
of
like
percentage-wise
of
how
far
you
are
through
that
epic,
in
terms
of
like
zero
to
100
off,
like
we
would
be
able
to
make
the
maintenance
policy
extension
at
a
hundred?
Do
you
have
a
rough
idea.
A
C
Thank
you,
so
I
was
looking
at
the
current
state
of
pages,
managed,
versioning
and
trying
also
to
bring
into
the
conversation
the
all
the
other
pages
maintainers
so
make
sure
that
we
can
have
this
ready
in
time
for
the
next
monthly,
and
this
reminded
me
of
the
very
old
issue
831
about
being
able
to
do
Shadow
releases,
because
the
the
current
proposed
test
plan,
I,
think-
and
so
let
me
rephrase
I
think
it
is-
is
likely
going
to
be
more
dangerous
to
tag
a
fake
version
and
then
have
to
undo
all
the
things
that
the
tool
is
doing,
because
right
now
is
a
lot
more
than
what
used
to
be
when
initially
Uric
was
doing
his
test,
because
he
used
to
tag
14
into
40
release.
C
Compare
it
to
actually
because
we
have
the
Fisher
flag,
try
it
so
not
really
just
well.
Okay,
it's
monthly
release,
gonna!
Do
it
and
cross
our
fingers,
but
more
about
having
some
sort
of
let's
test
some
of
those
pieces
independently.
We
know
that
the
gluing
code
around
this
already
works
because
it's
the
same
one
we're
using
for
gisely
and
so
I
was
thinking
roughly
the
last
three
release
that
we
have
are
those
one
in
the
list
right.
C
C
So
we
know
that
tagging
and
creating
the
change
log
of
pages
works.
Then,
on
top
of
when
this
works
we
can
say
maybe
we
can
do
a
gitlab
patch
release.
So
our
patch
current
patch
release
for
the
whole
package
and
if
we
are
able
to
do
this
before
tagging,
the
the
monthly
release
it
kind
of
give
us
another
big
chunk
of
this
run,
because
there
will
be
no
stable,
Branch
generation,
because
in
a
patch
release
is
already
there.
C
But
it
covers
most
of
the
code
base
of
what
we
introduced
and
then
it's
around
the
22nd
and
we're
going
to
run
the
regular
release
with
everything
included
and
yeah
I
mean
pages
is
quiet
at
the
beginning
of
it.
So
if
it
fails,
we
can
remove
the
the
feature
flag
and
continue
with
the
a
manual
process
basically
around
it.
C
E
Is
there
any
concern
with
having
those
those
tags
existing
on
pages
like
if
we
have
15.6.2?
Does
that
create
any
confusion
for
users
or
anything
like
that?.
C
So
it
will
create
confusion
in
any
case,
because
the
there
will
be
the
the
big
version
Gap.
So
if
we
are
going
to
create
those
ahead
of
time,
then
we
can
do
an
extra
merge
request
to
just
update
the
change
log
when
we
add
there
something
like
those.
This
is
where
version
1.62.0,
which
I
think
is
one
of
those
got
aligned
into
managed
versioning,
and
so
this
is
technically
the
same
software.
C
From
now
on,
this
will
be
the
the
the
the
the
the
the
verse
the
the
version
scheme
that
you
will
see.
Those
will
be
tagged.
Those
will
be
there,
but
they
will
not
be
released
because
we
are
not.
We
are
not
going
to
to
repackage
gitlab
for
those
right.
Just
we
are
just
creating
the
the
the
same
version
with
the
expected
numbers.
C
A
We
probably
have
stuff
but
I'm
thinking
like
if
we
need
it
for
testing
purposes.
Yeah
like
there
are
you.
A
We
needed
to
like
so
Stephen.
Why
are
you
weren't
in
this
morning?
It's
delivery
weekly,
but
we
talked
well.
Let's
see
I
suggested
to
the
release
managers
that
we
try
and
do
a
patch
on
Friday,
so
I
think
in
this
case
like
if
we
don't
have
I,
think
we
have
things.
But
if
we
didn't
have
anything
that
was
ready
to
patch
on
Friday
for
15.6,
we
could
always
patch
something
older,
yeah.
C
We
have
five
merge
requests
at
the
moment.
I,
don't
know
how
important
they
are.
That's
why
I
was
suggesting
we
can
do
for
for
that,
one
instead
of
going
back,
but
if,
if
we
go
as
back
as
15
4,
it
will
do
the
right
thing.
B
It
is
always
difficult
to
test
these
Integrations
I.
Think
I
was
talking
with
Steve
about
about
this
yesterday,
because
we
don't
really
have
a
playground
to
test
that
to
test
them
once
they
are
implemented,
so
we
always
come
up
with
something
like.
Oh,
we
need
to
do
it
live,
but
we
careful
about
it
and
I
think
it
is
one
of
these
problems
that
it
is
very
particular
for
delivery,
because
the
same
thing
happened
with
the
rearrange
of
the
coordinated
pipeline.
There
is
no
way
to
really
test
that
other
than
actually
do
the
deployment.
C
Also,
there
is
a
point
that
I
made
in
this
in
the
agenda
that
I
forgot
to
mention
I'm,
not
entirely
sure
that
the
release
classes
are
really
either
important,
I'm
thinking
about
especially
changelog
generation
and
version
bumpings,
because
so
I
don't
know
the
change
log
generation.
What
we'll
do
if
there
are
no
commits
past
the
chart,
because
in
theory,
if
you
rerun
it
will
just
try
to
generate
a
change
log
between
the
head
itself.
C
C
Nothing
that's
great,
but
the
version
bumping
we
are
generating
updates
for
version
file
either
the
gitlab
itself
does
for
the
components,
but
also
the
version
file.
So
each
component
has
its
own
version
in
its
own
repo
and
we
upgrade.
We
update
that
one
right.
So
again,
this
is
this.
Is
we
are
asking
through
the
API
to
create
a
commit?
That,
in
theory,
has
the
same
content
of
what
is
already
there?
C
I,
don't
know
what
happens,
but
I'm
sure
90
sure
that
there
is
a
trick
in
in
tagging,
EE
and
CE,
because
we
do
some
weird
magic
with
the
with
the
version
file.
C
So
I'm,
maybe
the
thing
kid
just
rerun,
because
it
is
not
finding
the
the
expected
file
but
in
any
case
yeah.
So
this
was
some.
This
is
something
probably
we
should
try
to
take
a
look
a
bit
closer
and
see
what
is
happening
there,
because
I
was
expecting
something
like
at
the
beginning
of
the
execute.
If
this
talk
is
already
here,
skip
everything
well,
it
seems
more
to
me
that
each
line
is
something
like
if
the
branch
exists
do
nothing
otherwise
create.
If
this
tag
exists,
do
nothing
otherwise
create.
C
A
Would
like
to
have
a
fun
issue
to
write
up
to
try
and
capture
a
investigation
for
that.
A
Just
seeing
like
yeah,
so
it's
set
up,
so
we
can
do
an
investigation
into
into
into
that
yeah
yeah
I
can
read
an
issue
for
that.
Awesome
thanks
Steve
and
there
might
be
some
gaps.
I
think
it's
a
good
one
for
Alessia
not
to
write,
because
I
think
this
is
we're
very
much
on
SEO
territory.
Right
now.
So
great
knowledge,
not
you
don't
have
to
do
the
investigation
statement
just
to
get
the
issues
so
that
we
can.
We
can
prioritize
this
one
other
thing
about
RC's.
A
That's
massively
changed
as
well,
since
the
the
last
time
when
we
did
a
lot
of
work
here
and
Uric
was
testing.
These
was
also
whether
or
is
a.
If
is
there
a
risk
that
we
end
up
affecting
jihu
as
they
are
picking
things
up
from
our
stable
branches
as
well
or
looking
at
our
packages.
So
that's
the
other
one
that
makes
it
a
bit
more
complicated
than
it
used
to
be.
A
Cool,
what
do
we
want
to
do
then
about
next
steps
like
did
we
did
we
get
enough
from
the
release?
Managers
or
the
release
manager
is
going
to
kick
off
like
a
potential
patch
on
Friday
or
or
how
do
we
want
to
coordinate
this
stuff.
C
I
think
we
first
want
to
make
sure
that
we
tested
some
of
those
steps
ahead
of
time,
so
I
I
don't
know
if
we
want
to
do
the
re-tag
first,
so
I
think
there
is
something
that
we
can
do
between
the
three
of
us
as
those
who
know
what
what
is
happening
with
this
Epic
and
then
talk
about
the
the
patch
release.
A
E
A
Perfect
good
stuff,
because
yeah
we
talked
a
little
bit
this
morning
in
delivery
weekly
and
it
sort
of
was
a
Friday
or
maybe
Monday
a
good
days
to
do
patches,
so
you
know
like,
but
once
we
go
beyond
some
point
on
Monday
but
we'll
be
in
the
release.
Prep
and
what
I
mentioned
to
McKelly
earlier
is
I
I,
wonder
if
Monday
might
be
a
tricky
day
on
deployments,
because
on
Friday
it's
the
last
working
day
of
the
milestone
for
a
lot
of
people.
A
It
might
also
be
that
will
last
working
day
of
the
year.
So
there's
a
I
think
there's
a
possibility.
We
might
see
more
things
merged
on
later
on
Friday
than
we
often
do,
which
might
increase
risk
for
Monday.
So
if
we
do
want
to
do
a
patch
sort
of
late
in
the
Prep
Station,
we
should
handle
the
patch
release
so
that
the
release
managers
can
focus
on
the
monthly
that
might
be
good
anyway.
Right.
If
we're
testing
stuff,
we
might
actually
want
to
be
doing
the
patch
release
so
that
you
can
test.
C
A
Just
one
quick
update,
then
so
in
terms
of
sort
of
how
things
are
looking
so
Graham
is
wrapping
up
his
year
on
Friday
and
then
hopefully,
he'll
be
back
and
working
on
the
release,
environments
from
early
January
and
then
I
think
pretty
much.
Everybody
else
is
mostly
around
next
week.
So
what
I
will
do
is.
A
Actually,
I
have
a
question.
Actually
what
do
you
want
to
do
down
by
next
week?
So
I
will
cancel
the
email
APAC
one
unless
Alessio
you
want
us
to.
We
could
hang
out
and
play
Mario
at
all
anything
else
or
we
could,
and
so
then
we
have
an
option
right
would
would
people
like
to
have
another
email
Americas
next
week
or
we
could
skip
the
week
after
will
be
canceled
because
of
the
holidays.
C
C
So
if
we
are
at
the
same
stage
as
where
we
are
this
week,
because
let's
say
we
try
to
focus
on
close
that
other
one
as
an
example,
then
maybe
there's
it's
pointless,
but
if
instead,
let's
say
Steve
and
I
can
work
on
on
the
GitHub,
Pages,
stuff
and
Mario
can
move
on
the
metrics
tracking.
So
maybe
there's
an
option
to
also
see
the
values
live
and
do
some
Thomas
query
altogether
to
see
what
those
numbers
look
like.
C
I
was
also
thinking
thinking
aloud
here,
because
we
are
going
to
do
a
patch
release
if
there
is
a
timing
that
we
can
use
to
gather
the
metrics
before
tagging,
if
there
is
an
option
for
us
to
actually
see
Myra's
work
running
in
the
tiny
fraction
of
time,
yeah
I
mean
it's
not
a
tiny
fraction,
because
we
tag
manually
right.
So
we
merge
the
preparation
branch
and
then
so
we
can
do
it
right.
So
that
could
be
a
good,
a
good
opportunity
to
see
it
actually
live
with
the
real
it
will.
B
C
And
everything
is
peaked
into
the
preparation
Branch,
it's
it's
not
the
same,
workflow
that
we
see
what
happens
right.
So,
probably,
even
if
you
count
just
one,
it
should
be
probably
one
with
priority
known.
B
D
A
Cool
great
sounds
good,
excellent!
Well,
that's
an
exciting
edge
of
the
year,
hopefully
test
two
things
on
Apache
release
and
we'll
see
how
that
looks
safer.
Is
there
any
other
stuff
we
should
mention
on
this
call.
A
No
okay
awesome!
Well!
Thank
you
very
much
for
the
discussions
and
demos
thanks
for
filling
in
the
agenda
Myra.
Thanks
for
all
the
notes,
Steve
and
yeah
well
excited
to
see
how
the
next
few
days
go.