►
From YouTube: Monitor:APM Weekly Meeting 2019-10-03
Description
Announcements and discussion of the release timeframe and process
A
Okay,
so
I
had
a
few
just
announcement
type
things
first,
and
then
we
can
talk
about
other
topics
too,
but
yesterday
we
merged
a
change
to
the
handbook
for
monitor
we're
gonna
start
doing
weekly
async
entry
updates,
so
the
merge
request
is
there
and
the
actual
handbook
change.
Basically,
the
goal
there
is
to
once
a
week
just
update
your
each
issue
that
you're
working
on
with
the
current
status.
A
A
The
it
will
help
me
and
I.
Think
dole
has
been
looking
for
something
similar
to
this,
for
some
of
the
issues
that
we
especially
the
ones
that
we
move
from
one
release
to
the
next
to
know
kind
of
how
much
work
is
left
but
I
think
it'll
just
be
useful
for
everyone
this
year,
looking
at
an
issue
just
to
know
at
least
the
current
status,
so
that's
that's.
They
won't
have
any
questions
about
that.
I'm.
B
A
I
see
what
you're
saying
this:
when
do
you
protect
it
to
be
ready,
might
kind
of
get
at
that?
But
it's
not
exactly
that
like,
but
I
know
what
you're
saying
so
well,
maybe
yeah.
Maybe
before
we
move
anything
yeah.
Maybe
we
should
bring
that
up
that
before
we
move
any
issue,
we
can
make
sure
to
put
something
in
there
about
how
much
work
is
left.
Basically
so
yeah.
C
B
C
C
B
I'll
think
about
that
and
put
together
a
proposal.
Then,
if
it's
I
mean
I,
think
it's
reasonable.
If
it's
a
few
days
before
the
release-
and
we
realize
you
know
it's
not
a
production
yet,
then
we
know
it's
gonna
have
to
carry
over
I
guess,
maybe
that's
a
better
practice.
Then,
at
the
point
where
we
know
we're
going
to
have
to
carry
over
to
the
next
release,
we
post
a
comment
about
how
much
effort
that
will
represent
in
the
next.
C
A
D
A
The
the
nice
thing
about
geek
bot
is
that
you
can
configure
it
to
the
right
time
right
when
you
want
to
get
reminded
slack.
Has
the
downside
of
its
implement
brought
this
up,
that
it's
kind
of
tied
to
whoever
sets
it
up
or
it's
a
very
specific
time?
It's
not
adjustable
for
time
zones
or
anything
the
reminders
so.
A
A
It
kind
of
historically
has
always
been
velocity,
as
we've
said,
is
the
top
priority.
But
we
can't,
unless
we're
also
thinking
about
availability
and
security.
We
can't
we
can't
move
very
fast,
I.
Think
part
of
the
background
on
that
is,
and
others
have
more
context
again,
fill
it
in
too.
But
we
want
gitlab
comm
to
be
available
for
enterprise
customers
that
they
that's
an
option,
so
they
don't
have
to
stand
up
their
own
Hardware,
their
own
infrastructure.
They
could
just
use,
get
lab
comm,
but
before
an
enterprise,
customer
will
do
that.
A
They
need
to
know
or
trust
that
get
lab.
Comm
will
be
highly
available,
so
everyone
at
least
thought
everyone
in
the
engineering
group
should
have
gotten
an
email
from
Eric
with
a
Google
Form
to
acknowledge
that
I.
Don't
know
how
widespread
that
was
sent
out,
but
I
just
want
to
make
sure
everyone
saw
that
email
and
has
seen
this
change.
So
I
need
to
go
into
any
more
detail
unless
anyone
has
thoughts
or
questions.
A
I
just
wanted
to
make
sure
everyone
had
seen
that
okay
and
then
lastly
I
just
this
morning
I
well
yesterday,
we
noticed
that
about
20%
of
our
bugs
had
not
had
priority
or
severity
labels,
which
was
a
little
surprising
I,
don't
know
it
kind
of
fell.
Oh
I
lost
track
of
it.
A
little
bit
so
I
went
through
and
prioritized
and
put
severity
x'
and
assign
them
to
milestones
if
any
of
those
I
kind
of
just
had
to
take
a
heavy
hand,
just
kind
of
go
through
them
all.
A
A
There
was
well,
there
was
a
handful
that
were
created,
so
we
part
of
the
processes.
We
also
get
a
report
every
week
and
I
think
it
gets
sent
to
me
and
don't
maybe
and
Adriel
mm-hmm
with
all
the
new
bugs
or
any
bugs
that
aren't,
prioritized
and
Saverio.
Don't
have
I
can't
say
that
word
so
Verret
eyes
that
yeah.
A
If
you
don't
have
a
priority
or
severity
or
they're
not
scheduled,
we
get
a
report
of
that.
So
we've
been
using
that
to
kind
of
go
through
and
make
sure
everything
is
I
think
there
was
some
that
either
slipped
through
that
or
we
just
I
thought
I
prioritized,
but
maybe
I
didn't
so
there
was
some
that
missed
there
and
then
there
was
I
know,
there's
a
handful
that
we're
all
created
in
the
last
week
or
so
and
that
we
just
hadn't
seen
yet
so
I
made
sure
all
those
including
a
number
on.
A
A
Kind
of
walking
through
setting
up
a
project
with
Auto,
DevOps
and
monitoring,
and
as
part
of
that
he
created
a
number
of
issues
of
errors
that
he
or
problems
he
saw.
So
there
were
three
or
four
right
there
that
he
created
in
the
last
couple
days
that
just
hadn't
been
prioritized
yet
so
that
was
part
of
it.
I
think
we
just
need
to
do.
I
need
to
do
a
better
job
of
kind
of
kind
of
checking
on
that,
on
a
regular
basis,
just
to
make
to
kind
of
keep
an
eye
on
what's
coming
into.
A
D
C
A
So
there's
still
31
things
slated
for
12,
for
which
considering
we
started
with
less
than
20,
and
that
was
kind
of
our
target.
It
seems
like
there's,
probably
too
much
I,
don't
know
that
we
need
to
go
through
every
one
of
these
issues
right
now,
but
I
did
want
to
talk
about
how
to
like
what
is
that
process
of
kind
of
going
through
and
reviewing
and
seeing
like?
How
do
we
know
if
things
aren't
going
to
make
it,
and
when
do
we
do
that?
So
that's
really
what
I
wanted
to
talk
about
today.
B
A
B
A
B
Just
because
of
the
way
these
releases
rolling
out,
like
I've,
been
trying
to
get
more
information
from
release
as
far
as
like
how,
when
does
this
stuff
get
released?
The
answer
is
that
we
deploy
multiple
times
a
week
at
you
know,
intervals
that
are
mostly
determined
by
how
much
code
were
merging.
So
there's
no
guarantee
that
if
you
get
it
merged,
you
know
I,
don't
know
I
I'm
I'm,
not
exactly
clear
and-
and
the
answer
is
basically,
we
don't
do
prediction
anymore.
B
So
it's
a
really
weird
state
right
now,
between
like
continuous
delivery
and
and
our
monthly
releases,
that
we
that
we
cut
so
I,
don't
know
I
think
our
safe
is
bet
if
we
really
want
to
be
sure
that
it's
in
there
is
that
it's
merged,
probably
at
least
two
weeks
before
the
cutoff,
maybe
a
week,
if
we're
pushing
it
as
long
as
there's
like
that
guess
it
depends
on
one.
The
twenty
second
falls
right.
A
B
Think,
as
long
as
we
are
like
5
to
7
working
days
before
the
22nd,
it
seems
like
things
will
make
it
in,
but
but
the
weekends
are
what
throws
that
off.
So
it's
not
very
clean
like
7
days
before
it's
it.
It
has
to
do
with
where
it
falls
and
I
think
it
comes
down
to
some
of
those
working
days
and
what
and
why
that's,
okay,
making
a
difference
as
best
I
can
tell
like
I
said:
there's
not
really
a
set
release
schedule.
B
B
E
So
unless
there
was
some
update
to
it,
my
understanding
was,
we
were
doing
a
merge
every
Monday,
and
that
was
a
week
through
canary
and
staging
and
then
following
Monday.
It
would
go
to
final
test
and
I.
Believe
then
Wednesday
was
a
validation,
it
would
be
complete
and
then
Wednesday
it
would
actually
be
released.
E
So
there
was
like
a
week
plus
a
little
bit
to
go
to
release,
but
there
was
a
big
discussion
around
when
we
first
changed
to
the
17th
as
being
the
end
of
the
milestone
work
which
we
moved
and
the
discussion
there
ended
up
being
kind
of
like
just
a
simple
question
of
like
do.
People
feel
like
things
that
they
had
merged
on
the
Monday.
Were
those
things
going
to
end
up,
so
the
Monday
was
basic.
Sorry,
let
me
say
that
again,
let's
go
sick,
I
apologize
so
like
on
the
17th.
E
If
you
merged
it
by
the
end
of
day
17th.
The
question
was:
do
you
think
that
would
end
up
in
a
milestone
and
it
seemed
like
there
was
still
some
confusion
there,
but
what
ended
up
happening
was
pretty
much
anything
merged
prior
to
the
17th.
Was
going
in
and
then
it
seemed
that
the
consensus
was
that
most
people
were
on
the
of
the
impression
that
it
was
not.
It
was
merged
by
the
end
of
the
17th
that
would
be
in
because
they
cut
a
new
release
for
that
I
I'm
gonna
follow
up.
E
B
A
Okay,
hopefully
he
comes
back
well
yeah,
so
he'll
share
that
then,
but
yeah
I
think
it's
confusing
one
other
thing:
I
wanted
to
bring
up
I
think
talking
to
someone
about
the
configure
one
of
the
configure
teams
and
they
I
don't
think
they
even
pay
attention
to
the
engineering
side
doesn't
really
pay
attention
to
when
things
are
getting
released.
They
just
kind
of
do
more
of
a
Kanban
style
I
guess
that
would
be
a
bigger
change
for
our
team,
but
it's
something
we
could
could
think
about.
A
A
D
C
F
E
Just
on
the
milestone,
releases
and
stuff
I
link
to
the
actual
handbook,
which
is
saying
the
13
release
code
finalized,
so
okay
and
for
whatever
that's
worth.
If
it's,
if
it's
actively
changing
and
there's
some
other
information
that
a
journal
has,
that
seems
to
be
all
writers.
But
I
will
follow
up
with
that.
Okay,.
B
A
Not
we
can
call
it
early
I.
Just
wanted
to
put
a
reminder
on
here,
like
I,
want
to
every
time
to
make
sure
that
you're
filling
out
the
retrospective.
If
anything
comes
up
and
put
the
link
in
here,
so
I'll
kind
of
sound
like
a
broken
record
in
these
meetings
and
kind
of
remind
people
everything
every
week
that
we
want
to
make
sure
we're
keeping
that
up
to
date
and
as
things
come
up,
we
want
to
enter
them
into
that
retrospective
document.
The
company-wide
retrospective
is
today
is
that
right
and
yeah.