►
From YouTube: 2020-09-01 - 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
Oh
wow,
okay,
I
upgraded
to
catalina
and
everything
is
broken.
You
were
saying
that
the
run
release,
merge
for
security
output,
less
issues
ready
to
be
processed
and
then
issues
not
ready
to
be
processed,
and
it
will
be
good
to
have
a
reason
why
those
issues
that
are
not
processed
why
they
are
not
processed.
A
Actually,
I
also
have
a
problem
with
a
problem.
I
have
an
improvement
request
for
for
the
output
in
general,
because.
A
Issues
ready
to
be
processed
number
number.
Okay,
that's
fine,
but
are
we
like?
Do
we
really
need
the
full
url
can't
we
use
some
markdown
or
whatever
slack
uses
to
actually
just
have
the
number
and
list
the
number,
and
that's
it
right,
like
it's
overwhelming,
like
it's
a
lot
of
text
and
then
the
second
thing,
if
we
use
the
same
approach
for
for
the
things
that
have
failed,
it's
easy
to
then
just
well
easy.
A
Then
it
doesn't
look
too
much
out
of
place
if
we
had
the
reason
like
dash
right
issue
that
was
not
processed
dashed
backwards,
not
ready
or
whatever
else
is
happening.
That
theoretically
would
reduce
the
clutter.
Although
now
that
I
say
it,
we
have
how
many
29
issues
here.
A
Do
you
really
need
to
list
all
issues
that
are
ready
to
be
processed
as
well?
What
are
we
going
to
do
with
that
information.
B
A
And
I
know
that
you
already
linked
that,
but
I
just
didn't:
have
the
moments
to
to
write
it
down
good
suggestion,
robert.
B
Okay,
so
let's
just
start
with
the
meeting,
there
are
several
points
there,
since
you
two
were
gone
for
the
last
two
weeks.
I
just
would
put
you
like
up
to
speed,
which
is
basically
that
all
we
did
is
to
change
the
way
security
implementations
issues
are
now
closed,
because
since
now
we
merged
that
merchant
was
targeted
master
earlier
and
then
the
backboards
are
merged
during
the
actual
security
release.
B
C
B
B
Okay
and
then
we
discussed
some
feedback
for
the
security
merge
command,
which
I
am
going
to
add
to
the
issue
and
then
moving
on
to
the
status
of
the
epic.
B
So
there
are
several
tiny
implementation
details
that
are
still
pending,
but
the
two
major
that
I
can
see
is
that
triggering
pipelines
for
merch
result
and
enable
the
merge
train,
which
I
am
currently
working-
and
I
have
an
item
later
and
robert-
is
working
or
already
implemented
the
automatic
toggling
of
merge
strain
based
on
the
mirror
status,
which
I
think
it
is
already
finished,
and
we
just
need
to
test
it
and
probably
set
a
schedule.
B
A
A
C
B
B
And
that
one
is
already
based
on
the
mirror
status.
Yes,
yes,
okay,
good
to
know,
I
had
no
idea
that
it
was
already
working.
A
Okay,
we'll
have
to
rename
the
project
at
certain
point.
I
guess,
although
we
should
tell
the
product
to
rename
theirs,
because
we
were
first
so
they
stole
our
name
anyway.
But
but
robert
just
just
a
question
for
you.
Why
would
we
have
a
separate
command
to
do
to
disable
like
or.
A
A
So
I
see
both
of
you
responded
amira.
You
said
used
at
least
same
interval.
A
So
how
about
we
just
run
it
once
an
hour
and
we're
done
with
it
because
myra
your
suggestion
about
timing
it,
together
with
how
to
deploy
branch
creation,
the
the
challenge.
There
is
timing,
because
the
merge
train
will
run,
but
the
pipeline
also
needs
to
finish
before
the
auto
deploy
branch
gets
created
because
otherwise
it's
going
to
create
it
from
the
commit
below
so
autodeploy
branch
gets
created
from
a
green
commit.
A
B
C
B
Okay,
great
and
then
so,
moving
on
to
trigger
pipelines
for
merge
result
and
enabling
the
merge
train
the
merge
train
the
feature,
not
our
merge
train.
So
from
the
configuration
side
it
seems
that
we
only
need
to
enable
some
setting
on
the
security
project
setting
and
we
should
be
ready
to
go.
I
do
have
like
some
questions
about
it.
I'm
not
sure
if
we
should
also
enable
pipelines
for
merge
results
for
the
back
ports,
because
stable
branches
are
mostly
static.
B
They
don't
receive
a
lot
of
changes
like
the
same
way
master
does
and
if
we
trigger
pipelines
for
each
backboard,
that
will
mean
that
we
will
trigger
a
bunch
of
pipelines
when
we
merge
the
backboards
like
taking
the
example
for
now.
We
have
29
27
security
issues.
If
we
multiply
that
by
three,
it
would
mean
like
80
something
pipelines
at
the
same
time,
which
they
are
not
really
necessary
for
backboards
and
they
might
increase
the
ci
cost.
I
guess
so.
What
do
you
think.
B
Yeah,
I
think
so.
My
understanding
of
the
merge
train
is
that
when
one
is
added,
when
one
merge
request
is
added,
then
a
pipeline
is
if
the
pipeline
is
pending.
Then
when
the
pipeline
finishes
another
one
starts
to
add
the
merge
train,
and
if
the
pipeline
is
already
finished,
when
the
merge
request
was
added,
another
one
starts
so
yeah
a
lot
of
pipelines.
C
A
One
in
if
you're
talking
about
merge
train
are
talking
about
the
queuing
system
and
the
queueing
system
is
first
in
first
out.
So,
basically,
as
we
iterate
through
the
list,
it's
going
to
add
every
merge
request
and
it's
going
to
wait
for
every
single
one
to
be
merged
then
run
tests.
On
top
of
that
then
merge
the
next
one
then
run
tests
on
top
of
that
and
merge
that
so
merge
train
itself.
A
I
don't
know
whether
that
actually
makes
a
lot
of
sense
for
for
backboards.
A
C
A
I
think
we
cannot
bet
on
that,
but
yeah,
of
course,
but
timeline
wise.
Theoretically,
it
should
be
good
to
go
because
we
are
actually
merging
sequentially
right.
We
are
merging
one
after
another.
We
don't
merge
at
the
same
time,
which
would
allow
a
bit
of
a
delay
between
the
two
and
github
is
never
quick
enough
to
actually
just
merge
immediately
right,
like
it
takes
some
time
to
do
this.
Sometimes
when
I
say
sometime
I
take
like,
even
if
it's
one
second,
it's
still
one
second
between
each
and
every
one
of
them.
C
B
Oh,
it
is,
it
is
the
bundled
they
are
together
like
okay,.
B
Well,
they
are
now
separated
by
a
feature
flag
that
is
going
to
be
removed.
So
once
the
feature
flap
is
removed,
it
is
the
both
of
them
together.
B
B
A
I
guess
what
I'm
trying
to
say
is:
I
don't
really
think
that
we
necessarily
need
the
merge
train
right,
the
order
of
merges
for
back
ports,
but
then
also
you
have
a
point
there,
because
do
we
then
even
need
merge
like
pipeline
results,
whatever
it's
called,
because
that's
going
to
do
the
same
thing,
because
when
you
click
the
merge
button,
it's
not
going
to
put
it
into
you,
but
it
is
going
to
try
to
run
the
tests
on
the
latest.
Whatever
is
in
the
stable
branch.
B
A
A
A
B
Okay,
yeah,
okay,
makes
sense,
so
I
asked
if
we
can
exclude
stable
branches
and
I
think
it
seems
we
can
so.
A
A
B
Okay,
so
just
another
question
is,
and
this
one,
my
I
think
it
is
going
to
apply
for
master,
is
that
we
have
a
lot
of
flacky
failures
right.
B
So
if
I
mean
if
the
merge
train,
if
a
pipeline
fails
the
merchant,
the
merge
request
is
going
to
be
removed
for
from
the
merge
train
and
if
it
is
alleged
failure.
That
is
fine,
but
if
it
is
a
flucky
failure
right
now,
we
have
no
way
to
track
those,
mrs
that
are
going
to
be
removed
by
the
merch
train
currently
on
canonical.
This
is
manually
done
like
on
the
www
gitlab.com
project.
A
I
had
a
lot
of
merge
requests
expected
to
be
merged,
looking
at
the
handbook
a
week
later
without
that
change,
and
then
I
only
find
out
that
for
some
whatever
reason
this
got
removed
and
I
got
no
notification
because
it
only
leaves
a
system
note,
it
doesn't
even
tells
you
anything.
C
C
C
C
A
I
would
I
would
prefer
that
myra,
so
this
is
one
of
the
cases
that
is
going
to
happen.
Often,
I
think
I
think
we
should
still
go
forward
with
this
with
enablement
of
this
and
just
see
how
of
a
serious
problem
this
is,
and
if
it
ends
up
being
really
serious,
like
we'll,
have
to
take
some
extra
care
as
release
managers
to.
A
I
don't
know,
do
what
actually
right
like
if
we
merge
things
frequently
and
we
see
the
same
issues
in
the
list
of
issues
not
ready
to
be
processed.
This
is
where
the
reason
for
why
issue
is
not
being
ready
to
process
would
be
a
good
actual
addition,
and
if
we
see
that,
then
we
can
manually
do
some
things,
but
that
will
allow
us
to
collect
some
data
as
well
to
go
back
to
product
and
say
we
want
to
help
out
fix
this
problem,
and
this
is
the
problem
we
are
trying
to
fix.
A
B
B
Yeah,
I
think
it
will
be
the
same
problem.
We
have
like
on
canonical
master
right
now
that
we
have
a
notification
popping
up
on
the
broken
master
channel
and
we
are
like.
Oh,
it
failed
because
it
is
a
lucky
one
and
we
ignore
it.
But
in
this
case
we
actually
need
to
do
something
so
yeah.
The
pace
is
quite
regular.
B
Okay,
so
just
an
fyi.
There
is
an
experiment,
a
schedule
for
the
first
week
of
september,
so
this
week
to
enable
the
merch
train
like
on
canonical.
So
I
I
think
it
will
be
interesting
to
keep
an
eye
on
it
to
see
what
sort
of
problems
they
are
dealing
with.
A
B
B
But
to
answer
your
question:
well,
I
think
if
you
continue
with
the
automatic
toggling
of
merge
train,
which
I
think
it
is
almost
ready
and
then
I
can
try
to
figure
it
out,
what
are
the
next
steps
for
triggering
the
pipelines
for
merge,
result
and
enabling
the
merge
train
and
if
I
need
help,
I
will
ping
you
on
that
issues
on
the
issue.
A
C
A
I'm
doing
three
things:
yeah.