►
From YouTube: 2023-02-21 - 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).
B
So
welcome
everybody.
This
is
the
21st
of
February
2023.
This
is
our
email,
America's
time
orchestration,
demo
Steve.
You
have
the
first
item.
A
first
demo
item
effect.
C
Yeah
we'll
see
how
much
of
a
demo
it
is
much
the
glance
with
the
code,
but
I've
been
working
on
some
notifications
for
the
extended
maintenance
policy
for
package
and
test
failures,
and
so
I
think
it
was
in
this
meeting.
We
had
kind
of
come
up
with
two
solutions.
C
One
was
when
the
packaging
test
fails.
Add
a
comment
to
the
Mr
pinging,
the
author
and
then
two
was
when
someone
approves
the
mrm
like
after
the
initial
review,
paying
that
person
saying
hey,
we
need
to
make
sure
that
the
package
and
test
job
is
successful
and
so
I
guess.
My
first
question
was
you
know
after
kind
of
looking
at
them
like
do
we
want
both
because
they
are
I
mean
it's.
C
It's
kind
of
a
repetitive
message,
but
it
does
I
mean
it
does
engage
different
people
at
least
which
I
think
is,
is
good
if
we
really
want
to
make
sure
since
this
the
test
isn't
blocked
from
from
failing
or
anything
like
that,
but
it
was
just
a
question
to
raise
and
we
can
jump
in
to
the
first
one
which
unfortunately,
the
pipeline
hasn't
finished
yet,
so
we
don't
have
a
comment
yet
to
look
at,
but
I'll.
C
Okay,
so
so
this
kind
of
parallels
the
failure
notification
that
we
have
for
the
main
pipeline
that
that
notifies
slack.
So
you
know
anytime,
the
master
pipeline
fails
or
now
a
stable
Branch
fails
on
a
commit
message
or
on
a
commit
Mr,
no
a
commit
pipeline,
then
slack
will
be
notified.
So
here
we
kind
of
do
a
similar
thing,
but
instead
of
notifying
slack,
we
add
a
comment
to
the
merge
request.
C
So
what
we're
saying
here,
if
we
look
at
the
rules,
is
if
the
merger
Quest
is
targeting
stable
and
fails.
We
allow
the
failure
to
happen
and
what
we
do
then,
is
we
run
this
script,
which
is
generate
failed
package
and
test
message,
and
so,
if
we
look
at
that
script,.
C
All
it's
going
to
do
is,
let's
start
at
the
bottom,
so
we
can
see
when
it
runs
so
yeah.
We
just
we
run
execute
on
this
class.
Nothing
too
fancy
the
only
option
really
is
the
API
token
that
is
already
part
of
the
pipeline.
C
But
all
we're
going
to
do
is
check
if
the
packaging
test
job
has
failed
and
then,
if
it
did
add
a
comment
to
the
Mr,
so
nothing
too
crazy
or
complicated
here,
we'd
just
have
a
very
simple
markdown
message:
saying:
hey
author:
the
package
and
test
job
has
failed
with
links
to
the
pipeline
and
the
package
and
test
Pipeline
and
then
instructions
to
paying
the
software
and
test
or
software
engineering
test.
C
So
that's
what
this
merger
Quest
does
and
that'll
happen,
I
think
on
every
failure,
which
is
good.
So
if
it
you
know
if
it's
flaky,
we
missed
it.
The
first
time
it'll
it'll
still
comment
the
second
time.
The
other
merge
request
is,
let's
see.
C
Using
the
bot-
and
so
this
runs
very
much
like
the
approval
message
that
you
see
when
you
first
approve
an
MR
and
it
kicks
off
the
new
pipeline.
This
is
kind
of
the
same
idea,
so
let's
go
to
the
actual
class,
and
actually
we
don't
need.
C
So
in
this
one,
all
we're
doing
is
saying
that
when
the
target
branch
is
a
stable
branch
and
it's
coming
from
gitlab
and
we
skip
certain
file,
changes
like
Doc
changes
and
things
like
that
and
this
as
long
as
this
comment
hasn't
been
posted.
Previously,
we
go
ahead
and
post
this
comment,
which
notifies
the
approver
and
says
thanks
for
approving
this
is
the
first
time
it's
approved.
Please
make
sure
that
the
package
and
test
job
has
succeeded.
C
I
think
the
only
thing
I
don't
like
about
this
is
the
person
that
approved
is
like
okay,
I,
just
approved
I'm
done,
and
then
it
pings
them
and
says:
hey
keep
an
eye
on
this
test
that
is
still
running
possibly
or
that's
going
to
run,
and
so
I'm
not
sure
about
that
as
being
the
best
best
way
to
notify
someone,
but
was
curious
about
your
overall
thoughts
on
on
both
of
those.
C
Web
no
I
think
this
is
a
hook.
This
is.
A
D
A
Relatively
yeah,
it
is
the
same
experience
as
when
I
program,
any
any
other
merch
requests
on
the
GitHub.
D
A
D
Yeah,
that
was
my
follow-up
question
then,
which
is
how
is
the
so
the
the
package
and
test
is
a
manual
job?
Isn't
it
not
on
the.
D
C
D
The
stable
Branch
every
single
commit
will
run
it
even
if
you
Skip,
rebasing
and
adding
stuff
okay
I
thought
we
were
there
was
this
concern
from
quality
about
the
load
of
this,
and
so
that
they
they
wanted
to
have
this
always
manual
yeah.
C
D
D
C
And
since
I
mean
I
guess
the
the
main,
the
main
reason
behind
all
of
this
is
that,
even
though
the
packaging
test
runs,
it
is
allowed
to
fail.
So
the
idea
is
we
want
to
raise
awareness
that
that
hey,
you
know,
potentially,
you
could
still
merge
this,
but
we
need
to.
We
need
someone
to
check
the
failure.
If
there
is
one.
D
Because
I
was
going
to
say
what
is
the
actionable
items
for
for
the
maintainers?
So
probably
just
maybe
we
want
to
post
a
discussion
instead
of
a
message,
so
that
is
it
kind.
It
prevents
the
merging
right
so
yeah.
D
So
it's
kind
of
now
there's
an
extra
step
because
I'm
trying
to
to
get
into
the
the
workflow
of
a
maintainers
right.
So
your
maintainers.
This
is
all
new
to
you.
You
look
at
the
things
it
looks.
Good
pipeline
are
still
running,
but
yeah
I'm
gonna
do
merge.
One
pipeline
approves
right
because
it
kind
of
feels
like
I'm
I'm
doing
right,
but
here
there's
an
extra
step,
which
is
that
job
will
run
May
Fail,
but
it
has
to
be
green
in
order
for
you
to
merge
right.
D
D
Yeah
now
because
say,
if
you
set
merge
when
pipeline
succeeded,
then
you
open
a
discussion.
I
think
it.
The
GitHub
will
reevaluate
the
merge
ability
of
the
merge
request
at
merge
time,
so
it
will
will
be
prevented.
So
in
that
sense
it
feels
more
actionable
right.
So
that's
kind
of
you
open
a
discussion
and
you
close
it
when
the
package
is
the
the
test
is
green.
C
Right,
okay,
so
I
think
then,
yes,
keeping
both
comments
makes
sense.
This
one
we
can
open
as
a
discussion
so
that
it
forces,
because
you
know
this
is
right
after
the
first
approval.
So
then
the
maintainer
gets
assigned,
and
then
they
will
see
this
very
quickly
when
they
start
reviewing.
C
And
then
the
other
one
that
only
pings
on
a
failure
that
one
we
might
still
want
to
keep
as
a
comment,
because
if
we
run
the
mer
like
if
we
set
immersion
like
when
succeeds-
and
we
know
it's
going
to
fail-
we
don't
want
it
to
start
a
discussion.
That's
going
to
stop
the
merge,
so
I'll
keep
this
one
as
a
comment.
A
C
D
A
C
So
yeah
well
I,
guess
the
scenario
I'm
imagining
is
it
fails?
The
engineering
test
says:
hey
that
failure
is
fine.
We
can
merge
it.
So
then
the
like
all
the
discussions
get
resolved.
The
maintainer
starts,
a
new
pipeline
hits
merging
pipelining
succeeds
and
then
this
gets
posted
again
as
a
new
discussion,
because
package
and
test
fails
and
then
that
stops
the
merge,
because
it's
an
unresolved
thread
mm-hmm.
A
Yeah
I
can
see
how
there
might
be
different
parts,
but
there
is
also
a
bit
hard
to
imagine
all
these
scenarios.
So
I
am
also
thinking
that
we
can
leave
both
comments
and
leave
them
as
discussions.
And
then
we
can
gather
feedback
on
the
internal
testing
that
we
are
going
to
do
and
if
it
turns
out
to
be
so
very
nosy
and
not
a
very
productive
workflow,
we
can
readjust.
C
C
D
Would
also
say,
oh
sorry,
I
would
also
say
something
that
the
the
this
new
message,
the
one
for
the
author.
It
should
not
be
allowed
to
fail
because
that
job
runs
only
on
failure.
So,
if
that,
if
that
discussion
being
created,
is
the
only
thing
that
prevents
the
thing
to
be
merged,
then
in
case
for
any
reason,
you
can
you're
going
to
generate
a
message
because
it
failed
right.
So
if
you
can't
generate
the
message,
it
should
fail.
The
pipeline.
B
C
No
I
think
yeah
I
think
we'll
see
what
happens.
I
suppose
with
the
I
think.
The
only
one
that
I
was
concerned
about
is
the
one
that
comments
on
a
failure
if
we're
merging
knowing
that
a
failure
is
going
to
happen
or
sorry
if
it
opens
a
discussion
on
a
failure,
but
we
know
a
failure
is
going
to
happen.
A
But
it
is
also
very
easy
to
fix,
like
you
just
need
to
solve
the
threat
and
then
the
March
request
can
be
merged.
A
D
The
pipeline
received
a
failed
pipeline
notification.
I
think
so,
if
say,
you
are
the
author
of
the
merge
request
and
it
failed
on
your
merge
request.
Then
you
get
the
email
and
the
to
do
items
that
the
pipeline
failed.
But
if
you
are
the
maintainer
and
you
see
I'm
approving
I'm
rerunning
the
pipeline,
because
I
has
been
a
long
time
so
I
want
to
rerun
before
and
then
approve.
In
that
case,
the
notification
should
should
be
received
only
to
the
to
the
to
the
maintainers
that
owns
the
pipeline.
D
But
then
we
have
the
message
that
Steve
made
in
the
first
merge
request
that
will
notify.
Also
the
author.
C
D
A
A
And
then
the
outdoor
has
to
ping
someone
else,
I,
don't
think
this
is
a
problem
that
we
are
going
to
solve
exclusively
for
Target
branches,
because
it
is
already
present
on
other
type
of
merge
requests
since
pipelines.
They
considerable
considerable
long
time
to
execute
and
people
can
comment
and
Etc.
We.
D
Really
worth
to
actually
rerun
the
pipeline
as
a
maintainer,
unless
you
have
because
the
the
widget
tells
you
how
how
many
commits
you
are
behind.
So
unless
you
are
actually
behind
well,
the
the
pipeline
result
will
be
the
same.
B
So
I
guess
like
what's
the
safest,
what's
the
what's
the
option
that
we
are
confident
catches
all
the
gaps,
even
if
it
possibly
ends
up
being
noisy
because
I
think
that's
an
easier
position
to
gather
feedback
and
adjust
from?
Is
that
having
them
as
both
as
discussions.
C
B
A
You
so
there
have
been
some
discussions
about
the
maintenance
policy,
rollout
plan
and
I
wanted
to
share
them
with
you.
So
we
are
all
on
the
same
page
and
for
you
to
be
aware
of
this,
so
the
maintenance
policy
itself
is
going
to
be
extended
on
the
16th,
a
major
release,
because
from
the
product
side
it
works
better.
A
We
are
going
to
have
a
dedicated
patch
release
on
the
16th
for
16,
15,
11
and
1510,
so
that
will
bring
our
active
versions
in
par
or
with
the
Align,
with
a
new
maintenance
policy
and
also
starting
with
15.10
Engineers
are
going
to
be
able
to
merge
into
stable
branches,
and
this
is
basically
together
early
feedback
on
tools
and
processes,
and
this
does
not
modify
the
maintenance
policy
so
far
because
release
managers
are
going
to
only
do
patch
releases
for
the
current
active
person,
which
in
that
case
it
would
be
1510
or
15
11.
A
and,
of
course,
since
this
is
a
big
change
for
all
of
us,
not
only
for
gitlab
users,
but
also
for
people
of
customers.
The
plan
is
to
have
recurrent
reminders
and
announcements,
internal
and
external
throughout
1510
and
1511
and
yeah.
There
are
a
lot
of
more
details
in
the
issue,
but
yeah.
This
is
basically
something
very
summarized.
A
No,
no,
it
will
be
kind
of
switching
to
the
new
process
because
we
are
going
to
open
up
stable
branches,
but
it
will
be
well
yes,
people
can
will
be
able
to
merge
into
stable
branches,
but
patch
releases
will
only
be
done
for
the
current
stable
version.
So
we
are
on
the
15.10.
B
B
I,
don't
think
we
only
have
the
option
of
it
being
a
patch
release
right
after
the
22nd
I
think
we
should
consider
what
other
options
we
have
for
Gathering
up
those
fixes,
and
then
we
yeah,
we
will
surely
get
exception,
requests
or
yeah
we'll
be
doing
security
releases,
or
you
know
it
might
just
be
worth
figuring
out
like
what
are
the
options
and
how
can
we?
How
can
we
handle
like
what
what's?
What's
the
easiest
way
to
do
it.
D
Basically,
yeah
a
good
point:
Amy
that
I
wasn't
thinking
about
the
series
releases,
so
they
will
start
merging
things,
but
then
the
First
Security
releases
that
came
in
will
ship
those
changes,
which
is
a
side
effect
that
is
expected
by
this
extension,
because
we
said
it
goes
in
the
direction
of
allowing
security
releases
to
also
include
bug,
fixes
which
was
agreed
upon,
and
but
this
as
soon
as
we
open
the
stable
branches.
This
will
affect
the
security
releases.
D
B
And
we
will
do
so.
The
the
next
AMA
is
on
the
15th
of
March.
B
We've
just
moved
it
back
one
week,
just
because
McKellar
and
I
are
both
out
on
the
8th,
but
that
actually
Times
Really
nicely
with
lining
up,
but
one
week
before
1510,
so
we'll
also
theme
that
around
the
maintenance
policy
extension
exclusively
be
that
but
yeah
one
we
announce
things
and
share
process
changes.
We
can
also
encourage
people
to
come
chat
to
us
in
our
Ama.
B
Cool,
do
you
need
anything
for
the
rollout
planning,
Myra.
A
Not
I
am
basically
keeping
an
eye
on
all
the
conversations
and
trying
to
put
together
all
the
pieces,
so
we
can
have
a
solid
plan.
It's
a
lot
of
collaborations
and
yeah
I
am
discussing
this
with
some
regarding
the
timing
of
the
dedicated
patch
release
for
the
maintenance
policy,
and
also
how
can
we
do
the
announcements
and
we
are
thinking
also
of
doing
a
blog
post,
some
ideas
to
publicize
this.
B
Awesome
sounds
good,
sounds
good
and
if
it
feels
like
there's
a
lot
going
on
there
don't
forget
this
is
going
to
take
place
over
a
few
months.
So
as
long
as
we
have
everything
we
need
for
the
1510
step,
we're
in
a
good
place,
and
it
gives
us
another
month
to
get
everything
ready
for
the
1511
step.
So
we
made
like,
for
example,
the
the
actual
patch
release
or
whatever
we
do
on
16.0.
We
don't
need
to
know
all
the
details
for
that
right
now,
because
that
will
be
in
a
few
minutes.
D
I
have
a
question
so
did
we
found
an
agreement
with
upsec
on
how
to
manage
the
bug
fixing
yeah
about
to
manage
the
blog
posts
for
bug,
fixes
included
in
series
releases
because
they
do
the
blog
posts
themselves?
But
in
that
case,
how
will
they
know.
B
D
A
D
I
will
I
think
would
be
better
from
us
if
we
start
with
a
proposal
more
than
a
discussion
right,
so
something
that
is
easier
because
they
are.
They
do
love
manual
things
and
also
automated
things,
but
because
we
invested
in
the
automation
for
this,
probably
we
should
try
to
give
them.
We
have
this.
We
can
generate
this.
How
can
you?
How
can
we
then
provide
this
information
to
you
right
so.
B
Just
stick
it
as
a
section,
so
maybe
we
can
almost
just
generate
them
that
section
so
I've
just
linked
one
that
had
a
bunch
of
non-security
fixes
in
I
assume.
This
is.
A
There,
how
are
you
visualizing
this
unless
you're
like
people
merging
into
stable
branches
and
then
the
security
list
comes
in
and
then
we
say
there
is
a
step
somewhere
in
the
security
template
when
we
say
to
observe
hey.
These
are
the
bug
fixes
that
should
be
on
the
blog
post?
Is
that
I
am
getting
your
idea?
Yeah.
D
Something
like
this
right,
so
what
I'm
thinking
is
that
mirroring
will
be
in
place
up
until
we
start
merging
the
security
things
right.
D
So
basically,
if
we
run
the
blog
post
generation
before
starting
merging,
we,
our
automation
with
working
on
the
canonical
repo,
will
find
all
the
commits
that
the
that
were
merged
there
and
produce
some
sort
of
a
blurb
that
we
can
send
them
and
say
yeah,
that's
the
extra
content,
because
then,
as
soon
as
we
have
this,
we
start
merging
and
then
we
will
break
mirroring,
and
so
no
extra
things
can
get
into
the
release.
B
A
A
B
Does
this
conflict
with
other
stuff
so
we're
about
to
go
into
the
next
Night
round
of
releases
right.
A
Yeah
I,
don't
think
so,
because
we
are
choosing
stable
branches
that
are
outside
of
the
policy.
So
I
shouldn't
interrupt
with
any
current
work
in
progress
about
releases.
B
Oh
okay,
great
I,
could
say
I
feel
like
this
is
the
step
that
has
the
most
likely
impact
on
the
next
sort
of
three
or
four
weeks
of
planned
work,
because
what
we
discover
here
may
be,
maybe
we
discover
something
huge
and
we
aren't
ready
for
every
step
to
adopt
this,
or
maybe
we
just
discover,
there's
some
other,
like
use
case
things
that
we
want
to
make
sure
we
highlight
in
our
comms
to
developers
or
release
managers,
so
I
think
getting
through
this
internal
testing
step
will
basically
give
us
all
the
information
we're
going
to
need
for
the
next
few
weeks.
A
B
So
how
confident
are
you
feeling
about
I
guess
up
about
the
rollout
to
developers
so
for
the
kind
of
beta?
How
confident
do
we
feel
that
we've
got
everything
sorted
out
on
our
side
and,
like
we've,
thought
of
all
the
you
know
edge
cases
and
things
like
that
and
that
we're
ready
for,
like
every
Stage
Group
to
start
using
this.
A
I'm
feeling
considerably
confident
from
my
perspective,
we
need
to
ensure
that
our
tooling
is
working
as
it
used
to
be
with
the
internal
testing.
We
really
need
to
do
some
announcements
to
developers
to
make
sure
that
they
know
about
this
process
and
I'm
excited
about
this,
because
it
will
gather
feedback
about
the
process
and
things
that
we
can
improve.
A
B
So
five
I
I'm
gonna
suggest
we
drop
once
we
got
the
new
retro
actions,
but
since
that's
all,
may
we'll
go
through
them.
Does
anyone
have
any
additional
collaboration,
requests
that
I
need
in
the
next
week
or
so.
B
I
would
say
just
the
only
thing,
I
think
Alessio,
you
might
not
be
affected,
but
Steve
just
in
case
you
are,
as
you
go
into
release
Management
on
Thursday
do
expect
that
that
will
be
100
of
your
time.
Hopefully
it
won't
but
anticipate
it
will
and
get
all
the
things
either.
You
know.
Stick
an
update
on
issues
like
pause.
B
On
those
like
hand,
those
back
to
Myra,
if
they're
still
outstanding
work
right,
like
maybe
you
can
do
other
stuff
as
well,
but
I
think
at
least
for
the
first
week
or
two,
it's
safer
to
assume
that
you
won't
have
any
extra
capacity.
Definitely
oh
and
Alessia,
and
I
actually
chatted
about
this
morning.
At
the
other
thing
which
I'll
just
share
in
this
demo,
we
are
entering
a
period
of
extraordinary
low
capacity
in
our
team.
B
So
do
just
be
aware
of
this,
so
obviously
with
Steve
Alessio
U2
in
release
management
I'm,
assuming
that's
going
to
take
up
100
of
your
time
for
the
next
Milestone,
so
Myra
yeah.
Hopefully,
you'll
still
have
people
to
give
you
reviews,
but
we
may
also
need
to
lean
on
Reuben
as
well.
If
you
know,
if
you,
if
you
do
need
reviews
to
come
through,
we
do
also
have
Graham
around.
B
He
will
be
a
little
bit
involved,
of
course,
with
some
of
the
release
management
tasks,
but
he
is
also
here
now.
I
do
know
that
Graham
has
a
ruby
task
coming
up
in
the
releases
work,
but
he's
aware
that
it's
going
to
have
to
just
queue
up.
It's
like
third
priority
behind
release
management
and
maintenance
policy,
so
I
think
he
is
going
to
put
it
on
the
board
when
he's
ready,
but
we'll
have
to
just
pick
that
up
when,
when
we
get
time
in
amongst
our
other
projects,.