►
From YouTube: 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
Welcome
to
the
12.5
gitlab
kickoff
review,
my
name
is
Scott
Williamson
I'm,
the
VP
of
Product
Management
at
get
lab
and
I'm
happy
to
be
your
emcee
for
today,
as
in
typical
get
love
fashion,
we
are
iterating
on
this
meeting.
Just
like
we
iterate
on
our
product,
you
might
notice
the
artifact
that
we're
gonna
review
today
has
changed
another
and
also
and
get
left
fashion
we
like
to
use
our
own
product,
so
we're
gonna
use
our
own
handbook
to
run
the
kickoff
review
from
here
on
out.
A
This
page
is
auto-generated
based
on
all
the
issues
behind
the
scenes,
and
so,
if
you're,
following
along
at
home,
about
that
gitlab
duck
comm
splash
direction,
slash
kickoff
is
where
you
can
find
this
page
on
your
own
note
that
there's
a
couple
links
in
here.
One
of
them
is
a
link
to
a
YouTube
playlist
of
all
the
kickoff
videos
and,
as
you
scroll
down
you'll
see
in
each
section,
we
have
links
to
videos.
A
A
Also
there's
a
feedback
link
here
so
at
the
end
of
this
we'd
love
to
get
feedback
on
how
this
format
how
this
meeting
worked
for
you,
we
want
to
continue
to
iterate
and
make
it
as
impactful
as
possible.
So
also
a
few
other
notes.
I
also
note
that
we
do
plan
ambitiously.
We
asked
our
team
to
to
be
aggressive
as
they
think
about
what
what
we're
going
to
plan
and
as
a
result,
we
may
not
get.
A
All
of
this
done
view
this
as
our
intention
for
the
release,
but
not
necessarily
a
commitment
and
may
some
of
these
things
may
may
slide
that
we
want
to
play
in
ambitiously,
so
that
let's
hand
it
over.
We
have
a
series
of
speakers
that
will
cover
the
dev
section
as
Erik
Brinkman,
the
CS
CD
section
is
Jason
Lenny,
the
ops
section
will
be
Kenny,
Johnston
secured,
is
Nicole
Schwartz
and
a
security
defend,
and
then
enablement,
Josh
Lambert.
A
B
So
much
Scott,
my
name
is
Eric
Brinkman
I
am
the
director
of
product
for
the
deaf
section.
The
deaf
section
is
the
first
three
stages
of
the
DevOps
life
cycle.
That's
managed
plan
and
creates,
and
we
have
a
ton
of
stuff
to
run
through
in
the
next
20
minutes.
So
I
will
attempt
to
be
to
be
pretty
quick.
I'll
start
with
the
manage
stage
in
the
manage
stage.
We
have
two
big
themes
that
we're
going
to
be
focused
on.
B
The
first
theme
is
focusing
on
enterprise,
great
improvements,
and
the
second
theme
is
analytics
so
to
assist
our
customers
with
enterprise
readiness,
we're
going
to
extend
the
soft
Elysion
functionality
that
we
are
already
working
on
for
projects
to
groups,
and
this
will
allow
users
to
recover
from
accidental
deletion
of
groups
by
placing
groups
in
a
read-only
state
before
actually
deleting
them.
We'll
also
be
focusing
on
the
creation
of
a
new
construct
inside
of
github
called
policies.
B
Policies
are
a
framework
that
lets
users
define
effects,
actions,
resources
and
conditions
and
will
be
a
powerful
tool
to
help
implement
things,
like
least
privileged
access
inside
of
gitlab,
and
so
you
can
see
some
of
the
mock-ups
here
in
the
issue
for
analytics
we'll
be
continuing
to
focus
on
the
type
of
work,
improvements
or
productivity
analytics.
This
will
include
a
breakdown
for
engineering
managers
to
understand
this.
B
In
the
plan
stage,
we're
focused
on
two
large
themes
as
well:
improving
sprint
management
inside
of
gate
lock
and
improving
our
epics
experience
in
order
to
improve
our
sprint
management,
we'll
be
releasing
a
feature
to
allow
multiple
milestones
to
be
attached
to
an
issue
or
merge
request.
So
this
will
let
our
users
take
advantage
of
saying
an
issue
is
going
to
be
worked
on
in
a
given
sprint,
but
then
also
released
in
a
given
release
and
a
lot
of
organizations
detangle.
B
Those
two
constructs
so
pretty
excited
about
that
and
we'll
also
be
providing
a
more
historically
accurate
burndown
chart.
So
if
you
today,
if
you
add
a
bunch
of
issues
into
into
with
like
a
release
after
that
release,
has
started,
you
essentially
have
added
a
bunch
of
scope
to
the
milestone
that
should
be
recorded.
And,
conversely,
if
you
take
issues
that
should
have
been
delivered
in
a
milestone
and
move
them
out,
you
would
want
to
understand
that
in
the
Byrne
chart.
B
But
if
you
do
that
in
the
burndown
chart,
but
if
you
do
that
today,
since
you
lose
all
of
that
historical
context
and
it's
difficult
to
tell
how
much
scope
was
either
added
or
how
much
work
was
missed
in
a
given
milestone,
so
burndown
chart
should
begin
to
tell
a
better
story
of
history
for
a
team's
performance
for
epics.
I'm,
really
excited
that
we're
going
to
start
making
epics
a
little
bit
easier
to
find,
instead
of
give
up
and
just
easier
to
work
with
in
general.
B
So
pretty
pretty
pumped
for
that
work
and
I
think
that'll
be
a
huge
win
for
our
customers
if
you've
ever
linked
issues
or
epics.
Together,
you've
probably
been
frustrated
by
that
experience,
because
it
requires
you
to
go
and
copy
and
paste
a
link,
but
in
this
issue
we're
actually
going
to
let
you
search
for
an
epic
or
an
issue
when
you're
linking
issues
together
and
so
quite
excited
for
that
improvement
at
well
on
the
kickoff
page,
there's
a
bunch
more
improvements
to
epics.
B
So
please
take
a
look,
but
in
the
essence
of
time,
I
just
wanted
to
highlight,
highlight
these
two
and
then.
Lastly,
in
the
plan
stage,
I
also
wanted
to
highlight
the
fact
that
we're
going
to
be
starting
to
invest
in
two
requirements:
management
and
start
the
start
of
that
is
going
to
be
introducing
dependencies
between
issues,
so
we're
going
to
add
a
blocks
and
is
blocked
by
construct
inside
of
get
lot
of
issues
which
should
help
identify
dependencies
between
issues
to
understand,
what's
blocking
or
what's
blocked
by
so
quite
quite
excited
for
that
as
well.
B
B
So
we've
got
some
remaining
performance
problems
in
in
rendering
gifts
on
the
changes
time
that
and
when
we
break
apart
the
request
for
rendering
that
disk
is
really
going
to
help
the
performance
of
a
merge
request,
we're
also
going
to
split
apart
loading,
syntax
highlighting
to
load
those
incrementally
and
then
cache
highlighted
em.
Our
disks
file
by
file
so
really
excited
to
see
some
of
those
performance
changes,
but
also
excited
to
see
some
of
the
kind
of
user
experience.
Changes
coming
to
the
merger
quest
as
well.
B
Well,
you
can
see
on
my
screen
is
we're
making
a
change
that
will
automatically
update
the
merge
widget
when
new
commits
are
pushed.
Currently,
if
you
do
that,
you
have
to
reload
the
merge
request
in
order
to
merge
the
merger
quest
and
a
common
workflow
is
to
apply
a
suggestion
yourself
very
quickly
in
the
merge,
a
quest
on
discussion,
and
then
it
should
be
very,
very
easy
to
merge
that
without
requiring
a
reload
and
so
we'll
be
adding
this
one.
B
Now
it
can
be
hard
to
find
you
can
scroll
past
it
pretty
easily
we're
going
to
put
this
right
below
the
title
and
then
we're
also
going
to
collapse.
The
merge
request
description
into
the
discussion
so
that,
when
you
view
a
diff,
the
description
goes
away.
You
can
just
focus
in
on
the
diff,
so
some
really
great
improvements
coming
to
merge
requests
experiences
as
well,
a
few
other
things
to
highlight
and
create
very
quickly.
B
We
are
continuing
our
work
on
our
some
of
our
research
spikes
into
our
high
availability,
freak
Italy
super
important
for
enterprise
architectures,
with
failing
failing
nodes
for
giddily,
and
we
want
to
make
sure
that
experience
is
robust.
We
are
going
to
put
some
effort
into
the
continued
testing
of
Prefect,
which
is
the
optional
reverse
proxy
service
for
giddily,
which
will
eventually
let
multiple
Ghibli
nodes
run
behind
the
reverse
proxy.
B
Previously,
we've
launched
the
ability
to
comment
on
designs,
but
those
comments
are
buried
in
the
designs
tab
when
you
navigate
inside
of
an
issue.
Those
comments
should
be
pulled
out
into
the
main
discussion
portion
of
the
issue,
so
that
those
comments
are
seen
right
next
to
other
other
comments
on
the
issue
so
we'll
be
doing,
that
will
also
be
generating
smaller
versions
of
design
images
when
they're
uploaded.
B
C
All
right,
hopefully,
everybody
is
able
to
see
this
now
what
we've
got
planned
for
C
ICD
we've
got
a
lot
of
exciting
stuff
planned
here,
including
some
very
popular
items
that
have
been
out
for
a
while
that
what
you've
got
scheduled
and
we're
looking
forward
to
delivering
probably
the
most
exciting
one.
There
is
the
first
one
on
this
list,
which
is
getting
windows
shared
runners
out
in
beta
form,
that's
something
that
we've
been
working
on
for
a
while
with
a
runner
team.
We
put
a
lot
of
work
into
that.
C
We
had
worked
on
the
shared
the
windows
executor
before
that,
and
all
of
that
is
sort
of
built
up
to
us
getting
to
you
having
windows
shared
runners,
so
we're
hoping
with
the
12.5
release
to
start
our
beta.
Some
of
the
details
of
how
that's
exactly
going
to
work
is
not
is
not
exactly
published
yet
and
not
fully
decided,
but
we'll
be
working
on
there
if
you're
interested
in
following
along.
Please
join
that
epic
and
join
the
conversation.
C
We're
also
working
on
improving
an
artifact
based
view
for
the
j-unit
XML,
and
what
this
does
is
lets
us
show
more
about
what
the
tests
are
doing
when
they're
running.
So
you
can
see
tests
that
are
failing
and
get
more
info
on
that.
You
can
get
more
info
on
the
tests
that
are
passing
as
well,
including
metadata
on
those,
and
this
will
just
make
it
a
much
nicer
experience
for
when
using
the
the
ju
unit.
Xml
results
that
are
built
in
to
get
low.
C
We've
also
got
here
the
visual
review
app
we're
improving
the
style
of
styling
on
that
and
usability
in
a
lot
of
different
ways.
In
particular,
we
are
making
it
easier
to
provide
multiple
pieces
of
feedback
and
provide
feedback
on
multiple
mr-s.
So
if
you
haven't
used
this
feature
yet
now's
a
good
time
to
try
it
and
check
out
some
of
the
new
features
that
we're
adding
to
make
it
easier
to
use
easier
to
configure
as
well.
D
C
Keeping
the
latest
artifact
for
each
job
is
another
feature
that
we're
really
excited
to
be
delivering.
What
this
will
do
is
make
it
possible
so
that
the
latest
artifact
for
a
given
job
is
always
kept
around,
and
what
this
will
let
you
do,
then,
is
set
a
very,
very
aggressive,
expiration
policy
on
your
artifacts.
C
So
you
can
manage
the
disk
space
that
your
artifacts
are
using
in
an
easier
way
where
you
can
readily
get
rid
of
any
artifacts,
that
you
don't
really
need
and
not
keep
them
around
forever,
while
at
the
same
time
knowing
that
you've
always
got
the
last
one
that
was
built.
It
was
difficult
to
balance
that
previously,
and
this
would
make
that
a
lot
easier.
C
Next
up,
is
these
two
they're
they're
really
related
to
each
other,
particularly
I
get
laps
yeah,
yeah
well
from
changing
by
developers
and
supporting
the
gitlab
CI
AML
outside
of
the
repository.
What
we're
doing
there
is
making
it
possible
to
configure
your
project,
so
the
get
levy
IML
is
outside
of
the
repo.
C
The
reason
for
this
is
originally
so
that
open
source
projects
that
are
building
packages
or
building
you
know
distributions
that
contain
packages
that
they
don't
have
right
access
to
the
repo
or
don't
want
to
introduce
a
get
live
CIE
em
all
into
they
can
store
these
somewhere
build
a
project
easily.
What
this
also
lets
us
do
is
use
that
external
repo
art,
the
act,
the
external
get
live,
see
I,
am
to
place
the
get
live,
see.
I
am
all
in
a
different
project
that
has
different
permissions
and
then
can
be
managed
in
a
different
way.
C
So
that's
that's!
A
nice
improvement
there,
we're
sort
of
getting
into
from
one
on
that,
and
it's
always
nice
than
we
can
do
that.
We
had
a
lot
of
great
conversations
with
customers
and
these
two
that
really
helped
us
come
to
a
creative
solution
and
yeah.
It's
always
nice.
When
you
get
a
chance
to
do
there
on
the
package
side,
we're
continuing
some
of
the
big
items
that
we've
been
working
on
for
the
last
release
as
well.
C
That
will
make
the
package
UI
easier
to
work
with,
and
then
the
other
item
that
I
wanted
to
mention
was
improving
the
performance
of
the
delete
api
for
our
teams
that
are
managing
very,
very
large
instances
of
gitlab.
The
delete
api
for
the
container
registry
has
been
a
sore
spot
where
it
takes
a
really
long
time.
It's
not
highly
performant,
it's
hard
even
to
iterate
over
the
item,
so
we're
diving
into
that
and
making
that
easier
to
use
in
order
to
manage
the
disk
space
that
your
containers
are
taking,
then.
C
We
are
also
making
it
possible
to
you,
filter
issues
and
merge
requests
by
release,
so
we've
introduced
a
feature
where
you
can
associate
milestones
one
or
more
milestones
with
the
release
and
it'll
be
possible
now
to
see
to
filter
from
an
issue
list
on
on
the
releases
as
well,
which
I'll
tie
this
together
in
a
very,
very
nice
way.
We're
making
it
possible
also
to
generate
the
get
the
release
from
the
gate
level.
Ci
ml
at
the
moment,
with
a
feature
in
a
new
state.
C
We're
only
really
able
to
do
that
with
the
curl
command,
but
yeah
it'll
be
much
more
nicer
to
be
able
to
do
that
and
get
lepsy
idml
directly
and
then
we're
also
adding
it
in
the
UI,
which
was
an
item.
What
we
pulled
in
from
the
last
release
as
well,
cleaning
up
stale
environments
is
something
that
it
again
for
larger
instances
is
really
interesting.
C
If
you
have
too
many
branches,
if
you
have
too
many
users
or
intricate
interacting
with
your
projects,
you
can
end
up
with
a
lot
of
environments
that
are
running
unnecessarily
and
there
isn't
really
an
easy
way
to
manage
those
and
clean
them
up.
So
we're
looking
at
some
new
controls.
That'll
make
that
easier.
You
can
clean
up
stale
environments
in
an
easy
way
and
and
apply
some
rules
and
have
that
be
nice
to
use.
C
And,
finally,
the
very
last
item
that
I
want
to
talk
about
is
limiting
pipeline
concurrency
using
some
cores,
which
is
to
say
that
you
can
have
a
named
configuration.
Typically,
you
might
name
this
the
same
thing
as
an
environment
and
that
will
prevent
more
than
one
deployment
happening
to
any
job.
That
is
using
that
same
same
lock.
C
So
if
you
have
a
physical
environment,
if
you
have,
if
you
want
to
control
deployments,
to
a
production
environment
and
in
an
orderly
way
and
not
using
merge
chains,
you
can
do
this
using
some
of
force,
I'm
just
getting
even
work.
For
you
know
kind
of
unusual
testing
environments
like
where
there's
a
physical
environment-
that's
not
just
a
test
environment
that
you
might
deploy
to
you,
but
it's
like
a
shared
piece
of
hardware.
That's
under
test
like
in
manufacturing
things
like
that.
C
So
a
bunch
of
cool
stuff
here
for
the
CI
CD
section
feel
free
to
dive
in
and
check
out
the
the
rest
of
the
things
that
we've
got
here
as
well.
There's
there's
a
ton
of
great
content,
there's
also
videos
that
dive
into
CI
testing
and
runner
that
you
can
check
out
and
all
that
stuff
is
hopefully
super
exciting
for
you
as
well
feel
free
to
reach
out
to
me.
If
you
have
any
questions
on
that
stuff,
Thanks
back
to
you,
Scott
thank.
D
Thanks
Scott,
let
me
share
my
screen:
real
quick,
yeah
yeah,
so
my
name's
Kenny
Johnston
I
cover
the
ops
section
that
includes
both
our
configure
and
monitor
stages.
All
hit
a
couple
of
the
highlights
here.
We're
doing
a
couple
of
thumb,
attic
things
around
improving
the
enterprise
robustness
of
our
server
lists
set
of
features.
So
we
rely
on
K
native
and
we're
adding
it
SSL
support
and
the
ability
to
kind
of
define
a
single
public
domain
for
you
to
use
for
SSL
support
for
your
server
list
functions.
D
We're
continuing
to
iterate
on
our
auto
dev
ops,
functionality,
making
it
more
efficient
and
faster
by
using
a
different
method
for
creating
your
docker
containers,
a
different
build
pack,
as
well
as
having
it
not
run
in
places
where
it's
and
has
been
a
pain
point
for
customers
that
we've
heard.
But
there
are
a
couple
of
ones
that
I
want
to
highlight
outside
of
those
themes.
D
The
first
is
we're
continuing
to
put
effort
into
an
item
that
we've
spoken
about
in
previous
kickoffs
around
adding
AWS
eks
support
to
get
labs
so
that
you
can
natively,
provide
your
AWS
credentials
and
create
eks
clusters
within
the
get
lab
UI
that
can
then
be
attached
and
used
to
add
managed
applications.
The
next
one
is
a
really
cool
MVC
for
our
first
step
in
chaos.
D
So
that's
super
cool
I
might
encourage
you
to
check
out
the
videos
from
the
configure
team,
Daniel
and
Viktor
the
two
PM's.
There
did
a
great
job
summarizing
their
issues
in
more
detail.
On
the
monitor
side,
we
have
a
couple
of
a
couple
of
big
themes
and
then
as
well,
one
or
two
items
that
I
would
love
to
highlight.
The
first
is
we're
really
investing
in
getting
our
error
tracking
to
viable.
D
So
today
you
can
attach
the
credentials
to
your
to
a
sentry
instance
and
surface
some
basic
information
about
those
errors
in
get
lab
itself
for
those
who
use
their
tracking.
This
is
super
useful
for
both
the
developer
workflow,
who
needs
to
to
triage
and
adjust
their
application
while
on
a
development
branch,
but
also
the
production
team
who
wants
to
see
the
error
is
coming
in
from
production
users.
D
D
Lastly,
we're
doing
a
couple
of
iterations
around
bringing
the
observability
system
that
you've
defined
for
your
production
application
into
source
control
again
right
alongside
your
application,
so
that
you
can
do
things
like
define
the
dashboards
more
easily
in
the
structure
of
those
dashboards,
as
well
as
the
alerts
that
you
want
for
your
application
monitoring
and
those
get
deployed
automatically
along
with
your
application.
So
those
are
a
couple
of
the
highlights
for
the
op
stage
that
I'm
really
excited
about
in
12.5
I'll
hand
it
back
over
to
you
Scott.
E
Hey
so
I
wanted
to
highlight
a
couple
things
if
you
want
to
get
into
the
details,
we've
got
three
videos
that
you
can
go
for
more
in-depth
looks.
The
first
thing
is
that
there's
going
to
be
a
secret
detection
available
to
run
on
the
full
history
of
your
repository,
so
you
can
find
any
secrets
that
have
been
previously
exposed.
This
is
really
great
because
it's
a
common
mistake
that
has
a
high
risk.
Also,
if
you
have
a
react
project
and
you've
wanted
to
use
our
static
application,
security
test
or
sassed.
E
That's
going
to
be
coming
and
you'll
be
able
to
do
that,
starting
with
the
next
release,
and
also
have
you
ever
wanted
to
know
what
security
features
you
actually
have
turned
on
or
which
ones
are
available.
We're
gonna
make
that
a
lot
easier.
Instead
of
having
to
go
to
your
config
file,
there's
now
actually
going
to
be
a
configuration
page
within
the
UI
that
you
can
look
at
and
see
exactly
what
things
are
enabled
and
not
yet
enabled.
E
So
you
know
what
your
options
are,
and
the
last
thing
kind
of
I
want
to
highlight
for
secure.
Is
that
we've
been
on
kind
of
a
streak
of
getting
all
of
our
security
scanners
to
work
offline?
So
if
you've
got
an
air-gapped
instance,
you
can
still
run
security
scans
and
container
scanning.
As
of
the
end
of
this
next,
really,
it
should
hopefully
be
available
to
you
if
you're
running
in
an
air-gap
situation
and
I'll
also
be
covering
defend
and
right.
E
Now,
we've
got
two
things
and
defend
and
I
kind
of
wanted
to
tell
you
a
little
bit
about
the
laughs,
statics
reporting.
That's
going
to
benefit
you
if
you
want
to
really
quickly
check
to
see
if
traffic
is
flowing
through
and
things
are
functioning
as
well
as
what
is
the
block
and
allow
ratio.
So
they'll
give
you
some
quick
statistics
on
that
which
should
make
troubleshooting
and
information
easier
for
you
to
come
by
and
the
last
one
is
a
really
big
effort.
We've
been
working
on
for
a
while.
E
It's
where
you're
going
to
be
able
to
escalate
a
finding
that
you
have
into
a
vulnerability
and
that
vulnerability
will
be
really
easy
for
you
to
track
and
share
it's
going
to
be
something
similar
to
an
issue
but
with
different
attributes.
But
now
you
can
much
more
easily
check
on
the
history
of
something
share.
It
with
other
people,
attach
it
to
things,
and
so
that's
going
to
hopefully
make
everyone
have
a
lot
easier
time
with
tracking
these.
F
And
we
have
three
main
themes
working
to
accomplish
this
release.
The
first
is
improving
the
performance
of
gitlab.
To
that
end,
we'll
be
working
to
enable
Puma
on
get
lab.
Comm
Puma
is
a
multi-threaded
application,
server
versus
unicorn,
which
is
per
process
by
shifting
to
multi
threads.
We
see
memory
reduction
of
about
33
percent
of
our
instances.
This
can,
of
course,
give
you
more
Headroom
as
well
as
more
performance,
and
so
we're
very
excited
about
this.
We're
also
working
to
drive
down
hotspots
more
code.
F
Finally,
we're
working
on
enabling
geo
and
get
lab
calm
to
this
end,
we'll
be
tracking
the
rollout
to
staging
first
and
then
we'll
be
define
the
architecture
for
production.
This
way,
we'll
be
well-positioned
to
continue
to
enable
good
comm
in
production
in
the
near
future.
Here
that
executes
releases.
So
those
are
the
key
things
work
and
enable
at
this
release
and
back
to
use,
got
to
wrap
it
up.
Thank.
A
You
Josh
appreciate
all
the
speakers
who
have
explained
all
the
great
stuff
we're
doing.
I
also
want
to
thank
all
the
contributors
behind
them
internally
and
externally
for
making
all
this
stuff
come
true
over
the
next
month
and
I
also
want
to
thank
every
one
of
you
who
joined
in
to
follow
along.
We
appreciate
your.