►
From YouTube: 2023-07-12 AMA about GitLab releases
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
Okay,
I'll
go
ahead
and
get
started
since
we're
at
time.
So
welcome
everyone.
This
is
the
July,
the
12th
AMA
with
the
delivery
group,
so
we
are
looking
after
GitHub
releases
and
appointments
so
sand.
Thank
you
for
taking
the
first
question.
John
verbalize.
B
Sure
there
was
an
issue
that
I
that
Chun
relayed
to
me
about
features
for
the
federal
process
and
who
I
didn't
have
a
chance
to
read
the
whole
thing.
But
I
was
trying
to
get
an
idea
of.
Maybe
you
could
summarize.
You
know
what
you're
proposing
and
the
goals
here.
A
Yeah
absolutely
I
would
love
to
yeah,
so
this
is
been
a
sort
of
work
in
progress.
This
quarter
and
we're
hoping
to
take
the
sort
of
first
iteration
of
it
next
quarter,
so
very
timely.
So
what
we
currently
have
the
current
release
cycle
is:
we
have
a
monthly
release.
That's
on
the
22nd
of
the
month.
A
That
is
all
new,
like
changes
features
bugs
and
things
like
that,
and
then
we
have
a
scheduled
monthly
security
release,
which
is
usually
around
the
28th
of
the
month,
and
any
security
vulnerabilities
are
fixed
in
that
month.
Now
we
have
a
couple
of
challenges
for
that.
A
The
biggest
one
really
is
a
month
is
quite
a
long
time
like
if
we're
unfortunate
and
a
vulnerability
gets
reported
like
on
the
29th
of
the
month,
it's
very
painful
to
have
to
make
it
wait
through
to
the
next
month,
so
it
definitely
doesn't
meet
fedramp
needs
or
customer
needs
that
we
have
such
a
long
Gap.
The
other
challenge
that
we
have
because
of
these
long
gaps
is,
we
can't
always
wait.
A
So
it
often
we
spend
quite
a
lot
of
our
time
in
our
months,
doing
patch
releases
or
in
some
cases
having
to
put
out
critical
security
releases
to
address
individual
fixes.
So
what
we
want
to
get
to,
and
it's
a
little
bit
of
a
longer
term
view
we
want
to
get
to
the
stage
where
we
can
do
three
security
releases
per
month
and
have
the
monthly
release
and
we'll
roughly
be
looking
at
One
release
a
week.
A
In
order
to
facilitate
that,
we
will
combine
all
patch
releases
and
security
releases.
So
the
moment
those
are
separate,
they're,
completely
distinct,
release
processes
and
we
either
put
out
bug
fixes
or
we
put
out
a
security
release
which
may
have
some
bug
fixes.
What
we're
going
to
do
is
combine
our
processes
together
and
every
patch
release
would
just
be
whatever
security
fixes
and
whatever
bug
fixes
are
ready
to
go
would
be
released
on
a
on
a
weekly
basis.
A
So
that's
the
kind
of
goal
we're
hoping
to
be
able
to
start
work
on
this
in
Q3
and
it
would
be
iterative
so
we'll
probably
try
and
get
to
two
security
releases.
We
have
a
few
really
big
pieces.
We
need
to
to
solve
we're
working
with
upsec
on
this.
One
of
them
is
around
mirroring
so
right
now
we
mirror
from
the
security
repo
to
the
dev
repo
and
we
use
that
for
our
nightly
builds.
A
A
The
second
really
big
piece
is:
there's
a
lot
of
work
that
the
release
managers
and
also
sort
of
maintain
as
an
upset
go
through,
but
in
the
prep
for
a
security
release.
Right
now
we
basically
have
everything
that
is
intended
to
go
into
that
release
is
assigned,
and
then
we
work
through
and
try
and
figure
out
like
is
it
ready?
Could
it
be
ready
or
if
it's
not
ready,
how
do
we
move
it
on?
A
A
So
it's
quite
a
lot
of
work,
particularly
for
appsec
to
produce
the
security
release
blog
post,
and
we
have
a
much
more
automated
process
for
patch
releases,
so
we'd
want
to
try
and
find
some
way
of
bringing
those
together
so
that
we
don't
kind
of
overwhelm
people
with
work.
So
we've
got
a
few
pieces
but
we're
hoping
to
be
able
to
get
started
on
those
next
quarter.
B
B
A
customer
standpoint
I'm
always
worried,
because
you
know
it's
hard
enough
for
them
to
keep
up
with
our
monthly
releases
and
then
we're
talking
about
weekly
releases
it'd
be
great
for
us,
but
I,
don't
know
if
our
cons,
our
customers
would
be
able
to
keep
up
with
that
right.
As
upgrades
that
we
would
be
pushing
out,
then
so.
C
There's
some
some
comment:
I'll
try
and
find
it
that
I
left
on
this
with
a
bit
of
the
numbers,
but
over
I
think
the
past
six
minor
releases
we've
on
average
pushed
out
kind
of
at
least
eight
or
nine
patch
releases,
and
this
would
actually
bring
that
number
down
to
four
more
regularly
and
kind
of
top
out.
As
we
do.
The
maintenance
policy
you
know
closer
to
eight
I
think
we're
just
on
15.11.12.
C
And
may
may
increment
that
further
so
I
think
it
can
be
a
it
looks
like
more,
but
it
should
be
less
over.
The
distance
is
what
we're
we're,
anticipating.
A
Yeah
definitely,
and
hopefully,
they'll
all
be
a
bit
smaller
as
well,
because
it's
not
like
more
security
vulnerabilities,
it's
just
instead
of
one
a
month,
security
release
which
maybe
has
25
vulnerabilities,
hopefully
we'd,
be
able
to
spread
that
a
bit
so
for
the
the
people
who
do
need
to
do
more
manual
verification.
Hopefully
that
gets
a
bit
easier
as
well.
A
D
So
what
was
exciting
about
this
price
to
start
to
see
the
practical
application,
what
we
are
working,
this
water,
so
the
ability
to
shift
traffic
between
different
deployments
and
get
to
the
Practical
part
where
we
can
see
how
this
is
impacting
the
deployments
or
how
we?
This
is
practically
also
the
road
backs,
because
we
expecting
to
have
faster
Robux
into
that
and
implementing
different
strategies
for
that
right.
D
Is
it
still
pretty
far
out,
but
at
least
we
are
understanding
the
solution
we
are
implementing
and
right
now
is
viable,
I
understand
which
are
the
moving
parts.
We
need
to
start
to
look
at
that
are
coded
like
implementing
of
the
deploy,
how
we
can
integrate
with
that
and.
E
D
This
will
be
will
become
like
in
the
next
quarters
or
so,
but
having
we're
very
excited
to
see
the
outcome
of
this
and
we're
very
excited
to
see
how
much
this
can
move,
the
needle,
and
especially
in
risky
rollouts,
for
instance,
like
the
Ruby
hero
louds
that
we
had
having
this
capability
already
back
at
the
time
would
help
us
like
to
the
risk.
D
Everything
in
would
have
much
bigger
impact
and
not
like
you
know,
stop
the
entire
company
for
deploying
something
for
40
hours
and
mobilizing
like
so
many
people
from
so
many
teams
right.
We
could
even
do
this
like
in
a
with
an
intellective
approach
and
expose
like
different.
B
D
A
D
There
will
be
available
as
a
outcome
of
the
this
or
this
okr
or
this
quarter
that
we
work
on,
and
then
there
will
be
a
lot
of
discussion
issues
actually
to
understand
how
to
move
these
two
later
environment
like
staging
and
production
right.
So
there
will
be
a
moment
where
okay,
with
this
functionality
is
what
is
gonna,
we
need,
and
it's
both
gonna
provide
value
to
the
development
teams
and
to
our
customer
at
the
end.
But
how
do
we
implement
this?
How
to
integrate
this
in
the
current
processes?
D
A
E
I'm
very
very
excited
about
decreasing
the
active
time
we
do
on
security
releases
because
it
is
one
of
our
hardest
process.
I'm
most
excited
about
doing
this
combination
of
patch
and
security
releases.
E
What
else
I'm
also
quite
excited
about
reducing
the
cognitive
load
for
release
managers,
because
this
is
something
that
we
have
been
working
in
the
past
month
and
I?
Think
that
is
going
to
have
a
great
impact,
because
then
release
managers
are
going
to
be
able
to
focus
on
doing
this
more
frequent
patch
and
security
releases
that
are
combined
even
more
deployments.
So
I'm
quite
excited
about
that.
A
Awesome
thanks
for
sharing
and
yeah
I,
just
linked
in
the
security
release,
epic,
because
yeah
I
agree
this
one's
a
really
interesting
one.
So
our
motivation
is:
how
can
we
reduce
the
workload
around
security
releases,
which
is
actually
a
kind
of
pre-step
for
us
having
more
security
releases?
A
But
this
one's
really
exciting,
because
we
have
been
moving
manual
tasks
which
are
we
have
a
lot
of
very
small
manual
tasks
that
we
tend
to
do
either
with
like
a
chat,
ops,
command
or
go
and
look
at
a
thing
with
removing
all
of
those
onto
a
CI
CD
pipeline.
A
So
we've
just
done
the
easier
ones,
the
first
steps
and
we're
doing
the
last
steps
right
now,
which
is
sort
of
administrative,
but
I
think
this
will
be
a
really
exciting
way
for
us
to
be
able
to
automate,
hopefully,
all
of
our
release
processes
and
put
them
on
pipelines
with
jobs
and
things
so
really
really
exciting.
Direction.
E
So
for
context
we
in
delivery.
We
use
this
metric
that
is
called
mttp.
That
is
the
mean
time
to
production
and
it
is
measuring
the
time
it
takes
for
a
merch
request
from
the
moment.
It
is
merge
to
be
deployed
to
gitlab.com.
We
have
a
standard
of
12
hours
and
I
was
checking
this
page
and
I'm
actually
going
to
share
my
screen.
E
So
it
is
easier
to
explain
so
I'm,
not
sure
if
this
is
because
how
it
is
recollected,
how
are
the
metrics
are
collected,
but,
for
example,
we
can
see
that
we
have
this
trend
of
12,
23
or
something,
but
here
in
July
we
have
46..
A
Right,
yes,
okay,
so
we're
already
on
the
12th
of
the
month,
so
the
numbers
get
skewed
a
little
bit
heavily
if
we
have
something
that
is
very
significant,
but
last
week
was
the
first
week
first
week
of
the
first
working
week
of
the
month,
so
the
first
was
on
a
Saturday
and
we
had
a
family
and
friends
day
and
we
had
a
two-day
deployment
block
to
cover
the
change
request,
and
then
this
Monday
we
had
a
PCL,
so
that
reflects
very
poorly
at
this
stage
in
the
month.
A
I
expect
that,
with
several
normal
weeks
of
deployments,
we'll
see
it
come
please
it
will
still
be
high,
I
think
mttp
for
this
month,
because
we've
had
sort
of
that's
four
days
effectively
without
real
deployments,
but
it
should
come
back
down
awesome
thanks
for
adding
some
colors,
but
also
one
other
thing
that
is
visible
on
that
mttp
metric
is
the
past.
Three
months
have
been
higher
than
we
were
previously,
and
that
is
because
we
have
currently.
We
have
no
APAC
release
management
cover
so
previously
being
able
to
deploy
All
Around.
A
The
Clock
helped
us
with
that,
but
because
of
reallocating
and
sort
of
helping
out
another
projects
we
haven't
had
that
available
to
us.
So
that's
another
reason
why
mttp
is
a
bit
higher
at
the
moment.
B
Well,
I
have
one
final
question:
is
there
anything
that,
in
light
of
all
these
incidents,
production
change,
locks
and
all
that
that
you're
thinking
about
doing
to
ensure
you
know
better
stability
on
github.com.
A
Yes,
there
are,
there
are
definite
discussions
taking
place
around
that,
like,
of
course,
we
are
in
an
Ideal
World.
We
would
have
like
yeah
100
stability
and
also
deployment
rolling
through
as
rapidly
as
they
can
so.
Yes,
there
are
definitely
discussions
ongoing
right
now
about
ways
we
can
improve
things
ways
we
can
like
improve
testing
and
ways.
A
A
In
which
case
thanks
everybody
for
joining,
thank
you
for
all
the
questions
and
for
the
answers
and
I
hope.
You'll
have
a
great
rest
of
your
day.
Take
care,
bye.