►
From YouTube: GitLab 15.9 Kickoff - Enablement:Distribution
Description
Scheduling Issue - https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/1176
A
A
Okay,
so
here
is
our
new
scheduling
issue.
We
wrapped
up
our
last
Trio
issue
this
this
mouse
and
we're.
Currently
in
it's
coming
up.
We
have
15
9,
10
and
11,
which
we
captured
here
at
the
top
in
our
product
Outlook
and
as
continuing
our
theme
from
the
last
couple,
I'll
capture,
all
issues
I
talked
about
in
this
issue
or
excuse
me
in
this
video
right
in
this
issue
a
little
bit
below
this
product,
Outlook
section
so
go
ahead
and
getting
into
it.
A
The
theme
of
the
next
three
Milestones
is
going
to
be
efficiency
for
the
distribution
team,
so
we
have
been
working
diligently
on
compliance,
work
and
I
know
I
bring
it
up
a
lot
about.
A
You
know
hoping
to
work
towards
some
of
this
efficiency
work,
but
we're
really
setting
aside
and
focusing
these
next
three
milestones
and
sort
of
putting
our
heads
down
on
this.
These
projects,
to
really,
as
I've
mentioned
before,
set
ourselves
up
for
a
lot
of
success,
moving
forward
both
for
teams
requesting
assistance
from
distribution,
as
well
as
our
our
own
reduction
in
general
maintenance
as
gitlab
grows
so
first
off.
A
However,
we
do
need
to
do
some
of
our
core
dependency
updates,
so
this
there's
normally
something
I,
probably
wouldn't
normally
mention,
but
in
this
15
nine
Milestone,
it's
actually
going
to
take
a
Paramount
of
our
attention.
So
this
includes
updating
kubernetes
to
support
one
1.22
and
1.25,
as
well
as
updating
openshift
to
support
4.11
for
the
operator.
A
So
now
that
we've
added
the
operator
as
employment
method
and
we
work
towards
recommending
it
for
production,
it's
going
to
be
another
another
dependency
that
we
need
to
support
So
in
this
Milestone
we're
working
on
4.11
for
that
next
up,
consumer
experience.
A
This
is
one
that
we've
talked
about
before,
but
really
haven't
had
much
time
to
dedicate
towards
so
this
time
we
have
a
slate
of
issues
that
are
going
to
be
scheduled
and
we
are
going
to
complete
and
this
Milestone,
as
well
as
our
long-term
Bill
efficiency,
I'm,
not
sure
if
I've
mentioned
this
one
specifically
in
the
past.
This
is
the
actual
epic
and
as
a
whole,
distribution
team
maintains
two
projects
or
excuse
me,
sort
of
two
code
bases
right
now.
A
One
is
our
Cloud
native
gitlab,
which
comes
our
health
chart
and
now
the
operator,
as
well
as
Omnibus
gitlab
for
our
Linux
distributions
and
virtual
machine
usage.
So
what
we
like
to
move
towards
is
a
single
process
to
maintain
both
code
bases
effectively
cutting
down
the
time
to
both
maintain
and
develop
new
builds
or
excuse
me,
you
know
anything
that
reflects
a
new
build
in
half,
so
that's
not
to
say
that
all
maintenance
work
will
be
cut
in
half,
but
the
time
to
build
a
new
one
and
Test
new
features.
A
A
So
moving
into
these
specific
issues,
I'll
go
ahead,
and
you
know
jump
through
this
really
quick
in
supporting
new
versions
of
kubernetes,
so
there's
a
fair
amount
of
issues
that
are
left
open
underneath
this
one.
So
we
have
three
issues
for
this
Epic
we've
got
a
handful
of
issues
related
to
this
epic,
as
well,
very
similar
to
the
1.22
epic,
and
then
this
is
actually
listing
4.8.
We
already
support
that
or
we
already
test
against
it.
A
This
issue
should
already
enclosed
for
the
4.8
ones,
but
you
can
see
a
slew
of
other
4.11
issues
as
well,
so
we're
gonna
work
towards
these.
Moving
into
our
contributor
experience.
We
have
a
number
of
issues,
so
I
left
it
on
this
page.
So
this
is
a
very
large
epic
42
issues
and
four
epics.
So
you
want
to
chunk
away
at
this.
The
next
three
milestones
we
will
not
finish
all
of
it,
but
that's
okay.
A
We
just
want
to
finish
the
bulk
of
it
and
really
help
folks
contribute
more
easily
and
could
collaborate
with
distribution
projects.
That's
going
to
be
huge
for
us,
so
two
benefits
are
brought
with
an
epic
like
this.
Currently
distribution
has
to
review
a
lot
of
Mrs
from
other
teams
that
are
trying
to
add
features
to
self-manage,
and
so
hopefully
this
will
reduce
that
or
at
least
reduce
the
amount
of
effort
needed
for
one
of
these
reviews
and
then
next
up.
A
So
two
issues,
I
suppose
we
want
to
call
out-
are
excuse
me,
one
Epic
and
another
issue.
So
four
total
issues
that
we
hope
to
work
on
in
15
9.
one
is
ensure
changes
that
other
components
don't
break
package
bills.
So
what
this
really
means
is,
if
a
specific
component,
so
you
know
this-
could
also
be
a
specific
product
team
looks
to
change
something
and
they
make
a
change.
It
can
actually
break
the
whole
build.
Obviously
this
is
only
in
a
testing
environment.
A
However,
there's
a
lot
of
troubleshooting
that
needs
to
go
into
it
after
that,
once
it
breaks,
and
this
really
dips
into
the
fact
that
you
know
that
that
initial
change
might
be
easy
or
more
approachable
and
then
once
the
build
breaks
as
a
whole.
This
is
really
where
a
distribution
skills
would
be
required
and
we
hope
to
not
require
that
anymore.
If
someone
change
a
component,
it
shouldn't
break
the
whole
build
which
would
allow
people
to
contribute
more
easily.
So
there's
three
issues
underneath
this
epic.
A
A
So
really
what
this
means
is,
if
we
bump
a
software
package
or
softwares
to
a
lace,
release
security
patch
Etc,
we
can
create
this
new
package,
but
this
sort
of
creates
a
list
of
or
things
that
need
to
be
tested,
along
with
it
so
similar
to
components
or
anything
that
is
grouped
in
this
sort
of
code
base,
and
so
if
someone
else
wants
to
do
this,
this
causes
a
big
problem.
A
Because
again
it
leads
back
to
the
point
of
really
it's
a
distribution
team
member
that
ends
up
having
this
work,
but
maybe
we
could
change
that
so
moving
on
to
distribution,
long-term,
build
efficiency,
so
I
I'm
not
mentioned
this
stuff
before,
but
I
just
want
to
bring
it
up
again.
A
You
know
this
is
just
a
it's
a
lot
of
work
for
us
to
maintain
these
two
code
bases
when
all
of
it
can
be
derived
from
a
single
code
base
that
could
affect
everything
that
we
do
in
distribution,
which
would
bring
a
lot
of
efficiency
into
the
the
way
we
work.
The
first
step
in
this,
the
foundation
of
this
whole
project,
is
this
Spike
and
parallelized
Omnibus
building
and
reduce
Omnibus
upgrade
gifts.
So
what
that
means
is
building
a
you
know.
A
Building
with
Omnibus
should
reduce
the
requirement
to
or
excuse
me
should
reduce
the
amount
of
differences
as
an
upgrade
happens.
So
this
makes
right
now
testing
very
slow
and
a
customer
needs
to
download
the
entire
Omnibus
package
every
time
they
they
upgrade,
which
is
annoying
for
both
us
and
a
customer.
So
what
this
would
do
is
it
would
just
change
the
things
that
we
change,
which
would
be
really
nice.
A
So
this
is
one
issue
that,
as
you
can
see,
we've
been
looking
to
work
on
for
a
while,
and
so
that's
the
point
of
sort
of
setting
everything
aside
and
focus
on
these
two
projects.
So
that
is
what
we
hope
to
accomplish
in
15.9.
Thank
you
so
much
and
have
a
great
rest.
Your
day.