►
From YouTube: GitLab 15.4 Kickoff - Enablement:Distribution
Description
Planning issue - https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/1074
A
A
So
here
is
our
scheduling
issue
continuing
our
theme
of
scheduling
for
roughly
three
milestones.
It
aligns
well
in
case.
We
need
to
shift
work
around
within
a
handful
of
milestones.
So
that's
the
reason
why
we've
changed
this,
but
overall
I
will
keep
this
updated
and
I've
updated
it
for
15
4
as
promised.
So
we
will
continue
to
work
on
some
of
these
main
projects.
A
However,
in
15
4,
one
thing
that
is
not
listed
here
is
some
compliance
work
that
is
sort
of
internal
to
gitlab,
so
we're
going
to
be
working
on
compliance
updates
as
a
large
project
that
I
sort
of
couldn't
spell
out
at
the
top
of
our
scheduling
issue
here,
however,
so
that'll
be
the
main
piece
of
the
work
that
we're
working
on
in
15
4,
but
we're
still
going
to
keep
trying
to
make
progress
on
our
long-term
bill,
efficiency
vision,
improving
our
team
pipelines
and
the
operator
next
release.
A
Another
thing
I
wanted
to
point
out
for
this
release
is
some
changes
to
our
bugs,
so
we
had
a
new
new
dashboard
and
there
was
a
plan
to
sort
of
start
burning
down
bugs
more
quickly
than
they
sort
of
arise.
A
However,
we're
going
to
be
fairly
busy
for
the
next
couple
milestones,
so
we're
going
to
continue
working
on
bugs,
as
we
have
in
the
past,
working
on
high
priority
bugs,
as
as
they
pop
up
as
needed
and
sort
of
continue
at
a
rate
where
we're
not
increasing
or
necessarily
decreasing,
the
amount
of
bugs,
at
least
for
the
foreseeable
future.
A
Moving
on
to
some
of
the
items
so
like
I
mentioned,
sadly,
for
for
this
milestone,
we're
gonna
be
working
on
heavy
compliance
work
for
a
cross
kit
lab,
but
I
want
to
call
out
a
couple
cool
issues
that
we're
gonna
be
working
on.
I
have
mentioned
in
the
past
that
might
have
rolling
over
since
the
the
last
milestone
when
we
were
working
on
again,
some
other
compliance
updates.
A
So
some
couple
key
ones
that
I
want
to
point
out
is
we're
going
to
be
working
towards
ubuntu
22.04
for
the
package.
So
this
is
another
nice
one
that
we'll
add
to
sort
of
keep
up
to
date
with
new
releases
for
the
ubuntu
packages.
A
Moving
on
here,
we're
going
to
be
trying
to
accomplish
our
azure
blob
storage
plan
here.
So
as
we
support
aws
and
gcp,
we
want
to
support
azure
in
the
same
way.
So
the
proposal
here
is
to
somehow
do
the
same
sort
of
support
for
azure
moving
on
to
encrypt.
You
know
rails
passwords,
so
we
have
an
epic
here
which
is
encrypt
all
rails,
password
stored
in
gitlab.rb,
and
this
is
the
specific
issue
that
we
would
like
to
work
on
for
this
milestone.
A
A
This
also
lends
itself
to
non-rails
passwords
stored
in
gitlab.rb
this
one's
a
little
more
of
an
investigation.
There's
a
lot
more
work
here.
We
did
a
piece
of
the
work
a
while
back,
but
we
want
to
kind
of
circle
back
to
this
and
try
and
solve
some
of
the
technical
issues
that
we
sort
of
pointed
out
with
with
this
one,
so
both
of
these
roll
up
to
our
secure
solution
for
managing
omnibus
configuration
secrets.
So
the
main
thing
here
is,
you
know
we
want
to
make
sure
that
we're
being
as
secure
as
possible.
A
Then
there
have
been
some
concerns
from
customers
about
essentially
storing
the
ldap
passwords
and
ldap
usernames
and
clean
clear
text,
and
so
we
want
to
make
sure
to
mitigate
that
as
well
as
not
add
a
more
confusing
system.
A
lot
of
folks
are
already
using
their
own
secrets
management
system.
So
we
don't
want
to.
You
know,
introduce
another
one.
So
the
main
piece
here
is
encrypting
those
passwords
within
the
configuration
files
and
then,
along
with
that,
we
can't
sort
of
just
do
that.
A
We
have
to
redesign
gitlab
to
be
able
to
read
those
so
overall,
a
nice
value
add
here
for
our
security
purposes,
but
there's
kind
of
a
lot
of
work
here.
But
you
know
we
want
to
keep
chipping
away
at
it.
A
Moving
forward
this
one's
been
out
there
for
a
little
while
this
sort
of
the
workaround
is
already
there,
but
we
want
to
make
sure
to
document
this.
This
is
important
because
you
know
you
know.
Major
update
for
postgres
could
be
challenging,
but
we
want
to
document
near
zero
downtime.
A
You
know
postgres
upgrades
for
the
patrony
clusters,
so
this
is
sort
of
helping
folks
who
want
to
stay
up
to
date
are
as
up-to-date
as
possible
with
our
releases,
and
you
know
making
this
as
a
blocker
from
a
post-best
perspective
is
not
ideal,
so
we
want
to
make
sure
to
document
this
as
best
we
can,
and
this
one's
been
like,
I
said,
we've
been
trying
to
hit
this
one
for
a
little
while,
so
hopefully
we
can
accomplish
this
one
in
this
milestone,
it's
a
nice
value
for
customers
and
then
moving
on
to
the
final
one.
A
Here
we
have
lots
of
ui
changes,
or
I
shouldn't
say
a
lot,
but
we
have
very
specific
ui
changes
that
fall
under
the
umbrella
of
many
different
changes
related
to
upgrade
rate.
We
want
to
make
it
as
easy
as
possible
and
also
as
apparent
as
possible
when
an
upgrade
is
available,
and
so
this
falls
under
sort
of
a
big
batch
work
related
upgrade
rate,
and
this
specific
issue
is,
we
want
to
make
sure
the
upgrade
bad
is
showing
up
and
there's
a
bug
that
is
sort
of
affecting
a
few
types
of
instances.