►
From YouTube: Pages Priorities Sync
Description
Discussion about pages rearch and other priorities
https://about.gitlab.com/direction/release/pages/
A
All
right
so
we're
here
for
our
pages
planning
sync
in
our
last
meeting.
We
just
went
through
all
of
the
pages
work
that's
in
flight
in
regard
to
the
read
architecture,
and
then
we
touched
on
some
future
looking
priorities
for
Gillett
pages,
so
I
just
wanted
to
kind
of
get
an
update
on
the
API.
Rollout
I
have
been
following
some
stuff
on
the
get
leadpages
channel,
but
I
see
that
you
also
have
a
new
blocker
from
Umbra.
So
love
to
hear
some
more
about
that.
Yeah.
B
Actually,
I
didn't
spend
much
time
on
this
over
the
last
two
weeks
and
Josh
and
amar
was
mostly
working
on
this
one
yeah.
Basically,
we
hit
the
rate
limit
on
the
API
notes
and
then
I
wanted
to
wait
until
we
resize
the
API
fleet
first
and
we
decided
it
like
yesterday.
So
then
he
started
and
then
he
has
some
other
blockers.
He
finally
resulted
couple
hours
before
and
now
he
waits
on
us
to
give
him
L
some
script
to
test
the
weight
limit
on
stage
and
crust.
B
So
right
after
this
meeting,
I
guess
I
will
go
and
maybe
help
him
with
that
yeah
right
after
we.
So
the
idea
was
to
test
this
on
staging
them
test
this
in
production
and
then
finally
go
and
I
don't
know.
Roll
out
pages
appear
to
be
high
percentage
that
we
have
at
the
moment.
So
hopefully
all
this
can
happen
tomorrow.
Maybe
on
Thursday,
yeah
and
I,
don't
know
in
the
ideal
world
this
week
we
can
hit
100%
I,
don't
believe
in
that,
but
in
the
idea
work
this
is
possible
yeah.
B
So
yeah,
that's
about
the
arrow
out.
Yeah
I
wanted
to
like
discuss
the
deep
one
more
time.
The
way
I
understand
it
is
like
we
need
to
make
everything
works
like
to
allow
people
to
switch
to
a
new
feature
or
something
before
the
13
that'll
be
before
the
major
release.
Then
one
major
release:
we
make
this
duplication
message,
but
we're
not
removing
and
and
then
like
three
months
later,
we
remove
in
the
future,
but
how
this?
How
I
understand
it
and
if
we
are
not
able
to
duplicate
it
on
13th
at
all?
B
A
So
there's
apparently
two
approaches
to
it.
So
if
a
feature
is
introduced
just
as
you
said
it,
we
announce
that
this
is
something
that
will
be
available.
It'll
be
available
on
the
major
release
date.
Then
we
can
also
announce
at
the
major
release
date
that
this
feature
will
be
marked
as
deprecated
and
we'll
end
support
of
it.
Meaning
will
actually
remove
it
in
the
next
major
release,
which
is
exactly
what
you
said.
B
A
The
deprecation
message,
since
it
depends
on
if
the
new
features
available,
so
if
the
new
feature
isn't
going
to
be
available
until
13
No,
then
we
can
potentially
announce
in
13
know
that
the
new
feature
is
available
and
that
we're
going
to
continue
support
of
the
disk
source
and
we're
going
to
defecate
that
their
stores
in
1402.
So
that's
we
don't
necessarily
have
to
announce
the
new
feature
in
1210.
A
B
It's
probably
better
if
I
just
explain
why
I'm
asking
yeah
we
have
this.
We
have
a
few
magic
words
like
three
of
them,
which
Jaime
was
working
on,
which
allowed
these,
like
opt-out
method
of
switching
to
the
new
API
source
right
and
they
are
not
merged
note
any
of
them.
I
guess
or
one
of
them
got
much
today,
I'm,
not
sure.
B
A
B
Make
it
but
actually
yeah
actually,
given
that
I
I
was
the
same
as
Nathan
I
saw
that
12.10
ends
tomorrow,
not
the
week
after.
So
actually,
if
we
will
merge
all
these
3m
hours
and
we
still
have
a
week,
so
we
can
test
it
in
production,
I
mean
if
we
will
finish
roll
out
this
week
or
maybe
Monday,
then
we
can
actually
even
duplicate
this
source
on
13,
but
all
if,
like
in
the
ideal
world
again
I
mean
yeah.
B
If
we
merge
all
these
free
Mars
like
tomorrow
and
throw
out,
goes
well
and
in
Monday,
we
can
decide
that
okay,
it's
actually
ready,
we
tested
it
on
dot-com
and
everything
is
fine
there
and
we
have
this
opt
outs
which
for
user.
So
then
we
can
announce
on
thirteen
dodo
that
hey
we
duplicate
this.
You
have
this
switch.
Now
we
actually
need
to
announce
the
switch
in
trouble.
B
A
Merge
for
the
1210
release
post
it'll
go
out
on
the
22nd,
so
really
the
release
post
ends
up
getting
a
lot
of
changes
between
now
and
the
22nd.
So
we
have
like
a
big
runway,
the
biggest
like
catch
there
is
that,
typically,
the
release
post
manager
likes
to
have
all
the
content
approved
and
merged
into
our
draft
post
by
the
17th,
so
that
we
can
get
to
you
from
marketing
all
that
stuff.
Yeah.
B
A
B
A
B
B
A
B
A
As
far
as
what
you,
what
do
you
think
in
between
announcing
this
and
actually
removing
the
feature
set?
If
we
could
make
the
case
that
we
would
want
to
not
maintain
this
for
another
year
after
we
announced
the
availability
of
the
new
architecture,
so
I
just
wanted
to
get
your
thoughts
on
that.
Would
this
be
something
that
we
would
the
discourse
that
is
make
it
available
to
people
and
then
deprecated
the
discourse
before
14.0
we
and
remove
it?
We
can.
We
can
make
that
choice,
and
we
can
make
that
case.
B
I
know,
first
of
all,
it's
kind
of
a
big
depredation
I
mean
if
we
just
remove
it
in
the
usual
milestone
and
user
updates.
They
get
love
and
I.
Don't
know
not
everybody
read
the
release,
notes
except
for
this
duplication
messages,
so
I
guess
some
people
may
be
surprised
and
very
negatively
surprised
with
doing
this.
B
The
other
point
is
that
actually,
like
everybody
who
wants
to
remove
this
code,
but
right
now,
I
can
say
I
mean
removing
this
code
is
actually
another
work.
We
need
to
do
it's
like
it's
another
refactoring,
and
it's
not
that
simple.
It's
not
like
one
day
so
I
mean
and
I
don't
really
know
how
much
problems
this
tech
depth
will
actually
create,
so
maybe
actually
supporting
it
for
another
year.
Isn't
that
bad?
Maybe
it's
okay,
and
maybe
we
will
not
touch
this
code.
B
B
A
So
we'll
stick
with
for
this
particular
deprecation
and
removal
having
it
being
on
the
major
release:
cadence,
that's,
okay!
What
I
would
like
us
to
do
is
make
sure
that
we
understand
the
bugs
in
the
backlog
and
what
it
means
to
fix
them
in
the
new
architecture
versus
on
the
old
architecture.
So,
for
all
the
things
that
are
currently
in
the
pages
bug
backlogs
as
you.
B
B
No
I
think
I
think
there
is
like
difference
between
like
duplication
and
removal.
We
I
guess
we
can
duplicate
it
in
the
sense
that
guys
too,
in
order
to
fix
this
issue.
If
you
have
it,
you
need
to
go
and
switch
to
the
new
way
of
configuring
pages,
and
then
you
this
issue
will
be
resolved
so
for
old
architecture.
We
don't
need
to
fix
that,
and
this
I
think
we
can
do
in
any
milestone.
So
basically
it's
like
recommending
a
workaround.
We
don't
need
to
wait
for
a
major
release
for
this.
B
Also
well.
Well.
I
have
this
sword
in
my
head.
It's
a
it
actually
will
be
super
nice
to
have
maybe
some
issue
or
something
in
the
like,
through
the
major
releases,
to
collect
the
stuff.
We
want
to
duplicate
because
I
just
noticed
on
our
team,
it
energy
and
in
the
press
post
a
couple
of
issues
in
the
duplication
marks
related
to
pages
and
actually
like
I,
believe
we
have
much
more
of
them,
but
it's
kind
of
hard
to
remember
all
of
them
right
now.
B
B
B
A
I
think
what
I'm,
when
I?
What
I
don't
know
is
when
I
look
at,
like,
let's
say
a
left
and
crypt
bugs
or
an
error
bug
that's
currently
in
the
planning
board
and
that
I'm
like
about
to
assign
to
somebody
it
away,
should
I,
be
making
notes
in
the
proposal
that
we
need
to
consider.
If
this
is
something
that
we
should
fix
on
the
old
architecture
and
the
new
architecture
or
if
the
recommendation
is
just
going
to
be
for
everybody.
That's
on
the
old
architecture.
A
In
order
to
receive
this
fix,
you
should
upgrade
to
a
new
one.
I
just
want
to
make
sure
that
I'm
able
to
advise
like
account
teams
and
be
in
the
users
of
pages
that
were
no
longer
going
to
be
deploying
bug,
fixes
on
the
old
side
on
the
old
source
or
if
this
is
like
a
strategic
grooming
opportunity
where
we
go
through
the
bugs,
and
we
say
all
of
these
bugs
are
gonna
get
resolved
by
the
new
architecture,
which
I
think
we
have
another
issue
out
there
today.
A
It
might
need
to
be
like
crew
a
little
bit
to
like
kind
of
have
that
be
published.
As
a
source
of
truth,
basically
I
just
don't
want
us
to
be
duplicating
effort
when
we
do
maintain
these
new
sites
and
I
want.
Are
these
two
sources
and
what
I
do
want
to
be
able
to
provide
prescription
to
the
people
with
accounts
that
are
using
pages
that
yeah
just
go
to
the
new
new
configuration
and
you'll
avoid
this
problem?
Yeah.
B
What
I
would
do
is
actually,
first
of
all,
we
have
this
couple
issues
like
first
for
API
rollout.
Second,
for
like
object,
storage,
implementation
right,
so
basically
I
would
mark
all
these
bugs,
which
should
be
resolved
by
these
issues
as
blocked
by
those
two
and
once
we
have
them.
Have
them
done
like
rollout.
Api
makes
it
deeper
difficut
it
even
if
it's
not
a
major
release.
B
A
B
A
I
think
John
what
I
could
use
help
with
on
this
is
either
some
wrangling
of
all
of
the
issues
that
we
feel
like
are
going
to
be
resolved
by
the
pages.
We
are
connec
sure
yeah,
so
that
I
can
go
through
and
make
note
that
hey
this
will
be
solved
by
the
Ryoka
tech
chure.
In
order
to
resolve
this
problem,
you
know
opt-in
or
upgrade
to
the
new
to
the
new
source,
new
method,
new
configuration.
A
Be
proactive
for
these
users,
she's
I'm,
just
I'm
just
worried
that
we're
not
yeah,
okay,
be
misleading.
People
and
I
can
also
talk
to
Suzanne
from
a
tech
writer
perspective,
but
this
makes
sense
to
have
like
as
its
own
section
inside
the
docs.
So
people
understand,
like
all
of
these
issues
related
to
the
Ryoka
tech
chure,
are
going
to
get
solved
by
you,
upgrading
or
opting
in
or
whatever
yep.
B
I
mean
we
still
need
to
we'll
need
some
section
in
the
dog
just
with
the
description
of
how
to
move
to
the
new
york
attack.
Sure,
basically,
with
this
opt-out
approach
and
with
immigration
plan,
if
you
have
a
different
servers,
so
that's
what
I
was
referring
to
when
I
said,
link
to
the
communication
right.