►
From YouTube: 2020-09-15 - 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
thank
you
for
joining
to
another
security
releases
as
part
of
the
auto
deploy.
Let's
get
started
as
part
of
the
progress
update.
I
am
working
on
triggering
pipelines
for
merge
results
actually
and
just
that
we
are
not
going
to
enable
the
merge
train
and
I
got
the
implementation
merge
like
in
the
morning.
A
Thank
you,
robert
and
the
next
steps
is
to
well
to
test
it
to
see
that
it
is
actually
working,
and
that
is
probably
the
approach
that
we
are
going
to
use
on
the
security
release
that
is
scheduled
at
the
end
of
this
month.
Robert.
What
about
you.
B
Yes,
so
I
we've
been
seeing
these
transient
mirror
failures
for
the
master
branch
between
canonical
and
security,
and
I
honestly
have
no
idea
why
that's
happening
so.
The
first
step
is
kind
of
add
some
logging
to
getaway
to
figure
out
when
it
happens
and
kind
of
where
it's
failing,
hopefully
so
that
merge
quest
is
open.
I
believe
for
review,
and
hopefully
we'll
get
some
logs
soon
on
to
my
rest,
for
discussion.
A
So
we
are
going
to
modify
how
the
security
release
processes,
the
merge
requests,
and
last
week
we
had
a
question
about
what
projects
should
be
considered
for
the
early
merge,
the
early
window
in
which
we
merged
security,
merge
request
targeting
master
and
so
far
we
are
only
considering
the
gitlab
project
and
we
and
we
thought
that
we
could
consider
like
any
other
satellital
totality
project,
including
abnormal
runner,
italy
workhorse
pages,
and
I
think
those
are
it,
but
it
turns
out
that
we
can
only
consider
gitlab
and
of
nibbles
gitlab.
A
There
is
an
investigation
about
it
on
the
issue,
but
summarize
we
cannot
move
italy,
because
that
would
require
to
also
move
the
automatic
automatic
updating
task
to
be
on
security
once
the
branches
diverge,
and
that
requires
implementation
work.
I
mean
we
can
do
that,
but
we
cannot
do
that.
I
don't
think
we
can
do
it
on
the
first
iteration
and
then
for
workhorse
workhorse
pages
and
runner.
All
of
them
have
an
independent
security
release.
A
We
do
not
manage
or
merge
security
releases
for
those
projects
they
are
manually
merged
by
maintainers
and
the
merge
request
that
bombs.
The
version
on
gitlab
security
is
actually
created
after
they
attack,
so
we
don't
really
need
to
do
anything
else
for
those
and
well
for
apni
booze
to
merge
security
merchandise.
We
will
just
need
to
adjust
our
automatic
merge
train
between
canonical
and
security.
A
To
also
consider
opens.
B
Yeah,
we've
never
done
a
merge
train
for
on
the
bus.
So
I
assume
it
should
work
the
same,
but
I
don't
yeah
I've
never
seen
it
work,
so
I'm
a
little
hesitant
there
and
then
it's
also
it's
slightly
more
complicated,
because
then
you
have
to
have
a
separate
task
for
the
autobus
merch
train
because
it
can't
be
the
same
task
and
then
we
have
to
have
a
separate
toggle
for
that
because
it
could
fail
independently
right.
B
A
A
C
Yes,
so
I
just
saw
this
issue,
so
actually
mine
was
kind
of
a
question
I
suppose
is.
How
are
we
going
to
handle
patch
releases
safely,
like
specifically,
I'm
thinking
for
the
next
security
right,
not
next
for
the
next
yeah
for
the
next
prepping,
the
next
security
release
next
week.
A
Yeah,
so
we
just
discovered
last
week
also
that
actually
preparing
a
patch
release
in
the
middle
of
the
early
phase
of
merging
security,
merch
request
actually
leaks
the
security
fixes,
because
when
it
compiles
the
change
law,
it
publish
the
change
and
it
pushes
the
changes
to
all
repositories.
A
So
that
is
actually
a
good
question
and
I
think
we
are
still
trying
to
work
out
a
solution.
I
think
one
of
the
options
is
to
somehow
identify
that
we
already
merged
security
fixes,
and
if
that
is
identified,
we
don't
push
to
canonical
and
I
think
the
other
option
is
to
analyze.
If
this
can
be
solved
by
the
api
release.
That
yorick
is
working
on.
B
Yeah,
so
the
first
one
where
we're
like
identifying
security,
fixes
that
that
worries
me,
because
I
worry
like
how
do
we
actually
identify
and
then
what
happens?
If
we
don't
identify,
then
we've
leaked
everything.
The
problem
now
is
that
when
our
old
release
style
it
clones,
the
entire
repository
compiles
the
change
log
in
both
stable
and
master
and
then
pushes
the
entire
thing
to
all
the
remotes.
So
the
problem
there
is,
even
though
we're
only
working
with
the
change
log.
B
It's
also
pushing
the
entire
master
branch,
as
it
is
from
security,
so
that
will
leak
stuff.
The
reason
the
api
stuff
works
is
we're
only
modifying
the
change
log
directly
through
the
api.
So
nothing
else
in
that
master
branch
is
touched,
so
I
feel
like,
if
we're
close
to
the
api
based
release
stuff,
at
least
like
one
release
away.
I
think
that's,
probably
the
safer
solution
just
deal
with
this
one
more
release
and
then
not
worry
about
it.
Assuming
the
api
stuff
works.
B
C
Right
like
because
I
think
that's
what
makes
this
difficult
is
the
we're
like.
We
pretty
much
always
have
to
patch
right
around
that
time.
So
does
that
mean
we
need
to?
I
mean,
maybe
it's
part
of
4c,
but
like
maybe
we
we
can't
start
this
early,
merge
phases
so
soon
after
the
monthly
release.
A
Yeah,
I
think
the
first
step
would
be
to
figure
it
out,
like
the
api
release
approach
to
see
if
it
is
close
to
finish,
I
think
while
georgie's
well,
I
think
mpto,
but
I
don't
know
if
you
have
some
sort
of
news
about
it
or
I
think
the
boring
approach
for
the
next
security
release
is
to
reduce
the
window
in
which
we
merge
security.
A
Merge
requests,
in
which
I
also
have
a
point
below
the
agenda,
but
we
can
reduce
it
instead
of
being
five
days
or
six
days,
it
could
be
like
two
or
three
days.
C
Yeah,
so
I
think
on
the
api
stuff
like
I
think
we
can
be
pretty
pretty
confident
that
for
13.5
we'll
we
hopefully
won't
have
to
worry
about
this,
but
for
next
week
yeah
we'll
need
we'll
definitely
need
a
workaround.
What
is
the
risk
of.
C
Like
there
is
still
a
risk
right
that
we'll
find
a
s1
issue
like
a
bug
that
needs
to
be
patched
like
how
do
we
know
how
we
would
be
able
to
deal
with
that
if
we'd
already
started
the
merging.
A
C
Yeah,
okay,
could
we
make
this
a
separate
issue,
because
I
think
in
the
majority
of
the
conversation
on
that
issue
is
about
italy,
which
I
think
kind
of
hides
us.
I
think
this
is
I'd
like
to
make
sure
we
keep
keep
this
visible,
especially
if
we're
relying
on
the
api
release
work
to
be
finished,
so
we
can
check
that
off.
C
Actually,
I
pulled
that
into
a
separate
issue,
so
if
you're
doing
that,
it's
fine
so
I'll
split
that
the
comments
around
this
stuff
onto
something
separate,
so
we
can
track
it.
There.
B
Yeah
part
of
the
work
on
the
api
really
stuff
was
kind
of
refactoring.
The
way
the
changelog
compilation
works
to
use
the
api,
and
I
suggested
at
the
I'm
like
hey,
could
you
like?
Would
it
be
possible
to
extract
just
this
changelog
stuff?
So
we
can
start
using
that
right
away
and
york
was
hesitant
because
he
like
he'd
rather
just
have
like
api
stuff
uses
the
api
stuff
and
the
existing
stuff
uses
the
existing
stuff.
B
C
B
And
if
it
does
come
down
to,
like
we've,
started
merging
stuff
into
this
stable
branch
on
security,
and
then
we
have
to
fix
a
normal
p1s
one
there's
some
stuff
we
could
do
like.
We
could
branch
the
security
stable
off,
do
its
own
thing,
force,
push
the
existing
non-security
stuff
to
security,
stable
and
then
do
a
patch
release
and
then
bring
back
the
stable
branch
through
another
force.
Push
like
it's
it's
ugly,
but
if
we
have
to,
we
can.
A
Yeah,
I
guess
it
all
come
down
to
analyze
what
kind
of
security
fixes
have
been
merged.
I
mean
if
they
are
like
s4
or
s3.
I
know
it
is
not
the
best
idea
to
publish
them,
but
they
are
s3
and
also
we
can
do
something
hackish
like
robert
did
so
I
guess
we
do
have
some
some
solutions.
They
are
not
pretty,
but
we
do
have
them.
A
B
We
can't
create
the
branch
on
canonical
that
source
is
only
on
security,
so
we
have
to
create
it
first
on
security
from
the
auto
deploy
branch
and
then
that
will
go
to
build,
and
then
we
need
to
say
how
do
we
get
this
stable
branch
back
into
canonical
right
now?
We
don't
have
like
an
existing
solution
for
that.
The
sync
remote
service
that
I
mentioned
in
the
issue
will
first
try
to
clone
the
branch
you
give
it
from
canonical
and
it
won't
exist.
So
it
just
fails.
B
We
can
kind
of
repurpose
that
I
had
a
hackish
of
course
solution
in
the
issue
that
I
didn't
like,
but
I
was
hopeful.
Somebody
else
had
a
better
idea.
A
B
A
No,
no
because
I
mean
it
shouldn't
unless
we
pick
a
security,
merch
request.
B
A
I
mean
we
have
several
ways
of
creating
stable
branches,
not
just
from
the
auto
deploy
branch.
I
think
we
can
create
the
one
from
from
master.
We
can
create
it
from
the
current
auto
deploy
branch
and
we
can
create
it
for
a
specific
shot.
So
I
think
the
problem
is
when
we
want
to
create
it
from
the
current
auto
deploy
branch.
A
B
Rethinking
it
now,
I
think
the
issue
is
not
the
the
ee
project
but
omnibus,
and
that
one
will
the
last
auto
deploy
commit
will
be
something
that
only
exists
on
security,
because
it's
that
update
versions,
one
so
yeah.
I
don't
know
what
to
do
in
that
case,
because
it
won't
exist
on
canonical.
A
A
B
C
C
A
I
think
so
I
think
that's
we
want
to
investigate
why
the
branch
or
the
show
was
not
found
on
canonical,
because
that
is
weird
and
it
might
be
because
we
talk
before
creating
the
stable
branch,
but
that
doesn't
make
any
sense.
B
Looking
at
it
looking
at
the
code
when
it
creates
stable
branches
on
the
bus,
the
source,
the
omnivore,
stable
branch
will
always
be
the
current
auto
deploy
branch,
not
even
like
the
last
one.
We
deployed
it's
the
current
auto
deployment
and
then
that
will
only
exist
on
security.
A
B
So
like
we
can
go
back
and
grab
that.
Third,
one,
two
four
three,
two
four,
but
that's
not
gonna,
have
the
versions.
We
need
right.
It's
gonna,
it's
not
gonna,
have
the
updated
rails
version,
although
I
guess
we
tell
it
to
use
a
specific
rails
version
anyway
right.
It
should
just
be
the
same.
Thirteen
two
stable.
C
B
A
Yeah,
but
we
don't
merge
security
fixes
like
on
the
18
or
the
19.
Whatever
we
create
stable
branch,
we
just
do
it
after
the
22nd
or
the
23rd.
C
B
Yeah,
but
if
we're,
if
we're
still
dealing
with
automating
pushing
of
a
branch,
we
thought
that,
like
we
can't
do
that
through
the
api
we
still
have
to
clone
it.
We
still
have
to
push
it
to
all
remotes,
so
we
might
as
well
just
create
it
on
security
first
and
then
do
the
same
thing
where
we
push
it.
C
Yeah
always
going
to
be
a
problem
like
does
any
of
the
api
work
help
with
this.
B
A
A
I
think
it
is
kind
of
similar
that
about
your
suggestion
about
passing
the
specific
remotes
as
arguments,
but
yeah,
probably
another
approach
we
could
explore
here.
B
A
Yeah
yeah
yeah,
I
mean
I
think
we
can
continue
discussing
on
the
issue
or
on
the
march
request.
So
I
think
this
needs
more
investigation.
In
the
meantime,
we
can
either
push
the
auto
deploy
branch
yeah,
the
auto
deployment
branch
inaudibles
into
canonical,
and
it
is
manual
work,
but
we
have
a
workaround,
so
yeah,
okay.
So
this
is
my
point.
A
So
the
next
security
release
due
date.
It
is
currently
using
september
28th.
Sorry,
I
didn't
post
it
a
link.
Let
me
do
that
very
quickly.
It
is
this
one.
A
It
is
using
september
28th,
but
there
are
still
some
pending
items.
September
28th
is
monday.
So
since
there
are
some
neat
bits
that
we
need
to
figure
it
out,
what
do
you
think
about
moving
the
due
date
to
october
21st
and
then
have
the
early
march
phase
from
september
25th
to
october
30.
september
30th.
A
C
I
think
my
only
concern
is:
we
need
to
sort
out
something
for
the
patrol
leaders,
because
I
mean
we
probably
need
to
so.
25Th
is
a
friday,
so
we're
going
to
do
the
13.4
release
on
tuesday
I
mean
I
assume
we'll
have
probably
patched
on
maybe
the
24th,
but
we
might
want
to
just
double
check
that,
but
I
suppose
we
could
still
go
later
on
25th
right
like
we
could
we,
I
guess,
as
part
of
our
process.
We
just
need
to
make
sure
we.
A
Okay,
so
it
sounds
like
we
agreed
on
the
due
date
for
october
1st
and
then
depending
on
how
the
release
pays.
It
is
depending
if
we
need
to
patch
or
something
then
we
can
play
around
the
dates
for
the
early
emerging
of
security
merchandise.
C
I
think
that
sounds
pretty
accurate.
I'm
not
going
to
be
the
release
manager,
I'm
handing
off,
but
but
I
I
can't
see
any
reason
why
these
dates
don't
work.
C
It
is
eurek,
but
actually
I'm
gonna
think
about
whether
we
maybe
change
that
so
we
can
push
on
with
the
api
stuff.
But
I'll
come
back
to
you
on
that
one
so
yeah,
I
think
it's.
It
makes
sense
from
a
dates
point
of
view.
I
think
I
think
that's
fine
if
I
need
to
step
in
to
cover
any
that's,
absolutely
fine
as
well.
So
yeah,
that's
what
goes
in.
A
Okay,
so
it
seems
we
have
five
minutes.
Does
anyone
wants
to
bring
another
discussion
before
we
assigned
to
those
and
such.
C
Probably
just
one
thing
like,
I
think,
we've
got
a
few
things
to
like
at
least
understand
a
good
approach
on,
but
I'm
kind
of
wondering,
particularly
if
we're
waiting
on
the
api
stuff
to
go
through
whether
after
the
first
of
october,
we
like
are
we
going
to
well,
we
should
review
like
do.
We
have
enough
work
to
keep
going
on
this
stuff,
or
do
we
pause
on
here
for
some
weeks
or
months
or
whatever
and
see
how
the
process
is
working
before
we
decide
on
the
next
round
of
things?
So
we
can.
C
We
can
kind
of
see
how
that
goes.
I
think
in
the
next
week
or
two,
but
it
feels
like
we
are
pretty
close
to
having
a
workable
process.
Even
if
there's
a
few
bits
that
you
know
are
more
manual
than
we'd
like
it
looks
like
it
pretty
much
all
works,
which
is
amazing,.
A
Okay,
so
on
the
assignments,
I
think
robert
you're
going
to
look
into
having
omnibus
automatically
updated
with
the
merge
trend
and
the
mirror
thing,
and
I
think
you're
also
going
to
continue
investigating
what
happened
with
the
sha
in
the
auto,
deploy
when
created
when
creating
these
stable
branches.
C
Nice
and
I'll
get
that
patch
release
issue
sorted
out
and
thank
you.