►
From YouTube: 2023-09-15 Overview of upcoming release process changes
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
A
This
is
a
company-wide
change,
but
it's
going
to
mean
that,
whereas
we've
always
normally
released
on
the
22nd
of
the
month
from
16.6,
which
is
in
November,
we'll
be
releasing
from
the
third
Thursday
of
the
month,
so
I've
linked
there's
an
epic
here
which
has
the
company-wide
changes,
so
you
can
follow
along.
This
affects
many
teams
and
the
idea
behind
the
change
is
to
get
people
not
working
on
weekends.
A
A
A
So
the
second
change
we
have
coming
is
around
supporting
multiple
security
releases
per
month.
So.
Currently
we
just
have
one
scheduled
security
release
each
month,
there's
usually
around
a
week
after
our
monthly
release.
So
in
August,
for
example,
it
was
on
the
31st
of
August
and
the
challenge
really
is.
This
creates
quite
high
pressure.
So
if
you
have
to
fix
a
certain
vulnerability
for
a
certain
date,
you
must
make
this
release
and
there
are
lots
of
steps
involved
in
reviews
and
pipelines
and
actually
getting
fixes
in
place
to
allow
you
to
do
that.
A
The
release
managers
also
have
quite
a
lot
of
work
as
they
try
to
complete
all
of
the
release.
Preparation
steps
in
order
to
hit
this
release
date
and
sometimes
having
these
long
gaps
between
our
security
releases
can
also
increase
our
need
for
critical
security
releases.
So
if
we
find
a
vulnerability
early
in
the
month,
we
may
not
be
able
to
wait
for
the
planned
security
release
in
order
to
fix
it.
A
So
it
means
we're
getting
more
releases
and
pushing
out
more
packages
for
our
customers,
but
at
the
same
time,
customers
are
actually
already
receiving
High
numbers
of
packages
and
that's
from
our
different
types
of
release.
So
in
August,
for
example,
people
would
have
seen
notifications
for
five
different
packages,
as
we
had
our
patch
releases
and
our
security
releases
and
I
also
our
monthly
release.
A
They're
roughly
made
up
of
these
six
different
steps,
so
the
first
one
is
around
the
preparation.
So
a
lot
of
work
goes
into
triaging
vulnerabilities
and
then
fixing
them
and
getting
the
four
different.
Merge,
requests,
ready
and
reviewed
and
passing
pipelines
and
like
a
whole
load
of
work,
goes
into
that
and
we
actually
come
to
prepare
the
actual
security
release.
So
some
initial
work,
where
we
basically
try
to
avoid
revealing
any
vulnerabilities
ahead
of
time,
so
we
move
over
to
our
security
mirror.
We
also
turn
off
nightly
builds
so
we're
not
revealing
anything.
A
Following
this,
we're
able
to
merge
in
all
the
back
ports
for
all
of
our
other
versions
and
go
through
our
steps
for
our
release.
Preparation.
So
at
this
point,
we're
very
dependent
on
working
mirrors,
passing
pipelines
for
all
of
the
merge
requests
and
generally
just
having
the
system
in
a
very
healthy
state
to
allow
us
to
complete
the
packaging
testing
and
releasing
and
then
the
very
final
steps
we
switch
back
to
our
canonical
repository.
We
re-enable
our
nightly
builds
and
we
revert
back
to
our
normal
state
of
working.
A
It's
a
very
high
number
of
touch
points
at
every
stage
of
the
release
and
we
have
quite
significant
impact
if
things
go
wrong,
so
we
may
end
up
unintentionally
revealing
vulnerabilities
to
users,
or
we
may
also
end
up
with
very
sort
of
high
severity
fixes,
perhaps
not
making
the
release
or
in
some
cases
we
have
to
postpone
a
release.
Or
you
know
it's
very
high
impact.
If
we
need
to
adjust
things,
there's
lots
of
impact
on
teams
and
users,
particularly
as
we're
operating
out
of
our
security
mirror.
A
So
before
we
go
ahead
and
actually
announce
like
multiple
security
releases
each
month,
we
want
to
improve
the
process,
so
we'll
be
doing
this
incrementally,
because
it
is
quite
a
complicated
process
already
and
we'll
be
making
announcements
ahead
of
each
change.
But
roughly
we're
planning
to
reduce
manual
steps
improve
the
communication.
So
you
have
a
better
idea
of
what
to
expect
when
to
expect
it
and
understand.
Maybe
more
is
a
fix
intended
to
be
at
the
next
release
or
not.
A
Overall,
we
want
to
have
shorter
release
preparations,
so
it's
less
impact
less
work
for
everybody.
Part
of
this
will
be
coming
from
as
automating
processor,
so
we
can
actually
combine
our
bug,
fixes
and
combine
our
security
fixes.
So
every
patch
release
is
a
combination
of
the
two
and
then
once
we
have
these
things
in
place,
we
can
start
to
move
to
multiple
scheduled
security
releases
per
month.
A
So
there's
quite
a
lot
of
work
that
will
go
into
this.
We
have
an
epic
which
we
can
follow,
along
with
all
the
different
issues
and
changes,
we're
planning
discussions
as
well,
and
we
also
have
an
issue
which
has
the
sort
of
overview
of
what
we're
planning
and
we'll
give
updates
on
the
completed
process
updates
so
follow
along
there
or
ask
us
questions
if
you're
not
sure
about
anything
and
we'll
be
communicating
via
that
issue
as
well.