►
From YouTube: Geo Scheduling Call 2020-07-21
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
B
A
Yeah,
you
might
need
to
refresh
the
board
there.
I
think
it's
updated
a
little
bit.
C
B
Yeah
verification
column
is
empty
right.
Okay,
let's
start
with
clothes.
Section
is
gabriel
here
at
all.
No.
A
He
isn't,
I
can
provide
an
update
on
that
real
quick.
He
went
through
and
tried
to
reproduce
the
issue
and
wasn't
able
to
so
left
a
comment
for
the
the
issue
author
and
but
close
it
out
for
now,
and
I
think
if
they
can
still
reproduce
it
just
suggested
to
reopen
the
issue.
D
Yeah
this
is
related
to
the
ssh
on
staging
geostaging,
so
it's
working
now
sorry,
you've
already
got
to
the
next
one,
but
that
was
what
my
ticket
was.
D
F
B
So
yeah,
okay,
so
yep!
This
is
from
zach.
E
Yep
yeah
there
was
just
some
missing
classes
in
gitlab
ui
that
I
had
to
add,
and
then
I
went
back
and
followed
up
and
replaced
some
of
them.
So
just
a
technical
debt
change
here,
cool.
B
This
one
is
mine.
There
is
now
a
force
mode
in
promote
to
primary
node
check
so
that,
even
if
pre-flight
checks
fail,
you
would
be
asked.
You
still
want
to
go
ahead
and
you
can
go
ahead
especially
useful
when
you're
actually
having
a
disaster,
so
that
is
in
now
complete
with
the
documentation.
F
Yeah,
I
can
so
this
one
was.
He
douglas
noticed
that
on
staging
backfill
takes
too
long,
because
we
have
selective
sync
on,
and
it's
only
a
very,
very
small
fraction
of
the
projects
that
are
being
synced
and
just
based
on
the
like
architecture
that
that
we're
using.
That
means
that
the
backfill
process
kind
of
almost
never
finds
work
to
do
so.
F
It
thinks
oh,
there's
not
much
work
to
do
on
this
instance,
I'll
just
exit
and
wait
for
the
next
cron
minute,
but
then
it
makes
it
take
too
long
to
like
get
through
all
the
records.
So
we
temporarily
or
we
just
bumped
up
the
batch
size
and
it
should
kind
of
like
be
a
stop
gap
for
now.
B
Okay,
enable
feature
frank
to
make
registry
table.
I
think
it's
also
true
the
products
and
the
keys.
A
B
A
Yeah-
and
that
did,
I
think
there
was
some
concern
that
it
might
not
be
enabled
in
time
for
the
release,
but
that
actually
did
did
make
the
release
so
pretty
exciting.
A
B
Yeah,
this
is
jenny's.
D
B
Cool,
oh,
the
video
link
is
here.
That's
very
nice.
A
Yeah,
sorry,
just
real
quick.
I
just
want
to
make
a
note
too,
so
we
had
some
some
of
those
follow-ups.
I
think
this
was
related
to
the
zero
downtime
testing,
and
so
we
and
we
had
talked
about
last
week.
Some
follow-up
issues
had
been
created
and
I've
tentatively
moved
those
to
thirteen
four.
So
we
can
prioritize
testing
getaway
cluster
on
a
geosecondary
and
anything
that
kind
of
comes
and
anything
related
to
patrony
on
the
secondary.
A
But
if,
if
those
happen
to
get
done
soon
enough,
we
can
kind
of
move
those
back.
Those
investigations
back
into
13-3.
B
Okay,
cool:
this
is.
B
Gabrielle,
I
guess
it
is
mostly
merged.
A
Yeah,
I
think
that
was
just
a
small
change
to
move
the
tasks
that
were
added
in
13-2
into
the
get
lab
geo
name
space
while
still
there,
so
that
we,
we
didn't
have
to
add
a
definite
yeah,
add
a
deprecation
notice
for
those.
B
Maintains
more
application
settings
field?
That's
great.
Finally,
we
get
a
maintenance
mode
again.
Data
yeah.
F
I
merged
this
one,
it's
yeah,
so
the
database
fields
are
in
place,
so
all
of
the
following
maintenance
mode
work
should
be
unblocked.
F
You
can
just
key
off
the
the
database
field
now
for
whether
it
should
be
enabled
or
not,
and
the
database
field
thing
is
like
backstage
or
whatever.
So
it's
not
it's
not
being
used,
because
the
front
end,
I
think,
is
feature
flagged
already
and
not
necessarily
hooked
up,
but
anyways.
The
rest
of
the
work
is
unblocked.
F
A
That's
good
yeah
and
yeah,
and
all
that's
yeah,
as
I
can
see
on
the
screen,
has
been
moved
at
13,
for
I
think
we
we
had
brought
this
in
when
we
before
when
maintenance
was
a
slightly
higher
priority,
but
it
is
nice
to,
as
mike
said,
get
this
one
out
of
the
way
now
so
that
the
rest
of
the
work
can
be
unblocked
when
we
get
to
it.
A
E
Yes,
so
this
is
a
an
issue
from
from
a
year
ago,
but
there
was
some
misalignments
of
some
of
the
icons,
and
I
also
took
the
time-
and
I
refactored
some
of
the
legacy
code
here
for
our
node
actions
to
kind
of
get
them
up
to
the
style
guidelines.
B
I
will
take
this
off
because
I
think
it's
done.
This
is
also
from
zach.
E
Yep
and
then
so
this
is
another
old
one.
We
kind
of
just
showed
a.
We
didn't
have
any
logic
around
some
of
the
front-end
generated
errors,
and
one
of
them
was.
It
didn't
make
much
sense
to
say
that
the
version
didn't
match
the
primary
node
on
the
primary
node
when
an
error
like
this
popped
up
so
just
added
some
logic
here
to
not
let
that
air
show
up
on
the
primary.
C
B
B
C
A
Yeah,
I
don't
know
if
yeah
mike,
you
have
any
more
to
say
to
anything:
it's
just
a
continuation
of
moving
moving
other
data
types
over
to
use
yeah
to
kind
of
use
this
new,
I
guess
yeah
style
of
or
to
use
the
tables
as
the
same.
B
Okay,
I
see
it's
part
of
the
big
scalability
epic
that
douglas
has
been
working
for.
It's
super
huge
and
I
think
many
of
these
things
got
closed
in
13.2,
which
is
cool.
Yeah
this
mind
this
was
a
small
technical
depth.
There
was
a
there
was
an
option
we
were
not
using
in
the
promoter
primary
command,
so
I
removed
it
and
I
think,
also
improved
the
documentation
for
one
of
them.
B
Yeah,
that's
all
okay!
So
that's
everything
that
we
closed,
which
is
quite
a
bit
and
now
quite
a
lot
of
things
in
the
view
as
well.
Let's
start
with
this.
D
B
This
is
one
of
the
new
data
type
replications,
so
this
is
one
from
turn.
This
is
alex.
B
B
So
this
one
is
from
tune
and
let
me
just
see
where
we
are,
if
you
okay,
so
the
idea
is
we're
working
on
these
three
data
types-
external,
mr
diffs,
terraform
states
and
vulnerability
exports,
and
we
couldn't
release
it
in
13.2,
because
there
was
a
lot
of
work
to
still
be
done.
Plus
we
wanted
to
put
this
behind
a
feature
flag.
We
still
have
to
figure
out
sync
object,
storage
or
no
and
selected
sync-
and
I
think
on
his
mr
there
is,
there
is
still
some
work
to
do.
B
There
are
some
review
comments.
I
think
he's
looking
into
that's
where
this
is,
and
I
think
he
still
has
to
work
on
selective
sync,
I'm
not
mistaken.
B
B
I
have,
I
think,
a
few,
mrs
on
this,
some
to
update
the
set
service
framework
documentation
because
we
found
a
lot
of
things
that
had
to
be
different
and
it's.
We
basically
collected
a
lot
more
things
in
that
documentation.
It's
going
to
be
easier
to
add
new
replication
on
and
feature
flags
have
been
added
in
a
way
that
any
new
data
type,
that
is
the
fair
application,
is
added.
B
It
can
be
disabled
by
default
or
enabled
by
default,
and,
of
course,
when
we
release
first,
we
have
the
option
of
just
filling
it
by
default,
which
is
what
we're
doing
for
these
three
layer
types
and
on
this
one.
I'm
waiting
for
maintainer
reviews
on
my
house
as
well
yeah.
That's
where
these
these
three
are.
They
will
definitely
make
it
into
14.3
you'll,
be
able
to
find
them.
Okay,
so
yeah.
A
Thanks
for
that,
thanks
for
the
summary
and
yeah
I
just
want
to
say
yeah,
even
though
I
think
we
we
were
hoping
for
it
to
be
in
13-2,
and
it
missed
that
yeah.
It
seems,
like
everyone
made
really
great
progress
just
this
last
week
on
it,
and
so
it's
nice
to
see
everything
moving
along
quickly
and
that
there's
yeah,
and
that
seems
like
there's
a
pretty
clear,
clear
idea
of
what
what
needs
to
happen
to
to
wrap
everything
up
so
yeah
thanks
for
everyone,
who's
working
on
those.
F
Yeah
same
same,
thank
you,
crete
and
okay.
So
this
one
was
a
bug
for
the
package
file,
implementation.
F
We
and
and
yeah
so
now
we
now
we
properly
exclude
remote
stored
files.
If
sync
object,
storage
is
disabled.
Therefore
staging
is
now
fixed.
It
now
shows
package
files
as
nothing
to
sync
because
they
are
they're
all
object
stored.
F
So
it
sounds
oh
right,
so
the
reason
that
that
issue's
still
open,
I
think,
was
because
can
you
scroll
down
a
little
bit
to
do
yeah?
So
I
I
made
registry
consistency
worker
work
properly,
so
then
things
will
get
to
the
right
place,
but
we
also
need
to
make
the
events
the
create
events
not
run
if
the
thing
is
object
stored.
So
a
new
package
file
will
come
in
it'll,
get
replica
it'll
try
to
replicate
it,
but
it
shouldn't
have
it'll
fail
and
then
the
other
process
will
come
around
and
remove
it.
F
So
we
still
need
to.
I
still
need
to
fix
that
piece.
F
B
Okay,
add
package
files
to
status
rate
tasks.
Valerie
is
working
on
this.
I
think
this
comes
out
of
one
of
my
tasks
before
so
maybe
I
can
give
a
small
update
on
this,
so
the
status
rate
task
and
the
check
replication
verification
status
only
shows
everything
that
we
had
before
package
file.
So
every
time
we
have
new
things
replicated,
we
should
go
at
them,
which
is
what
he's
done
for
package
files
yeah
and
looks
like
there's
only
one
mrt
to
be
emerged
so,
basically
done.
We
just
need
some
decision
on
okay.
B
First,
we
need
this
is
merged.
Okay,
so
I
guess
it's
in
progress:
let's
do
two
more
store
classroom
mike.
Do
you
want
to
give
an
update
on
that.
F
Yeah,
this
is
kind
of
the
similar
problem
as
that
package
file
one.
So
this
was
fixed.
The
fix
is
in
it
actually
missed
this
one
miss
yeah,
so
it's
in
13.3.
I
think
the
mr
has
a.
F
A
Okay,
sorry
mike
did
you
say
that
the
the
main
fix
did
make
13
2
or
didn't.
F
B
Okay,
breadcrumbs
missing,
geonotes
part.
E
Yep
yeah
this.
This
change
here
was
pretty
simple:
it's
in
review
right
now
for
maintainer,
but
we're
just
missing
like
that
middle
layer
between
admin
and
geo
nodes
for
the
edit
nodes,
so
yeah,
pretty
simple
change.
B
Simon
doesn't
work
on
the
secondary
threat
of
url.
I
think
this
was
just
a
bug
and
I
am
reviewing
this
more
right
now.
B
A
Yeah,
this
was
something
that
I
think
yeah
came
from
a
support
ticket
for
a
customer
trying
to
set
set
up
geo
and
yeah
just
want
to
say
thanks
valerie
for
really
digging
into
it,
and
there
was
there
was
quite
the
long
slack
thread.
I
think
kind
of
investigating
this
so
looks
like
a
fix
has
been
found
so
yeah
nice
work.
There.
B
This
is
blocked,
enable
feature
flag
to
make
it
he
hasn't
said
anything,
but
I'm
just
guessing.
It
might
be
blocked
because
there's
another
related
which
you
might
need
for
the
feature
platform.
F
Yeah
that
yeah,
the
other
part
part,
isn't
merged.
Yet
so
we
can't
test
it
and
enable
it
yet.
B
Yeah,
do
we
go
through
the
in
dev
issues
as
well.
A
C
D
Yeah,
I
can
start
so.
The
first
two
are
just
quad
planning
issues
right
now
we're
trying
it
at
the
epic
level.
So
I
create
an
issue
for
each
milestone.
If
there's
any
issues
open
for
that
epic
or
do
for
that
milestone
yeah.
So
I'm
just
updating
the
testing
section
of
the
epics.
So
that's
the
the
self-service
framework
and
then
the
next
one
is
the.
I
think
it's
the
other.
D
Yeah,
oh
yeah,
that's
with
patrony
on
the
secondary,
so
I'll
be
updating
that
the
next
one
is
testing
the
getaway
cluster
on
a
geosecondary.
F
F
I
added
geoactive
to
this
issue
because
valerie,
while
investigating
the
other
thing,
found
the
solution
for
this,
so
he
opened
an
mr,
so
it
should
resolve
it.
The
proposal
is
kind
of
not
really
necessary
because
he's
got
a
one-line
fix
for
for
the
problem,
so
I
just
made
it
active
and
assigned
valerie
since
he's
got
that
mr
open.
B
This
is
for
me,
I
haven't
updated
the
description
yet
okay,
so
this
is
for
checking
sync
object,
storage
and
excluding
remote
starter
records.
I
have
I
just
barely
started
on
this
issue,
so
there's
not
much
time
a
petrol
is
time
by
clustering
at
one
second
replicate
from
time.
Does
anybody
have
opinions
on
this
gabriel.
A
Yeah,
I
can
provide
an
update,
so
yeah.
First
of
all,
thanks
gabriel,
has
signed
up
to
take
engineering
ownership
of
the
epic
that
this
is
a
part
of
the
secondary
nodes
should
support
postgres,
aha,
which
is
really,
I
guess,
at
the
core,
trying
to
figure
out
how
to
use
patrony
to
on
the
secondary,
and
so
this
is.
A
There
are
quite
a
few
issues
in
that
epic,
but
this
is,
I
think,
kind
of
the
core
one,
which
is
we
want
to
figure
out
how
to
configure
configure
a
petrone
standby
cluster
on
the
secondary
to
replicate
from
the
primary
and
see
just
kind
of
see,
what's
required
to
support
that.
What
kind
of
documentation,
maybe
omnibus
updates,
need
to
come
out
of
that?
So
he
just
pulled
that
into
development
today,
but
that's
a
very
high
priority
one
for
this
milestone,
and
also
I
just
wanted
to
note.
A
Thank
you,
jenny
for
going
through
these
issues
and
and
adding
to
the
descriptions-
and
I
know
you
had
some
questions
in
there,
so
I
now
that
gabriel
has
taken
ownership
of
the
epic
I'll
ping
him
as
well
to
help
collaborate
on
some
of
the
testing
stuff
and
questions
that
you
raised.
If
that
sounds,
okay,
cool.
B
Okay,
it's
from
douglas
remove
geo
idea
diploma.
F
A
Yeah,
I
think
he
had
started
on
it
a
couple
weeks
ago,
but
just
I
think
decided
to
prioritize
some
some
of
the
other,
like
I
guess,
core
architectural
work
and
and
and
prioritize
this
later,
since
it
wasn't
as
necessary
for
the
release.
B
So
this
is
a
bug
mike.
Can
you
tell
us
about
this.
F
It
was
a
bug
that,
like
I
think,
support,
kind
of
found
or
dug.
B
F
C
F
A
A
Can
speak
to
it
a
little
bit?
It's
it's
also
something
I
think
I
had
noticed
it
in
doing
that
design.
A
Thumbnails
fix
a
while
back
and
yeah
there's
this
kind
of
this
problem
with
the
authorization
headers
when
you're
you're
downloading
from
the
primaries
s3,
and
I
think
valerie
had
also
fixed
something
similar
in
a
different
issue,
a
while
back
and
and
I
think
it
just
kind
of
needs
to
be
applied
to
maybe
just
lfs
files.
I
don't
know
if
that
sounds
right
to
you
mike,
but
either
way
I
think
he's
taken
it.
Valerie
has
taken
it
on,
since
he
has
already
sort
of
dealt
with
similar
issues.
A
Yeah
yeah:
let's
I
think
we
can
take
that
off
really
what-
and
this
is
probably
something
we
need
to
adjust
in
our
process.
I
think
we
had
tried
to.
A
So
so
I
think
in
that
sense
like
it's
been
in
in
the
in
dev
column,
for
for
a
while
but
and
yeah,
and
so
we
can
kind
of
leave
it
there.
But
I
don't
know
it's
the
more.
We
like,
I
haven't
done
a
great
job
of
of
keeping
up
with
those
labels,
and
so
I
so
we
probably
need
to
revisit
how
we're
like
what
we're
doing
for
this
process.
B
B
A
Yeah,
I
can
talk
about
that
and
then
the
other
one
that's
kind
of
under
it.
Moving
the
geo
deployment
from
rep
manager
to
petroni
is
kind
of
related
yeah.
So
I
think
this
was
meant
to
this
was
meant
to
like
verify
a
fresh
geo.
A
Install
sort
of
what
ended
up
doing
was
using
the
orchestrator
to
do
a
do,
a
geo
deployment
that
used
rep
manager
and
then
kind
of
convert
that
which
we
already
had
in,
or
I
guess,
migrated
from
rep
manager
to
petroni,
which
was
kind
of
a
faster
way
to
to
go
about
this
setup
and,
I
think,
still
uncovered
kind
of
the
the
core
issues
with
using
petroni
and
geo,
at
least
in
a
single
node
secondary,
which
is
that
petroni
uses
replication
slots
to
manage
its
its
cluster
members.
A
So
so
it
it
will
like.
If
you
anytime,
you
restart
petroni,
it
will
like
delete
the
replication
slot
for
for
the
secondary
and
then
there
are
also
concerns
about
like
a
failover
in
the
petroni
cluster
and
the
secondary,
not
knowing
to
which,
like
which
patrony
member
to
point
to
so.
This
was
also
jose
and
also
demoed.
This
for
the
distribution
team
and
wrote
up
a
pretty
nice
summary
of
what
the
core
issue
is.
A
The
kind
of
the
result
of
all
this
is
that
we
we
have
a
follow-up
issue
to
explore
replication
slots
or
explore
permanent
replication
slots
as
a
solution.
We've
kind
of
done
this
testing.
The
the
main
thing
that's
left
for
me
here
and
why
I
still
have
it
in
dev-
is
just
that.
A
I
want
to
make
an
mr
to
the
geo,
validation
tests,
documentation
page
just
kind
of
pointing
to
the
issue,
and
I
guess
maybe
calling
this
a
partial
success
like
we
were
able
to
sort
of
get
it
set
up,
but
and
and
get
it
working.
But
there's
also
some
of
these
some
some
major
issues
here
that
we,
where
we
can't
really
recommend
supporting,
like
we
can't
officially
like
recommend
using
patrony.
A
Yet
I
think
now
what
we're
gonna
do
is
shift
focus
to
supporting
petroni
on
the
secondary,
since
I
think
that's
really
where
a
lot
of
the
primary
interest
in
using
patrony
comes
from
and
then
we'll
once
we
get
that
handled,
we'll
shift
focus
back
to
trying
to
get
it
to
work
with
a
single
node
secondary,
okay,.
E
Yep
so
mike-
and
I
had
a
call
about
this
this
morning,
and
so
this
is
kind
of
the
the
solution
we
came
up
to
instead
of
rewriting
the
restful
api.
If
anyone
had
followed
that
thread
of
there
was
conversation
around
creating
a
new
or
updated
restful
api
in
lieu
of
creating
a
graphql
api
and
based
on
our
conversations,
we
found
a
way
that
we
could
avoid
touching
the
api
all
together
and
instead
use
our
controllers
to
pass
the
relevant
data
to
the
front
end,
for
this
is
for
geostatus
bars
by
the
way.
B
E
See
I'm
gonna,
I'm
gonna
go
ahead
and
contribute
on
the
back
end
here
and
pick
this
up.
B
A
No
yeah,
it's
just
it's
kind
of
a
similar.
It's
it's
very
related
to
what
I
just
talked
about,
but
it
was
just
a
separate
issue
specifically
to
to
move
an
existing
geo
deployment
from
rep
manager
to
petroni.
So
I'm
planning
to
yeah
just
add
some
add
some
documentation
that
should
kind
of
cover
both
of
those
issues
and
move
them
and
then
close
them
both
at
the
same
time,
I
think-
and
maybe
I'll
I'll
I'll
hear
something
about
it.
A
When
fabian
gets
back,
I
think
I
kind
of
went
a
little
out
of
order
of
the
epic.
I
think
we
were
kind
of
skipped
to
this,
creating
a
sufficient
reference
architecture,
part
of
it,
which
I
think
we
had
decided.
We
could
also
just
do
with
with
orchestrators.
So
I'll,
probably
update
that
as
well
just
kind
of
with
some
of
the
steps
that
we
that
we
took
but
yeah,
I
expect
to
close
both
those
out.
At
the
same
time,.
A
Yes,
thank
you
for
that.
Yeah.
B
Okay-
and
I
think
that
was
it
okay,
I
guess
fabian
needs
to
go
through
the
ready
for
development
right,
yep.
A
And
I
can
take
over
and
go
go
through
that
now
awesome
yeah!
Thank
you,
kriti
for
sharing
your
screen
so
yeah.
Let
me
share
mine
and
go
through
the
ready
for
development
column.
A
So
it's
a
little
so
I'll
say
this
I'll
say
the
the
first
like
three
or
four
are
pretty
representative
of
of
kind
of
the
high
priorities,
after
that
it
gets
a
little
scattered,
and
part
of
that
is
because
we
sort
of
know
that
we
have
these
this
high
priority
or
these
high
priority
additional
data
type
epics
in
progress,
and
we
we
know
that
each
of
them
have
engineering
owners,
but
it's
kind
of
hard
to
like
I.
I
didn't
really
get
a
sense.
It's
kind
of
hard
to
like
prioritize
them.
A
So
I'll
have
a
question
to
to
ask
all
of
you
in
a
little
bit
about
maybe
how
we
should
handle
those
sorts
of
issues,
because
it's
something
I've
noticed
come
up
before
too,
but
real,
quick
I'll
just
go
over
some
of
the
top
priorities
here
in
the
ready
for
development
column,
top
one
is
creating
a
runbook
style
documentation
for
failover
with
two
sites,
a
single
node
geo,
omnibus
managed
database,
and
that's
part
of
this
epic
for
simplifying
our
planned
failover
documentation.
A
So
I
will
also
say
that
we
could
use
an
engineering
owner
for
this,
and
this
is
part
of
our
disaster.
Recovery,
viable
maturity
and
it's-
and
it
right
now
just
consists
of.
Excuse
me
these
two
issues
which
are
which
are
improving
our
documentation
for
a
failover
in
these
configurations.
So
right
now
the
the
documentation
is
a
little
jumpy,
as
noted
in
the
description
here,
and
what
we
want
to
do
is
say:
okay,
here
are
some.
A
A
So
that
is
a
high
priority.
I
think
it's
one
of
those
ones
that
kind
of
keeps
getting
overlooked
in
the
ready
for
development
column.
So
I
I
pushed
it
to
the
top
just
to
highlight
its
its
importance
and
after
that
we
have
our
first
issue
for
the
sec
for
the
snippet
replication
implementation
for
self-service
framework,
thanks
mike
for
volunteering
to
be
the
engineering
owner
on
this
one.
A
E
E
A
Cool
yeah,
so
so
that's
another
big
epic
that
we
want
to
get
started
on
in
13,
3.
A
A
And
then,
after
that,
we
have
issues
related
to
additional
data
types.
Let's
see,
oh
okay,
we
have
this
fight.
This
follow-up,
I
think,
from
what
okay
from
what
you
worked
on
in
the
pre-flight
checks
for
for
failover,
as
well
as
another
investigation
item,
but
I
think
my
my
main
question
here
is
okay,
so
we
have.
A
We
have
these
issues
for
data
types
and
and
we've
kind
of
added
a
lot
of
them
here
and-
and
it's
like,
we
know
that
we
know
that
these
epics
are
are
being
worked
on
and
that
they're
high
priority
and
that
they
generally
have
an
assignee,
which
is
the
the
engineering
owner
for
the
epic
so
like,
for
example,
okay
for
these
ones
here
like
does
it
make
sense
for
them
to
be
in
ready
for
development
if
we
kind
of
like
know
that
you're
assigned
to
them
and
that
they're
part
of
this
epic,
that's
already
in
progress,
or
do
we
maybe
like
just
move
them
on
into
the
ready
for
development
column,
sort
of
when,
like
when
the
next
item
in
that
epic
is
ready,
like
I'm,
not
yeah,
I
guess
I'm
kind
of
asking
like
what's
the
best
way
to
handle
these.
A
These
sorts
of
issues
as
far
as
the
ready
for
development
column
is,
is
concerned.
B
These
are
by
status,
ready
for
development,
they
are
planned
out
and
they
are
important
for
13.3,
so
it
makes
sense
to
have
them
here.
Usually
what
we
were
doing
was
fabian
would
put
a
few
new
issues
here
that
were
going
to
be
worked
on
for
the
next
week.
So
I'm
not
sure
all
of
these
will
be
worked
on
in
the
next
week,
but
since
they
are
ready
and
they
planned
out,
they
should
be
here.
I
guess
if
you
want
to
highlight
more
the
issues
that
are
not
assigned
to
anybody.
B
We
could
maybe
move
them
up,
because
you
know
they
don't
have
priority
labels,
so
it
doesn't
say
anything
about
priority,
so
that
is
fine
with
me
as
well.
There
are
also
corresponding
issues
that
alex
is
working
on
by
the
way
for
terraform
state.
A
Yeah
yeah-
and
I
think
that's
that's
kind
of
my
question
is:
do
we
want?
I
think
we've
generally
tried
to
keep
the
column
yeah,
like
you
said,
kind
of
representative
what
can
be
worked
on
the
next
week
and
maybe
if
there
are
all
those
things
and
they
can
move
pretty
quickly,
we
can
do
that.
A
But,
like
you
said,
if
once
we
apply
geoactive
and
ready
for
development
to
the
equivalents
that
are
that
alex
and
tone
are
working
on
this,
this
column
becomes
pretty
long,
and
so
once
you
get
past,
maybe
the
first
few
items
it's
hard
to
get
a
sense
of
what
the
what
the
priorities
are.
B
I
see,
then
we
could
move
back
a
few
of
my
issues
into
open.
Okay,
I
can
do
that
I'll.
Just
look
at
the
ones
that
are
interactive
and
move
back
all,
except
for
two
or
three
into
open.
Okay,.
A
Yeah
that
sounds
good
and
just
yeah.
Does
anyone
else
have
any
any
thoughts
on
that?
I
I
think
it's
yeah,
it's
kind
of
just
a.
I
don't
know
if
it's
like
it's
kind
of
a
general
question
too
on
how
to
handle
this
this
column
and
how
how
everyone
looks
at
it.
So
also
don't
wanna,
I
I
don't
I'm
not
necessarily
putting
out
a
suggestion
here
either.
F
I
think
I
think
it
makes
sense
to
do
it
that
way,
because
the
ready
for
development
column
is
just
like
if
you
are
ready
to
work,
and
you
don't
have
work
and
there's
for
some
reason,
you
don't
have
any
work
you
pick
from
the
top.
Ideally,
so
I
think
it
makes
sense
it's
okay
to
move
stuff
to
open.
If
you
know
they're
gonna
be
handled,
and
we
already
know
what
to
do
for
those.
F
Does
that
make
sense,
so
I
agree
with
equity
moving
some
of
them
back
out
of
ready
for
development.
A
Cool
yeah,
I
think-
and
that's
I
think,
that's
a
good
way
to
think
about
it,
so
so
so
really
in
in
that
sense,
yeah
we,
if
something
is
kind
of,
has
someone
assigned
or
might
not
be
in
the
first
few
items,
it's
okay
to
be
in
open
yeah
thanks
for
that,
I
think
other
than
that
yeah.
So
we
have
some
of
these.
Some
of
these,
I
guess
in
the
holding
tanks,
so
so
to
speak
in
open
kind
of
like
we.
A
We
know
what's
what's
happening
with
them,
one
that
I'm
a
little
uncertain
about
and
let's
see,
yeah
josh
you're
still
on
the
call.
Maybe
you
can
provide
some
insight
here.
I
think
we
were
going
to
verify
geo
with
postgres
12,
with
the
assumption
that
it
was
making
13
2.
I
think
I
saw
that
it
wasn't
quite
going
to
be
in
the
release.
G
From
the
right
size,
she'll
know
better
as
of
course
well,
like
you
know,
dj
or
steven,
but
the
update
I
have
is
that
it
just
missed
and-
and
so
it's
probably
merged
at
this
point
in
time,
but
it
it
just
missed
the
branch.
A
Okay,
so
we
could
probably
still
like
test
it
with
a
nightly
build
or
something
like
that
if
we
yeah.
A
Okay,
okay
sounds
good,
so
I'll
leave
it
here.
I
think,
since
it
won't,
I
think
we
have
quite
a
few
other
pretty
high
priorities.
I'll
leave
it
here,
so
we
don't
lose
track
of
it.
It
may,
unless
you
think
otherwise
it
it
may.
A
Move
towards
the
end
of
the
milestone,
or
maybe
even
beginning
of
13
4,
once
it
becomes
available
in
the
13.3
package.
But
if
we
can
verify
ahead
of
time,
we'll
we'll
we'll
try
to.
G
Yeah,
if
we
can,
it
also
might
be
good
to
connect
with
the
distribution
team,
but
I
I
think
they're
trying
to
hit.
G
Upgrade
stories
for
multi-node
in
13
3
for
postgres
12..
I
believe
so
so
that
that'll
be,
you
know,
probably
a
pretty
wider
audience
that
we
want
to.
You
know
enable
for
pg12,
but
you
know
if
geos
supports
it,
doesn't
test
it
until
1304
is
probably
not
the
biggest
deal.
We
have
all
the
way
until
february
march
to
really
start
turning
this
on
and
they
can
opt
in
and
start.
You
know
making
it
opt
out
shortly
thereafter
sure.
A
Cool
yeah
that
that
makes
sense
yeah,
so
that
is
yeah,
so
just
just
to
kind
of
summarize
where,
where
we
are
yeah
so
still
in
terms
of
13
3
planning,
so
yeah
high
priorities,
wrapping
up
wrapping
up
support
for
the
additional
blob
types
package
file,
replication
is
is
going
to
be
released
in
13-2,
getting
started
on
snippet
replication,
and
then
these
testing
and
and
support
issues
specifically
getaway,
cluster
and
and
adding
support
for
petroni
on
the
geosecondary.
A
I
think
douglas
is
continuing
to
make
a
lot
of
progress
on
backfill
operations,
and
I
think
we
can
expect
to
have
foreign
data
wrappers
removed
this
milestone,
but
we
might
need
to
check
in
with
him
there
over
the
next
couple
of
scheduling
calls
and
then
I
think
the
the
only
one
that
doesn't
really
have
a
clear
engineering
lead
or
someone
kind
of
moving
this
forward.
Are
these
documentation
ones
for
a
planned
failover?
A
So
you'll
likely
hear
me,
keep
talking
about
it
and
trying
to
suggest
them
to
different
people
until
so
until
we
end
up
having
someone
on
them,
but
that's
that's
kind
of
one
I
have.
I
I'm
gonna
have
my
eye
on
and
then
finally
front
end
stuff.
I
think
zach
you're
going
to
yeah
be
working
on
some
some
back
end
related
stuff
for
the
self-service
front
end.
So
that
is
awesome.
A
Thank
you
for
for
doing
that,
and
then
we
also
have
the
new
design
from
or
design
proposal
from,
xunjung
and
in
an
issue
and
and
everyone's
provided
some
really
great
feedback
on
that.
So
hopefully
we'll
see
some
some
updates
there
and
hopefully
have
some
some
new
designs
that
we
can
start
working
on
in
the
coming
weeks.