►
From YouTube: 2023-03-15 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
We
are
delivery,
are
working
to
extend
the
maintenance
policy,
so
we
can
cover
up
to
the
past
three
versions
and
as
part
of
this
change,
we
are
running
an
internal
pilot
of
1510
that
is
going
to
enable
stage
teams
to
merge
into
the
stable
branches
while
release
managers
prepare
patch
releases
for
the
current
versions.
A
I
have
added
some
links
to
offer
some
guidance,
so
they
are
in
the
agenda
and
we
can
start
with
the
questions
now.
If
someone
can
take
notes
that
will
greatly
appreciate
that.
So
the
first
question
is
from
Tong
who
I
think
it's
a
bit
early
for
him
or
late
for
him.
So
Amy
can
I.
Ask
you
to
please
visualize
his
questions.
Thank.
A
Yeah
I
think
this
is
a
very
good
question.
First
of
all,
I
think
what
we
want
is
to
give
developers
some
sort
of
Early
Access
over
what
can
be
back
ported
and
in
what
versions,
and
this
is
what
we
mean
when
we
say
that
we
want
to
empower
stage
teams
in
this
iteration.
A
What
we
want
as
a
library
is
to
want,
is
for
developers
to
have
more
control
over
what
changes
can
be
included
in
a
patch
release,
because
we
delivery
team
are
not
like
in
the
best
position
to
decide
what
should
be
backboarded
and
in
what
versions.
Stage.
Teams
are
better
positioned
for
this,
because
the
stage
teams
are
more
knowledgeable
about.
Their
features
are
more
knowledgeable
about
the
Box
fixes
that
needs
to
be
back
ported
and
in
what
version
should
be
back.
A
C
B
A
I
think
it
was
covered,
but
if
not
thank
you
please
let
us
know,
and
we
can
continue.
I
think.
B
But
I'm
also
curious,
just
also
make
a
little
mention
like,
because
I
think
that
one
thing
we
will
still
have
is
going
to
be
the
back
ports,
exceptions
policy,
so
that
will
still
exist
to
catch
everything.
That's
outside
of
any
of
the
maintenance
policy,
extensions
that
will
continue
to
be
based
on
severity.
B
A
Awesome,
thank
you.
Amy
I'm
also
kind
of
curious
about
what
are
the
what
other
people
think
about
this
change.
I
see
that
we
have
some
back-end
Engineers
here
in
the
call,
and
also
it
seems
that
we
also
have
some
people
from
product
or
other
people
in
in
the
sales
side.
I
don't
know
if
they
want
to
add
something
about
this.
B
B
Is
also
not
on
the
coast,
so
let
me
just
verbalize
through
this
question
as
well,
which
is
around
the
the
fact
that
I
guess
like
whether
things
are
going
to
be.
In
fact,
maybe
we
didn't
answer
that
did
we
answer
the
question
of
when
there
is
a
bug
fix?
Is
there
an
expectation
that
this
will
always
go
into
all
three
versions,
or
is
it
just
going
to
go
into
the
one
that,
like
a
Stage
Group
chooses?
How
does
that
get
decided?
B
This
is
the
follow-up
which
is
like.
Is
there
a
judgment
call
involved
here
like
who
gets
to
make
the
decision.
A
Yeah
for
sure
it
is
also
a
great
question.
I
think
this
is
kind
of
a
business
question
and
it
is
a
product
of
organization,
the
site
decision.
It
should
be
made
based
on
the
a
combination
of
the
engineering
manager,
the
product
manager
and
the
stage
team
to
decide
what
should
be
backwarded
and
in
what
version
we
are
given
the
ability
for
stage
teams
to
do
it
in
the
three
pass
versions,
and
then
the
stage
teams
can
take
the
decision
of
what
is
the.
What
a
bug
fixes
should
be
back
ported.
A
C
E
Of
all
of
this
that
that
we
never
had
before,
which
is
now
even
The,
Wider
Community-
can
contribute
back
porting
fixes.
So
this
is
something
that
we
didn't
had
so
far
right,
because
we
had
those
things
about
labels
and
we
were
always
running
a
single
patch
release
for
the
current
Milestone.
But
now,
if
you
are
a
customer
that
you're
running
two
versions
behind
and
you
deeply
care
about
a
specific
bug
that
is
already
fixed,
nothing
prevents
you
to
create
the
backboard
assigned
to
a
maintainer.
B
Sure,
so
let
me
verbalize
Drew's
question
number
two,
because
I
don't
think
we'll
check.
Maybe
it's
still
not
cool,
which
is.
Did
we
get
customer
feedback
that
led
to
this?
It
seems
like
a
better
new
bug.
Experience
of
stuff
managed
users
that
won't
have
to
upgrade
did
anything
specifically
to
the
change
of
back
Port
policy.
Like
setting
aside
all
the
delivery,
mechanics
so
I
have
an
answer
which
I've
added.
If
anyone
wants
us
jump
in
which
is
like
yes,
this,
like
has
been
a
long-running
discussion
around.
B
What
is
the
right
policy
to
have
to
meet
our
customer
needs?
Basically,
so
I've
Linked
In
the
issue
which
it's
fairly
old,
but
has
quite
a
lot
of
interesting
Nuance
around.
What
is
the
right
level
like?
What
requests
have
we
had
for
extending
it,
and
it
also
includes
the
the
actual
decision
to
make
this
extension.
B
So
I
know
there's
sort
of
two
parts
to
this
change
we
are
making
and
the
first
one
coming
up
is
actually
a
process
change,
mostly
I
guess
affecting
developers.
But
could
you
just
give
us
a
bit
of
an
overview
of
actually
what
this
new
developer
process
is
going
to
look
like.
A
Yep
for
sure,
thanks
so
I
pasted
some
links
about
what
I'm
going
to
say.
So
it
is
there,
but
basically
before
or
the
current
process
that
we
have
so
far
is
that
if
someone
wants
to
backboard
something,
they
need
to
add
this
handy
label
about
Peak
into
and
the
version
and
then
release
managers
when
there
is
a
time
they
kind
of
collect
this
merch
requests
and
then
prepare
the
whole
process
of
doing
a
batch
release
now,
starting
with
15-10.
A
What
we
want
is
to
move
some
of
that
responsibilities
to
the
stage
teams
as
a
way
they
can
self-serve
and
what
they
can
do
is
that
if
they
want
to
passport
a
bug
fix,
they
are
going
to
open
up
a
merch
request
into
a
stable
branch.
They
need
to
use
a
stable,
Branch
template.
A
Basically,
in
this
template,
we
have
some
checklists
that
we
need
to
validate.
The
bug.
Fix
has
been
deployed
to
gitlab.com.
That
is
actually
a
bug
fix
that
it
is
not
a
feature
per
the
maintenance
policy.
We
cannot
backward
features
and
also
one
important
side
effect,
or
one
important
thing
to
mention
is
that
we
have
the
package
and
test
pipeline,
which
is
a
differentiator
from
all
the
merge
requests
in
github.com.
A
So
we
need
to
make
sure
that
the
backend
package
and
test
finishes
and
if
it
fails
quality,
Engineers
review
the
failures
because
executing
the
package
and
test
is
a
way
for
us
to
actually
guarantee
that
the
code
changes
are
compatible
from
the
quality
side.
A
C
And
even
to
build
on
that,
maybe
where
previously
we
might
have
taken
a
stance
on
right,
we
can
get
that
back
part
into
the
previous
version,
but
beyond
that
we
may
have
to
reject,
because
there's
not
kind
of
the
time
in
the
day
to
do
that,
giving
that
ability
back
to
the
stage
teams
to
be
able
to
own
those
backboards
decide
where
you
know
those
bug
fixes
are
feasible
to
introduce
I.
Think
that's
gonna!
C
E
Yeah,
there's
also
another
important
benefit
of
this,
which
is
in
the
current
process
the
one
we
are
running
today.
Everything
gets
picked
and
prepared
to
merge
at
the
time
of
the
release,
so
people
experiencing
the
this
this
process,
they
may
have
received
things
from
the
bot
saying
we
are
going
to
release
a
package,
we're
going
to
do
this
in
a
couple
of
hours
and
your
contribution
doesn't
apply
so
please
fix
it
now,
which
is
kind
of
impossible
right.
So
you
end
up
rushing
running
against
time,
while
here
everything
happens
before
right.
E
So
when
you,
as
a
stage
team
developer,
prepare
this,
you
have
the
control
and
to
hand
over
the
pipeline,
the
validation.
You
know
that
it
applies.
That
does
what
is
expected
and
once
its
merge
is
there,
so
it
will
be
included
in
the
next
package
and
we
are
also
working
I
mean
we
back
ported
one
of
the
part
this
morning
we're
also
working
on
the
release-
environments,
which
are
an
interesting
new
change,
is
related
to
this,
but
it's
not
part
of
the
extension
per
se.
E
What
we
are
doing
that
we
are
built,
we
are
creating
three
long-running
environments.
One
for
each
supported,
stable
branches,
so
that
when
you
backpot
your
fixes,
even
before
the
package
is
ready
for
releasing,
you
will
have
it
live
on
an
environment,
so
you
can
actually
go
there
validate
and
do
a
check
that
is
actually
working
as
expected.
So
we
never
had
this
before.
So
these
are
all
good
Improvement.
A
Yeah,
that
is
going
to
be
super
handy
awesome,
so
Drew
I
see
that
you
are
now
on
the
call.
I,
don't
wanna
point
fingers
at
you,
but
we
have
answered
your
questions.
So
can
you
just.
B
F
A
Just
to
confirm
that
we
have
answered
your
questions
and
you
take
a
look
at
the
notes.
They
are
there
and
just
please
let
us
know
if
that
is
enough.
F
Yeah
yeah
I
know
I
did
and
it
makes
sense
to
me
especially
I
mean
in
a
you
know.
This
seems
like
it's
still
kind
of
you
know
it's
a
pilot
phase,
it's
kind
of
open
to
feedback.
If
the
PM
and
the
em
and
the
team
are
having
trouble
making
a
decision,
then
there'll
be
some
process
feedback
for
sure,
and
we
can
worry
about
it.
Then.
B
In
many
ways,
true,
this
is
similar
to
the
existing
Blackpool
extension
request,
because
what
happens
on
that
is
when
we
find
a
bug
and
there's
kind
of
a
severity
agreed,
it
goes
back
to
the
product
manager,
who
presumably
then
discusses
with
the
stage
groups
to
actually
decide
like
how
significant
is
this
right.
I
think
this
is
going
to
be
a
pretty
much
the
same
conversation
of
how
significant
like
like
how
much
effort
we
want
to
put
into
fixing
it
like
for
for
the
different
versions.
F
Right,
which
and
I
mean
to
the
point
that
Osco
was
just
making
that
conversation
should
hopefully
be
a
lot
easier
when
we're
not
doing
it
like
everybody
at
once.
Four.
B
Myra,
could
you
just
give
us
a
little
overview
on
like
kind
of
like
dates
and
what
we
can
expect,
because
I
know
this
we're
moving
into
like
the
internal
roll-up
phase
like
what?
What
is
the
sort
of
rough
timeline
look
like.
A
Yeah
thanks
for
that
question,
so
we
are
entering
on
the
internet
pilot
on
15.10,
so
we
are
going
to
run
this
internet
pilot
along
15.10
and
then
on
15
11.
We
are
going
to
assess
the
results
and
see
what
does
it
look
like
the
fit?
What
we
have
received,
everything
all
the
metrics
that
we
have
and
then,
if
everything
goes
right,
we
hope
to
sort
of
extend
the
maintenance
policy
on
16.
But
this
is
like
what
we
are
targeting.
We
are
not
committed
yet
to
that
date.
D
A
Yes,
good
call
out:
it
is,
after
the
1510
published
date
during
the
1511
release
cycle.
So
yes,
this
will
get
confusing,
but
yeah
starting
on
March
22nd.
Once
1510
is
a
release.
We
are
going
to
open
up
the
stable
Branch.
We
are
going
to
run
the
pilot
and
then
continue
reassessing
how
the
effectivity
of
this
process
along
1511
and
decide
if
the
maintenance
policy
could
be
extended
of
16.
A
G
Just
because
I'd
seen
Vladimir
had
dropped
their
question,
but
I
wanted
to
try
to
make
sure
you
got
through
your
piece
of
your
AMA
before
doing
it,
but
it
was
the
like
if
your
agenda
was
not
too
busy,
I
thought
I'd
come
in
and
just
ask
and
make
sure
I
clarify
we're
all
here
and
I'd
seen
the
discussion
so
I
just
wanted
to
make
sure
I
gave
context
on,
like
the
whole
Loki
Tempo
POC
that
we're
doing
we
were
adding
it
because
it
was
one
day
to
add
on
a
small
deployment
of
those
two
that
would
help
us
debug
things
with
Thanos
and
I
saw
interest
derived
from
that.
G
G
I
wanted
to
make
sure
it
was
shared
that
I
hadn't
had
a
point,
a
chance
to
add
to
the
issue
and
I
was
going
to
add
to
the
issue,
but
then
I
realized
the
same
was
going
on.
I'm
like
well
just
come
and
see
it
too
so
is,
is
Vladimir
the
right
person
to
work
with
Michaela
or
should
I
also
work
with
you.
G
It
was
just
one
of
those
like
how
do
we
help
you
POC
I
just
want
to
make
sure,
because
if
it
sounds
useful
to
you,
I
want
to
enable
you
to
do
it.
I
just
wanted
to
make
sure
it
was
a.
This
could
be
taken
away.
If
we
decide
it's,
not
the
right
direction
or
told
like
we
need
a
dog
food
Jaeger
or
something
weird
like
that.
So
yeah.
H
We'll
try
the
same
question
there.
So
in
general
I
asked
this
question
because
if
he
sung
it
was
something
already
in
place.
We
put
a
look
into
that
I,
don't
think
we
can
make
it
actually
in
this
quarter,
because
we
would
actually
played
that
role
in
one
of
our
okrs
to
understand
a
bit.
Better
I
will
link
together
traces,
metrics
and
logs,
so
we
don't
want
to
be
like
kind
of
the
guinea
pigs
for
that
and
just
that
do
all
the
learnings
or
just
have
it
for
us
only.
H
We
only
we
already
have
another
path
how
to
achieve
what
we
want
to
achieve
there,
but
on
the
longest
term,
having
a
very
good
correlation
between
metrics,
logs
and
traces.
In
the
case,
when
we
spot
something
will
be
like
a
very
good
state
where
we
want
to
be,
and
it's
going
to
help
us
a
lot
in
identifying
the
various
you
know,
problems
we
have
in
Pipelines.
So
what
is
not
something
that
is
urgent,
but
was
it's
good
to
know
your
contest?
You
just
provided
now?
G
I
guess
I
just
meant
like
do
you
know,
there's
been
no
Readiness
review,
we're
not
investing
in
it
in
a
flavor
of
like
this
is
going
to
be
fully
highly
available
and
all
those
things.
So
if
you
wanted
to
POC
things
like
it's
probably
safe
to
do
that,
but
I
wouldn't
want
to
rely
on
it
for
the
solution
yet
give
us
a
quarter.
I
think
that's
the
whole,
like
observability
team,
just
formed
we're
just
getting
directions
so
I,
don't
know
that
this
is
the
decided
on
Direction.
Yet
so
I
just
wanted.
G
Okay
I'll
comment
that
on
the
issue,
but
at
least
as
I
can
at
least
come
in
and
say
that.
Thank
you
have
the
context.
D
G
G
G
Quiet
being
Nick
so,
but
at
the
same
time
like
if
you
do
at
least
want
to
do
that,
POC
reach
out
to
one
of
them
and
I
think
we'd
be
happy
to
at
least
try
to
wire
things
up.
So
you
can
see
what
it
looks
like.
That's
that's
where
we
were
with.
G
E
A
Awesome
thanks.
We
don't
have
more
questions
on
the
agenda,
but
does
anyone
wants
to
verbalize
a
question
regarding
the
maintenance
policy
or
delivery
subjects
deployments
and
releases.
A
Okay,
I'm
gonna,
take
that
as
I
know
so
well,
thank
you
everyone
for
coming.
If
you
still
have
any
questions
about
the
maintenance
policy,
please
refer
to
the
engineering
announcement
issue
or
post
questions
on
the
delivery,
slack
Channel
or
the
releases
slab
Channel
well
yeah.
Thank
you
and
I
will
see
you
next
time.