►
From YouTube: 2021 06 23 EMEA Sharding Group 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).
B
C
C
I,
like
we
were
asked
through
craig,
to
develop
a
plan
to
deliver
a
decomposed
ci
implementation
by
the
end
of
october
within
48
hours.
We
had
a
discussion
about
it.
I
think
the
in
essence,
I
think
the
answer
is,
is
this
is
not
feasible?
It
is,
I
think,
the
reality
is.
We
have
like
sort
of
three
dimensions
that
we
can
work
with
right.
C
We
have
scope
quality
and
time
right
and
we,
I
don't
think
we
are
in
a
position
where
we
can
significantly
decrease
scope
if
we
want
to
decompose
the
ci
tables
really,
maybe
on
some
instance.
If
we
are
going
to
reduce
time
even
further,
I
think
the
main
thing
that
will
happen
is
it
gets.
It
would
affect
quality
and
given
the
risk
associated
with
this
quality
means
something
is
going
to
go
wrong
and
I
don't
think
that's
necessarily
acceptable.
C
Also,
after
doing
a
little
bit
of
sort
of
comms
and
trying
to
figure
out
where
this
request
came
from,
my
impression
is
that
this
is
driven
by
a
perception
that,
by
october
1st,
the
database
is
going
to
fall
over
and
based
on
that
estimate.
Obviously,
in
october
timeline
for
delivering
stuff
makes
sense,
but
I
think
there
are
a
couple
of
things
that
I
would
like
to
highlight.
Based
on
my
current
understanding.
C
First,
one
is
based
on
the
latest
estimates
from
from
andrew
the
october
date
does
not
hold
we're,
not,
I
think,
going
to
topple
over
at
that
point.
The
second
thing
is
that,
and
I
think
this
is
maybe
where
things
also
are
a
little
bit
confusing.
C
Also,
for
me,
the
ci
decomposition
work
is
one
dimension
of
the
work
that
we
need
to
do
to
increase
database
scalability,
and
there
are
other
things
ongoing
that
already
do
this,
so
they
they
have,
I
think
different
impact
and
different
timelines
associated
with
them,
and
so
we
should
be
this
sort
of
a
suggestion
that
I
have
maybe
to
help
with
the
visibility
of
of
this
right
is
to
say,
like
we
understand,
database
capacity
is
a
problem
right.
This
is
you
know
in
this.
C
Tamland
estimate
is
sort
of
the
best
estimate
that
I'm
aware
of
right-
and
here
are
all
of
the
like
things
that
are
happening
to
address
the
key
concerns
in
that
document,
and
this
is
not
only
going
to
be
ci
decomposition,
but
it
is
also
going
to
be
other
things
right,
like
we
are
doing
the
primary
key
overflow
mitigation.
We
are
thinking
about
petitioning
you
know,
like
yorick,
has
deploted
things
right,
so
there's
a
lot
of
things
that
are
going
on.
A
Okay,
no
it's
my
turn.
Let
me
share
all
I
know
so.
The
date
october
1st
is
mentioned
in
dot
com
stand
up.
I
think
there
was
a
slack
channel
us
like
a
conversation.
Jerry
mentioned
that
he
will
attend.
The
stand
up
today,
explain
that
this
date
no
longer
holds
so
that
date
is
from
there,
so
the
leaders
were
doing
backwards
from
that
date.
A
I
don't
know
why
I
just
want
to
be
honest.
I
don't
know
why
with
all
the
data,
but
we
haven't
updated
the
leaders
about
the
latest
data,
so
it's
we'll
see
how
that
works.
But,
to
be
honest
I
don't
know
why,
but
as
you
see
that
the
infrastructure
team
actually
is
working
on
something
similar,
if
you
or
you
follow
the
stand
up,
steve
has
some
items
to
work
on
a
plan
for
the
scenario.
What
if
we
see
a
10x
or
even
more
load
increase
on
the
system?
A
A
Playing
here
could
be
some
factor,
that's
playing
some
decision
making.
Here
I
don't
know
I
can.
I
just
have
no
way
to
verify
that,
so
that
could
be
something
impacting
this
decision,
and
I
do
understand
all
the
reasons
here.
Camille
and
everybody
shared
that
you
know
a
lot
of
points.
I
I
understand
that
too.
So
this
is
all
the
background
I
have.
A
So
I
think
what
the
best
we
can
do
is
basically
my
two
questions:
would
more
people
have
what
kind
of
people
we
need,
but
that
depends
on
how
much
work
can
be
parallelized
and
how
much
work
we
already
know.
So.
Can
we
already
explain
it
very
well?
We
shall
bring
this
back
to
the
standard,
probably
or
in
the
in
the
working
group
meeting.
We
shall
present
all
this
information
there
to
make
sure
that
everybody
is
on
the
same
page
and
also
is
there
any
opportunity
to
trim
down
the
first
day
iteration.
D
Like
we
are
the
most
iterative,
as
we
can
be
on
this
subject,
if
we
trim
down
more
iterations,
not
gonna
have
the
benefits
that
we
described
so
and
what
is
the
purpose
of
even
doing
that
in
the
first
place,
if
it
doesn't
bring
any
benefits
and
we
ship
something
that
either
increases
technical
depth
or
increases
complexity,
but
doesn't
help
with
anything
so
unlikely
like?
We
are
like
looking
at
the
time
frame
right
now
in
the
three
or
four
months
from
now
to
finish
the
development
aspect.
D
What
can
happen
like
you're,
not
gonna,
be
able
to
roll
out
that,
because
rolling
out
production
changes
take
a
look
at
the
pg-12,
something
that
was,
I
guess,
probably
different,
but
maybe
of
the
similar
complexity.
How
long
it
took,
and
we
actually
had
a
lot
of
control
over
that
and
running
out
like
like
reaping
the
benefits
like
it's
not
gonna
happen
in
october,
because
we
may
be
able
to
finish
all
the
developments
and
just
by
that
then.
D
But
then
it's
like
the
whole
process
of
the
rolling
code,
which
kind
of
released
with
these
own
like
rollout,
changes
and
and
aspects
that
like
we
don't
want
to
break
guitar
because
it
will
be
even
worse
than
not
rolling
out
in
the
first
place
and
rushing
that.
So
I
think
my
answer
is
no
sorry,
I'm
not
sure
if
everyone
agrees
with
that,
but
I
think
my
answer
is
no.
It's
not
really
like
that.
D
We
are.
We
also
don't
have
even
yet
assign
sre
at
this
point,
and
this
is
something
that
we
are
waiting
for.
So
I
I
think
it's
impossible
for
having
this
rollout
because
of
like
all
the
constraints
that
are
beyond
our
control.
At
that
point,.
A
Yeah,
sorry,
so
what
I'm
thinking
right
now
I
get
a
very
clear
answer
from
the
team.
So
what
I'm
thinking
right
now
is
to
develop
two
plans
to
present.
One
is,
of
course
we
do
everything
we
can
to
achieve
the
october
goals.
What
do
we
need
and
what
do
we
need
and
the
other
players
you
know
whatever
we
do
is
impossible,
then
draw
a
plan
with
more
granular
date,
not
the
course
not
as
close
as
a
quarterly,
but
let's
say
which
months
we
can
achieve
a
first
deployment
and
to
realize
some
headroom
day.
D
D
I
think
like
if,
if,
if
we
are
working
on
that,
we
should
have
the
a
set
of
alternative
aspects
to
increase
the
headroom
to
actually
be
able
to
execute
that
in
its
own
time
frame.
I'm
just
not
saying
that
happening.
C
C
And
I
think
I
think
my
understanding
is,
the
concern
is
coming
from
the
fact
that
there
is,
you
know
like
a
risk
that
by
october
the
the
database
is
going
to
fall
over
and
if
I
am
not
wrong,
you
know
based
on
what
I've
read
in
the
in
the
documents
as
they
are
available.
This
is
not
true
based
on
the
data
that
we
have
and
you're
right.
Do
you
agree
or
do
you
disagree?
You
shake
your
head
substitute.
C
No-
and
I
think
this
is
like
for
me
if
there
is
no
like
risk
of
falling
over
in
october,
but
there
is
generally
a
risk
of
you
know
like
scalability
concerns.
You
know,
I
think
maybe
the
conversation
does
not
need
to
be.
Why
can't
you
deliver
ci
decomposition
by
october,
but
the
conversation
should
be
okay.
How
long
you
know
like
what
is
the
latest
projection,
given
the
data
right
and
what
are
the
different
things
we
are
doing
to
address
them
because
they
have
different
time
horizons
right.
C
So,
for
example,
craig
and
janice
need
to
keep
me
honest
here
within
the
next
two
months.
We
are
we're
going
to
have
mitigations
for
the
primary
key
overflow
risk,
which
is
identified
as
the
highest
risk
for
our
scalability
issue.
Right
now,
that's
gone.
That
has
nothing
to
do
with
ci
decomposition
and
so
there's,
maybe
another
list
of
things
that
are
either
ongoing
or
that
where
we
need
to
define
when
they
will
start
and
how
long
they
will
take.
And
then
it's
actually
sort
of
a
multi
like
multiple
things
are
happening
in
parallel
and
ci.
C
A
I
raised
my
hand
I
want
to
interrupt
you.
I
think
one
thing
I
just
want
to
share
it's
unfortunate
for
all
the
information.
To
my
best
knowledge
I
got
this
october
call
is
unrelated
to
where
the
tipping
point
is
I'm
I'm.
Just
being
blunt,
I
don't
know
why.
A
I
think
some
information
was
already
passed,
say
the
tipping
point
right
now,
even
given,
given
what
we
are
doing,
like
you
said
all
the
things
we're
doing
and
the
timeline
projection
is
roughly
towards
the
end
of
the
year.
So
we
have
two
more
rounds
at
least,
but
the
decision
was
still
shooting
for
october.
C
B
Think
we
we
definitely
need
more
context.
I
I
get
yeah
okay,
then
yeah
I
get
when
upper
management
wants
to
challenge
a
team,
and
you
know
challenge
their
assumptions
and
see
if
we
can
get
some
more
out
of
this
any
kind
of
goal
that
you
set
up
right.
But
what
what
I'm
reading
through
this
thread?
And
the
slack
thread
is
no,
we
can't
meet
the
october
time
frame,
even
if
we
had
you
know,
none
of
the
constraints
that
we
had
now
like
and
the
biggest
constraint
I'm
thinking
of
is
sre.
B
B
We
need
more
context
from
eric
as
to
why,
as
we
explain
like
here's,
what
we
can
get
in
october,
but
it's
not
realizing
the
headroom
that
you're
looking
for,
but
in
parallel
we're
getting
all
of
this
other
headroom
with
all
the
things
that
are
listed
in
that
spreadsheet,
yeah
and
just
understand
what
he's
concerned
about
my
conjecture
on
this
is
there's
still
some
concern
that
well,
yes,
we're
not
gonna
tip
over
in
october.
B
We
may
be
at
a
point
where
it's
so
bogged
down,
that
performance
starts
to
degrade
a
little
bit
and
we
still
have
three
four
months
to
go
right.
They
just
maybe
they
just
want
to
clear
this
out
and
get
that
headroom
before
it
becomes
a
problem
and
right
now
we
just
don't
have
enough
evidence
to
point
us
from.
Although
I
mean
the
early
projection,
is
we
still
have
a
year's
worth
of
runway
on
our
current
database.
B
So
I
get
why
he's
asking
or
I
get
why
it's
being
asked,
but
I
think
there
just
needs
to
be
a
conversation
there
where
we
come
back
with
this
information
and
say
yeah
october
deployment
is
not
realistic,
but
here's
what
we
can
do
in
that
time
frame
and
here
are
the
gains
that
we
will
get
out
of
it.
A
Yeah,
I
I
think
this
stand
up.
May
not.
We
don't
have
enough
time
to
discuss
there.
We
shall
assemble
a
plan
or
proposal
here
like
okay.
We
don't
think
that's
a
realistic
goal.
Here's
here's
are
the
reasons
and
we
should
schedule
a
meeting
with
with
eric
to
explain.
A
A
A
C
But
to
be
to
be
thank
you
john
for
your
transparency
here.
I
really
appreciate
it.
C
It
feels
to
me
as
if
you
know
I
like,
I
would
not
know
what
kind
of
plan
I
can
craft
that
I
can
stand
behind.
Given
the
information
that
I
have
even
with
more
time,
because
I
wouldn't
know
what
what
to
say
because
it
wouldn't
be,
it
wouldn't
be
real,
and
I
you
know
like
at
that
point
it
to
me
feels
like
that's,
not
fair
for
for
the
team
that
has
to
execute
on
that,
because
it
wouldn't
happen
right
and
then.
A
D
C
D
A
D
C
C
I
think,
like
I'm
just
wondering
if
this
is
the
right
discussion
to
have,
and
maybe
there's
some
kind
of
communication
mix
up
right
in
in
the
mix
where
assumptions
are
being
made.
That
are
not
not
quite
right,
and
you
know-
maybe
that's
the
the
first
conversation
to
have,
because
otherwise
it's
going
to
be
confusing.
A
C
I
think
I
mean
we
can
we
can.
We
can
go
full
waterfall
mode
and
that's
like
a
couple
of
months
planning
this
out
into
detail,
but
I'm
also
wondering
why
that
like.
Why
is
that
needed
at
this?
This
point:
what
is
the
the
added
benefit
of
that
we've?
We've
done
a
lot
of
this
work
and
it
has
it
has
created
overhead,
and
that
is
that's
sort
of
my
concern
with
this
right.
E
Yeah,
I
I
was
gonna
ask
well
one
thing:
first,
we
we
seem
to
be
generally
under
people.
We,
some
people
seem
to
be
under
the
assumption
that
at
some
sort
of
finite
point
in
time,
specifically
in
this
year,
magically
our
database
and
everything
is
gonna
explode
and
you
know
basically
commit
sudoku.
E
What
are
the
like?
Is
it
known?
What
we're
sort
of
the
most
worried
about?
Are
we
worried
about,
say,
cpu,
use,
storage,
everything
because,
for
example,
a
concern
is
hey
in
let's
say
october,
but
it
could
be
any
dates.
We're
going
to
run
out
of
storage,
then
we
could,
for
example,
come
up
with
a
plan
and
say
okay
or
we're
going
to
do
all
the
stuff
we
want
to
do,
but
for
october
our
goals
is
going
to
be.
E
You
know
clean
up
these
tables
etc
and
we're
going
to
save
you
know
this
much
space
and
then
based
on
the
projections
that
gives
us.
You
know
this
much
extra
time,
but
if,
for
example,
the
concern
is,
let's
say
the
number
of
rights
there
isn't
really
a
sort
of
quick
thing.
I
think
you
can
do
before
october,
because
the
sort
of
natural
process
is
there
as
well.
E
You
reduce
the
number
of
writes
or
you
make
them
less
expensive,
but
that
is
a
very
sort
of
micro,
optimization
kind
of
work
where
you
really
have
to
get
into
the
details
and
say:
okay,
you
know
we
have
this
little
bit
so
we're
going
to
do
this
here
and
then
there
you
can't
do
something
like.
Oh
we'll,
just
move
data
to
a
different
table.
D
C
This
is
the
timelines
associated
with
them.
Many
of
them
will
be
done.
Some
of
them
will
be
done
before
october.
Some
will
be
done
after
october,
but
that
is
sort
of
as
a
package
is
going
to
mitigate
these
these
risks
plus.
I
think
there
is
not
necessarily
a
concern
about
this
sort
of
explosion
within
the
next
six
to
12
months,
and
so
that's
maybe
also
a
question
it's
like.
C
D
E
You
are
still
muted,
I
got
muted,
I
don't
know
how
that
happened.
I
I
was
gonna
say
that
I
think
what
might
be
happening
here
is
that
we're,
perhaps
not
so
much
worried
that
there's
going
to
be
a
point
in
time
where
the
system
says
no
more,
I
mean
we've
had
these
thoughts
for
years
and
years
ago.
People
said:
oh,
we
need
to
do
this
because
you
know
in
this
many
weeks.
This
will
happen.
E
Basically
doomsday
never
comes,
or
at
least
never
comes
when
you
predict
it
to
put
it
that
way,
I
suspect
what
may
be
play
playing
a
role
here
is
that
there
is
a
certain
three-letter
event
coming
up
somewhere
in
the
near
future
and
that
gitlab
has
this
assumption
that
when
that
happens,
suddenly
we'll
get
10
million
extra
users
that
were
you,
know
some
sort
of
growth,
and
I
personally
believe
it's
fairly
naive,
but
I
I
don't
know
what
they're
working
on
behind
the
scenes.
B
Yeah,
it's
the
conjecture,
that's
killing
us
right,
we're
given
an
edict
without
context
and
to
pile
on
like
we,
we
were
asked
to
focus
on
the
ci
tables
instead
of
decomposing,
something
else
so
that
we
know
that
we
can
roll
things
out
right
like
we
talked
about
decomposing
the
logs
tables,
but
we
were
asked
to
focus
on
ci,
so
we
can
realize
that
headroom
so
telling.
B
The
message
I
would
give
was
we're
being
asked
to
set
a
date
and
we're
we've
cut
fixed
date,
fixed
scope
and
effectively
fix
people
based
on
the
constraints,
and
that's
always
a
recipe
for
disaster.
So
we
need
to
have
a
conversation
with
eric,
because
this
is
based
on
the
frustration
I'm
feeling
and
what
I'm
reading
in
the
room
in
the
threads
here.
This
is
just
not
productive
at
all.
To
ask
this
question.
A
I
think
we
have
heard
all
the
things
from
the
team,
but
the
the
what
the
team
presented
and
what
we
were
actually
doing
doesn't
cross
each
other.
So
what
we
were
asking
is
basically
taking
october
as
a
ending
date,
as
you
know,
as
a
as
the
end
of
the
world
date
then
trace
back
to
see
what
we
can
do
to
make
it
happen
in
october.
That's
what
we
were
asked.
So
that's
why
I'm
asking
if
more
people
helps
or
there's
an
opportunity
to
trim
down,
but
I
got
the
answers.
A
C
I
think
I
think
the
we
are
still
operating
under
the
constraint
here
that
we
want
to
do
something
that
is
reasonable
right.
It's
like,
I
can
probably
give
you
know
like
come
here,
production
access
and
we
try
to
do
it
and
you
know
it
goes
wrong
and
then
well,
you
know,
we've
taken
an
unacceptable
risk.
It's
like
you
can
always.
D
I
I
I
would
not
do
that
like
we
can
do
something
different.
It's
just.
It's
not
gonna,
give
benefits
that
we
described
so
then
the
question:
what
is
the
point
of
doing
that?
In
the
first
place
we
can
move
archived.
I
was
without
even
caring
about
migration,
probably
starting
writing
and
like
after
three
months
like
we,
our
problem
in
my
database
will
simply
go
away,
but
it
will
not
give
benefits.
D
That
was
like
the
fundamental
reason
for
doing
that
in
the
first
place
so
like
we
could
probably
mark
doing
something
useful.
That
would
be
not
useful
at
all,
but
that's
not
really
like
the
intent
of
our
work.
A
Sorry,
yeah
sorry
yeah
to
clarify
the
archive
tables
one.
We
saw
that
initial
discussion.
We
feels,
like
the
team
agreed
that
we
won't
get
much
headroom
or
from
the
archive
tables.
It's
just
a
tooling
or
paving
the
path
towards
a
good
solution.
D
B
C
I
think
we
have
all
the
points
yeah.
I
think
the
last
thing
I
want
to
do
is:
I
still
think
that,
from
sort
of
a
project
management
perspective,
even
though
we
have
zero
project
managers
present
in
this
meeting,
I
think
we
can
do
like
some
improvements
right
and
aggregate
what
is
being
done
and
present
that
in
a
maybe
more
like
rolled
up
fashion
right.
I
think
that
is
generally
helpful,
but
that
doesn't
change
what
we
discussed.
C
I
think
that
just
makes
it
maybe
a
little
bit
more
apparent
what
is
going
on
so
I'm
happy
to
help
with
this,
but
you
know
that's
a
that's
a
different,
a
different
thing
that
we
can.
We
can
maybe
do
because
the
new
thing
is,
you
know
if
we
say
like
oh
we're
doing
everything
we
can.
We
have
no
good
way
of
saying-
and
this
is
what
we're
doing,
and
I
think
that
that
may
be
a
problem,
but
that's
my
only
thing.
A
Yeah,
okay,
let
me
circle
back
a
little
bit
and
update
later
I
mean
I
will
circle
back
to
the
leader
to
see
what
they
think
about
this
or
I
I
will
present
extract
information
from
here
then
see
what
we
get.
Don't
do
anything
don't
assemble
any
plan
right
now
and
that's
overhead.
We
don't
want
to
waste
our
time.
So
wait
for
my
feedback
to
see
what
next
step
is.
I
will
make
it
very
clear
what
we
talked
to
here.
C
A
You,
if
you
need
any
help,
please
let
me
know,
thank
you
very
much,
and-
and
there
is
a
stand
up
today,
if
I
don't
know
how
much
time
we
will
have
on
that
topic,
but
if
you
can
join
the
stand
up
please
and
help
the
discussion
share
more
information.
If
I
don't
have
all
the
information
to
share
with
with
eric.