►
From YouTube: Manage:Import 14.9 planning
Description
This is the sync planning session for the 14.9 milestone for the Manage:Import group.
Planning issue shown:
https://gitlab.com/gitlab-org/manage/general-discussion/-/issues/17460
A
A
A
B
A
C
A
Percent,
okay
yeah:
I
feel
like
this
time
around.
We
probably
should
try
to
get
some
of
those
quality
issues
solved,
especially
with
tests
that
are
not
doing
what
we
need
them
to
do.
They're
not
like
if
they're,
not
completing
or
not
complaining,
all
the
time,
they're
not
helpful
if
we
can't
trust
them.
A
A
A
So
clearly,
whatever
somebody's
doing
to
reach
out
to
the
community,
seems
to
be
working.
That
said,
these
couldn't
have
hit
at
a
worse
time,
for
george
to
not
be
able
to
help
along.
So
I've
been
thinking.
You
know
other
engineers
and
can
try
to
get
help
as
much
as
I
can
from
outside
the
group
to
to
shepherd
these
merge
requests.
But
you
know
some
things
are
getting
done
by
the
community.
A
At
least
from
the
numbers
perspective,
somehow
I
don't
see
the
these
numbers
really
translating
between
the
two.
So
I
wonder
exactly
how
that
works,
but
I
have
noticed
that
the
front
end
velocity
has
dipped
a
little
and
that's
understandable
with
ilia,
not
being
you
know
not
being
able
to
work
in
148
as
much
as
we
originally
planned.
A
D
A
A
What
beckham
is
working
on
in
order
to
for
them
to
understand
sort
of
what
our
priorities
are.
You
know
what
the
importance
and
the
priority
of
these
tasks
are
that
we're
currently
working
on
because
we're
getting
a
lot
of
requests,
for
you
know
different
things
that
need
to
get
done
from
different
directions
and
they
all
have
in
their
own
world
and
in
their
own
little
in
their
vacuum.
They
have
high
importance,
but
we
we
do
have
to
slot
them
against
everything
else.
A
So
you
know
infra
devs,
requests,
customer
escalations
security,
all
of
those
are
top
importance,
but
they
can't
all
be
the
top
issue,
especially
if
you
have
multiples
in
each
bucket.
So
I've
tried
to
sort
of
narrow
that
down
here
a
little
bit
and
create
a
more
focused
area,
for
hopefully
it's
helpful
to
george,
to
know
sort
of
what
to
really
focus
on
and
like
what
all
the
things
are
that
he
can
ignore,
which
is
everything
outside
of
this.
A
A
A
That
would
allow
george
to
move
down
the
list
and
pick
up
the
next
thing,
which
is
this
one
really
important
for
the
thing
that
came
out
of
out
of
an
incident.
I
believe
where
we
need
to
figure
out
how
to
not
not
make
a
make
long
db
transactions
because
they
seem
to
hurt
our
availability.
So
that's
something
we
need
to
do
spike
on
and
understand
the
next
step,
and
maybe
next
step
is
the
first
step
is
easy,
perform
the
first
step,
but
at
least
we
need
to
run
through
that.
A
That
is
part
of
our
engineering
allocation
bucket,
as
well,
so
for
us
to
be
able
to
complete
our
engineering
allocation.
This
is
the
next
important
item,
the
one
below
that
is
also
infrared
related
and
it's
a
general
imports
and
mirrors
seem
to
saturate
the
cpu
in
generally,
so
we're
looking
to
see
if
we
can
do
something
about
that,
I'm
not
sure
exactly
what
and
how
we
do
not
want
to
rate
limit
anything
that
we
do
in
theory,
but
we'll
have
to
look
into
that.
A
I've
asked
for
you,
know
other
groups
to
contribute.
There
were
some
source
code
developers
who
chimed
in
so
I've
asked
if
they
have
bandwidth
to
help
with
this.
If
not,
this
will
wait
for
us
to
to
pick
up,
and
then
this
is
this.
This
is
another
database
decomposition
related
issue
that
we
have
until
the
end
of
1409
to
solve,
but
it
needs
to.
You
know
it
needs
to
be
part
of
49,
so
this
will.
A
The
last
security
issue
that
hadn't
been
picked
up
from
our
backlog,
which
is
super
that
we're
like
at
the
bottom
of
it
was
was
getting
picked,
is
getting
picked
up
by
the
security
burn
down
team.
So
the
team
that's
burning,
going
on
bringing
out
all
security
issues
for
that
they'll
pick
up
this
issue
and
already
has
been
assigned,
and
the
next
down
in
the
security
is
the
threat
model
that
we
that
nick
developed
for
the
gitlab
migration
we'll
need
to
start
doing
the
research.
So
we
had
the
you
know.
A
We
split
it
into
multiple
issues
and
probably
just
need
to
start
picking
them
one
at
a
time.
So
maybe
one
per
milestone
or
some
way
of
burning
down
through
the
research
so
that
we
I
so
that
we
can
proactively
see
if
there
are
any
evil
vulnerabilities
in
this
area
and
not
just
wait
for
it
to
come
back
as
a
high
priority
issue
and,
last
but
not
least,
is
finishing
the
project
migration.
A
For
for
the
gitlab
migration
initiative.
We
are
not
that
far
from
the
end,
it's
just
like
the
question
of
how
much
time
can
we
put
against
it
and
how
fast
can
we
bring
over
the
finish
line?
So
I
feel
like
we're
close,
but
like,
depending
on
like
how
everything
else
plays
out
in
the
priorities
we
may
or
may
not
be
able
to
push
it
over
the
finish
line.
A
Next,
two
milestones,
but
that'd
be
great
at
the
point
where
we
feel
like
we
have
this
mvc,
which
is
really
which
creates
a
parity
between
the
project,
export
import
and
the
group
and
project
migration,
so
that
you
know
anything
that
the
export
import
was
able
to
do.
You
can
also
do
it
through
migration.
A
I
will
initiate
some
changes
in
the
ui
to
first
of
all,
deprecate
and
like
let
people
know
that
the
project
export
import
will
get
deprecated
at
some
point
in
the
future,
announce
that,
but
also
take
it
out
of
the
ui
so
make
that
not
be
the
easy
thing
to
do,
but
maybe
something
that
is.
You
know
that
you
can
do
through
the
api
only
in
the
end,
but
generally,
I
would
like
to
discourage
the
usage
of
project
export
import
in
favor
of
migration.
A
Two
things
we
get
out
of
that
one
is
migration,
gets
a
lot
of
eyes
on
it
and
we
get
feedback.
We're
able
to
turn
around
bugs
we
figure
out.
What's
the
next
most
important
thing
like
we
get
feedback
on
what
features
they
want
to
see,
we
get
feedback
on
what
works,
what
doesn't
and
we're
able
to
actually
make
it
a
better
product.
A
A
A
A
So
that
is
the
back
end.
I
just
kind
of
wanted
to
walk
through
this
to
get
everybody
on
the
same
page.
I've
listed
that
here
as
well,
so
for
49.
Really,
the
expectation
is
that
we
would
get
to
the
spike
on
the
long
db
transactions
and
we
needed
to
complete
the
db
decomposition.
So
those
are
like
the
two
top
issues
that
need
to
get
done
for
14.9
9
on
the
security,
if
there's
anything
incoming
which
right
now
there
isn't,
but
if
there's
anything
incoming,
we
might
pay
attention
to
depending
on
how
severe
it
is.
A
B
You
never
know
how
much
time
you're
gonna
spend
on
one
issue
versus
the
other,
and
I
mean
the
long
db
transaction
is
a
spike.
It
doesn't
mean
it's
going
to
be
solved
after
you
know
the
the
spike
is
completed.
Maybe
it's
going
to
be
a
bigger
change.
Maybe
it's
going
to
be
a
quick
win
that
we
are
able
to
ship
so
the
db
decomposition.
B
D
B
B
A
A
B
B
I
think
it
will,
but
you
know
you
never
know
what
kind
of
issues
we're
going
to
introduce
and
that's
another
thing
that
you
mentioned.
I
guess
you
know
the
brick
kitchen
project
import
export
is
great,
but
we
might
also
introduce
new
things
with
the
gitlab
migration,
which
underneath
is
more
or
less
the
same
process.
You
know
so
yeah
anyway,
I
just
derailed
it.
B
A
That's
fair,
I
know
they've
done
some
research
and
some
investigation
and
they've
tried.
The
you
know
shared
this
issue
where
they've
looked
into
group
migrations,
when
the
groups
were
available
through
the
api
and
concluded
that
it
worked
for
them,
I
think,
and
then
they
said
that
they
would
work
on
the
project
as
well.
A
A
B
It
was
the
proposal
was
one
week
by
name
yeah,
that's
how
much
time
I'm
gonna
spend
given
I'm
going
to
also
look
at
other
things
like
the
vmware
escalation
that
doug
is
going
to
be
helping
to
bend.
So
I
don't
think,
there's
anything
that
doug
will
be
able
to
do
there,
because
I
think
that
we
solve
it
already,
but
we'll
see.
Okay,.
A
A
But
hopefully
this
is
the
end
of
that
the
validation
of
the
gtrl?
I
would
have
thought
that
was
going
to
be
so
long-living.
This
is.
This
is
really
cool,
so
this
is
the
viewing
the
history
for
all
project
imports
and
india
worked
on
both
backhand
and
front-end.
I
think
the
back-end
is
in
review,
so
hopefully,
when
that's
done,
we'll
have
we'll
have
that
view.
A
This
is
the
one
that
we
looked
at
last
time,
which
was
really
cool.
It
wasn't
able
to
make
progress
on
it
because
he
was
out,
but
this
is
kind
of
exposing
that
api
replied
the
the
the
reply
on
the
status,
so
we
have
a
new
status
that
we
can
like
a
detail
status.
We
can
query
now,
for
github
importer
tells
us
sort
of
by
each
one
of
the
type
of
things
how
how
many
we've
imported
out?
How
many
so
that
to
do
that,
you
have
to
query
the
api.
A
A
A
A
And
like
just
like
with
backhand
and
front
end,
this
is
the
order
of
things.
We're
gonna
do
things
and
we
may
you
know
we
may
get
to
the
bottom
of
it
or
not.
It
is
kanban.
So
this
is
just
what
the
order
looks
like
right
now
for
the
next
month
in
two
weeks.
I'm
sure
this
will
be
different,
so
don't
get
married
to
this
order.
A
C
D
C
Yeah
yeah,
those
are
the
the
two
that
have
tasks
already.
We
have
like
a
few
more,
it's
also
something
to
to
think
about.
If
we
want
to
cover
every
single
object
we
have
or
not,
these
tests
are,
do
take
a
little
bit
longer
to
run.
They
are
pretty
easy
to
implement
for
the
most
part,
but
they
require
sometimes
ex
like
expensive
precondition
setup.
C
C
A
C
I'm
actually
even
referring
more
to
not
these
two
that
are
already
mentioned,
but
some
of
the
other
like
more
like,
I
don't
know
more
obscure
parts
of
functionality
that
maybe
not
as
many
people
use
that,
for
example,
we
have
in
the
task
list
of
unfinished
project
migration
items
like
but
yeah.
I
think
we
can
leave
that
that
will
come
in
most
likely.
Some
of
the
next
milestones.