►
From YouTube: GitLab 15.8 Kickoff - Enablement:Distribution
Description
Scheduling issue - https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/1131
A
Here's
our
scheduling
issue
and
we're
going
to
be
closing
out
our
Trio
issues,
this
Milestone
so
rounding
out
the
15,
6,
7
and
8
scheduling
issue
here
so
we'll
be
building
a
new
one.
So
look
for
that
for
next
time,
but
here
is
the
epics
that
we're
hoping
to
work
towards
this
time.
Obviously
we're
not
going
to
you
know
complete
them
all,
but
these
are
the
general
categories
we
would
like
to
work
towards.
I
will
add
the
issues
I
discuss
here
below
in
this
video.
A
So
if
you
want
to
take
a
look
or
just
link
them
directly
in
this
scheduling
issue,
so
the
first
one
we're
going
to
be
working
on
is
multi-architecture
support
for
gitlab.
The
the
main
piece
here
is,
you
know
allowing
builds
for
new
CPUs
such
as
Arch
64
and
arm
64.,
or
you
know,
for
these
new
systems.
We
need
to
be
able
to
build
Cloud
native
gitlab
on
them.
A
So
we
have
a
couple
use
cases,
but
essentially
you
know
it
all
falls
under
just
building
on
these
new
architectures
and
then
having
a
process
in
place
to
support
multiple
different
architectures
at
once.
Internally,
next
up
here,
I'm
improving
our
team
distribution
team
pipelines.
You
know
this
is
an
internal
efficiency
item,
but
we'll
pay
dividends
down
the
road
for
the
community
as
well
the
quicker
and
easier
we're
able
to
work
with
our
pipelines.
A
A
This
is
an
internal
thing,
but
ultimately
everyone
can
contribute,
as
we
say,
gitlab,
so
the
the
more
that
we
can
work
towards
this
issue,
the
easier
it'll
be
and
we
can
enable
contributors
from
the
community
better,
which
again
will
ultimately
allow
us
to
deliver
more
features
quickly
and
also
specifically
ones
that
the
community
is
asking
for,
because
you
know
they'll
feel
empowered
to
go
and
start
an
MR
with
you
know
out
the
hurdle
or
the
or
the
difficulty
that
it
is
to.
A
You
know
approach
a
distribution
project,
so
we
need
to
do
a
better
job
to
enable
those
community
members
to
jump
in
and
contribute
next
up.
Here
we
have
our
secure
solution
for
managing
Omnibus
Secrets.
You
know
this
has
been
mentioned
for
a
while
and
we're
making
slow
but
steady
progress.
A
It's
a
tough
topic-
and
you
know
one
that
takes
a
lot
of
growth
in
research
and
so
we're
just
going
to
keep
working
away
at
it.
We
are
certainly
making
good
progress
so
moving
into
specifically
some
of
these
issues,
as
I
mentioned
here,
this
multi-architecture
support
for
cloud
native
gitlab.
Some
of
the
issues
that
we're
specifically
going
to
be
working
on
is
using
build
X
for
building
and
tagging
Docker
images
and
then
ultimately
provisioning
kubernetes
clusters
for
housing,
multi-architecture,
CNG,
build.
A
You
know
our
our
CNG
builds
Fleet,
so
we
have
to
have
a
place
to
you,
know,
sort
and
enable
us
to
work
efficiently
with
this
project.
So
next
up
here,
you
know,
as
I
mentioned,
improving
our
distribution
team
pipelines.
This
is
a
lengthy
issue.
There's
there's
lots
of
issues
underneath
it,
but
any
progress
you
can
make
here.
Will
you
know
make
us
more
efficient,
so
we
want
to
refactor
job
names
to
not
rely
on
dot
release.revision
and
another
one
sort
of
related
is
just
make
use
of
releases
feature.
A
So
you
know,
as
I
mentioned,
this
is
sort
of
internal
efficiency,
and
we've
been
hoping
to
work
on
this
for
a
while.
You
can
see
you
know
how
how
many
times
we've
kind
of
tried
to
work
on
something
like
this,
but
it's
now
sort
of
time
to
just
set
this
aside
or
not
to
decide,
put
this
at
the
Forefront
and
make
make
time
for
something
like
this.
It
just
needs
to
be
done
so
moving
on
is
improving
our
contributor
experience,
as
I
mentioned.
A
You
know
we
just
need
to
be
able
to
allow
everyone
to
con
to
contribute
more
easily,
especially
in
a
tough
space
like
distribution
to
contribute
to
we.
We
need
to
build
tools
and
Frameworks
and
improve
our
documentation
to
help
collaborators
more
easily,
and
one
step
forward
on
that
is
create
a
process
for
updating
package
and
repo
signing
keys.
A
So
we
want
to
be
enabled
to
move
a
project
board
that
might,
you
know,
require
keys
to
be
signed,
and
you
know
this
is
just
one
one
thing
as
I
mentioned.
This
is
a
lengthy
issue.
There's
lots
of
issues
underneath
this
and
we
need
to
you
know,
start
tackling
them,
and
so
this
is
one
of
the
first
ones
that
popped
up
so
now
encrypt
all
rails
passwords
stored
in
GitHub
RB.
This
is
under
the
sub
epic
of
securing
our
Omnibus.
A
You
know
configuration
Secrets
and
then
the
sub
issue
here
that
really
set
the
foundation
here,
is
going
to
be
encrypting
incoming
email,
passwords
and
so
all
these
rails
passwords
stored
in
gitlab
RB.
Once
this
work
is
done
here,
the
the
rest
of
these
issues
that
are
related
will
fall
fairly
quickly,
and
then
we
can
sort
of
move
on
to
the
next
step
here,
which
is
all
non-rails
passwords,
so
we're
working
on
this
one
right
now
and
then
we're
gonna.
A
You
know
finish
the
research
here,
but
whatever
we
learned
in
the
all
rails,
passwords
will
set
us
up
well
for
the
non-rails
passwords
work.
So
that's
a
good
summary
of
what
we're
going
to
be
working
on
we're
still
working
on
some
of
the
compliance
work,
but
it's
certainly
slowing
down
which
opens
us
up
to
work
on
more
specific
distribution
issues
which
we're
very
excited
about
so
happy
holidays,
everyone
and
hopefully,
we'll
have
a
great
15.8
release.
Thank
you.