►
From YouTube: GitLab 15.3 Kickoff - Enablement:Distribution
Description
Planning issue - https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/1074
A
Here
is
our
scheduling
issue
again
we're
following
the
theme
that
we
proposed
a
few
milestones
back
of
capturing
our
scheduling
issue
for
three
milestones.
This
allows
us
to
sort
of
capture
the
the
sway
or
the
movement
of
a
few
milestones
if
issues
need
to
be
moved
to
later
milestones
pending
availability.
So
you
know
this
just
gives
us
a
better
way
to
capture
that
movement
a
little
bit
so
jumping
into
a
couple
of
the
high
level
product
outlooks
and
I'll
continue.
A
Upgrading
updating
this
product
outlook
section
as
we
move
forward
in
milestones,
but
we're
still
moving
on
the
phipps
audit,
so
similar
large
project
that
we've
been
working
on
for
a
while.
The
audit
will
be
scheduled
some
time
after
15-2,
so
working
into
15-3.
Really
what
we're
looking
to
do
is
efficiency
related
to
fips.
So
how
many
of
these
components
can
we
sort
of
automate
in
order
for
us
to
stay
compliant
more
effectively
and
efficiently?
A
Two
other
long,
long
term,
projects
that
you've
seen
before
that
we're
going
to
continue
to
rotate
on
is
our
distribution,
long-term,
build
efficiency
and
improving
our
distribution
team
pipelines.
Both
of
these
issues,
I
would
say,
are
sort
of
maintenance,
related
and
you'll
see
when
I
show
the
deliverables
board
of
how
many
issues
that
we
actually
have
scheduled
that
are
related
to
maintenance
in
1503,
but
really
the
the
more
of
these
that
we
do
now.
A
The
more
dividends
will
pay
off
in
the
future
for
us
to
have
less
time
to
maintain
and
work
on
our
build
and
our
pipelines
and
more
time
for
us
to
work
on
issues
related
to
features.
So
in
the
end,
these
will
be
many
dividends
for
the
end
user.
So
moving
forward
here,
the
the
next
one
we
have
is
our
operator
next
release.
So
I
know
I've
been
mentioning
the
operator
for
many
milestones
now
and
now
we're.
A
So
we
are
committed
at
get
lab
to
continue
to
work
on
bugs
that
get
raised,
and
this
is
just
another
way
for
us
to
ensure
that
these
bugs
stay
at
the
forefront
of
what
we
work
on
every
milestone.
So
here's
a
couple
that
we've
got
scheduled,
they
will
remain
to
be.
You
know
a
few,
a
few
of
them
scheduled
every
milestone,
so
keep
looking
for
this
section
that
I'll
continue
to
update
for
milestone
as
well.
A
So
moving
on
to
the
fifth
issue,
real
quick,
the
one
of
the
efficiency
issues
that
we
want
to
do
is
actually
create
issues
for
fips
compliance
checks.
So
this
issue
is
more
about
finding
all
those
components
that
need
those
compliance
checks
within
distribution
and
there'll
be
many
more
issues
that
sort
of
spawn
out
for
this.
One,
this
kind
of
lays
the
foundation
for
our
automation,
related
compliance
moving
forward,
and
then
I
wanted
to
show
related
to
our
maintenance
so
related
to
our
build
efficiency
and
our
improving
team
pipeline
epics.
A
A
For
example,
one
of
the
issues
is,
you
know,
creating
a
script
comparing
the
size
of
two
gitlab
omnibus
packages,
so
this
is
pretty
basic,
but
again
it
lays
the
foundation
for
future
work.
So
if
we
can
actually
know
and
measure
the
growth
over
time
of
our
package,
we
will
be
able
to
tell
you
know
if
we're
effectively,
adding
and
maintaining
our
package
and
if
we
can
ultimately
reduce
the
size
of
our
packages.
A
It's
just
less
time.
For
every
time
we
have
to
spin
up
an
instance
of
git
lab
or
our
end.
Users
have
to
spin
up
instances,
git
lab
either
related
testing
or
an
upgrade
whatever
it
is.
So
a
little
small
change
like
this
will
pay
off
big
in
the
future
and
that's
what
many
of
those
maintenance
issues
are
similar
in
in
fashion
too
so
moving
forward.
Our
get
lab
operator
next
feature
release.
A
A
So,
on
the
same
theme
of
quality
of
life
for
our
engineers,
the
more
that
we
can
automate
related
to
testing
and
a
general
test
framework
for
the
operator,
the
more
we
can
work
on
features
and
not
have
to
worry
about
making
sure
the
operator
is
running
effectively
because
we've
got
the
testing
framework
in
place
to
do
so,
and
then
we've
got
a
couple
miscellaneous
issues
that
I
definitely
want
to
call
out.
So
one
of
them
is
a
feature
proposal
for
omnibus.
A
A
So
this
will
be
a
nice
value
once
we
introduce
it
another
one
that
is
sort
of
a
two-part
issue,
so
either
last
milestone
or
a
few
milestones.
We
worked
on
this
research,
which
was
supporting
multiple
pg
bouncer
instances
on
the
same
port.
A
The
research
is
complete
and
now
we're
moving
on
to
implementing
the
solution
and
similar
to
my
you
know,
reasoning
before
this
is
important,
because
there
could
be
a
bottleneck
for
a
single
core
running.
You
know
multiple
pg
bouncer
instances,
and
so
we
want
to
you
know,
reduce
that
bottleneck,
and
so
this
is
the
issue
to
implement
the
the
change
to
do
so
and
then,
finally,
this
is
kind
of
the
basic
one,
but
we're
going
to
upgrade
our
nginx
ingress
to
version
1.21
based
on
just
new
security
capabilities.
A
So
pretty
basic
issue,
but
you
know
be
a
nice
upgrade,
so
that
is
our
scheduling
issue
for
15.3,
as
always
have
a
good
rest.
Your
day.