►
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
I
am
really
excited
today
to
share
with
you
kind
of
the
story
of
the
container
registries,
retention
and
exploration
policy.
It's
a
feature
we
just
rolled
out
and
we're
really
excited
about
it
and
a
is
great
by
itself,
and
it's
also
a
really
cool
experience
of
how
product
management
and
product
design
can
work
together
and
utilize
research
to
find
solutions.
Even
when
there
is
a
lot
of
user
interface
involved,
which
is
kind
of
where
you
X
tends
to
slow.
So
I'm
really
excited
to
share
that
story
with
everyone.
A
Quick
backgrounds,
the
packaged
stage
can
be
currently
are
part
of
CI
CD
and
our
focus
is
taking
bundled
up
versions
of
code,
whether
that
be
a
package
or
an
image
or
a
couple
of
other
options,
storing
them
and
then
getting
them
ready
for
whenever
they
need
to
be
released.
Whether
that's
you
know
pulled
in
by
a
pipeline
or
put
out
to
production
or
anything
like
that.
A
Tim
Rizzy
is
the
product
manager
and
we
work
together
a
lot
on
this,
as
well
as
Laurie
on
the
research
side
of
things.
So
there
was
quite
a
few
of
us
involved
in
getting
this
done.
I'm
really
excited
so
the
initiative
goals
split
into
two
things:
we
have
a
business
goal:
user
goal
the
business
goal.
A
We
also
want
to
make
sure
that
we're
removing
unneeded
images
we're
keeping
it
organized
and
clean
so
that
the
experience
of
using
the
registry
is
nice
and
smooth.
So
we
had
two
different
goals
there,
which
aligned
really
nicely
a
history
of
this
initiative.
The
docker
container
registry
fvc
came
out
for
gitlab
about
three
years
ago.
A
The
scalability
of
deleting
the
images,
the
backend
structure.
Just
wasn't
there
as
well,
is
not
a
solid
understanding
of
what
users
and
other
companies
actually
want
to
see
in
terms
of
what
rules
they
use
to
delete,
all
the
images,
and
so
we
took
this
initiative
and
Tim
and
I
decided
rake
it
down
as
we
started
growing
the
team.
The
two
technical
limitations
that
we
kind
of
have
to
pay
attention
to
is
that
revolve
around
the
container
registry,
which
is
outside
of
the
rails
environment.
A
A
lot
of
us
work
in
there
were
two
main
points
that
were
causing
some
problems.
One
is
that
the
api's
themselves,
built
into
the
container
registry,
were
a
little
inefficient
and
turned
out
to
be
unstable,
as
the
registry
started
getting
kind
of
large,
and
so
the
results
in
calls
being
timed
out
or
things
failing
and
some
things
being
half
deleted
and
then
half
saved,
which
isn't
a
good
solution
for
everyone.
A
The
other
half
of
the
technical
problem
we
were
running
into
is
the
garbage
collection
for
the
container
registry
requires
for
it
to
go
into
read-only
mode
and
for
a
lot
of
our
customers.
This
would
take
two
or
three
days
for
them
to
actually
go
through
the
process
of
removing
all
of
the
extra
blobs
since
clearing
the
storage,
officially
leading
to
them
not
being
able
to
work
for
two
or
three
days
which
isn't
really
an
option
for
a
lot
of
users,
of
course,
because
we
are
user
experience
designers.
A
The
first
thing
we
did
was
research
with
our
users,
which
is
my
favorite
thing
to
do.
We
started
with
qualitative
data,
so
we
did
some
in-person
interviews.
Tim
and
I
decided
to
split
this
up
a
little
differently.
We
worked
on
the
discussion
guide
together
and
then
he
went
and
did
the
actual
interviewing
we're
in
different
time
zones.
So
when
he
was
done,
I
took
the
recording
and
I
was
kind
of
in
charge
of
synthesizing
the
results.
A
So
we
both
got
that
kind
of
first-person
view
as
to
what
this
data
meant
and
how
it
could
come
together
if
I
felt,
got7
unique
insights
as
well
as
kind
of
a
full
understanding
of
what
the
retention
and
expiration
policies
and
want
are
for
our
users
across
the
board,
not
just
get
lab
calm,
but
on
prime
solutions
and
stuff,
like
that,
we
also
did
a
quantitative
survey
which
we
sent
out
to
a
lot
of
people
if
you
notice,
if
you're,
paying,
really
close
attention.
This
is
the
same
survey.
A
I
mentioned
last
time
about
package
details
we
baked
into
this
survey
where,
if
you
responded
saying
yes,
I
use
the
container
registry,
we
asked
a
couple
of
additional
questions
to
understand.
Really
how
many
images
does
your
team
create
and
how?
Many
of
them
do
you
actually
end
up
using
as
well
as
how
do
you
generate
those
different
tags?
Do
you
manually
build
it
on
your
desktop
and
upload
it
from
the
command
line,
or
does
your
pipeline
build
a
lot
of
your
images
for
you?
A
We
came
back
with
a
validated
problem
which
felt
really
good,
because
a
lot
of
the
conversations
were
stalling
out
because
they
didn't
quite
fully
have
the
view
of
what
our
users
were
thinking.
It
kind
of
boiled
down
to
three
points.
The
storage
cost
was
frequently
the
number
one
reason.
Customers
were
frustrated
with
this.
A
The
we
confirmed
that
users
create
a
lot
of
images
through
the
pipeline,
so
you
can
run
a
commit
that
commits
generates
one
image:
that's
used
to
build
another
image
which
is
then
used
for
testing,
and
then
it's
all
added
to
the
registry
and
never
used
again.
So
that's
kind
of
adding
a
lot
of
cost
for
no
gain
for
the
the
organization,
and
we
really
could
confirm
there
without
the
introduction
of
a
better
tool.
There
really
isn't
a
good
way
to
solve.
This
I
had
to
laugh
really
hard.
I.
A
Think
every
presentation
needs
a
comic
or
a
gift
for
me
or
something
fun,
but
this
one
with
the
dog
and
saying
everything
is
fine.
While
the
house
is
on
fire
was
actually
one
of
our
users
said.
This
is
what
I
feel
like
I
know:
I
need
to
solve
the
problem
and
it's
you
know
continually
growing
as
a
problem,
but
I
can't
do
anything
about
it
right
now.
A
We
also
learned
some
more
specific
things,
but
in
terms
of
scale,
one
of
the
notes
that
was
important
for
us
is
that
some
of
our
users
were
reporting
that
their
registries
were
50
terabytes.
So
that's
about
a
hundred
different
laptops
all
combined
together
and
then
we
took
a
look
at
get
labs
container
registry,
which
is
currently
at
3.5
petabytes,
which
is
insane
and
almost
seven
thousand
laptops
full
of
data
that
a
lot
of
it
isn't
getting
used
for
our
users.
A
What
we
did
from
there
is
we
designed
an
iterative
solution.
We
recognized
out
of
the
gate
there.
There
wasn't
weight
for
us
to
feasibly
wait
until
we
could
solve
all
the
problems
and
then
move
forward
wasn't
going
to
be
good
for
us.
It
wasn't
going
to
be
good
for
our
users,
so
we
decided
to
try
to
solve
all
for
the
solution
as
best
we
could
now
and
then
create
a
plan
moving
forward,
but
you
know
the
gitlab
iteration
value.
A
A
One
of
the
great
things
that
happened
is
because
we
had
all
this
data
and
this
knowledge
and
this
understanding
it
only
took
us
a
couple
of
hours
to
really
work
it
out,
which
kind
of
shows
you
the
value
of
what
happens
when
you
have
all
the
data
you
need
and
actually
ask
your
users
and
gather
that
information
which
felt
good
as
a
designer
I
think
we
sat
down
in
the
room
and
just
kind
of
worked
our
way
through
five
or
four
major
areas,
one.
What
was
the
dream
state?
A
What
do
we
want
this
to
be
in
five
years
when
everything
Auto
magically
works?
That
was
basically
a
idea
of
if
I'm
not
going
to
use
a
tag
again
we're
going
to
remove
it
from
the
repository
we
went
through
a
couple
of
more
questions.
We
reviewed
all
the
data
we
had
in
terms
of
it
labs
impact
and
an
on-prem
solution
and
stuff
like
that,
as
well
as
working
with
Steve,
to
really
understand
the
nuance
of
those
technical
limitations,
and
then
we
sat
down
and
asked
the
real
question.
A
What
is
a
realistic
change
that
we
can
make
that
now
that
will
slow
down
the
growth
of
this
seemingly
exponential
problem?
Does
not
only
does
it
grow
over
time,
as
you
start
building
more
images
per
team,
but
then,
as
you
start,
building
out
more
projects
that
are
using
this,
the
bigger
and
bigger
the
problem
becomes.
A
The
first
iteration
was
just
released,
which
I
mentioned
earlier,
and
I'm
really
excited
about.
We
delivered
for
all
project,
starting
in
twelve,
eight
moving
forward,
so
they
had
very
few
images
to
start.
So
we
don't
have
to
worry
about
the
API,
a
set
of
default
policies
that
protected
our
users
that
don't
heavily
utilize
a
lot
of
images,
so
they
only
upload
three
or
four
and
they
need
to
stay
there
for
six
months.
A
For
example,
we
created
a
bunch
of
policies
to
protect
them,
while
also
making
sure
that
no
one
registry
can
kind
of
grow
to
scale
the
policies
are
at
the
project
level.
That
was
a
determination
we
made
just
based
on
the
information
we
had
heard
from
all
of
our
users
they're
a
little
different
every
time.
So
that's
where
we
started
there
is
a
plan
to
kind
of
expand
outside
of
that
and
I
went
out
of
order.
So
those
are
the
three
points
right
now.
A
If
you
open
into
a
new
project-
and
you
go
to
this
PID
fee-
see
ICD
settings
section,
there's
a
place,
you
can
go
and
turn
on
the
exploration
policy,
which
is
really
exciting.
When
you
start
to
think
about
how
involved
the
problem
is,
when
we
first
release
it,
we
kind
of
got
two
reactions
from
our
users.
A
A
lot
of
them
started
out
a
little
frustrated
and,
to
be
honest,
Tim
and
I
kind
of
expected
that
we
were
releasing
a
new
project
or
a
new
feature
that
would
solve
a
problem
for
a
lot
of
existing
projects
and
customers,
and
then
we
didn't
allow
them
to
use
it
so
understandable
frustration,
Tim
did
an
incredible
job
dove
into
the
issues
where
they
started.
Commenting
and
saying
this
is
our
plan.
This
is
why
we
did
it
this
way.
You
know
stay
in
contact
and
stuff
like
that,
and
their
view
of
the
situation
really
evolves.
A
This
user
suddenly
became
excited
to
participate
with
us
too.
They
volunteered
to
do
interviews
to
do
testing
for
us.
Ask
questions
stuff
like
that,
and
some
of
them
even
called
out
that
the
open
source
value
is
really
exemplified
here
and
how
gitlab
works
really
shining
through,
and
so
they
were
excited
to
work
with
us,
instead
of
just
being
frustrated,
which
is
where
they
started.
A
Next
up
some
iterations,
we
have
three
main
areas:
we're
going
to
continue
to
improve
the
registry
API
performance.
This
will
allow
us
just
to
scale
out
to
bigger
and
bigger
projects
without
having
to
worry
about
things
breaking
halfway
through,
as
well
as
creating
throttle
metrics
so
that
the
registry
only
handles
so
many
deletions
at
a
time,
and
we
stay
within
our
boundaries
to
make
sure
everyone
has
a
nice
stable
experience.
We
are
gonna,
introduce
some
additional
features
from
the
research
that
just
expand
the
capacities.
A
Thank
you.
Everyone
for
taking
the
pennant,
listen
to
me
and
my
story.
I
was
really
excited
to
share
it
and
special
thanks
to
Steve
and
Sam
and
voilá
and
Nico
and
Lorie,
and
really
everyone
on
package.
This
was
a
big
undertaking.
It
had
a
lot
of
open
questions
and
a
lot
of
opinions
and
we
were
able
to
make
a
first
step
and
I
feel
like
once.
You
make
that
first
step.
Every
step
can
build
on
it
and
we
can
get
feedback
and
everything's
gotta
be
fantastic.
B
This
is
fascinating.
Thank
you.
So
much
for
sharing
this
and
I
loved
hearing
you
talk
about
how
the
team
iterated.
Can
you
talk
a
little
bit
about
the
timelines
for
the
iteration,
so
how
much
time
did
y'all
spend
on
research
and
design?
How
much
time
did
it
take
to
build
the
first
MVC
that
y'all
rolled
out
and
then
how
are
you
thinking
about
the
next
steps
and
kind
of
how
they're
gonna
fall
on
our
timeline?
That's.
A
A
The
container
registry
is
using
go,
we
didn't
have
a
go
engineer,
so
we
couldn't
exactly
work
on
it
now
that
those
counterparts
are
up
to
speed
and
are
now
really
building
heavily
I
think
we're
gonna
be
able
to
move
faster
in
terms
of
the
time
we
started,
building
it,
and
so
now
that
was
about
two
months
to
milestones
to
get
the
foundation
as
well
as
the
initial
UI
and
then
in
the
next
two
to
three
milestones.
We
hope
to
see
a
really
big
improvement
in
that
wider
adoption.