►
From YouTube: 14.2 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
Greetings:
everyone
happy
monday
on
the
heels
of
two
amazing
14.x
releases.
Today,
I'm
excited
to
kick
off
our
monthly
release.
14.2
we
just
added
a
three
year
product
vision.
Video
would
love
for
you
to
check
it
out
and
let
us
know
what
you
think
and
our
one
year
themes
continue
to
be
the
same
ast
leadership,
adoption
through
usability
and
sas
first
posture.
A
As
you
know,
we
plan
ambitiously
and
our
roadmaps
are
subject
to
change
without
notice.
Having
said
that,
you
can
follow
along
and
contribute
by
going
to
the
direction
kickoff
page
and
looking
at
all
the
videos
and
issues
we
welcome
any
and
all
contributions
and
inputs
with
that.
Let
me
share
the
order
of
kickoff.
Today,
david
will
start
off
by
covering
the
development
in
the
sec
section
followed
by
kenny,
who
will
walk
us
through
the
op
section
and
josh
will
take
us
through
the
enablement
section
that
take
it
away.
David.
B
Thank
you
very
much
anu
and
let
me
get
my
screen
share
here,
so
to
kind
of
dive
into
the
dev
section.
First,
the
create
stage
is
focused
on
adoption
through
usability,
but
for
the
source
code
team,
they're
working
on
refactoring,
the
repository
browser
to
be
within
a
single
app
so
today,
they're
focused
on
moving
these
components
over
the
value
here
is
that
things
will
load
much
faster
for
the
user
and
will
continue
to
improve
the
usability
of
our
source
code.
Part
of
the
product.
B
The
code
review
team
is
focused
on
improving
the
merge
request,
experience
and
code
review
experience,
so
here
first
they're
working
on
improvements
to
how
merges
are
done.
This
will
include
new
icons
and
other
components
will
make
a
lot
more
crisp
for
you
to
understand
the
currency
of
your
merge
request.
B
This
is
a
multi-month
project,
they're
kicking
off
for
the
next
quarter
and,
of
course,
that'll
start
with
14-2,
including
that
is
restructuring.
The
merge
request
widget
today
inside
the
merge
request.
A
lot
of
the
interactions
are
below
the
merge
button
and
we
found
through
user
testing
that
does
not
flow
with
the
way
our
users
currently
look
at
the
ui.
B
So
part
of
this
will
be
relaying
it
out
here
you
can
see
here,
it's
telling
you
to
try
to
merge,
and
then
interactions
are
before
the
merge
button
itself,
and
you
can
see
that
the
whole
way
through
as
additional
components
are
exposed.
So
this
is
again
a
multi-milestone
project
but
improving
the
code
review
experience.
B
Both
the
combination
of
the
button
will
now
be
there,
as
well
as
being
able
to
embed
those
snippets
inside
the
content
editor
and
then
finally,
for
the
getaway
team,
they're
working
on
infradev
related
items
with
the
goal
of
making
getaway
cluster
even
higher
performance.
B
Again,
this
is
part
of
our
move
to
get
early
clusters,
the
default
for
getaway
and
the
team
is
very
much
excited
to
keep
on
pushing
forward
on
usability
there
for
the
plan
stage
also
focused
on
adoption
through
usability
and
improving
performance
via
infradev
focus.
First,
the
ecosystem
team.
They
are
looking
at
creating
a
proxy
for
self-managed
self-managed
git
lab
with
the
integration
for
giro.
So
what
you'll
see
inside
the
get
lab
app
inside
of
jira
is
the
option
to
select
self-manage
and
then
put
in
the
instance
url
today.
B
That's
something
that
has
to
be
done,
not
user
friendly
to
be
able
to
allow
self-managing
able
to
talk
to
a
jira
deployment
for
jira
issues.
The
project
management
team
is
focused
on
performance
improvements.
We've
been
highlighting
this
for
the
last
couple
of
kickoffs
again
here
focused
on
improving
the
search
api
when
listing
out
issues,
and
then
the
product
planning
team
is
starting
a
multi-milestone
project
of
introducing
a
feature
component
at
the
project
level.
As
you
can
see
here,
this
will
give
you
a
planning
component
at
the
project
level.
B
So
a
single
leveled
item
so
for
the
first
release,
they'll
be
focused
on
just
introducing
that
and
of
course,
there'll
be
multiple
npcs
after
that
to
get
it
properly
fully
integrated
in
and
then
wrap
up,
dev
with
manage
manage
is
focused
on
adoption
through
usability
as
well
as
sas.
First
here,
the
compliance
team
is
working
on
bringing
group
level
settings
in
for
merge,
request
approvals,
kind
of
give
you
a
sense.
B
What
that
looks
like
here
are
some
mock-ups,
starting
with
instant
instance
level,
so
here
I'm
setting
that
mrs
cannot
be
merged
from
users
who
make
a
commit
to
that
merge
request.
If
we
then
looked
at
it
at
the
group
level,
you'll
see
that
it's
now
enabled
and
grayed
out
that
cannot
be
disabled
and,
of
course,
at
the
project
level.
You
can
see
the
same
thing
again
as
well
as
things
implemented
at
the
group
level.
B
The
access
team
is
focused
on
providing
api
components
for
both
group
level.
Access
tokens,
as
well
as
samwell
group,
sync,
again
very
much
a
focus
on
improving
what
is
there
today
for
adoptability,
as
well
as
focusing
on
our
sas
or
get
lab,
managed
option
first
and
then
wrap
up
the
dev
section
and
manage
the
import
team
is
working
on
apis
for
group
migration.
B
This
will
be
a
huge
improvement
for
customers
who
are
moving
from
self-managed
to
sas
or
sas
back
to
self-managed,
given
the
capability
to
fully
migrate
the
project,
as
opposed
in
group
as
opposed
to
having
to
export
and
then
re-import
it
back
in
to
head
over
to
the
sex
section.
We
start
us
off
with
stack
analysis.
They're
continued
they're,
continuing
their
work
to
switch
to
semcrep
as
one
of
the
primary
analyzers
for
sas
with
14.0.
B
B
For
the
dynamic
analysis
team
they're
focused
on
their
desk
on
demand
scanner
scheduler.
That's
a
tongue
full
there
as
we
had
in
14.0.
We
had
our
initial
release
of
dast
on
demand.
It
might
have
actually
been
1312
and
now
we're
looking
to
expand
upon
that.
So
here
in
the
mock-up,
you
can
see
what
you
would
normally
see
today
for
an
on-demand
scan
at
the
bottom.
B
We're
also
looking
to
continue
to
expand
what
we've
released
related
to
our
new
das
browser-based
engine
here,
they're
focused
on
improving
some
of
the
passive
checks,
specifically
around
content
type
header
checks,
as
well
as
continuing
to
expand
that
to
the
point
where
we
can
begin
to
make
this
the
default
scanner
for
everyone
for
composition,
analysis.
They
are
focused
on
their
viable
to
complete
plan.
They
did
some
usability
testing
and
identified
some
other
areas
they
wanted
to
improve.
B
B
What
to
do
with
license
scanning
moving
forward,
as
we've
discussed
on
several
kickoff
calls,
we
put
license
scanning
on
hold
in
a
maintenance
mode,
while
we
focused
on
dependency
scanning
we're
now
this
year,
beginning
to
bring
that
back
and
see
whether
the
better
path
forward
and
they're
researching
everything
from
embedding
the
strictly
into
our
dependency
scanner
should
be
giving
everyone
just
a
single
engine
as
well
as
looking
at
other
projects
open
source
related
that
we
could
also
integrate
and
contribute
to
and
then
finally,
for
secure.
B
We
talked
on
the
last
couple:
kickoff
calls
about
the
ability
to
create
a
vulnerability
record
via
the
api.
This
is
now
bringing
that
functionality
into
the
ui
and
allowing
you
to
create
vulnerability
findings.
Here,
you
can
see
a
snapshot
of
what
that
will
look
like
right
off
the
vulnerability
report.
You'll
have
a
button
at
the
top.
That
says,
add
new
vulnerability.
B
B
This
will
allow
you
to
bring
in
external
results,
let's
say
from
external
pen
tests
and
have
them
all
be
on
a
single
view
within
gitlab,
really
nice
extension
of
what
the
platform
can
do
today
and
to
finish
up
the
sex
section
with
protect
with
14.0.
We
defaulted
to
trivia
as
the
container
scanning
engine,
starting
at
14
2
we're
working
on
making
that
run
against
running
containers.
So
this
is
going
to
blur
that
line
for
container
scanning
between
the
development
side
in
the
upside.
B
The
scanning
results
be
provided
within
the
typical
view
you're
used
to
today.
There'll
be
some
new
tabs
added
here
you
can
see
security,
and
here
are
the
four
new
vulnerabilities
that
were
found
from
the
last
running
against
the
container
on
a
highlight,
this
looks
very
much
like
the
vulnerability
report.
Our
goal
is
to
make
sure
you
have
a
unified
experience.
No
matter
where
you
are
in
the
ui
same
thing
will
be
true
about
any
found
access
tokens.
C
C
I
am
the
director
of
product
covering
the
ops
section
for
as
a
reminder,
the
op
section
is
comprised
of
verify
package
release,
configure
and
monitor,
and,
as
I
highlighted
in
our
last
kickoff,
we
have
a
new
top
level
direction,
page
called
deployment
which
covers
release
and
configure,
and
the
release
team
is
already
working
on
improvements
to
our
environment
dashboard
in
order
to
pursue
that
direction.
This
coming
release
I'm
going
to
go
through
some
highlights
that
cover
our
two
primary
themes
in
the
ops
section,
sas
first
in
adoption
through
usability
on
sas.
C
First,
I
want
to
talk
about
what
the
verify
ci
pipeline
execution
group
is
going
to
be
working
on
in
14.2.
Their
primary
focus
is
on
showcasing
ci
usage
in
your
project
and
group
level
to
users
in
a
more
user-friendly
way.
C
In
our
theme,
around
adoption
through
usability,
I
wanted
to
highlight
that
we're
going
to
be
adding
in
partnership
with
ibm
team,
gitlab
runner
support
for
power,
9
architecture
in
14.2.
The
ibm
team
has
been
working
alongside
us
to
contribute
this
capability.
C
We're
excited
to
see
it
ship
in
14.2
we're
also
going
to
be
working
on
adoption
of
gitlab
ci
via
our
pipeline
editor.
So,
over
the
last
six
releases,
we've
been
adding
new
capabilities
to
the
pipeline
editor.
One
thing
that
we
had
not
added
was
the
ability
to
check
the
syntax
of
your
of
the
cima
that
you're
writing
against
a
kind
of
known,
up-to-date
schema.
We
use
an
external
schema,
that's
stored
in
schema,
store
and
for
self-managed
instances.
That's
meant
that
you
know
if
you
didn't
have
an
external
connection
from
your
gitlab
instance.
C
You
weren't
able
to
get
the
benefits
of
schema
validation
directly
in
the
pipeline
editor,
so
in
14.2
we're
going
to
be
removing
that
requirement
of
the
connection
to
the
external
store,
storing
the
schema
directly
in
within
your
gitlab
instance
and
referencing
that
that
making
sure
it's
up
to
date.
This
is
all
in
an
effort
to
get
to
what
we're
really
excited
about
which
is
adding
autocomplete.
While
writing
your
gitlab
gmo
for
anyone
who's
written
pipeline
definitions
in
gitlab.
C
I
also
wanted
to
highlight
in
adoption
to
usability
that
you
know
we
found
a
number
of
users
of
our
pi
pi
package
registry,
we're
wanting
to
reference
pipe.org
for
any
packages
that
weren't
found
in
gitlab's
package
registry,
so
in
14.2
we're
going
to
be
adding
this
ability
to
retrieve
packages
from
pipi.org
that
aren't
found
in
gitlab's
registry
just
similar
to
functionality.
We've
added
for
other
registries
and
a
step
in
our
direction
to
have
your
gitlab
registries
kind
of
be
the
complete
proxy
for
any
public
or
other
private
registries
that
you
might
be
utilizing.
C
And,
lastly,
in
14.2,
I'm
excited
to
announce
that
I'm
actually
releasing
it's
available
on
gitlab.com
today,
but
we'll
be
releasing
it
in
14.1.
Here
in
just
three
short
days,
we
added
the
ability
for
you
to
use
a
tunnel
from
your
gitlab
kubernetes
agent
to
connect
to
your
registry
to
connect
to
your
kubernetes
clusters
while
performing
ci.
C
I
want
to
highlight
that
this
does
not
mean
that
other
features
that
utilize
the
agent
like
full
base
deployment
or
network
security
integrations
will
be
moved
to
core,
but
we're
really
excited
about
bringing
the
agent
and
the
ability
to
register
your
agent
core
and
the
ability
to
execute
jobs
over
the
tunnel
decor.
C
D
Kenny,
I
can't
wait
for
the
syntax,
the
inline
syntax
co-complete
in
the
editor.
I'm
super
excited
for
that.
But
let's
get
started
with
the
enablement
section
and
all
that
we
are
working
on
here
in
14.2.
D
Again,
we
have
similar
themes
here
as
above
and
let's
get
started
with
adoption
through
usability.
We
have
a
couple
items
in
this
category.
Working
on
the
first
one
is:
we
are
working
to
improve
the
performance
of
the
counts
aspect
of
global
search.
So
if
I
go
into
here
and
search
for
git
lab,
you
can
see
that
we
populate
a
number
of
accounts
and,
depending
on
your
search
in
your
project
and
whether
your
advanced
search
turned
on
or
not.
This
can
take
some
time,
and
so
you
can
actually
see
here.
D
Our
p95
is
actually
up
around
15
seconds
on
gitlab.com,
which
provides
a
poor
experience
for
all
those
users
affected,
and
so
we
are
working
to
improve
this
to
improve
the
overall
performance
and
give
you
your
results
faster
from
there.
We're
also
working
to
help
give
you
additional
tools
to
find
the
content.
You're,
looking
for
we've
been
adding
improved
options
to
sort
and
otherwise
filter
on
the
results,
and
in
this
release
we
are
working
to
add
the
ability
to
sort
by
popularity
here.
D
This
would
be
things
like
upvotes
and
likes
on
this
way.
If
you
have
a
common
search
term,
perhaps
like
design,
you
can
actually
then
use
that
to
help
to
cut
through
some
of
the
signal
and
noise
based
on
what
you're.
Looking
for
so
looking
forward
to
that
as
well
and
next
up,
we
are
continuing
our
work
on
the
ability
to
make
secondaries
completely
transparent
to
end
users
right
now.
D
If
you
are
working
with
a
company
who
have
a
deployment
of
git
lab
who
has
multiple
secondaries
of
their
github
instances
across
the
world
for
performance
improvements,
you
have
to
be
aware
of
that.
So,
as
a
user,
you
have
the
cognitive
load
of
knowing
that
there's
different
servers
out
there
and
you
happen
to
actually
select
the
one
that's
best
for
you
in
particular
for
the
web
ui,
and
so
we
want
to
make
this
completely
go
away
and
make
it
so.
D
The
end
user,
just
types
in
their
git
lab
url
and
the
right
thing
happens
for
the
user,
and
so
we're
doing
this
by
having
the
secondaries
capable
of
proxying
some
content
off
to
the
primary,
which
is
the
only
one
that
can
accept,
write
access
and
that
way
you
can
have
a
load
balancer
in
front.
The
user
gets
directed
to
the
right
instance.
The
rights
get
magically
transported
off
to
the
primary
and
to
the
end
user.
It's
like
magic
and
they
don't
even
need
to
be
aware.
The
secondaries
exist.
D
They
are
completely
taken
to
the
right
one
for
their
own
deployment,
which
is
great,
so
they'll
all
have
a
faster
experience
with
less
cognitive,
overhead
and
less
education
needing
to
be
rolled
out
to
them
from
there.
We
are
also
continuing
our
work
to
help
improve
the
process
of
promoting
a
secondary
to
a
primary
and
so
right
now
the
current
process
requires
pedestal
configuration
and
commands,
and
this
can
be
potentially
error-prone
if
the
human
is
doing
it
or
potentially
more
complex
automate.
D
If
you
were
automating
this,
and
so
we've
been
working
on
a
lot
of
improvements
here
to
help
improve
the
overall
process
of
promotion
and
emotion.
And
so
the
goal
here
in
this
particular
epic
is
to
have
a
single
command
to
promote
a
secondary,
two-way
primary
and
removing
all
the
need
for
the
edit
configuration
and
other
complexity.
So
we're
hoping
to
make
our
admins
lives
a
little
easier
with
this
particular
feature
from
there.
D
We
can
move
on
to
sas
first,
and
the
first
item
we
are
working
on
is
continuing
our
work
to
upgrade
git
lab
to
ruby,
3.0
ruby.
The
ruby
group
had
a
goal
of
having
ruby
fit
adobe
three
times
faster
than
ruby
turdo,
and
they
hit
that
on
some
metrics,
and
so
we
are
looking
to
take
advantage
of
that,
plus
all
the
new
great
things
in
ruby,
30,
and
that,
of
course,
just
means
work
for
us.
D
We
are
also
working
similarly
on
database
scalability
here
and
in
this
case,
with
migrating
our
primary
keys
to
a
larger
data
type
so
way
back
when
gitlab
got
started.
The
primary
key
for
ruby
default
was
an
inch
integer
and,
as
gitlab
has
grown
and
as
in
particular,
ci
has
exploded
in
popularity.
This
has
posed
some
challenges
and
we
are
at
risk
of
on.com
at
least
running
out
of
primary
index
space,
and
so
we've
been
going
through
and
moving
these
indexes
over
to
larger
data
types.
So
they
have
more
headroom
and
we
are
about
complete
here.
D
We
will
be
cutting
over
all
active
use
to
the
new
columns
with
the
new
data
types
in
14.2
and
then
the
next
step
after
that
would
be
to
simply
delete
the
old
columns
with
the
old
integer
and
that
would
complete
the
migration
for
many
of
our
tables.
So
we
are
well
in
advance
of
even.com
projected
cases,
and
so
we
are
doing
great
here,
but
it's
a
great
update
for
the
team
to
continue
to
close
this
one
out
from
there.
D
We
are
also
working
to
continue
to
again
scale
gitlab's
database,
and
in
this
case
we
are
doing
that
by
taking
all
of
our
ci
content
and
shifting
that
to
a
new
database
for
self-managed.
This
won't
introduce
extra
complexity,
but
for
people
who
need
it,
you
can
actually
then
optionally
have
that
secondary
ci
database
running
in
a
separate
database
infrastructure
and
give
you
significantly
more
headroom
in
case
you
are
in
danger
of
running
out
of
how
large
of
instances
you
can
potentially
vertically
scale
your
primary.
D
So
this
will
help
give
some
extra
headroom
for
folks
and
similarly
we're
also
working
to
help.
You
know
trim
our
overall
database
sizes
we're
doing
this
in
a
few
ways.
One
of
the
items
here
we'll
continue
working
on
14.2
is
adding
options
for
partitioning
and
then
pruning
database
tables,
where
you
really
don't
necessarily
want
to
keep
everything.
D
D
It
to
help
make
it
easier
for
folks
and
remove
one
kind
of
admin
action
that
they
have
to
go
through
and
do
last.
We
can
move
on
to
new
markets
here
and
our
ga
release
of
our
operator.
We've
been
working
this
for
a
number
of
months
and
we're
getting
very,
very
close.
There's
a
few
last
items
you
have
to
go
through
and
work
on.
The
first
one
is:
we
are
working
to
improve
the
installation,
experience
and
we've
landed
on
utilizing
customize
as
the
installation
experience
for
our
operator.
D
D
Also
customize
has
been
baked
into
coop
ctl
as
well,
and
so
it's
a
nice
lightweight
approach
that
still
provides
some
flexibility
for
deploying
the
operator
and
also,
if
you're,
familiar
with
deploying
operators,
you'll
see
a
number
of
other
ones,
also
taking
this
attack
for
the
installation
as
well.
So
we
are
so
excited
on
the
operator
again.
We
are
very
close.
We
also
bring
a
couple
other
things
around:
adding
some
qa
tests
and
also
adding
support
for
a
few
config
options
that
wasn't
quite
there
yet
for
things
like
external
redis
and
national
postgres.
A
Thank
you,
josh
wow.
I
heard
a
lot
of
amazing
things.
I
heard
enhancing
merge,
request,
usability
the
core
workflow
for
many
of
our
developers
and
other
team
members.
High
performance
gitly
cluster
for
demanding
users
that
continue
to
migrate
off
nfs,
better
jeera
integration
for
our
self-managed
users
group
level.
Settings
for
mre
approvals,
that'll
make
thousands
of
project
it'll,
make
it
so
easy
to
have
thousands
of
projects
be
compliant
instead
of
going
per
project,
on-demand
dash
scheduler
for
very
free
operations.
A
You
don't
have
to
remember
you
don't
about
running
the
on-demand
scan
dependency
scanning
going
to
complete
that's
amazing
scanning
running
containers
with
trivi.
That's
gonna
be
great
to
help
protect
your
production
environments,
security
policy,
orchestrations
again
to
make
it
easy
to
secure
the
product
that
you're
building
visibility
into
ci
usage,
extremely
important
as
more
and
more
customers
drive
more
and
more
ci
usage
to
make
their
products
better
and
faster
power.
9
runner
support
with
ibm
to
help
our
joint
customers.
A
I
also
heard
a
lot
of
amazing
scaling
work.
We
are
doing
as
larger
and
larger
enterprises
adopt
gitlab,
whether
it's
shifting
to
read
only
db,
whether
it's
shifting
read
only
db
load
to
replicas,
partitioning,
decomposing
or
db,
and
obviously
the
ga
of
the
operator
I'm
super
excited.
This
is
going
to
be
the
best
release
ever.
Thank
you
all
and
we'll
see
you
next
month.