►
From YouTube: Verify Product FY22Q2 Sync
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
All
right
we're
here
to
do
our
verify
quarterly
sync:
this
is
our
opportunity
to
kind
of
kick
off
the
quarter.
We're
doing
this
to
share
our
quarterly
plans,
to
kind
of
re-establish
our
cadence
for
verify
as
a
team.
A
What
I
would
love
to
do
is
start
this
off
with
a
fun
fact
to
share
I'll
get
us
started,
so
we
finished
mapping
the
first
leg
of
our
trip,
so
some
of
you
may
know
that
I
am
staying
in
a
recreational
vehicle,
an
rv
and
we'll
be
traveling
for
40
days,
we'll
start
in
july
and
go
through
the
end
of
august,
we'll
be
going
all
the
way
up
to
montana,
going
through
colorado
and
idaho
and
stopping
along
the
way
to
hike
fish
and
hang
out
I'll
pass
it
up
to
whoever
wants
to
go
next.
B
I'll
go
next.
I
I
put
a
work
one
in
too,
but
it's
exciting
that
we're
starting
interviews
for
a
designer
that'll
be
fun
to
get
a
designer
back
for
darren
and
I
and
then
kitchen
remodel,
started.
That's
a
link
to
yesterday's
tweet.
I
am
tweet
storming
this
as
we
go
so
day.
B
Nine
was
yesterday
of
officially
having
a
crew
in
and
doing
stuff
and
they
rebuilt
the
wall
used
to
be
a
funky
half
wall
there
between
the
level
of
the
kitchen
and
the
level
of
the
family
room,
which
is
down
half
a
flight
of
stairs.
So
you
would
like
lean
down
and
look
down
into
one
room
from
the
other.
C
I'll
go
next.
I
just
put
a
down
payment
for
one
new
car
and
I
thought
it
would
take
me
a
while
to
sell
my
old
one,
but
I
started
it
like
less
than
a
week.
I
mean
opportunity
came
so
I
didn't
want
to
to
lose
it.
But
now
I
have
no
car
for
the
next,
like
you
know
I'll
say
like
two
months
or
so,
but
we
will
manage.
D
Oh
my
turn,
I
don't
know
if
I
have
anything
fun
to
share,
I
just
I'm
getting
old.
Last
weekend
I
tried
some
to
mulch.
You
know
like
just
do
some
mulching
in
the
garden.
Just
only
got
10
bags
of
mulch
at
home
depot
only
10
and
all
I
did
was
get
them
onto
the
cart
put
them
in
the
back
of
the
suv
drew
it
home,
took
one
bag
out
each
from
the
cart,
and
you
know
used
the
rake
to
to
bulge
the
front,
and
I
was
completely
sore
all
freaking
saturday
nights.
I
know.
A
I
love
that
that
is
a
fun
fact.
Perfect.
That's
some
some
good
news
all
around!
Thank
you
all
for
sharing
that
so
diving
on
in
would
love
to
hear
a
little
bit
about
our
quarterly
plans.
A
We
had
this
new
engineering
allocation
initiative
in
ci,
particularly
around
ci
scaling,
which
will,
I
think,
shift
to
be
less
about
this
20
million
builds
per
day
and
maybe
about
queuing.
This
is
like
kind
of
like
a
breaking
update,
but
I
think
that
that
might
might
come
through
today
from
darby.
I've
linked
our
one-year
focus
for
continuous
integration,
which
doesn't
have
any
of
the
engineering
allocation
work
in
here,
but
it's
stacked
ranked
for
what
we're
hoping
to
accomplish
outside
of
the
engineering
allocations
and
the
abuse
work.
A
A
So
I'm
going
to
start
kicking
off
some
validation
for
those
later
two
epochs,
hopefully
here
in
q2
and
q3
with
vitica
fitsuka
will
also
start
working
on
a
ux
scorecard
for
variables
so
that
we
can
get
a
comprehensive
understanding
of
what
the
current
state
of
variables
really
are.
Given.
That's
such
an
expansive
experience-
and
we
have
so
many
bugs
around
variables
today
that
it's
really
really
unpredictable
for
how
users
are
are
reporting
their
experience
with
variables.
A
C
C
They
have
a
solution
for
like
expanding
variable
infinitely,
because
I
think
now
we
only
like
we
only
pass
a
variable
to
one
level
down
like,
for
instance
in
and
child
pipeline
things
like
that,
and
so
it
worth
looking
at
the
solution
and
maybe
propose
to
some
of
our
users
to
lift
the
feature
flag
and
see
if
it
solved
the
problem,
because
we've
seen
it
actually
solving
some
problems
in
some
bugs
that
they've
reported
around
bibles.
A
A
Who
wants
to
talk
a
little
bit
about
their
kichi
priorities?
Next.
D
And
as
always,
every
time
you
copy
and
paste
it
that
does
this
weird
linking
thing.
So
let
me
just
find
the
the
first
one
and
add
a
link
to
the
epic,
sorry
so
slow
this
morning,
all
right,
so
that's
the
first
one
so
and
that
I
created
a
few
weeks
ago
as
a
way
to
kind
of
just
consolidate
some
of
the
moving
parts
to
kind
of
like
get
some
structure
in
terms
of
what's
happening
with
runner.
D
D
The
only
reason
it
came
on
the
runner
was
because,
a
few
months
ago
we
didn't
have
the
bandwidth
in
ci
to
do
it
and
because,
at
those
points
on
the
team
picked
up
the
that
written
nested
variable
feature
we
just
kind
of
pop,
but
I
don't
think
it
actually
belongs
on
the
runner.
As
a
matter
of
fact,
elliott
got
pained
by
t-mobile
yesterday
on
a
feature
proposal.
D
They
put
it
in
the
running
team.
He
just
moved
it
this
yesterday
evening
to
to
see
anyway,
so
maybe
some
of
us
to
think
about.
So
that's
that
the
big
that
was
the
initial
thinking
in
terms
of
fy
22..
I
think
the
only
thing
that
caught
in
this
epic
that
I'm
concerned
about
for
runner,
fy
22,
is
of
two
things
to
call
out.
D
One
is
the
the
first
class
support
for
podman
and
runner
is
probably
not
going
to
happen
because
our
testing
founded
a
lot
of
our
testing
and
work
with
red
hat
engineering
and
red
hat's
product
management.
We
found
some
gaps
in
podman,
so
it's
not
a
quote-unquote
drop-in
replacement
for
docker,
we'll
see
if
red,
where
heck
can
fix
it.
But
right
now,
I'm
not
that
in.
D
I
feel
very,
I
feel,
that's
kind
of
a
lower
probability
of
making
an
f120
to,
even
though
a
lot
of
people
a
lot
of
people
on
red
hat,
need
this
solution
and
the
other
big
thing
to
call
out
in
terms
of
this
big
bucket
for
fy22
junkie,
which
sort
of
I'm
not
going
to
use
any
big
language.
It's
kind
of
related
to
the
scaling
and
kind
of
related
to
the
appdexon.com
in
a
weird
kind
of
roundabout
way.
D
Is
this
auto
scanning
provider
you
just
merged
mr
this
morning
I
believe
around
only
compared
to
stuff
and
then
for
dolphin
for
james
to
give
you
a
high
level
how
it
all
comes
together
today
on
gitlab.com
to
keep
it
simple.
We
use
the
gitlab
runner
with
the
doctor
machine
executor
to
autoscale.com
a
lot
of
our
customers
also
use
that
git
lab
runner,
docker
machine
executive,
auto
scale,
they're
self-managed
fleets
right
that
docker
machine
piece
of
code
is
no
longer
being
maintained,
being
maintained
by
docker
machine
people
or
the
docker.
D
Folks,
like
a
couple
of
years
now,
we've
been
maintaining
our
old
forks.
So
this
epic,
which
we've
been
talking
about
since
I
joined,
was
like
hey.
What
are
we
going
to
do
to
get
off
of
duck
machine
right
and
so
we're
still
using
docker
machine
we're
still
adding
stuff
to
it?
We're
obviously
doing
a
bunch
of
things
within.com,
but
it
may
not
necessarily
be
the
thing
we
want
to
stick
with
for
both
the
customers
and
that
comes
that's.
D
So
that's
my
biggest
fear
in
terms
of
like
everything
like
to
jackie
spence
everybody's
focused
on
rapid
actions.
Right
now
and
stuff
I
mean:
when
do
we
pivots,
actually
focus
on
tackling
this
and
it's
so
interwoven
with
other
things
like
hey?
Do
you
change
it
for
calm
and
it's
a
different
solution
for
the
customers?
D
Don't
know,
and
then
the
only
other
thing
I
want
to
add
really
fast
and
I'll.
Stop
hugging
the
oxygen
as
I
created
this
new
epic
shoot.
I
lost
it
already.
I
am
so
no
I
I
found
it.
Oh
goodness,
I
created
this
new
epic
yesterday,
so
I
just
added
in
here
I
said:
oh,
let
me
try
and
do
that
it
does
this
like
crazy
thingy.
So,
let's
make
it.
B
I
was
just
really
excited
about
that.
Epic
darren-
I
am
just
super
excited.
I
am
so
late
to
the
moon.
D
So
this
is
kind
of
one
of
those
things
that
kind
of
like
variables
too.
Some
some
of
this
is
probably
on
the
ci,
but
yesterday
I
just
created
this
epic
because
it
was
like
so
many
different.
I
felt
felt
like
there
were
so
many
different
things
about
tagging
and
the
user
tags
yeah.
So
I
was
like
and
prioritization,
so
I
just
created.
Yes,
I
don't
know
like,
for
example,
really
fast.
I
don't
know
where
all
of
this
work
fits
in
terms
of
priority.
D
I
can
only
say
that
issue
number
three,
two,
nine
three,
four
four
in
this
epic,
the
one
called
namespace
or
protected
tags.
That
brainstorm
was
a
quick
brainstorm
because
of
a
discussion
and
an
issue.
The
gesso
and
I
wasn't
paying
attention
was
like
we
got
painted
the
issue
by
sophie
said:
hey
a
customer
needs
a
solution,
and
then
I
looked
at
us
like
nah.
That's
not
the
solution.
The
solution
is
this
thing.
D
Aaron
pointed
out,
we
jumped
on
the
call
yesterday
with
sophie's
customer,
which
happens
to
be
a
big
customer
and
they're
like
oh
we're,
the
one
who
wants
this
problem
so
that
name
space
or
protected
tags,
then
we
might
have
to
figure
out
a
way
to
do
that
sooner
rather
than
later,
even
though
nothing
in
this
whole
bucket
of
work
is
prioritized.
So
that's
kind
of
my
quick,
I'm
running
brain
dump.
D
C
So
our
our
team
is
that
we've
seen
in
and
increase
adoption
for
users
that
are
using
our
pipeline
editor
and
we
can
share
the
systems
a
chart
later,
but
we
are
growing
in
terms
of
like
the
amount
of
unique
users
that
are
interacting
with
the
pipeline
editor,
which
is
very,
which
is
very
promising
and
see
that
this
is
a
very
needed
capability
that
was
missing
in
in
gitlab.
So
definitely
continue
the
work
on
the
epic.
On
that
editor.
C
C
You
can
link
the
epics
afterwards
I
have
like
we
have
an
mvc,
for
we
call
it
like
the
pipeline
drawer,
where,
whenever
you
will
open
your
pipeline
editor,
you
will
see
like
a
drawer
with
some
meaningful
insights
or
so
informal
information
about
how
you
can
get
started
with
a
new
pipeline,
because
we
all
know
soon
we'll
get
our
users
to
get
to
the
first
game
pipeline,
more
likely
for
them
to
continue
to
use
our
gitlab
ci,
especially
the
first
one,
and
so
this
is
this
is
this.
Is
this?
C
Is
a
the
first
priority
that
we'll
focus
on
like
as
a
part
of
the
pipeline
editor?
The
second
big
thing
that
I
think
is
is
is
pretty
it's
pretty.
C
I
would
say
it's
it's
big
change,
for
our
users
will
be
maybe
sounds
simple,
but
it's
not
is
to
allow
need
to
refer
to
a
job
in
the
same
stage.
That's
the
name
of
the
of
the
architectural
issue.
It's
an
issue,
but
it's
it's
pretty
big.
C
I
mean
today
the
near
dependencies
between
job
of
the
limitation
that
you
can
only
need
a
job
that
exists
in
different
stage
and
we
want
to
basically
drop
that
limitation,
so
you'll
be
able
to
need
you
can
you
can
link
neat
dependencies
between
job
regardless
of
the
stage
they're
at,
and
this
is
pretty
drastic
dramatic
for
our
users,
because
it
means
that
we
are
actually
basically
breaking
the
stage
complex.
C
So
there
will
be
no
need
for
stages
when
users
will
start
defining
their
pipeline
and
for
years
we've
been
using
stages
as
a
way
to
control
when
certain
jobs
will
run
and
set
like
specific
execution
order.
But
I
would
say
that
this,
like
one
issue,
is
actually
allow
users
to
use
like
stageless
pipeline,
so
walking
a
little
bit
with
marketing,
obviously
drafting
a
blog,
we'll
take
our
time
on
releasing
this
feature,
because
we
understand
that
this
is
a
major
change.
I
want
to
make
sure
a
lot
of
our
engineers
will
have
their
eyes
on
that.
C
C
Probably
there
will
be
like
more
follow-ups
on
this
specific
issue.
We
have
already
won
when
we
like
identified
that
the
front
end
is
so
think
about
it,
like
you
will
have
like
one
stage.
So
how
will
the
pipeline
look
like?
C
We
like
a
really
big
vertical
vertical
a
pipeline,
so
this
is
why
we
introduce
like
a
different
type
of
visualization,
so
there
will
be
like
a
lot
of
things
that
we
need
to
do
like
in
order
to
adapt
to
that
new
style
and
honestly,
I
think
that
once
we'll
have
this
capability
available,
we
may
end
up
like
in
like
a
year
or
two
for
now,
people
will
stop
using
stages.
A
Yeah,
definitely
definitely
so
that
we
can
take
a
look
at
those
in
the
future.
I
really
appreciate
you
walking
through
that
feels
like
we
have
so
much
to
do.
I'm
excited
for
our
upcoming
quarter.
Thank
you
all
for
telling
me
about
y'all's
plans.
A
A
It's
called
sas
first
and
we're
having
this
kind
of
cultural
phenomena,
that's
coming
in
hot
for
git
lab,
and
it's
this
sas
first
focus,
which
is
we're
committed
to
developing
our
ethic
around
gitlab.com,
and
this
is
mean
this
means
driving
a
feature
parity
that
is
on
selfmanage
to
gitlab.com
a
renewed
focus
on
availability
and
performance,
and
why
we're
doing
this
is
because
we
are
really
noticing
that
there's
a
huge
opportunity
for
enterprise
customers
for
the
market
and
people
wanting
to
not
manage
their
own
software
services.
A
So
it
really
is
important
for
us
to
start
investing
in
that
opportunity,
because
the
more
that
we
can
manage
other
people's
services
for
them,
the
better
our
product,
is
going
to
perform
the
more
that
they're
going
to
pay
for
our
product
and
the
more
consumption
prices
like
artifacts
and
minutes
are
going
to
be
on
gitlab
right.
A
A
Metric
darren
has
a
special
one
that
he'll
be
accountable
for
too
it's
going
to
be
a
an
slo
that
he's
responsible
for
for
runner
on
aptx,
and
there
will
probably
be
some
other
things
that
end
up
coming
up
as
we
start
to
monitor
and
manage
availability
and
performance,
any
questions
or
thoughts.
D
I'm
still
gonna,
I
just
yeah,
I'm
still
confused
slightly
about
the
error
budgets.
I
mean
in
layman's
terms
how
we,
how
we
plan
to
use
error
budgets.
A
So
how
I've
used
them
in
the
past
is
on
a
regular
basis.
If
you
use
a
sas
product
and
you're
releasing
continuously
to
it.
You
would
check,
after
a
release,
because
it's
a
lagging
metric
to
see
how
your
releases
are
impacting
your
availability,
metrics,
and
if
your
downtime
is
being
impacted
by
your
releases,
you
should
have
leading
indicators
like
mean
time
to
resolution
and
seeing
how
those
see
how
those
metrics
are
are
interplaying.
A
What
we're
trying
to
go
toward
is
maintaining
a
99.95
availability
percentage
in
q2.
So
that's
that's.
Our
target
is
just
to
have
that
that
percentage
of
uptime
across
gitlab.com
and
what
we
should
be
doing
in
response
to
that
is
prioritizing
things
like
infradev
issues
or
doing
root
cause
analysis
on
what
causes
downtime.
A
So
this
will
be
hey.
Scalability
you'll
submit
an
issue.
I
noticed
a
dip
in
my
availability
after
I
released
these
features.
Can
you
help
me
root?
Cause
analysis,
this
dip
and
sometimes
scalability,
would
then
come
back
with
a
solution
or
root
cause
analysis
on
what
features,
what
apis,
where
what
things
have
happened
and
that
might
might
might
require
you
to
do
refactors
or
roll
back
features
or
do
changes
best
case
scenario,
is
that
you
aren't
spending
your
budget
or
you're.
A
D
A
A
Other
other
things
that
I've
done
with
air
budgets.
I've
I've
been
in
places
where
I've
had
like
five
minute
air
budgets
before
and
I've
been
like
held
contractually
to
five
nines
and
that's,
like
you
know,
like
super
high
availability,
sas
products
and
and
that's
whenever
you're
you're,
you
need
really
performance
systems
and
you're
doing
really
high
your
high
prioritization
for
for
redundancy
for
setting
up
failover
systems
disaster
recovery.
A
Super
redundant
systems
and
creating
new
partnerships
with
gcp
and
aws,
and
a
really
robust
technical
roadmap
in
order
to
produce
that
5.9
sla,
not
even
slo,
to
support
that
kind
of
infrastructure.
I'm
not
quite
sure
we'll
get
to
that
point.
D
A
So
that
kind
of
brings
me
to
the
next
point
there's
this.
This
issue
that
I
have
opened
called
the
united
model
and
verify
where
we're
waiting
for
an
infrastructure
delegate
from
engineering
team,
so
that
we
have
like
a
stable
counterpart
from
engineering.
That
is
an
assigned
infrastructure
person,
so
that
we
can
ask
questions
and
have
like
a
shared
kpi
ownership.
A
We
currently
have
the
united
leadership
at
the
product
like
function
organization
level,
so
we'll
test
it
at
the
verify
stage
level.
The
idea
is
we'll
pick
some
sort
of
goal
to
chase
at
the
year
and
we'll
have
an
organizational
alignment
with
these
various
leaders
to
make
that
happen.
We're
still
waiting
for
an
infrastructure
delegate,
but
I
think
in
part
that
infrastructure
delegate
would
help
us
execute
on
something
like
error
budgets
effectively,
because
if
we
don't
have
those
kinds
of
people
then
we
won't
get.
A
E
B
So
it's
like
we're
gonna,
have
questions
then
about
how
do
you
balance
things
that
fall
under
this
united
model
with
your
okrs,
or
do
we
ensure
that
the
okrs
roll
up
to
this?
Yes,
it
just
seems
like
it's
another,
yet
another
layer
of
things
that
we
have
to
deal
with
this
product
and
incoming
okrs
for
various
other
groups
that
we're
going
to
have
to
expend
energy
pushing
back
on
to
say,
nope.
Sorry,
this
priority
is
our
number
one
priority.
This
quarter,
based
on
our
group's
united
model
and
where
we.
A
I
would
like
us
to
find
like
something
that
intersects
at
all
right.
If
we're,
if
we're
driving
an
exclusive.com
metric,
then
I
think
that
intersects,
all
of
it,
the
sas
first,
the
availability
metric
the
scaling
metric
and
then
we,
then
we
can
funnel
in
the
features
that
are
going
to
drive
that
we
can
funnel
in
the
infrastructure
component.
That's
going
to
drive
that
we
can
get
the
business
cases
the
acquisitions
that
are
going
to
need
to
underpin
that.
We
just
have
to
get
the
alignment
and
then
we
can
say
no
to
everything
else.
A
A
To
me
to
me,
I
know
that
we're
over
time,
but
I
wanted
to
call
attention
to
this,
mr
that
I
have
out,
which
is
moving
artifacts
over
to
testing,
which
is
a
first
increment
to
the
team
proposal.
It's.
A
One
small
iteration
james
feel
free
to
say
no,
so
just
it's
a
backlog,
balancing
maneuver,
it's
a
pass
toward
it.
That
way.
When
we
backfill
this
cipm,
it
really
helps
them
have
a
more
realistic
handle
on
the
landscape.
I
was
going
to
do
variables
to
pipeline
authoring,
but
I'm
a
little
hesitant
at
one.
The
front
end
back
end
distribution
for
that,
because
pipeline
authoring
has
a
lot
of
friend
and
stuff
right
now,
so
I
didn't
want
to
overload
the
front
end
on
pipeline
authoring
and
then
the
back
end.
C
A
So
we
can
iterate
more
in
that
merge
request
on
if
there's
other
things
to
consider,
moving
and
james
feel
free
to
push
back
and
say
no
we're
all
ears
on
this
and
then
I'll
be
opening
up
an
issue
to
talk
more
about
this
verify
front
end
proposal.
A
I
think
that
there's
an
opportunity
to
more
holistically
think
about
our
frontend
team
and
maybe
have
the
front-end
team
pull
from
a
board
instead
of
from
their
own
team's
board,
so
that
when
they're
blocked
by
their
group's
back
end,
they
can
then
go
to
a
verify
board
and
pull
from
front
end
verify
and
team
scope,
that's
ready
for
them
to
work
on
and
that
way
they
can
maybe
work
on
testing
scope.
That's
ready
or
run
a
scope,
that's
ready
and
for
pipeline
authoring
scope.
That's
ready!
That's
groom!
A
That
has
an
issue
that
has
a
proposal
on
it
and
that
way
we
can
have
more
fluidity
of
delivery
and
then
ship
it,
but
I'll
open
up
that
issue
for
y'all's
review,
and
we
can
see
that
that
way.
We're
not
like
realigning
front
end
engineers
across
verify,
but
we
can
ship
more
front
end
work
and
not
have
a
bottleneck.
D
B
A
B
A
It
seemed
like
a
novel
idea
when
I
asked
arby
about
it,
but
I'll
I'll.
He
could
have
just
been
flattering
me
so
I'll,
create
the
I'll,
create
the
issue
and
we'll
see
if
yeah
kind
of
well.
Thank
you
all
for
your
engagement
and
sharing
everything
and
for
staying
a
little
bit
late.
I
appreciate
everything
that
you're
doing.