►
From YouTube: Discussing Delivery-metrics implementation
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
I
think
you
are
seeing
my
screen
now
yep
I
I
am
so
we
have
the
delivery
release
management,
dashboard,
I
know
it
is
not
your
favorite
dashboard
and
I
understand
that,
but
it
is
what
we
have
so
we
have
kind
of
to
iterate
on
it
now
sure
for
the
release
pressure.
We
have
this
information
first,
like
the
the
current
milestones
and
I'm,
not
sure
if
you
use
this,
but
I
don't
really
use
this,
because
it
doesn't
tell
me
a
lot
of
things
right.
It
is
telling
me
that
we
have
some
pressure.
A
B
A
So
I
prepare
a
simple
sketch.
Please
be
amazed
about
mine,
okay,
Excel
skills,
yep
yep.
B
A
Want
to
I
thought
I
thought
about
having
another
one,
but
I
don't
want
to
have
like
too
many
dashboards,
I'm,
not
sure
I'm
not
really
sure
about
what
would
be
the
easiest
solution
for
a
for
a
person
to
have
like
two
or
three
dashboards
open
or
just
that
one,
because
but
honestly
I
think
it
can
be
a
decision
that
can
be
taken
later.
I,
don't
see,
yeah
I.
B
Care
we
don't
care
about
that
one!
We
don't
do
you.
Do
you
ever
look
at
this
I
mean
we
decided
that
century
is
no
longer
a
release,
manager
concern
as
a
development
one.
So
just
thinking
my
own
view
here
that
if
we
remove
the
Sentry
Sentry
information
is
not
actionable
to
us,
we
don't
use
it
so
removing
that
we
just
removed
the
complexity
of.
As
you
would
say,
this
is
not
my
favorite
dashboard.
This
is
one
of
the
reasons
but
yeah
just
it's
just
an
data
point
right.
So
we
are.
A
A
This
is
trying
to
mirror
the
the
dashboard
that
we
that
we
just
saw
and
basically
what
I
want
to
know
as
a
release
manager
to
start
a
patch
release
is
okay,
if
I
have
s1s
or
S2s,
and
probably
if
I
have
like
the
number
of
merchants
merged
into
the
stable
branches,
and
for
that
I
basically
create
two
statistics
or
two
numbers.
A
The
first
one
is
will
be
like
the
total
of
S1
and
S2
merge
request
merging
to
stable
branches,
whether
this
is
like
git
love,
Omnibus,
Italy
or
CNG,
or
any
project
that
participates
into
manage
versioning.
So
this
is
actually
telling
like
there
is
something
there
that
like
we
need
to
act
on
it,
and
this
one
is
basically
informative
right.
This
is
the
number
of
merch
request
merge
into
stable
branches,
regardless
of
the
priority.
So
just
to
have
these
two
numbers.
A
Okay,
and
so
we
have
that
information
and
I
would
like
to
see
also
as
a
release
manager,
a
breakdown
now
We
have
basically
three
variables
I
think
we
have
the
versions,
We
have
the
number
of
merch
requests
and
the
severities,
so
I
was
trying
to
play
with
it.
And
how
can
we
show
that
information?
And
the
first
thing
is
that
okay,
basically
you
we
can
have
the
number
of
s1s
and
S2
per
version
and
then
a
breakdown
per
project
and
perversion.
A
B
A
Okay,
yes,
so
in
this
case,
for
example,
we
have
four
S,
one
and
S2,
and
in
this
case
we
can
say
okay,
we
have
2
for
15.5,
one
for
15.4
and
three
four,
five
one
for
15.3.
So
that
makes
a
total
of
four
and
on
this
merge
shock
on
this
other
table,
we
can
see
that
we
have
like
one
on
gitla
for
each
version
and
another
one
on
Optimus.
This
actually
should
be
read
so
yeah
and
then
the
other
one.
We
don't
really
have
anything
and.
C
A
This
side
yeah,
it
is
the
same
story
for
merch
request
for
each
version.
B
Okay,
so
I
was
thinking
that
maybe
big-
maybe
here
so,
can
you
can
you
go
to
the
dashboard
instead,
the
first
step
in
your
browser.
Thank
you.
C
B
B
So
S4
means,
as
for
show
me
numbers
for
everything
as
far
as
3s1
as
all
the
numbers
from
has
from
one
to
four
three
means
up
to
three
two
minutes
up
to
two
one
means
only
one
I,
don't
know
if
it's
doable
I'm
not
familiar
enough
with
this,
but
this
could
be
an
option
to
take
a
look
at
right,
because
all
those
queries
are
filterable.
B
So
probably
this
could
simplify
a
lot.
The
interface,
if
not
I,
agree
with
your
thing.
Also,
there's
nothing
to
take
into
consideration
is
the
each
one
of
those
things
is
making
queries
to
tanos
yeah.
So
this
is
extra
queries
everywhere.
So
if
that
thing
could
help,
and
basically
we
are
cutting
in
half
the
number
of
queries
and
we
can
go
by
having
a
default
on
S1
S2,
which
is
the
most
valuable
information
so
that
when
you
open
up
the
page,
it
just
shows
you
S1
S2,
and
then
you
can.
A
No
worries
so
yeah
I
mean
something
to
investigate
if
it
is
doable.
Also,
I
am
not
very
knowledgeable
about
the
things
that
we
can
do
in
a
dashboard.
I
was
trying
to
play
it
with
yesterday,
but
there
are
so
many
brackets
and
parentheses
that
I
was
like
okay,
now
I'm
wasting
too
much
time
so
yeah,
okay,.
B
Also,
this
thing
that
if
you
start
doing
manually
with
just
cloning
one
and
then
changing
or
creating
a
new
one,
and
then
you
say:
okay,
you
think
that
you
understand,
but
then
you
have
to
do
the
jsonnet
version
of
it,
which
is
kind
of
completely
different
right,
because
then
it's
all
declarative.
You
write
the
functions.
You've
read
the
the
script
that
generates
this
and
often
times.
Yeah
I've
done
this
in
the
UI.
B
A
So
I
like
your
idea
about
drop
down,
but
I'm,
not
sure
if
it
is
doable
and
I
really
want
to
do
like
what
is
the
most
simple
version
of
all
of
it.
A
So
I
was
thinking
since
I
did
this
yesterday
and
yesterday,
I
was
a
bit
over
one
with
all
the
information
that
I
was
analyzing,
so
I'm
thinking
that
this
might
be
a
bit
too
complex
because
well,
we
have
like
this
information,
so
I
guess
if
we
have
something
that
is
better
than
this,
it
will
be
like
a
good
first
iteration.
So
I
was
thinking
of
Simply
Having.
This
like
this
metric
and
then
just
having
these
two.
B
A
Yeah
yeah
I
was
thinking
of
having,
for
example,
this
one,
the
main
one,
and
probably
these
two.
So
we
can
have
a
better
perspective
and
then
another
follow-up
would
be
like
to
filter
for
severity,
and
another
follow-up
could
be
to
break
it
down
per
project,
so
we
could
have
more
yeah
yeah.
So
pick
us
up
more
information.
B
We
can
always
link
that's
an
option
right
because
it's
going
to
be
easier,
you
can
always
add
the
text
note
or
things
like
that
to
the
to
the
dashboard,
because
you
can
add
written
information
and
linking
to
let's
say,
Thanos
query
that
gives
you
the
breakdown.
C
A
Interesting
yeah
for
sure,
okay,
awesome
great,
so
I'm
going
to
open
up
an
issue
with
this
proposal
and
just
being
the
team.
So
if
anyone
has
any
other
ideas
or
if
anyone
doesn't
really
like
it,
they
can
say
something
before
we
start
implementing
this.
A
So
I
was
taking
a
look
around
metrics.
Now
we
have
these
metrics
and
then
I
think
they
are
oh,
yes,
metrics
and
I
think
we
have
two
ways
of
sending
information.
A
Exactly
right,
so
this
one
is
like
the
current
one
or
the
new
one,
the
one
that
we
should
be
using
like
to
delivery,
metrics
yep
and
this
one
about
release
pressure,
that
is,
the
code,
is
kind
of
complex
I
was
trying
to
see
how
many
Loops
it
is
doing
and
try
to
picture
it
on
my
head,
but
it
took
me
a
while,
but
I
think
this
is
the
old
one.
Yes,
this
is
the
old
one,
okay,
and
for
us
to
push
the
information
to
to
delivery
metrics.
B
A
Okay,
so
on
the
new
one,
I
remember
when
back
when
we
were
dealing
in
the
deployment
SLO,
that
we
have
different
ways
to
send
the
information
I
think
we
have
like
an
increment.
That
is
basically
the
set
I
think
and
we
have
the
histogram.
A
Yeah
yeah
histograms,
but
I
was
kind
of
getting
confused
with
the
labels
that
we
should
use
as.
B
Okay,
the
bad
news
is
that
when
we
designed
delivery
metrics
in
order
to
prevent
the
explosion,
I
think
it's
the
label.
Cardinality
problem,
I
think
is.
B
Name
right,
so
we
made
a
decision
where,
when
you
define
metrics
in
delivery
metrics,
you
have
to
define
the
possible
value
that
that
label
the
number
of
labels
and
all
the
allowed
values
for
those
labels,
so
that
you
can't
push
unexpected
values.
So
that's
the
bad
news.
B
The
code
AS
is
cannot
accept
the
the
variable
versions,
because
we
have
the
milestones
and
the
Milestones
are
variable,
so
this
could
be
easily
fixed.
We
just
need
to
implement
an
extension
over
it
when
you
say
say
something
like
regex
match
or
something
like
this
right.
So
we
say
when
I
tell
you,
this
is
a
version
you
don't
match
by
the
string,
but
you
match
by
say
a
regular
expression
so
that
you
are
you're
still
doing
validation,
so
you're
just
expecting
in
this
case
is
always
going
to
be
major
dot
minor.
C
B
It's
still
so
it
can
still
fit
in
the
in
the
way
that
we
have
this
Loop.
That
is
checking
for
the
incoming
values
and
is
just
validating
all
the
input.
But
it's
not
there
yet
and
yeah
as
I
can.
How
can
I
say
if
you
want
to
move
forward?
You
can
just
enumerate
everything
from
current
Milestone
to
I.
Don't
know
16
dot,
something-
and
this
gives
you
several
months
of
headspace,
where
you
can
say:
okay,
I
have
many
Milestones.
That
I
will
just
be
pushed.
B
Accepted
from
the
system
so
that
we
can
split
the
problem
into
right,
so
someone
else
can
work
on
implementing
this
more
Dynamic
thing,
but.
B
There
is
the
good
news
which
is
I
was
looking
at.
If
you
remember,
we
had
the
conversation
about
how
do
we
keep
the
two
systems
together,
while
we
are
migrating
from
the
old
system
to
a
new
one
right?
So
there's
a
good
news
here
which
is
because
delivery
release
pressure
is
running
on
the
old
system.
B
We
can
basically
Implement
a
new
class.
That
is
just
counting
the
new
pressure
and
the
new
pressure
can
go
with
the
same
label
name.
The
near
pressure
can
go
on
delivery.
Metrics,
the
old
one
will
still
go
on
the
Gateway,
and
this
will
allow
us
to
distinguish
between
the
two,
because
there
is
a
label
that
is
applied
by
Prometheus
himself,
which
is
where
did
I
scrape
this
information
so.
B
C
B
I'm
going
tell
you
delivery.
This
is
the
auto
deploy
pressure,
so
this
is
another
metrics
that
is
state
is
stored
on
delivery,
metrics
and,
as
you
can
see
here,
the
job
here
is
delivery,
metrics,
okay,
so
everything
scraped
from
delivery
metrics
can
be
easily
identified
by
this
now
back
to
the
original
thing.
So
this
is
what
we
have
right
now
and
basically
just
very
what
we
care
about
this
is
so
the
values
that
are
interesting
to
us
are
severity.
B
B
B
C
C
B
All
makes
sense
right,
so
what
I'm
thinking
is
that
if
we
could
so
I'm
gonna
put
you
this
also
jump.
B
Okay,
so
basically,
what
we
can
do
here
is
that,
if
we're
going
to
implement
the
same
metric
with
version
that
has
this
yet
to
be
say
not
completely
implemented
feature
that
we
can
expand
the
number
of
labels,
that's
the
problem,
then
you
have
severity.
That
is
accept
those
values.
Here
we
can,
if
we
can
Define
them
up
front,
State
I
mean
I,
would
not
put
state
in
there,
because
in
in
the
new
in
the
new
world,
there's
only
one
state
which
is.
B
B
Okay,
yeah
and
latitude
process
run
together
right.
So
when
we
I
don't
know
how
we
do
the
publishing,
but
probably
we
can,
we
will
have
this
class
that
is
doing
something
and
is
pushing
the
value
and
we
can
actually
have
another
class
that
is
doing
the
same
thing
with
the
new
values.
So
you
run
one
and
the
next
one
in
the
same
job
right.
B
A
B
B
If
I'm,
if
I
go
and
pick
a
random
close,
merge
request,
so
it's
not
merge
it's
closed
or
an
open
one
and
add
the
label.
Will
this
show
up
here?
We
can
test
immediately
because
there
is
the
the
batch
is
is
working
later
on,
so
what
I'm
thinking
is?
Maybe
the
Ruby
code
that
you
were
looking
at
before
is
actually
doing
more
than
this
right.
So
it's
also
looking
for
those
extra
status
and
Publishing
those
extra
stuff.
A
B
C
A
Something
implementation
question,
but
if
we
push
like
yeah
I
think
it's
if
we
push
to
the
same
metric
with
the
same
name
and
with
different
labels,
that
is
not
going
to
interfere
with
the
information
that
we
have
right
now,.
B
C
B
Me
go
here,
that's
the
query
right.
So
this
is
what
we
have
right.
So,
let's
assume
for
a
moment
that
instead,
so
we
are
gonna
have
jobs
right.
So
basically,
what
happens
here
is
that
if
we
had
gonna
do
this
job
as
well,
then
those.
C
A
A
B
We
are
gonna
say
we
don't
care
about
job,
give
some
everything
that
has
the
same
state
inversion.
They
will
just.
It
will
just
give
you
a
number,
and
the
number
will
be
correct
in
the
sense
that
if
it's
merged
is
not
peaked
and
when
we
pick
so
the
current
process,
we
remove
the
label,
so
they
are
counting
two
different
things.
B
That's
the
that's
the
keyboard
right,
so
the
number
are.
Actually
you
are
supposed
to
count
both
of
them
to
get
the
proper
representation
of
this
thing
right,
because
I'm
yeah
I
mean
it
will
help
us
to
see
things
and
see
how
maybe
easily
or
those
other
projects
are
already
behaving.
And
then,
when
we
switch
to
the
new
system,
they
would
just
the
the
danger
boat,
probably
or
something
else.
We
just
tell
people
hey.
B
A
Yeah
but
I
wonder
that
if,
for
the
entering
period
in
which
we
are
still
implementing
this
I
suppose
we
will
need
to
modify
the
current
query
for
the
delivery
release,
pressure
to
exclude
the
jobs
or
the
information
that
we
are
going
to
push.
C
A
B
Yeah
and
if
someone
is
already
starting
testing
the
new
workflow
for
any
reason,
maybe
it's
us
that
we
are
just
working
closely
with
someone
say:
we're
going
to
do
a
patch
release.
Do
you
mind
just
for
your
own
thing
doing
this,
and
this
will
just
give
us
the
right
numbers
and,
for
instance,
will
give
us
correct
numbers
for
Italy,
because,
as
we
have
seen
easily
is,
as
we
told
them
to
do,
we
always
told
them
to
do
if
you
want
something
to
be
released.
B
Merge
it
on
your
stable
branches
and
next
time
we
run
a
patch
release.
It
will
be
Tagged,
so
we'll
we'll
give
us
a
more
accurate
reading
of
the
pressure,
because,
right
now
we
are,
we
can't
see
Italy.
B
The
only
thing
we
need
to
take
care
of
is
when
we
decommission
this
one,
so
we
remove
the
old
system
to
clear
the
value
to
delete
the
value
on
on
the
old
system.
Otherwise
they
will
still
be
there
counting
right.
So
either
we
filter
out
by
then
heading
job,
delivery,
Medics
or
I.
Think
it's
going
to
be
easier
to
just
delete
them,
because
I
think
it's
already
implemented
there,
because
I
think
it's
deleting
the
old
one
and
it's
adding
the
new
ones.
A
And
another
small
question
so
for
us
to
push
into
the
delivery
metrics
I
remember
that
we
need
to
do
like
basically
a
ruby
class.
We
already
have
like
the
interface
and
that's
it,
although
we
also
need
to
do
something
in
go.
You.
B
B
So
take
a
look
at
this
as
an
example
right.
So
this
is
the
absolute
deploy
pressure.
Okay,
so
the
delivery
is
the
system.
How
to
deploy
is
the
subsystem
in
this
case
is
going
to
be
release
and
then
basically
here
is
the
definition
of
the
metrics
right.
So
this
is
going
to
be
gauchevec
as
well,
because
it
can
go
up
and
down,
and
that's
the
thing
right,
so
this
is
going
to
be
pressure
as
well.
This
is
this
is
going
to
be
obviously
changes
as
to
release
description.
C
B
B
B
Okay,
but
I
mean
this
is
Will
unblock
you,
because
this
I
mean
I
can
help
you
here
as
well
right
just
this.
This
is
very
it's
a
very
easy
change.
You
can
make
this
in
the
same,
merge
request
of
the
Ruby
one.
If
you
want-
and
maybe
you
do
a
feature
flag
on
the
Ruby
side
to
start
publishing
only
when
we
have
this
deployed
or
you
can
do
the
the
Ruby
the
go
link
first
and
then
check
for
the
other
one,
but
that's
it
I
mean
it's.
B
Basically,
you
cut
and
paste
this
and
change
this
with
the
other
one
and
create
the
appropriate
label.
You
can
put
many
of
this,
so
you
can
be
I
mean
you
can
see
here.
Where
is
it
how
to
have
a
multi-label
somewhere.
B
Than
one
and
it
will
just
work
and
the
other
things
that
you
need-
because
you
are
introducing
a
new
package-
is
something
like
this
right.
This
is
the
initialization
class.
Basically,
this
is
calling
each
one
of
those
function
down
there
and
it's
one
by
subsystem.
So
basically,
you're
gonna
do
something
like
this
cadm
based
and
you're,
going
to
be
air
equal
in
it
release
metrics.
C
B
Thing
right
so
I
mean
you
can
assign
I
can
help
you
reviewing
this.
Yes
for
sure,
if
you
want,
if
you
don't
want
to
do
this
yourself,
I
can
do
this
for
you,
as
you
prefer
right.
So
this
is.
This
could
be
quite
easy,
so
maybe
it's
worth
for
you
to
just
give
it
a
shot
and
see
if
it
works
just
to
get
a
bit
more
confidence
and
also
suggesting
you
very
important,
there's
it
here.
Just
let
me
check
yeah
this
one.
B
C
B
Is
the
definition
of
all
the
tests-
and
this
is
the
code
that
is
running
the
test,
so
you
can
imagine
having
something
like
an
extra
element
here,
which
is
saying:
release
pressure,
a
list
of
labels
that
you
want
to
test
a
value,
and
then
you
have
to
provide
the
the
expanded
metric,
because
this
is
testing
the
internal.
So
it's
actually
starting
a
web
interface
running
the
system,
sending
them
the
request.
B
Downloading
the
metrics
and
and
checking
the
the
value
and
metrics
are
exposed
with
the
with
the
exploded
labels.
Okay.
So
this
is
just
an
easier
way
to
to
to
tell
what
to
look
into
them
into
the
metrics.
So
you
can
make
something
like
this
very
simple
you
can
see
here.
You
have
a
multi-label
version
right,
so.
B
A
A
Okay,
awesome
well,
yeah
I
think
I
have
enough
to
continue.
So.
Thank
you
so
much
for
your
time.
I'll!
Let
you
as
usual
and
you're,
welcome.