►
From YouTube: 2022-08-31 Delivery:Orchestration team 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
A
Really
low,
is
it
just
me
or
okay,
so
try
to
fix
my
audio.
C
B
B
B
Confusingly
go
okay,
so
the
I'll
just
I'll
shout
so.
The
first
item
is
this:
is
this
is
all
around
the
Epic
that
we've
got
in
progress
around
analyzing
and
comparing
deployment
of
these
components,
Kaz
Pages
registry
and
gitly
this?
So
the
agenda
item
here
is
really
off
the
back
of
your
comment
that
you
left
yesterday
Graham
a
couple
days
ago.
B
Your
time,
which
is
specifically
around
the
fact
that
we've
gathered
a
lot
of
information
but
due
to
partially
due
to
the
way
that
things
are
structured
at
the
moment
and
also
just
to
share
quantity
and
information
there,
it's
difficult
to
be
able
to
sort
of
cross-reference
and
pull
out
the
individual
pieces
of
information
that
are
most
relevant
to
what
we
are
trying
to
do,
and
also
to
try
and
figure
out
exactly
what
what
pieces
overall
are
most
relevant
to
helping
us
essentially
move
towards
achieving
our
okrs,
which
is
kind
of
kind
of
the
Plumb
line
of
you
know
the
the
goals
of
what
we're
looking
to
accomplish.
B
This
course
is
so
it's
just
I
made
in
in
a
follow-up
comment
and
wanted
to
put
in
the
agenda
here
for
discussion
is
really
that
we
try
and
scope
down
the
bits
in
The
Epic
that
we
want
to
drill
down
into
deeper
or
deep
as
deep
as
deep
as
we
need
to
to
be
able
to
move
us
towards
those
okay,
Arts
and
then
just
sort
of
leave
the
other
bits
sort
of
on
the
periphery.
B
Although
we've
already
sort
of
captured
quite
a
bit
of
information
for
them
already
so
with
the
with
your
car
as
being
specifically
or
to
the
client
chat,
that
was
tagging
for
Chasm
pages,
the
three
areas
that
I've
suggested
it
doesn't
have
to
be
these.
But
my
suggestions
would
be
focusing
specifically
on
auto
deploy
enabling
it
for
cars.
What
are
the
What's,
the
diff
between
where
things
are
now
to
where
they
need
to
get
into
Auto,
deploy,
versioning
and
then
tagging
or
chat?
Ups
tagging
specifically.
D
Sorry
just
interrupt
quickly,
I
I
find
it
like,
and
when
I
look
back
at
the
okrs
I
still
realized
I
have
no
clue
what
I
think
to
me.
This
might
be,
or
maybe
this
is
just
me,
I'm
sure,
like
Alessio
or
maybe
Myra
have
got
more
background
context,
but
I
feel
like
when
we
say,
chat,
Ops
tagging
for
like
pages
that
that's
like
a
couple
of
words
that
are
very
vague,
like
I,
don't
understand
what
that
actually
means.
Like
chat,
Ops
tagging.
Does
that
mean
we
write
a
whole
new
chat,
UPS
command?
D
D
C
Then
because
I
think
that's
a
super
good
point.
Let's
all
make
sure
we
don't
know
what
the
okrs
are
as
a
starting
point
right,
because
I
think
we
we
have
a
few
things
running
in
parallel,
which
is
needed,
but
I
think
we
need
to
be
clear
what
the
parts
are
so
that
we
don't
get.
We
don't
need
to
answer
the
entire
self-serve
question
right
now,
all
right,
let's
be
clear
on
that
one,
so
the
actual
okrs.
Let
me
actually
get
these
accurate,
so
I
just
gotta
log
into
Ali.
C
So
what
we
know
is
as
delivery
group.
We
are
working
towards
the
platforms,
Direction
stuff
right,
so
I'd
recommend
everyone
spend
some
time.
Take
a
look
through
the
handbook
make
sure
you're
really
on
board
with
what
that
means.
That's
the
direction
we're
headed
in,
but
what
we're
actually
trying
to
do
this
quarter
is
the
okr
is
written
at
I'll.
Add
you
the
link
to
this
after
as
well,
so
you
can
jump
in,
but
just
for
now,
so
the
overall
for
this
particular
for
what
we're
talking
about
in
this
particular
demo.
C
The
objective
is
defining
a
path
towards
self-serve
deployments
and
moving
two
components
towards
this
state
and
what
we've
got
written
as
the
key
results
for
that
and
it's
deliberately
open
so
that
we
can
we
can
adjust
if
we
need
to
but
I
think
from
what
we've
seen
so
far.
This
quarter,
I
I,
don't
think
we
will
need
to
and
the
key
results
are.
C
C
Which
I
think
is
quite
a
well-known
thing:
I,
don't
think
I'm
hoping
this
isn't
an
enormous
piece
of
work
and
I'm,
hoping
it's
reasonably
well
known,
and
then
the
third
one
is
working
with
editor
group
to
enable
chatops
tagging
for
the
pages
service
again
I'm,
hoping
that's
a
reasonably
well-known
piece
of
work.
A
B
A
Yeah,
why
don't
we
take
a
look
at
this
thing
together,
starting
from
the.
C
C
C
So
what
I'm
hoping
is
that
we'll
find
that
this
quarter
is
reasonably
straightforward
and
implementation,
and
that
gives
us
some
space
to
figure
out
what
are
the
foundational
pieces
we
want
to
do
for
self-serve,
and
then
we
can
figure
out
working
on
it
so
like
POC
or
all
that
stuff,
but
I
think
let's
push
all
of
that
back
into
later
into
the
quarter,
so
that
we
can
just
sort
of
scope
down
what
we're
working
on
right
now
and
get
some
get
some
issues
and
epics
things
ready
to
pick
up.
D
Are
we
talking
about
so?
The
other
thing
is
that
is
confusing
to
me
and
maybe
once
again
this
is
just
my
perception
or
whatever
is
when
we
say
release,
do
we
mean
Auto,
deploy
or
self-managed
releases
yeah.
A
Really
can
we
can
we
go
through
the
table
that
I
did
when
we
do
when
we
were
doing
the
okr
description,
because
there
are
many
conflicting
things
that
are
happening
in
this
conversation
that
are
actually
easily
linked
together,
but
we
are
kind.
So,
oh,
this
investigation
got
sidetracked
by
the
details
and
and
that's
part
of
a
bigger
issue,
which
is
that
we
for
historical
reason,
implemented
the
same
thing
with
different
code
path
and
different
names.
That's
why
things
seems
more
complex
than
what
they
are
right.
A
So
let
me
try
to
to
briefly
work
through
one
comment
that
I
wrote
in
the
okr
description
to
see
if
this
helped
to
to
clear
some
of
the
what
we
means
when
we
say
something:
let
let's
try
this
so
I'm
going
to
share
this
page
here
sorry,
so
this
was
part
of
the
okr
planning
and
basically
we
were
defining
this.
Let's
call
them
five
steps
right
toward
self-serve
deployment.
A
These
are
all
based
on
things
that
we
already
have
today
on
some
components.
So
here
is
a
kind
of
a
highlight,
high
level
description
below
I
think
there
is
also
some
kind
of
requirement
list
for
each
step.
But
let's,
let's
start
with
this
very
simple,
so
there
is
a
we
have
this
step,
one
which
is
do
we
have
a
version
file
or
not
and
the
gitlab
repo,
and
then
we
have
the
table
that
breaks
this
down
by
component,
who
has
it
and
who?
Don't
only
registry?
A
Don't
have
it
right
now
right
so
then
we
have
automated
rollout,
which
is
how
to
deploy
automated
rollout
means
that
if
something
is
in
Auto
deploy,
what
does
it
mean
to
be
in
200
deploy?
It
means
that,
because
it
has
a
version
file
when
we
Tag
Auto
deploy
by
default,
we
propagate
version
files
to
the
packagers.
So
this
column
here
means
are
we
acting
on
that
specific
component
when
we
roll
out
how
to
deploy
or
not
example,
easily?
A
D
C
A
Yeah
right
so
I
just
want
to
make
sure
that
we
in
this
call
understand
what
we're
thinking
about.
So
we
can
find
better
words
that
can
we
we
can
also
use
outside
of
this
right,
then
so,
automated
rollout?
Is
it
clear
to
anyone?
Registry
and
cars
are
and
yeah
also
magic.
Sport
are
the
only
one
not
implemented
in
this
right,
because
everything
else
is
installed
when
we
do
when
we
do
another
employee
deployment.
A
Does
this
make
sense
to
everyone?
Okay,
then
we
have
automated
release,
which
is
what
what
I
think
isn't
the
scope
of
the
okr
for
this
quarter
for
pages
and
casts?
What
does
it
mean?
So
basically,
automated
release
means
that
when
we
do
a
monthly
patch
security,
any
type
of
customer
facing
release
which
is
not
out
of
deploy
the
content
of
the
single
source
of
Truth,
which
is
the
version
file,
is
reflected
into
a
tag
being
prepared
for
that
component.
A
So,
as
you
can
see,
visually
is
the
only
one
implementing
this
and
is
the
thing
that
was
investigated
by
part
of
this,
the
epics
that
we're
working
on,
which
is,
but
basically
we
call
this.
We
can
call
this
product
version
alignment,
which
means
we
do
15.4.something.
Then
every
component
goes
through
an
automation
that
makes
that
15.4.
something
for
them
based.
A
C
D
A
That's
the
point,
so
you
are
think
you
are
thinking,
I,
think
you're
thinking
a
step
right
to
what
I'm
thinking
so
I
am
in
in
the
realm
of
the
component
repository.
So
each
component
developer
must
create
his
own
release
with
the
custom
process
that
they
they
find
in
their
own
repo,
which
is
the
things
that
you
were
investigating.
But
if
you
look
at
Italy
they
don't
they
just
they
get
all
this
for
free
with
it
and
it
there's
a
price
for
this
price.
Is
that
you
don't?
C
A
Aligned-
and
you
must
apply
the
changelog
system
that
we
have
in
the
product,
because
we
we
do
the
API
change
log
generation.
There
is
a
third
price
which
is
part
of
a
of
discussion
happening
in
an
issue
related
to
pages
that
we
can
dig
a
bit
deeper,
but
it's
important
for
all
of
us
to
understand,
which
is
by
doing
automated
release
components,
get
a
tag
in
the
release.
Even
then,
even
when
there
is
no
changes
for
for
them
specifically,
so
we're
gonna
do
a
patch
release.
A
D
That
part
is
yes,
so
it's
basically
see
to
me.
I
thought
it
was
automated
releases
as
in
going
out
the
door
releases,
but
I
see
it's
like
it's
kind
of
like
delivery,
managed
releases.
We
manage
your
Rel,
your
delivery
managed
component
releases,
so
the
releases
of
the
company
yeah,
that's
managed
by
delivery,
yeah
absolutely
and
they
because
I
think
the
thing
is
is
because
you
have
releases
for
the
component
and
releases
for
gitlab,
which
the
component
is
inside.
The
release
for
gitlab
and
I.
Think
that's
what
kind
of
gets
com
yeah
gets
confusing.
C
I
think
that's
one
thing
we
were
talking
about
a
little
bit
last
week
right
so
for
like
do
you?
Are
you
meaning,
like
the
things
that
get
kind
of
like
gems,
that
get
sort
of
tagged
and
released
independently?
Is
that
what
you're?
Referring
to
that
Graham.
D
No,
so
the
components
like
cars
Pages
pages
is
a
good
one.
Their
versioning
scheme
is
like
version
one
two,
three
one,
two
four
one,
two
five
but
Italy
right
and
butily
and
I
didn't
realize
this.
Until
we
did
this
whole
exercise-
and
obviously
Alessia
knows
all
this,
but
I
don't
but
Gita
Lee,
their
versioning
is
15.4
every
new
month.
They
got
like
there's
literally
one
to
one
and
I
think
you
know.
D
Amy
I
talked
to
you
this,
like
we,
we
chatted
about
this
before,
like
a
single,
you
know
we
talked
about
like
a
defined
versioning
scheme,
but
what
what
I
was
talking
about
that
or
thinking
about
that?
What
I
didn't
realize
is
we
actually
already
have
that
and
we
have
the
automation
for
it.
It's
just
the
get
that
versioning
scheme.
So
essentially
it's
like.
We
want
all
components
to
ditch
their
own
versioning
scheme
and
align
with
the
gitlab
versioning
scheme
and.
A
We
did
a
big
band.
Basically,
we
do
if
they
apply
it.
We
just
move
from
version
one
to
version
15..
We
did
this
for
digitali.
There
is
a
an
issue
opened
by
Vladimir
for
pages
that
we
were
just
saying:
why
don't
we
align
things
because
it
makes
it
but
security
release
easier,
because
I
mean
I've
been
through
this
as
a
workers
maintainer
as
a
Pages
maintainers?
It's
it's
a
it's
really
a
pain.
A
In
the
last
three
stable
releases,
and
then
you
have
to
pre-allocate
version
numbers,
because
you
do
the
development
in
in
this
in
the
mirror,
but
because
the
number
are
independently
released,
then
you
can't
release
a
new
component
version
publicly
in
the
meantime,
because
you
are
keeping
hold
on
on
version
numbering
that's
the
nightmare.
It
happened
last
month,
I
think
with
Pages,
where
this
things
was
done
in
the
wrong
order
and
they
basically
got
stopped
with
the
with
the
version
numbers
because
they
couldn't
release.
C
Can
we
just
grab
that
little
thought
right
like
that?
That
should
be
an
issue
right.
The
whole
complexity,
around
versioning
and
I
think
that
would
be
a
really
good
thing
to
pull
from
all
of
these
sort
of
broad
discussions,
which
is
like
the
specifics
of
when
what
I
mean
I
know
it's
kind
of
covered
in
this
table,
but
I
don't
think
we
have
the
details
right
and
I
think
what
we're
trying
to
do
is
get
to
the
full
team.
Understanding
of
why
aversion
is
difficult
when
you
do
a
security
lifestyle
pages
right.
A
Yeah
because
I
think
it's
my
solution
to
why
we
are
struggling
with
how
we
are
documenting
things
and
an
alternative
proposal
of
how
how
we
should
try
to
document
those
things.
So
we
are
on
automated
release.
I
hope
this
is
now
clear.
That's
as
I
said,
as
Amy
was
asking
me
to
repeat:
that's
the
the
point
where
how
to
deploy
gets
into
on-premise
releases.
Why
is
that?
A
That's
so
in
theory,
because
the
not
in
theory
because
the
system
is
managing
releases
for
developers,
they
don't
have
to
release
anything
which
means
that
they
can
just
bump
the
version
at
this
point
in
time
as
a
manual
bump,
they
can
bump
the
version
with
sha.
They
say
I
think
this
is
a
production
ready
version
of
Cass
has
this?
Is
the
Shan
number
so
I'm
gonna
bump
the
Shop
version
on
the
component
and
it
will
get
into
Auto
deploy
and
when
is
the
22nd?
It
will
be
tagged
accordingly
and
released.
D
D
Yeah
I'm
still
I'm
I'm
still
trying
to
understand
why
building
from
Char
is
important
like
if,
if
a
if
a
component,
let's
say
cars,
for
example,
if
they're
on
the
burgeoning
scheme-
I,
guess
I,
guess
if
you
adopt
I,
think
this
is
a
tricky
part
here.
If
you
adopt
the
gitlab
versioning
scheme
like
15.2
or
whatever,
you
can't
cut
your
own
like
yeah.
This.
A
D
D
So
I
think
this
is
actually
a
really
key
point
for
all
of
this
as
well,
especially
if,
when
we
talk
to
developers
around
this,
so
at
the
moment
Kaz
can
tag
whenever
they
want
right.
They
can
literally
go
in
create
their
own
tags.
Then
they
go
to
the
ssot
like
the
version
file
and
put
that
tag
number
in
whatever
it
is
version.
D
One
two
three
version,
four,
five:
six,
but
if
you
adopt
the
git
lab
versioning
system-
and
we
can
and
that's
good
for
you
because
you
get
a
bunch
of
brand
short
I-
think
Branch
automation
is
the
big
one
right
like
getting
branches
created
for
you
and
stuff.
But
what
you
can't
do
is
you
can't
as
developer
cannot
tag
because
it's
our
job
to
tag
yeah,
not
your
job
anymore,
yeah
and
I.
A
D
D
A
Don't
want
to
create
packages.
Packages
are
ephemeral.
You
just
want
to
exactly
to
have
a
point
in
time
in
the
history
of
your
code,
but
there
is
an
alternative
option
that
we
never
did
before.
I
mean
never
Italy
is
the
only
component
in
at
this
level
of
Automation
and
is
not
doing
it.
So
that's
the
point.
A
We
could
do
two
taggings,
something
like
an
example
say
cast
say,
cast
one
two
tag
their
own
things
to
Mark
what
they
think
is
ready
to
be
included
in
the
product,
but
then
it's
kind
of
an
internal
information
right,
so
they
could
do
something
like
tagging
by
say,
internal
Dash,
their
own
version.
That
means
that
when
they
release
something
internally
with
no
need
to
change
log
or
anything
like
that,
they
can
bump
this
version
here
with
their
internal.
D
A
A
We
never
done
this
before,
but
actually
it
works,
and
the
point
is
that,
when
things
get
out
of
the
door
for
customers,
things
are
aligned
with.
How
do
we
do
change
logs?
We
do
that's
how
we
do
change
logs.
How
do
we
create
stable
branches,
because
this
opens
the
door
for
something
that
is
not
here?
That
is
not
in
scope
with
oh
for
this
OCR,
but
it
is.
How
can
I
give
all
of
the
components
clear
and
understandable
security
release
process,
which
is
streamlined,
which
is
the
same
regardless
of
where?
D
So
I'm,
just
in
in
the
interest
of
time,
circling
back
to
the
okr,
so
the
okrs
are
to
get
cars
into
Auto,
deploy
so
correct
me
if
I'm
wrong,
I,
I
I'm,
hoping
I'm
not
wandering
too
far
off.
Here
you
were
doing.
You
commented
Alessia
that
you're
getting
Kaz
to
build
on
Shah,
which
is
great,
but
technically
that's
not
needed
for
auto
deploy
right
like
at
the
moment.
Cas
wanted
to
go
into
Auto
Okay
cool,
so
that
is
good
for
cars,
but
it's
more.
It's
really
good
for
cads
for
automated
release.
D
A
D
C
And
and
one
other
question
I
have
as
well,
which
I
know
we
talked
a
bit
about
in
the
past
grade
and
I.
Don't
know
if
we've
got
an
answer
on
is
we
know
that
at
the
moment
cars
has
prey
available
as
part
of
their
sort
of
I.
Don't
know
if
they
test
on
it,
but
certainly
they
do
a
deploy
to
prey
as
kind
of
a
piece
of
their
deployment.
They
will.
C
If
we
just
go
with
the
vanilla
Auto
deploy,
they
lose
that
so
we
should
probably
figure
out
if
they
actually
need
that
I
hope
they
don't,
but
we
should
check
in
with
them
on
there
yeah,
but.
C
Deploy
a
show
I
think
we
should
check
with
them
if
they
actually
need
it,
and
if
they
do
can
figure
out
a
way,
but
I
think
it
would
be.
It
might
be
useful
to
I.
Think
it'd
be
an
interesting
conversation
to
actually
be
like
part
of
our
Auto.
Deploy
doesn't
generally
use
pre.
Are
they
actually
using
it?
Isis.
D
I'm
pretty
sure
from
we're
working
with
them.
They
don't
they
just
do
it,
because
we've
asked
them
to
to
do
it
because
suspects
so
yeah.
But
yes,
we
should.
We
should
just
double
check
that
with
them,
because
they
will
still
get
to
be
able
to
test
it
in
Pre.
But
it's
RCS
like
everything
else,
you
could
go
and
test
an
RCM
pre
at
release
time,
if
you,
if
you
so
desire.
A
I'm
going
to
conclude
the
stable,
because
we
are
at
the
end-
and
this
is
the
last
step-
are
easy
enough,
so
automated
update
is
just
a
script
that
is
part
of
release
tools
that
make
sure
that
this
file
here,
the
the
version
file,
is
automatically
bumped
to
the
last
green
Pipeline
on
master
of
your
component.
So
this
ties
back
into
this
one
and
kind
of
gives
you
call
it
continuous
delivery,
not
really
because
it's
aligned
to
how
to
deploy
yet,
but
that's
the
closest
thing
to
continuous
delivery.
You
can
have
yeah
go
ahead.
A
In
some
released
tools,
it's
a
simple
step
create
a
merge
request
so
that
it
runs
the
integration
test
and
pre-approve
and
preset
the
merge
when
pipeline
is
green,
using
two
tokens
that
that's
what
is
happening.
It's
it's
very
simple
one.
There
are
problems
here
like
it
can
fail,
and
things
like
that
there
are
pain
Point
here,
but
this
isn't
yeah.
This
is
not
really
part
of
I
mean
it's
it's
a
later
step,
so
just
be
aware
of
what
does
it
mean
independent,
deploy?
A
That's
a
green
field,
so
the
question
is
once
we
have
things
automated
up
to
this
point,
which
we
can
treat
all
of
them
independently
manage
releases
and
things
like
that.
How
do
we
deploy
them
independently
and
keep
it
still
keeping
track
of?
What
is
inside
of
a
package,
because
everything
up
to
here
starts
with
the
single
source
of
Truth.
Is
the
code
on
Rails
and
from
there
we
propagate
versions
here,
there's
a
big
change
because
things
could
be
deployed
independently,
so
we
need
to
backtrack
so.
D
I
think
so,
I
think
independent.
Once
you
go
into
Auto,
deploy
you
lose
independent
deployment,
yeah
I,
suspect,
yeah,
I
suspect,
that's
what
we
when
we
move
these
guys
over,
they
will
lose
independent,
deploy
and
then
the
next
stage
of
independent
deploy
becomes
the
self-managed
blueprint.
A
A
Yeah
to
know
thank
you
what
it
is
I
just
want
to.
Was
it
here
yeah?
Basically,
here
there
is
a
kind
of
what
doesn't
what
do
we
actually
need
to
to
to
give
a
component
each
of
those
steps,
and
that's
the
thing
right.
A
So
the
for
the
yeah
here
was
I
was
supplies
was
in
here
right,
so
automated
allow
autoplies
that
that's
it's
about
metrics,
it's
about
tracking
component
versions
when
we
deploy,
so
this
is
kind
of
a
high
level
information
of
what
what
does
it
mean
to
to
complete
that
stage
for
for
a
given
component?
So
that's
something
we
can
break
down
through
and
that's
it.
Oh
yeah,
that's
one
right!
A
So
we
say
we
we
need
to
be
able
to
to
build
from
Sha
to
to
give
things
automated
releases,
and
these
are
kind
of
an
entry
point
to
to
that
conversation.
What
before
I
go
ahead
in?
Do
we
do
we
have
questions.
A
Okay,
so
my
take,
let
me
stop
sharing,
so
what
I'm
going
to
suggest
to
try
to
make
this
easier
to
to
work
on
is
try
to
Define
process
by
the
steps
that
we
described
instead
of
digging
too
deep
into
every
single
code.
Detail
of
how
we
do
things
today,
for
instance,
I,
would
consider
removing
entirely
everything
like
security
releases,
patch
releases
and
things
like
that.
They
are
kind
of
out
of
scope.
They
once
you
bring
things
into
release
Automation
in
automated
releases.
A
C
Because
is
there
any
value,
though,
right
now
in
so
I
think
my
guess?
Unless
you're,
perhaps
the
only
person
who
understands
what
happened
with
the
pages
security
release,
like
I
I,
do
think,
there's
probably
some
value,
and
maybe
we
don't
need
to
know
every
single
step,
but
I
think
we
probably
need
to
know
enough
about
how
Pages
security
release
work
show
that
we
understand
what
the
pain
points
are,
but
yeah
yeah
for
a
lot
of
the
other
pieces.
We
certainly
don't
need
to
know
every
single
step.
I
think.
That's
probably
probably.
A
Yeah
there
was
meaning
with
this-
is
that,
instead
of
repeating
those
things
for
every
component
is
more
about
with
release
automation,
you
gain
this
and
that's
a
that's
a
benefit,
because
example,
security
releases
are
painful
and
you
explain
briefly:
what
does
it
mean
to
create
a
security
release
for
a
generic
component
and
then
by
component?
We
can
because
describing
this
way
we
can
identify
requirements.
So
what
do
we
need
to
give
you
automated
releases?
A
C
Two
right
I
think
we
know
what
needs
to
happen
and
we
know
what
we're
missing
and
we
know
what
we
need
to
ask
configure
about
so
I
feel
like
we've
got
a
decent
idea
around
what
we
need
to
do
at
Cal,
so
we
probably
need
to
make
sure
they
are
aware
about
what
they
lose
and
that
pull
that
together,
but
I
think
we
have
a
good
understanding
for
that.
So.
C
C
Sure
yeah
right
so
then,
because
we
know
that
cars
is
probably
going
to
take
a
little
while
to
get
Auto
deploy
because
of
canary
I.
Think
that
means
the
next
thing
we
can
be
thinking
about
is
the
pages
automated
release
and
I
think
we
do
need
to
figure
out
what
that
name
is,
but
if
we,
if
we
think
about
that
as
a
it's,
not
currently
blocked.
C
A
D
D
B
A
Mean
yesterday
has
some
problem
in
how
the
process
behave,
how
do
we
spot
errors
and
the
biggest
problem
with
gizzly
is
that
we
had
an
idea
and
we
forced
the
process
into
the
team.
What
we
want
to
do
here
is
more
about
describing
the
benefits
and
say:
do
you
want
this?
Because
if
you
get
this,
this
is
what
you
don't.
You
no
longer
have
to
do
so,
just
describing
the
the
security
release
process
and
say
this
all
goes
away.
You
just
merge
things
into
the
stable
branches
and
you
get
things
tagged
for
you.
A
It's
it's
a
huge
benefit.
There
are
drawbacks.
We
mentioned
them,
so
you
you
lose
the
ability
to
talk
independently
to
her.
You
need
to
be
version
aligned
and
things
like
that.
So
if
we
are
clear
up
front
on
what
we
give
them,
then
basically
we
have
a
buy-in
from
them.
So
yeah
just
I,
want
to
I
want
to
enroll
in
this
because
I
see
the
benefit.
A
They
have,
but
there
are
other
components
there.
So
if
we
are
going
to
write
this
down
well
enough
now,
then
you
can.
We
can
just
point
the
the
next
round
of
components
that
we
want
to
integrate.
So
that's
that's
the
thing
right.
So
this
is
a
release.
Automation
and
that's
how
behave
these
are.
The
components
are
already
and
that's
the
benefit,
that's
what
you
lose.
A
At
this
stage
we
are
doing
this
for
them,
but
tomorrow
a
new
components
come
in
and
they
have
a
recipe
to
follow.
So
they
can
just
do
the
things
by
themselves.
D
C
Even
if
we
make
up
a
name
yeah
right,
because
I
think
there's
two
iterative
pieces,
we're
talking
about
here
right,
one
is
I.
Think
the
first
bit
to
answer
your
question.
Graeme
of
what
are
we
aiming
for
like
I,
do
think
we
should
consider.
Is
there
a?
Is
there
a
thing
we
can
do
to
the
gitly
process
that
it
makes
it
a
slightly
better
process
for
whoever
comes
next
right
like
is
there
an
iterative
improvement?
We
can.
C
We
can
see
if
so,
let's,
let's
try
and
improve
it,
and
then
I
think
we
can
also
it's
iterative
right.
So,
let's
not
try,
write
down,
sit
right
now
or
write
the
perfect
sort
of
document
that
everyone
would
sign
up
to,
but
we
should
certainly
be
aiming
towards
that.
We
know
we
have
two
components.
In
fact,
we
know
we
have
three
components
that
are
really
brought
in
with
this
pages
cars
registry.
So
we
don't
need
to
do
very
much
selling
for
those
three.
C
A
D
So
I
guess
that
comes
back
to
them.
Where
do
we
feel
with
the
with
Matt's
original
point
and
I?
Guess
the
Epic
that
we're
I
can
see
now,
obviously
I've
dived
a
little
bit
too
deep
in
some
of
the
stuff
in
that
epic,
although
probably
a
really
good
learning
experience,
even
if
it's
not
inherently
useful
to
our
goals,
is
it
really
then
I
I
think
perhaps
maybe
maybe
you're
right
Alicia,
maybe
with
that
Epic?
D
Because
because
we
were
just
like,
let's
document
the
patch
process
like
I?
Perhaps
we
just
put
some
stuff
in
there
like
of
what
we're
trying
to
document
and
capture,
but
it
was
kind
of
a
bit
too
much
for
for
what
we
needed
and
we
need
to
pull
that
back.
I
still
think
it
was
really
good,
like
even
the
stuff
yeah.
C
I
agree,
I,
agree,
I,
think
it's
really
useful
and
I
think
like
I
think
as
long
as
we
stay
focused
on
cars,
Pages
Italy,
it's
super
useful
right
like
we.
Maybe
don't
want
to
do
it
to
the
step
for
every
single
component
ever
but
I
think
for
getting
on
the
right
page
right
now
and
understanding
I
think
we've
all
learned,
stuff,
I
think
we've
all
gone.
Oh,
it
doesn't
work.
C
How
I
thought
it
worked
and
even
as
I
was
reading
the
comment
yesterday,
I
was
like
okay,
I,
don't
know
what's
happening
in
that
step
like
I
I
actually
have
no
concept
of
that
individual
step.
So
I
think
it
is
really
useful,
but
we
probably
don't
want
to
try
and
get
a
here
is
a
complete
documentation
for
every
piece
of
deployments
and
releases
like
because
we
we
could
spend
years
doing
that.
B
A
C
So
we're
running
up
on
time,
so
I
guess
as
I
I
I
think
probably
two
things
jump
out
for
me
on
what
we
have
on
the
analysis.
Stuff
one
is:
does
everybody
have
a
concept
of
what
the
gitly
pain
points
are.
C
Let's
make
sure
we
get
that
as
an
action
I,
don't
I,
you
know,
I
know,
Myra
is
busy
on
the
security
release
whatever
but
I
think
as
a
gittily
component.
A
gitly
analysis
issue
is
complete.
Let's
make
sure,
as
well
as
knowing
roughly
how
that's
working.
We
really
understand
what
the
gitly
team
find
Difficult
about
the
process,
because
we
can't
just
pick
up
the
gitly
process
and
add
it
to
other
components
anyway,
because
they're
on
VMS
they
have
different
dependencies.
C
Do
we
know
enough
about
like
I
feel
like
with
cows?
We
have
a
good
understanding
of
kind
of
it's
dependencies
and
kind
of
how
the
configure
team
generally
work
day
to
day
do
we
have
the
same
kind
of
understanding
about
pages
and
how
the
which
team
owns
it.
The
editor
group
is
kind
of
working
with
pages.
I
know
there
are
super
new
owners
for
for
this
stuff.
So
those
are
kind
of
question
marks.
At
least
I
have.
A
Yeah
ownership.
There
is
a
bit
of
a
tricky
so
because,
if
you
look
at
the
say,
directional
slash
architecture
conversation
happening
in
there.
They
are
from
people
that
are
not
part
of
that
stage.
Group,
because
you
can
see
me,
you
can
see
Vladimir,
you
can
see
gregors
because
all
of
us
being
former
Ops
engineer
from
the
upstage
we
were
working
on
this
one
Pages
was
part
of
opposite
release:
yeah,
so
there's
a
transition
that
is
happening
so
yeah.
Maybe
it's
I
mean
they
are
willing
to
change
things.
So
probably
right.
C
That's
it
that's
it.
It
might
be
that
they
in
a
way
simpler
in
that
they
probably
are
going
to
just
want
the
easiest
thing
right.
Let's
load
it
all
inside
Auto
deploys
and
releases
and
we've
just
wrapped
them
up
like,
but
it
that's.
Certainly
a
question
mark
I
think
we
should
as
part
of
the
analysis,
we
should
probably
figure
out
what
they
actually
they.
C
It's
absolutely
fine,
just
stop
it
in
the
delivery
tracker
we've
got
to
self-serve
deployments
label.
You
can
stick
on
it,
so
we'll
be
able
to
locate
it,
but
yeah.
That's
absolutely
fine.
Just
an
issue
somewhere
would
be
super.
D
And
just
remain
clarification.
We
really
just
want
to
get
out
of
this
a
targeted
like
name
or
something
we
can
give
people
that
has
a
distinct
meaning
and
then
like
a
a
fairly
high
level,
but
still
a
little
bit
low
level
definition
about
what
you
get.
What
you.
C
What
else
would
be
useful,
Matt
you've
got
a
kind
of
a
kind
of
issue
that
you're
kind
of
thinking
through
about
how
we,
how
we
sort
of
wrap
up
this
epic
and
pull
together
some
analysis.
Things
like
what
would
be
a
useful
action
to
take
from
this
discussion
to
help
that
move
along.
B
Yeah,
it's
a
good
question.
I
think
the
getting
the
main
thing
that
was
was
in
my
head
through
a
lot
of
the
discussion
was,
was
actually
what
we
literally
just
covered,
which
is
defining
exactly
what
the
next
step
looks
like
to
these
components
and
exactly
what
we
mean
when
we
say
automated
releases
because
well,
like
I,
said,
I,
don't
think
we're
in
a
place
where
any
of
us
can
confidently
and
fully
explain
exactly
what
that
means
to
anybody
that
comes
along
and
that's
a
problem.
I
mean
I.
B
So
getting
that
down
and
getting
that
agreed
upon
across
the
board
is
going
to
be
really
important
and
if
anything,
I
kind
of
feel
like
that
is
sort
of
quite
a
helpful
Direction
in
defining
exactly
where
this
epic
needs
to
be
tied
off
like
once
once
we
know
exactly
what
that
is,
we
can
say:
okay,
well,
this
epic
only
needs
to
do
as
much
as
we
need
in
order
to
understand
what
that
definition
means
for
us
and
what
we
need
to
do
to
translate
that
definition
into
cousin
and
Pages,
because
right
now,
it's
just
a
whole
heap
of
stuff
that
we
can
pick
from.
B
A
How
do
we
feel
of
instead
of
just
giving
a
clear
definition
of
automated
releases
just
going
through
all
the
five
steps
so
that
we,
each
one
of
them,
has
a
clear
name,
could
be
the
one
that
is
already
in
there
could
be
a
new
one
with
a
set
of
say,
expectation
or
requirements.
So
something
is
needed
in
order
to
have
this
and
kind
of
a
dependency
graph
between
them.
So
can
I
have,
for
instance,
dreams
say:
oh,
so
we
can
have
automated
release
without
having
Auto
deploy.
That's
true
right,
so
they
are
in.
A
They
are
linear
because
they
kind
of
reflect
how
we
went
to
them
so
how
we
implemented
them
sequentially,
but
for
some
of
them
are
there
are
branching
point
where
you
can
go
parallel
in
some
of
them
and
then
maybe
just
looking
at
everything.
There
is
a
junction
point
where,
in
order
to
get
to
the
next
step,
you
have
to
complete
both
both
tracks.
So,
let's
say
in
independent
releases,
automated
releases
and
autoplay
as
an
example
right,
so
they
can
go
on
Parallel.
C
C
Like
I
mean,
does
it
does
that
help
us
a
lot
like
I
know,
it's
helpful
for
us
I
guess
to
know
that
we
can
we're
not
blocked
on
Kaz
Canary,
but
I,
wonder
in
terms
of
kind
of
future
planning
like
does
that
help
us,
or
does
that
kind
of
add
complexity?
If
that
makes
sense
you
know
like,
would
it
is
it
more?
Is
it
easier
for
us
to
go
okay,
we
want
people
to
move
through
things
in
this
way
versus
having
people
just
dropping
in
and
saying,
I
want
step,
five.
A
Yeah,
that's
the
point
right
so
because
we
care
about
the
initial
steps
so,
for
instance,
Auto
deploy
an
automated
rule
out,
but
this
is
not
of
any
concern
for
developers.
They
want
automated
releases,
which
has
no
dependency
on
the
other
one,
but
then,
if
they
actually
want
independent
deployment,
they
need
to
to
have
all
of
them
right.
So
what
I'm
saying
is
that
I
don't
want
to
force
process
on
people,
because
when
we
said
people
do
you
need
to
implement
the
QA
because
you
want
to
get
into
Auto
deploy?
D
Yeah
I
I
do
agree
with
what
you're
saying
so.
Maybe
it's
an
iterative
approach,
then
we
want
to
Define
these
things
and
then
maybe
want
to
talk
about
requirement
like
I,
I,
I,
I
kind
of
agree
with
what
you're
saying
but
I
think
if
we
can
it'll
be
easier
to
see
how
they
relate
to
each
other
and
their
requirements,
if
we
can
Define
them
first
yeah.
A
A
So
everyone
has
its
own
need
the
most
important
they
may.
They
may
find
time
to
implement
one
of
that
and
then
they
they.
Basically
we
are
upselling,
but
instead
of
having
a
linear
path,
when
you
say
you
need
to
do
this
this
and
that
the
entry
point
is
easier,
you
can
choose
what
is
most
valuable
to
you
as
a
development
team.
But
then
you
experience
the
benefit,
and
maybe
you
want
to
to
get
the
extra
implementation
and
move
on
to
the
a
complete
independent
deployment.
A
C
C
Awesome
one
thing
I
would
like
as
to
sort
of
be
starting
to
work
on,
is
I,
don't
mind
if
it's,
if
it's
cars
or
or
pages,
but
I
would
like
us
to
get
an
epic
set
up
for
moving
like
getting
epic
and
getting
issues
trying
to
get
that
set
up
for
moving
to
the
automated
releases
per
stage.
I,
don't
know
if
we
know
enough,
we
might
it
might
be
that
we
start
writing
it
and
we
don't
know
all
the
pieces.
D
Agree,
I
think
I
think
that
has
possibly
been
the
key
piece.
If
we,
if
we
start
fleshing
them
out,
what
will
happen
is
when
we
get
stuck
on
them.
Then
we
drive
back
to
the
analysis,
epic,
like
then
we're
like.
Okay,
we're
getting
stuck.
You
know.
What's
going
on,
we
drive
back
to
the
analysis,
epic.
Maybe
we
do
some
code
jumping
then,
because
you
know
somewhere
buried
in
some
class.
There
was
like
something
for
Italy
that
we
completely
missed
or
something,
but
it
at
least
then
it
does
Drive.
C
Okay,
that
makes
sense
so
should
we
aim
then
does
for
like
next
Wednesday
is
a
kind
of
deadline
to
get
the
definitions
of
done,
and
hopefully
that
gives
us
also
an
end
point
on
the
analysis
because
we'll
be
like
okay,
we
know
enough
focusing
on
the
auto
releases
and
auto
deploy
just
for
Chasm
pages.
D
C
D
Yeah
yeah
sure
I
think
that
I
thought
that
one
still
had
like
no
description
or
whatever,
but
I
haven't
looked
at
it
in
a
while.
So
that's
fine,
but
yeah
anyway.
We've
got
the
Epic
for
that
and
then
we
just
need
two
more
then
one
for
this.
Well,
we've
got
to
Define
what
we're
going
to
call
this
and
then
we
should
have
an
epic
saying:
delivery
delivery
defined
releasing
or
whatever
it
is.
We
want.
C
D
It
four
or
four
pages
and
then
delivery
defined
releasing
for
delivery
controls
releasing
for
cars,
yeah
exactly
and
then
yeah
the
cas
ones.
We
can
still
work
independently
because
I
think
the
case
one
will
take.
The
auto
deployment
will
take
a
bit
longer
that
we
can
probably
start
moving
the
release,
part
for
them
quicker
and
I.
I
know
they're
off
at
the
moment.
So
it's
going
to
be
a
bit
tricky,
but
I
still
think
if
we
get
enough
ready
so
as
soon
as
we're
back
from
holiday.
D
D
We
can
focus
on
pages
as
the
first
one
that
we
actually
kind
of
and
I
think
once
again,
without
digging
into
too
much
depth.
We're
actually
gonna
have
to
like
hack
into
code
on
release,
tools
and
stuff
right
unless
you
like,
when
we
actually
do
this,
like
we're,
going
to
have
to
kind
of
start,
because
they're
going
to
have
to
because
we've
got
to
do
the
automated
branches
and
stuff.
So
we're
actually.
D
C
D
C
D
Which
we
can't
get
there
all
the
way
yet,
but
yes,
you're
right
as
we
do
two
components,
we
would
hope
that,
even
if
we
do
component
specific
classes,
they
should
look
almost
similar
that
we
could.
We
could
start
trying
to
you
know
in
the
future
squeeze
that
down.
So
we
don't
don't.
The
concept
of
a
component
class
just
doesn't
exist.
C
C
Cool
so
I
put
those
epics
under
BNC
I
won't
assign
them
to
anyone.
Just
now,
like
we'll
focus
on
doing
the
naming
and
the
definitions,
but
like
once,
we've
got
those.
If
anyone
wants
to
jump
on
and
get
on
get,
but
one
or
two
set
up,
then
just
please
go
for
it
right.
We
don't
have
an
epic
right
now.
C
Right,
I
think
we're
done
we're
at
time.
Thanks
for
the
discussions,
everyone,
let
us
stick
up
a
doc,
Graham
ping,
us
all
in
there
and
let's
see
if
we
can
get
some
definitions,
not
Ted.