►
From YouTube: Plan & Release Management: Milestones & Releases
Description
In this video we discuss how to accomplish a planned vs actual delivery metrics with GitLab by using Milestone Timeboxes and Releases
A
A
Those
and
couple
them
Mike
and
I
were
talking
earlier
today
that
we,
we
think,
releases
our
milestone
type,
because
release
is
our
moment
in
time
for
your
code,
but
wanting
to
make
sure
that
we
still
are
allowing
our
customers
to
understand
the
prescriptive
use
case
of
what
our
releases
and
how
to
use
it
properly.
And
what
that
means
when
we
introduce
other
milestone
types.
So.
B
Yeah
there's
some
interesting
conversation
about
this,
because
I
think
it
is
a
milestone
type,
but
it's
different.
It's
not
necessarily
like
a
releases
in
a
time
box
per
se.
All
the
like
the
time
boxes,
all
the
events
that
your
things
are
playing,
you
included
in
the
release
and
when
you're
working
on
them,
but
like
I,
just
get
a
little
confused
cuz
release
is
like
a
tag.
B
It's
like
a
snapshot
in
history
about
your
code
at
any
given
point
in
time,
which
is
the
culmination
of
all
the
issues
and
merge
requests
that
neither
work
not
over
like
a
given
time
period
and
that's
where,
like
I,
don't
want
to
duplicate
effort
here
but
like
I,
also
want
to
figure
it
out
because
I
don't
know.
If
you
saw
on
that
one
issue
the
this
is
in
the
release
project
where,
yes,
they
view
milestones
in
key
lab
as
they
release
a
lot
of
organizations.
B
B
A
So
from
a
vision
perspective
and
what's
an
immediate
future
for
release
capabilities,
my
understanding
of
releases
is
to
be
able
to
show
the
collection
of
an
issue
that
could
span
multiple
versions
or
be
a
moment
in
time
for
various
applications
within
a
same
same
repo.
If
you
have
that
so
it's
very
flexible
to
accommodate
within
any
given
project
how
a
company
is
releasing
code
committing
patches
to
that
version.
A
For
example.
If
on
that
summary
page
and
their
releases,
you
have
released
V
12.6
released
V
12.54
and
you
want
to
show
the
comparisons
between
release
12.4
and
release
12.6.
You
can
link
to
those
separate
issues,
and
today
you
can
only
link
to
the
page.
You
can't
really
linked
to
a
specific
release
inside
that
page.
So
that's
the
purpose
of
creating
a
view
only
page
and
then,
as
we
start
to
talk
to
more
customers
about
how
they
want
to
see
releases.
A
There
could
be
a
case
where,
in
that
view
of
a
release,
they
may
indicate
that
that
release
is
shared
across
other
groups
and
projects.
So
we
have
other
issues
that
are
linking
back
to
the
same
release,
API
or
tag,
so
it
could
be
redundant
across
groups
and
projects,
and
that
would
give
them
the
picture
of
hey.
I
have
a
gait
lab
instance,
and,
in
since
environments,
aren't
really
shared
across
its
groups.
This
would
be
one
way
to
leverage
the
releases
API
to
show
versions
across
multiple
multiple
groups.
B
A
To
Alexis
I
was
wondering
if
there's
ways
that
we
can
carve
out-
or
we
make
releases
like
a
mandatory,
milestone,
type
a
mandatory
time
box
and
have
that
be.
This
is
how
you
specify
a
version,
and
you
can
set
like
start
date
and
end
date
within
a
release,
so
that
could
be
an
option,
but
I'm
not
sure
it
might
might
be
helpful
to
understand.
A
B
So
within
our
release
kittens
we
have
four
weeks
basically
until
what
if
my
team
want
to
have
two
two-week
sprints,
where
we
like
committed
the
smaller
chunks
to
work
with
each
one,
that's
one
that
I
personally
would
like
to
see
us
do
another
one
would
be
one
of
our
larger
customers,
like
I,
said
they
do
their
planning
on
the
team
level
in
two
weaknesses,
and
then
they
have
quarterly
Department
or
organizational
goals
that
they
want
to
track.
Issues
against
as
well.
B
So
like
there's
like
these
two
they're
related
but
they're,
separate
like
where
you
will
have
one
roll
up
to
another,
and
the
team
just
wants
to
look
at
their
own
goals
and
and
within
each
that
within
each
of
those.
The
way
we're
going
to
span
milestones
or
time
boxes
so
that
once
a
time
box
type
is
related,
we
can
calculate
velocity
over
them
and
we
can
do
things
like
volatility
and
shows
showing
like
okay,
knowing
over
the
last
five
Sprint's.
For
example,
you
got
an
average
of
55.
B
Wait
done
each
sprint
this
next
one
when
you're
going
in
and
planning
now
like
within
your
planning
board
or
wherever
we
can
start
to
show
indicator.
Saying
like
okay.
Well,
you
you're
at
your
capacity
like
that
you
can't
do
any
more
work
based
on
you're,
just
helping
teams
get
away
from
using
spreadsheets
reporting.
That's
what
they're
doing
right
now
like
I,
was
on
a
call
earlier
to
the
customer,
and
they
showed
me
all
the
spreadsheets
that
they
manually
create
based
off
of
data
within
get
lab
and
part
of
the
reasons
why
I
do.
B
That
is
because
they
can't
use
milestones
because
they
don't
treat.
Issues
is
done
when
they're
closed
or
they
don't
close
issues
when
they're
done,
they
leave
them
open
for
another
team
to
take
over,
so
they
can
track
their
own.
Like
personal
loss,
we
didn't
get
lot
because
we
can't
let
them
specify
when
something
is
technically
done.
Well,
which
burned
our
chamber
records
and
a
scope
has
changed
involved
in
all
that.
B
And
I
think
that's
where,
if
it
releases
we're
to
be
a
milestone
type,
for
example,
where
you
could
start
dating
and
date,
that's
where,
like
it
doesn't
do
it
way.
Now
it's
like
a
point
in
time
that
you
create
snapshot
via
API,
but
if
you
want
to
start
planning
ahead
of
time
associated
issues
to
be
given
release,
then
you
need
the
ability
to
do
that,
which
is
that
one
that
it
just
becomes.
It
is
like
a
more
or
less
like
time
box
that
you
playing
against
that
makes
sense.
Yeah.
A
If
you
can
create
an
upcoming
release
and
an
upcoming
release
is
a
future
release.
Okay,
so
that
capability
of
having
a
release
created
and
sitting
out
there
until
you
mark
it
as
done
or
until
it's
delivered,
and
when
you,
when
you
actually
execute
your
deployment,
you're
right
that
it's
a
snapshot
in
time.
But
you
can,
you
can
create
releases
in
the
future
for
a
future
release
like
for
acetic
employment.
So
I
think
what
I'm
trying
to
reconcile
here
is:
how
can
we
just
serve
people
to
use
milestone?
A
Types
like
maybe
releases,
are
the
two-week
incrementing
planning
and
then
there's
like
a
milestone
type
that
captures
at
a
larger
instance,
level
or
group
level
feeds
the
time
box,
of
which
it
releases
is
indicating
a
snapshot
of
time
for
ya.
I
connect
deployments
to
your
planning,
I
think,
is
what
I'm
trying
to
ask
yeah.
B
That's
where
it
all
must
be
ideal,
if
you
think
about
like
promises
where
an
issue
is
the
implementation
details
in
the
merge
requests
and
the
merge,
the
code
getting
merged
into
master
is
kind
of
like
the
fulfillment
of
an
issue
or
part
of
an
issue.
It
almost
be
nice
to
figure
out
how
to
take
like
really
like
keep
milestones,
is
a
complaining
type
thing
and
then
sharing
releases
is
the
I
guess,
compliance
like
verification
of
what
actually
was
completed
and
then
BL
see
the
different
was
planned
versus
what
was
actually
delivered.
B
Because
right
now,
on
the
milestone
page,
we
have
like
we
show
issues,
but
then
we
also
say
merge
requests.
And
then
we
have
a
section
about
like
participant
labels,
but
it
would
be
nice
to
be
able
to
say,
like
with
any
given
occurs.
Everything
these
plans
so
milestones
are
the
planning.
And
then
you
associate
a
release
which
then
like
verifies
the
X
number
of
issues,
and
that.
B
So
I
don't
know
how
you
want
to
work
it,
but
I
would
be
like
I,
don't
like
all
a
lot
of
the
informations
on
the
milestone.
You
need
to
be
reworked
anyways,
and
since
we
can
associate
releases
to
milestones
now,
we
just
need
to
figure
out
how
like
to
tie
those
things
together,
because
within
a
merge
request,
you
can
associate
to
an
Austin,
but
it's
almost
like
I
would
want
the
merge
request
to
be
associated
to
release,
not
a
milestone.
B
A
B
That's
what
I
would
like
it
make
sense
to
me.
I
think
right
now,
there's
also
I,
don't
know,
there's
a
super
tight
coupling
between
issues.
Emergent
costs
like
you
can
do
related,
but
it's
almost
like
I
can
relate
emergent,
question
issue
that
has
nothing
to
do
with
it
and
it's
a
like
I
wanted
more
tight
coupling
and
promise
between
the
merge
requests
and
what
specific
things
within
an
issue
it
satisfies
and
I
think
another
use
cases
your
being
ready
to
add
like
issue
tasks
and
task
list
issues.
B
A
A
The
deployment
is
in
an
audit
sense
in
like
a
compliance
sense
and
what
releases
are
supposed
to
help
satisfy
for
our
users
is
you're
able
to
see
the
why
a
change
was
made
to
production
and
then
that
change
was
made.
Yes,
today,
it's
very
hard
to
connect
the
issue
in
the
merge
requests.
So
why
the
issue
what
was
made?
A
So
that's
one
issue
that
we're
looking
at
making
making
a
change
to
bring
the
merge
request
information
to
deployment
information
into
that
issue,
but
I
think
then
that
means,
if
everything
is
contains,
then
the
release
object
related
to
deployments
environments.
We
just
have
to
figure
out.
How
do
we
connect
that
information
meaningfully
back
to
the
milestone?
Okay,
yeah,
so
that
you're
agnostic
to
merge
requests,
because
all
of
the
information
and
relationships
are
contained
within
release.
C
A
C
D
The
planet
works
today,
but
if
you
look
at
the
vision
of
like
true
CD
right,
releasers,
don't
to
zero
like
there,
there
are
no
releases.
Essentially,
every
merger
quest
is
a
release
at
that
point.
So
in
that
sense,
like
you
have
to
be
weird
to
force
people
to
have
to
have
releases
simply
to
be
able
to
tie
that
together
right,
the
milestone
being
tine
box
model
makes
more
sense
than
a
true
CD,
where
every
single
commit
is
essentially
a
release.
Yeah
good
point,
I.
A
Would
say
like
this
is
where
releases
right
now
they're
a
collection
of
issues
that
people
are
indicating
as
groups
together
as
a
single
representation
of
a
chain
connection.
So
this
is
where
it's
associated
to
a
my
also
to
indicate
this
is
the
time
frame
that
we're
taking
a
snapshot
for
us.
It's
just
about
evidence
that
you
need
to
create
for
your
Onix
right.
B
B
Because,
like
you
said
I,
think
of
this,
for
you
like
NCI
CDs,
you
continuous
delivery,
you
would
be
pushing
directly
a
master,
but
at
some
point
you
still
had
the
code
base
is
stable.
You
know
like
you're,
you
can
see
there
your
nightly
build,
which
is
sort
of
like
what
we
deal
with
to
marry,
and
then
you
have
the
stable
branch.
D
A
I
also
think
that
release
fits
a
very
good
model
for
companies
who
are
continuously
delivering
and
that
they
are
releasing
code
all
the
time
to
master,
but
it's
behind
a
feature
flag
and
then
once
they
do
a
market
announcement,
they
then
unleash
that
change
to
their
production
environment
and
that's
the
version
that
they're
declaring
and
they
change
that
like
that.
That's
the
marketable
change,
so
they
still
consider
themselves
leveraging
CI
CD,
because
they're
big
they
can
they
could
deploy
to
production
for
master.
B
So
that
way
like
it's
ambiguous
of
like
whether
something's
it's
everything
when
shakes
production,
universe
behind
each
a
flag
and
when
a
Premier
Li
roll
it
out
via
another
web
UI
enable
it
remotely
so-
and
it
seems
like
if,
like
Alexis
and
I,
were
talking
about
how
we
were
gonna,
do
naming
like
what
the
names
were
and
we're
starting
with
three
milestone
types:
one
we're
gonna
leave
who's
milestone,
so
we
don't
like
to
shop
for
flow.
How
people
are
currently
looking.
You
know
great
I
mean
the
other.
B
Two
that
would
make
sense
would
be
like
and
version,
and
that
way,
like
you,
gotta,
have
your
short,
short
time
box.
It's
like
a
sprint.
Your
milestone
is
more
like
a
quarterly
type
thing,
and
then
your
birthing
is
targeting
specific
version
of
software,
but
beyond
like
how
we
like
I,
just
don't
want
to
duplicate
effort
where,
like
when
you
create,
create
a
release.
You
also
thing
like
a
time
box
and
then
yeah.
B
A
I
could
in
like
you
might
specify
versions.
The
thing
about
releases
is
that
we
could
have
multiple
tags
and
inversions
milestones
insider
release,
so
maybe
there's
some
some
containing
that
we
need
to
do
there
like
that.
Maybe
there's
some
prescription
and
documentation
that
we
write
once
we
release
milestone
types
like
this
is
how
you
should
use
releases
with
milestone
types
mainly
because
if
it
is
that
hey
as
a
user,
you
enable
these
three
default
flavors
of
milestone
types,
and
you
want
to
use
them
to
time
box
sets.
A
B
Needed
like
on
the
fence
about,
actually
they
got
wanting
to
allow
users
to
customize
the
names,
but
if
we
don't
allow
them
to
customize
names,
then
we
could
deviate
and
have
like
special
characteristics
for
each
mouse
one
time.
So,
even
if
like,
if
it's
on
the
version
and
they
wanted
to
create
a
new
version
milestone
and
they
exist,
they
could
create
that
new
version
directly
from
within,
like
when
they're
setting
up
that
milestone
and
they
would
show
up
and
releases
as
well.
So
you
could
have
like
either
pick
one
or
great
one.
You
know.
A
So
the
Capitol
our
releases
functionalities
in
get
lab
today,
Keppel,
are
this
release.
Page
is
a
tag.
It
contains
issues,
it's
related
to
a
milestone.
Okay,
if
we
say
sorry
I'm
thinking
out
loud
here,
cuz
I'm,
trying
to
figure
out
how
do
we
like
decouple
while
being
prescriptive
to
customers
and
sorry,
if
that's
frustrating,
and
so
if
we
were
to
prescribe
to
our
users
that
they
must
leverage
our
milestone
heights,
to
specify
the
name
of
a
tag
or
to
time
box
or
release.
A
We
could
we
could
say
that
that's
how
you
use
milestone
types
and
releases
together,
given
that
releases
are
to
signify
deployments
and
moments
in
time
of
the
code
and
milestone
types
are
a
planning
mechanism.
I
just
want
to
make
sure
that
we
don't
undermine
either
functionality,
because
people
could
plan
releases
by
Justice,
OCC
issues
to
release
and
then
continue
to
create
versions
and
tags
and
not
lever
it
to
milestone
types,
or
they
would
only
leverage
milestone
types
and
never
touch
the
releases.
Api.
B
D
D
What
didn't
and
the
success
rates
and
associated
with
this
associated
with
that
I,
don't
think
there
is
a
much
of
a
delta
except
for
who's,
the
parent,
maybe
of
like
what
you
would
ideally
want
on
a
milestone
page
and
ideally
want
on
the
release
page,
which
leads
me
back
to
this
like.
Is
there
even
any
sense
in
trying
to
have
a
separation
between
you,
two,
maybe
right,
because
they
both
exist
now,
and
you
don't
want
to
alienate
people,
but
those
pages,
in
my
opinion,
would
have
the
almost
the
exact
same
data
on
them.
D
B
They're
slightly
different
in
talking
with
meirin,
he
was
like
I
think
it'd
be
nice
to
see
a
couple
like
you're
planning
versus
what
actually
all
the
work
and
effort
that
went
into
a
given
release
right
or
given
version
of
your
software
and
so
I.
Think.
That's
where,
like
from
my
standpoint,
I
care
the
most
about
making
sure
that
we
have
like
milestones
your
time
boxes
like
it's,
a
recurring
cadence
like
it's
on
the
kind
of
a
fixed
schedule,
but
like
whether
it's
every
two
weeks
or
every
quarter.
B
It's
like
the
thing
that
recurs
and
because
it
recurs
you
can
establish
capacity
planning
and
allocate
target
issues.
You
want
to
work
on
to
a
given
time
box
now
or
in
the
future
and
my
plan,
all
of
your
work
out
and
I
think
that's
where,
like
maybe
we
do
duplicate
some
information
between
two
or
maybe
like.
We
only
show
like
merge
request
is
part
of
like
what's
in
a
given
release
and
then
issues
you're
part
of
like
the
mouse
and
make
sense
so.
A
Issues
will
need
to
still
be
included
in
releases
so
that
we
can
show
the
why,
for
the
audit
trail
and
the
change
was
committed,
but
other
than
that
like
as
long
as
we
can
show
that
that
relationship
inside
the
evidence
of
a
release,
then
we
set
by
the
requirements
for
compliance.
Yeah,
I'm,
gonna,
head
Mike.
D
I,
don't
want
to
beat
a
dead
horse,
but
I
feel
like
bad
exercise,
but
you
just
said
there
I'm
telling
you
maybe
we
should
just
go
through
him,
but
like
yep,
we
want
to
see
merge,
assess
yep.
We
want
to
see
it's.
You
know
like
I'm,
pretty
sure
the
the
data
is
going
to
be
the
same.
There's
an
argument
to
be
made.
I
think.
A
The
milestones
are
planning
mechanism
and
in
order
to
surface
to
an
end-user
plan
versus
actual,
we
need
to
be
able
to
represent
what
was
delivered
and
the
releases
are
the
moment
in
time.
When
your
issues
merge
requests
have
been
delivered.
So
if
we
think
in
practice
say
that
I'm
going
down
with
milestone
planning
and
oh,
we
identified
a
issue
that
needs
a
hotfix.
A
release
is
gonna
go
out
right
now,
regardless
of
the
milestone
planning
cadence,
that
we
would
need
to
show
that
12.6
had
a
sub
release.
D
A
If
we
look
at
the
UI
of
the
release
page
currently,
the
release
page
just
has
a
series
of
rows
and
boxes,
of
course,
code
relevant
artifacts
and
a
release
and
elique
evidence.
So
each
of
those
blocks
are
going
to
contain
their
own
version.
There
will
be
a
link
to
that
that
relief
version
that
will
then
pop
open
a
new
view
page,
which
is
hopefully
going
to
be
delivering
12.9.
This
page
will
contain
an
issue
summary
that
shows
the
progress
of
those
issues
within
that
release.
A
If
you
created
the
release
before
the
deployment
and
if
the
release
is
completed,
show
that's
the
issue,
progress,
a
hundred
percent
that
the
release
has
been
completed,
and
this
could
be
then
cooled
into
a
view
milestone
page
to
show
hey
at
the
end
of
my
milestone
planning.
This
was
the
release
that
showed
what
we've
completed,
which
is
what
we
planned
at
the
beginning,
they're
like
two
snapshots
in
time.
Right.
B
A
E
B
Why
would
you
so
I
have
maybe
changes?
Why
would
you
only
do
it
in
the
releases
page?
It's
the
same
problem
that
we
ran
into.
If
it's
where,
when
we
create
bits,
you
can
only
add
an
issue
to
an
epic
through
the
epic
view,
instead
of
like
I'm
on
an
issue
and
I'm
gonna,
associate
it
I'm,
gonna
search
for
the
epic
and
I'm
an
associate
to
like
within
the
issue
view.
So
then
you
either
like
copy
the
copy,
the
URL
go
to
the
epic
be
pasted
in,
and
then
click
Add,
which
was
like
super
clunky.
A
A
B
A
I
agree,
so
that
makes
sense
we
would
want
to
be
able
to
today.
The
first
iteration
that
we
have
represented
in
our
mocks
is
that
you
create
release
page,
and
you
have
the
ability
to
associate
issues,
but
I.
Don't
think
that
that
ties
back
to
the
issue
screen
so
that
he'll
be
a
follow
up
for
me
to
ask
Iona,
because
then
we
probably
want
to
iterate
on
that.
If
it
issue
is
associated
with
the
release,
that
means
to
do
surfaced
in
the
issue.
How.
B
A
E
A
B
Comes
from,
like
the
background
of
some
agile
planning
methodologies,
like
I,
know,
one
ace
extreme
programming
which
I
used
before
from
the
gate
lab
and
the
way
the
Kings
works.
There
is
you
have
vision,
and
then
you
break
everything
down
into
four
week
releases
like
high-level
epics,
and
then
you
break
that
down
into
one
week
iterations
and
you
work
in
one
week
iteration
cycles,
and
then
you
reset
it
four
weeks
ago.
B
A
Yeah
and
I
think
that,
from
the
release
manager
side,
we
are
in
the
world
of
talking
about.
How
do
you
coordinate
deployment,
at
least
for
our
tool,
since
a
release
is
a
snapshot
of
time
for
your
given
deployment
or
the
code
that
you're
expecting
to
deploy.
So
it's
a
little
bit
different
than
when
I
work
at
other
companies.
Release
management?
Being
this
huge
orchestration,
including
portfolio
management,
a
bunch
of
upstream
activities
but
I,
think
it's
a
relevant
question
in
that?
Yes,
capital.
A
A
A
A
B
I
think
there's
also
the
case
where
a
specified
person
will
naturally
or
could
naturally
span
multiple
to
like
time
boxes
so
like
it
is
a
different
sort
of
use
case,
especially
compliance
and
nice
boys
like
you,
and
look
at
something
in
it's
like
not
connected
whatsoever
to
a
plane
in
kingdoms,
but
like
it's
just
an
exceptional
time
and
and
how
it
got
there.
And
why,
even
though,
like
you
know,
we
could
have
like
I
think
it
lab.
We
maintain.
B
The
proposal
now
is
to
keep
milestones
open
for
three
months,
even
though
we're
mostly
done
with
them
up
for
one
month.
So
that
way,
any
like
topics,
crashes,
like
attractions,
can
be
added
to
that
parent,
like
minor
virgin
milestone,
which
is
fairly
like
not
valuable
from
a
playing
standpoint
since
it
except
your
capacity
for
your
team.
So
like
I,
don't
know
the
best
way
to
solve
it.
B
I
think
we
should
keep
looking
at
I
think
there
is
a
unique
opportunity
to
have
release
with
the
capo
RB,
like
part
of
the
compliance
of
like
what
was
actually
delivered
in
a
given
time
box,
and
it
be
kind
of
cool
to
see
that
and
if
that
happened,
I
would
expect
the
other
within
an
issue
specify
that
it
was
part
of
you
know,
whatever
version
or
with
an
emergency
price.
It
was
part
of
whatever
version.
Maybe
it
makes
more
sense.
A
E
C
A
An
interview,
the
milestone
types
are
planning,
commerce
and
I
can
look
at
the
the
downstream
impacts
in
the
audit
conversation
of
excluding
issues,
naturally
from
a
release.
This
might
change
something
that
we
we
have
currently
scheduled,
which
is
an
issue
show
issue
summary
on
release
page,
which
is
release
or
assigned
to
release
here's
the
progress,
and
maybe
we
actually
change
that
to
merge
request.
A
B
Requirements
means
right,
we're
being
certified,
there's
a
whole
point.
There
was
just
a
traceability
from
like
a
requirement,
which
is
this,
like
Longwood
thing,
to
an
issue
that
talks
about
implementation
to
emerge,
request
which
implements
it
to
a
test
which
then
traces
that
the
requirements
true
or
like
fulfilled
so
that'll
be
another
things
they
just
like
think
about
as
okay
like
I.
Don't
we
more
tightly
couple
of
these
things
because
I
think
you're
gonna
want
like,
while
an
issues
like
a
planning
type
thing,
and
the
merge
request
satisfies
like
that
plan?
A
B
It's
fine
like
I,
wouldn't
change
anything
like
we
can
continue
like
evolved
things
and
buts.
Happy
promise
strategic
conversations
about
how
they
emerge
and
how
we
want
to
be
intentional
about
that,
because
I
think
from
a
compliance
standpoint,
you're
they're
gonna
want
to
see
where
they
come
from
and
which
the
context
around
that
the
merge
request
satisfies
the
attacks.
The
you
know.
The
audit
logs
showed
the
trail
of
how
everything
pretty
much.
B
A
B
Really
this
is
like
building
a
product
and
being
a
team
we're
just
like
to
do
what's
best
for
the
customer,
because
their
product
I
don't
care
about
mice.
Now
I
mean
they
can
that's
not
even
really
but
yeah,
whatever
is
best
for
the
customers,
invest
for
you
know
the
business
and
down
port.
So
that's.