►
From YouTube: GitLab 16.4 Kickoff - Enablement:Distribution
Description
Scheduling Issue - https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/1320
A
A
A
So
we
encourage
you
to
take
a
look
in
more
detail
if
you'd
like
to
see
everything
that
we've
got
planned
specific
to
16-4,
we've
got
a
couple
top
level
epics
I'd
like
to
mention
and
a
couple
of
the
work
items
underneath
each
of
them.
So
the
first
thing
they're
going
to
work
on
is
operator,
project
aranis,
depending
the
updates
and
efficiency,
and
then
increasing
distribution,
maintainers
and
reviewers
and
finally
arm
support
for
gitlab.
A
So
these
are
the
items
that
we
are
planning
to
tackle
in
16.4,
but
just
because
of
the
nature
of
some
of
these
items,
some
of
them
are
large.
So
the
reason
why
we've
introduced
this
quarterly
planning
issue
is
to
allow
the
work
to
kind
of
flow
more
easily,
but
these
are
the
items
that
we
hope
to
at
least
make
some
Headway
on
in
16.4.
So
moving
into
our
first
epic
that
I
mentioned
here
is
our
operator
production
anus.
A
So
the
the
key
Point
here
is
the
operator
is
a
production,
ready,
Cloud,
install
method
so
similar
to
our
home.
Chart
we'd
like
to
now
offer
the
operator
as
production
ready.
The
operator
can
be
used
right
now
and
and
I
know
there
are
individuals
using
it
in
production.
This
is
sort
of
Just
The,
Next
Step
that
we
would
like
to
achieve
as
a
general
sort
of
production
Readiness.
A
These
are
the
work
items
associated
with
them
more
from
a
ux
or
product
perspective.
Things
like
you
know.
The
operator
is
no
longer
dependent
on
the
OM
chart.
Right
now,
the
underlying
operator
is
running
with
a
dependency
on
the
helm
chart
so
we'd
like
to
remove
that
just
so
that
we
have
two
separate
paths
forward.
The
operator
is,
is
the
future?
Let's
say
of
our
Cloud
install
method,
so
differentiating
that
before
we
go
to
a
production,
ready
system
will
be
important.
Then
we've
got.
A
You
know
ensuring
that
the
the
you
user
experience
relates
to
our
versioning
makes
sense.
So,
right
now
for
some
of
our
certifications,
you
can
only
offer
the
latest
version
of
the
operator.
However,
with
the
nature
of
gitlab,
we
offer
mini
versions
that
people
can
run,
maybe
if
they
don't
want
to
be
constant
upgrading
to
the
latest
version
of
gitlab.
A
A
Also,
that
goes
without
saying,
but
we
say
it
here
which
is
comprehensive
documentation
for
those
who
want
to
use
it
and
then
for
ourselves
and
our
commitment
to
offering
a
consistent
product.
You
know
we
have
thorough
production
testing,
so
those
are
the
workout
is
related
to
this
epic
as
a
whole.
I
think
some
of
the
items
they're
working
on
most
immediately
is
definitely
the
dependency
on
our
Helm
chart.
A
So
this
is
something
we'd
like
to
remove
it's
a
it's
a
top
level
item
here
and
we
like
to
investigate
it
now,
so
that
we
can
hopefully
deliver
it
for
production
readiness.
So
moving
on
to
our
next
epic
here,
which
is
upgrading
core
dependencies
and
improve
the
process
in
distribution,
we
deal
with
the
responsibility
of
making
sure
that
we
offer
let's
say
the
latest
dependencies
that
customers
might
be
interested
in
running
the
application
or
dependencies
related
to
the
application.
That
is
gitlab.
A
So
we
have
two
small
issues
scheduled
here,
but
this
will
expand
to
more,
especially
based
on
reviewing
and
defining
kubernetes
version
support
policy.
So
this
is
just
one
example
of
one
of
the
dependencies
that
we're
focused
on
and
the
plan
is
to
use
this
one
as
sort
of
a
groundwork
or
foundation
for
all
the
other
dependencies.
A
So
so
the
the
learnings
that
we
find
from
this
issue
will
hopefully
be
expanded
to
a
larger
number
of
our
dependencies,
and
then
this
is
also
an
immediate
one
for
us
related
to
the
operator,
as
I
mentioned
before
so
these
kind
of
tied
together.
But
we
want
to
have
a
media
strategy
for
our
open
shift,
CI
clusters
so
that
again,
when
we
go
to
production
Readiness
for
the
operator,
our
dependencies
are
also
able
to
update
quickly
so
yeah
and
I
mentioned
going
before.
A
You
can
see
that
we're
improving
the
process
there
as
well,
so
expect
to
see
this
expand
but
yeah.
This
is
where
we're
at
right
now
for
expenses
moving
next
into
another,
very
important
area
for
distribution
that
I
might
have
mentioned
before,
but
I'm
going
to
mention
it
here
again
in
a
little
more
detail
is
increasing
the
number
of
distribution,
reviewers
and
maintainers.
So
in
distribution
we
review
a
very
large
number
of
let's
say:
Mrs
issues,
even
epics
from
other
teams,
and
because
we
are
sort
of
the
gate
into
self-managed.
A
We
do
catch
a
lot
of
this
work
from
a
very
diverse
group
of
teams
here
at
gitlab
and
also
community
members,
because
we
do
so
many
reviews.
Sometimes
this
takes
a
little
while
and
so
we'd
like
to
improve
how
quickly
we
can
get
to
these
reviews,
and
so
what
that
means
is
we
we'd
like
to
maybe
add
the
number
of
reviewers
and
maintainers
so
that
a
lot
of
these
projects
can
self-serve.
A
The
importance
of
this
is
one:
maybe
we
don't
even
have
to
review
something
if
the
the
team
feels
empowered
to
review
something
themselves
or
even
be
a
maintainer
of
the
project
and
have
it
ready
to
go
for
production
or
the
Mrs
and
issues
that
are
created
that
need
to
be
reviewed
by
distribution.
Team
members
might
deal
more
complete,
and
so
the
reviews
are
more
quick
done
more
quickly.
Let's
say
if
someone
is
already
a
reviewer
or
maintainer
of
a
project,
and
we
see
it
in
incoming.
A
We
might
not
need
to
spend
so
much
time
on
it.
So
those
are
some
of
the
benefits
I
I
did
want
to
mention
this
for
16-4.
You
can
see
a
lot
of
these
issues
are
scheduled
for
16.3
I.
Do
think
some
of
these
will
roll
to
the
next
one,
but
we
do
have
a
lot
of
plans
specific
in
16-4
related
to
all
the
members
of
the
distribution
team
being
at
least
in
the
process
or,
if
they'd
like
to
be
in
the
process
to
be
a
maintainer
of
our
own
projects.
A
So
this
is
an
important
step
just
to
reduce
the
load
on
each
individual
person.
Who
is
a
maintainer?
You
know
if
we've
got
five
maintainers
for
a
project
versus
two
things
can
get
done
more
quickly.
It's
it's
easier
to
kind
of
Shuffle
the
work
around
if
someone's
working
on
a
certain
issue
at
a
certain
time.
So,
finally,
moving
on
to
our
last
item
for
16-4,
that
I
would
like
to
mention:
is
our
okr
related
to
building
multi-architecture
images
for
CNG
this
one
specifically
unlocks
our
ability
to
run
arm
64.?
A
So
you
can
see
a
fair
amount
of
these
are
related
to
arm
64..
The
general
process
that
we
did
to
achieve.
This
is
a
larger
initiative.
It's
not
just
specific
to
m64,
but
the
biggest
customer
need,
or
the
the
user
interest
we
have
here
is
related
to
arm64
and
running
on
those
platforms.
This
is
something
we're
very
excited
about.
You
can
see.
Some
of
these
are
scheduled
for
16-3
already,
but
this
work
will
roll
over
or
the
completion
of
this
okr,
a
bulk
of
it
will
be
done
in
16-4.
A
We
don't
want
to
save
anything
for
16.5
on
this.
One
so
expect
to
see
many
scheduled
about
4
16
core,
probably
in
a
couple
days.
So
that's
the
things
that
we're
excited
about.
If
I'd
like
to
review,
we've
got
the
operator
going
to
production
and
Readiness,
which,
from
a
user
perspective,
will
be
a
very
forward-looking
installation
method,
offering
many
new
tools
and
features.
A
We've
got
upgrading
record
dependencies,
which
one
is
already
a
benefit
to
our
users,
because
they
can
run
the
latest
version
of
software
that
they're
interested
in
as
soon
as
a
new
version
is
released,
such
as
kubernetes
we'd
like
to
increase
our
number
of
reviewers.
This
allows
us
to
push
out
more
features
more
quickly
and
field,
more
requests
from
both
internal
git
lab
members
and
community
members
and
finally
I'm
64
supporting
arm
64
is
a
growing
technology
with
growing
interest
from
our
users.
A
So
we'd
like
to
support
that
it
was
a
lot
of
a
lot
of
work
on
this
one
deciding
exactly
how
to
make
this
work,
but
it
will
leave
us
in
a
better
place
and
more
efficient,
not
just
for
m64,
but
for
our
Cloud
native
git
lab
offering
as
a
whole.
So
that
is
our
16
point
per
release.
I
look
forward
to
chatting
with
you
next
month.
Thanks
have
a
great
day.