►
From YouTube: 2020-07-14 - Security Releases 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
B
B
Next
thing
was
last
week:
we
wanted
to
gather
some
statistics
on
how
the
security
merge,
boss
kind
of
affect
our
master
branch
and
how
often
those
are
being
merged
and
when
they're
ready
and
how
long
it
takes
them
to
be
assigned
and
merge.
So
I
gathered
some
statistics
in
that
datasheet
link
there
and
there's
a
summary
in
the
first
link
and
Meyer
you
actually
added
some
stuff
yesterday,
you
know
summarized
up.
A
Sure
sure,
alright,
so
I
am
assuming
everyone
can
see
my
screen
and
I
built
graphs
based
on
Roberts
data.
That
basically
represents
how
the
security
march
boys
have
been
created
over
time,
and
we
are
starting
late
on
December,
20
2019
to
basically
July
first
two
weeks
ago
right,
so
the
blue
lines
represent
the
number
of
March
Oak
was
created
and
the
red
pinkie
dots,
whatever
they
represent
when
the
security
release
has
started.
A
So
what
I
can
see
from
here
is
that
most
of
the
security
March
of
ways
are
created
like
one
week
before
the
security
release
starts,
and
while
we
can
see
like
there
is
in
this
increasing
number
right
like
there
is
this
pattern
and
based
on
Roberts
number
or
numbers
only
17%
of
March
of
ways
were
created
before
the
AP.
That
means
that
it
is
17
out
of
130,
merge,
request
kind
of
so.
B
A
Always
thought
that
security
March
request
where
prepare
and
then
just
holding
and
waiting
for
the
security
release
to
start,
but
that
appears
not
to
be
the
case
because
they
are
basically
created
just
one
week
before,
and
that
is
not
too
much.
That
might
be
because
the
due
date
is
set
at
the
end
of
the
month.
So
you
know
how
people
normally
leave
like
everything
for
the
last
day,
and
that
might
be
an
indicator
of
that.
A
But
for
me
it
is
telling
me
that
when
the
security
requests
are
ready,
which
is
one
week
before
we
can
merge
them
if
they
are
ready
and
the
difference
between
canonical
master
and
security
master
is
going
to
be
basically
non-existent
on
the
until
the
last
week
of
the
month.
That
is
what
I
can
infer
from
the
data.
B
Yeah,
it
was
interesting
to
me
that,
like
in
theory,
were
supposed
to
be
prioritizing
security
like
this
right,
but
it
also
makes
sense
that
they're
not
prioritizing
them
until
they
know
they're
gonna
be
released
because
they
know
the
monthly
release
is
coming
up
as
well.
So
they
prioritize
that
work
and
then
once
that's
out
the
door,
then
they
prioritize
the
thing
that's
coming
next,
so
it
makes
sense.
D
C
Interesting,
my
conclusion
is
a
bit
different
from
yours,
Amy,
mostly
because
I'm
expecting
that
if
we
keep
the
okay
accumulation
point,
which
is
the
deadline,
we're
not
gonna
see
any
change
in
behavior
you'll
see
from
people
who
are
more
methodical
and
organized
a
change.
They're
all
gonna
benefit,
so
the
17
percent
that
are
ready
and
on
top
of
things,
they're
going
to
benefit
from
it,
and
maybe
they
actually
get
that
time
back
and
be
more
efficient
elsewhere,
which
is
good,
I.
C
Think
vast
majority
won't
change
their
habits
at
all,
because
there
is
an
accumulation
point
and
humans,
like
art,
I,
think
prefer
working
in
campaigns.
Basically,
so
you
know
sing
behavior,
like
University
students,
you
have
an
exam,
you're
gonna
work
the
night
before
to
actually
prepare
it
proper.
C
C
But
if
we
decide
to
remove
the
deadline
and
say
we
are
going
to
release
when
we
accumulate
enough
security
requests
that
can
actually
cause
a
problem
for
us
instead,
because
we
will
have
then
people
at
more
random
dates
doing
their
things,
which
works
in
our
advantage
when
we
are
talking
about
CD
and
when
we
are
talking
about
regular
fixes,
but
does
not
work
in
our
advantage.
When
we're
talking
about
how's,
it
go
security
fixes.
C
That
is
a
bit
of
my
confusion
and
compute
conclusion,
and
also
what
that
also
tells
me
is
that
by
tweaking
the
deadline,
we
can
get
the
biggest
bang
for
our
buck,
because
if
people
are
starting
to
work
on
the
18,
that
is
where
their
new
cycle
begins.
Right,
2012
22nd
is
done
and
so
on.
If
we
say
that
if
we
create
the
security
list
process
where
the
28th
for
security
fixes
becomes
more.
C
Impactful
right
now,
it's
a
bit
of
a
free-for-all
because
release
managers
are
the
ones
deciding,
but
if
we
kind
of
set
it
in
stone
and
say
the
deadline
for
you
doing
things
with
security
backwards
is
25th
random
date
now
25th
we
could
compress
the
timeline
even
a
bit
further
right,
because
we
expect
between
18th
and
twenty-fifths,
the
people
are
going
to
do
a
bit
of
a
panic
because
they
just
finish
their
features.
Now,
let's
get
to
security
things
done.
C
The
month
no
I'm
saying
that
we
by
controlling
this,
we
can
control
the
spread
of
merge
requests
of
those.
What
well
I'm,
really
terrible
at
quick
math
83%
right,
the
82%
that
actually
accumulate
things
around
the
release
date.
There
Robert,
you
said
between
18th
and
the
release
date
right
or
something
like
that.
Yeah.
C
So
that
means
that
if
we
kind
of
push
the
deadline
towards
more
of
the
30th,
we
buy
them
more
space,
which
means
we
collect
more
of
those
merge
equation.
It
means
that
we
can
say
that
around
the
week
we'll
have
a
bit
of
a
divergence
in
master
in
general,
and
we
can
control
that,
because
during
that
period
of
time,
if
all
of
you
remember
it's
like
goes
down
right,
the
number
of
commits
drop.
Actually,
that
is
something
that
we
can
also
investigate.
C
B
C
D
D
C
So
so
the
reason
why
we
would
take
a
different
approach
if
the
security
Amar's
were
scattered
across
the
month.
That
would
work
in
the
advantage
over
sorry
that
would
work
towards
well.
Our
deadline
helps
no
one
apart
from
ourselves,
so
let's
remove
it
completely
so,
and
we
are
them
focusing
on
removing
the
deadline
and
want
to
see
the
outcome
of
removing
that
deadline
for
everyone
all
right
like
that,
would
be
move
towards
our
process,
and
we
wouldn't
be
talking
about
automating
anything
right
now.
C
We
will
be
talking
about
changing
the
process
so
that
we
can
radiate
that
information
so
that
we
can
get
more
data
on
how
this
impacts
us.
We
would
probably
take
on
more
work
that
way,
because
this
deadlines
on
security
thing
was
set
to
create
bit
more
room
for
us,
but
I
think
we
would
be
going
in
a
direction
of
a
process
change
rather
than
direction
of
automation.
Okay,.
B
Not
this
specifically,
but
it
could
does
kind
of
naturally
did
lead
into
Amy's
point
on
the
next
item.
Where
okay
say
we
start
merging
security
fixes
after
the
18th
into
master
or
security
master,
then
that
creates
this
problem
with.
What
do
we
create
the
auto
to
fly?
Branch
from
are
not
the
other
point,
the
stable
branch
for
the
upcoming
release
from
because
then
we
suddenly
have
master
with
security
fixes
in
it,
but
we
don't
want
those
to
release
as
part
of
monthly
release.
I
don't
know
if
we
should
just
segue
into
that
discussion.
Smaller.
C
Smaller
iteration
point
Robert,
it's
a
good
remark
that
it
you're
correct,
but
we
are
assuming
I'm
guessing
that
we
are
going
to
take
in
the
whole
18
to
28
all
right.
That
is,
the
distribution
we
have
in
here
right,
like
between
18
to
28,
30
ish,
is
where
we
see
the
majority
like
we
will
receive
these
bikes.
Is
that
correct?
First
iteration
can
be
move
one
thing
to
the
side,
which
means
22nd.
C
We
already
have
to
have
a
stable
branch
and
we're
going
to
say
everything
that
is
ready
on
the
22nd
between
the
22nd
and
28th
goes
into
master
as
soon
as
it's
ready,
which
means
you
have
stable
branches,
so
your
auto
deploy
so
you're,
not
totally
I'm.
Sorry.
So
yours,
your
stable
releases
self
managed
releases
I'm.
Looking
for
that
word,
your
self
manage
releases
are
already
dot,
0
is
out,
and
you
have
a
way
to
create
patches.
Auto
deploy
depends
on
master
anyway,
so
you're
disconnected
from
the
South
manager
e.
C
So
you
have
like
how
I
visualize
or
to
the
boys
so
ghetto,
but
calm
releases
and
self-manage
releases.
Is
you
have
parallel
processes
that
converge
overlap
and
then
move
further
away,
and
you
have
that
play
all
the
time
all
the
time,
so
you
write
like
if
you
kind
of
move
that
deadline,
you
kind
of
more
align
it.
Naturally,
with
that
convergence
point
sorry
I'm
using
big
words,
but
I
had
too
many
meetings
today,
where
I've
been
playing.
I,
don't
know
what
so,
but
does
that
answer
your
question?
C
B
C
A
C
C
A
A
C
C
D
B
D
B
C
Yes,
because
we
are
talking
about
auto,
deploy,
we
are
not
talking
about
backwards,
so
how
I
visualize
this
is
to
what,
if
this
20
seconds
is
the
the
the
cross
point
right,
like
the
intersection
between
the
two,
we
say
that
now
we
have
a
window
of
20,
second
to
let's
say
twenty
eight,
because
that's
a
significant
deadline.
So
that's
a
full
week
if
almost
off
a
window
where,
whenever
like
we
have
still
the
security
validation
stuff,
which
means
you
still
have
to
be
have
back
ports
ready.
Everything
needs
to
pass
bla
bla
bla.
C
B
C
Are
ready
to
back
port
them
right
when
we
are
ready
to
create
the
backwards,
so
we
have
a
beautiful
disconnect
from
what
we
are
doing
right
now,
which
is
we
merge
everything
in
one
go?
We
don't
want
to
do
that
right,
because
we
need
stable
branches
free
for
patch
release,
just
in
case
we
need
to
do
them,
which
means
that
our
validation
needs
to
verify
that
we
have
backwards.
Targeting
the
things
correctly.
We
have
all
the
bits
and
pieces
correctly
done,
so
validation
still
needs
to
be
there.
D
C
C
D
C
The
questions
that
you
ask
here,
like
master
branch
like
how
are
we
doing
all
these
edge
cases,
because
that
is
then
going
to
poke
holes
into
this
whole
thing,
but
then,
ultimately,
I
think
we
need
to
answer
those
questions
regardless
and
that
will
feed
to
Robert.
You
stayed
a
bit
silent
there,
I'm
hoping
you're
thinking
but
also
I
know
you
were
a
bit
unsure
about
data
collection,
so
I
want
to
give
you
a
chance
to
speak
up.
If
you
have
any
concerns,
yeah.
B
A
B
I
had
a
just
kind
of
like
a
random
idea
for
possibly
like
for
the
master
in
Mars
attempt
doing
like
a
dry
run,
cherry-pick
of
those
into
the
existing,
stable,
wrenches
or
I.
Guess
what
would
be
the
stable
branch
is
for
security
release
and
then
determining
if
we
needed
manual
backwards
at
all
or
if
we
could
just
cherry-pick
the
master
yeah
straight
away.
There
is
no
existing
functionality
for
a
dry
run
cherry-pick
so
we'd
have
to
fake
it.
B
I
had
two
ideas
for
that
that
are
in
the
issue
and
Myra
had
the
idea
that
I
agree
with
that.
We
probably
need
some
data
to
see
if,
like
how
many
potentially
backports
don't
change
it
all
from
their
master,
counterpart
and
I.
Think
there's
a
way
to
do
that,
but
unfortunately
our
API
doesn't
have
a
way
to
get
the
diff
of
an
mr
cleanly,
which
is
what
I
would
use
to
compare
that
I.
Think
really.
C
B
Know
I'll
look
into
that
but
like
there
is
like,
if
you
go
to
an
mr
needs,
throat,
dot,
patch
or
dot
diff
under
the
URL.
It
shows
you
a
perfect
get
patch,
but
we
don't
expose
that
in
the
API.
So
you
have
to
like
to
automate
it.
You'd
have
to
figure
out
like
how
to
log
in
or
how
to
like
extract
your
cookie,
which
I'm
not
sure,
is
possible.
So
I'll
look
into
it.
C
C
What?
If,
during
the
initial
validation,
we
go
down
the
route
of
checking
whether
master,
M
R
has
been
approved
by
AB
side,
blah
blah
blah
pipelines
assigned
to
the
correct
people
and
box,
and
so
on,
and
in
there
we
plug
in
this
checker
that
says:
okay!
Well,
it's
going
to
be
cleanly
done,
post
back
a
message,
saying,
you're
clear:
we
are
ready
for
merge,
no
action
from
the
developer
same
way.
We
have
the
auto
deploy
cherry
picker,
which
prints
a
message
back,
saying:
hey,
I'm,
sorry,
blah
blah
blah
blah
blah.
C
C
C
C
Want
us
to
lock
in
the
steps
I
want
us
to
lock
in
the
steps
this
week,
because
I
think
this
not
like.
If
you
all
now
go
back
and
think
a
bit
about
this,
and
we
have
a
write
up
if
we
lock
down
the
exact
steps,
this
might
be
the
crucial
intersection
that
we
were
looking
for.
That
will
allow
us
not
to
have
more
of
these
calls
for
a
while,
but
we
don't
have
to
Amy
I
know
you're
away.
So,
let's,
let's
try
using
I.
D
C
Do
a
sing
first
and
see
my
right
if
we
get
locked
down
too
much
into
details
and
you're
not
getting
or
set
in
clear
direction
on
Thursday
your
time
just
set
something
up
for
for
Friday
between
the
three
of
us,
if
nothing
else,
but
I
think
you
should
like.
We
should
all
watch
this
recording
and
try
to
poke
holes
and
see
whether
we
can
whether
whether
this
is
this
should
be
the
way
to
go
forward.