►
From YouTube: 2021-04-26 Delivery team weekly
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).
B
I
I'm
pretty
sure
it
is
right,
maybe
jack.
B
It's
a
good
question.
Let
me
check
the
you
know.
A
B
A
C
C
Now
awesome
so
just
want
to
say
firstly
on
mttp,
so
I'm
still
tracking
on
the
deployment
blockers
last
week,
look
pretty
healthy.
C
I
can
actually
only
update
the
target
monthly
because
that's
what
we
track
on,
so
I
will
see
how
things
go
this
week,
but
if
it
continues,
if
it
looks
like
it
did
last
week
and
we
have
a
calm
week
for
deployments
and
incidents,
then
I
will
probably
just
switch
the
target
back
down
to
12
hours,
but
I'll
I'll
put
that
in
slack
later
in
the
week,
but
nice
work
euric
and
robert,
like
things,
are
looking
pretty
nice
awesome,
there's
a
couple
of
read-only
announcements
just
to
keep
going
to
the
loop
and
then
discussions
so
first,
one
yuric
is
off
to
join
sharding,
so
from
may
10th,
but
he's
out
next
week,
so
he's
here
he's
around
this
week.
C
Is
there
anything
people
need
from
him
like?
What
are
you
most
concerned
about
with
euro
cleaving
like?
Is
there
anything
we
could
demo
or
write
or
share
in
this
week?
Also
little
things
go
this
that,
like
he's
not
dead,
so
you
know
like
he
will
still
be
available
after
the
10th,
but
just
not,
maybe
not
quite
as
much
as
he
has
been.
D
I'm
gonna
personally
be
missing
the
updates
on
his
perils
of
shipping
and
the
occasional
astronomy
update.
So
if
you
could
still
come
and
join
us
for
our
delivery,
weekly
that'd
be
that'd,
be
wonderful.
C
B
C
Fantastic
awesome.
Well,
if
anyone
thinks
of
anything
throughout
this
week
or
next
week,
then
let's,
let's
get
something
sorted
out
there
awesome,
and
this
might
actually
be
your
last
delivery
weekly
eric.
If,
if
that
is
the
case,
then
like
we
should
say,
I
mean,
obviously
you
can
still
come
like
like
jobs.
Still,
we
still
let
jarvan
so
you're
still
welcome
to
join
if
you
want,
but
thank
you
for
your
delivery
efforts
and
good
luck
with
the
with
the
sharding.
C
Cool
so
on
b,
so
epic
status.
So
for
the
last
few
weeks,
thank
you
for
all
of
you,
who've
been
putting
our
epic
statuses
on
your
epics.
I
wanted
to
just
try
and
move
this
the
next
stage.
So
what
I'm
using
epic
statuses
for
is
to
update
the
parent
epics
is
my
primary
goal
so
that
people
who
are
outside
of
the
team
can
just
land
in
one
place
and
get
a
nice
overview
of
like
here's.
What
we're
working
on
here's!
What's
going
on!
C
He
has
some
understanding
of
what
we're
doing
he's
not
in
the
team,
but
he's
also
quite
likely
to
be
asked
by
other
people
outside
like
hey,
what's
delivery
working
on
so
it's
somewhere
that
he
can
come
and
just
get
like
a
quick
snapshot
of
what's
happening
right
now,
it's
taking
me
quite
a
lot
of
time
to
compile
this
stuff,
so
I
do
the
epic
updates-
and
I
also
that's
where
I
generate
the
sas
weekly
agenda
from
on
a
thursday
as
well.
C
C
So
now
we've
been
doing
this
for
a
little
bit.
I
wanted
to
see
if
we
could
actually
agree
on
what
that
standard
format
should
look
like
scalability.
Do
this
as
well,
so
it
might
be
nice
to
just
like
standardize
with
scalability
as
well,
but
we
don't
absolutely
have
to
so
fully
open
for
here.
C
But
my
proposal
would
be
that
on
your
epic
there's
a
status
and
a
date
and
then
a
description,
few
sentences,
what
we're
working
on,
why
we're
working
on
it
and
what
the
next
steps
are
and
then
each
week
just
clear
down
the
date
and
the
status
and
replace
it
with
your
current
one,
and
I
can
just
pull
that
up
and
then
that
just
means
that
we
always
just
have
like
one
small
chunk
of
information
that
people
can
read.
They
don't
have
to
concatenate
other
things
together.
We
comment
and
things
like
that.
D
Overall,
it
sounds
okay.
The
only
thing
I
question
is
the
why
that
should
be
elsewhere
in
the
epic
or
issue
description.
I
don't
think
we
need
to
reiterate
the
why,
unless
there's
something
related
to
that
specific
step
that
we're
stuck
on
that,
we
need
to
explain
further,
but
I
feel
like
that
would
be
traced
into
the
issues
that
are
leading
up
to
that
epic,
that
we're
working
on.
C
So
I
find
that
why
it's
kind
of
useful-
it's
probably
I
guess
it's
not
like
useful
on
the
big
project
thing
like.
Why
are
we
migrating
kubernetes
like
yes,
absolutely
people
can
just
read
that.
I
think
it's
useful
for
know
why
we're
doing
a
specific
task
so,
like
I
think
I
guess
I'm
thinking
about
this
more
at
a
task
level.
So,
for
example,
your
case
like
discovery
like
investigating,
buffering
or
you
know
like
investigating
nginx
configuration
like
that's
a
perfectly
reasonable
status,
but
it
doesn't
give
people
too
much.
So
I
think
the.
C
C
C
Are
there
anything
from
from
your
side,
so
this
status
also
might
be
useful
for
kind
of
keeping
in
touch
with
other
things
inside
the
team.
Like
is
there
anything
on
here
that
is
like,
I
guess,
is
there
anything
else
you'd
like
to
see
on
a
status.
E
F
Answer
it,
I
think
that
I
guess
if
we
need
to
fit
this
into
the
weekly
status,
update,
sas
meeting
and
things
that
needs
to
be
short
right.
It
can't
be
very
long
so
yeah.
C
You
can
write
as
much
as
you
like.
Actually
so
the
sas
weekly
has
actually
become
interesting
in
that
it's
we
don't
need
this
section.
So
actually
like
you
can
you
can
I
mean
if
it's
really
long,
if
you
write
a
simple
essay,
then
yeah
I'll,
probably
edit
it
down
a
little,
but
like
don't
feel
too,
like
a
like
a
chunky,
paragraph
sculpture,.
F
F
C
F
Concrete
proposal
for
how
to
do
this
best,
but
just
thinking
that
we
can
maybe,
if
we
find
other
things
to
standardize
here
and
maybe
for
automation,
we
should
maybe
have
some
special
starting
and
beginning
sections,
maybe
as
a
comment
to
make
it
easier
to
pass
out
or
something
like
that.
I
don't
know.
C
We
possibly
could
like
generally
the
I'll
check
in
on
that
one
I
was
gonna.
Just
rachel
has
a
script
that
she
uses.
She
has
hers
running
on
ci
and
it
updates
every
hour
or
something.
So
then
you
also
get
a
bit
more
freedom
about
when
you
do
so
I'll
check
in
on
her
script
generally,
I
think
it's
just
looking
for
status
and
then
it
just
pulls
that
chunk
so,
but
I
can
double
check
that
yeah.
C
Are
there
any
concerns
about
doing
this?
Anyone
feel
like
this
is
adding
too
much.
E
Well,
I'm
well,
I
had
this
conversation
when
we
were
starting
doing
this
right,
so
it's
kind
of
shifting
things
from
you
to
us.
So
it's
kind
I
mean
every
one
of
us
has
less
things
to
follow
up,
so
I
mean
it's
perfectly
fine
and
it
also
may
help
creating
a
clear
review
on
the
epic
issue
so
down
below
what
I
don't
like,
and
so
because
none
of
my
epic
follows
this.
E
E
I
I
don't
like
it
so
I
mean
because
you're
going
to
use
an
automation.
I
think
that
I
would
probably
use
an
authorization
as
well
to
do
kind
of
the
opposite,
so
I've
write
my
status
as
a
command
so
that
I
have
my
linear
version
of
it
and
this
will
replace
with
the
the
status
in
the.
So
we
just
select
the
last
one
and
replace
it
in
the
in
the
description,
because
I
obviously
I
I
was
testing
two
different
way
of
doing
this.
E
One
was
manually
adding
status
with
date
every
time,
so
you
get
you
have
this
journal
of
status
and
the
other
one
was
using
this
kodo
when
I
was
just
adding
status
and
so
letting
this
go
to
summary,
using
the
summary
features
to
bring
it
up.
So
I
could
write
more
in
my
message
and
then
just
select
which
point
I
wanted
to
outline
above
I
mean,
then
I
don't
know
how
how
many
people
read
those
things.
So
maybe
it's
it's
fine
to
just
have
the
short
version
and
replace
it
every
time.
E
C
F
I
think
in
those
cases
I'm
mostly
really
start
reading
the
comments
in
the
epic
which
I
would
think
would
track
what
happened
right
and
why-
and
I
think,
maybe
really
in
this
in
the
description
as
a
summary,
maybe
really
you
should
have
the
short
version
version
of
it.
I
don't
know
it
could
be
a
lot
of
content
after
a
while
right
I
mean
having
a
nice
summary
of
of
how
things
changed
could
be
nice
there.
But
anyway,
if
you
really
need
to
understand
what's
happening
there,
you
need
to
leave
the
comments
section
anyway
right.
E
C
C
Places-
let's
continue
to
iterate
on
this,
like
so,
I
think
as
much
as
we
can
like,
let's
standardize,
but
I'm
also
like
very
like
if
we
want
to
kind
of
keep
a
if
we,
if
you
think
it's
useful
to
have
this
like
as
a
timeline,
I
think
the
comments
work
best
to
keep
the
timeline,
because
you
get
all
the
extra
stuff
and
you
can
share
it
more
easily.
G
We
can
probably
have
two
sections:
we
can
have
the
status
that
represents
the
lat,
the
last
status,
the
current
one
and
the
development
law
or
timeline
that
states
how
it
has
evolved
across
time.
It
is
it
shouldn't,
be
that
long,
just
a
summary
of
what
has
happened.
E
If
I
can
just
if
I
just
write
a
comment
in
the
epics
with
status
date
and
then
my
status
and
then
I
have
something
to
just
pull
it
up
on
top
replacing
the
with
just
the
latest
one,
and
so
you
can
still
read
the
timeline,
but
I
don't
have
because
if
ever,
if
I
have
to
section
in
the
epics
dinner
every
week,
I
have
to
remember
to
okay.
This
was
last
one.
E
C
F
Do
we
do
we
have
some
product
feature
where
you
can?
You
know
in
a
comment
put
in
a
slash
command,
saying,
update
description
or
something
like
that?
I
mean
that
would
be
a
cool
feature
for
exactly
this
case.
Right
like
I
want
to
commend
here,
but
I
want
to
get
this
edit
or
replacing
some
place
in
the
description.
C
Yeah
yeah
cool,
okay.
Well,
for
now,
let's
put
a
standardized
thing
on
it,
but
I'm
very
happy
to
like
keep
chatting
about
how
we
how
we
track
this
over
time.
So
we
don't
lose
the
efforts
put
in
so
cool
myra.
G
Yep
thanks
so
probably
most
of
you
already
know,
but
we
now
trigger
individual
deployments
for
each
of
our
environments
and
those
are
coordinated
by
release
tools.
So
just
this
is
more
like
an
announcement.
I
don't
know
if
anyone
has
questions
comments,
complaints
about
this.
C
Great
work,
I
think
it's
exciting
to
see
it
say
that
one
question
I
had.
I
don't
know
if
it
was
just
when
so
last
week
when
we,
when
I
had
that
when
I
saw
that
pipeline
coming
through
with
the
bug
I
wanted
to
cancel
the
deployment
do,
do
you
still
have
to
do
this
into
player?
Or
do
you
do
this
in
release
tools?
If
I
wanted
to
cancel,
say
a
pipeline
kicks
off,
and
I
know
I
don't
want
it
to
deploy
to
canary.
How
do
I
cancel
that
yeah?
D
G
Nice
awesome,
so
I
also
have
the
next
point-
and
I
just
wanted
to
bring
everyone's
attention
to
this
merch
request
that
is
setting
some
sort
of
proposal
for
security,
merch
requests
for
feature
flags,
and
I
think
these
proposals,
this
proposal,
introduces
more
questions
and
problems
than
solutions.
So
particularly,
I
don't
enjoy
it
because
it
allows
self-hosted
instances
to
opt
out
of
security
fixes.
G
There
is
no
clear
indication
of
what
we
should
do
about
backboards.
Should
the
backboards
also
have
a
feature
flag,
should
they
don
if
they
have
the
feature
flag
when
the
feature
flap
is
going
to
be
removed
and
the
next
security
release
on
the
next
batch
release,
and
also
if
a
security,
merch
request
is
deployed
to
gitlab.com
and
the
feature
flag
is
enabled,
and
this
one
doesn't
solve
the
security
vulnerability.
G
C
I
agree,
I'm
interested
that
this
proposal
has
come
from
security.
However,
so
I
think
I
will
have
to
have
spend
a
bit
more
time.
Thinking
about
it,
but
I
guess
from
our
side
we
should
probably
focus
on.
Is
it
going
to
make
our
job
harder
like?
How
does
it
impact
release
management?
G
I
think
they
are,
I
don't
think
they
are
considering
the
whole
release
implication
and
the
whole
process
changes
that
it
means
for
us,
because
they
are
not
really
sure.
Okay,
I
ask:
what
should
we
do
if
the
security
vulnerability
is
not
fixed
and
they
have
an
answer,
and
I
also
they
don't
outline?
What
should
we
do
about
backboards?
G
Should
they
also
include
the
feature
flash?
I
think
they
are
more
focusing
on
trying
to
include
a
feature
flag
in
a
safe
way
from
a
security
perspective,
but
they
are
not
considering
the
release
perspective
on
this
process.
C
C
If
we
don't
go
too
far
forwards
with
this
like
if
it,
if
you
don't
feel
like
they're
paying
enough
attention,
please
just
schedule
a
sink,
and
then
we
can
talk
through
like
what
might
be
involved
there.
E
So
I
mean
in
the
interest
of
time-
and
I
kind
of
understand
why
they
want
to
do
this,
because
maybe
that
specific
problem
doesn't
apply
to
their
configuration,
but
it
will
come,
but
the
fix
will
completely
break
their
workflow.
They
say
yeah.
We
are
not
suffering
the
security
risk,
so
we
we
are
not
going
to
accept
this.
I
kind
of
understand
why
it's
kind,
the
question:
the
fact
that
they
can't
answer
your
question
is
it
tells
you
that
I
mean
even
without
feature
flag?
They
don't.
E
They
can't
answer
that
question,
because
what
if
we
without
a
fission
flag,
merge
something
that
is
supposed
to
fix
the
security
issue
and
is
not
every
time
it
happened
and
every
time
it
happened,
we
had
to
deal
with
consequences
of
each
choice
so
either
delay.
Don't
delay,
let
the
information
out.
So
it's
it's.
It's
a
process
around
this
that
is
kind
of
tricky,
and
so
this
is
not
specific
to
introducing
the
feature
flags
or
not.
Yes,
but
I'm
concerned
by
the
fact
that
someone
with
database
access
could
let's
say,
disable
a
security
fix.
E
Maybe
you
have
a
remote
code
execution
and
then
you
just
need
database
access
to
disable
it
yeah.
I
mean
it's
good.
You
can
still
serve
yourself
into
enabling
feature
enabling
security
vulnerability,
which
is
kind
of
dangerous.
C
If
we
should
make
sure
before
this
gets
merged,
if
it
assume
it
gets
merged
that
we
have
a
clear
agreement
on
what
we're
going
to
do
with
back
ports,
like
you
know
like
we
can't
just
change
our
process
afterwards,
like
we'll
need
to
agree.
Security
is
taking
on
responsibility
for
checking
these
things
or
making
sure
this
stuff's
okay
and
we
will
be
coordinating
the
deployment
so
at
the
release.
C
I'll
add
a
comment
on
that,
though
cool
thanks
for
bringing
that
amira.
That's
good!
I'm
going
to
hand
over
host
responsibilities
because
I'm
going
to
drop
on
the
out
on
our
half
past
search
mentioned
that
you
can
all
keep
going
of
course
jav
over
to
you,
though,.
A
Oh
yeah,
just
a
quick
about
the
setting
feature
flags
during
deployments.
If,
if
we're
all
okay,
I
guess
amy,
maybe
this
is
maybe
you're
the
last
person
to
act
this.
It
sounds
like
we're
generally,
okay
with
this,
but
if
anyone
objects,
can
you
just
add
it
to
the
issue?
I'm
happy
to
make
this
change.
I
also
added
a
comment
under
the
single
or
the
the
new
pipeline
thing
letter
c.
If
someone
has
an
answer,
just
you
can
comment
underneath
the
in
the
doc.
C
Cool
thanks
I'll
I'll
have
a
read
through
and
add
a
comment
on
those
things
thanks
so.
A
Like
as
our
gitlab
ci
gets
more
complicated,
it
seems
like
we're
using
jsonnet
in
other
projects
to
generate
ci
config,
and
it
might
be
nice
to
standardize
early
for
that.
If,
if
we're
at
the
point,
where
we're
at
least
full
ci,
as
I
imagine
it's
getting
more
complicated
as
we
move
like
deploy
our
functionality
into
release
tools
right,
it's
just
a
thought.
I
don't
know
like.
Maybe
something
to
consider.
E
A
A
E
E
Like
that,
you
can
do
the
same
thing
on
production,
canary
or
things
like
that,
and
because
we
also
have
more
code
available
and
less
pipeline
code,
it's
kind
of
easier
to
handle
differences
in
ruby
instead
of
having
the
explosion
of
ci
options.