►
From YouTube: 2023-06-14 AMA about GitLab releases
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
B
A
Now
pass
out
a
bit
of
feedback
Central
pretty
much
all
here
so
earlier.
Today,
I
was
in
the
infra
quality
kind
of
managers,
meeting
I'm,
not
sure
exactly
what's
called,
but
all
the
managers
across
the
department
and
yeah
huge,
huge
Kudos
to
all
of
you
for
for
continuing
the
consistency
of
these
amas
I.
Think
was
the
thing
that
Max
said
is
the
the
most
impressive
thing
about
you
know
our
amas,
so
great
work,
I,
don't
think!
We've
missed
one
of
these
for
many
years
I
remember.
A
We
had
a
period
where
we
did
cancel
a
few,
but
that
was
a
really
long
time
ago,
like
pre-pre-pre-roll
box,
so
huge
huge
credential
for
those.
A
His
arm
hey
bud,
we
are
actually
at
time.
Has
anyone
actually
got
anything
they
wanted
to
discuss
or
or
ask
questions
about,
because
back
in
the
day,
this
meeting
was
actually
delivery
office
hours,
and
then
we
just
made
it
public
in
case
other
people
wanted
to
come
and
chat
to
us,
so
it
doesn't
actually
have
to
be
external
questions
like
is
there
anything
inside
delivery
that
people
want
to
shout
about?
Ask
about,
or
just
generally
talk
about.
A
C
C
So
onboarding
is
fun
right
on
boarding
into
delivery.
It's
very
fun,
as
as
part
of
that
I've
learned
a
lot
from
you
all
and
I'm
still
kind
of
mentally
trying
to
untangle
yeah
deployment,
release
security
release
patches
and
how
all
of
those
things
interact
together
and
then
all
the
other
teams
that
we
have
kind
of
shelved
responsibilities
with
and
share.
You
know
the
end-to-end
process
with
being
distribution,
quality
like
infrastructure
and
sres.
C
You
know
if
there's
incidents,
it's
been
quite
fun
to
to
pick
through,
so
I
had
to
go
at
creating
a
process
diagram
which
I'm
sure
you
can
all
agree
is
a
fantastic
and
kind
of
fun
educational
use
of
time,
but
really
one
of
the
the
questions
I
had
with
a
deployment
and
release
process
that
spans
so
much
of
the
organization
infrastructure,
not
infrastructure.
You
know
not
even
anything
to
do
with
kind
of
engineering,
particularly
in
some
places.
How
do
we
start
to
kind
of
get
an
idea
of
what
actually
happens?
C
What
are
the
steps
and
where
those
steps
are
kind
of
owned
and
bring
those
teams
together
to
say,
let's
pick
a
box
and,
for
example,
that
packaging
is
in
trouble,
and
you
know
something's
going
wrong
on
a
regular
basis
who
gets
involved
in
packaging?
C
Can
we
together
for
a
quarter
for
a
milestone,
work
on
this
box
and
improve
it
and
and
make
it
better,
rather
than
trying
to
kind
of
attack
and
ingest
the
the
whole
process
at
once,
because
I
think
where
we
are,
is
kind
of
in
this
vertical
slice
of
not
automation
but
kind
of
the
release
manager,
tasks
that
have
to
be
done
on
a
regular
basis?
And
whilst
it's
nice
to
have
a
view
of
the
the
whole
map
the
bit
that
we
can
really
get
on
board,
control
and
and
kind
of
change
as
delivery?
C
Is
this
vertical
slice
and
the
same
is
true:
I
guess
of
quality
of
distribution
or
have
their
own
vertical
slice?
You
know
that
we
all
need
to
come
together
and
collaborate
on
so
one
of
the
questions
I
had
was.
Does
this
seem
like
a
good
idea
to
get
everyone
on
the
same
page
and
how
do
we
want
to
kind
of
contribute
to
and
map
this
out
in
a
way
that
makes
sense.
C
So
we
can
start
looking
at
those
individual
boxes.
Do
they
make
sense
in
our
process?
Can
we
get
rid
of
them
evolve
them,
and
can
we
do
better
kind
of
thing?
Is
that
a
reasonably
level
explanation.
A
Pretty
good
yeah,
yeah
I
think
it's
a
great
question.
Like
so
I
mean
I,
guess
we
have
got
some
people,
so
maybe
this
is
like
a
kind
of
twofold
question
so
for
people
inside
the
team
does
this
feel
like
a
useful
activity
and
we've
got
a
couple
of
people
outside
the
team
who
might
have
perspectives
from
like
as
someone
who's,
not
in
delivery?
What's
actually
useful
to
to
know.
A
Drop
it
in,
for
you
I
think
for
Myra.
Don't
worry
too
much
about
like
I,
think
think
about
this
more
of
the
concept
level
of
like.
Would
it
be
useful
for
us
to
have
something
of
of
this
site
style,
especially
with
the
effort
that
we'll
probably
go
into
creating
it
or
other
other
things?
That
would
be
useful,
yeah.
C
And
I'll
drop
out
of
sharing,
because
the
the
focus
is
definitely
not
completely
on
the
diagram,
but
would
a
visual
that
we
can
all
kind
of
get
around
and
align
on
start
to
make
sense
to
to
bring
some
of
the
teams
to
the
table
where
we
have
yeah
multi-ownership
things
that
we
need
to
kind
of
coordinate
and
get
mine
done.
B
C
D
It
is
enormous,
but
it
represents
like
the
big
picture
of
our
processes
and
the
deployments
and
yeah
I
think
it
would
be
a
good
idea
for
especially
for
people
that
are
on
boarding,
because,
right
now
our
boarding
is
not
the
best.
We
just
throw
people
at
a
bunch
of
documentation
and
you
know
try
to
wish
them
the
best
of
luck,
but
they
are
having
some
sort
of
visual
that
puts
all
together.
I
think
it
would
be
useful.
D
We
do
have
a
couple
of
maps
that
were
created
by
another
team
member,
but
they
are
also
a
bit
convoluted.
So
I
think
this
one
looks
better
so
yeah.
C
Yeah,
there's
there's
crazy
nuances
as
well
for
anyone
in
the
call
it's
not
super
familiar
with
the
release,
process
and
deployment
kind
of
process.
In
that
you
know,
releases
are
sort
of
their
own
separate
thing
except
security
releases
because
normally
with
a
patch
or
you
know
the
monthly
release
version
something
already
has
to
be
in
gitlab.com,
then
it's
packaged
put
into
you
know
a
tagged
version
number
right,
but
with
security
fixes
they
have
to
go.
C
You
know,
through
the
security
mirror
into
gitlab.com
and
then
be
patched
into
a
version,
so
they
almost
happen
in
reverse
order
to
what
we
expect
from
our
other
patch
release,
processes
and
I.
Don't
think
that
process
dependency
is
is
particularly
well
captured
across
the
different
departments,
either.
A
As
a
follow-up
question
Sam,
how
was
your
onboarding
into
delivery
like
what
what
what
would
in
the
Magic
World
of
the
future?
What
should
we
do
to
onboarding.
C
I
think
it
was
the
level
of
detail
that
we've
got
in
some
of
the
repositories
and
other
stuff
is,
is
really
cool
and
especially
how
the
documentation
is
broken
down
into
you
know:
user
groups
if
you're
a
lease
manager.
This
is
the
one.
If
you're
an
engineer,
this
is
the
one
if
you're
consuming
on
a
different
level.
This
is
the
one,
but
due
to
how
gitlab's
search
function
Works
it's
kind
of
quite
hard
to
discover
some
of
that
that
it
exists.
C
If
you
don't
know
it
exists
and
then
searching
through
the
repositories
is,
is
quite
challenging.
C
So
I
think
we
could
do
more
to
make
that
a
bit
easier,
but
I
think
that's
that's
sort
of
an
overall
gitlab
challenge
as
well
is
how
do
you
make
stuff
that
isn't
in
the
handbook
and
on
a
specific
algolia
index,
you
know
discoverable
and
searchable,
and
the
the
other
things
are
the
the
nuances
of
dog
fooding
and
then
the
pragmatisms
and
realities
of
we
have
to
have.
You
know
ops.gitlab.net,
because
we
can't
deploy
gitlab
with
gitlab,
because
there'd
be
a
point
where
it
doesn't
work
right.
C
But
then
you
know
kind
of
there's.
Also,
a
secret
kind
of
a
third
build
server
where
we
do
the
builds,
which
is
another
component
of
that
which
is
I,
think
kind
of
hidden
away,
because
it's
it's
very
much
part
of
what
delivery
need
to
operate
and
do
the
release
and
deployment
kind
of
processes.
C
But
it's
sort
of
not
owned
by
delivery.
So
it
ends
up
as
almost
an
invisible
piece
that
you
learn
about
through
osmosis
but
is
not
openly
documented
kind
of
anywhere.
C
You
know
and
I
think
there's
a
a
few
things
like
that,
where
the
lines
blur
cross
group,
Cross
organization
and
those
bits
are
very
hard
to
discover,
but
the
within
the
vertical
slice,
I
think
everything
is
very
well
documented
and
thorough.
If
you
go
through
it
and
there's
just
a
lot,
because
it's
a
complex
process
right
foreign.
A
A
If
not
I'm,
really
sorry
Sam
I
asked
you
another
question,
this
one's
a
little
bit
generic,
but
you
may
know
an
answer
for
this
one,
but
it's
something.
I
was
curious,
but
I
saw
the
announcement
recently
about
the
distinction
between
dog,
fooding
and
llama
feeding
and
I
was
actually
not
necessarily
always
like.
Not
attempting
to
always
make
the
product
do
absolutely
everything,
because
we
may
not
actually
be
the
intended
user.
A
A
Think
it's
reasonably
rare
that
you
would
want
to
be
running
continuous
deployment
Approach
at
the
same
time
as
having
like
a
monthly
package
release,
and
some
of
our
complexity
comes
from
the
two,
but
I
was
curious
like
or
anyone,
but
maybe
some
from
a
kind
of
product
perspective
like
do
we
have
any
kind
of
sense
of
like
you
know.
Where
does
delivery
sit
in
terms
of
that
dog
fooding
versus
llama
fooding
category.
C
Cool
I'll
go
I,
think
there's
there's
two
things
that
are
a
part
of
that
kind
of
llama
fooding
discussion
as
well
of
the
we
put
out
a
feature
or
a
product
that
we
expect.
You
know
users
to
consume
it
in
one
way
and
I.
Think
the
CI
stuff
is
is
a
really
good
example
that
I'll
try
and
get
a
link
to,
but
Lyle
in
support
kind
of
talked
about
how,
instead
of
using
the
CI,
you
know
workers
and
jobs
to
do
any
CI
stuff.
C
They
use
cron
jobs
to
just
kick
off
a
whole
bunch
of
process
and
project
Automation
and
they're
using
RCI
Platformers,
something
not
unlike
a
zapier,
and
actually
a
lot
of
customers
probably
have
that
need
as
well.
So
where
we've
adopted
and
kind
of
forced,
weird
work
processes
in
it
could
be
fun
to
see.
Actually
if
customers
have
some
of
the
same
needs
as
well
and
I
think
the
that
with
us
there
are
some
practicalities
around
dog
fooding.
C
If
we
look
at
environments
as
an
example,
it's
going
to
be
challenging
for
us
to
use
some
of
the
proposed
features
because
of
how
we
have
to
run.
You
know
our
deployments,
our
environments
off
of
ops.gitlab.net,
and
we
can
never
really
run
them
off
of
the
you
know.
Gitlab.Com
servers,
I,
don't
think,
there's
a
good
answer
on
how
we
do
some
of
those
things.
I
think.
Sometimes
our
product
approach
to
customer
facing
only
can
hurt
us
a
little
in
adopting
some
of
the
tools
that
our
feature
teams
create
there.
C
But
one
of
the
things
that's
that's
on
my
agenda
massively
is
is
how
do
we
kind
of
create
some
space
to
engage
with
other
teams
and
share
a
bit
of
what
you
know
we're
doing
and
seeing
if
there's
anything,
we
can
really
consume
and
use,
or
we
can
share
out
right
to
other
stage
teams.
C
A
Song
Nels:
do
you
want
to
verbalize.
C
It
was
I
think
it
was
in
a
what's
happening
at
gitlab
thread
and
it
was
Lyle
specifically,
but
he
used
a
phrase
or
use
the
phrase
llama
fooding
to
describe
when
we
had
radically
diverged
from
what
the
expected
use
case
was,
and
the
dog
fooding
was
the
expectation
that
you
know
you
will
use
it.
You
will
use
it
this
way
that
we
have
pre-ordained,
because
this
is
the
use
case
we
found.
C
You
know
ourselves
in
a
number
of
situations,
doing
nothing
even
remotely
similar
to
the
you
know
validated
problem,
but
still
getting
some
value
out
of
how
we
were
using
it,
even
if,
in
kind
of
a
an
edge
case
way.
A
Tried
searching,
there's
no
results
come
up,
so
I
can't
help
you
now
so
I,
don't
know
where
the
link
is,
but
I
will
we'll
try
and
find
it
for
you.
You.
C
It
was
in
what's
happening
in
gitlab,
I,
think
I.
E
Think
it
was
referring
to
something
that
a
customer
told
him
when
he
was
explaining
some,
because
if
I
remember,
because
I
remember,
I,
really
I've
read
this
conversation
as
well,
but
I
can't
remember
where
basically
was
something
about
support
using
scheduled
pipeline
to
generate
calendar
availability,
calendar
and
issues.
Something
like
this,
some
sort
of
a
table
with
who
is
available
for
support
when
and
it
was
showing
this
to
a
customer
just
say
wait.
E
A
B
F
Document
it
because
I
I
didn't
open
the
dock,
but
just
related
to
what
he
was
just
talking
about
so
I
work
with
very
large
organizations
in
Silicon,
Valley
and
their
I
know
that
it's
a
lot
easier
for
me
to
say
than
than
it
is
to
do.
But
you
know
I
could
really
Envision
documenting
some
of
these
different.
F
You
know
some
of
these
llama
fooding
examples
and
what
you
do
or
how
we
do
things
I
could
see
that
as
very
beneficial
in
providing
to
some
of
the
larger
organizations
I
work
with
because
gitlab
overall,
you
know
if
you,
if
you
look
at
if
I
want
a
cookie
cutter,
follow,
get
lab
flow
and
you
know
the
auto
devops
and
everything
as
long
as
I'm
doing
a
cute
little
web
page,
it
works
beautiful,
but
as
soon
as
I
start
getting
into
a
real
robust
solution,
embedded
software-
or
you
know
something
that's
going
to
impact
tens
of
thousands
of
users,
then
it's
different
right
and
I'm
constantly
having
to
work
with
large
orgs
on
well,
let's,
let's
work
outside
the
box
and
let's
create
this
weird
thing:
to
use
gitlab
to
solve
your
problem
and
they're
constantly
asking
for
that
kind
of
thing,
and
so
and
they're
constantly
asking
for
documentation.
F
So,
like
I,
said,
I
totally
respect
it's
easier
to
say
than
to
do,
but
I
could
absolutely
see
this
sort
of
process
being
documented,
or
this
sort
of
use
case
being
documented
in
some
way
beneficial
to
the
larger
organizations.
F
C
I'd
agree:
the
customers
I've
spoke
with
have
definitely
building
their
platform
on
top
of
our
platform
and
doing
the
kind
of
convoluted
stuff.
That
may
may
be
helpful
for
us
to
share
that
we're
doing
too.
A
A
G
Was
just
gonna
add
kind
of
a
plus
one
to
documenting
those
weird
use
cases,
because
we
have
seen
in
certain
areas
like
I
know.
Specifically,
the
package
registry
was
discovered
at
one
point
like:
oh
you
can.
You
can
store
packages
in
this
weird
way
that
we
didn't
realize
we
even
allowed-
and
we
recorded
a
video
of
that-
put
it
in
the
docs
just
in
case
and
then
that's
become
actually
the
way
that
is
now
recommended
to
use
the
package
registry
so
I
think
it's
always
beneficial
to
document
anything
that
can
be
a.
B
Use
case
so
honestly,
sorry
to
talk
without
having
put
a
an
agenda
point
in
here,
but
it
the
dog,
fooding
aspect
of
the
gitlab
product
is
always
fascinated
to
me
and
I.
Think
it's
pretty
unique.
Do
we
have
any?
Are
there
any
other
examples
of
companies
that
produce
a
product
where
they
do
this
kind
of
thing.
C
Interestingness,
like
is
highlights
it
particularly
because
you
can
really
see
it,
and
there
are,
you
know,
like
our
competitors,
harness
talk
about
how
much
they
dog
food,
but
with
gitlab
everything
is
transparent
and
you
can
see
it
happening
in
in
real
time.
Right.
A
Yeah
I
think
it's
definitely
interesting.
It's
been
interesting
over
the
last
few
years
in
delivery.
It'll
be
interesting
to
see
where
we
can
go
in
the
next
few
years,
but
you
know
seeing
some
of
the
features
coming
in
that
we've
been
able
to
adopt,
like
you
know,
I
think
the
parent
child
pipelines
and
triggering
those
child
pipe.
Fines
was
like
you
know,
massive
help
for
us
and
then,
like
we've,
had
some
things
that
we've
been
able
to
contribute
back
into
the
product
but
yeah.
A
It
still
feels
like
we're
a
little
bit
away
from
where
we
like,
ideally,
would
like
to
be
in
terms
of
just
the
sheer
number
of
features
we
have
available.
A
No
okay,
in
which
case
before
I,
let
your
head
off
so
I,
updated
the
Links
at
the
very
top
of
this
agenda,
just
to
add
in
a
fourth
link,
which
is
the
delivery
group
like
in
progress
and
planned
work.
So
we
have
a
single
epic,
which
is
the
sort
of
like
Landing
point
for
absolutely
everything
going
on
in
delivery.
So
all
of
our
ongoing
epics
are
linked
there
and
they
are
automatically
being
updated
each
day.
So
you
always
have
the
latest
like
we
do
a
weekly
status,
but
that
pulls
through
each
day.
A
So
you
always
have
like
the
latest
information
about
epics
and
then
we
also
are
building
up
like
what
is
coming
up
next
for
us.
What
work
are
we
currently
trying
to
like
scope
out
and
what
do
we
just
sort
of
have
in
our
like
project
backlog?
So,
if
you're
curious
about
anything,
that's
ongoing
feel
free
to
take
a
look
through
there
and
yeah
give
us
a
ping
if
you
have
questions
or
drop
by
our
Channel,
which
is
GE,
underscore
delivery
and
ask
us
questions
great.
Thank
you.
A
Everyone
for
joining
thanks
for
all
the
discussions.
Great
to
see
you
all
and
I
hope
you
have
a
great
rest
of
your
day.