►
From YouTube: 14.4 Monthly Release Kickoff (Public Livestream)
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
All
right
greetings
everyone
happy
monday.
I'm
excited
to
kick
off
gitlab
monthly
release.
14.4
a
few
months
ago,
we
published
a
three-year
vision,
video
that's
available
on
our
website,
for
you
all
to
check
out
so
to
try
to
check
it
out.
I
think
it's
pretty
cool
and
exciting
about,
and
it
shows
you
what
we're
working
on
and
then
we
also
have
our
one
year
usability
one
air
product
investment
teams
that
continue
to
be
the
same
application,
security
testing,
leadership,
adoption
through
usability
and
gitlab,
hosted
first
focus,
including
reliability,
performance
and
availability.
A
A
A
B
Thank
you,
newt,
let's
dive
in
so
to
start
with
the
sex
section,
we'll
talk
about
the
secure
stage,
they
are
focused
primarily
on
reliability
and
performance.
First,
here
with
static
analysis,
they're
focused
on
ways
to
improve
the
performance
and
reliability
of
the
sas
and
secret
detection
scanners.
This
work
will
not
finish
in
this.
Milestone
will
be
a
goal
over
the
next
couple
of
milestones.
B
One
thing
they
are
working
on
within
this
milestone
related
to
this
is
the
ability
to
allow
pre-filtering
as
part
of
the
scanning,
for
those
who
are
familiar
with
this.
The
exclude
command
does
not
exclude
areas
from
being
scanned.
It
actually
only
excludes
them
from
the
results.
While
this
has
the
expected
outcome
in
large
projects
like
monorepos,
that
still
means
that
everything
is
being
scanned.
So
this
effort
is
not
only
just
to
improve
the
reliability
and
performance,
but
also
to
continue
to
extend
our
application
security
testing
leadership.
B
Next,
with
the
dynamic
analysis,
team,
they're
continuing
their
work
and
with
the
goal
of
wrapping
up
this
milestone
to
roll
out
our
dast
on
demand
scan
scheduler.
If
you're
unfamiliar
about
this
from
our
page
kickoff
calls
at
the
bottom
of
your
on-demand
desk
and
profile,
there
will
be
an
option
to
schedule
the
scan.
You
can
schedule
this
to
run
once
as
you
can
see
here.
It
does
not
repeat,
but
you
can
also
schedule
to
run
on
a
frequency
schedule.
It's
a
nice
improvement
to
our
application
security
testing
offering
and
providing
us
additional
leadership
there.
B
Our
competition
analysis
team
is
focused
primarily
on
git
web,
hosted,
first,
with
a
focus
on
reliability
and
scalability.
Again
here,
they're
focused
on,
as
you
can
see
primarily
in
infradeb
issues,
the
composition,
analysis
team
is
supporting
the
managed
stage
and
burning
down
some
of
their
infra
dev
debt
and
that's
very
exciting,
to
see
the
cross
stage
work.
On
top
of
that,
they
will
continue
to
move
items
forward
within
their
own
area
as
well,
and
then
to
wrap
up
the
secure
stage.
B
B
However,
they're
also
looking
to
move
the
create
vulnerability
records
to
the
api
from
behind
its
feature
flag
to
being
a
ga
feature
for
those
who
remember,
this
is
going
to
allow
you
to
start
creating
your
own
vulnerability
records
externally
from
gitlab
into
the
get
lab
vulnerability
management
experience.
It's
really
great
step
forward
for
people
who
use
third
parties
like
hacker,
one
that
do
their
external
scanning
being
able
to
then
take
those
results
and
put
them
into
the
same
workbook
and
then
to
wrap
up
the
sec
section
with
the
protect
stage.
B
The
container
scanning
team
or
container
security
team
is
also
supporting
manage
over
the
next
couple
milestones
on
scalability
infertive
related
tasks.
However,
with
the
last
milestone,
we
did
release
an
alpha
version
of
cluster
image
scanning.
This
is
a
scanning
running
product,
our
scan
scanning
containers
that
are
running
within
production.
I
swear.
I
had
a
lot
of
caffeine
this
morning
and
it's
just
bad
speaking
today.
B
This
work
was
released
as
an
alpha
functionality
behind
a
feature
flag,
they're,
going
to
continue
to
push
this
forward
to
be
a
two
article
of
the
ga
release
of
it
later
this
year,
and
that
is
everything
from
the
sex
section.
With
that
alberta,
kenny.
C
C
I
put
together
a
little
highlights
note
for
the
things
that
I'm
excited
about
for
kickoff
and
I'm
going
to
go
through
them
one
by
one
sas.
First
and
reliability
is
up
on
the
agenda
first,
so
there
are
a
couple
of
big
ticket
items
that
the
whole
app
section
is
working
on.
The
first
is
decomposing
gitlab's
database
to
make
sure
that
we
have
scalability
for
it.
C
So
one
of
the
things
we're
going
to
be
doing
is
decomposing
to
have
to
allow
for
instances
to
have
the
ci
related
tables
be
decomposed
in
their
own
separate
database,
so
that
it
can
scale
it's
a
highly
scaled
portion
of
the
product.
If
you
think
about
it,
when
users
create
start
using
ci,
they
continue
to
create
more
and
more
pipelines
that
have
more
and
more
jobs.
C
So
the
artifacts
in
the
database
related
to
uci
continue
to
expand
almost
exponentially,
so
the
whole
ops
section
will
be
participating
in
work
that
we'll
be
doing
to
decompose
that
which
should
result
in
higher
performance
on
gitlab.com
and
your
own
individual
gitlab
instances
for
ci
related
tasks
like
creating
pipelines
and
triggering
jobs.
C
Next,
we
have
had
a
significant
focus
in
the
op
section
on
our
sas
performance
indicators.
So
these
are
the
error
budgets
for
gitlab.com
and
actually
over
the
last
couple
of
weeks,
three
of
our
four
groups
that
are
participating
in
this
effort
have
seen
their
error
budgets
go
to
green
and
we'll
continue
to
have
all
other
groups
focus
on
improving
their
error
budget
so
that
our
users
have
a
more
reliable
and
performant
experience
when
using
gitlab.com.
C
The
pipeline
execution
team
is
actually
very
heavily
focused
on
fixing
infradev
and
other
blocking
issues
that
enable
scalability.
So
I
didn't
want
to
go
through
each
one
of
them,
but
a
lot
of
focus
in
this
specific
group
on
ensuring
that
we
have
a
reliable
and
scalable
gitlab.com
instance
in
our
pipeline
authoring
group.
This
is
the
group
that
works
on
the
pipeline
editor.
C
They
noticed
a
timeout
that
was
happening
regularly
when
users
were
including
multiple
includes
into
their
gitlab.ci
yaml
file
for
defining
their
pipelines,
they're
going
to
be
digging
into
figuring
out
and
adjusting
the
way
that
we
make
calls
to
include
other
pipeline
definitions
in
their
in
a
project's
pipeline
definition
and
smooth
that
out,
so
we
don't
get
500
errors
or
response
errors.
C
When
attempting
to
do
so
in
our
release
group,
the
our
package
or
sorry
our
pages
capability,
we
recently
saw
some
instances
where
we
were
overwhelmed
with
traffic
on
specific
page
sites,
so
we're
going
to
be
adding
rate
limiting
to
ensure
that
any
you
know,
high
traffic
sites
doesn't
necessarily
take
down
or
bring
down
other
sites
in
your
pages
environment
and
then,
lastly,
when
it
comes
to
sas
focus
and
reliability.
C
But
when
you
generate
a
qubitera
report,
which
is
a
testing
report
for
your
in
your
gitlab
ci
jobs
when
we
parsed
it-
and
it
was
a
really
large
file
that
was
sometimes
timing
out
or
causing
errors.
So
we're
going
to
be
adjusting
the
parser
that
we
use
so
that
that
is
more
performant
and
happens.
You
know
iteratively
over
the
xml,
which
will
mean
that
users
who
generate
these
files
that
are
quite
large
can
use
them
much
more
readily.
C
So
it's
a
great
example
of
digging
in
deep
and
figuring
out
a
performance
improvement
that
will
really
help
our
users
on
their
daily
job.
Using
gitlab.
Next
is
a
focus
on
adoption
through
usability.
So
I
wanted
to
highlight
that
in
the
runner
group
they
continue
to
focus
a
lot
on
usability
specifically
for
our
kubernetes
executor.
C
This
has
been
a
really
point
of
priority
for
the
group
all
year,
almost
and
so
they're
excited
to
continue
to
work
on
improvements
that
allow
users
to
easily
stand
up
a
fleet
of
runners
based
on
kubernetes,
that
is
highly
scalable,
a
bunch
of
usability
and
performance
improvements
that
are
included
in
the
work
coming
up
in
14
4
from
the
runner
group.
C
I
also
wanted
to
highlight
that
in
our
monitor
group,
we
have
great
incident
management
and
escalation
policy
and
on-call
schedule
management
already
available
in
git
lab
one
of
the
things
that
the
monitor
group
identified
was
that
for
users
who
weren't
necessarily
triggering
incidents
from
alerts,
it
was
difficult
to
manage
escalations
and
so
they'll
be
working
on
escalating
manually,
created
incidents
including
having
the
ability
for
responders
to
signify
the
status,
whether
they've
acknowledged
or
responded
to
that
incident.
C
So
you
can
see
that
here
where
they,
you
can
assign
an
escalation
policy
after
an
incident
has
been
created.
That
will
immediately
start
the
clock
on
that
escalation,
as
well
as
for
those
who
are
paged
to
assign
the
status
that
it
was
triggered
or
acknowledged
or
resolved.
So
that's
a
great
improvement
that
focuses
on
what
we've
learned
about
how
users
intend
to
use
the
product
that
will
make
their
lives
easier
and
then
a
couple
of
small
ones
that
I
wanted
to
highlight.
C
One
is
when
viewing
our
environments
page,
we
realized
from
feedback
from
users
that
the
sorting
order
was
not
logical.
It
was
ordering
based
on
the
timing
of
the
last,
commit
well
when
you're
looking
at
an
environment,
you
really
want
to
see
the
timing
of
the
last
deployment.
Here's
an
example
where,
because
there
was
a
rollback,
commit
the
commit
happened
recently
but
or
sorry
the
commit
happened
a
while
ago,
but
the
deployment
happened
most
recently
and
it's
all
the
way
down
at
the
bottom
in
the
list
of
deployments
for
this
environment.
C
C
Editor
so
think
about
your
editing,
your
pipeline,
and
you
want
to
know
what
would
this
pipeline
look
like
if
this
was
for
a
feature,
branch
or
my
default
branch
or
was
triggered
by
a
scheduled
job
or
was
part
of
a
merge
request,
we're
going
to
be
working
on
a
workflow
so
that
users
can
easily
simulate
their
their
pipeline
based
on
some
of
those,
whether
it's
the
branch
or
the
the
triggering
action
that
is
pretty
common
within
their
organization?
C
So
that's
a
great
example
of
improving
the
usability
of
the
pipeline
editor
so
that
you
can
more
rapidly
check
to
make
sure
that
how
you've
configured
your
pipeline
is
how
you
expect.
So
those
are
the
highlights
that
I'm
super
excited
about
14.4
from
the
ops
section
and
with
that
I'll
hand
it
over
to
josh
for
enablement
thanks.
D
Kenny
those
are
super
exciting
and
let
me
share
my
screen
for
the
name,
one
section
and
we
are
focused
on
three
themes:
this
release
and
the
first
one
and
the
key
focus
for
a
lot
of
our
teams
are
scalable
first
and
in
particular,
sas
reliability.
So
I've
called
out
three
here
in
this
particular
kickoff.
There's
a
lot
of
other
work
happening
as
well.
So
please
do
watch
the
group
pick
up
videos
on
our
kickoff
page,
but
the
dive
into
these
three,
the
first
one,
is
a
continuation
of
work.
D
We've
been
doing
for
some
time
now.
If
you've
been
watching
the
previous
kickoff
videos,
this
might
be
a
bit
of
a
repeat
but
effectively
we
had
10
years
ago
when
goodluck
got
started.
A
relatively
small
key
and
literature
used
for
our
primary
key
on
some
tables,
and
you
can
see
how
we
were
on
gitlab.com,
at
least
approaching
the
total
capacity
around
80
on
some
of
these
tables.
D
We
have
10
of
13
tables
completely
completed
and
we're
hoping
to
have
the
rest
of
the
three
completed
this
month
and
wrapped
up
in
14.4
for
our
self-managed
users,
and
the
best
news
is
that
our
self-managed
admins
don't
have
to
worry
about
anything
at
all
here.
It's
all
completely
transparent
in
the
background,
and
they
can
rest
assured
that
they
can
grow
their
gill
of
instances
for
a
long,
long,
long
time
to
come
so
great
work
from
database
team
they're,
hopefully
wrapping
this
up
in
this
release.
D
We
also,
of
course,
need
to
make
sure
we
can
continue
to
scale
our
redis
instances
as
gitlab.com
also
scales
as
well.
We
have
two
clusters
currently
and
we're
going
to
be
going
through
and
further
partitioning
our
redis
persistent
cluster,
so
the
memory
group
will
be
going
through
and
splitting
out
the
session
keys.
D
Those
are
the
information
that
tracks
who's
logged
in
and
for
how
long
to
a
new
writer's
cluster,
we
were
approaching
effectively
some
cpu
saturation
on
the
redis
cluster
in
this
case,
and
so
this
will
give
us
additional
room
to
continue
to
continue
to
grow.
Our
writer's
cluster
is
by
effectively
partitioning
this
workout
into
additional
clusters,
so
thanks
the
memory
team
and
thanks
to
the
scalability
team
for
also
supporting
them
in
this
work,
similar
to
the
postgres
work
of
the
primary
keys.
D
This
will
also
not
be
required,
and
so,
if
you
don't
need
this
level
of
scale
for
our
self-managed
users,
you
won't
have
to
stand
up
as
separate
british
infrastructure.
So
don't
worry
about
that,
but
know
that
if
you
need
it,
the
support
is
there
tacking
on
to
what
kenny
mentioned
about
the
decomposition
effort
for
the
starting
team.
This
is
the
overall
starting
group
kind
of
view
of
the
project
and
so
we're
going
through
in
14.4,
and
we
are
working
on
creating
a
benchmarking
environment.
D
So
we
can
compare
the
performance
and
overall
effectiveness
of
this
particular
strategy.
Ensure
things
are
working
and
we're
also
working
with
the
ci
groups
and
the
much
of
other
groups
to
help
make
sure
that
their
features
continue
to
work
in
this
new
dual
database
environment
so
effectively.
What
we're
doing
here
is
that
in
postgres
you
could
only
write
to
a
single
node
at
a
given
time,
and
single
nodes
can
only
get
so
big,
and
so
this
effectively
puts
a
natural
cap
on
how
many
writes
you
can
get
into
your
database
at
any
given
time.
D
This
is
also
something
that
would
be
largely
transparent
to
a
lot
of
our
customers
on
the
self-managed
side,
who
don't
need
the
scale
effectively
we'll
have
a
separate
database,
we'll
create
and
put
it
there,
but
keep
it
in
the
same
database.
Cluster,
and
so
you
only
need
to
worry
about
managing
a
separate
database
infrastructure
if
you
actually
need
this
scale,
and
so
again
don't
worry
about
it,
but
be
confident
that
gillette
can
scale
with
you.
Should
you
need
it,
which
is
great
from
there?
D
D
What's
not
entirely
clear.
Is
that
if
I
just
hit
enter,
I
will
actually
get
this
first
option
here
and
so
we're
going
ahead
and
making
that
much
more
clear
by
calling
out
the
scope
right
there
in
the
search
bar
will
also
be
dynamically,
making
it
bigger.
So
once
you
click
on
the
search
bar
you'll,
get
more
space
to
view
more
of
the
text
and
have
a
better
user
experience
so
looking
forward
to
that
from
the
search
team.
D
Additionally,
the
search
team
is
also
going
to
be
adding
additional
filtering
options
to
code
search
code
search
is
one
of
the
most
commonly
used
kind
of
jobs.
We've
done
in
our
codes
in
our
overall
global
search
functionality,
and
we
want
to
make
it
better
and
easier
for
users
to
find
things
that
they're
looking
for
and
so
we're
working
on,
adding
the
ability
to
actually
filter
based
on
what
language
the
code
file
is
in.
D
So
right
now
with
geosecondaries,
they
are
read
only,
and
so
you
have
to
kind
of
be
mindful
of
that.
If
you
want
to
use
it
for
the
performance
benefits,
you
have
to
particularly
go
there
and
you're
going
to
get
this
kind
of
read-only
banner,
but
we
are
working
to
transparently
proxy.
Those
back
to
the
primary
the
overall
benefit
here
is
that
users
will
no
longer
need
to
know
or
be
aware
that
any
secondaries
actually
exist.
D
They
can
simply
access
the
url
gitlab
can
then
direct
them
to
the
best
geosecondary
for
their
location,
and
then
they
can
interact
with
it
as
if
it
was
the
primary
so
make
issue
comments.
You
know,
change
milestones,
make
commits
that
will
all
work
completely
transparently
and
so
users
can
just
use
gitlab
and
their
performance
will
be
great
and
they'll
automatically
be
taken
to
the
right
location
for
their
particular
location
in
the
world.
D
We
have
our
new
gitlab
operator
for
deploying
gitlab
on
kubernetes
and
openshift
that's
becoming
available
in
14.3
or
in
just
two
days,
and
now
you
want
to
go
through
and
take
that
and
make
it
officially
red
hat
certified.
This
will
allow
it
to
be
enabled
to
be
published
in
the
red
hat
marketplace
and
make
it
overall
easier
to
consume.
D
Also
working
through
on
adding
additional
fips
compliance
efforts
for
our
packages,
so
we
had
some
improvements
here
in
14.3
and
we'll
be
carrying
those
forward
and
14.4.
So
hopefully,
overall
have
a
fips
compliant
version
of
gitlab
that
users
can
deploy
if
they
need
it.
So
that's
it
for
the
enablement
section
and
I'll
be
passing
it
back
over
to
david
to
take
it
from
here.
B
B
B
That
is
what
the
current
focus
on
is
improving,
that
over
to
the
source
code
team,
they're,
currently
working
on
supporting
the
dependency
proxy
as
part
of
the
work
for
workforce
component
of
the
product.
This
is
a
great
example
of
partnership
across
group,
where
the
create
stage
is
supporting
the
package
stage
on
being
able
to
asynchronously
download
packages
and
it
not
impact
the
user's
usability
of
the
product
over
to
code
review.
B
B
As
far
as
this
work
based
off
user
research
will
be
moving
to
a
more
simplified
version,
that's
more
actionable
and
that
you
can
see
here.
Is
it
giving
you
the
current
status
actions
you
need
to
be
taking
or
not
taking,
and
then,
of
course,
then
the
merge
button
and
then
wrap
up
the
create
stage
with
the
editor
team.
They're
focused
on
gitlab
posted
first,
as
well
as
reliability
and
scalability.
B
The
first
time
to
highlight,
for
you
is
the
work
around
rendering
very
large
markdown
files
within
the
wiki
today
that
can
lead
to
occasional
500
errors.
The
goal
this
is
significantly
improve
the
performance,
with
a
focus
on
improving
the
availability
of
that
component
and
finally
they're
working
on
a
redesign
of
the
state
within
the
web.
Ide
today,
the
web
ide
does
have
some
performance
impacts.
B
B
The
first
item
to
highlight
for
you
is
improving
around
full
text.
Search,
reduce
the
overall
number
of
500s
that
can
be
generated,
as
well
as
improving
the
performance
of
the
search
in
general.
The
one
thing
I
do
want
to
highlight
for
you
is:
we've
talked
a
lot
about
plan
focused
on
infradev
and
performance,
starting
this
week,
they've
actually
moved
to
green
within
their
error
budgets
showing
a
99.75
uptime
so
just
slightly
above
the
goal,
and
with
these
computer
improvements
they'll
continue
to
see
that
get
better.
B
The
product
planning
team
within
plan
is
continuing
to
work
for
it
on
the
work
items.
Initiative
example
of
this
is
being
able
to
move
things
like
epics
down
to
the
project
level.
This
is
in
partnership
with
the
manage
stage
in
the
work
on
workspace,
which
I
plan
on
talking
about
on
the
next
kickoff
call.
But
if
you
go
to
the
docs,
you
can
search
your
workspace
and
see
the
project
and
the
current
status
they're
also
kicking
off
a
growth
experiment
which
I
think
is
rather
exciting.
B
They're
focused
on
how
we
can
drive
more
adoption
of
the
boards.
The
current
implementation
looks
like
this
today.
If
I
want
to
create
a
board,
I've
got
to
go
to
the
selector
and
then
go
all
the
way:
the
bomb
to
click
for
a
board
they're
going
to
do
a
growth
experiment
around
moving
the
crate
new
board
to
a
better
location
as
well
as
potentially
duplicating
the
ability
to
create
a
board.
B
Obviously
those
are
the
things
we
try
to
stay
away
from
and
that's
why
the
growth
experiment
will
help
us
validate
that
and
then
finally,
to
wrap
up
with
the
manage
stage,
manage
agents
very
much
focus
the
entire
stage
on
scalability
reliability
and
burning
down
some
infra-death
tech
depth.
However,
the
front-end
teams
do
have
a
little
bit
of
bandwidth,
as
most
of
that
is
backing
related.
A
great
example
of
this
is
an
improvement
to
the
dev
ops
adoption
report.
This
will
be
introducing
a
trend
over
time
breath,
which
you
can
see
here,
including
a
line.
B
The
thing
I
do
want
to
highlight
is
their
effort
on
bringing
parity
between
self-managed
and
gitlab.com
market
lab
posted
first
here
they're
working
on
enabling
the
ability
to
check
your
sso
status
on
api
activity.
That'll
be
a
new
component
introduced.
We
talked
about
this
a
couple
months
ago
when
it
was
a
new
idea,
but
this
is
focused
on
bringing
that
parity
between
the
two
deployments.
B
It
also
involves
related
to
being
able
to
update
enterprise
user
status
on
every
sync.
Today
is
a
one-time
poll
they're
going
to
be
focusing
on
the
ability
to
continue
to
synchronize
that
so
you
can
do
things
such
as
set
new
product
project
limits
or
can
create
groups
within
your
enterprise
user
group
and
from
there
be
able
to
give
you
that
parity
on
get
live,
hosted
first
as
well,
and
then
to
wrap
up
the
manage
stage.
The
compliance
team
is
continuing
their
work
related
to
group
level
settings.
B
This
is
allowing
us
to
then
inherit
settings
down
that
are
immutable.
An
example
of
this
is
the
work
around
merge,
request
approvals,
the
screenshot
we
talked
about
last
time,
but
here
you
can
see,
there's
two
options
that
are
grayed
out
and
they
show
a
lock.
These
are
things
that
have
been
set
and
are
enforced
at
the
group
level.
That
must
be
run
at
the
project
level.
This
is
a
great
step
forward
on
usability,
but
also
improving
our
application
security
testing
leadership.
A
Thank
you,
everyone
that
was
an
amazing
update.
I
noticed
a
few
things
that
I
want
to
highlight.
First
is
pre-filtering
source
files
for
sas
scans,
especially
for
large
reposts.
It's
really
helpful
filtering
options
on
code
search
can't
wait
for
that
to
help
me
find
exactly
what
I
want
also
excited
about
the
full
text,
search
for
work
by
the
plan
team.
A
Mr
richard
usability
improvements,
devops
adoption
trend
reports,
amazing
work
overall.
I
also
noticed
a
lot
of
focus
on
reliability
and
teams
coming
together
to
help
the
entire
product
be
more
reliable.
I
saw
composition,
analysis
container
scanning
and
various
other
secure
and
dev
teams
coming
together
to
help
reliability
of
the
product
as
a
whole
focus
on
error
budgets.
That
means
improving
reliability,
fixing
timeouts
of
various
kinds,
whether
it's
in
ci,
linter
or
copedura,
timeouts.