►
From YouTube: 12.8 Planning Release: Progressive Delivery group
Description
A recording of our team planning for 12.8
Stage: Release
Group: Progressive Delivery
A
Okay,
so
welcome
to
12.8
planning
the
team
meeting
planning
we're
not
yet
using
the
new
process
that
we're
going
to
be
displaying
in
the
team
meeting
tomorrow,
I
think
or
maybe
the
next
day,
so
we're
still
gonna
plan
this
as
we
did
before.
So
we
have
our
famous
12.8
board,
which
is
divided
into
different
columns,
we'll
start
by
talking
about
the
envy
scenes
or
MVPs
or
whatever
we
decided
to
call
it
for
this
release
of
their
release.
A
So
there's
three
of
them.
We
have
one
support,
predefined
types,
AWS,
environment
variables,
and
this
ties
nice
nicely
into
the
natively
supporting
cloud
theme
that
we
have
going
on.
We
started
in
the
last
release
by
deploying
the
first
AWS
compatible
container
image
from,
but
that's
managed
by
given.
This
is
a
continuation.
A
We're
gonna,
see
in
the
next
few
releases,
also
some
more
building
blocks
related
to
AWS
deployment,
and
this
one
lets
you
predefined
these
environments
under
the
CI
CD
variables,
and
you
can
basically
just
select
AWS
and
you'll,
have
an
option
to
choose
these
values
from
a
predefined
list.
So
this
is
the
first
issue.
A
The
second
one
is
allow
only
forward
deployments,
which
is
for
the
entire
pipeline,
not
only
merge
changes
for
every
kind
of
merge
request,
and
last
but
not
least,
we
have
group
deploy
tokens
which
will
allow
you
to
have
joint
keys
between
different
projects.
So
those
are
the
top
three
items
of
the
release.
A
Waited
three
to
six:
kick
that
in
mind.
We
have
quite
a
few
bugs
in
this
release.
We
have
four
I'm,
not
sure
about
the
spillover
from
12.7
yet,
but
maybe
you
will
have
some
more
well
when
the
highest
priority
in
terms
of
the
bugs.
Besides
at
the
severity
and
priority
labels,
our
merge
trains,
I,
don't
know
if
if
you
were
following,
but
we
disabled
merge
trains
again
due
to
these
two
bugs,
so
we
need
to
fix
them
and
re-enable
them
again.
A
Moving
on,
we
have
continuation
from
the
previous
solution,
validation
that
we
haven't
completed
yet
for
research.
So
that's
the
first
class
for
view
apps,
which
is
kind
of
going
through
all
the
insights
that
we
have
from
the
previous
research
and
deciding
what
our
next
steps
in
terms
of
relapse
will
be
and.
C
B
A
Okay,
and
maybe
it
just
doesn't-
have
a
bug
label
or
something
silly
yeah,
okay,
so
under
the
design
column,
which
is
things
that
are
currently
under
UX
review,
slash
work.
We
have
MIRR
strange
to
support
fast
forward
emerge.
So
this
is
a
combination
between
our
MVP
item
of
forward
of
supporting
cuss
part
with
a
combination
of
merged
trains.
There's
a
little
bit
of
a
nuance
over
there.
That
needs
some
attention.
A
Support
the
predefined
AWS
environment,
which
we
discussed
and
improve
messaging
on
pipelines
for
emergent
results.
So
this
one
is
a
an
item.
That's
been
following
us
around
for
a
few
for
a
few
releases
in
Vienna
really
wants
to
get
this
done
in
this
release.
So
we're
gonna
get
this
done
in
this
release.
A
D
I,
just
didn't
really
quickly,
I
think
that's
not
in
planning
breakdown,
anymore,
I.
Think
we've
resolved
our
answer
and
it's
just
ready
for
death
or
in
dev,
depending
on
how
you
look
at
it
but
yeah
it
doesn't.
It
doesn't
need
to
be
broken
down.
We
last
week
got
to
a
solution
and
I
think
everyone's
really
happy
with.
D
Ninety
percent
of
the
work
it
doesn't
matter
what
we
end
up
saying
in
the
end,
it's
more
that
we
decided
to
do.
One
thing
I
mean
this
is
sort
of
a
weird
issue.
It's
a
little
sad
in
some
ways
that,
like
we
decided
to
do
something
and
did
a
bunch
of
work
so
make
that
thing
possible
and
then,
when
it
existed
further
up
the
line
people
were
like.
No,
we
didn't
actually
want
that.
B
A
A
A
Okay,
so
the
first
item
we
have
is
true,
truly
dynamic.
Environment
URL-
and
this
is
I
would
say
on
the
top
three
of
the
popular
issues
asked
by
customers.
It's
an
addition
for
Jim
review
acts,
and
this
is
something
that
wouldn't
everyone
who
was
on
break
Camilla
and
I
delve
into
this
issue
and
got
a
that
proposal.
That
looked
that
we
were
happy
with,
and
so
was
the
community.
So
I'm
really
happy
to
be
able
to
tackle
this.
It's
in
scheduling
because
we
do
have
quite
a
bit
of
other
issues.
A
A
A
This
is
tied
in
to
the
new
reflector
of
UX
that
we
did
for
future
files,
and
this
is
like
the
foundation
of
everything.
So
before
we
get
these
two
items,
there's
no
point
and
freaking
on
anything
else.
So
that's
the
couple
new
feature:
flag
environments
and
strategies
and
multiple
strategies
for
environment.
So
these
are
two
really
important
masses
and
I
think
they're.
A
The
only
ones
scheduled
for
this
release,
but
we'll
see
when
we
go
back
when
we
go
forward
in
the
next
column-
and
this
is
a
bug
that
also
has
I-
think
it
was
following
us
for
also
a
few
releases
record
staff
actions
of
the
plugins
so
we'll
see
if
we
can
get
to
that
to
merge.
Trains
is
more
important
questions
on
scheduling,
I.
C
B
Jason
Jason's
out
today,
I
think
yeah.
All
this
stuff
sort
of
depends
on
that.
So
last
I
checked
I
think
we
were
getting
close,
but
I
think
we
we've
been
close
a
couple
times
and
had
to
go
back
to
the
drawing
board.
I
I
feel
like
we
gotta
get
that
resolved
this
week.
One
way
or
another
so
like
I'll
continue
to
work
with
him
on
getting
that
sorted
out.
I
guess.
A
B
A
B
Mean
you
know
it's:
it's
trying
to
account
for
a
bunch
of
edge
cases
that,
like
you
know
in
a
world
where
we
have
a
lot
of
content
in
those
tables,
would
would
be
important,
but
I
think
the
utilization
is
very
low
right
now,
so
we
will
probably
just
have
to
make
it
a
bit
of
a
compromise
and
and
sort
of
deal
with
the
side
effects
if
they
it
all
occur.
So,
but
that's
that's
on
my
list
of
things
to
work
with
him
on
when
he's
back
tomorrow.
A
A
B
E
D
A
Number,
so
that's
what
we
want
to
do
in
this
issue,
and
next
one
is
an
issue
that
we'll
discuss
in
length.
You
know
in
our
weekly
meeting,
but
this
is
part
of
the
new
process
and
basically
it's
part
of
and
I
don't
want
to
open
this
for
discussion
and
in
the
planning.
I
want
to
talk
about
it
in
the
weekly,
but
just
so
you
guys
are
not
on
pins
and
needles.
A
We
we
gave
each
engineer
about
four
issues
to
wait
in
this
release
that
need
to
be
waited
for
the
next
one
so
that
we
can
plan
capacity
accordingly
for
12.9,
and
this
issue
should
be
done
by
the
end
of
the
release.
So
it's
it's
up
to
you
when
you
do
it,
but
but
it
needs
to
be
done
by
the
end
of
the
release.
But
since
I
haven't
talked
to
chase
and
Darby
about
this
specific
one,
I
don't
want
to
go
into
it
in
detail.
A
A
And
that
is
everything
that
is
involved
on
age,
and
you
can
see
that
it's
a
smaller
release,
we're
trying
to
find
the
optimal
number
of
things
that
we
can
do
and
not
be
depressed
about
over
allocating
stuff
that
we.
So
this
is
an
attempt
for
us
to
to
feel
confident
about
what
we're
planning
and
delivery
I.
B
A
F
C
A
A
B
Instead
of
having
like
a
like
a
hard
cut
because
I
think
that's,
it's
gonna
be
hard
to
do
that
with
with
the
way
that
we're
doing
it
now.
So,
if
we
just
start
to
like
fill
up
that
backlog
with
you
know
sort
of
the
next
items,
we
could
just
fill
that
with.
What's
in
the
scheduling
column
now
and
say,
if
you
finish
everything,
that's
in
you
know
ready
for
dev,
then
you,
you
pull
the
next
top
item
from
there.
So.
A
You,
where
we,
where
the
scheduling
what
everything
in
the
scheduling
board,
would
be
priority
by
my
stack
ring
but
pulling
things
into
scheduling
column
in
a
specific
milestone
is
very
confusing
for
the
users
they
don't
know.
What's
going
to
come
up
and
I'm
going
to
remind
you
about
the
auto-generated
kickoff
that
could
be
problematic.
A
Yes,
we
have
a
little
bit
of
a
discussion
in
the
merger
quest
that
John
and
Jackie
were
working
on.
That's
the
missing
piece
that
I
am
missing
like
how
do
we
figure
out?
What's
in
the
current
release
and
what's
in
the
next
release?
That's
the
missing
piece,
though
I
think
we
should
take
it
offline,
yep.
F
D
F
D
A
question
which
is
I
I
just
clicked
on
it
really
quickly.
So
look,
but
it
doesn't
look
like
we
have
broken
down
the
columns
into
back
end
in
front
end
and
I
just
want
to
raise
that
that,
like
as
an
idea
that
we're
supposed
to
just
pull
things
off
of
something
as
we
move
forward
isn't
possible
if
we're
not
breaking
up
the
back
end
and
the
front
end.
Mrs
because
you
know
if
we
need
someone
else
to
do
something
like
from
a
front-end
procedure,.
A
D
B
F
Yes,
sorry
Sarah,
thank
you
for
bringing
that
back
up.
Like
I,
we
were
jacking
our
chatting
about
a
few
things
on
for
Thursday
or
Friday
I.
Think
like
we're,
trying
to
have
folks
like
review
and
add
weights
to
issues
like
ahead
of
time,
which
is
which
so
we're
just
randomly
assigning
them
to
engineers.
F
So
Sarah
are
you,
for
example,
my
triage,
an
issue
that
has
a
review,
an
issue
that
has
back-end
and
front-end,
so
you
would
kind
of
review
it
from
a
funding
perspective
and
then
we'd
also
have
a
back-end
engineer,
review
that
and
kind
of
break
those
out
or
at
least
get
you
know,
ideas
of
what
we're
looking,
but
it
still
doesn't
solve
the
hey.
This
is
just
a
front-end
issue.
This
is
just
a
back-end
issue
problem,
so
yeah.
D
I
mean
another
idea:
you
like
I,
don't
know
that
it's
always
obvious
to
when
people
look
at
it
stuff,
obviously
like
whether
it's
gonna
be
a
front-end
or
back-end
entirely.
Another
idea
to
write
is
to
like
have
people
to
have
the
starting
column
be
like
proofs
of
concept
like
if
we're
going
to
work
together.
You
know
where
someone
pulls
something
together
and
everyone
does
that
together
and
then
breaks
it
up
into
the
actually
merge.
Abul
and
Mars
is
probably
another
way
to
like
keep
one
column,
but
essentially
you're
pulling
it
off.
F
D
A
A
Your
question
Darby
regarding
the
left,
Iverson,
12.7
I,
think
where
we'll
just
keep
consistent
anything
that
has
started
development,
let's
complete
it
anything
that
has
not
started
development.
Is
we
need
to
reprioritize,
so
don't
put
it
in
automatically?
We
can
discuss,
but
I
don't
want
to
waste
any
developer
them
in
time
matter
has
already
happened.