►
From YouTube: GitLab 15.2 Kickoff - Configure:Configure
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
The
current
support
policy
works
in
a
pretty
much
ad
hoc
manner.
We
regularly
review
cloud
provider
support
and,
if
you
don't
forget,
we
start
adding
the
maintenance
work
needed
to
support
a
new
version
of
cabanas.
A
With
the
new
support
policy,
we
would
have
a
way
more
easier
to
track
and
expect
support
policy
kind
of
like
an
slo
around
command
support.
Moreover,
being
it
good
for
our
users
actually
would
be
even
compatible
more
with
openshift,
who
has
a
very
similar
policy
around
supporting
new
commandos
versions.
A
New
support
police
would
say
that
if
a
release
of
kubernetes
comes
out,
for
example
mid-july,
they
would
plan
an
investigation
issue
for
the
august
milestone
and
if
there's
any
work
to
be
done,
we
have
two
more
milestones
to
do
that:
work
to
schedule
that
work
and
deliver
that
work.
This
way,
three
months
after
the
initial
release
of
the
plan's
version,
we
can
add
support
for
that
version
in
the
milestone
plus
three
of
the
release,
which
is
an
amazing
thing.
A
A
The
one
big
item
that
we
are
working
on
is
to
provide
cube,
ctl,
exec,
attach
and
copy
support
in
the
ci
cd
workflow
with
the
agent.
This
is
mostly
a
limitation
in
the
upstream
kubernetes
project
and
we
are
working
with
the
comments
community
to
ship.
This
feature:
at
the
same
time,
we
managed
to
ship
a
partial
solution
for
some
self-managed
users
in
15.1.
A
The
fourth
item
that
we
set
up
as
a
goal
is
to
ship
monthly,
active
user
based
metric
for
the
ci
cd
workflow
with
the
agent.
This
will
be
our
first
monthly
active
user-based
metric
around
the
agent.
So
we
are
really
interested
to
see
these
numbers
coming
in
and
change
our
regular
reporting
to
the
mao
numbers.
A
If
you
want
to
have
more
insights
about
our
plans,
you
can
check
out
the
board,
that's
linked
in
the
in
the
planning
issue
and
there's
one
more
item
that
I
want
to
speak
about,
which
is
not
the
top
priority
goal
for
us
for
the
milestone,
but
very
likely
to
get
there
as
we
have
a
bit
more
front-end
bandwidth,
and
we
start
with
the
front-end
only
aspect
of
it.
This
issue
is
about
providing
status
page
for
the
gitlab
agent.
A
This
status
page
could
serve
our
users
in
many
amazing
ways
like
telling
them
if
they
want
to
use
ultimate
features,
but
they
are
a
premium
or
free
user
telling
them
if
some
of
the
configurations
are
invalid
or
that
there
is
some
other
error
with
their
agent
setup.
Of
course,
we'll
start
in
an
iterative
approach,
which
means
that
the
first
version
will
be
much
lower
than
what
you
can
see
now
on
your
screen.