►
From YouTube: 2023-07-19 - Delivery:Orchestration demo - APAC/EMEA
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
B
B
Contacts
actually
so
I
guess
I
made
this
recording.
So
this
is
a
alternative
and
probably
more
of
a
longer
term
solution
for
syncing
the
repositories
at
the
end
of
the
security
release,
using
an
MR
to
bring
everything
back
together
versus
the
merge
train,
which
we
tested
out
last
month,.
A
Okay
and
now
I'm
going
to
live
stream
I'm
in
order
to
share
screen
screen
share
okay,
okay,
so
let
me
reorganize
my
window.
This
is
so.
What
are
we
looking
at
here
on
the
right
side?
This
is
my
GDK
installation
running
and
here
I'm
logged
in
as
myself.
A
A
Impersonate,
what
we
see
here
down
below
is
the
triage
Ops
running
on
my
machine
with
the
changes
are
in
a
merge
request,
but
I'm
running
them
locally
because
they
are
not
merged
yet
so,
okay,
now
here,
I
am
in
the
bot
okay.
So
let
me
see
what
we
can
do
so
back
to
my
regular
user
on
this
installation.
This
is
the
gitlab.
This
is
a.
This
is
a
fake
gitlab,
canonical
repo.
A
So
everything
is
here
is
just
what
we
normally
do
and
then
there
is
security
mirror
so
security,
not
this
research
thing
yeah.
So
there
is
a
security
mirror
that,
as
we
can
see
here,
is
Fork
from
the
canonical
one
and
is
up
to
date
with
the
Upstream
repo.
Now,
because
I
don't
have
all
the
automation
to
do
a
security
release
here,
I
will
just
use
the
web
IDE
and
make
a
change
just
a
regular
change,
so
web
ID
in
adding
a
file
so.
A
A
Well.
If
we
get
back
to
the
project
now
we
see
that
this
is
the
security
repo
that
is
forked
and
is
one
commit
hi-hat
from
Upstream
repo.
So
this
is
a
diverging
situation.
Basically,
is
what
we
have
since
we
start
working
on
the
security
release,
because
we
start
merging
fixes
and
the
history
diverged.
Now
we
fast
forward
at
the
end
of
the
security
release,
everything
is
being
deployed
and
tested.
A
A
Correct
yeah
yeah
correct,
so
basically,
what
we
see
here
is
that
we
are
creating
a
merge
request
from
the
security
repo
Master
Branch
into
the
canonical
repo
Master
branch
and
basically,
what
I'm
expecting
here
if
the
demo
is
still
working,
is
that
as
I
create
this,
the
triage
Ops
will
intercept
the
creation
of
the
merge
request,
leave
a
message
saying:
I
approve
this,
because
this
is
a
security
to
canonical
Master
Sync
and
then
react
to
the
approval
and
set
the
auto
merge.
A
A
C
A
So
what
I'm
going
to
do
is
going
here
on
the
regular
gitlab
canonical
repo
I'm,
going
to
create
a
merge
request
still
using
the
web
IDE.
A
I
just
yeah:
let
me
try
if
I
can
make
it
see
patch
I
hope
it
gets
the
right
message.
In
any
case,
it's
just
a
message
so
I'm
going
to
create
a
merge
request.
A
Yes,
it
did
okay,
so
this
is
a
merge
request.
I'm
going
to
create
just
not
writing
anything
else.
Just
want
my
drugs
to
be
here
and
now
what
I'm
gonna
do
I'm
moving
I'm
moving
to
the
bot
account
here
and
I'm
kind
of
impersonating,
a
malicious
user
that
took
control
of
the
bot
and
wants
to
approve
something
that
is
outside
of
policy.
A
So
what
we
go
I
go
here,
go
to
merge
requests.
I
will
find
this
and
basically
oh.
This
is
nothing
that
I
care.
I
will
approve
it
as
the
bot
as
we
can
see
it,
just
up,
approved
and
removed
immediately.
So
if
we
go
down,
we
see
the
trash
bot
approve
this
merge
request
and
then
the
automation
kicked
in
an
unapproved,
immediately
and
left
this
discussion
open
that
also
the
discussion
itself
prevent
emerging
from
happening.
Not
only
the
removal,
and
here
we
can
change
the
the
message,
also
painting
someone.
A
B
And
so,
where,
on
that
message
says
it
outside
of
the
allowed
policies
where
are
those
where
are
those
policies
like
captured?
Is
that
the
code
owner's
file,
yeah.
A
A
Basically,
there
are
those
concept
of
processors
which
are
a
simple
file,
we're
going
to
say
when,
when
the
this
piece
of
code
should
react
to
something
happening
on
github.com,
so
in
in
this
merge
request,
which
is
what
we
were
looking
at
in
the
demo,
we
are
introducing
two
we're
introducing
the
concept
of
delivery
processors,
where
we
can
put
everything
we
we
code
and
basically,
we
have
to
processors,
so
the
first
one,
let's
see
if
I
can
maybe
just
make
it
bigger,
which
is
okay,
so
basically
the
first
one
is
this,
which
is
the
the
regular
operation?
A
No
not.
This
is
not
the
sorry
security
this
one.
This
is.
This
is
a
proving
security,
sync,
okay,
so
it
reacts
to
opening
our
an
approving
in
general.
So
everything
that
when
we
open
a
merge
request
or
if
we
remove
approvals,
removing
approvals
is
because
first
maybe
we
have
a
synchronization
issues
because
we
may
have
a
conflict,
and
so
we
do
the
the
opposite
operation,
which
is
fixing
the
mirroring,
as
we
do
with
the
regular
security
release.
A
This
will
generate
a
new
commit
on
security
master
and
by
the
settings
of
the
project,
we'll
just
remove
approval,
and
so
this
will
re-engage
and
make
sure
that
the
the
that
everything
is
still
approved.
But
basically,
what
happens
here
is
this
if
this
event
is
coming
from
GitHub
org
namespace-
and
this
is
coming
from
a
security
Fork
and
the
source
branch
is
master
and
the
target
branch
is
main
or
master.
So,
basically,
everything
has
the
highest
level
of
approval
already
applied,
because
we
have
code
owners.
We
have
upsec
reviewing.
A
B
A
A
So
let
me
remove
this
comment
here,
so
this
reacts
simply
to
approvals
of
any
kind,
but
then
engage
only
if
it's
a
gitlab
org
namespace
a
project
in
the
GitHub
org
namespace,
and
if,
if
the
approval
is
coming
from
gitlab
bot,
so
it
only
reacts
to
gitlabot
and
then,
when
it
processes
the
things
it's
doing
this
check
again.
So
if
it's
a
security,
Fork
it's
coming
from
a
security,
four
Source
branches,
Master,
Target,
branches,
main
or
Master,
then
is
merging.
So
it's
the
happy
path.
Everything
is
working
as
expected,
we're
merging.
A
Otherwise
someone
is
abusing
the
bot,
and
so
this
is
the
thing
we
were
leaving
the
message
and
we
are
unapproving.
So
that's
so
this
is
the
the
policies.
This
is
this
control
here,
basically
right
so
and
if
we
ever
end
up
expanding
the
policy,
this
is
the
place
to
own
it
right,
because
this
is
where
we
react
to
those
approvals.
B
And
just
to
actually
have
a
couple
questions,
so
first
one
is:
are
these?
Is
this
the
first
time
that
we
have
used
anything
along
this
line
with
these?
These
processes?
Is
this
like
a
brand
new
approach.
A
As
delivery
guess,
because
we
always
implemented
everything
in
release,
tools
or
merge
strain,
so
the
the
closer
think
this
is
the
gitile
version
bump
and
the
easily
version
bump
is
entirely
developed
in
release
tools
and
it
probably
suffers
some
of
the
issues
where
sometimes
it
gets
stuck
that
maybe
a
reactive
approach
like
this
one
could
solve.
But.
A
A
A
A
Sense,
on
the
other
hand,
so
company
wise-
we
are
using
this
quite
a
lot
and
for
I
see
more
complex
workflows
than
the
one
we're
doing.
I
think
this
is
the
first
time
we
are
implementing
a
merge
operation
in
here.
So
that's
the
novelty
but,
for
instance,
appsec
is
using
this
to
track
upset
approvals
on
community
contributions.
A
Okay,
so
the
it's
trying
to
it's
basically
implementing
custom
complex
workflows
on
top
of
the
regular
workflow,
so
it's
mostly
working
with
labels
reacting
to
adding
labels
reacting
to
if
the,
if
someone
from
appsec
approves
something,
then
I'm
putting
a
label
say
that
it's
been
approved
by
upsec.
But
if
someone
changed
something
that
is
approved,
it
removes
the
approval
so.
A
Of
this
type
of
interaction,
our
workflow
is
simpler
because
we
are
coming
from
a
very
specific
Branch
to
Branch
project,
to
project
relationship
where
everything
is
being
pre-approved
and
deployed
actually
also.
So
we
are
it's
it's
simpler
in
that
contest,
but
we
are
introducing
this
anti-abuse
mechanism,
which
I
think
is
very
useful.
B
Okay,
yeah
and
then
just
one
other
question,
so
where
did
you
originate?
The
Mr
from?
Is
that
originating
off
the
security
repo?
Is
that
where
you
open
up,
if
you
go
there,
yes,
I.
A
B
Never
opened
it
videos
online
you're
wondering
is
so.
Let
me
just
get
straight,
so
this
is
the
triage
op
spot
operating
in
the
security
repo.
No.
A
B
Challenge,
could
it
be
in
the.
A
A
B
Think
what
I
was
actually
asking,
what
I
was
actually
thinking
more
about
is
just
how
many
activities
does
the
triage
Ops
bot
do
with
more
what
I
was
wondering
about
because
I'm
just
wondering
given
we
are
reusing
this
bot,
whether
we
are
going
to
won't
answer
it
here,
of
course,
but
that's
probably
another
question
compliance
may
have,
which
is
just
going
to
be
when
they
come
to
audit
these
events.
B
A
A
Oh,
that's
interesting
though
we
are
no
that's
interesting,
so
we're
using
the
bot
for
approving
things.
What
are,
but
these
are
all
the
old
ones:
yeah,
okay,
good
good.
Okay,
so
we
used
to
use
the
get
lab
Bots
to
approve
Gita
Lee
version
bumps
I'm,
going
trying
to
filter
those
out
to
see
if
there
are
others
so
before
using
project
access
token
for
digital
version
bump.
We
use
this
bot.
A
When
then
there
was
a
situation
where
this
token
was
rotated
and
we
decided
to
move
away
from
this
token,
but
this
was
before
introducing
code
owners.
Now
this
Expo
then
now
this
we
have
another
problem
with
the
Gateway
version
bump
that
project
access
token
create
a
fake
user
actually
and
when
the
token
expires,
the
fake
user
is
the
is
deleted.
So
now,
when
in
10
months
time
from
today,
the
our
token
will
expire,
we
will
also
have
to
update
the
the
code
owner's
file.
So
this
is
not
a
problem,
but
so
okay.
B
But
in
today's
world
that
the
bot
isn't
actually
doing
any
approvals.
Okay.
A
Yeah
three
years
ago,
one
I
mean
this
is,
let's
do
the
sort
by
created
date
Okay
so
one
year
ago,
okay,
fine,
okay,
that's.
B
Okay,
then
so.
A
B
Yeah
so
my
assumption.
B
B
C
C
B
And
this
is
just
game
like
last
on
the
last
security
release,
we
tested
doing
this
sync
with
the
merge
train
which
did
work,
but
it's
probably
not
a
long-term
solution,
because
once
once
things
scale
up,
we
won't
be
able
to
probably
get
a
a
clear
shot
at
the
master
branch
on.
B
Oh
yeah
he's
probably
overheated
he's
buying
until
like
mid-morning
cool,
so
hopefully
we'll
be
able
to
test
that,
hopefully
Alessio
would
rejoin
I.
Think,
probably
right
now
the
biggest
uncertainty
is
going
to
be
I
know.
Alessia
is
talking
with
compliance
about
whether
this
approach
will
be
like,
like
compliant.
C
So
is
the
plan,
then
this
new
approach
will
be.
It
will
open
an
MR
on
canonical
and
then
basically
like
or
more
or
less
set
it
to
merge,
but
because
we
kind
of
had
DMR.
We
then
get
notified
a
bit
easier,
a
bit
cleaner
if
there's
conflicts
and
also
testing
and
like,
rather
than
just
trying
to
cram
stuff
back.
C
C
B
I
guess
no,
that's
what
Alessia
is
hoping
to
avoid
I.
That
would
have
been
one
question
I'd
ask
about.
If
he
comes
back,
which
is
the
I
think
the
challenge
we
have
is
I,
don't
believe,
there's
anyone
delivery
who
could
approve
this?
B
Yes
and
that's
the
challenge
is
the
the
delay.
But
given
these
things
of
oh,
this
kind
of
irascia
has
been
thinking
about
it's
like,
given
that
these
are
all
changes
that
have
all
been
approved
by
maintainers.
B
They're,
just
things
coming
out
of
security,
because
yeah
I
in
an
Ideal
World.
If
someone
in
delivery
could
approve
this
and
we
could
merge
it,
that
would
actually
be
the
most
simple
process
in
the
world.
But
that's
what
Alessia
is
hoping
to
cut
down
on
that
that
delays?
It's
just
an
automated
sync.
B
A
Back,
did
you
explain
anything
to
brains,
I
think,
right,
I.
C
B
A
A
This
one,
so
let's
get
what
it
was.
B
A
Message,
yeah
yeah,
so
the
problem
is
that
we
want
to
have.
We
need
a
fast
pipeline
which
is
somewhere
here.
We
need
a
fast
pipeline,
we
need
the
automation
to
approve
and
then
we
need
the
code
owners.
Otherwise
the
approval
is
we
can.
We
cannot
merge
so
in.
In
this
context,
the
us
pipeline,
which
is
here
which
is
almost
there
I,
mean
in
theory,
has
all
the
approval
needed,
but
the
he
decided
to
go
to
an
extra
maintainers.
A
So
basically,
we
already
have
two
approvals
which
are
more
enough,
but
they
decided
to
take
the
third
one.
So
if
this
lens,
we
can
still
try
it,
even
if
we
don't
judge
it
back
this
way,
it
will
still
be
interesting
to
test,
because
this
one
come
on.
Yeah
I
I
can
stop.
A
Sharing
I
mean
my
connection
is
terrible,
so
basically
we
will,
we
will
very
like
we
will
likely
be
able
to
test
the
merger
request
itself,
even
though,
if
we
may
not
merge
it
by
using
that
merge
request,
and
so
this
gave
us
validation
of
the
fast
pipeline,
then
we
may
or
may
not
be
able
to
test
the
triage
but
to
approve
things,
even
though,
if
the
approval
may
not
be
enough
to
merge
and
so
I,
don't
think
we
will
have
the
the
code
owners
changed
in
time
that
that's
the
thing
is
now
I'm.
A
Writing
the
outdoc
access
request
and
I'm
trying
to
Gap,
because
I've
been
asked
by
compliance
to
write
this
other
access
request,
exception,
or
something
like
this,
so
I'm
trying
collecting
evidences
of
what.
What
are
the
current
permission
right
now,
what
we
are
asking,
what
we
are
doing
and
why
we
are
doing
those
things
right,
so
just
because
there's
there
should
be
I
think
what
they
want
to
do
out
of
this
is
kind
of
making
a
plan
for
reviewing
both
permissions
and
actions
yeah.
A
B
So,
okay,
so,
in
which
case?
Could
you
admirer
make
a
bit
of
a
plan
for
what
we
want
to
do
for
the
next
security
release?
Because
we've
got
the
merge
train?
We
know
it
works,
but
it's
not
really
a
fully
fledged
solution,
but
it
would
be
very
good
to
have
like
it
would
be
good
to
know
a
kind
of
like
scoping
of
of
this
problem,
because
so
that
we
don't
spend
sort
of
too
long
trying
to
Implement
something
about
sinking.
B
So
it's
kind
of
a
if
you
admire
always
Steve
next
week,
but
let's
figure
out
what
we're
going
to
do
for
the
next
security
release
and
then
actually
work
out
like
like.
Maybe
like.
Is
there
any
way
of
testing
this,
for
example,
without
having
the
bot
doing
the
approvals.
A
Well,
against
what
we
want
to
attest
right,
so
a
couple
of
examples,
so
I
was
hoping
to
have
the
pipeline
merged
today
it
didn't
happen,
so
it's
probably
gonna
be
tomorrow.
Hopefully,
so
this
will
already
give
us
some
opportunities
of
testing,
because
we
can
always
create
an
empty
commit
on
the
security
mirror
and
test
the
the
mirror
just
making.
A
The
merge
request
manual
just
verify
that
the
pipeline
is
actually
working
and
things
like
that
and
that's
a
test,
and
there
is
another
thing
that
I
think
that
is
important
to
test
in
the
security
release
itself,
which
is
so,
if
you
make
a
merge
request,
so
we
can
make
the
merge
request
like
we
want
this
to
be
right.
A
So
the
fast
pipeline
merge
request,
even
though
we
don't
have
the
bot
with
the
permission
to
approve
or
things
like
that,
if
merge
strain
is
merging
manually,
that
merge
request
will
be
marked
as
merged
in
the
UI
as
well,
because,
basically,
this
is
how
the
the
software
behaves
if
you're,
if
someone
merged
manually,
something
that
is
also
a
merge
request,
gitlab
is
able
to
detect
and
update
the
merge
request
accordingly.
So
it's
kind
of
give
us
something
more
to
show
compliance
like
so
with
the
say.
A
A
No
that's
the
problem,
so
I
was
it
depends
on
the
content
of
the
security
list.
That's
that's
the
real
challenge,
because
when
we
enabled
code
owners
it
was
only
star
rule,
so
everything
can
be
approved
by
any
maintainer
Plus
delivery.
A
So
it
was
except
for
the
code
owner's
file
itself.
That
has
I
think
enduring
leadership.
Something
like
this.
So
we
usually
don't
change
code
owners
in
security
list,
so
we
could
have
approved
manually
and
merge
it.
But
re
I've
said
recently:
I,
don't
know
when
it
happened.
Basically,
some
Stage
Group
changed
their
optional
approvals
into
mandatory
approval,
and
so
if
the
security
release
touches
one
of
those
files,
we
need
a
code
owner
from
that
Stage
Group.
B
Okay,
that
makes
sense:
okay,
okay,
so
how
about
then
next
week
we
make
sure
we
have
a
plan.
Perhaps
we
could
use
actually
next
week's
demo
so
that,
because
Steve
I
believe
is
a
release
manager
is
that
right.
B
In
the
next
demo,
we
can
see
how
far
you've
got
and
work
out
what
the
plan
is
for
the
next.
The
next
release.
A
A
I'm.
Writing
right
now.
It's
it's
a
bit
complex
process
because
you
have
to
gather
evidences.
You
have
to
explain
what
you're
doing
it's,
not
the
regular
access
request.
It's
it's
a
different
one:
yeah
cool,
okay,.
B
Okay,
great
awesome,
any
other
questions
on
that
Graham
nope
awesome
great
stuff,
so
let
me
see
actually
I'm
going
to
switch
these
around
because
we
could
do
the
okay,
our
stuff,
more
racing,
so
Graham
I'll
hand
over
to
you
for
the
next
discussion
item.
C
Yeah
so
after
gosh
I've
kind
of
lost
track,
which
major
incident
we've
had
recently,
but
one
of
the
major
incidents
we've
had
recently
I
think
Auto
deploy
was
paused.
You
know
it's
going
to
look
at
unpausing
them
and
when
I
went
to
the
release
tools,
repo
on
Ops
and
went
to
the
CI
scheduled
jobs,
I
mean
I
could
show
you
the
screen.
Actually,
basically,
it
looks
different
now
the
jobs
all
look
different
and
which
is
fine
and
it's
great,
obviously
something's
changed.
C
C
Yeah
so
I
think
we
there
used
to
be
like
a
pick
and
all
of
these.
A
C
C
C
A
B
But
I
would
also
add
on
to
this
that
actually,
the
borderless
here
is
not
mentioning
it's
all
the
work
he
did
to
actually
speed
up
things
so,
as
she
Graham
I
would
say.
That
probably
now
is
a
really
good
time
to
actually
us
to
stop
doing
so
much
hand-holding
on
things
like
it's.
C
C
B
C
B
A
C
C
B
Is
also
I
think
a
slightly
interesting
I
know
it's
good
not
to
waste
resources,
but
also
I
think
that
yeah,
if
something
isn't
going
to
go
beyond
the
broken
environment,
then
sometimes
it
may
just
be
less
work
to
just
allow
the
automation
to
continue,
and
we.
A
Can
do
an
an
easy
soft
pose
it's
very
simple,
to
implement,
because
basically,
the
timing
is
determined
by
an
environment
variable
in
the
project
that
is
giving
the
it's
the
list
of
hours.
So
if
we
do,
our
soft
pose
chat,
UPS
command
whatever
it
is
that
replace
that
variable
with
an
empty
list?
It
will
never.
C
A
This
gives
power
into
the
hands
of
developers
because
they
can
pick
whatever
they
want,
and
but
it's
so
it
can
be
useful
for
reacting
to
objects
or
things
like
that,
because
then
there's
no
really
need
to
have
a
delivery
team
members
around.
You
just
apply
the
label
one
hour
later.
The
package
starts
roll
out
and
you
only
have
to
promote
that's
the
only
manual
things
you
have
to
promote
on
piano.
B
Yes,
I
mean
certainly
it's
certainly
an
option:
yeah,
I,
I
I
think
we
should
consider
the
need,
like
I,
think
consolidating
our
processes.
So
we
have
one
process
that
just
does
what
it
needs
to
do
makes
things
easier.
I
I
know
you
two
know
a
lot
about
these
things
and
can
certainly
like
navigate
through
scenarios
and
use
cases
and
edge
cases
and
things.
But
it's
really
hard
to
onboard
people
into
release
management,
because
there's
so
many
different
processes,
so
I
think
if
we
don't
need
something
and
if
we.
B
B
C
B
I
think
there
are
different
cases
for
politics,
so
yeah
like
I,
think
PTL
or
we
know
we
don't
want
to
deploy
like
it's
family
and
friends
day
or
we
are
blocked
for
us.
We
are
for
three
days
then
sure,
let's
not
bother
building
a
package,
but
if
it
was
a
case
of
you
know
like
something
is
block
is
breaking
the
pipeline
and
we
we
don't
want
to
go
beyond
like
I,
think.
Perhaps
locking
an
environment
is
an
easier
way.
A
Yeah,
because
the
problem
that
we
have
sometimes
we
block,
because
we
know
that
there
is
an
issue
that
is
not
detected
by
QA,
so
we
don't
want
to
continue
building
and
deploying
because
we
will
just
reach
Canary
production
Canary
without
detecting,
but
we
will
still,
let's
say
we-
we
identified
something
that
is
broken
and
we
don't
want
to
keep
building
that
packet
package
with
that
that
broken
things.
A
So
we
pose,
we
wait
for
the
for
the
fixed
to
land,
and
then
we
and
then
we
impose,
but
the
other
option
is
that
we
just
lock
staging
but
sorry
staging
Canary,
but
this
kind
of
affects
other
things
like
CR
or
anything
else.
That
is
checking
the
if
the
environment
is
free,
so
it
really
depends
on
how
much
we
want
to
take
ownership
of
an
entire
environment
say
for
six
12
hour
compared
to
just
say
or
just
sub
building
packages,
because
in
delivery.
A
Next
we
have
this
idea
of
the
minimum
shot
which
is
later
down
and
the
thing
where
you
say
a
situation
like
this
happen.
This
is
the
fix,
don't
build
anything,
don't
promote
anything
at
any
stage
until
we
reach
this
point,
which
is
where
we
actually
want
to
go
right.
This
is
the
the
real
solution,
because
we
don't
want
to
block
yeah
others
from
doing
their
work
and
we
don't
want
to
waste
time
or
packages.
So.
B
B
And
Jonah
dig
out
the
link
for
Graham.
This
would
be
a
good
one
to
share
in
the
slack
Channel
as
well,
because
Graham
is
definitely
not
the
only
person
who
has
missed
this
change
coming
through.
B
But
I
think
the
the
hopefully
the
just
a
bit
is:
there
should
be
a
bit
less
to
do.
I
think
this
can
be
an
interesting
mindset.
Change
actually,
as
we
go
through.
A
lot
of
this
work.
Is
that
some
things
that
we
previously
did,
we
won't
be
able
to
do
in
the
future,
or
we
shouldn't
do
in
the
future
and
actually
I
think
that's
going
to
be
quite
a
difficult
adjustment
of
us
feeling
like
that.
B
We
should
be
doing
something
and
actually
as
sort
of
getting
to
the
point
where
our
automation
just
takes
over
for
us.
B
Cool
okay,
great
so
final
topic,
I
had
we
could
definitely
take
this
one
async
as
well,
but
I
just
I
left
a
comment
on
the
Q3
okr
discussion.
Not
so
much
aimed
at
you
Graham,
because
I
know,
you're
going
to
be
continuing
on
Runway
and
I.
B
Think
we'll
get
you
looped
into
those
okrs,
so
you
actually
have
a
goal
that
you
can
be
driving
towards,
but
I
haven't
had
too
much
response,
so
I
just
wanted
to
check
in
on
the
Q3
okrs,
which
is
I,
know
a
few
people
mentioned
about
the
I.
Guess
the
the
stretchness
of
moving
to
multiple
security
releases
in
Q3
and
what
I
wanted
to
say
was
so
I
was
thinking
along
the
lines
of
having
a
I
should
just
show
my
screen.
B
I
was
thinking
about
breaking
our
okr
up
so
that
we
have
something
along
the
lines
of
I
need
to
figure
out
where
anything
but
Sunday.
It
basically
says
we'll
do
more
security
releases,
but
the
key
are
the
chaos
to
go
and
achieve
this
would
be
one
would
be.
The
the
big
piece
from
our
side
will
be
to
switch
from
you
to
using
a
pull
model
instead
of
a
push
model.
B
So
basically
we
don't
say
tell
us
everything
that
should
be
in
this
release
and
we
try
and
get
it
into
this
release,
but
we
basically
say
get
everything
ready
and
when
we,
when
our
automation
declares
it's
ready,
it
will
be
pulled
into
our
release.
So
hopefully
we're
not
chasing
around
so
much
stuff.
B
B
It
may
only
have
security
fixes,
it
may
have
critical
security
fixes
which
appsec
would
like
labeling
different
or
it
may
only
have
bug
fixes,
in
which
case
absec
don't
really
mind
what
we
do
with
it
so
having
it
doesn't
have
to
be
that
fully
fledged
solution,
but
basically
some
automation
that
actually
pulls
that
stuff
together
and
allows
the
right
people
to
approve
things
and
get
the
information
needed
into
the
blog
post
and
then
I've
got
this
one
I
think
is
more
of
a
discussion,
one
which
is
quite
a
lot
of
us
being
able
to
support
multiple
security
releases.
B
It
comes
down
to
them
being
less
work,
and
some
of
that
will
come
just
from
the
switching
things
over
so
we're
not
waiting
on
people.
We
can
just
more
say
if
it's
ready
it's
in
the
release
and
on
we
go,
but
I
wondered
whether
we
also
wanted
another
KR,
which
is
maybe
doing
something
more
with
automation
or
something
which
you
mentioned.
Alessio
was
about
the
tagging
the
amount
of
time
it
takes
to
tag
the
packages,
so
I
was
wondering
if,
like
should
we
put
something
here
and
if
we
should.
What
should
that
be.
A
So
I
think
that
distribution
was
working
on
some
improvements
there,
that
I
Linked
In,
My,
release
manager,
Andover
message
and
basically
the
biggest
challenge
we
see
on
so
here's
your
release
and
we've
seen
a
scary
release,
because
this
is
the
extreme
release
process.
We're
doing
three
versions
at
the
same
time
is
our
problem
of
research
contention
on
dev
Runners,
so
I
don't
know
if
they
moved
on
that
issues
or
epic
I,
don't
remember
or
not.
A
But
the
problem
is
that
everything
has
been
set
up
manually,
so
they
were
doing
First,
Step,
moving
to
I,
think
terraform,
so
terraforming
the
runner
environments
and
then
the
ability
to
actually
scale
it
and
because
I
was
asking
can
we
have
dedicated
dedicated
random
Fleet
for
the
for
the
releases
so
that
autoploy
releases
always
have
a
bandwidth
and
so
I
think
if
we
can
try
and
work
with
them
on
this,
but
it
sounds
more
like
a
distribution.
B
Yeah,
okay
yeah,
that
makes
sense
Okay
cool,
so
we
can
certainly
check
in
with
them
on
progress
towards
this.
Okay.
That
makes
sense.
So
is
there
any
other
stuff
we
should
have,
or
would
it
be
enough
on
our
side
to
just
have
a
if
everything
was
ready
when
we
start
doing
the
release
and
like
is
there
anything
else
we
should
be
putting
in
place
before
so
this
will
be
a
combining
things
together,
hopefully
being
able
to
do
two
planned
combined
security,
slash
patch
releases
a
month
and
then
reviewing
where
we
are.
B
B
A
Yeah,
on
the
other
hand,
what
I'm
hoping
that
we
achieve
here
is
that
by
having
a
shorter
time
of
things
that
diverging
we
are
actually
reducing
the
because,
because
we
have
two
sinking
problems,
one
is
the
broken
and
I
and
merge
conflict.
The
other
one
is
thinking
at
the
end.
So
if
we
have
a
shorter
time
window,
where
things
diverge,
we
have
a
less
likelihood
of
merge
conflict.
A
So
we
conclude
earlier
we
merged
back,
and
so
maybe
we
are
dealing
less
stock
less
often
with
broken
stuff,
diverging
with
merge
conflict.
A
On
the
other
hand,
that's
absolutely
true
right,
so
we
want
to
of
the
emerging
work
at
the
end
of
these
things,
because
we're
gonna
make
it
two
one
more
time
and
then
there
is
also
the
security
list.
Basically,
there's
always
something
every
week
for
for
release
managers,
because
you
start
there's
a
security
for
security
release.
Then
probably
there
is
a
week
there's
nothing!
Then
there
is
the
monthly
release
and
then
there'll
probably
be
another
one.
Oh
yeah
man,
the
other
way
around,
but
basically
we
have
four
weeks
and
three
releases
yeah.
B
Exactly
but
the
other
I
think
if
we
can
get
this
right
and
this
kind
of
ties
together
the
work
that
Steve's
been
leading
this
quarter.
If
we
can
get
this
right,
it
should
get
rid
of
other
releases,
so
I
know
at
the
moment.
We
don't
do
three
planned
releases
each
month,
but
we
do
more
than
three
releases
each
month.
B
Some
of
those
are
patch
releases
which
are
relatively
straightforward,
but
they're
still
they
still
work
and
they
can
sometimes
be
quite
reactive,
and
some
of
them
are
security
releases,
which
are
definitely
reactive,
whereas
what
we
should
hopefully
find
is
that,
hopefully
we'll
see
it
a
bit
if
we
can
get
to
two
releases,
we'll
definitely
see
if
we
can
get
to
three
releases,
which
is
some
of
these
really
reactive.
Things
can
just
wait
for
the
next
planned
release
because
it
won't
be
so
far
out
yeah.
B
So
hopefully
we
will
we'll
start
to
feel
the
benefits,
and
it
just
makes
it
a
bit
more
predictable.
That
and-
and
this
is
where
automation
can
kick
in,
because
these
multiple
security
releases
or
patch
releases
should
I
say,
will
line
up
with
the
release
date.
Changing
of
the
22nd,
so
then,
hopefully,
what
we
get
to
is.
We
just
have
a
day
like
probably
each
week
where
this
process
kicks
off
and
it's
pretty
much
automated
and
it's
just
pulling
in
what
it
needs
to
do.
B
B
So
I
need
to
fix
the
wedding,
but
this
is
the
this.
The
first
okr
will
be
to
make
the
tool
the
process
changes
needed
to
support
us
moving
away
from
22nd.
It's
16.6
is
going
to
be
the
first
release.
That
does
that,
so
that's
November,
so
this
will
be
the
bit
which
we
I
think
will
have
to
kick
off
the
quarter
with
these
these
tasks,
because
it
would
be
a
shame
to
be
late
on
this.
You
and
I
hope
it's
not
a
ton
of
work.
B
A
B
Good
awesome,
okay,
grace
if
I'll
stick
that
back
on
the
issue,
so
Myra
can
also
comment
on
there
and,
as
I
said,
Graham
I
chatted
with
Liam
yesterday
we'll
try
and
get
you
in
a
KR
that
you
can
exclusively
own
that
pushes
into
Runway.
B
So
once
we've
got
that
we
can
also
share
that
back
with
delivery.
So
everyone's
got
some
visibility,
but
one
thing
sorry
go
ahead:
no.
B
C
Yeah
I,
yes,
I'd
heard
just
that
from
other
sources
as
well,
which
it's
good,
but
it
also
is
I,
need
more
context
and
understanding.
B
C
Day,
like
I
I,
see
them
tangently
related
I'd
like
to
I
I,
do
see
them
being
related
in
the
future,
but
I
just
think
I'd
like
to
make
sure
we
get
some
clear
understanding
about
what
the
goals
are
and
then
how
I
can
align
technically
as
well.
Behind
that
I
suspect
the
okay
after
the
next
quarter
is
probably
just
going
to
be.
Have
some
Runway
Services
running
in
production,
I.
C
Without
going
into
too
much
detail,
the
very
quick
update
is
we're
actually
getting
pretty
close
to
a
lot
of
the
like
deployment
and
running
the
containers
and
giving
the
developers
the
power
and
all
that
stuff.
We're
close
to
being
done.
I'm,
not
saying
it's
by
any
means
a
stellar
system,
but
it's
pretty
good
with
a
good
level
of
safety,
and
we've
got
a
good
level
of
being
able
to
run
things
and
doing
test
workloads
on
it
seems
to
be
pretty
good
for
the
simple
use
cases
we're
targeting.
C
The
big
thing
we're
left
is
just
observability
once
we
get
a
good
observability
story
in
place,
which
is
likely
just
installing
the
bits
and
connecting
it
all
up
to
our
dashboards
and
so
forth.
I
suspect
that
we're
very,
very,
very
much
looking
at
you
know,
making
a
service
like
GA
in
a
service
more
or
less.
B
A
C
It
seems
like
from
what
I'm
hearing
runway's
not
going
away,
which
is
obviously
always
the
other
concern
with
it
was
it
was
hotly.
You
know
it
was
very
much
wanted
at
the
start
of
all
this
AI
work,
but
you
know
I
say
our
work
has
grown
and
shifted.
There
was
I
was
always
wondering
if
the
company's
focus
and
appetite
would
grow
and
shift
as
well,
but
it
seems
like
that's
not
the
case,
which
is
good.
Okay,.