►
From YouTube: 2020-08-10 Delivery Team weekly
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
Awesome
shall
we
get
started
happy
monday,
everybody
so
in
announcements,
job
over
t8.
B
Thanks
amy,
I
just
wanted
to
signal
boost
a
couple
of
improvements
to
the
change,
lock,
changelock
logic,
which
was
sort
of
being
messed
up
by
the
recent
locking
environment,
so
that
we
don't
have
simultaneous
deploys.
So
there
should
be
two
improvements
that
just
got
merged.
If
you
have
any
other
suggestions
for
how
to
make
this
easier,
I
know
it's
been
a
little
bit
rough.
Sometimes
it
can
be
difficult
to
troubleshoot
why
an
environment
is
failing
on
the
prepare
stage,
but
hopefully
should
be
easier.
A
Cool,
thank
you
so
yeah
just
a
reminder,
friends
of
family
day
on
friday,
myra,
it's
a
great
question.
D
B
A
Cool
sounds
like
a
good
plan.
Can
you
get
release
managers
to
manage
that?
One
awesome
thanks
for
raising
that
mirror.
A
So
next
one
is
we
on
wednesday
haven't
asked
me
anything
about
releases,
so
mostly
heads
up
great
if
at
least
some
of
you
could
be
around
there
just
in
case
we
get
questions
that
you're
more
capable
of
asking
answering
sorry
so
or
if
you
have
anything
you
want
to
ask
as
well
and
then
final
announcement
is,
I
should
say
well
done
with
myra
robert
awesome
that
we
got
through
the
security
release
last
week
on
time,
as
well
as
running
the
first
experiment.
A
So
I
know
you'll
give
us
more
details
in
a
few
minutes,
but
yeah,
it's
really
once
a
huge
milestone.
So
we're
done
with
that.
A
Awesome
so
on
to
discussion,
so
I've
been
thinking
about
our
issue
workflow
and
before
I
went
too
far
thinking
about
a
way
of
doing
this,
I
just
wanted
to
kind
of
run
the
early
stages
through
with
you
and
see.
If
there's
anything,
I'm
missing,
so
I'm
thinking
about
how
do
we
get
our
issues
into
or
have
some
sort
of
workflow
that's
easy
to
use
and
suits
us,
but
makes
it
really
easy
so
that
people
can
just
drop
in
and
see.
A
Okay,
this
stuff
is
in
progress,
and
this
stuff
is
coming
up
next,
so
that's
kind
of
just
basic
stuff,
but
then
the
other
bit
I
was
thinking
about
which
might
actually
be
useful,
is
the
we
at
the
moment
it
feels
like
we
raise
issues
and
then
it's
a
bit
sort
of
reliant
on
you
all
kind
of
just
keeping
an
eye
on
that
and
jumping
in
on
issues.
A
We
don't
really
have
a
good
way
of
saying
like
this
is
the
issue
that
we
most
need
to
work
in
our
like
a
solution
out
for,
or
you
know
like
this
one
is
going
to
be
a
problem
in
a
few
weeks
or
any
sort
of
prioritization
about
things
that
we
triage
so
looking
at
our
workflow
at
the
moment,
everything
is
basically
in
triage
until
someone
picks
it
up
and
does
it.
We
don't
have
anything
to
say
like
that.
This
thing
is
like
a
super
early
stage
idea.
A
We
need
to
think
about
this
properly
or
this
is
actually
something
which
is
ready
to
be
picked
up.
There's
no.
We
don't
really
have
any
distinction
between
very
rough
ideas
and
something
you
could
just
pick
up
so
try
to
think
about
that
as
we
sort
of
put
together
a
process,
but
so
there's
kind
of
two
requirements.
I
guess
in
my
head.
One
is
the
somebody
mostly,
I
guess
somebody
outside
the
team.
A
It
might
be
useful
for
us,
but
I
think
it'll
be
more
useful
for
somebody
outside
the
team
can
drop
in
somewhere
and
see
this
stuff
is
in
progress
and
this
stuff's
coming
next
and
then
the
other
one
is
within
a
team
within
our
team.
We
have
a
good
idea
of
these
x
issues.
Three
four
issues
are
likely
going
to
be
things
we're
working
on
soon
and
I
should
prioritize
thinking
about
them
above
other
stuff,
other
other
like
what
are
the
other
requirements
that
we
want
to
capture
in
our
workflow.
A
B
Of
just
a
just
kind
of
a
random
thought,
but
would
it
would
it
make
sense
for
us
to
arrange
our
work
around
monthly
release
milestones,
even
though
we
don't
really
have
release
deliverables?
B
This
is
just
one
thing:
I've
I
feel
like
it
would
be
nice
to
kind
of
know
what
like,
or
at
least,
I
have
some
kind
of
planning
on
what
we
plan
to
deliver
over
the
course
of
an
iteration
where
an
iteration
would
be
like
about
a
month
which
kind
of
lines
up
for
the
monthly
releases,
but
and
since
every
other
or
most
other
teams
are
using
it
anyway.
Would
it
make
sense
for
us
to
use
that
as.
D
Well,
I
I
think
it
could
be
helpful.
I
do
think
that
we
are
in
sort
of
a
bit
of
an
opposition
where
a
lot
of
the
work
we
do
is
usually
a
multi-month
work
like
if
you're
on
some
team,
where
your
your
task
is
to
build
features
or
fix
box
or
whatever,
that's
usually
something
where
you
can
sort
of
time
box
it
quite
well,
whereas
with
some
of
our
work
like,
I
know,
let's
say
migrating
to
kubernetes,
whatever,
probably
on
a
monthly
basis.
D
There
are
sort
of
student
sub
tasks,
but
I
think
to
to
tackle
that
we
have
to
basically
take
a
very
good
look
like
okay.
How
are
we
gonna
sort
of
spread
this
on
these
sort
of
iterations?
B
D
You
know
this
month,
I'm
going
to
do
the
same
thing
as
last
month.
Basically
because,
if
you're
at
that
state,
then
you
know
it's
not
really
beneficial,
but
I
do
think
having
some
sort
of
iteration
where
we
plan
certain
things.
Look
back
at
it
could
be
helpful
at
least
a
bit
more
structured
compared
to
what
we
have
now,
which
is
basically
oh,
this
quarter,
we
you
know
have
these
okrs
have
fun.
Basically.
A
Cool.
Okay,
that's
really
helpful,
so
I
I
think
I
what
I'm
gonna
do
I'll
put
an
issue
I'll
open
up
an
issue,
so
you
can
all
see
the
stuff
and
start
dropping
ideas
and
things
in
there.
A
I'm
mostly
thinking
that
we
can
take
advantage
of
some
of
the
time
that
we
have
in
this
meeting
either
weekly
or
the
beginning
of
the
month
or
whenever
it
makes
sense
to
actually
sort
of
work
out
like
what
what
sort
of
goals
we
want,
and
I'm
not
at
all,
expecting
that
we
would
say
like
for
the
next
month.
We
will
do
these
27
tasks
and
that's
absolutely
it
right.
A
There
would
definitely
be
room
for
us
to
respond
to
things
coming
in
and
flex,
but
just
think
in
terms
of
the
the
bigger
pieces
that
either
we
are
thinking
of
or
we
you
know
sort
of
have
in
our
mind,
I
think,
having
everybody
together
and
actually
sharing
ideas
on
like
what
what
are
our
biggest
pain
points
or
like
what
do
we
think
is
going
to
give
us
the
biggest
benefit.
If
we,
if
we
actually
worked
out
a
solution,
might
help
us
progress
through
some
of
this
stuff
awesome.
A
C
Over
to
you,
myra,
yes,
thank
you
amy,
so
just
a
brief
recap
about
the
experiment
we
did
last
week,
so
this
experiment
allow
us
to
confirm
that
security
fixes
can
be
part
of
the
auto
reply
processes
and
what
we
did
for
that.
Well,
we
did
a
bunch
of
things,
but
I
tried
to
summarize
the
most
important
ones.
C
C
C
Canonical
just
for
master,
we
no
longer
do
it
in
master,
but
stable
branches
are
still
protected.
Branches
are
still
push
mirror.
If
I
am.
C
Okay,
so-
and
we
also
did
some
modification
to
the
release
tools
like
implementation
details
to
make
it
work,
and
the
actual
experiment
was
that,
during
a
small
window
of
time
between
friday
and
tuesday
last
week,
we
merged
security
fixes
targeting
master.
We
pick
them
into
autodeploy
and
we
deploy
them
to
our
different
environments,
staging
canary
and
production,
along
with
regular
fixes.
C
Something
that
is
not
written
here,
but
it
is
interesting
is
that
nine
out
of
ten
security
fixes
that
were
included
in
the
into
the
security
release
were
deployed
before
the
security
release
started,
so
that
actually
speed
up
a
lot
of
the
security
release,
and
so
jarv
is
asking
that
if
we
are
still
using
pikit
autodeploy
on
gitlab.com
yeah,
so
as
release
manager,
I
have
noticed
that
the
traffic
of
those
merch
requests
has
like
come
down
a
lot.
B
Does
it
work
with
the
security?
How
does
or
how
does
it
work
with
the
security
with
the
with
the
auto
deploy
branch
on
security
we
pick
from
gitlab.com
to,
or
I
guess,
the
it
gets
mirrored
over
to
the
security
project,
and
then
we
pick
it
yeah.
So
the.
E
The
merge
requests
on
canonical
we
merge
into
master
and
then
that
gets
merged
through
the
merge
string,
so
that
commit
becomes
available
on
security
and
then
we
use
security
to
pick
it
from
that
repository
into
the
auto
deployment.
So
there's
an
assertion
there
that,
like
first,
we
make
sure
this
commit,
has
actually
been
mirrored
to
the
security
repository
first
and
then
attempt
to
track
it.
Otherwise
it
fails
loudly,
it's
not
ideal,
but
it,
but
it
actually.
B
E
It
worked
yeah,
we
tried
it
wow
cool.
There
is
another
piece
of
functionality
we
haven't
done
yet,
where
you
can
label
a
security,
merge
request
taken
autoplay,
but
I'm
not
sure
we
even
need
that
anymore
right,
because
it's
it'll
get
merged
early
into
master
and
then
just
automatically
affected
by
deploy,
because
we
always
want
every
security
effects
right.
So
maybe
we
don't
even
need
that.
D
I
was
going
to
suggest
the
same
because
there
is
a
proposal
for
me
to
start
auto,
deploying
or
start
creating
all
the
deploy
branches
twice
a
day
at
the
very
least,
and
I
think,
with
the
time
it
takes
for
building
packages
and
etc,
that
that's
going
to
be
just
as
fast
as
picking
essentially,
because
when
we
pick
it's
one
hour
for
testing
pipelines
and
it's
like
two
hours
for
building
packages
and
getting
it
to
staging
like
two
two
and
a
half.
Something
like
that.
D
It's
like,
I
think,
like
half
an
hour
so
for
canary
and
then
it's
basically
the
same
time
as
the
the
whole
pick
until
all
the
deploy
thing,
and
I
think
at
least
in
the
last
month,
I've
not
heard
a
single
person
asked
okay.
Can
we
pick
this
into
autodeploy.
E
B
I
have
one
more
question:
does
the
so
the
mirror
status
cutoffs
command?
That
includes
the
merge
train
now
or
it
doesn't.
E
C
Yep,
so
the
next
steps
is
basically
now
to
modify
the
security
release
process
to
be
executed.
Like
the
same
way,
we
executed
the
experiment,
merging
merge,
requests
that
are
ready
early
and
then
the
backboards
are
merged.
During
the
actual
security
release
and
yeah,
I
mean
in
a
very
broad
sense
that
would
be
the
major
next.