►
From YouTube: 2022-10-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
B
Yes,
thanks
for
having
me,
this
question
has
to
do
with
the
Dora
metrics
that
are
baked
into
git
Labs
gitlab
project
on
gitlab.com.
It's
always
great
to
be
able
to
show
customers
how
we
build
gitlab
on
gitlab.com
as
gitlab
the
organization
and
the
door.
Metrics
are
usually
pretty
good
the
time
to
restore
service.
One
specifically
doesn't
look
all
that
great
and
my
primary
question
is:
are
there
any
plans
to
incorporate
how
time
to
restore
Services
calculated
into
the
actual
deployment
process?
B
So
that
way,
when
we
do
rollbacks
or,
however,
that's
calculated,
we
would
then
be
able
to
show
that
number
and
it
look
a
little
bit
better
for
our
customers.
C
Okay,
so
great
question
Tim,
so
thanks
for
asking
I
would
like
to
give
some
highlights
on
why
some
of
the
values
are
there.
Some
are
not.
Authors
are
not
looking
great.
The
basic
reason
is
that
all
those
metrics
are
designed
around
a
a
single
repository,
but
we
don't
deploy
by
repo
and
we
don't
deploy
from
github.com.
C
So
that's
the
big
barrier
that
we
have
when
we
are
looking
at
those
values.
So
what
we
are
doing
so
I'm
explaining
what
we
are
doing,
because
maybe
this
can
get
start
a
conversation
about
how
can
we
make
sure
that
those
value
then
gets
calculated?
So
what
we
are
doing
is
that
we
deploy
from
our
oops
instance-
and
we
have
let's
say
a
single
pipeline
that
deploys
everything
right.
C
So
then,
at
the
end
of
this
pipeline,
I
mean
at
the
end
of
every
stage
deployment
we
go
in
and
with
the
API
calls
we
Mark
the
deployment
on
every
project
on
github.com.
So
this
is
what
we
are
doing.
So
if
this
is
not
enough
to
populate
those
values,
then
we
need
to
figure
out
way
to
actually
have,
for
instance,
the.
C
What's
the
thing
you
were
time
time
to
restore
service
to
to
get
extracted
from
this
from
those
information,
because
we
do
run
rollback
right,
maybe
they
are
not
detected
as
ruled
back
by
by
the
API,
so
yeah.
B
Because
I
was
surprised
to
actually
see
that
deployment
frequency
worked
with
the
API
call.
Given
that
you
are,
you
know,
leveraging
the
API
to
declare
that
I
was
a
little
bit.
So
I
was
delighted,
and
do
you
do
you
feel
like
three
3.6
deployments
per
day
is
about
correct
yeah.
C
It
is
because
we
fixed
the
implementation,
so
we,
our
environment,
were
not
recognized
as
production
environment
because
of
the
name
we're
using.
So
we
we
contributed
the
the
way
to
change
the
type
of
environment
using
API
which
wasn't
part
of
the
product
and
those
value
are
correct.
We
look
at
them
weekly.
So
if
you
are
interested,
you
can
join
our
weekly
call
it's
Monday
afternoon
in
Mia
time
and
the
release
manager
did
do
a
walkthrough
of
the
metrics.
We
take
a
look
at
the
number
of
deployments.
We
take
a
look
mean
time.
C
B
But
the
time
to
restore
service,
one
specifically
looks
to
not
be
looking
at
the
right
data,
and
or
is
it
not
instrumented
correctly
for
our
environment.
C
B
And
so
I
guess
my
question
within
that
then,
because
time
to
restore
service.
B
I,
don't
know
how
exactly
it's
calculated,
I
guess:
I
was
trying
to
look
through
the
documentation,
but
to
date
we
haven't
looked
at
figuring
out
hey.
How
could
we
make
this
this
metric
actually
work
for
gitlab.
C
Yeah
I
was
also
looking
at
the
the
actual
graph.
Now
that
you
that
you
were
talking-
and
there
are
some
data
points
in
there-
that
I
have
no
idea
where
they're
coming
from
July
18,
July,
29,
August,
22,
September,
11.,
11th
and
September
21st,
no
idea
why
those
data
points
are
there
so
and
we
need
first
to
probably,
we
need
first
to
figure
out
how
we
calculate
the
metrics
and
then
try
to
figure
out.
If
we
can
feed
information
into
our
tracking
system
too
yeah
yeah.
B
It
does
seem
and
specifically
I,
believe
I'll
put
it
in
that
back.
B
But
this
this
page
specifically
here
in
if
you
and
you're,
referring
to
the
last
90
days,
not
last
30.,.
B
I'm
still
not
I
I,
the
definition
seems
to
not
make
sense
either
median
time.
An
incident
was
open
on
a
production
environment
in
the
given
time
period.
That
would
not
be
time
to
restore
service.
That
would
be.
B
A
B
A
To
discuss
with
the
team
in
charge
of
those
metrics
I
can
sync
with
you
offline
literacy
and
just
give
you
the
name,
the
team
name.
D
Thanks
yeah,
maybe
it's
a
misplaced
question.
I
think.
Maybe
the
distribution
group
is
the
one
who
owns
this
I'm,
not
sure,
but
do
you
know
if
the
gitlab
chart
is
released
together
with
gitlab.com
the
same
date,
the
same
cut
date
for
getting
commits
like
it's
the
same
automation
or
it
happens
like
a
few
days
after
and
which
date
would
that
be?
Anyone
has
an
idea.
C
I
can
try
so
I
usually
have
to
check
the
code
every
time
that
question
like
this
show
up,
because
it's
a
bit
tricky
if
I
remember
correctly,
what
happens
is
that
we
talk
the
charts
at
the
same
time
of
when
we
publish
the
packages,
that's
the
tricky
part,
so
most
of
our
softwares
and
components
in
general
get
tagged
in
advance.
C
So
we
attack
two
working
days
before
the
actual
release
and
those
are
either
if
it's
a
security
release
or
a
public
one,
they
are
some
they
are
not
published.
So
we
have
an
internal
repositories.
We
can
download
and
install,
but
they're
not
available
to
the
general
public
unless
they
build
themselves
the
same
thing,
then
there
is
a
point
in
time
when
a
release
manager
release
the
package
which
basically
moves
the
thing
to
a
public
place
at
that
point
in
time
there
are
extra
feature
that
goes
into
CNG,
so
the
charts
and
I
don't
remember.
C
There
should
be
another
project
as
well
and
and
create
the
release
there,
because
those
projects
do
not
support
this
in
between
State
between
being
tagged
but
not
released.
So
that
should
be
the
rough
timeline.
D
C
So
I
don't
know
if
that.
That's
that's
the
detail
that
I,
don't
remember,
I,
don't
know.
If
the
when
we
start
the
process,
we
are
still
say,
branching
off
the
main
branch,
and
so
it's
just
a
matter
of
when
the
tag
operation
happens,
but
the
content
is
the
same
or.
C
Is
actually
an
extra
Gap
in
time
where
you
can
say
add
some
new
feature
or
whatever
this
is.
This
is
definitely
more
a
distribution
question.
B
This
page
is
typically
what
I
I
see
my
customers
asking
about
of
like
hey
is:
is
this
updated
yet.
B
Usually
go
here
first
and
then
they
navigate
over.
But
it
like.
This
seems
like
a
simple
page
that
if
this
is
kind
of
the
the
starting
point
where
we
want
people
to
go
to
it'd,
be
nice
to
be
able
to
say
like
chart
name
and
then
the
status
not
just
GA,
but
also
like
what
version
has
been
released
for
the
gitlab
gitlab
agent
and
gitlab
Runner
foreign.
A
B
A
Well,
if,
if
not
thanks,
everybody
for
joining
the
call
and
also
feel
free
to
reach
out
to
us
in
the
G
delivery,
slack
Channel,
if
you
have
extra
questions
that
are
coming
up
to
your
mind
later
and
we'll,
we
will
do
our
best
to
answer
them
in
the
shortest
amount
of
time.
So
thank
everybody
for
joining
today,
AMA
and
I
speak
to
you
soon.