►
From YouTube: 2022-02-07 Database Scalability WG Weekly
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
Okay,
probably
let's
get
started
today-
is
the
february
7th.
This
is
the
database,
scalability
working
group
and
first
item
and
significant
updates
since
last
meeting
timelines
there,
so
everybody
feel
free
to
check
and
there's
no
change
to
the
timeline
and
no
confidence
level
change
as
well.
So
I'm
going
to
go
through
the
sharding
groups
updates
one
by
one.
The
first
one
is
actually
phase
phase
two
deployment
to
the
staging
environment
that
was
done
kudos
to
jose
and
the
data
for
deploying
the
ci
cluster
to
the
staging.
C
So
that
enabled
us
the
phase
three
goal.
Rollout
next
is
exactly
dylan.
The
tone
were
able
to
roll
out
the
cia
separate
the
ci
rate
in
in
a
staging
environment,
and
we
are
keeping
it
50
percent
like
last
time.
We
did
it
so
that
that's
the
best
way
to
discover
what
catch
issues
in
the
staging
now
the
degrees
craze
are
to
the
ci
cluster
dedicated
ci
cluster
and
also
then
pull
in
number
three.
We
will
be
starting
rolling
out
the
phase
three
or
stage
three
deployment
in
production
once
the
cluster.
C
The
new
petroleum
cluster
is
ready
in
the
production
environment.
So
that's
the
the
other
part,
the
other
half
of
phase
three,
we
finish
the
staging
next
will
be
production
environment
and
a
few
other
changes
I
remember
bullied
for
is
this
feature
fla
this
issue,
the
ci.
I
mean
we
labeled
all
the
issues,
that's
not
required
for
for
the
first
integration
as
a
ci.
C
Decomposition
follow-up
then
moved
to
a
dedicated
epic
to
keep
them
organized,
so
we
can
follow
up
after
the
first
iteration
is
deployed,
and
also
we
completed
the
law
out.
The
production,
100
percent
production
world
of
the
future
flag
track
gilad
ski
schema
in
current
transaction,
to
detect
the
modifications
to
run
db.
That
was
done
over
the
last
week
since
last
update
and
then
body
number
six
here.
So
we
do
have
a
candidate
plan
for
rollout
phase
four
and
then
the
first
step
is
to
test.
C
C
This
will
be
the
blocker
war
or
a
requirement
to
enter
the
face
for
our
route
and
next
one
number,
seven
quickstart
from
fabian.
Thank
you
very
much
fabian
for
doing
that,
math.
So
the
conversation
we
have
roughly
81.
This
was
made
about
a
week
ago,
so
the
number
can
be
slightly
different,
but
it
was.
C
We
had
roughly
81
open
issues
remaining
out
of
the
271,
so
that's
roughly
about
30
percent
of
the
backlog,
so
we
have
about
30
remaining
in
the
development
backlog
and
then
about
out
of
the
81
building
issues.
24
are
labeled
ci
decomposition
follow-up,
so
they
are
not
required
for
the
first
iteration.
So
roughly
those
are
roughly
seven
30
percent
of
the
outstanding
issues.
C
So
what
this
means
is
that
the
infrastructure
deployment
carries
more
and
more
wage
in
upcoming
months,
because
the
development
work
becomes
ready
for
more
and
more
development.
Work
will
become
ready
for
deployment
and
also
development.
Work
will
start
running
start
running
down
slowly.
C
A
That
helps
us
ensure
that
you
know
what
is
in
that
epic
is
all
of
the
work
that
we
need
to
do
in
order
to
deploy
a
decomposed
database
on
gitlab.com
and
the
other
work
is
what
needs
to
happen
in
upcoming
next
iterations
of
our
self-managed
customers,
and
I
think
that
reflects
better.
What
we're
actually
trying
to
accomplish
makes
it
easier
to
see
how
far
along
we
are
yeah,
that's
important
to
know,
because
the
stats
may
change
a
little
bit.
I
think
sort
of
commenting
to
what
june
said
earlier.
C
Cool
any
questions.
B
Yeah,
so
I
excuse
me,
I
was
looking
at
the
issue
that
you
said
was
opened
up.
I
see
it
there,
I'm
trying
to
figure
out
why
it's
not
showing
up
on
the
ops
board
I've
been
using
for
tracking,
but
I
think
so.
We
have
one
issue
open.
I
think
that
all
the
other
ones
closed
last
week,
so
I
think
we're
pretty
good
there's
not
a
not
a
huge
update
there,
but
I'll
look
into
why
the
labeling
on
that
one
is
not
why
it's
not
showing
up.
B
B
C
Four
and
was
discussed,
I
discovered
the
last
week.
C
Okay,
oh
wait!
William,
is
not
here
so
I'll
update
for
him,
so
there
were
two
issues
for
a
secure
section.
The
first
one
scheduled
both
are
scheduled
over
14.8
and
they're,
both
on
track
according
to
maine's
update
last
friday.
So
we'll
just
keep
track
of
those
progress.
C
No,
so
this
update
from
the
team
was
also
last
friday.
One.
There
are
two
issues
for
the
import
team.
One
is
four
phase:
four
one
is
for
space
six
and
the
fifth
four
is
in
the
review
stage
and
the
other
physics.
According
to
team,
the
team
probably
can
get
on
late.
You
know
get
it
done
prior
to
physics,
which
starts
in
mid
march,
so
we
still
have
one
and
a
half
months
to
get
the
physics
issue
done
so
we'll
keep
track
in
the
daily
standard
of
the
stakeholder
from
stakeholders.
C
And
the
infrastructure,
I
mean
anyone
from
the
infrastructure
here.
No
so
I'll,
just
update
from
the
this
morning's
stakeholders
stand
up,
so
the
infrastructure
team
will
find
someone
to
get
started
on
this
issue
and
especially
get
the
testing
issue
done.
The
testing
issue
is
mentioned
here
at
the
top
in
footage
number
one:
a
and
roma.
D
C
You
and
then
body
number
two
review
the
rollout
progress,
so
the
chart
screen
capture
of
the
charts
here.
So
we
are
our
issue.
Burnout
is
accelerating
and
you
can
see
the
the
delta
or
the
data
is
dropping.
So
that's
what
we
are
going
to
see.
We
expect
to
see
this
trend.
The
the
data
will
slowly
drop
to
complete
zero.
C
C
And
mr,
I
might
burn
up
continue
to
save
same
pace,
so
we
are
not
backing
up.
We
don't
have
a
c
increase
dogs
that
deny
mr.
So
that's
good.
Also
any
questions
about
this.
Let's
charts.
C
Okay,
then
no
risks
and
also
number
four.
The
end
is
not
endowments,
but
our
next
significant
date
is
february,
22nd
or
23rd.
That's
our
entry
of
phase
four!
So
that's
a
date.
We
need
to
keep
in
mind.
We
need
to
get
everything
ready
for
entering
phase
four,
so
the
teams
are
working
towards
that,
especially
the
infrastructure
team
is
working
on
the
second
pg
monster
cluster.
C
Okay,
other
discussions,
so
dylan
dylan
is
the
acting
manager
of
starting
now.
So
I'm
wondering
if
everyone
here
is
okay
to
alternate,
but
this
meeting
every
other
week,
so
this
week
is
a
morning
time
for
us,
then
the
next
week
will
be
the
afternoon
time
for
for
us,
so
that
didn't
can
join.
I
just
don't
want
to
touch
base.
Everyone
is
that.
Does
that
work
for
you
or
we
just
to
keep
this?
I
can
continue
to
run
this
meeting.
Always
ellen
is
providing
a
async
update
anyways.
A
I
mean
my
preference:
is
I'm
happy
with
that,
like
there's
no
issue,
but
I
will
not
be
able
to
join
because
that
is
way
of
my
work
day.
So
it's
it's
up
to
to
you.
I
feel
very
confident
that
I
can
provide
the
updates
needed
asynchronously.
C
Cool,
thank
you
for
the
for
the
input
so
dylan
preferred.
I
think
he's
believed
that
async
works
the
best
so
I'll,
just
fight
that
that
will
confirm
with
steel's
preference
and
we'll
make
a
decision
I
will
if
needed.
I
will
make
a
change
to
the
schedule,
but
I'll
make
that
decision.
It
looks
like
everybody
is
open
to
any
any
option.
D
You
and
to
be
clear,
I
I'm
not
asking
or
describing
any
changes
yet
merely
collecting
data
thinking,
long
term
engineering
data
trajectory.
So
do
we
use
severity
labels
for
all
the
issues
in
this
workstream.
Is
there
a
is
there?
Can
all
the
issues
be
clearly
mapped
to
a
severity
or
that's
still
yet
to
be
defined?.
C
A
We
we
don't,
we
don't
use
any
severity
issues
for
regular
issues.
We
use,
I
think,
if
we
had
a
bug
you
know
we
would
classify
that,
but
any
of
the
other
issues
aren't
are
the
issues
in
our
backlog.
They,
maybe
I've
been
using
it
wrong.
I
don't
know,
but
I've
I've
reserved
severity
and
priority
issues
for
bug
classification.
A
That
is
when
I
applied
them.
So
if
you
look
at
you
know
a
random
phase,
four
issue
that
we've
been
dealing
with,
then
they
will
not
usually
have
that
because
we
didn't
need
that
fidelity,
because
the
assumption
is
for
a
lot
of
the
workers,
it's
sort
of
severity,
one
in
the
case
of
like
we
need
to
do
it.
Otherwise
we
can
ship.
So
it
hasn't
really
happened.
A
I
think
it
will
become
more
relevant
when
we
start
rolling
out
features
into
into
production
and
we
see
issues
and
then
we
see
bugs
and
then
we
have
to
actually
act
on
them.
We
had
a
couple
of
those,
but
they
are
still
pretty
rare,
but
they
could
become
more
prominent.
A
Yeah
as
a
follow-up,
it's
like
you
may
be
able
to
help
me
with
this.
It's
like
I
have
used
severity
labels
and
priority
labels
for
clearly
communicating
the
impact
of
something
that
is
labeled
type
bug.
I
have
not
done
this
for
others,
because
I
thought
that
was
where
we
were
using
them.
Is
that
going
to
change
potentially.
D
I'm
still
collecting
data,
I
think
using
the
severity
for
the
bugs
in
this
workstream
is
the
correct
going
by
the
handbook
in
the
current
form
and
I'm
thinking
on
long
term.
How
do
you
want
to
help
capture
help
provide
a
fidelity?
I
think
thinking
better
better
to
check
better
visibility
in
the
burn
down
of
the
the
issue,
so
I'm
still
collecting
there
and
thinking
on
how
easy,
okay.