►
From YouTube: 2020-08-25 - Security Release as part of auto-deploy.
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
Okay,
so
welcome
to
another
security
releases
as
part
of
auto
deploy
meeting.
It
seems
that
today
is
just
you
and
me,
and
we
have
some
few
items
to
discuss
the
first
one
is
that
now
that
we
are
merging
security,
merge
request
early
and
we
require
like,
in
the
emma
and
the
merch
request
description
to
say
like
oh,
this
merch
request
is
going
to
close
this
issue,
so
once
it
is
merged,
the
issue
is
automatically
closed
and
we
don't
want
that
because
the
backboards
are
still
pending
right.
A
So
the
security
issue
should
actually
be
closed.
Now,
at
the
end
of
the
security
release,
and
with
that,
I
proposed
some
steps
to
accomplish
that.
The
first
one
was
to
simply
disable
the
setting
that
allows
at
the
automatic
closing,
but,
to
my
surprise,
it
has
a
box,
so
it
is
currently
not
working.
I
already
reported
this
and
I
think
the
respective
engineering
manager
and
well,
I
don't
think
we
can
rely
on
that.
A
So
what
I
am
going
to
do,
instead
is
to
add
a
validation
enough
tooling,
to
well
now
prevent
that
the
closest
description
appears
on
the
merchant
description
and
that
way
try
to
circumvent
the
possibility
and
then
I'm
going
to
add
some
sort
of
chat.
Ups
command
at
the
end,
so
we
can
say,
like
oh
security
release,
is
finished.
Now,
let's
indicate
child
that
we
want
to
close
all
the
security
issues
that
were
processed
and
that's
it
so.
A
Yeah,
I
already
modified
also
the
security
template,
and
I
also
I
already
like
removed
that
step,
and
it
was.
It
was
nice
because
we
already
have
a
lot
of
steps,
so
it
is
better
once
we
remove
one
that
when
we
add
one,
so
I
honestly
don't
think
anyone
is
going
to
notice
until,
like
the
validation
is
in
place.
A
Okay,
cool-
and
I
do
have
a
question
for
you
now
that
you
are
working
like
as
a
release
manager
and
you
are
also
trying
driving
this
iteration
of
merging
security.
Merge
requests
earlier.
So
what
are
your
thoughts
about?
It.
B
So
I
think
so
far
it's
going
really
smoothly.
So
yesterday
I
think
there
were
just
two
things
merged
that
would
find
there's
more
today.
I
haven't
done
that
yet,
but
I
will
so.
B
So
that's
really
great!
So
from
that
side
of
things,
I
think
it's
working
really
well.
I
think
the
only
thing
which
I'm
trying
to
think
about
which
actually
leads
to
some
of
these
questions
I
have
is
just
I
think,
whenever
we
see
something
odd
around
the
auto
deploy
branch,
there's
the
assumption
that
it's
because
of
this
security
stuff-
and
that's
not
in
fact
so
far-
that
hasn't
been
the
case
at
all.
B
We've
had
some
really
strange
stuff
happening
with
the
auto
deploy
branch
today,
nothing
to
do
with
any
of
of
like,
where
nothing
to
being
on
security
and
nothing
to
do
with
the
divergence.
B
So
I
think
that's
probably
the
only
thing,
I'm
kind
of
thinking
about
right
now,
so
I
suppose,
there's
probably
two
parts
that
wanted
to
add
a
few
more
steps
to
the
security
release,
documentation
just
to
kind
of
be
like.
Oh
did
this
thing
happen.
B
It's
fine
two
examples.
I
think
the
one
I've
got
here
for
b.
So
it's
like
this
when
you
run
like
all
of
our
kind
of
instructions
around
checking,
the
mirror
status
is
like
once
everything
is
completely
matching
you're
good
to
go,
but
we
know
that's
not
the
case
right.
We
know
in
these
circumstances.
A
B
A
Yeah,
okay,
so
just
refresh
my
memory,
do
we
have
an
instruction
on
batch
releases
that
we
need
to
check
for
the
mirror
status?
Because
I
don't
remember.
A
Oh
yeah,
you
know
that
when
we
are
creating
a
batch
release,
a
regular
one
right,
so
we
we
create
these
release
tasks
with
multiple
steps
for
release,
managers.
A
B
Do
you
would
there
be
anything
if
we,
if
we
had
to
ended
up
having
to
do
a
security
like
a
critical
security
release
this
week?
Would
there
be
anything
special
for
that.
A
No
not
really
because
on
that
scenario
I
mean
we
will
still
merge
the
security
merchandise
target
master
earlier
and
the
back
ports.
We
will
merge
to
the
stable
branches
and
we
all
when
we
talk,
we
are
only
going
to
tack
the
ones
from
the
stable
branches
that
are
only
going
to
contain
the
critical
fixes.
B
Great
all
right,
then
sounds
good,
so
yeah
that
covers
off
the
patch
stuff,
so
that's
great
and
then
yeah,
I
think
the
other
one.
Is
this
the
point
c,
which
is
exactly
the
same?
It's
I
think,
probably
what
we
maybe
what
we
don't
we
just
don't
have
visibly
enough
is
the
the
solution
around
the
merge
train,
and
you
know,
I
think,
the
mirroring
the
divergence
is
very
visible,
because
we
have
lots
of
errors
to
indicate
on
our
errors,
but
like
lots
of
warnings
to
show
that's
happening.
B
So
maybe
what
we're
missing
is
just
the
visibility
for
the
team
in
some
form
like
insac
or
something
of
here's,
how
this
stuff
is
still
working.
A
Yeah
I
noticed
like
yesterday
that
well
I
think
it
would
have
been
a
good
idea
yesterday
for
the
release
manager
in
america
just
to
click
to
trigger
the
merch
request
at
the
end
of
the
day.
So
you
have
a
fresher
branch
to
start
one,
because
I
think
that
you
did
that
in
the
morning.
So
you
can
refresh
like
the
security
repository
and
then
you
can
start
the
auto
deploy
processes
so
yeah.
A
Perhaps
an
idea
that
could
be
is
to
add
a
step
on
the
release
task
saying
like
for
the
release
manager
in
america.
At
the
end
of
the
day,
please
trigger
the
merge
train
and
ensure
that
it
was
propagated,
and
then
I
guess
once
this
is
all
graphed
up
and
all
working.
We
do
need
to
send
a
message
to
our
team
that
okay,
this
is
what
is
going
to
happen
and
based
on
the
implementation
that
rover
is
doing
like
because
right
now
we
are
doing
manually.
A
But
the
final
outcome
is
that
it
is
automated
based
exactly
on
the
mirror
status
output,
the
one.
So
that
is
how
it's
going
to
look
like
right
and
we
need
to
send
the
message
to
our
thing
and
perhaps
to
everyone
else,
but
yeah.
B
Yeah-
and
that
makes
sense
cool
but
yeah
at
the
moment.
I
think
it's
working
pretty
nicely,
which
is
great.
A
Yeah,
what,
where
do
you
think
speaking
of
the
same
process,
about
the
picking
how
to
deploy
that
it
is
the
same
and
that
is
actually
transparent
to
us?
Do
you
think
we
should
update
our
documentation
somewhere
around.
B
That
yeah,
I
do,
I
think,
it'd,
be
helpful
to
have
it
in
that
troubleshooting
guide
in
the
critical
security
just
because,
like
as
a
a
literal
line
of
you
know,
if
you,
if
you've
got
the
like,
I
think
that's
where
I
would
look
like.
I
know
we've
diverged.
I
need
to
get
something
just
double
check.
Is
this
the
right
place,
yeah.
B
Amazing,
great
thanks
very
much
awesome.
What
what
are
kind
of
the
are
there
any
kind
of
changes
that
you're
expecting
to
have
in
place
before
the
actual
critical
security
release
happens
next
week.
A
Okay,
basically,
I
would
like
to
have
the
issue
about
changing
the
way
security
implementations
issues
are
closed,
because
if,
if
we
don't
have
that
on
time,
you
or
or
the
release
manager
in
america
is
going
to
have
to
manually
close
all
the
issues
right
and
that
is
kind
of
annoying.
It's
not
much
because
you
only
need
to
click
about
one,
but
it
is
annoying
right.
So
I
would
like
to
have
it
like
probably
this
week
and
I
don't
think
it
is
like
implementation
wise.
A
A
A
Okay,
okay,
so
I
think
this
is
our
shortest
meeting.
B
B
So
the
only
thing
I
wasn't
clear
about
was-
and
I
I
see
they're
kind
of
doing
quite
different
things,
but
I
just
wanted
to
check
that
we
definitely
wanted
both
of
them.
So
I'm
just
clicking
through
all
my
tabs.
B
A
Yeah,
yes,
so
a
bit
of
history,
they
are
about
the
same
thing,
so
the
the
last
one,
the
one
that
says,
security
release
during
that
street
and
in
the
totally
that
one
and
that
is
on
gitlab
canonical
and
that
the
one
that
was
created
by
me.
It
is
the
security
release
tracking
issue.
That
is
his
formal
name,
and
that
is
the
one
that
serves
as
a.
A
As
an
issue
that
organizes
all
the
security
issues,
because
when
we
actually
run
our
release
tooling,
when
you
run
like
the
security
dash
dash,
merge
dash
master
that,
behind
the
curtains,
is
going
to
iterate
over
all
the
link
issues.
If
you
scroll
down
in
that
issue,
you
are
going
to
see
that
we
have
27
right
now.
Oh
yeah,
it's
going
to
say,
okay
about
this
27,
we
have
nine
that
are
ready
to
be
processed
and
18.
A
A
B
A
And
the
other
one,
the
security
patch
release
the
one
that
was
created
by
the
gitlab
release
tools,
but
it
is
basically
for
release
managers
and
it
is
listing
every
step
or
the.
The
purpose
of
this
issue
is
to
list
every
step.
The
release
manual
manager
needs
to
follow
so
this
issue.
It
is
basically
going
to
be
you
and
the
release
manager
in
america
to
adjust
the
steps
and
well
to
complete
all
the
steps
that
are
marked
there.
A
So
back
in
the
days
we
used
to
have
three
more
issues
once
one
for
every
version,
so
we
have
a
realistic
issue
for
13.3
another
one
for
3.2
and
it
was
like
way
too
many
issues.
So
we
decided
just
to
put
all
the
instructions
into
one
and
just
remove
another
ones,
but
yeah.
Perhaps
an
issue
like
for
later
on.
It
would
be
like
how
can
we
remove
one
of
these
two
issues
and
have
all
like
in
a
single
one,
because
journaling
between
these
two,
sometimes
it's
too
much
yeah.
B
I
I
think
it's
definitely
not
immediately
clear
from
the
kind
of
names
which
which
one
to
be
interacting.
I
mean
it's
clear
from
the
content,
but
it's
not
immediately
clear
at
the
beginning,
when
you
sort
of
start
out
cool
yeah
but
yeah
that
makes
sense
that
makes
sense
but
yeah.
Otherwise,
I
think
everything
is
going
really
smoothly.
So
yeah,
that's
really
exciting.
A
Okay,
so
do
you
have
any
other
question.
B
No,
I
don't
think
so.
I
think
that
all
makes
sense,
because
she's
gonna
keep
keep
merging.
I
think
for
this
week.
A
Yeah
yeah.
For
me,
it
would
be
to
wrap
up
the
security
implementation
issues.
The
way
they
are
close
and
well
for
you
on
your
side
will
be
to
run
this
second
iteration
and
well
any
question
or
anything.
I
am
here
to
help
fantastic.
That's
great
awesome!
Thank
you
so
much
for
your
time,
and
I
will
see
you
next.
One
bye,
bye,.