►
From YouTube: 2022-11-16 Delivery team weekly APAC/EMEA
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
Run
this
is
November
16th,
APAC,
emea,
timed
delivery,
weekly.
So
there's
a
few
announcements
which
I'll,
let
you
mostly
read
through
one
I've,
just
added
on
as
I
mention
is
1B,
so
just
as
a
kind
of
like
FYI,
it
is
US
Thanksgiving
next
week,
so
I
expect
things
will
be
quiet
at
the
moment.
A
I
don't
believe
there
are
any
pcl's
planned
that
could
change,
but
I
think
for
now
it
won't,
but
just
as
a
you
know,
if
you
are
going
to
need,
other
people
expect
that
if
they're
us-based,
they
may
not
be
around
late
next
week,
cool
and
then
on
discussion,
points
I
wanted
to
just
I
was
thinking
as
sort
of
like
what
we
could
use
this
time
for
usefully
and
actually
I
realized,
like
I,
think
the
last
few
weeks
months
this
these
both
the
delivery
weekly
meetings
have
become
quite
updated,
but
actually
what
they're
super
useful
for
is?
A
So
you
know,
do
feel
free
to
take
advantage
and
the
agenda
is
open,
so
feel
free
to
just
like
take
a
control
of
it,
and
if
there's
something
that
you
want
to
get
people's
thoughts
on
or
discuss
or
raise
up,
then
you
know
this
is
this
is
absolutely
the
meeting
for
that
for
today
is
there
actually
anything
anyone
has
on
their
mind
around
kind
of
like
a
technical
concern
or
idea
or
something
that
we
should
all
kind
of
be
we
might
be
interested
in
or
some
people
might
be
interested
or
that's,
something
which
we
should
be
actually
starting
to
chat
more
about
before
before
next
year.
A
B
So,
just
today
morning,
I
was
wondering
why
we
have
Auto
deploy
tag
and
auto
deploy,
prepare
as
two
parallel
processes.
Sort
of
you
know,
serial
jobs
that
run
independent
of
each
other.
It
might
have
made
sense
in
the
past,
but
now.
B
Maybe
now
we
can
sort
of
combine
the
two
like,
for
example,
we
only
actually
need
to
tag
after
two
possible
events.
One
is
the
creation
of
a
new
auto
deployment
branch.
Actually,
three
I
guess:
creation
of
water
deploy
Branch
picking
of
a
commit
into
an
existing
audit.
Club
branch-
oh
yeah,
that's
two:
two
events
so
ends
of
just
running
tag.
Every
30
minutes
we
could
I
have
like
two
specific
processes,
one
to
prepare,
Auto
Branch
and
then
tag
in
the
same
scheduled
job
and
another
to
pick
commits
and
tag
in
the
same
schedule.
C
It's
even
worse
than
this
I've
lost
track
of
how
many
time
I
was
arguing
with
Yorick
about
this
implementation.
So
to
be
fair,
it
made
sense
in
the
past
because
think
about
this.
We
were
preparing
branches
once
a
week.
When
all
of
this
started,
we
were
preparing
Branch
once
a
week
and
deploying
two
or
three
times
a
week.
So
this
is
where
all
it
started,
so
it
definitely
made
sense
there
things
changed,
and
this
is
just
a
major
source
of
problem
because
of
timing,
so
I
I
think
that
I
wrote.
C
Somewhere
I
should
have
also
a
timeline
example
of
how
things
can
go
wrong.
If
you
get
the
wrong
timing
in
creating
tagging
and
peaking
up
to
the
point
that
you're
losing
stuff,
so
it's
it's
a
mess.
We
could
just
use
a
simple
schedule
that
is
just
checking
all
the
requirements.
So
do
I
need
to
create
a
new
Branch.
Yes,
no,
if
so,
do
do,
I
need
to
pick
stuff
into
this
Branch.
Yes,
no,
if
so
pick
now
should
I
tag,
yes,
no
yeah
and
so
and
with
a
single
one,
just
find
what
is
needed.
C
I
will
not
spend
much
time
in
optimizing
for
the
peaking,
because
I
don't
think
it's
worth
continuing
on
the
peak
in
tour
to
deploy.
So
especially
now
that
we
are
going
to
remove
the
peak
into
stable.
We
should
think
about
next
step,
removing
also
the
big
into
Auto,
deploy
because.
C
It's
a
perfect
example
for
another
thing:
you
were
mentioning
before
Amy,
so
yeah,
very
simple
thing:
we
are
extending
the
patch
policies
from
one
version
to
three
like
the
security
release
and
in
order
to
scale
the
process.
We
are
redesigning
this
so
that
we
trying
a
very
high
level.
We
are
trying
to
go
for
something
that
is
similar
to
Auto
Deploy
on
stable
branches,
so
that
when
something
is
ready,
it
got
merged.
So
there's
no
picking
tool.
C
You
could
prepare
the
merge
request,
you
get
it
reviewed
and
you
get
it
merged
by
a
maintainer.
Then
delivery
gets
into
this
after
the
merge
right.
So
we
have
a
change
in
the
stable
branch,
which
means
we
can
prepare
a
package
and
deploy
this
to
some
QA
environments
related
to
that
stable
branch.
And
so
the
idea
is
that
the
development
of
the
fix
it
became
a
development
problem.
C
Then
we
take
care
of
the
stable
branches
and
there's
QA
and
everything.
And
then
basically
we
are
splitting
preparing
the
release
from
tagging
the
release.
So
when
we
want
to
do
a
release,
we're
just
tagging,
something
that
is
already
there
and
it
is
known
to
be
working,
that's
the
basic
idea.
So,
with
this
in
mind,
the
next
logical
step
is:
let's
remove,
also
big
into
also
deploy
as
it
it's
easier
to
create
a
new
house
deploy,
branch
and
and
tag
I.
A
Have
set
up
employee
pick
label
right,
so
the
pick
label
I
think
it
has
a
use
which
is
kind
of
a
indicator
for
somebody
outside
of
delivery
to
kind
of
flag.
This
is
a
an
urgent
Mr
that
requires
a
little
bit
of
extra
attention
right
like
that.
It
maybe
needs
to
go
in
the
next
package
or
it
we
need
to
make
sure
it
lands
in
a
package.
A
A
Hey
release
managers
take
care
with
this
Mr
and
most
likely
it
will
just
land
in
the
next
Auto
deploy
package,
and
we
need
to
do
nothing,
but
also
we
would
have
that
visibility,
because
what
that
means
is
it
wouldn't
change
a
developer
workflow.
They
still
have
a
way,
but
it
also
wouldn't
be
generating
packages
for
us.
So.
C
First
thing:
you
can
subscribe
to
labels
and
receive
email
every
time
that
label
is
used,
I
think
so
I
know
you
can
subscribe,
I,
don't
remember
which
type
of
email
you
receive.
In
theory,
you
get
every
message.
A
A
C
I
was
thinking
more
in
terms
of
how
can
we
why
we
are
using
big
labels
right
so
we're
using
big
labels
to
say
this
thing
should
be
in
the
next
package.
That's.
B
B
C
I
would
say
something
we
were
discussing
a
long
time
ago
was
the
the
introduction
of
the
minimum
Sha
of
the
next
package,
which
means
that
so
right
now
we
have
this
implicit,
which
is
a
prevention
from
rollback
right.
So
because
we
had
issue
in
the
past,
when
we
were
tagging
stuff,
because
the
pipeline
changed
from
red
to
from
green
to
Red,
then
the
next
speaker
was
going
back
and
finding
a
commit
that
was
pre
prior
to
the
last
known
package.
And
so
the
idea
was
that
we
should.
C
We
could
build
on
top
of
that
and
having
the
concept
of
we
are
not
going
to
deploy
unless
this
is
included,
which
basically
means,
when
you
run
the
prepare
you're,
not
creating
the
autoplay
branches,
unless
it
includes
the
thing
that
you
need
and
and
top
on
top
of
that
right.
So
you,
basically,
if
you
don't
set
this,
it
is
just
gonna,
be
the
previous
package.
So
you
don't
want
to
build
something
that
is
older
than
the
no
than
the
previous
package
that
you
have
deployed
have
built.
C
But
you
can
build
on
top
of
that
and
say
now.
I
have
a
stronger
requirement,
which
is
there
is
this
problem.
It
makes
everything
that
does
not
include
this
merge
commit
will
still
fail
QA.
So
it's
just
a
waste
of
time.
C
And
the
idea
is
that
this
should
save
time
in
terms
of
Pipelines,
because
when
you
pick,
then
you
have
to
run
the
pipeline
again
and
in
this
idea
is
more
about
when
we
create
a
the
auto
reply,
branches
which
guess
what
now
is
no
longer
needed.
If
you
don't
pick,
you
don't
need
to
multiply
branches,
but
that's
not
sorry.
Basically,
the
first
run
is
the
one
that
you
already
have
on
the
master
branch.
C
So
we
all,
if
even
when
we
create
the
up
Supply
branches,
a
new
pipeline
starts
because
this
is
how
it's
designed
it
creates
new
branches.
So
it
creates
a
new
pipeline.
But
there
is
a
logic
which
said
if
that
pipeline
is
running
and
is
the
one
on
the
stable
Branch,
but
we
already
have
a
pipeline
that
is
green
on
master,
because
this
is
the
merge
base
of
where
we
split
the
branch
we
consider
this
green,
and
so
this
should
speed
up
things
quite
a
lot.
B
C
A
Mean
we
certainly
I
I.
We
certainly
could
create
issues
I
guess
like
certainly
in
orchestration
we
haven't,
we
haven't
prioritized
it
just
simply
because
it's
not
our
it's,
not
our
orchestration's
biggest
problem
right
now.
It's
definitely
something
which
I
wouldn't
be
unhappy
to
see
happen,
but
it's
not
it's
not
orchestration.
It's
okay,
I'll
for
sure
this
culture.
Unfortunately,.
A
Didn't
say
it
is.
It
is
an
interesting
trade-off
right,
because
I
think
this
pick
label
does
create
work
for
release
managers,
so
it
is
a
little
bit
of
a
trade-off
I
wonder
if
it's,
if
it's
a
good
one
for
you
know
as
release
managers,
make
improvements
the
process
I
wonder
if
we
could
get
the
issues
to
be
small
enough
that
they,
you
know,
a
release
manager
could
be
iterating
towards
it.
Based
like
around
release
work,
that's.
B
What
I
was
thinking
yeah
and
sorry
if
anyone
has
anything
else
about
this
different
on
a
very
related
topic,
the
other
thing
I
think
we
can
remove.
Is
the
tag
latest
feature
flag,
so
we
use
the
tag
latest
feature
flag
when
we
want
to
tag
something
without
waiting
for
the
pipeline
to
turn
green,
but
the
problem
is
usually
when
we
want
to
do
that.
B
We
have
a
specific
commit
in
mind,
but
again
here,
you're
playing
timing
games
where,
by
the
time
you
turn
off
the
feature
flag
and
go
around
the
prepare
job
or
on
the
tag
job.
Another
comment
might
have
been
added
and
that
one
gets
you
know
picked
into
Auto,
deploy
or
tagged
or
whatever.
B
So,
instead
of
having
that
flag
and
then
having
to
run
the
schedule
job,
we
could
instead
have
something
that
allows
us
to
like
tell
our
tooling
create
a
branch
from
this
commit
or
tag
this
commit,
regardless
of
whether
the
pipeline
is
green
or
not.
So
you
don't
have
that
feature
flag.
You
don't
have
to
remember
to
turn
it
off
afterwards,
which
we've
forgotten
a
few
times
so
I.
C
C
Is
this
is
good
as
well
and
I
think
that
if
we
removed
the
idea
of
creating
the
branch,
this
could
be
a
very
simple
chatops
command
when
you
say,
because
we
already
have
the
command
to
tag
right
and
we
can
add
a
parameter
which
say
tag
and
you
give
the
Sha,
which
you're
basically
saying
only
check
that
I'm
not
rolling
back
something
like
this.
So
we
can
just
simplify
the
checks
and
say
that's
the
thing
right.
Trust
me:
I'm
the
release
manager
I'm,
making
the
call
here
create
a
package
from
this.
C
C
Thanks,
no,
we
don't
because
the
thing
that
we
were
back
then
discussing
is
that
basically
we
have
a
variable
that
is
that
contains
the
current
Auto
deploy
branch
and
when
we
run
the
prepare,
we
are
changing
that
CI
variable.
So
when
we
tag
we
don't
we
just
read
the
variable
right.
So
what
we
were
discussing
with,
maybe
we
would
help
some
feature
flag.
We
can
test
the
idea
of
having
master
in
in
that
variable,
not
bumping
the
so
it
will
not
generate
the
neo2
deploy.
C
Branch
will
just
work
always
from
master,
and
then
this
will
attack
from
master
and
then
this
extension
right
when
you
say
I
want
to
tag
this.
So
it
should.
C
It
looks
complex
because
there
are
many
ramifications
of
this,
but
it's
just
a
very.
We
are
simplifying
a
lot
the
process,
so
it
probably
should
be
easier
to
just
set
some
feature
flag
and
cut
some
boundaries
in
the
code.
When
you
say
you
can
stop
here,
don't
have
to
do
all
the
extra
stuff
and
it
should
work
and
I
mean
because
the
first
thing
is
still
generating
a
package.
C
I
think
we
have
room
for
test
and
Improvement
right,
because
it
works
well,
as
as
Amy
pointed
out
as
a
kind
of
release
manager
I
want
to
say
experiment
because
they
are
in
control
of
what
is
happening.
So
if
they
can
say
I
have
time
today
and
now,
I
feel
that
I
can
try
to
build
a
package
from
Master,
Tag
and
auto,
deploy
tag,
I'll
Supply
from
master
and
see
how
it
goes
because
I
have
time.
I
can
I
can
take
a
look
of
the
pipeline.
A
Awesome
great
thanks
for
the
discussion.
Thanks
for
the
question
Reuben
like
super
super
great
on
thoughts
and
as
we've
discovered
with
the
maintenance
policy
thing,
that's
actually
what
actually
I
think
these
delivery
week
leads
are
going
to
be.
They
are
most
useful
thing
for
us,
so
we
can
share
those
ideas
and
stuff
awesome.
A
So,
in
the
interest
of
time,
let's
move
on
so
release
manager,
review,
stuff.
I
know
we
went
through
on
Monday,
so
we
don't
need
to
cover
that
again.
Unless
actually,
unless
there's
anything
extra,
you
do
want
to
highlight
Reuben.
B
No
I
don't
think
so.
Awesome.
A
One
thing
I
just
mentioned:
we
talked
about
it
about
on
Monday,
but
would
I
be
able
to
just
leave
the
action
with
you
Reuben
to
get
the
change
requests
added
onto
the
deployment
blockers.
A
A
Great
is
there
anything
anyone
else
wants
to
bring
up
on
this
recording.