►
From YouTube: 2020-07-07 - 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).
B
So
just
a
quick
status
update
there,
we
can
do
that.
A
synchronously
I
think
we're
just
about
ready
to
turn
on
the
feature
flag,
but
I
thought
of
one
other
thing
last
night
that
we
don't
necessarily
want
to
sync
the
auto
deploy
branches
across
all
the
remotes
after
we
release
anymore,
but
Myra
I
think
we
can
just
not
sync
it
at
all
right,
because
it
only
needs
to
go
from
security
to
build
which
are
already
well.
C
Good
question
I
know
why
we
want
approval
for
four
master,
only
from
ab
sac,
but
I'm
afraid
this
is
gonna,
create
a
confusion.
It
already
did
actually
create
a
confusion
of
who,
like
where
does
AB
set
needs
to
approve.
Do
we
want
to
consider
having
just
one
process
and
say
approval
from
these
two,
regardless
of
backports
or
not
I,.
A
C
Challenge
here
is
you
know,
in
majority
of
the
cases
sure
master
is,
or
rather
the
backwards
are
the
same
as
the
the
one
targeting
master.
There
are
cases
where
that's
not
the
true,
the
truth
right.
So
what
do
we
do
in
that
situation?
And
then
I'm
gonna
refer
to
yesterday's
security
release
that
we
did
where
there
was
confusion
on
whether
we
need
approvals
for
backward,
so
I'm
not
going
to
push
for
this
I'm
placing
this
in
your
heads.
B
So
it
becomes
the
combination
of
the
two
kind
of,
and
that
seems
to
work.
I
mean
it's
got
the
usual
problems
of
the
merge
train
that
we
already
know
about.
Where,
like
your
commented,
that
we
only
do
the
foss
merge
train
every
couple
of
hours,
because
if
we
do
it
on
every
commit
and
we'll
create
all
these
duplicate
pipelines,
it
has
like
a
generic
commit
message
where
it's
just
like
latest
changes
from
master
which
may
or
may
not
be
necessary.
B
So
I
guess
that's
kind
of
our
next
big
discussion.
Point
is
like
if
we
merge
that
branch
immediately,
that
doesn't
necessarily
mean
it's
ready
for
the
next
security
release
right
something
could
be
merged
and
sit
there
for
weeks
and
it's
not
something
that,
like
maybe
the
backboard
starts
right
here.
A
So
before
we
go
into
the
publish
problem,
that
is
another
different
problem:
I
just
want
to
check
if
creating
another
branch.
Is
that
solute
the
solution
that
we
want
to
choose?
Because
in
our
prior
discussions
we
also
talked
about
well
the
fact
that
another
branch
access
we
have
master
and
we
will
have
security
master
and
then
the
tree
stables.
Not
we
are
funding
five
branches
and
then,
of
course,
that
means
that
it
is
maintenance.
A
B
Yeah
I
guess
the
alternative
we
talked
about.
There
was
creating
that
kind
of
mirror
strategy.
Where
we
say
this
branch
is
not
just
mirrored
it's
merged
and
yeah,
it's
possible,
that's
where
we
want
to
get
to
ultimately,
but
that's
I,
think
that's
that's
the
one
that
has
the
most
development
overhead
right.
We
have
to
do
UX
and
create
it
has
to
be
reusable
by
everybody
versus
merging.
We
just
like
Yolo
use
it
ourselves.
A
C
What
what
I'm,
seeing
that
with
mirroring
with
merge,
is
that
we
already
have
all
the
tools,
all
that,
like
completely
rudimentary
and
hacky,
to
do
the
same
thing,
but
right
now
what
I
mean
right
like
we
have
mirroring
and
we
have
a
way
of
merging.
Why
would
we
want
to
build
a
feature
that
gives
us
that
same
thing
like?
Why
would
you
want
to
set
out
on
that
same
route
like
the
difference
would
be?
B
C
C
B
C
B
C
C
My
point
is
like
that:
I
see
a
common
line
between
the
two
and
one
while
being
harder,
like
you
said,
Mara
initially
for
us,
with
multiple
branches
to
care
for
and
so
on,
puts
debt
on
us
versus
a
feature
that
is
still
on
us
that
we
need
to
define
design,
develop,
run
an
idyllic
see
where
I'm
going
with
this,
like
it
took
us
a
while
to
even
get
this
just
mirroring.
Keep
divergent
rest,
let
alone
merge
as
well
with
mirroring,
like
I
sure
whether
we
want
to
go
that
way.
C
C
B
D
B
Yeah,
hopefully,
that
that
land
in
my-
why
do
we
want
this?
It's
so
that
we
can
have
stuff
merged
as
soon
as
it's
ready
in
security
security
fixes
can
be
merged
as
soon
as
they're
ready
and
then
those
can
ultimately
be
the
source
of
what
we
create
the
auto
deploy
branch
from,
so
that
we
are
always
deploying
both
the
latest
development
changes
and
the
latest
security
fixes,
like
kind
of
behind
the
scenes
where
we're
not
necessarily
releasing
all
that
stuff
yet
but
get
like
calm,
has
it.
A
B
B
C
C
You
know
what
we
are
missing
here
apart
from
a
magical
solution
that
will
appear
out
of
thin
air
and
resolve
all
our
problems.
I,
actually
don't
understand
the
volume
that
we
expect
to
see.
I
don't
understand
how
often
will
divergence
happen.
We
need
some
data
running
me
to
understand
how
many
security
merging
class
we
see
throughout
the
month
when
they
are
ready.
So
the
moment
they
are
assigned
to
get
lab
release
bot
would
indicate
that
they
are
ready
and
to
try
to
graph
a
bit
over
a
period.
C
Let's
say
a
quarter
or
a
three
month
period
understand
at
which
points
emerge
request
would
be
merged,
which
would
give
us
an
understanding
of
how
frequently
we'll
canonical
and
security
master
be
diverging,
because
those
two
like
knowing
that
information
actually
should
inform
our
decision
here,
because
we
are
trying
to
make
a
decision
on
something
that
is
potentially
dangerous,
very
involved
from
our
side,
without
actually
understanding
how
often
we
will
see
something
like
that.
Maybe
most
of
the
time
the
branches
are
not
going
to
leverage.
B
C
But
that's
that's!
The
thing
is
that
is
a
function
of
us
accumulating
having
accumulation
point.
What
I'm
trying
to
say
here
is
that
there
is
a
time
like
that.
14,
those
pretty
much
requests
are
stretched
over
a
period
of
a
month.
If
you
find
a
way
to
see
the
moment
when
they
were
ready,
so
that
is
the
assigned
to
merge
request
so
to
release
both
meaning
approved,
reviewed
and
so
on.
C
C
Point
where
you
know
people
are
now
preparing
the
security
requests,
knowing
that
in
a
week
time
they
have
to
do
they'll
have
to
do
it
right
and
maybe
but
again
like
I'm,
using
a
lot
of,
maybe
because
I
think
we
know
it's
a
feeling
that
we
have
informed
by
a
process
that
we
enforce
at
the
moment.
If
we.
C
B
C
C
A
Think
it
makes
sense
to
see
the
data
and
I
mean
I,
wouldn't
be
surprised
to
find
out
that
most
of
the
security
reliefs
are
prepare
right
now
the
sweetie
fixes
are
preparing
out
like
one
week
before
the
security
release,
which
is
after
the
22nd,
because
to
date,
at
the
end
of
the
month
like
we
also
need
to
consider
that
they
do
that
of
the
security.
Really,
the
regular
ones
are
like
two
days
or
three
days
after
the
end
of
the
month.
A
A
D
I
I
just
find
I
think
gathering
some
data
would
help.
Definitely
I
think
I'm
unclear
on
how
much
behavior
is
driven
by
the
current
process
and
how
much
it's
like.
We
would
want
to
protect
and
support.
So,
for
example,
like
you
know
this,
we
don't
want
this
security
fix
to
be
merged
into
the
release
for
the
22nd,
for
example
like
one
of
those
scenarios
and
what
are
ones
where.
Actually
it
doesn't
matter,
we
should
just
make
it
simple.
I
think
it'd
be
really
interesting
to
see
like
how
they
are
being
handled.
B
B
C
C
There's
gonna
be
some
discrepancy,
probably
but
yes,
yeah,
because
theoretically
they
should
be
assigning
to
digital
to
release,
but
when
they
have
all
the
approvals,
unless
they
assigned
it
and
then
the
bottle
them,
you
didn't
get
an
approval.
You
didn't
get.
You
are
missing
five,
so
yeah
I,
guess:
that's
why
we.
C
B
A
Yeah
I
think
I
think
the
buck-buck
persuading
it
is
fine
until
the
security
releases
starts
because,
yes,
that
is
the
security
release.
So
we
thought
that
that
would
you
get
before
a
problem,
because
once
the
security,
our
merge
immediately,
let's
suppose
that
we
already
have
that
in
system
and
they
are
merging
medially.
C
Sure,
but
the
thing
is
back,
ports
are
ready.
The
moment
that
merge,
request
to
master
is
ready
right,
like
we
remember,
that's
right
now,
and
that's
not
going
to
change
I,
don't
think
we
should
change
it.
We
have
to
have
master
and
back
ports
reviewed
and
ready
for
release.
So
the
difference
here
is
we
would
be
merging
master
immediately
while
waiting
for
backwards,
try
to
accumulate
or
for
us
to
do
the
release.
So
from
that
side,
that
shouldn't
be
a
problem
unless
I'm
missing
your
point,
overt,
like.
C
A
Okay,
why.
A
B
I'm
wondering
about
like
the
timing,
for
that
I
want
to
do
it
if
possible,
like
just
before.
We
create
the
next
out
it'll
play
branch
so
like
everything's
kind
of
started
from
that
new
branch,
rather
than
like
doing
it
midday
right
now,
where
we
have
one
branch,
that's
already
on
canonical
and
then
suddenly
we're
only
potentially
cherry
picking
stuff
in
the
security.
So
if
we
can
possibly
like
what
time,
I
have
to
look
at
what
time
branches
get
to
create
it
and
see
if
somebody
maybe
I
think.
B
B
C
C
D
D
C
I
think
he
might
have
it
with
true
labels
on
the
actual
merge
requests
that
are
being
pushed
into
security.
So
every
merge
request
that
is
emerging
to
master
would
be
not
having
a
label
or
having
a
specific
label
which
would
then
be
collected
at
a
certain
point
in
time
and
that
merge
request
cherry-picked
into
whatever
the
main
ends
up
being
that's
the
idea
at
least
I
had
in
my
head
like
how
what
kind
of
edge
cases
we
have
there
I,
don't
I,
don't
follow
fully.
D
C
Could
it
be
handled
by
process
and
saying
that
everything
that
is
on
the
run
up
to
the
22nd
inside
of
the
branch
inside
of
the
security
branch
has
to
go
out
in
a
security
release
in
a
back
porch?
This
way,
then,
we
also
read
resolve
one
other
problem
that
people
have
which
is
not
having
the
future
stable
branch
to
target.
If
we
pull
down
all
the
work
and
say
that
current,
stable
branches
and
master
are
the
ones
that
are
the
policy,
it
means
by
the
22nd.
D
Well,
let's
see
what
the
data
says,
I
think
that'll
be
really
I,
think
that
will
help,
because
I
think
it
will
show
right.
I
said
it's
kind
of
like
what
what's
first
like,
what's
going
to
have
to
depend
on
the
other,
because
I
think
only
one
can
be
stable,
I
think
that's
probably
in
my
head,
like
only
one
thing
stable
and
everything
is
diverging
off
that.
So
what's
the
stable
thing.
C
A
Well,
if
it
makes
you
feel
better,
that
is
the
exact
same
feeling
we
had
when
we
move
security
development
from
death
to
security
like
we
had
no
idea
about
what
all
the
other
changes
that
were
required,
but
we
discover
them
once
we
were
moving
on
so
I
guess
as
long
as
we
have
something
to
do,
and
we
keep
walking
I'm
sure
we
are
going
to
find
a
lot
of
problems.
I
don't
know
I'm,
not
really,
that
is
going
to
make.
You
feel
better.
Buddy.