►
From YouTube: 2023-03-20 Delivery team weekly EMEA/AMER
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
I
think
well
we're
just
trying
to
find
the
agenda.
I've
got
too
many
tabs
cool,
so
welcome
everyone,
20th
March.
There
are
a
couple
of
things.
Any
announcements,
but
I
did
just
want
to
particularly
highlight
we
have
a
few
people
out
today,
and
so
please
do
make
sure
to
use
the
release
management
escalation
process
if
needed,
ahmad's
very,
very
kindly
stepped
in
helping
Vladimir
and
Steve
you'll
be
taking
on.
A
We
are
on
the
day
20th,
so
we
do
have
quite
a
few
release
management
tasks
to
make
sure
we
definitely
get
through
today.
We
want
to
make
sure
we
complete
those.
So
please
do
ask
early
if
you
need
any
help.
A
C
Yeah
sure
just
gonna
pmcl
doing
yeah,
so
Dove
is
doing
a
lot
of
stuff
around
release,
pipelines
and
pipeline
authoring
right.
They
have
I've,
sent
him
the
link
with
the
passcode.
That's
why?
Because
we
have
several
different
links
in
that
doc.
Don't
we.
C
Anyway,
because
pipeline
authoring
have
a
number
of
features
platened
for
kind
of
their
six
to
12
month,
roadmap,
including
what
they're
kind
of
billing
is
CI
components.
The
CI
components,
particularly.
C
Are
their
take
on
completely
reusable
components
that
you
can
plug
into
workflows
in
a
similar
way
to
what
we've
seen
coming
out
of
GitHub
actions
in
the
past
kind
of
12
to
18
months?
That
will
help
organizations.
Have
you
know
pre-configured
pipeline
pieces
that
you
can
just
slot
in
and
should
be.
You
know
ident
in
their
or
ident,
in
the
way
that
they
work
and
and
you're
able
to
use
them.
C
D
Just
a
little
bit
just
the
band
and
I
think
it's
it's.
What
will
basically
is
what
we
are
aiming.
We
still
have
a
long
way
until
we'll
get
there,
but
we
are
I.
Can
I
can
start
the
presentation,
but
basically
we
are
adding
incremental
value
in
every
in
every
release.
D
Do
some
show
some
examples,
but
I
really
want
to
make
sure
that
I'm
here
also
to
like
answer
any
questions
and
see
if
we
can
collaborate
further
on
this
on
this
project
and
basically
and
I,
want
to
show
you
what
we
are
planning
to
achieve
and
cicd
components.
Catalog.
It's
it's
a
solution,
but
as
we
get
into
that
solution,
eventually,
as
I
mentioned
in
every
release
in
every
iteration,
we'll
be
able
to
provide
meaningful
value
for
for
our
users
and
I
really
hope
that
many
teams
in
gitlab
will
be
able
to
start
adopting
this.
D
Those
capabilities,
those
set
of
capabilities
that
will
release
and
we
can
walk
closely
to
get
like
a
close,
closer
feedback
loop
and
we
can
Implement
features
that
you
would
like
us
to
like
internally
in
GitHub
that
you'd
like
us
to
implement.
Of
course,
we
are
going
to
release
it
to
all
of
our
customers,
who
will
get
also
feedback
from
there,
but
but
obviously
like
like
in
getting
internal
feedback,
is
much
more
quicker
than
reaching
out
to
customers.
D
Basically,
we'll
cover
the
background,
the
Spectrum
monetization,
what's
the
components
and
catalog
user
value
and
our
roadmap
so
basically
a
little
bit
about
maybe
the
problem,
and
we
know
already
we
identified
that
before
anyone
creates
any
pipeline,
it's
very
hard
to
understand
what
is
out
there.
What
is
what
is
there
out
there
for
them
to
use?
D
Then
they
find
themselves
either
going
to
go
to
Google
or
maybe
searching
something
within
the
organization
on
some
ripples,
but
overall
what
they
are
doing
is
they're
Reinventing
the
wheel
over
and
over
again
when
they
start
writing
a
pipeline.
Now
we
have
this
concept
of
CI
templates
that
obviously
everyone
is
using,
but
we
also,
we
also
acknowledge
that
templates
are
not
designed
with
designed
with
the
usability
in
mind.
D
Okay,
it's
like
a
scaffolding,
and
you
start
with
with
a
with
some
sort
of
a
starting
point
starting
point,
and
then
you
own
that
template
and
you
extend
it
and
you
add
like
hidden
job
and
you
extend
the
jobs
So.
Eventually,
a
lot
of
the
logic
will
actually
go
into
the
template,
and
eventually
the
template
will
go
bigger
and
bigger
and
bigger.
It's
not
a
bad
thing.
D
I
mean
the
templates
are
really
good,
but
I
think
we
are
at
the
place
when
we
are
saying
okay,
there
is
like
a
natural
Revolution
that
we
can
take
the
templates.
The
templates
are
not
going
away,
they
are
going
to
stay.
What
we
are
adding
is
capabilities
on
top
of
those
templates
that
eventually
will
move
them
to
something
that
we
like
to
call
as
CI
components,
and
so
just
briefly
about
the
goal.
D
The
goal
is
to
create
some
sort
of
a
framework,
some
sort
of
an
ecosystem
to
gitlab
that
will
allow
users
to
easily
share
code
with
other
and
to
collaborate
quickly.
Eventually,
we
want
to
make
sure
the
developers
focus
on
sort
of
innovation,
and
everything
that
is
related
to
configuring
pipeline
is
something
that
you
would
do
once
and
that's
it.
You
won't
need
to
to
redo
it
over
and
over
again
the
tattoo,
the
ultimate
the
ultimate
feature,
or
maybe
pattern
monetization,
but
actually
it's
like
the
Natural
Evolution,
as
I
mentioned.
D
The
way
I
said
is
we
have
now
templates
and
the
idea
is
that
more
and
more
users
will
start
converting
templates
into
a
component.
Okay
and
the
component
is
the
reusable
unit
of
pipeline
configuration
it's
very
similar
to
a
template,
but
we've
added,
as
I
mentioned
more
and
more
things
around
that.
So
there
is
also
some
sort
of
a
hybrid
approach.
You
see
you
see
that
even
without
the
component,
you
can
still
use
many
of
the
elements
that
we
Implement
into
a
component,
so
you
can
use
it
in
the
in
the
template.
D
D
We
are
not
settled
on
the
name,
but
basically
it
will
be
the
collection
of
all
the
projects.
The
scope
per
namespace
that
contain
component
basically
think
about
like
an
index
page
or
a
catalog.
That
will
will
provide
you
an
easy
way
to
search
to
filter
and
to
view
what
are
the
available
components.
What
are
the
instructions
and
how
to
use
it?
It's
like
some
sort
of
a
self-service
approach
and
to
consume
a
CI
company
thinking
about
GitHub
Marketplace,
but
for
organizations
think
about
Circle
cios,
but
for
organizations.
D
And
of
course,
if
you
have
any
questions
like
feel
free
to
stop
me
in
the
middle
and
ask
okay.
So
what's
a
component,
and
so
as
as
I
mentioned,
a
component
is
a
reusable
single
purpose,
building
block
and,
and
basically
it
will
be
a
part
of
your
of
your
pipeline
configuration
and
every
component
will
have
an
input
and
a
Content.
We
also
want
the
component
to
have
an
output
I
really
want
to
hold
on
I
want
to
exit
this
presentation.
D
So
I
can
show
you
some
examples
on
how
a
component
is
using.
So,
as
I
mentioned,
a
component
will
have
a
input
parameters.
Okay
and
those
are
all
the
options,
different
inputs
that
we'll
have
obviously
incrementally
we
won't
have
all
of
them
at
the
beginning.
But
let's,
let's
break
it
down
at
the
beginning
of
each
component,
users
will
specify
spec
input
and
then
they
will
specify
the
list
of
inputs
that
this
component
could
receive,
and
so
by
default,
all
inputs
that
we
are
declaring
are
mandatory.
D
If
you
give
them,
if
you
give
them
a
value,
some
sort
of
a
value,
then
they
become
an
optional,
an
optional
input
today,
by
the
way
any
I
guess
like
if
you're,
using
templates,
you're
using
variables-
and
there
is
a
there-
is
a
problem
with
variables,
because
variables
is
like
a
it's
a
global
keyword,
it
is
affecting
the
entire
pipeline,
so
it's
very
hard
to
to
make
sure
that
the
the
variable
will
only
be
part
of
the
of
the
template.
D
So
the
idea
with
inputs
is
that
inputs
are
only
related
to
or
only
attached
to
that
component.
So
whenever
you
declare
an
input,
it's
an
input
that
is
running
in
the
context
of
the
component,
only
for
the
only
folded
company
and
there
are
like
different
variations-
that
we
want
to
have
like
a
default.
One
required
a
required
input,
a
default
input,
multiple
options
and
more,
and
we
have
like
a
full
epic
where
we
are
saying.
D
Okay
in
this
iteration
We'll,
add
options,
then
maybe
regular
expression
input
start
data
input,
validation,
for
instance,
I
want
to
declare
an
input
that
will
be
like
a
Boolean,
a
string,
a
number.
So
we
can
definitely.
We
can
definitely
do
that,
and
then
we
have
the
content,
the
actual
content
that
the
content
is
is
similar
to
the
component.
D
So
you
declare
a
variable
and
then
you
use
that
variable
within
the
template.
But,
as
you
probably
know,
there
are
some
things
but
support
variable
expense
extension,
and
there
are
some
things
that
does
not
support
variable
extension
here
with
inputs,
everything
will
be
supported.
So,
ideally,
you
can.
Okay
can
replace
any
key
or
any
value
with
any
input
parameter
that
you
want,
and
then
you
can
use
it
when
you
call
that
component
similar
to
a
function
and
how
do
you?
How
do
you
so-
and
this
is
this-
is
how
this
is
like
an
example.
D
D
This
is
the
job
name,
and
then
there
is
a
script
and
there
is
another
job
name
and
there
is
a
script,
and
here
this
is
this
script.
For
instance,
this
field
has
been
replaced
by
the
input
that
will
be
used
here
and
we
can
use
it
with
rules
and
we
can
but
explicitly.
We
can
use
it
anywhere.
You
we
want
inside
that
that
component,
the
way
to
use
it
is
that
when
we
do
an
include,
we
do
an
include
of
the
component.
Okay-
and
this
is
like
the
first.
D
The
first
thing
is
that,
as
you
can
see,
we
we
will
support
Version
Control.
So
if
you
have
different
versions
of
the
same
component,
you
can
call
that
specific
version
of
the
component,
and
then
you
do
it
with
the
inputs
that
you
want
to
run
so
here.
This
is
where
you
will
feel
the
the
input
parameter
that
you
want
to
pass,
so
you
create
the
component
once
and
then
you
can
run
it
many
many
times
with
different
inputs,
different
types
of
of
inputs
and
let's
see
if
I,
was
more
examples.
D
E
A
D
A
Just
because
I
was
going
to
say
that
I
wonder
if,
with
this
time,
it
might
be
that
a
good,
a
nice
conversation
to
have
like
as
a
discussion
about,
do,
we
have
ideas
of
components
or
pipelines
we
can
use,
and
then,
if
we
can
think
of
those,
we
can
come
back
and
sort
of
watch
this.
How
we
would
apply
that
as
a
more
of
an
async.
D
Okay,
I
just
wanna
I,
just
wanna
I,
just
want
to
explain
like
what
you
know
what
I'll
I'll
go
over
the
the
release,
because
I
wanted
to
explain
the
entire
the
entire
roadmap
and
then
I
want
to
go
over
the
release
plan
that
we
have
in
this
plan
and
just
to
explain
why
I
think
this
is
something
that
users
would
all.
Not
only
users
like
many
teams
in
gitlab
could
start
dog
folding
it.
As
we
mentioned
as
I
mentioned.
We
are.
D
We
are
talking
about
moving
into
component,
but
before
we
will
use
the
component,
we
want
to
allow
anyone,
basically,
that
is
using
today
deadlab
and
using
templates
to
specify
so
the
first
iteration.
We
are
going
to
ask
users,
because
we
kind
of
understand
that,
like
now
asking
everyone
that
is
using
templates,
convert
your
templates
to
components.
Okay.
This
is
not
a
fair
ask
because,
okay,
what's
what's
in
it,
for
me
like
what?
What
is
the
benefit
and
I
think
the
the
first?
D
The
first
phase
is:
we
want
to
allow
any
includable
file
to
use
an
input?
Okay,
so
it
doesn't
matter
if
you're
using
you
don't
need
to
use
components
in
order
to
specify
input.
So
it's
the
spec
input
that
I,
just
that
I
just
showed,
will
work
today
with
templates.
Okay,
because
the
idea
is
that,
as
you
move
from
templates
to
components,
we
want
to
give
you
like
a
an
easy
Bridge,
an
easy
way
to
migrate
and
I.
Think
that
the
first
I
would
like
to
ask
everyone.
D
Basically,
if
you're,
using
templates
and
I,
assume
that
you
are
using
templates
and
you
are,
if
you
are
passing
them,
if
you
are
passing
parameters
to
a
templates
using
variables
now
think
about,
instead
of
doing
that,
declaring
input
at
the
beginning
of
a
template
and
then
use
the
template
with
with
those
inputs.
So
basically,
basically,
what
I
would
ask
from
from
what
I'm
asking
for
everything?
Okay
is
to
do
exactly
that.
Look
at
your
templates.
D
They
ask,
is
not
to
convert
it
into
a
component,
just
the
templates
that
you
are
using
that
you're
using
it
with
with
variables,
try
to
think
about
okay.
How
can
you
use
now
inputs
instead?
Okay-
and
this
is
what
we
want-
a
like
other
teams
in
gitlab
to
tutor-
is
it
like
something
that
resonates
within
that
team,
something
that
you
think.
F
We
use
some
of
the
basic
templates
like
around
security
skating
and
such
we're,
using
a
lot
of
yamo
anchors
and
such
like
some
of
the
awkward
features
of
building
a
yaml
configuration
for
CI
and
a
wide
array
of
places
where
templates
are
probably
more
suitable.
We
just
never
explored,
or
you
know,
move
that
direction.
Part
of
that
being
that
we
leverage
jsonnet
to
build
some
of
our
pipelines,
not
all
of
them,
obviously
and
Json.
It
kind
of
abstracts.
Some
of
that
away
for
us
preventing
the
need
for
us
to
leverage
templates
to
some
extent.
F
I
know
I'm
stretching
the
definition
of
all
that
a
little
bit
but
like
like
our
deploy.
Deployer
for
is
one
key
example
where
everything
is
pretty
much
the
same
for
every
stage
in
every
environment,
except
for
the
name,
production
or
except
for
the
name
staging,
but
the
entire
pipeline
looks
almost
identical.
So
something
like
that
would
be
a
perfect
opportunity
for
a
template.
We
just
don't
leverage
it.
D
E
F
C
And
has
that
been
I?
Think
it's
fair
to
say:
that's
been
a
time
constraint,
mainly
the
stopped
us
moving
on
to
the
templates
right
and
what
we
have
does
service
relatively
well,
given
that
the
the
pipelines
are
fairly
similar.
F
A
Well
fits
in
with
some
of
the
the
future
plans.
We've
had
because
I
think
some
of
the
things
around
our
pipelines
is
it's
one
Pipeline
and
it's
just
been
there
and
it
just
works,
so
sort
of
we
haven't
prioritized,
go
change
it
because
it's
working,
but
actually
as
we
go
into
the
sort
of
future
stuff,
so
the
work
Graham's
doing
right
now
with
the
release
environments,
possibly
as
we
I,
you
know,
independent
deployment
blueprint.
We
have
a
big
idea
which
is
much
more
about.
In
order
to
solve
this
problem.
A
We
would
have
new
pipelines,
we
would
need
to
create
a
lot
more
pipelines
and
at
that
point,
templating
becomes
really
useful
because
we're
probably
creating
lots
of
new
similar
pipelines,
whereas
I
think
as
it
is
today,
we
more
or
less
just
have
one
fairly
long-lived
static
pipeline.
A
I
think
it's
reasonably
long
term.
We've
got
it
under
our
sort
of
long-term
roadmap.
There
may
be
some
things
beforehand,
so
I
think
this
would
be
a
certainly
is
a
good
one.
Definitely
for
us
to
keep
in
mind
like
skybek.
You
know
sort
of
the
thinking
you're
doing
at
the
moment
about
the
QA
tests
on
kubernetes.
That
right
now
feels
like
a
possible
point
where
we
should
consider
if
this
is
helpful
for
us
but
I.
It
feels
like
it
sits
more
closely
with
the
independent
deployments
blueprint,
which
is
probably
next
year
earliest.
D
Okay,
imagine
you
think
that
you
yeah
anything
that
you
can,
you
think,
might
might
benefit.
You
might
benefit
from
that,
but,
as
I
mentioned,
if
you
have
like
the
same,
even
if
you
have
the
same
template,
we
sorry
the
same
pipeline
but
with
different
environment
name,
for
instance.
This
is
definitely
something
you
can
just
like.
D
You
know,
call
that
same
Pipeline
with
and
just
templatize
the
name
of
the
template,
like
anything
that
you
can
do
in
order
to
so
I
use
it
and
also
like
provide
us
with
feedback
by
saying:
hey,
like
that's
great,
but
if
you
had
like
I,
don't
know
this
feature
this
Edition
or
could
you
support
like
with
that
variation?
This
is
definitely
something
that
we
can
prioritize
because.
G
D
Are
really
at
the
beginning
of
like
launching
that,
and
we
really
want
that
that
fit
that
feedback,
because
it
will
take
time
until
users
will
adopt
their
features
with
that
diameter
will
get
feedback
from
that.
So
getting
like
internal
feedback
would
be
super
useful,
even
if
it's
just
something
very
minimal.
A
That
makes
sense
okay.
Well,
we
have
an
epic
where
we
keep
track
of
these
dog
fooding
ideas
and
asymmetric
Graham
who's,
not
on
the
call
but
working
on
release
environments.
Let's
see,
if
there's
the
pieces
of
that
that
we
can
combine
in
so
that
we
can
start
picking
this
up.
D
D
So
we
also
going
to
like
we
want
to
convert,
like
all
the
all
the
all
the
scanners
that
we
have
sticker
detection,
the
code
quality,
the
performance,
all
the
templates,
basically
eventually
I
see
them
converted
into
into
a
component
So,
eventually
in
one
way
or
another,
everyone
will
use
either
use
like
a
component
or
you
use
the
template
with
an
input
instead
of
variables.
So
yeah.
C
The
security
scanner
specifically
does
that,
because
we've
done
a
number
of
updates
and
deprecations
around
those
and
how
we
roll
them
out,
are
those
going
to
be
a
kind
of
well
yeah
managed
component
where
breaking
changes
happen
in
the
background
and
the
impact
to
a
team
like
the
the
delivery
group,
is
you
change
from
version
one
to
version
two
and
then
you're
done.
D
Exactly
you
can,
but
this
something
this
is
something
that
will
come
with
it
with
only
with
components.
So
this
is
like
a
value
that
you'll
get
from
a
company
template
you'll
still
do
like.
If
you
use
template,
you
still
don't
do
like
an
included
template,
but
usually,
if
you
go
like,
if
you
want
to
configure
some
sort
of
an
analyzer,
so
you
need
to
pass
variables
different
variables.
So,
instead
of
that,
we'll
convert
them
into
into
into
inputs.
D
Okay,
but
then
eventually
we'll
move
them
into
into
a
component
and
when
we'll
move
them
into
a
component,
then
moving
like.
If,
if
you
already
took
a
template
and
add
an
input
to
that,
you've
done
most
of
the
work.
Okay,
because
this
is
the
majority
of
the
hook,
then
all
you
need
is
just
like
give
it
like
a
name
at
the
readme,
and
this
is
more
or
less.
This
is
more
or
less
what
we
need.
D
B
I
have
a
question
regarding
that.
Actually,
so,
when
you
said
versioning
does
this
versioning
mean
tagging
on
a
repository
where
you
store
this
component
or
is
is
basically
tag
of
the
docker
image
or
something.
B
And
the
reason
I'm
asking
is
that
that
multiple
components
might
require
a
different
execution
environments,
for
example
like
these
scanners
right,
so
they
they
require
to
have
some
special
tooling
installed
on
on
the
docker
like
where
this
component
actually
run,
where
this
scanner
actually
run,
and
if
you
just
include
the
the
versioning
and
tags
in
in
the
Repository,
there
is
a
chance
that
this
component
might
have
some
executables
or
some
tooling.
That
is
not
present
on
the
current
Runner.
B
That's
why
that's
the
reason
why,
for
example,
GitHub
has
those
actions
built
not
only
by
you
know,
on
on
the
tax
from
the
repository,
but
also
from
Docker
images,
so
you
just
specify
that
the
docker
image
stack
because
component
might
have
some
something
that
some
application
that
requires
to
run
this
component.
D
Yeah
I
think
what
you're
saying
is
is
fair.
I
have
like
two
things
to
mention.
First
of
all,
a
component
with
a
repository
you
can
have
like
a
repository
with
multiple
components
and
multiple
dependencies
we
can
have
like
a
component
like
one
per
one
depends
on
the
way
you
want
to
structure
but
I.
Think
what
you
just
mentioned
is
more
of
like
what
we
would
like
to
call
a
step
and
a
step
is
something
that
it's
it's
it's
further
here
and
it
doesn't
have
like
a
priority.
D
The
timeline
is
I'm,
not
sure
about
the
time
plan,
but
basically
we
want
to
introduce
a
step.
A
step
is
is
exactly
an
action.
This
is
like
just
what
the
runner
is
doing.
It
will
need
to
involve,
like
the
runner
theme,
but
we'll
start
we're,
starting
with
the
template,
but
eventually
we'll
also
get
into
steps.
D
I
haven't
gone
into
that
because
we
didn't
broke
it
down,
but
the
idea
is
even
you'll
be
able
to
take
like
an
action
form
from
GitHub
action
and
you'll
be
able
to
convert
it
into
a
step
and
you'll
be
able
to
run
it
in
a
in
in
in.
In
our
this,
like
think
about
steps
as
as
the
same
as
as
actions,
and
but
it's
not
something
we'll
be
able
to
receive.
Like
16
pretty
question
mark,
maybe
two
of
the
second
half
of
of
this
year,
maybe
the
beginning
of
next
year.
B
Then
I
honestly
don't
understand
what
component
is
then
because,
as
you
described
component
has,
has
some
inputs
right
and
then
has
some
execution
part.
And
then
you
expect
this
execution
part
based
on
the
inputs
to
run
this
execution
part.
B
D
B
You
write
an
action
and
you
pack
everything
in
a
Docker
file
and
you
publish
the
section
as
as
a
Docker
image
and
you
use
it
and
whatever
you
have
running
on
installed
on
your
Runner,
it
doesn't
matter
because,
because
GitHub
action
unpack
this
Docker
file,
Docker
image
and
run
within
the
docker
container,
so
and
kind
of
yeah
I
see
some
technical
difficulties.
With
this
honestly.
A
Is
there
an
issue
that
that
we
can
take
that
to
just
on
the
interest
of
time?
I
want
to
move
on
to
some
of
the
release
management
tasks,
but
it
sounds
like
a
great
read
thought
that
you're
having
that
bad
of
my
site,
it's
obviously
somewhere
useful
that
Vladimir
can
document
that.
A
That's
great
thanks
for
bringing
this
one
up
doc.
So
what
I'll
do
is
I'll
link
it
onto
our
dog,
fooding,
epic
and
then
for
everyone
else
like
if
you
are
using
pipelines
or
thinking
about
creating
new
pipelines.
Please
consider
whether
we
can
make
use
of
some
of
this
stuff.
A
G
A
To
jump
to
release
management,
Ahmad
I
see
you're
having
fun
with
some
tagging.
So
how
are
you
getting
on?
Do
we
need
to
do
a
bit
of
a
like?
Would
it
be
useful
to
make
use
of
everyone
on
this
call
to
go
through
anything.
H
I
just
like
retry
the
tagging
because
it
failed
so
I'm
checking
if
it's
gonna
fail
again
yeah
I
think
I
will
ask
for
some
help.
Then
it
fails
again
but
like
so
far
so
good
awesome.
A
Fingers
crossed
on
this
one
awesome.
Are
there
any
other
discussion
that
people
want
to
bring
up
before
we
jump
into
the
metrics.
E
I
So
last
week
there
were
a
few
incidents
that
we
can
see.
We
actually
had
one
go
over
the
weekend
into
the
beginning
of
last
week
and
the
the
one
or
two
incidents
that
kind
of
took
up
some
time.
It
was
pretty
much
we
resolved
through
the
day,
but
then
the
package
wasn't
gonna
get
the
new,
the
the
like
the
revert
or
the
fix
until
the
next
day.
I
So
it
was
pretty
much
like
we,
we
got
things
moving
and
then
the
next
shift
kind
of
was
able
to
finally
get
the
package
in
and
that's
the
same
thing
that
we
saw
that
happened
here.
So
that's
kind
of
where
we
see
this
increase
in
not
promoted
packages,
because
we
were,
we
were
truly
blocked
until
we
had
a
package
with
the
revert
in
place.
These
two
are
a
bit
more
minor.
I
They
were
like
blocking,
but
not
not
in
a
way
that
really
caused
any
problems
it
was
it
was.
They
were
not
long
enough
to
really
cause
any
issues,
and
then
I
marked
a
few
UA
failures
here,
just
as
like
single
one-offs,
because
they
were
happening
quite
a
bit
earlier
in
the
week.
I
So
I
started
to
mark
them
and
actually,
at
the
end,
I'll
probably
ask
everyone
about.
You
know
what
you
think
about
how
we
track
some
of
those
and
then
jumping
over
to
the
deployment
frequencies,
so
I
guess
over
the
over
the
last
90
days.
We
do
see
that
this
last
week
was
a
bit
lower
than
the
average
and
I
think
that's
due
to
like
starting
off
with
an
incident
and
then
having
one
or
two
midweek.
I
That
kind
of
just
slowed
things
up,
so
we
couldn't
get
more
than
two
packages
out
per
shift
for
the
most
part,
there's
this
Indian
View
and
then
looking
at
the
lead
time
for
changes.
This
fits
our
standard
pattern
where
we
we
see
it
bump
up
over
the
weekend,
and
then
we
come
back
down
to
our
standard
level
before
the
weekend.
Again,
if
we
look
at
the
deployment
blockers,
there's
a
handful
of
issues
here
that
blocked
us.
I
So
the
main
one
was
the
QA
failures,
so
that
kind
of
happened
at
the
end
of
the
emea
time
zone
and
what
ended
up
happening
was.
It
didn't
really
get
raised
up
to
being
an
incident
until
a
few
hours
later,
and
then
it
was
kind
of
like
okay.
Now
we
have
to
wait
for
Quality
to
get
involved
and
and
get
the
revert
going,
and
so,
even
though,
like
there
were
ongoing
deployments
at
the
beginning,
it
slowed
down
all
of
the
upcoming
packages
and
then
eventually
caused
a
larger
delay.
I
And
so,
even
though,
like
during
this
10
or
12
hour
period,
we
had
a
package
go
out.
We
were
technically
blocked
through
that
whole
time,
because
nothing,
nothing
else,
was
progressing
forward.
I
I
This
is
essentially
how
we
track
it,
where
we
just
I
mean
put
the
hours
in
the
incidents.
So
we
don't
end
up
with
doubled
hours.
A
Really
you
couldn't
even
just
leave
it
off
the
table
company.
As
long
as
we
have
a
record
where
we
actually
track
the
the
total
number,
then
it
doesn't
matter
too
much
how
we
have
it,
but
yeah
having
it
at
zeros
is
totally
fine
as
well.
Okay,.
I
And
then
I
know
that
one
or
two
of
these
other
incidents
weren't
like
explicitly
blocking
deployments,
but
we
like
there
was
one
or
two
of
them
that
it
was
kind
of
like
more
of
a
safety
we
didn't
want
to.
You
know
risk
at
all
introducing
anything
in
the
wild
because
we're
getting
resolved
so,
let's
just
or
those
just
included
a
few
extra
hours
for
each
of
those.
I
I
So
if
we
look
at
the
Run
books,
so
anytime,
there's
like
a
flaky
failure,
for
example
like
it
does
say
that
when
a
job
fails
create
an
issue
on
the
release
tracker
and
so
that
you
know,
even
if
we
just
retry
it
and
it
succeeds,
it
seems
like
we
should
create
an
issue
I
dug
in
a
little
bit
further
into.
You
know
following
the
steps
of
the
deployment
or
deploy
failures,
runbook,
and
it
says
that
if
you
can't
resolve
it
within
five
minutes,
you
should
open
an
issue
on
the
release.
I
Tracker
and
so
I
was
curious
because,
most
of
the
time
to
just
retry,
a
QA
failure
is
going
to
take
more
than
five
minutes.
Should
we
be
tracking
every
single
QA
failure,
even
if
it
succeeds
after
the
first
retry
or.
A
Is
that
something,
if
you
my
idealistic,
View
and
then
everyone
else
can
wait
in
with
a
realistic
view,
so
I
I
would
love
to
see
these
things
tracked,
simply
so
that
we
can
go
back
to
Quality
and
actually.
B
A
Able
to
say
like
hey
last
week,
we
had
10
things
right.
However,
I
am
aware
that
it
creates
an
overhead
for
us
and
it's
not
always
realistic,
so
you
can
use
your
discretion
on
that
one,
but
I
I,
think
quality
are
doing
a
great
job
of
seeing
a
lot
of
these
failures
now,
maybe
more
so
than
some
of
our
times
in
the
past.
A
So
perhaps
it's
a
little
less
urgent,
but
at
the
same
time,
I
think
as
much
as
we
can
make
the
delays
and
pain
that
we're
experiencing
more
visible
the
easier
it
is
for
other
people
to
actually
go.
Okay,
that's
a
real
problem.
Let
me
go
fix
it.
So
that's
kind
of
the
intention
behind
all
of
these
metrics
but
I'll.
Let
other
people
wait
in,
because
I
know
it
is
a
little
bit
down
to
how
you
manage
your
workload
and
how
you
like
how
that
gets
handled.
I
A
To
duplicate-
and
we
may
want
to
use
those
as
well
but
I
do
think
it's
useful
for
us
to
be
able
to
like
one
one
thing:
we
we
do
and
we're
going
to
do
a
lot
more
of
is
pointing
out
to
people
that
hey
like
last
week.
We
had
this
number
of
deployment
delays.
It's
certainly
useful
for
people
to
be
able
to
see
the
different
types
of
those
things
someone
about
QA.
Some
of
them
are
incident
or
or
other,
but
yeah.
If
there's
an
easy
way
to
help,
do
that,
then
please
click!
A
Please,
go
ahead,
automate
it
or
make
use
of
something
that
exists
already.
Whichever
is
better.
A
Also
one
observation
I'm
going
to
move
on
rapidly
in
a
sec
because
we're
quite
running
quite
late,
but
for
the
next
release,
managers
so
Vladimir
and
Myra,
who
probably
was
recording
it,
does
look
like
for
a
week
like
last
week,
certainly
we're
creating
a
lot
more
packages
than
we
end
up
using
so
do
consider
whether,
when
we
adjust
the
release
manager
schedule,
you
may
not
want
to
go
at
the
frequency
we
have
been
going
at.
A
It
may
be
worth
considering
whether
we
like
increase
the
time
between
package
tagging
and
produce
just
a
few
about
one
less
package
or
a
couple
less
packages
each
day.
B
I
think
the
main
reason
we
dropped
so
many
packages.
It
was
incidents
I,
think.
I
A
E
A
A
Be
nice,
should
we
just
do
it
together
as
a
group
since
I
think
this
may
be
new
for
a
lot
of
people,
so
gonna
be
leaning
on
you
too?.
H
I,
think
it
cannot
find
the
tag
in
this
repository.
The
false
reposter.
G
C
G
Yeah
yeah,
the
last
the
last
line
in
gitlab
client
get
City
party.
So
the
reason
that
400
is
happening,
I
think,
is
because
of
the
way
we
are
passing
the
message
when
calling
the
tag
API.
G
G
G
So
waiting
for
it
to
load,
so
this
is
not
supposed
to
be
a
keyword,
argument.
I
think
that's
what
the
problem
is
earlier.
We
were
calling
a
different
method
here,
find
or
create
tag,
and
that
was
one
of
our
methods,
so
that
was
taking
message
as
a
keyword
argument,
but
now
we're
calling
create
tag,
which
is
something
that's
provided
by
biogem,
so
it
doesn't
take
messages
as
a
argument
like
this.
G
A
Thank
you,
so
if
it
doesn't
right,
thank
you.
Thank
you.
Yeah
thanks
Vivid,
so
we
are
running
quite
over
time.
If
anyone
needs
to
drop
or
wants
to
drop,
please
just
go
for
it.
Otherwise,
that's
I'll.
Stop
this
recording
and
we
can
jump
to
some
other
stuff.