►
From YouTube: 2021-06-09 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
B
Okay,
I'll
just
give
it
up
one
a
few
more
seconds,
and
then
we
shall.
C
B
Okay,
so
let's
get
started
so
welcome
everyone.
This
is
the
june
delivery
team,
ama,
so
we'll
be
answering
questions
around
deployments
releases
and
any
of
the
delivery
team
projects.
B
C
I
appreciate
the
answer
you
pretty
much
already
took
care
of
it.
This
came
up
with
the
jihu
team
yesterday
during
during
their
sync
there's
a
few,
mrs
that
they've
upstream,
to
the
get
lab
projects
that
they
have
self
self
managed
customers
of
theirs
that
are
very
interested
in
getting
those
fixes
and
specifically
in
1312,
because
they
may
not
be
able
to
support
all
the
breaking
changes
that
are
coming
in
14-0.
C
So
I
wanted
to
just
ask
to
confirm
my
understanding
of
the
process.
I
thought
this
would
be
a
great,
a
great
opportunity
for
it.
So
before
we
add
the
pick
into
1312,
we
would
need
to
categorize
them
as
like
a
we
need
to
follow
the
process
you
have
where
they
need
to
be
like
a
security
one
or
severity,
two
issue
for
them
to
be
picked
appropriately.
Is
that
a
fair
summary.
B
Yes,
that
would
be
perfect,
so
we're
considering
all
the
jihu
contributions
to
be
exactly
as
a
regular
contribution
contributor.
So
the
steps
in
the
document
should
follow.
For
that
one.
B
I
suppose
to
your
your
further
point
in
sort
of
b
is,
I
suppose,
the
question
of
of
when
we
can't
make
that
assessment.
That's
probably
a
bit
more
like
a
bigger
question
right,
so
I
don't
know:
do
we
have
any
existing
contributor
kind
of
assessment
guidelines
that
we
could
we
could
lean
on
for
this.
B
Okay,
I'm
wondering
if
we
need
to
if
we
should
consider
an
update
to
the
actual
like
so
in
an
ideal
world,
could
you
who
would
be
able
to
kind
of
make
their
own
severity
assessment
the
same
as
any
other
contributor?
B
I
think
for
this
case
like
if,
if
we,
if
we
don't
know,
I
think
going
with
an
s2-
is
fine,
so
just
kind
of
a
little
bit
of
extra
context.
We
use
these
severity
labels
to
decide
how
urgently
we
need
to
patch.
B
So
we
wouldn't
want
to
just
kind
of
blanket
s1
everything
because
we'll
be
patching
every
day,
and
you
know
it's
a
huge
amount
of
extra
work,
but
I
think
having
them
labeled
as
an
s2
would
mean
that
you
know
we
would
be
aware
of
them
and
they
would
be
included
in
the
next
patch,
but
an
ideal
would
be
to
actually
see
if
maybe
we
could
extend
our
like
severity
table
to
actually
maybe
just
have
the
wording
in
there.
That
would
allow
jehu
to
be
able
to
make
an
accurate
severity
assessment
as
well.
C
Yeah,
what
got
me
thinking
so
I
I
was
not
able
to
participate
in
the
sync
discussion
on
this
and
there
will
be
an
issue
that
I'll
tag
you
in,
but
I
think
we
need
to
update
definitely
some
handbook
pages
to
make
it
clear
the
guidelines
around
this,
because
I
also
don't
want
to
encourage
the
jihu
team
to
say
a
customer
really
wants
this.
Let's
get
it
into
it
like.
C
I
don't
want
to
increase
your
team's
workload
for
this,
so
I
wanted
to
understand
the
process
first
and
then
look
to
document
guidelines
around
to
to
the
jihu
team
and
the
gitlab
team
on
when
this
should
be
done,
especially
if
it's
you
know
like
a
slight
bug
fix,
which
one
of
these,
mrs,
is
just
like
a
smaller
bug
fix,
I
would
say:
that's
right.
Yeah.
B
Exactly
yeah,
I
appreciate
that,
let's,
like
definitely
let's.
B
C
Going
to
create
it,
so
I
didn't
want
to
jump
in
and
create
one
as
he
already
had
one
in
flight,
but
I
appreciate
all
the
the
help
and
the
pointers
on
the
process
and
we'll
we'll
go
from
there
async
in
an
issue.
That's.
B
So
a
slight
kind
of
additional
one,
I
suppose
for
this
month
is.
We
are,
of
course
preparing
for
the
14.0
breaking
changes
release
is
there
anyone
on
the
call
who
would
like
to
kind
of
clarify
how
to
go
about
getting
something
into
that
release,
or
are
there
any
questions
around
the
actual
release?
Preparation
process
that
will
be
will
be.
A
Used,
I
can't
find
the
agenda
right
now,
but
I
do
have
I
I
have
a
question
for
documentation.
A
Is
there
a
cut
off
date
for
when
documentation
would
be
added
for
the
14.0
release
versus
a
later
release?.
D
So
first
I
have
a
question
to
clarify
your
question.
Greg,
which
is,
are
you
referring
to
documentation
that
is
bundled
in
the
package
or
that
is
published
on
docs.github.org.com.
D
Okay,
so
the
cutoff
date
is
the
same
for
code
changes
in
that
case,
because
we
cannot
afford
running
extra
rc
so
in
it's
a
bit
unfortunate
this
month
because
of
weekends,
and
things
like
that,
so
I
will
quickly
check
you
to
date,
which
always
remember,
is
a
tentative
date,
because
it
really
depends
on
the
stages
of
incident
and
things
like
that.
But
we
will
start.
Oh,
is
it
perceived?
B
D
D
There's
seven
themes,
so
what
is
so
some
at
some
time
in
on
the
17th
release
managers
we
decide
to
run
rc42
and
the
this
is
not
what
is
merged
up
to
that
point,
but
is
what
was
deployed
on
production
up
to
that
point,
so
yeah,
more
or
less,
you
can
consider
16th
as
a
kind
of
edgy
situation
and
15
can
be
kind
of
safe.
B
So
greg
your
next
question.
A
Yeah,
oh,
I
got
another
one.
So
when
will
the
14.0
release
candidate
package
be
available
for
hands-on
testing.
D
We
create
it,
oh
yeah,
I
don't
remember
if
we
published
this
directly
of
or
not.
This
is
something
that
I
don't
remember,
but
we
we
we
tag
on
the
on
the
17th,
so
you
should
be
able
to
find
it
perfect.
Thank
you.
B
Okay,
fantastic!
Thank
you
so
much
everyone
for
your
time
today
and
all
the
questions.
If
you
need
anything
like
async,
you
think
of
something
straight
after
then
we're
in
due
delivery
during
school
delivery
and
slack.
We
obviously
answer
questions
there
as
well.
B
So
thanks
everyone
for
joining
today
and
have
a
good
rest
of
your
day
take
care.