►
A
B
C
A
great
introduction,
thanks
for
that
Fabian
I,
will
start
examining
and
asking
questions
now,
but
that's
the
first
thing.
I
now
I
realize
I
started
phrasing.
That
question
before
we
started
recording
recording
wrong.
So
I
won't
finish
that
previous
sentence,
but
okay
proposal
is
to
make
it
so
that
we
can
create
a
group
on
pod
2.
C
C
C
Could
you
know
Implement
something
that's
kind
of
replicating
the
user's
table
over
to
the
second
instance
in
some
way,
and
maybe
that's
sort
of
enough
to
get
it
to
work,
but
it's
it's
replicating
the
data
to
the
the
two
instance
database,
so
I.
That's
why
I
kind
of
don't
know
when
I'm
done,
but
maybe
I'm
thinking
about
it
wrong
and
I
yeah
thoughts.
A
A
A
This
seems
like
a
valid
solution,
but
you
still
need
to
somehow
sell
that
data
between
these
Bots
instances,
so
I
think
the
architecture
of
the
post.
How
we
describe
that
now
it
says
that
like
user
is
part
of
the
cluster
stuff.
So
for
these
to
be
successful,
it
means
that,
like
me,
as
a
user,
that
is
like
the
same
entry
on
both
of
the
instances
can
create
groups
on
on
these
above
instances.
A
So
one
way
is
to
do
it
like
via
cluster-wide
tables
at
these
inscribe
or
second
one
is
like
we
are
what
you
describe,
that
your
replicate
data.
But
then
the
question
is
like
me:
as
a
user
can
I
also
modify
my
user
entry
and
it's
going
to
be
automatically
be
visible
on
our
Bots.
Let's
say:
I
set
my
status
to
something
different
and
like
we
did.
We
actually
achievable
on
the
post
tool
as
I
think
to
be
done,
because
I
think.
A
A
B
A
A
Think
in
that
sense,
as
you
mentioned
as
objective,
it
doesn't
constitute
both
too
because
it
doesn't
require
data
separation,
where
user
can
create
a
group,
it
simply
says
that
group
is
created
exclusively
in
context
of
the
Pod
tool,
but
in
terms
of
modifying
user
profile.
This
is
rather,
you
are
modifying
that
fix
cluster-wide.
So
what
is
specific
then,
to
the
port
2
in
terms
of
the
workflow.
B
So
I'm
I
am
not
going
to
argue
with
that
I.
My
point
was
more
that
that
prerequisite
to
getting
into
creating
a
group,
if
that
makes
the
most
sense
is
that
you
have
this
shared
user
architecture
right
in
four
parts
and
that
involves
minimal
decomposition
of
user
data.
For
this
specific
feature
set
I
think
that's
the
step
one
here
and
then
have
the
user
do.
Something
is
that
true.
A
Yes,
that's
true,
because
if
your
objective
is
like
groups,
group
can
be
created
on
the
Pod
store,
the
foreign
Keys
between
user
and
group
regardless.
If
you
do
cluster
widen
the
composition
or
data
replication,
you
still
need
to
get
rid
of
this
foreign
keys,
because
you're
not
gonna,
be
able
to
create
a
group
because
of
the
invalid
foreign
key
constraint,
probably
or
maybe
you're
gonna
be
able
to
creating
a
replication.
A
C
Yeah
I,
I
I,
would
say:
I've
Not
got
anything
clarified
really.
So
what
I
have
heard
that
that
is
clarifying?
Is
that
we're
all
in
agreement
that
you
know
if,
if
a
solution
was
based
on
oauth
between
the
two
instances?
It's
not
actually,
you
know
working
towards
our
end
objective
of
PODS,
it's
and
it
it
works
today.
So
it's
not
really.
You
know
like
that.
That's
not
a
real
example
of
something
that
we
actually
want
to
work
towards.
The
second
thing,
I
I,
don't
think
I
heard
explicitly,
but
I
you
know.
C
Probably
it's
worth
calling
out
explicitly
is
that
we
don't
plan
to
use
replication
as
part
of
the
architecture,
so
we
would
explicitly
call
out
that
that
is
not
how
you
manage
to
share
users
between
the
two
instances
so
then
kind
of
logically.
All
that
leads
to
is
like
stop
asking
questions
about
how
that
users
works
and
reads
the
pods
proposal,
which
says
this
is
how
user
sharing
works
and
the
pods
proposal
says.
User
sharing
is
accomplished
via
decomposition
in
two
instances
pointing
to
the
same
database.
C
Now,
when
I
reach
all
the
way
to
the
end
of
that
conclusion,
all
of
the
rest
of
it,
you
know
the
the
proposal
is
a
distraction
because
I
feel
like
I've
already
arrived
at
well.
I
just
need
to
figure
out
how
to
decompose
users
to
get
to
the
next
step.
That's
kind
of
how
I've
been
thinking
about
this
work
in
general
for
a
little
while.
But
if
we
read
on
the
thread
of
conversation
here,
the
last
time
Camille
and
I
talked
Camille's.
C
If
we,
if
we
do
it,
you
know,
if
we
do
user
decomposition
without
focusing
enough
on
pods,
we
could.
We
could
choose
an
incorrect
partition,
but
I
also
don't
know
how
we
partially
decompose
users.
That's
the
the
thing
that
I
get
a
bit
confused
by.
We
know
that
the
user's
table
itself
is
the
place
where
the
password
is
stored.
So
if
we
were
just
talking
about
login,
we
know
that
table
alone
should
be
enough
to
allow
user
to
log
in,
but
I
do
not
know
how
we
decompose
that
table
without
cascading
everything
down.
A
It's
gonna
attach
groups,
table,
probably
members
table
and
a
few
more
tables,
and
we
simply
focus
on
interactions
between
users
and
other
assets
and
groups
and
ideas,
and
for
that
specific
workflow,
and
we
simply
disconnect
these
two.
So
we
focus
on
the
very
isolated
service
that
create
a
group
service.
We
look
at
what
is
happening
at
that.
We
break
those
foreign
keys
and
we
change
how
we
read
the
data
for
I
believe
users
in
this
kind
of
context.
So
this
is
so
so.
This
is
like
how
we
set
with
this
specific
workflow.
A
Instead
of
trying
to
find
all
of
the
stuff
related
to
users,
that
would
have
to
be
decomposed,
because
you
still
you're
still
not
gonna
face
all
of
the
cluster
wipes
tables.
But
it
should
be
enough
for
us
to
create
an
entry
in
the
groups
when
you
are
logging,
without
triggering
foreign
Keys
constraints,
and
by
fixing
also
these
cross
stones,
that
we
would
have.
C
C
You
know
valid
in
for
non-decomposed,
as
in
the
way
we'll
be
running,
gitlab.com
won't
be
won't,
have
a
decomposed
users
database
and
also
valid,
for
you
know
it's
it's
a
step
towards
what
will
eventually
be
a
working
pods
installation.
So
could
I
share
my
screen
for
a
second
and
try
to
come
up
with
an
example.
C
So
what
I'm
curious
about
is,
like
you
know,
we
we
said
we're
going
to
focus
on
the
tables
that
will
show
up
in
the
in
the
workflow
of
creating
a
partner.
So
let's
pick
hypothetical
example
that
won't
band
uses
is
a
table
that
points
out
a
user
which
has
been
banned.
So
we
know
that
this
table
probably
will
eventually
belong
as
a
in
the
decomposed
users.
Database
belong.
C
No
I
know
yeah,
so
so,
let's,
let's
assume
that
for
the
first
part,
all
we
need
is
like
say
emails
and
users,
but
I
I
want
to
ignore
that,
because
I'm
taking
this
in
a
slightly
different
direction,
it's
like
we
know
that
it
won't
include
band
users.
So
what
that
leaves
me
to
conclude
is
that
there
needs
to
be
a
loose
foreign
key
from
band
users
to
users,
table
committed
to
master
and
you'll
need
to
delete
the
foreign
key
from
band
users
table
that
references
the
users
table.
A
C
A
Yes,
we
will
probably
gonna
have
to
figure
out
how
to
annotate
that
better,
because,
like
the
the
current
GitHub
schema
is
not
gonna
be
enough,
but
fortunately
we
not
only
use
GitHub
schema
right
now,
because
we
migrated
all
of
these
tables
into
DB.
Docs
GitHub
schema.
So
this
is
it
give
us
more
flexibility
on
on
better
describe
the
behavior
on
a
few
tables.
C
Yeah,
it
kind
of
almost
makes
me
feel,
like
you
know,
we'll
have
a
stable,
a
stable
set
of
databases,
Main
and
CI,
and
we
we
need
to
describe
the
next
step
that
we
want
to
start
enforcing,
but
not
enforcing
the
same
same
way
as
Main
and
Main
and
CI,
because
Main
and
CI
needs
to
work
today
and
and
any
but
uses
main
NCI
needs
to
work
in
the
future.
So
they
could
be
warnings
where
the
other
one
needs
to
be
errors.
C
A
Robert
I,
I
I
didn't
think
yet
exactly
how
we
would
model
that,
because
it
could
be
either
GitHub
cluster
schema
or
whatever
that
would
be
used.
That
would
override
that
in
some
cases
when
running
in
the
cluster
mode.
Initially,
you
would
have
to
think
about
the
specific
behavior
about
like
between
users
and
band
users,
how
it
would
would
have
to
be
enforced.
A
Simply
context
means
whatever,
and
you
simply
ignore
that
for
now
and
you
allow
basically
foreign
keys
to
happen
between
whatever
context
it
is.
Maybe
this
is
part
of
the
GitHub
schema
or
maybe
this
is
an
additional
parameter
that
we
add
that
simply
refines
schema
or
it
can
be-
let's
say,
GitHub
underscore
Main,
comma
dot,
cluster
or
whatever.
Is
that
that
simply
we
can
easily
parse,
and
we
find
that
this
GitHub
schema
is
more
specific
in
terms
of
the
Affinity,
the
gitlab
main
of
groups,
so
I
like
I'm,
not.
C
Sure,
if
you
are
following
yeah,
no
I'm
I'm,
definitely
following
you,
but
what
I'm
hearing
is
that
we
are
building
a
new
set
of
static
and
dynamic
analysis
based
on
a
new
way
to
view
the
database
as
either
pod
or
cluster
and
we're
not
able
to
reuse.
Our
existing
concept
of
gitlab
schema
to
help
us
get
from
A
to
B,
like
we
did
for
for
the
first
CI
decomposition
we
used
gitlab
schema
and
all
the
static
and
dynamic
analysis.
Tooling
there
I
in
my
head,
I,
was
thinking.
C
We'd,
keep
reusing
that
exact
Concept
in
the
in
the
yaml
file
format
that
I
just
showed
you
to
get
us
from
A
to
B,
but
that
won't
work
in
the
way
you're
thinking
about
this
iteration
you
you
instead
want
to
start
gradually
marking
things
as
cluster
and
have
a
have
similar
but
different
tooling.
That
that
does
the
schema
analysis
that
the
dynamic
and
static
schema
analysis.
A
C
B
C
So
right
so,
but
it,
but
it
is
a
it-
is
a
different
rule
than
what
we
have
implemented
in
the
dynamic
analysis
today,
because
the
rule
says
if
they
don't
match.
But
now
the
rule
is
going
to
say
if
the,
if,
if
they
don't
match,
then
check
the
second.
If
they
don't
match,
then
check
the
first
to
see
if
the
schema
or
cluster
is
defined.
C
Right,
but
we
still
want
warnings
for
band
users
as
as
a
strategy
for
helping
us
iterate
towards
finding
the
table
so
that
that
would
be
that's
what
what
it
would
mean
for
us
to
use
the
existing
tooling
right
for
us
to
use
the
existing
tooling.
We
need
a
warning
to
tell
us
what
to
what
tables
get
moved
next.
A
Yes,
like
like,
we
would
have
to
figure
out
like
the
better
way
to
Affinity
that
stuff,
because
then,
probably
how
you
would
do
you
would
say
obvious
repos
for
Bobby
is
another
one.
We
figure
out
that
one
user
should
be
part
of
the
cluster
and
it
basically
starts
to
generate
failures
related
to
band
users.
C
A
I'm
not
I'm,
not
sure
if
I
got
these
things
on
because,
let's
say
like
in
case
of
the
bond
users
and
users,
it's
still
undefined.
So
so
we
don't
know
if
this
is
a
a
warning
or
error
or
whether
this
is
actually
like
a
legitimate
case,
because
this
information
is
not
enough.
Like
a
clear,
concise
answer,
it's
like.
A
Lack
of
the
cluster
here-
it's
maybe
so
like
it's,
maybe
not
warning,
but
rather
maybe
this
is
something
similar
to
what
we
did
with
the
query,
analyzers
and
figure
out
figuring
out
the
cross
joints
that
may
be
happening.
Maybe
this
is,
but
that
was
a
warning.
This
is.
This
is
thing
that
actually
triggers
like
this
is
cross
lines
that
is
basically
undefined
in
its
scopes
of
the
operation,
and
we
don't
know
how
to
classify
that
so,
okay,
in
that
sense,
it
may
be.
C
More
yeah
but
yeah
imagine
to
simplify,
like
imagine
you
add
colon
pod
to
the
end
of
band
users.
We
want
that
to
be
a
warning
because
that's
not
broken
in
production
today,
but
if
you
added,
if
you
change
band
users
to
be
gitlab
CI,
you
would
want
that
to
be
an
error
and
that
that
won't
be
able
to
possibly
reach
production.
So
that's
what
I
mean
about
the
difference
in
tooling
has
now
extra
complexity
to
detect
we're
not
just
able
to
use
the
existing
comparison
of
say
this.
C
This
is
allowed
or
disallowed,
because
there
are
things
that
are
really
really
not
allowed
and
then
there's
things
that
won't
be
allowed
eventually,
I
know
I
I,
don't
know
all
the
answers.
You'll,
probably
figure
out
that
yeah,
I,
guess
and
and
all
of
that
going
through
my
head
is:
what's
making
me
think
differently
about
this
problem
and
saying
I
would
rather
focus
on
the
UI,
the
the
just
the
user
decomposition,
but
I
didn't
really
think
about
this
colon
cluster
colon
pod.
C
That's
how
you've
been
thinking
about
it,
but
I've
been
thinking
like
and
in
fact
our
our
original
proposal
says.
Users,
routes
and
admin
are
all
three
different
databases,
but
I'm
also
fine,
to
say
all
three
of
them
go
into
one
cluster
database,
I'm.
Okay,
to
do
that
too,
but
in
my
head,
if
I
thought,
okay,
users,
routes
and
admin
were
three
different
databases
that
would
that
allowed
me
to
break
it
down
in
my
head
to
say,
I
killed.
C
A
I
I
don't
think
that
those
things
are
incompatible
because,
ultimately,
you
may
end
up.
On
the
same.
It's
just
a
question
like
that.
This
I
sorry
I,
like
I
I,
thought
about
that
like
alongside
our
discussion,
I,
was
not
thinking
how
we're
gonna
be
doing
that
before
that
goes.
So.
This
is
why
it
was
not
described
anywhere.
A
But,
ultimately,
I
think
they
are
not
incompatible
with
the
ideas,
because
even
in
this
model
you
can
still
like
decompose
users.
You
simply
somehow,
like
this
mother,
allows
you
to
do
iterative,
the
composition
of
the
users,
but
technically
we
still
can
introduce
as
completely
separate
schema
that
kind
of
introduce
like
a
a
false
boundary
between
easily
so.
A
So,
basically,
you
can
consider
what
I
brought
more
like
the
intermediate
step
with
the
internet
that
all
things
the
composed
into
cluster.
They
actually
have
their
completely
own
schema,
because
my
thinking
was
like
it's
gonna,
be
too
many
things
to
change
at
the
single
time.
But
when
we
get
some
critical
mass
of
the
tables
be
classified,
this
is
maybe
when
it
may
be
easy
for
us
to.
Let's
say
to
to
finish
the
rest
of
we've.
Introdu
introduction
of
the
new
schema
foreign.
C
What
do
you
think
is
the
first
thing
that
gets
merged
into
Master,
then
for
your
proposal?
What
is
the
first
code
change
more
concretely,
because
if
I
look
at
what
you've
described
now,
the
first
concrete
changes
we
need
our
tooling,
our
gitlab
schema
tooling,
to
become
more
sophisticated
and
be
able
to
distinguish
between
pod
and
cluster
and
present
some
useful
information
to
developers
that
allow
us
to
discover
the
next
table
that
violates
the
constraint.
C
A
My
thinking
was
that,
like
we
were
simply
not
sure
if
this
is
like
what
is
the
order,
whether
we
need
to
link
or
not,
but
I
would
simply
probably
try.
First
application
settings
as
a
simple
staple
to
add
new
connections,
but
some
base
classes
and
things
like
that,
and
if
we
do
application
settings
we
figure
out.
If
we
need,
let's
say
the
syntax,
that
I
described
or
not
at
that
moment,
because
application
settings
on
its
own
has
some
foreign
keys.
C
C
C
C
I
can
imagine
all
you
would
have
to
do
is
delete
the
foreign
keys,
but
if
I,
if
I
had
to
break
down
that
proposal
it
to
me,
it
seems
completely
independent
of
what
you've
written
of
user.
Creating
group
two
like
I,
don't
see
the
connection.
Why
I
actually
need
a
shared
application
settings
in
order
to
create
group
two?
What
is
it
about
that?
A
I
agree,
my
thinking
behind
that
was
like,
like
it's
easier
to
start
with
something
that
is
like
the
very
well
defined
and
fairly
isolated,
even
if
it
makes
us
like
to
get
our
goal
slightly
longer.
But
we
introduce,
like
this
initial
boiler,
place
that
we
need
and
this
initial
body
air
plate
is
like
connections,
configurations,
I,
don't
know
whatever
schema.
We
need
to
discover
that
stuff
and
also
prepare
our
environments
to
test
that
which
is
like
I,
don't
know,
gtk
GC,
key
gck
or
whatever
it
is
so
I
am
assuming
that,
like.
A
C
It's
we
don't
know
how
to
implement
pods
without
doing
this.
So
that's
what
we're
doing
first
and
it
doesn't,
it
doesn't
actually
fit
into
any
workflow
until
a
long
time
down
the
road,
and
that
may
be
practically
all
we
could
achieve
in
a
quarter
depending
on
how
many
Engineers
are
working
on
it.
I.
A
Mean
like
like
technically
like
our
goal,
can
be
split
into
two
steps
like
first
step,
but
without
saying
user
is
kind
of
pointless,
but
you
can
log
in
into
Bots
2
and
change
admin
settings
and
this
admin
settings
are
shared,
but
technically
it's
still
like,
probably
very
workflow.
Even
if
you
have
two
separate
users,
it
means
that,
like
there
is
some
amount
of
the
data
serving
between
instances
as
a
setting
and
users
are
sharing
will
arrive
later.
A
A
C
C
Yeah
I
agree:
it's
it's!
It's
not
really
that
black
and
white,
but
but
I,
don't
know
if,
if
that's
like,
if
that's
the
objective,
I
feel
like
we're
a
little
bit
back
to
where
we
were
with
our
original
proposal,
which
is
there,
is
this
large
end
architecture
that
we've
come
up
with,
that
that
matches
the
description
of
PODS
as
we've
been
asked
to,
and
this
architecture
requires
these
independent
small.
C
You
know
these
these
small
individual
problems
to
be
fixed
one
at
a
time
and
ultimately
the
whole
thing
will
not
make
any
sense
until
we
do
that,
and
this
and
the
exact
same
procedure
was
followed
for
CID
composition.
We
didn't
jump
to
splitting
the
database
for
one
user,
something
crazy
like
that,
because
that
would
have
just
been
a
distraction.
What
we
said
was
we
defined
virtual
boundaries
and
we
start
fixing
problems
until
the
application
actually
works,
and
only
then
does
it
even
run
with
two
databases
in
our
CI
environment.
C
C
You
know
what
is
what
is
working
if
in
a
broken
environment
but
I,
don't
know
maybe
I'm
being
too
literal,
but,
and
you
need
to
ask
other
Engineers
on
the
team
to
interpret
what
they
what
they
interpreted
from
these
requirements
like
what
did
what
did
tonganoma
when
they
saw
these
requirements?
What
did
it
mean
to
them?
What
did
they
think?
The
next
step
was
because
I
yeah
I
think
we'll
all
have
different
thoughts
on
that
I
know.
C
I,
don't
I,
don't
really
know
what
more
actionable.
If,
if
honestly,
if
I
had
like
my
strongest
opinion,
would
be
to
say,
walk
into
this
meeting
and
present,
we
have
an
end
architecture
that
we
have
come
up
with
as
a
team.
We
agree
on
most
of
it
and
there
are
specifics
that
will
be
figured
out
along
the
way,
but
we
all
agree
that
this
final
architecture
cannot
be
shippable
without
all
of
these
prerequisites,
prerequisites
are
shared
databases,
prerequisites
are
sequential
IDs.
C
You
know
conflict
namespace,
conflict
resolution.
All
of
these
things
are
prerequisites,
otherwise
the
architecture
will
not
work
and
the
own.
That
is
the
that
the
only
way
we
can
proceed
to
make
to
build
this
in
a
way
that
works,
but
that
that's
in
my
head.
That's
that's
how
I
I
still
think
about
this
problem,
but
yeah.
C
C
I
think
we
did
get
somewhere
but
like
we,
we
also
arrived
at.
Like
a
conclusion
of
you
know,
we
we
want
to
work
on
application
settings
and
we've
kind
of
both
landed
on
that
conclusion
differently.
What
I'm
I'm
still
concerned
about
from
a
describing
the
team's
Mission
like
the
the
q1
mission
or
whatever
I
I,
feel
like
it
isn't
a
you
know.
If,
if
we
say
it's
application,
settings
shared
across
two
get
lab
instances
which
I
think
is
valuable.
We
both
agreed.
C
And
in
fact,
two
gitlab
instances
with
different
admin
settings
would
would
wouldn't
actually
break
the
the
title
of
that
proposal.
You
wouldn't
actually
need
admin
settings,
because
when
you
create
a
group,
you
don't
go
and
change
any
admin
settings
you
could
just
live
with.
Both
of
those
instances
could
have
the
default
admin
settings
and
they
would
accidentally
be
the
same.
You
never
changed
any
admin
settings,
so
it
would
work
and-
and
that's
my
concern
still
around
the
you
know
what
is
actionably
the
next
step
for
developers
to
do
and
the
title
is
misaligned.
A
So
do
you
propose
like
to
transfer
title
that,
like
applications,
I
think
is
being
served
between
ports
or
or
do
you
want
to
keep
like
the
application
settings
more
like
be
like
a
soup
task
of
this
bigger
goal?
Because
right
now
in
my
head,
the
application
settings
were
was
rather
like
a
soup
task
of
user
can
create
a
group.
But
we
agree
that
this
alone
is
not
essential
to
achieve
the
goal,
but
his
desire
for
us
as
a
way
to
embrace
the
problem
in
more
iterative
way.
C
A
Mean
like
it
still
may
be
certain
like
be
valued
like
that
our
African
hour
ago
is
like
user,
can
create
a
group
on
both
tools,
but
the
iterations
are
more
defined,
and
this
is
basically
what
like
the
first
iteration
that
we
are
focusing
on
and
as
part
of
that
iteration
like
we'll
block
out
these
I,
don't
know,
schema
stuff
connection
stuff.
All
of
these
biology
are
played
that
we
have.
C
To
go
through
yeah
I,
the
thing
that
I
think
is
missing
there
is.
You
know
that
it's
a
valid
criticism
to
say
when
we
want
to
cut
scope
and
make
this
work
as
simple
as
possible,
we're
going
to
remove
a
subtask
that
is
not
necessary
for
this
end
goal.
Your
very
first
sub-task
is
not
necessary
for
the
end
goal,
so
as
a
product
manager
I
think
it's.
C
You
know
the
right
step
to
remove
that
scope
from
this
work
and
and
that's
what
we're
missing
and
I
think
that
could
be
a
valid
criticism
that
we
actually
get
for
the
proposal,
which
then
our
reasoning
should
should
be
the
same.
With
the
first
reasoning
we
came
up
with,
which
is
you
know,
we
need
to
start
decomposing,
cluster-wide
tables
in
order
for
this
architecture
to
even
be
describable
as
a
software
architecture.
C
There
is
that
the
pods
architecture
is
defined
by
some
tables
being
shared
across
two
different
applications,
and
if
we
do
not
do
that
as
a
Next
Step,
then
you
know,
regardless
of
whether
users
notice
that
or
benefit
from
them
from
that,
then
we
we
don't
know
where
to
start,
but
your
user
can
create
group
two
with
the
same
login
implies
that
the
first
example
should
be
the
user's
table,
but
we
know
that's
a
deeper
rabbit
hole.
If
we
go
down
that
road
and
that's
why
we
didn't
want
to
do
it.
A
C
A
C
C
It
it
would
be
simplest
if
we
followed
the
exact
same
procedure,
we
used
for
CID
composition
and
it
would
be
well
defined
and
you
and
some
work
that
could
be
delegated
more
easily
because
we
say
this
is.
This
is
how
it
works.
You
you
update
the
schema,
you
see
the
violations,
you
fix
them,
you
then,
and
then,
if
we
want
to
get
that
onto
production,
it's
a
separate
story.
C
When
you
consider
all
the
different
things
involves.
However,
if,
if,
if
the
proposal
is
what
your
think,
what
you've
described
earlier,
which
is
actually
these
application
settings
are
not
going
into
their
own
schema
they're
going
into
a
New,
Concept
called
clustered
wide
tables
and
cluster-wide
tables
are
a
little
bit
like
decomposition
in
that
we
will
eventually
have
to
enforce
them,
but
they
have.
C
They
generate
a
different
type
of
warning
to
what
we
used
to
do
before
and
developers
don't
have
to
action
those
straight
away,
and
there
can
be
some
violations
in
the
code
base
for
cluster-wide
tables.
If
go
down
that
route,
then
I
think
it's
harder
to
delegate
that
work
like
even
to
me,
because
I
I'm
still
wrapping
my
head
around
exactly
where
the
boundaries
of
that
are.
C
I
would
like
that
to
be
the
next
step
and
that
that
schema
could
be
called
gitlab
cluster
I,
don't
mind,
get
lab
pods,
cluster
or
gitlab
cluster
or
whatever,
and
then
fix
all
the
violations
and
merge
that
to
master.
And
then
we
have
a
version
of
gitlab
that
could
run
locally
as
decomposed
cluster
decomposed
or
not,
and
then
you
could,
you
could
actually
Implement
in
the
GDK
away,
where
you
run
two
instances
that
actually
shared
that
database.
C
That
would
be
well
defined
in
my
head
I.
You
know
that.
That's
how
I
would
like
to
see
us
iterate
on
that,
but
yeah
once
once
it
comes
to
users
as
soon
as
as
soon
as
you
say
that
the
next
step
is
to
add
users
to
that
cluster,
wide
thing
that
the
task
will
be
defining
all
of
the
users
tables
which
I
I
know
you
don't
like,
but
my
head
I
think
it
could
be
achievable
it
it
just
it
again.
It's
it's.
B
I
I
missed
a
bit
of
the
conversation
in
the
middle
but
I.
What
I'm
hearing
is
like
I
personally
like
having
a
functionality
that
you
can
describe
like
you
know,
we
have
application
settings
that
are
shared
across
pods.
When
you
can,
you
can
update
them
in
a
way
or
having
a
user
do
something
on
a
pod
as
an
outcome.
C
Camille
also
believes
that
doing
application
settings
first,
and
that
was
actually
his
suggestion
originally
so
I'm
actually
kind
of
ultimately
agreeing
with
him.
I
actually
was
thinking
that
we
were
doing
users
first,
but
Camille
was
rightly
notice.
Application
settings
is
one
table
and
it's
the
simplest
one
too
decompose
compared
to
users.
So.
C
I'm
trying
to
pause
exactly
the
last
thing,
Camille
said,
which
is
if
we
could
go
through
that
proposal
and
still
arrive
at
the
same
destination,
which
I
think
is
totally
reasonable.
My
the
original
way
I
was
thinking
about.
It
is
the
reason
we
will
arrive
at
the
same
conclusion
is
that
the
the
actual
proposal
is
gitlab
potted,
some
shared
databases,
some
not.
C
B
B
So
I
and
I
also
have
to
hop
again
it's
not
a
great
time
for
me
today,
but
I
think
what
I
liked
or
I
still
like
in
Camille's
proposal
is.
It
makes
this
entire
pod
process
more
tangible,
but
it
will
not
be
fully
functional,
but
I
think
it
is
enough
to
make
it
much
more
concrete,
and
we
may
then,
on
top
of
that,
build
more
knowledge
and
have
better
ways
of
delegating
it.
But
I
think
this
is,
is
just
a
small
slice
right.
Well,.
C
C
Decomposition
was
one
of
them,
but
then
there
was
something
else
well
in
in
the
end,
you
know,
let's
say
Q8:
we
have
pods
pod
2
on
production,
so
you
can
write
this
proposal
up
in
a
way
where
we
we
say
our
end
goal
is
still
here,
but
you
can
ask
us
to
skip
these
steps,
but
then
we
don't
understand
what
we're
building
any
that's,
how
I
feel
about
it
anyway,
you
can.
You
can
ask
me
to
skip
these
steps,
but
I
don't
know
if
you
tell
me
to
skip
any
of
these
steps.
C
C
And
I
think
that's
fine
for
us
to
be
to
be
upfront
and
say:
well,
that's
still
necessary
for
us
to
ship
the
final
useful
thing
to
Features
into
the
users,
because
we
did.
The
same
thing
was
true
of
CID
composition,
which
took
us
more
than
a
year.
But
you
know
look
reflecting
back
on
that.
Would
we
have
rather
set
arbitrary
goals
in
the
middle
of
partially
broken
applications.
A
A
C
A
But
like
but
like
I
think
my
perception
is
like.
If
you
go
through
workflow,
you
Embrace
like
a
fundamental
problems
of
how
to
let's
say
these
different
workflows.
Work
like
you
go
through
groups.
Maybe
we
then
go
through
projects.
We
already
have
like
enough
experience
to
say:
hey
the
CI
Runners
is
now
fixed.
You
ask
a
group
verify,
should
go
and
fix
based
on
our
work
on
the
project.
A
A
At
least
this
is
in
my
head,
I'm
kind
of
thinking
that,
like
in
my
head
that
like,
if
we
fix
like
two
or
three
workflows,
we
just
get
enough
of
the
Tooling
in
the
application
that
this
should
be
done,
like
replicatable
by
other
groups
by
fixing
them
their
stuff
and
like.
We
could
then
work
on
the
more
essential
stuff,
like
a
rotor
sequence,
IDs
cluster-wide,
plus
foreign
keys,
whereas
I
think
in
the.
A
If
we
do
like
the
user
decomposition,
which
is
a
very
wide
problem,
we
kind
of
forced
to
be
engaged
like
with
everyone
and
focus
basically
specifically
on
that
and
kind
of
now
figure
out
that,
like
this
is
user,
that
is
broken,
but
then
they're
gonna
be
probably
something
else.
That
also
has
to
be
cluster-wide.
That
is
gonna
also
gonna
be
broken,
so
I,
I'm
kind
of
like
thinking
about
like
this
is
more
like
a
vertical
size
versus
horizontal
slice,
of
how
you
approach
that
I
I,
like
I,
think
like
that.
A
But
if
we
follow
like
a
a
model
that
like
we
need
to
fix
all
of
the
user
decomposition,
we
may
be
missing
some
other
things
are
gonna,
be
reckon
that
are
essential
for
the
pulse
to
be
actually
generally
available
on
on
that.
So
I
think
it
moves
Focus
from
trying
to
fix
a
white
stuff
to
try
to
fix
like
a
specific
workflows.
Knowing
that's
okay,
not
all
work
was
going
to
be
fixed.
C
Okay,
well,
I'd
be
fine
with
vertical
slices
if
it
actually
went
all
the
way
to
the
end.
So
that's
the
difference
right.
We,
you
know,
we
said
we
said
in
the
last
call.
Was
we
deploy
pod
2
to
production
and
get
real
users,
but
we
have
we
already
have
things
that
will
be
broken
and
we'll
have
to
throw
away,
and
it
doesn't
work
so
like
I
would
like
a
vertical
slice
as
well.
That
gets
us
a
pod
2
in
production.
That's
mostly
working
and
good
enough
for
some
of
our
customers.
C
I
would
I
would
say
that
that
is
the
best
outcome,
no
matter
how
you
think
about
this,
but
when,
when
we
cut
scope
to
the
point
where
removing
things
we
know
explicitly
are
not
acceptable
to
remove
like
route
conflicts
to
you
know,
projects
having
the
same
path
or
two
projects
having
the
same
primary
key.
If
we
explicitly
cut
that
scope,
then
I
don't
think
we're
doing
vertical
work
anymore.
We're
doing
like
something
in
between
and
and
the
bigger
problem
is
I
can't.
A
Whatever
is
there
that
is
really
essential
for
Bots
I'm,
not
saying
that
like
if
we
kind
of
focus
on
the
decomposition,
because
I
think
it
like
makes
you
like,
when
you
put
the
composition
of
the
user's
Roots.
Maybe
some
other
feature
before
we
even
we
can
actually
start
thinking
about
the
the
router
that
is
even
like
functional,
so
I
think,
like
I
kind
of
received
it
more
like
a
waterfall
model
in
terms
of
how
how
we
get
things
into
production
yeah
and
like
and
like
how?
A
How
how
early
like
you
get
any
results,
because,
like
I
think
one
thing
is
like
I
think
the
city
had
like
very
big
problem
with
understanding.
Okay,
so
you're
gonna
now
do
a
decomposition
for
one
year,
but
like
what
is
actually
in
between
it's
like,
not
really,
something
that
like
we
can
show
that
we
are
doing
progress,
It's
very
invisible
to
whoever
is
not
developer.
What
we
are
doing,
I.
B
I
think
I
tend
to
agree
with
with
Camille
in
the
sense
that
I'm
not
sure
what
axes
we
are
talking
here
right.
But
if
I,
if
I
look
like
I'm
looking
at
sort
of
you
know
sequentially,
you
know
we
do
decomposition
first,
then
we
do
Roots.
Then
we
do
this
right
and
then
two
years
later
we're
at
pause
right,
that's
I,
think
one
way
of
doing
it
and
then
I
think
what
Camille
is
proposing.
Is
we
take
a
tiny
slice
and
try
to
take
it
all
the
way
to
the
end?
B
You
know
which
is
a
specific
workflow,
and
we
accept
that
we
won't
have
everything
in
place,
for
you
know
to
make
that
work
end
to
end.
Yet
you
know
what
we
learn
a
little
bit,
we'll
do
the
next
one
and
ultimately
we
build
up
the
tooling
to
make
these
features
work
one
after
another,
and
in
that
way
we
we
have
a
better
chance
of
sort
of
enabling
more
and
more
workflows
that
are
required
for
pods,
because
we
also
know
that
we
don't
have
to
do
all
of
them.
A
C
I
would
I
would
want
parallel
risk
demitigation
in
like
every
quarter
and
that
we
actually
had
proposal
for
the
next
quarter's
risk
mitigation.
Sorry,
risk
mitigation
and
that's
exactly
the
same
concern
I
have
that
you're
you
have,
which
is
we
spend
years
and
we
get
to
a
blocker
at
the
end
of
it.
That's
that's
absolutely
the
worst
case
scenario
of
this
whole
thing,
and
so
you
know
the
first
risk
mitigation
strategy
we
had
already
proposed
is
it
was
presumably
the
least
desirable.
C
You
know,
based
on
the
response
was
the
least
desirable
thing
and
I'm
I'm
concerned
with
throwing
that
away
for
q1,
with
with
our
current
proposal,
I
feel
like
we
still
miss
that
risk
mitigation,
because
we
don't
ship
to
production
so
and
we
say
that
it's
still
broken,
so
we
we're
still
left
with
a
situation
where
we
we
just
go
okay.
Well,
we
know
it's
broken.
So
let's
not
worry
too
much
about
that.
Yet
we
don't
learn
whether
or
not
things
are
going
to
be
absolute
critical
blockers
to
this
architecture
early
enough.
So.
C
We,
we
have
seen
other
projects
where
people
kind
of
get
stuck
on
details,
and
they
look.
They
see
the
next
step.
They
see
the
next
step,
they
see
the
next
step
and
they
work
on
it
for
years
and
you're
still
wondering
why
this
aspect
of
gitlab
is
not
fixed
after
you
know
it,
people
have
been
talking
about
it
since
I
joined
the
company,
whatever
that
particular
problem
is
and
we're
just
another
one
of
those
problems.
B
C
B
Yeah
I
think
that
will
still
need
to
happen
right,
that's
sooner
or
later
right
and
ideally
sooner
so
I'm.
But
that's
that's
my
biggest
risk.
I
think
the
other
one
is
I.
Think
similar
is
like
it's
a
bit.
It's
a
massive.
It's
a
massive
thing:
it's
a
completely
different
way
of
running
gitlab
right
and
so
there's
always
a
risk
that
you
get
stuck
or
you
know
the
world
moves
on
and
changes
and
you
you
have
been
something
but
I,
think
I
think
what
we
are
facing
as
well.
B
A
A
A
Simply
and
like
the
only
approach
that
seems
to
allow
us
to
fail
fast
is
basically
go
by
workflow,
because
users
and
the
composition
is
gonna.
Take
really
long
time
to
learn
that
it's
paid
because,
like
the
any
user,
visible
change
is
going
to
be
pretty
light
and
people
will
not
really
see
impact
on
their
features
in
the
Pod
architecture
because,
like
they
did
see
the
composition
and
they
learned
how
to
do
it
like.
It
seems
that,
like
everything,
is
pretty
much
feasible,
but
it
turns
us
really
like
in
terms
of
the
post
architecture.
A
So
what
I'm
kind
of
thinking
after
hearing
that
like
we
need
to
fire
fast.
So
we
like,
we
should
focus
on
the
workflow,
so
people
could
work
on
their
workflow
and
very
fast
as
well,
and
while
fixing
that
workflow
and
for
me,
I,
think
the
composition
really
like
delays
that
by
one
year,
if
we
focus
on
the
decomposition
for
them
to
learn
that
they
work
very
simply
so
broken
that
it's
like
unfixable.
C
Yeah
I,
actually
yeah,
have
forgot
that
that
was.
Our
original
objective
was
actually
that
we
were
going
to
start
working
on
organizations
and
user
research
at
the
same
time
in
the
next
quarter,
and
given
that
me
remembering
that
I
actually
think
that's
the
quickest
way
to
de-risk
all
of
well,
no
sorry
quickest
way
to
de-risk
my
concern
and
fabian's
concern.
C
But
your
concern
is
that
the
router
won't
work
that
will
take
that
we
wouldn't
be
able
to
de-risk
that
with
the
organization's
work
or
the
user
research,
in
my
opinion,
so
I
but
I'm
concerned
that
your
approach
doesn't
de-risk
us
learning
that
it
doesn't
work
for
users
because
we're
not
presenting
this
to
any
users
so
that
that
that's
what
I'm
a
little
bit
so
I
I
just
tried
to
write
this
up.
I
I,
think
I,
said
user
research
doesn't
make
sense.
C
I
feel
like
Fabian,
did
say
the
same
thing
as
me
in
a
different
way
and
I
actually
wasn't
writing
this,
as
you
were
speaking
so
that
that
misquoting
and
then
you're
Camille's,
is
that
the
router
is
impossible
to
implement
so
I
feel
like
we
have
the
overlap
of
of
isolation
organization
stuff
too
large
to
complete
I.
Think
it's
it's
almost
overlapping
with
this
a
little
bit,
but
not.
B
A
B
But,
but
just
to
talk
about
the
skin
General
right,
it's
like
we're,
not
I,
think
the
sort
of
the
two
things
right
that
we
would
like
to
accomplish
in
this
whole
like
product
isolation,
space
right,
that's
still
going
to
have
to
happen
also
in
q1
right
I'm,
not
like
going
to
shelves
that
and
come
on
I'm
going
to
hand
it
to
Josh,
but
it
needs
I.
Think
that's
a
fundamental
thing
that
we
need
to
figure
out,
but
that
well
requires
I.
Think
that
it's.
C
So
well,
on
the
flip
side
of
that
I
feel.
Like
that's
the
one
thing
we
need
to
ask
for
permission
from
the
CEO
on,
because
it's
out
of
our
ability
to
execute.
So
let's
say
we
agreed
on
Camille's
plan
and
then
we
started
working
on
it
and
one
monthly
and
everybody
on
the
team
agreed
that
we
are
going
to
change
something
about
it.
We
don't
really
need
to
ask
the
CEO
permission.
C
We
have
the
we
have
given
the
permission
to
execute
and
take
the
next
steps
on
the
technical
implementation
in
a
way
that
makes
sense
to
us,
but
we
do
not
have
permission
to
ask
every
single
person
in
the
company
you
know
or
or
start
experimenting
on
users
and
say
like
well.
You
just
signed
up
to
gitlab.
You
got
an
isolated
experience
and
you
can't
no
longer
see
the
to-do's
in
in
a
certain
way
or
whatever
I
feel
like
we,
that
that
that's
products
that
features
that
are
outside
of
our
team.
C
That's
that's
why
I
I'm
more
focused
on
that
aspect
of
what
we,
what
we
got
denied
what
you
know
we
got
pushed
back
on
in
the
last
call.
That
was
the
thing
that
we
got
pushed
back
on
and
organizations
is
like
yeah,
so
user
experience.
Then
organizations
executing
on
that
is
the
quickest
way
to
actually
put
it
in
front
of
real
users
and
and
better
than
research.
B
B
Have
anything
it's
like
I
think
the
the
workspace
group
and
group
manage
actually
has
knowledge
and
is
empowered
to
build
that
out
as
well
I
think
they
know
how
to
do
this
once
we
agree
on
what
to
do.
I
don't
know
if
they
are
in
a
position
to
work
on
any
of
the
like
back-end
pod,
related
things
that
we
just
outlined
right.
C
A
I'm
actually
finding
problem
with
the
organization,
because
I
mentioned
I,
don't
know
how
it
moves
the
ports
architecture
closer
to
to
what
we
are
aimed
to
do.
It's
like
prerequised,
the
organization
stuff,
but
in
the
most
high
sense
like
if
you,
if
you
can
run
Parts
on
the
Pod
tool
and
Port
free
and
put
four,
it's
already
isolated.
A
C
I
think
we
have
it
in
the
proposal
it
it
accounts
for
how
the
global
pages
will
behave,
so
a
user
that
finds
themselves
loading
page.
You
know
a
page
off
of
a
different
pod.
It
it
accounts
for
and
ex
in
solves
the
problem
of
what
what
happens
when
they
try
to
look
at
their
to-do
list
or
their
dashboard,
the
home
page
of
gitlab,
and
it
also
accounts
for
what
will
happen
when
they
try
to
link
issues
across
different
namespaces.
B
I'd
like
to
take
a
step
back
also,
especially
because
I
really
need
to
get
home
and
I
I
need
to
wrap
it
up
at
least
mentally.
For
me,
I
thought
going
into
this
discussion
that
we
had
maybe
more
alignment
than
we
now
seem
to
have.
Maybe
that's
also
just
because
we've
talked
about
it
for
one
and
a
half
hours
Okay,
so
which
is
maybe
Testament
to
the
fact
that
it
is
complex.
B
B
At
least
be
okay
with
you
know
a
statement
rather
than
No
statement,
because
I
think
that's
not
going
to
be
productive
for,
for
anyone
and
I
think
right
now,
because
I'm
I
think
a
little
bit,
undercooked
I'm,
not
quite
sure
if
we
like
what
we
are
agreeing
on
and
what
the
what
the
next
steps
really
are
for
for
tomorrow,
because
I
think
now
we
are
talking
about
the
details
of
the
value
of
organizations.
So
are
we?
B
Are
we
okay
with
saying
like
look
we're,
trying
we're
going
to
try
and
get
a
for
me
horizontal
Slice,
on
a
on
an
individual
workflow?
Should
we
outline
those
two
paths
and
say
like
look,
you
know
we
could
do
what
Dylan
said,
and
this
is
this
is
one
way
or
we
do
this,
which
is
something
that
we
also
can
do.
Should
we
also
highlight
the
like
parallel
discussion
that
still
needs
to
be
resolved
regarding
isolated
workspaces,
I'm
I'm,
a
tad
lost.
C
C
You
know,
if
you
ask
me
the
question
of
am
I,
confident
it's
something
we
can
delegate
to
the
team
in
the
way
it's
written
by
I
I
have
the
same
concerns,
and
if
you
ask
me
Dylan,
can
you
think
of
any
criticisms
that
Sid
may
have
of
this
proposal?
I
think
the
ones
I've
presented
I
think
would
you
know,
may
be
things
that
some
of
which
may
come
up
or
not
I,
don't
know,
but
otherwise,
like
let's
say
we
agree
to
do
that
and
then
we
end
up
working
on
application.
C
Setting
cluster
decomposition,
I'm,
okay,
I
believe
that
could
be
delegated
on
its
own,
but
yeah,
then
right
so
so,
I
I'm,
totally
fine
with
Camille
owning
all
aspects
of
that
and
describing
it
in
the
way
that
makes
sense
to
him.
I
think
yeah
just
expressed
ways
that
it
makes
less
sense
to
me,
but
that's
okay,
because
I
think
about
it
differently.
Also
vertical
versus
horizontal
slicing
Fabian
that
vertical,
as
in
we're
going
to
go
all
the
way
from
here
to
here.
C
B
B
Think
we're
saying
the
same
thing
just
in
different
axes.
Thank
you.
Also.
I
drew
that
picture
so
past
Fabian
had
different
axis
orientation.
Very
clearly,
cool
I
think
that
maybe
I
think
my
like-
and
this
is
maybe
my
thinking
about
big
concerns.
It's
like
we
get
into
sort
of
a
paralyzed
mode
where
everything
like
it's
hard
to
make
a
decision.
So
we
we
talk
about
it
for
a
long
time
which
we
are
I,
think
doing
and
I
think.
B
B
This
is
not
working
out
the
way
that
we
thought,
because
in
the
grand
scheme
of
things
given
that
this
is
going
to
be
take
two
years
plus
wasting
four
weeks
on
something
and
figuring
out
that
it
didn't
work,
is
not
going
to
be
that
critical,
but
I
think
we
we
have
capacity
and
we
need
to
concretely
move
forward
and
try
to
merge
things.
I
think
that
is
my
worry,
that
you
know
there's
going
to
be
upsides
and
downsides
for
most
things
and
I.