►
From YouTube: 2020-08-11 - 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
All
right,
so,
let's
start
I
have
the
first
item
in
progress
updates
and
it
is
about
the
experiment.
So
we
already
talked
about
this
yesterday
in
the
deliveries
meeting,
but
since
marine
was
not
there,
I
am
just
going
to
repeat.
The
conclusion
is
basically
that
this
experiment
allow
us
to
keep
the
mttp
below
our
average.
A
All
right,
fine,
I
mean,
I
feel,
very
fine
and
very
happy
to
say
this
again,
so
okay.
So
this
is
the
first
time
we
were
able
to
execute
the
auto
deploy
and
the
security
release
processes
without
one
blocking
the
other.
So
that
is
awesome
and
updating
security
master
through
merge
train
was
easy
like
we
did,
we
didn't
encounter
any
conflict
and
it
didn't
cause
any
broken
master
problems,
so
that
was
nice
and
90
of
the
security.
A
Merge
requests
were
merged
and
deployed
before
the
security
release
actually
started,
and
the
steps
on
the
security
release
tasks
were
considerably
reduced,
which
makes
which
made
easier
the
release,
manager,
role
and
well
what's
next,
in
a
bigger
scheme
of
things,
it
will
be
to
modify
the
security
release
process
so
from
now
on,
it
can
be
executed
the
same
way
as
we
executed
on
the
experiment
and
then
amy.
You
have
a
question
there.
C
A
C
B
A
Oh
yeah,
I
think
it
was
raised
a
couple
of
times,
but
honestly
it
hasn't
been
raised
a
lot
from
my
perspective
to
actually
remove
that
check
from
our
settings.
I
think
it
give
us
more
benefits
than
troubles.
C
D
B
A
I
think
we
removed
that
part
once
the
merch
results
were
enabled
for
the
canonical
project,
but
I
mean
we
can
discuss
this
in
another
issue
not
to
take
too
much
time
on
this
meeting.
D
A
Yeah,
so
the
next
point
is
actually
the
trigger
pipelines
for
merch
yep.
B
B
I
understand
that
it's
an
inconvenience
for
appsec,
but
also
it's
not
something
that
we
should
be
driving,
adding
to
the
release,
tools
on
or
in
any
way
resolving,
because
then
we
get
into
even
more
tricky
situation,
which
is
handovers
handovers
between
different
teams
in
different
departments
are
horrible,
so
I
think
we
should
find
a
way
to
address
certain
things
with
them
when
it
comes
to
blog
posts.
But
honestly,
blog
posts
are
not
something
that
we
should
be
owning.
C
B
Right,
but
now
that
we
are
merging
into
master
a
single
laptop
approval,
already
puts
you
on
a
notification
list,
so
when
something
is
merged
into
master,
there
is
a
way
for
you
to
just
look
at
them.
What
is
merged
and
based
on
approvals,
or
something
like
that?
Maybe
I
think
we
have
that
feature
as
well.
In
any
case,
there
is
a
way
to
get
that
done.
A
Fine,
okay,
so
moving
on
to
trigger
pipelines
for
merge
results,
it
is
still
under
investigation
and
well.
I
took
the
last
week
kind
of
easy
on
me,
so
I
haven't
moved
up
move
on
on
that
one
that
much
so
that
would
be
my
to-do
for
this
week.
Basically
robert,
you
have
the
next
point.
D
Yeah,
so
we
had
two
questions
from
last
week.
The
first
one
was:
will
the
merge
train
commit
kind
of
dirty
the
commit
history
and
introduce
problems
for
blames
it?
Doesn't
it's
transparent
other
than
being
an
extra
commit
on
the
history,
it's
transparent,
yeah
and
then
yes,
mario,
did
you
have
a
thumbs
up
and
then
we
wanted
to
investigate
if
we
could
auto
toggle
the
merge
train
schedule
kind
of
based
on
the
status
of
the
mirror,
all
the
pieces
are
there
to
do
it
there's
just
some
implementation
details.
D
I
wasn't
sure
if
we
wanted
to
discuss
now
or
later
basically
just
like.
When
do
we
want
to
run
this
check
and
then
how
often
I
wasn't
sure
if
it
was
if
it
should
be
like
its
own
job
or
if
there
was
like
an
existing
job
we
could
hook
into,
but
then
I
wasn't
sure
if
that
kind
of
dirties
the
domain
of
that
job.
A
I
think
this
relates
to
the
first
discussion
point
about
the
window
to
merge
security,
merge
requests
targeting
master
so
based
on
the
analysis
we
did.
A
I
don't
know
three
or
four
weeks
ago
we
encountered
that
most
of
the
merch
requests
are
ready
one
week
before
the
due
date,
which
is
basically
from
the
2017
to
the
28th,
and
with
that
in
mind,
I
was
proposing
for
the
window
to
be
between
the
20
upon
to
the
due
date
of
the
security
release,
and
I
already
saw
marine
a
response
to
that,
which
is
not
a
very
good
idea
to
overlap
that
window
with
the
final
release,
which
I
totally
agree.
A
B
D
I
think
now
we
like
we
at
least
check
if
we
want
to
create
a
stable
branch
every
time
we
create
the
auditory
branch.
So
as
soon
as
that
happens,
it's
kind
of
it
just
happens.
B
I'm
not
following
what
I'm
what
I'm
suggesting
is
the
moment
when
the
stable
branch
exists,
we
should
be,
we
can
consider
enabling
the
window,
but
I'm
not
really
sure
why
follow
robert?
What
are
you
exactly
saying.
B
If
it's,
if
it's
a
specific
date,
when
it's
created
inside
of
the
code,
I'm
going
to
go
into
release
tools
to
rip
it
out
and
send
you
a
merge
request,
but
I
think
it
might
be
in
the
process
in
the
release
task
where
we
described
do
x,
y
and
z
around
this
time.
It's
again
night
18th,
but
it's
some
business
days
before
the
22nd
right.
A
B
B
A
So
if
we
use
the
creation
of
the
stable
branch
as
initial
date,
wouldn't
that
bring
the
same
problem
that
you
mentioned
about
overlapping
the
final
days
of
the
release
with
the
window
of
allowing
merchant
quest
to
be
merged.
B
Well,
the
reason
why
I'm
suggesting
this
is
because
the
history
right,
like
the
timeline
changes
there
like
if
we
merge
things
into
master
and
then
later
on,
create
a
stable
branch.
We
might
inadvertently
include
something
in
a
stable
branch
that
we
are
not
intending
to
because
we
are
building
from
a
master
from
autodeploy.
There
might
be
also
divergence
in
branches
and
so
on
and
so
on.
B
So
I
don't
think
it
should
be
creating
the
same
problem,
so
the
problem
of
actually
inadvertently,
including
something
in
stable
branches,
is
resolved.
Sorry,
including
something
universal
inner
release,
is
resolved
because
we
already
created
a
stable
branch.
B
B
You
can
make
it
simple:
let's
start
23rd
like
you
suggested.
I
think
it's
a
good
suggestion.
We
can
move
on
with
it,
but
I
think
there
might
be
actually
a
benefit
for
us
to
think
about
it,
like
a
more
fluid
next
set
of
dates
to
introduce
more
fluidity
into
the
into
the
process
for
everyone,
and
that
could
be
like
that
moving
target
as
an
explain.
C
The
23rd
would
give
us
like
a
longer
period
than
last
time
right.
So
it's
still.
We
still
benefit
also
robert.
After
this
meeting,
I've
got
a
note,
and
I
want
to
talk
about
that
security
release
date,
because
I
think
that
that's
a
friday,
so
that's
a
bad
day,
so
it
might
actually
be
a
bit
like
longer
than
that
anyway.
A
Okay,
so
moving
on
to
the
next
discussion
point
is
that
I
finally
had
the
time
to
update
the
main
epic
about
security
releases
and
how
to
deploy
with
all
the
things
that
we
have
done,
and
the
current
proposal
and
the
next
steps
and
summarize
the
next
steps.
Well,
I
listed
those
on
the
document.
It
is
basically
to
create
auto
deploy
branches
on
security.
I
think
this
is
almost
done.
C
A
Feasible
well
sometimes
I
am
too
enthusiastic
and
I
like
to
put
a
lot
of
pressure
on
myself,
but
I
don't
know.
Perhaps
I
shouldn't
be-
that
enthusiastic
and
move
the
due
date
to
september
the
security
release.
B
Looking
at
the
current
things
that
you
wrote
up,
I
the
biggest
longest
running
thing
that
I
see
here
is
changing
the
process.
A
A
B
But
the
security
template
is
a
problem
because
it
involves
humans
and
that
one
is
going
to
take
the
longest
to
actually
radiate.
The
information
for
and
you'll
also
have
to
update
the
existing
issue
templates
to
reflect
this
new
information,
so
that
one
has
like
the
possible
the
biggest
toil
level
amongst
them
all
in.
In
my
view,
the
thing
I
don't
really
follow
is
allow
for
a
lot
of
security.
Merge
requests
to
trigger
pipelines
for
merge
results.
B
That
is
basically
enabling
merge
train
for
sorry,
enabling
the
merge
train
feature
the.
B
Merge
request:
we
need
to
change
the
the
name
of
the
project
by
the
way,
so
that
one
really
depends
only
on.
A
So
from
the
implementation
perspective,
we
will
need
to
add
a
new
feature
into
release
tools
to
trigger
a
pipeline.
Every
time
a
merge
request,
targeting
master
is
assigned
to
the
release
tool
spot.
We
don't
have
that
right
now
and
I'm
pretty
sure
it
is
something
we
can
do.
I
think
robert
already
did
most
of
the
investigation.
A
B
Yeah,
the
problem
in
the
canonical
project
is
mostly
because
of
the
volume
we
are
talking
about
right
like
we
have
too
many
merge
requests.
We
have
too
many
changes
in
master
and
so
on
and
so
on.
On
security
we
have
a
different
problem.
The
problem
is
only
master,
is
fast
moving,
but
not
to
the
volume
of
the
merge
requests.
B
Theoretically,
number
of
merge
requests
in
security
repository
so
theoretically,
before
we
set
the
approved
and
have
that
pipeline
run,
it
should
be
fine,
like
the
diff
shouldn't,
be
that
large,
although
it
doesn't
matter
because
the
thing
comes
from
canonical
monsters.
So
that's
the
amount
of
this
is
where
we're
getting
the
amount
of
commits
from.
B
I
know
that
you
like
setting
ambitious
dates,
myra,
but
I
also
like
doing
that
same
thing.
I
think
this
is
doable.
C
The
only
thing
like
there's
a
couple
of
things,
I
think
we
should
think
about
before
we
go.
I
I
like
aiming
at
these
dates
a
couple
of
things.
One
is
if
it
feels
like
before
we
consider
it's
closed.
We
should
at
least
know
how
we're
handling
the
monthly
releases
and
the
other
one
is
robert's
away
for
most
of
the
next
few
weeks,
so
that
might
factor
in.
A
Yeah,
okay,
so
let's
not
complicate
things
and
let's
move
the
due
date
for
september
the
next
release.
If
rover
is
not
going
to
be-
and
I
am
going
to
handle-
also
the
monthly
release,
then
let's
not
put
extra
pressure
and
just
move
the
due
date.
A
bit
more,
I
mean
we
have
been
waiting
the
whole
year
like
we
can
wait
another
month,
that's
fine!
A
So
just
returning
to
your
point
marin,
I
was
trying
to
understand
what
were
you
saying
and
we
do
need
security
pipelines
for
merch
results,
but
we
don't
need
the
merge
train
feature.
Do
we?
I
I
don't
understand
why
we
need
that.
D
My
suggestion
that
was
only
it
was
only
because,
potentially
I
thought
we
were
merging
them
like
in
tandem,
so
like
merge,
one
merge
one
merge
one
and
that,
like
doing
that,
I
don't
think
the
pipeline
was
it
called
pipeline
for
merge.
Results
gets
us
the
same
thing,
because
we're
triggering
a
pipeline
in
kind
of
each
one,
merging
the
first
one
and
then
potentially
merging
the
second
one.
B
B
We
don't
have
that
much
insecurity.
We
have
maybe
like
www.com
level
when
we
do
the
first
batch
and
then
later
on.
It's
not
a
problem
and
that
automatically
buys
you.
If
I'm
understanding
robert
correctly,
that
automatically
buys
you
the
most
up-to-date
master,
because
when
you
click,
when
you
add
something
to
the
merge
training
picks
the
most
up-to-date
master
runs
the
latest
pipelines
there
and
then
merges
it.
A
Do
we
know
if
it
gets
the
latest
pipelines?
I
am
not
familiar
with
the
merge,
trying
features.
B
Yeah,
I
think
that's
the
case
because,
like
look,
how
wget.com
is
working,
otherwise
we
wouldn't
merge
anything.
But
wget.com
is
the
messiest
repository.
We
have
people
overriding
each
other
changes
and
if
it
wasn't
for
that
and
the
latest
master,
I
don't
know
where
we
would
be.
A
Okay,
so
I
can
investigate
how
it
works,
so
we
are
sure
about
introducing
this
change
and
yep,
so
the
due
date
is
going
to
be
moved
to
september.
I'm
going
to
investigate
if
we
can
include
merge,
train
on
the
security
project
and
well
is
there.
We
still
have
seven
minutes
before
finishing
this
meeting.
Does
anyone
want
to
bring
some
other
point.
B
When
you
are
ready
to
merge,
if
you
haven't
run
a
pipeline
for
a
while,
the
target
branch
may
have
already
changed.
Merging
at
that
point
could
introduce
breaking
changes.
Merge
trains
can
prevent
this
from
happening.
A
merge
strain
is
acute
list
of
merge,
requests
each
waiting
to
be
merged
into
the
target
branch.
B
B
B
D
A
Okay,
robert
with
the
window
from
the
23rd
to
the
28th:
do
you
have
everything
you
need
to
work
on
the
merge
train
now
to
total
mirror
status,
team
yep,
great
okay?
So
does
anyone
wants
to
add
another
discussion
point
before
ending
the.
A
A
All
right,
I
am
going
to
take
your
silence
as
a
no,
so
I'm
going
to
investigate
security
pipelines
plus
how
the
merge
train
feature
works
and
see
if
it
can
be
included.
Robert,
it's
going
to
work
on
the
auto
toggle
and
we
are
going
to
move
the
due
date
for
september.