►
From YouTube: GitLab 13.6 Release Kick Off-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
Hello
to
the
13.6
release,
kickoff
of
the
configure
group,
my
name
is
victor,
no,
I'm
the
product
manager
and
here's
me
maria
brachmi,
our
product
designer,
and,
let's
see
what
we
plan
to
accomplish
in
the
next
month.
So
we
have
four
goals
and
the
first
is
a
pretty
urgent
one
ham
ham.
3
was
released
last
november
and
in
la
in
together
with
the
release,
the
ham
team
claimed
that
they
will
deprecate
ham
to
in
one
year's
time
so
in
november.
2020.
A
A
So
we
have
to
fix
many
of
the
of
the
ham
access
paths,
basically
in
order
for
gitlab
managed
as
apps
and
how
to
develop
the
function
properly,
and
this
allows
as
well.
This
is
needed
as
well
for
hand
free
support
that
we
are
working
on
for
some
time
now.
A
A
As
I
said,
the
first
two
items
are
around
the
ham:
rapid
applications
and
hand
free
upgrades
in
gitlab
managed
apps.
So
I
don't
want
to
speak
more
about
these.
The
third
item
is
feature
flag
that
was
outstanding
for
a
long
long
time,
and
we
didn't
have
much
time
to
work
on
it.
We
just
want
to
knock
it
out,
so
other
teams
can
start
a
work
as
well.
That
depends
on
us
to
roll
out
reactive
cache
limits
on
deploy
boards.
In
our
case
already
mentioned,
one
of
our
goals
is
to
get
to
gitlab.com
with
the
agent.
A
We
will
have
a
very
different,
simple
design
in
the
first
iteration,
which
can
just
show
the
state
file
and
who-
and
one
did
the
changes,
because
we
don't
have
the
connection
to
the
pipeline
and
commit
and
merge
requests.
Yet
this
will
be
added
in
a
future
iteration.
So
it's
only
the
state
file
name
and
the
user
and
time
of
the
changes.
A
The
next
item
is
a
technical
item
related
to
the
agent
that
will
allow
us
to
start
requests
from
git
lab
to
specific
agents,
and
this
allows
us
to
get
status
reports
of
an
agent
or
ask
the
agent
to
perform
specific
tasks
inside
the
cluster.
So
this
is
a
very
important
step
in
the
in
the
life
of
the
agent,
because
this
will
allow
real
bi-directional
communication
between
git
lab
and
the
agent
and
providing
this
we
will
be
able
to
get
the
database
page
for
the
agent
as
well.
A
A
A
If
it
opens
yes,
it's
for
almost
an
year
and.
A
A
Something
personal
I'm
really
excited
about.
Is
this
poc
around
the
gitlab
managed
applications
with
the
agent?
Here
we
want
to
install
as
part
of
the
poc.
We
want
to
install
runners
with
the
agent
you
might
ask:
why
is
it
already?
Why
does
it
have
a
green
check
mark
in
the
do?
We
expect
deliver
column
because
we
are
really
confident
about
it.
We
started
work
in
the
current
milestone,
so
we
are
100,
confident
to
be
able
to
ship
it
and
show
how
to
install
gitlab
runners
with
the
gitlab
agent.
A
We
have
a
ux
depth
issue,
but
actually
this
is
currently
blocked
by
ux
research.
So
I'm
not
speaking,
I'm
not
going
to
speak
about
it
more
and
another,
very
important
issue
that
we
think
can
be
a
life
changer
in
the
life
of
a
game.
Changing
the
life
of
the
agent.
Is
this
agent
authorization
to
access
private
manifest
projects?
A
A
You
want
to
change
this
setup
to
be
able
to
deploy
a
directory
of
manifest
yaml
files
as
well
or
even
a
recursive
directory
of
manifest.cml
files.
In
this
way,
a
user
can
actually
provide
their
own
cluster
setup
in
a
directory
with
all
its
different
components
and
services,
and
the
agent
can
keep
it
updated
inside
the
cluster
and
provide
this
very
nice
pool,
basically
top
flow
that
it
is
meant
to
do.
A
The
last
item
here,
which
is
against
stretch
goal,
is
an
extension
on
the
list
of
git
lab
manager
from
states
that
I
spoke
already
about.
The
extension
is
about
adding
basic
actions
around
the
state
to
be
able
to
lock
or
unlock
the
state
file
to
be
able
to
download
the
latest
version
of
the
state
file
or
to
be
able
to
remove
the
state
file
and
all
of
its
versions
entirely.
A
There
are
many
reasons
why
it's
a
strategic
goal:
it's
not
most
designed,
but
because
some
of
the
apis
are
still
missing
and
we
have
to
develop
those
as
well.
So
these
are
the
the
features
we
plan
to
work
on
from
the
engineering
side
and
that
we
sooner
or
later
want
to
get
out
of
the
on
the
door.
And
now,
let's
turn
to
the
design
work.
I
just
tap
my
screen
share
and
then
mario,
you
can
share
your
skin.
B
Thank
you
so,
from
a
design
perspective,
we
have
planned
the
following
issues.
First,
one
is:
introduce
a
terraform
state
file,
details
page.
So
this
is
the
ongoing
work
we
are
doing
for
terraform
state
management,
it's
already
in
progress,
so
this
issue
is
about
providing
a
details
page
to
view
the
terraform
detail,
state
file,
details,
but
also
the
versions
and
the
versions
actually
is
a
separate
issue.
It's
the
next
issue
so
provide
a
ui
of
how
the
users
are
going
to
view
the
versions
of
a
state
file.
B
B
So
as
part
of
the
solution
validation,
we
hope
to
test
the
information
and
interactions
we
provide
to
the
users
for
the
terraform
state
file
and
validate
these
two
issues,
hopefully
as
well,
and
finally,
we
have
the
agent
authorization
for
private,
manifest
repositories.
So
victor
spoke
about
that
in
terms
of
development.
B
B
So
we
want
to
enhance
this
feature
by
providing
more
information
about
the
affected
resources,
so
we
need
to
create
a
scalable
design
and
then
design
for
the
affected
resources.
Following
that,
these
two
are
stretch
goals.
I
believe
they
will
have
to
go
to
13.7,
but
maybe
there's
a
chance
to
start
working
on
them
in
13.6,
so
that
was
all
from
design
work.