►
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
B
So
I
think
that
the
biggest
one
is
we
guarantee
some
dates
on
which
we
will
do
releases,
but
the
pace
of
change
at
gitlab
is
growing
as
we
scale
up.
You
know
both
the
software
officing
offering
and
the
teams
and
we're
at
the
limit
of
what
the
current
process
will
sustain
in
terms
of
the
the
pace
of
change
and
there's
two
kind
of
sub-components
to
that
in
that
are
continuous.
B
You
know
on
an
ongoing
basis
and
one
idea
that's
been
posited
of
an
on-demand
release
because
of
the
environment
that
gitlab
works.
In
specifically,
being
public
by
default
may
not
be
kind
of
possible
or
sustainable
at
all,
versus
a
predictable
schedule
that
allows
us
to
do
stuff
and
kind
of
meet
demand.
A
Think
the
first,
the
first
thing
I'd
like
to
sort
of
get
straight
and
correct
me
if
I'm
wrong
the
way
we
release
changes,
they're,
essentially
two
two
streams
when
we
deploy
pretty
continuously
several
times
a
day
to
gitlab.com
our
SAS
platform,
and
that
means
a
feature
team
emergency
Mr
that
will
actually
get
you
know
into
production
on
our
SAS
service,
ideally
the
same
day
and
the
pipelines
that
do
this,
you
know
I,
think,
are
you
know
robust
enough
to
deliver
these
changes
on
a
more
or
less,
let's
say,
continuous
base.
I.
A
B
A
Of
course,
have
a
significant
self-managed
offering
where
we
now
need
to
package
these
these
changes
and
distinguish
between
you
know,
minor
releases
that
happen
once
a
month.
Security
releases
in
that
contain
security
fixes
during
that
month
and
Patch
releases,
which
fix
bugs
those
pipelines
that
you
refer
to
that
handle
those
processes
are
sort
of
at
the
limit
of
what
is
sustainable
at
this.
This
moment
is
that
right.
A
A
Yeah,
okay,
and
so
one
of
the
challenges
is
sort
of
the
increasing
that
pace,
which
is
happening,
which
means
more
automation.
You
know,
because
we
don't
want
to
hire
more
people
to
push
buttons
faster,
but
one
of
the
the
issues
that
I'm
aware
of
and
I'd
love
your
perspective
on
it
is
all
of
those
changes
are
being
made
available
to
our
customers.
A
You
know
either
as
deployments
on
github.com
or
as
releases
for
self-managed,
and
some
of
the
feedback
that
I've
received
is
that
it
is
hard
for
folks
to
understand
when,
like
what
is
being
deployed
and
if
it
is
relevant,
what
they
do
and
what
is
being
released
and
what
kind
of
changes
those
are
right
in
the
future
editions
which
are
simpler.
But
then,
with
major
releases,
we
have
breaking
changes.
B
Yeah
and
I
think
that
kind
of
leads
a
bit
into
the
the
second
call
it
thematic
problem
is
that
for
self-managed
and
those
releases
that
we
kind
of
publish-
and
we
have
a
number
of
strategies
like
the
change
log,
the
deprecations
page
removals
page
and
other
things
to
allow
us
to
communicate.
You
know,
what's
included
in
those
releases
and
what
might
break
and
what
our
plans
are
for
future
releases,
as
well
as
some
guidance
to
you
know
kind
of
help.
Customers
deal
with
that.
B
What
we
don't
have
is
something
that's
equivalent
and
has
you
know
product
Market
fit
for
the
the
SAS
users,
if
you're
a
SAS
user
right
now
you
can
look
at
the
breaking
change
pages
and
you
can
look
at
the
the
change
log,
but
that
doesn't
give
you
an
up-to-date
instruction
of
what
is
life.
What
features
are
live
in.com
and
we
don't
really
have
a
pathway
or
kind
of
mechanism
to
deliver
that
information
to
to
SAS
users
at
all.
A
B
Their
you
know,
ideal
state
was
as
an
admin
or
as
a
kind
of
user
of
the
platform
when
one
of
you
know
kind
of
their
internal
users
uses
a
deprecate
feature,
something
that's
broken,
where
you
could
send
a
notification
either
to
the
account
team
or
directly
to
the
user.
That
says
you
know
this
feature
is
duplicated.
There's
going
to
be
a
breaking
change,
you
know.
We've
detected
this
usage
somewhere
in
your
organization.
B
Can
you
you
know,
follow
up
which,
which
could
be
an
interesting
way
of
doing
that,
but
also
there
isn't
a
self-serve
option
right
now,
which
lets
customers
really
know
what
is
live
in
terms
of
both
features
and
breaking
changes,
and
it's
the
what's
newest
push
from
us.
We
decide
very
carefully
what
goes
into
the
what's
new
notification
and
that
may
not
be
as
transparent
as
kind
of
we
want
to
represent
ourselves.
I
think
yeah.
B
A
That's
something
we
want
to
make
people
aware
of,
ideally
in
the
context
where
they
can
do
something
about
it,
but
then
you
also
have
situations
where
we
push
out
something
that
we
believe
is
useful
and
has
more
of
a
marketing
component
to
it,
and
we
want
to
say
hey.
This
thing
is
now
available
to
you:
go
check
it
out
and
so
I
think
right
now,
the
that
doesn't
really
happen
as
much
in
a
understood
way.
A
I
think,
and
it
also
means
that
it's
kind
of
backwards,
where
customers
on
gitlab.com,
who
are
impacted
first,
don't
get
informed
first
in
the
same
way
as
self-managed
customers,
who
also
you
know,
have
to
still
upgrade
to
do
it.
Yeah
and
I
know
that
one
of
the
reasons
why
upgrading
sometimes
is
complicated
other
than
the
technical
reasons
for
upgrades,
maybe
being
hard,
is
also
because
you'll
want
to
understand.
A
B
B
And
I
think
the
the
other
thing
that
is
is
connected
there
with
the
the
SAS
users,
especially,
is
actually
how
we
release.
Those
changes
is
a
very
interesting
component
of
that,
because
our
our
SAS
users,
I
think
intentionally
or
unintentionally,
dog
food
with
us,
and
there
are
various
strategies
that
I
think
we
can
use
in
terms
of
kind
of
group
level,
feature
Flags
and
turning
it
on
for
just
git
lab
users.
First,
that
we
look
at
things
like
the
the
navigation
update.
B
We
do
really
well,
but
I,
don't
think
we
apply
those
uniformly
across
some
of
the
product
offerings.
We
do,
and
you
know
we
cause
incidents
for
the
platform,
but
also
kind
of
user
Interruption.
When
we
do
things
like
that
and
having
a
more
Universal
and
considered
approach
to
how
we
do
all
changes
that
could
potentially
be
disruptive-
and
not
just
you
know,
things
like
the
nav
that
we
know
are
going
to
have
serious
user
impact.
A
Think
that's
a
that's
a
great
call
out
and
ideally
I
think
you
know
there
are
various
strategies
that
you
can
consider
to
do
this,
but
I
think
you
said
that
before
this
is
a
decision
that
is
best
placed
with
the
groups
developing
those
features
you
know
if
they,
for
whatever
reason
want
to
maybe
roll
it
out
to
a
small
number
of
users,
first
right
in
a
gradual
fashion.
Right
if
they
are,
you
know
we
have
different
feature
States
from
experimental
to
Beta.
A
B
B
B
B
A
A
Then
another
another
question:
I
think
this
goes
into
some
some
things
that
you've
mentioned
before
so
on
SAS,
when
we
have
continuous
change,
I,
think
that
is
expected
and
it
is
upon
us
to
make
sure
that
that's
communicated
correctly,
which
is
something
that
we
should
improve,
but
then
for
self-managed
style
customers.
Yes,
you
know
every
update.
A
Every
new
release
requires
an
upgrade
to
that
release
for
our
customers
and
I.
Think
there's
an
interesting
question.
It's
like
how
many
releases
is
actually
acceptable
and
is
that
and
I
think
this
is
something
we
don't
know.
For
example,
there's
this
question
about
LTS
releases,
long-term,
stable
releases:
do
customers
ask
for
stable
releases
because
they
are
unable
to
understand
the
changes
that
are
being
made
and
have
trouble
upgrading.
A
So
if
those
components
would
go
away,
they'd
happily
upgrade
more
often
or
are
there
sometimes
also
business
reasons
where
they
just
cannot
actually
upgrade
certain
components
for
compliance,
reasons
or
policy
reasons
and
I
think
those
are
two
very
different
things,
because
if
that's
the
case,
you
can
do
the
best
communication
in
the
world
and
have
the
best
upgrade
process
in
the
world.
It
just
doesn't.
Actually
address
their
use
case.
B
Yeah
and
I
think
there's
the
to
touch
and
connect
that,
back
to
the
earlier
point
on
the
an
on-demand
release,
May
Never,
Be
feasible.
You
know
critical
security
releases
where
we've
got
to
patch
stuff
aside.
You
know
there
are.
There
are
some
operational
concerns
where
we
may
need
to,
but
on
the
point
of
view
of
a
I,
have
a
fix,
I
need
to
create
a
release
for
it
immediately.
B
You
know
a
lot
of
the
feedback
we
have
from
customers
is
that
they
don't
want
to
see.
You
know
gitlab
16.0.54,
it's
not
going
to
be.
You
know
a
sustainable
path
for
a
lot
of
the
customers
to
upgrade
on
a
daily
or
every
other
day
schedule,
and
we
have
a
little
bit
of
the
problem
of.
We
serve
some
very
different
segments
on
self-managed,
and
you
know:
single
user,
single
VM
installations
and
tens
of
thousands
large
air-gapped.
B
You
know
environments
and
they,
you
know,
operate
very
differently
on
very
different
schedules
and
it's
you
know
two
quarters
and
a
half
of
who
really
liked
lots
of
releases,
because
it
shows
we're
doing
lots
of
stuff
we're
fixing
security
issues,
and
you
know
the
other
half
I,
think
well.
Lots
of
security
releases
indicate
that
your
product
is
not
secure.
Why
haven't
you
made
it
secure
from
the
start?
Is
that
not
something
you
can
do
you
know?
B
So
we
need
to
find
a
happy
medium
in
terms
of
a
schedule
where
we're
able
to
release
things
to
users
on
a
schedule
that
they
can
work
to
for
those
users
who
want
to
upgrade
constantly
kind
of
through
the
month,
and
you
know
with
zero
downtime,
but
also
to
enable
The
increased
demand
for
change.
We
have,
with
the
feature
velocity
and
with
both
fed
ramp,
enablement
and
transparently.
The
rapid
nature
with
it
with
which
you
know,
cves
are
becoming
discovered
and
proliferated
as
that
market.
B
You
know
the
job
market
and
the
market
for
vulnerabilities
expense,
I,
don't
see
in
the
future
that
will
decrease
in
terms
of
demand.
So
we
need
to
find
a
balance
between
doing
that
and
I
think
that's
an
important
Next
Step,
which
will
allow
us
to
create
a
predictable
cycle
for
the
delivery
group
and
for
our
customers,
but
tangentially
to
that
there
is
kind
of
a
long-term
support.
Question
wherefore
a
certain
segment
of
customers.
B
Long-Term
support
is
never
a
question.
It's
always
budgeted
for
in
platform
acquisition
and
other
things
like
that
and
the
nature
of
the
environment
and
the
schedule
on
which
they
run
a
lot
of
those
processes
in
their
portfolio
and
program
management
usually
dictates
that
on
a
checklist
of
there
is
some
kind
of
long-term
support.
I,
don't
know
if
you
are
familiar
with
kind
of
set
lumira,
but
lumira
are
on
the
third
extension
of
their
long-term
support,
which
was
originally
10
for
2022
and
is
now
2030..
B
A
B
So
I
think
the
two
most
important
things
to
address
are
the
communication
broadening
of
marketing,
both
internally
and
externally,
to
SAS
customers
in
particular
about
how
we
release
and
well
sorry.
I
should
be
careful
with
the
language
there
how
we
deploy
changes
to
gitlab.com
on
a
regular
basis
and
get
that
present
of
mind.
You
know
not
only
in
the
customers
who
sometimes
believe
they're
on
not
a
rolling
update,
even
though
they're.com
customers,
but
also
in
our
product
managers,
our
Engineers
and
you
know
other
team
members.
A
B
A
B
A
You
know
that
were
made
available
yeah
on
the
day
they
were
made
available
or
you
know
to
be
able
to
say
hey.
Those
are
all
of
the
deprecated
features,
and
this
is
how
I
am
impacted,
and
this
is
what
I
need
to
do
right
now.
I
think
that's
yeah,
that's
a
far
in
the
future
and
then
the
second
thing
well.
B
The
the
second
component
of
that
is
the
the
change
log.
The
first
thing
that
needs
to
be
addressed.
There
is
actually
having
a
mechanism
to
tell
users.
What's
in
the
platform
we
don't
at
all,
and
we
should
start
with
something
that
is
basic
and
probably
reuses
one
of
the
things
we
already
have,
which
is
the
change
log,
but
have
that
on
a
rolling
per
deployment
basis
and
to
make
that
consumable
for
customers,
because
a
lot
of
people
already
use
the
change
log.
B
The
second
thing
is
getting
the
release:
schedule
kind
of
locked
down,
it's
something
that
that
Marion's
put
together
an
issue
for
and
got
some
alignment
from,
I
think
it
is
something
that
will
meter
the
increasing
operational
concerns
of
the
team
and
allow
us
to
be
more
deliberate
about
some
of
the
operational
activities
that
the
team
performs
and
gives
some
predictability
to
engineering.
You
know
customer
success,
support
on
how
and
when
we
do
these
things-
and
you
know
what
is
is
reasonable.
B
A
That's
always
the
case,
but
it
would
make
it
a
lot
clearer
like
when
we
expect
things
to
happen.
I
think
it
may
also
make
it
significantly
clearer
internally.
You
know
when
fruits
need
to
be
merged
in
order
to
make
it
I
think
that
is,
you
know,
I
think
that's,
maybe
a
little
bit
too
much
in
the
weeds,
but
I
think
the
hard
due
dates
are
sometimes
easier
to
remember.
Yeah.
B
Significant
amount
of
the
toil
in
that
process
is,
is
bundling
and
well.
We've
got
two
fixes
in
there,
but
there's
probably
one
coming
in.
You
know
three
days
or
two
days.
If
it
makes
it
quick,
should
I
do
the
patch
release
now
or
should
I
wait
and
you
know,
can
I
get
alignment
well
if
it's
on
a
fixed
schedule,
it's
really
easy
to
say
if
you
get
it
in
by
this
date,
we'll
get
it
out
if
not
seven
day
wait.
It
sounds
like
ages
when
it's
seven
days
away,
but
poor
sales.
B
Yeah
deployments
you
merge
to
master
and
it
should
be
I
think
the
mttp
right
now
is
just
under
seven
hours.
You
know.
So
if
you
merge
Monday
to
Thursday,
it's
probably
gonna
get
right
in
Friday
morning,
UTC
it'll
probably
be
in
and
we
hold
deployments
obviously
over
there
the
weekend.
So
everyone
can
rest
yeah.