►
From YouTube: 2022-04-06 Workspace meeting
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
A
Yeah,
like
in
the
short
term,
it's
good
news
that
we
can
move
on,
but
I
I
I
was
just
saying:
I
don't
exactly
like
the
idea
of
like
only
having
this
middle
point
where
or
end
or
start
of
the
really
it's
just
for
for
doing
something
required,
because
that,
like
that
means
that
you
need
to
postpone
stuff,
sometimes
like
for
six
months
right,
if
you,
if
you
just
missed
the
midpoint
or
the
end
of
the
or
yeah
like,
then
you
kind
of
have
to
postpone
it
for
a
long
time,
and
I
understand
the
customers
part.
A
I
understand
that
we
should
not
make
it
difficult
for
customers
to
update
to
upgrade,
but
I
don't
think
we
I
mean
we
should
try
and
not
make
it
at
the
cost
of
the
of
the
teams
doing
stuff
and
implementing
stuff
and
releasing
it
as
well
right.
So
yeah
I
was
just
I
was
saying
I
don't
have
the
solution,
but
we
should
have
some
sort
of
a
discussion
and
see
where
we
can
improve
the
process.
A
They
should
know
in
advance
that
these
are
the
steps
that
they
will
need
to
take
to
get
to
the
latest
version
and-
and
I
think
the
the
biggest
problem,
but
like
don't
quote
me
on
that,
but
like
to
me,
the
biggest
problem
is
that
customers
don't
really
know
their
great
pots.
They
will
have
like
they.
A
They
think
that
they
are
on
eight
zero
and
they
can
jump
right
straight
to
15
00,
which
is
not
exactly
true
and
if
we
kind
of
at
least
inform
them
and
tell
them
well,
there
are
some
specific
things
that
need
to
happen
before
you
can
jump
to
that
version.
Then
it's
kind
of
I
think
it's.
It
solves
one
of
the
problems,
but
I
guess
there
are
some
other
concerns
as
well
with
that
I
don't
exactly
know
we'll.
A
Well,
I
don't
want
to
take
too
much
work
on
my
myself,
but
it
will
be
nice
to
kind
of
get
this
sorted
out.
This
distribution,
it's
like
my
understanding.
It's
perhaps
something
to
be
solved
between
database
team
and
the
distribution
team,
because
these
seem
to
be
batch
migrations
that
kind
of
require
this
stuff.
I'm
I'm
I'm
okay
to
participate
in
that
and
give
feedback
and
contribute
as
much
as
I
can,
but
like
this
solution
of
having
a
midway
point
and
and
or
start
of
a
release,
doesn't
really
sound
right
with
me.
A
Term,
it's
fine
that
we
can
move
on.
I
don't
know
if
you've
had
a
chance
to
look
through
other
discussions
and
we
are
I'm
sorry
manoj
I've
already
we're
taking
the
point.
So
we
are
so
somewhat
already
at
this
second
point
in
the
agenda
and
there
is
a
another
discussion
with
the
developer
on
the
distribution
team
about
how
we
can
perhaps
run
it
in
line.
A
I
I
think
one
tweak
that
we
can
do
to
the
migration
itself
is
use
the
postgres
statistics
and
and
if
we
have
the
information
that
there
are
less
than
x
number
of
throws,
we
can
just
run
it
in
line
and
not
have
it
a
background
migration
and
that
kind
of
solves
that
problem
with
the
ensure
that
the
migration
finished
migration,
that
that
will
raise
an
exception
right
because
it
will
run
in
line.
A
It
will
wait
for
the
migration
to
finish
and
then
it
will
move
on
to
the
to
the
other
one
so
that
one
will
not
fail
anymore.
So
I
think
that's
one
tweak
that
we
can
do
that
will
not
cover
all
of
the
customers,
but
I
think
a
good
part
of
people
that
customers
that
don't
have
that
many
projects
will
probably
benefit
from
that.
A
That
will
be
probably
less
work
for
the
support
for
the
again
for
the
smaller
customers,
so
to
say
the
ones
that
can
run
it
in
line
for
a
couple
hours
or
I
don't
know
how
long
it
will
take.
But
yeah.
A
We
just
need
to
figure
out
what
that
number
is,
which
can
be
a
difficult
task.
I
guess,
because
it
very
much
depends
on
the
size
of
their
instance
right.
A
B
A
I
think
there
is
some
database
office
hours
after
the
call
I'll
try
to
raise
it
there
and
see
if
we
get
some
feedback,
but
the
other
otherwise
like
they.
They,
the
go-to
thing
for
me
right
now
is
just
leave
it
as
is,
and
then
see
if
we
can
introduce
any
kind
of
improvement
to
the
existing
migration
so
that
we
don't
have
this
stopping
thing.
A
A
Let
me
think
so
say
you
needed
to
migrate.
Username
spaces
right,
do
something
with
the
username
spaces.
What
a
background
migration
will
do
is
really
select
only
those
namespaces
and
run
the
migration
over
those
databases.
So
that's
like
what
maybe.
C
A
Of
the
of
the
namespaces
table
with
the
batched
migration,
what
we
do
is
we
actually
iterate
through
the
entire
table
through
everything
and
then
within
that
smaller
iteration.
We
pick
the
records
that
we
need
and
we
need
that
to
make
it
like
more
predictable
to
predict
how
the
migration
will
behave,
and
but
that
makes
the
migration
the
batch
migration
like
at
least
three
times
bigger
than
the
background
migration,
and
I
don't
think
we
had
this
situation
before
we
had.
A
We
might
have
had
it
actually
when
we
migrated
the
begins,
the
integer
primarily
to
the
big
end,
but
that
was
stretched
over
many
many
releases
and
probably
did
not
so
did
not
cause
this
three
releases
scenario,
kind
of
steps
that
was
needed
to
take.
So
nobody
really
encountered
this.
I
guess.
B
A
Yes
and
like
I
guess,
the
problem
is
a
combination
of
two
things.
One
is
what
you're
saying,
and
the
second
thing
is
that
we
were
sort
of
unlucky,
that
it
happened
on
14
9
right
if
it
would
have
happened
in
45,
like
people
would
say.
Well,
it's
not
ideal,
but
that's
okay,
right,
because
we
need
to
introduce
this
stopping
step
for
the
migration
to
finish
and
then
move
on
right.
So
so
it's
a
combination.
A
It
seems
of
two
things
because
it
happened
on
49,
which
is
one
release
before
the
last
release
in
the
major
version,
and
then
there
is
the
new
release.
So
this
is
where
this
kind
of
from
it's
a
bit
yeah,
it's
a
bit
weird
and
and
kind
of
unlucky,
but
because
of
these
three
releases
in
a
row
thing,
it
seems
that
this
migration,
that
checks
and
fails
has
has
become
more
of
a
more
into
attention.
So
to
say
right.
A
So
it
was
there
before
it
was
used,
but
it
didn't
come
as
much
into
attention
as
it
does
right
now,
and
I
agree
that
it's
not
an
ideal
path
to
to
fail
a
migration.
An
ideal
path
would
be
try
and
overtake
it
and
finish
it
get
it
over
the
line.
Somehow,
but
it's
not
totally
not.
It's
not
always
possible
to
do
that,
because
if
you
overtake
it
and
it's
a
big
migration,
then
you
kind
of
have
to
wait
for
it
right.
I
don't
know
like
maybe
a
day.
A
A
Yeah:
okay:
here's
here's
where
the
automated
script
check
that
I
thought
of
came
into
play
right
so
so
say
yeah
so
so
say
you
are
on
14
5
version
and
then
you
get
this
checking
script.
That
says,
you
need
to
go
to
49
version.
First,
you
go
to
fortune
9
version.
First,
all
the
migrations
ran
and
say
you're,
not
aware
that
you
have
a
migration
running
in
background
and
it
didn't
finish
yet
right
and
when
you
run
the
upgrade
script
again
it
the
part
of
the
checking
will
be.
A
Do
you
have
any
running
migrations?
Yes,
you
do
well
sorry.
You
cannot
upgrade
yet
because
you
don't
like
your
migrations,
didn't
finish,
and
then
you
don't
end
up
in
the
situation
where
you
upgrade,
you
run
into
a
failed
migration
and
you
need
to
revert
back
right.
You
just
don't
get
into
a
failure
state
in
the
first
place.
You're
just
yes,
you'll
be
on
a
lower
version
of
the
gitlab
for
a
few
days
for
a
week
for
a
month
I
don't
know
and
then,
when
you're
ready,
you
can
move
on
and
upgrade.
B
I
mean
this
is
the
like
the
feedback
that
distribution
team
needs
to
hear
that
maybe,
if
we
like
have
not
migration,
because
right
now,
we
have
one
tool
to
stop
the
upgrade.
If,
if
migrations
are
like
patch
migration
is
not
finished.
This
is
the
typical
migration,
but
maybe
there's
supposed
to
be
like
something
better,
rather
than
you
know
something
failing
when
customers
wants
to
upgrade.
A
B
A
Yeah,
the
the
other
problem
is,
and
I
don't
exactly
know
the
the
flow
the
process,
but
I
guess
the
other
problem
is
that
we
have
different
ways
to
upgrade.
One
is
the
this
opening
box,
the
other
one
is
from
source.
The
other
one
is
is
through
the
cloud
native
or
some
so
at
least
three
versions
to
three
versions
of
I
don't
know
keeping
github
or
I
don't
know,
github
installs,
if
you,
if
you
will
right-
and
I
don't
think
we
have
a
single
upgrade
flow
for
for
every
single
one
of
them
like
this.
A
These
are
three
different
upgrade
flows
and
like
different
things
are
possible.
I
don't
know
if
there
is
any
work
on
consolidating
that
having
a
single
upgrade
script
or
something
like
that.
I
don't
even
know
if
that's
possible,
because
I
guess
the
omnibus
things
are
the
ones
that
are
kind
of
even
the
cloud
ones
and
the
source
ones
are.
The
whole
idea
of
self-managed
is
that
it
can
be
isolated
from
internet
right.
It
doesn't
expose
the
instance
to
the
internet,
and
then
how
do
you
have
a
single
script?
A
A
Know
how
all
that
stuff
works,
but
that's
one
of
the
things
that
that
might
not
that
be
that
easy
to
solve,
but
yeah.
It's
something
that
it's
more,
I
think
in
the
distribution
team
camp.
But
if
we
can,
we
should
bring
it
up
and
try
and
suggest
as
a
discussion,
maybe
maybe
maybe
that's
something
that
can
can
open
up
to
some
some
some
other
solutions
that
they
are
not
considering.
At
this
point.
C
Okay
yeah,
so
my
agenda
is
around
the
feature
that
we
are
trying
to
release
ownership
for
projects,
so
we
are
as
we're
digging
deeper.
We
are
figuring
out
more
and
more
use
cases
where
maintainers
should
not
be
allowed
to
deal
with
owners
and
owners
should
be
able
to
add
on
us
and
things
like
that,
so
a
lot
of
changes
going
on.
But
if
we
include
refactoring
along
with
that,
which
is
the
current
state
of
that,
mr
that
I've
posted
it
becomes
a
a
lot
of
things
to
manage
in
one
go.
C
So
my
idea
is
that
we
should
keep
refactor
aside
and
then
just
simply
feature
flag
and
feature
changes
in
this.
Mr,
when
you're
releasing
it
because
everything
together
is
going
to
be
problematic
and
if
we
feature
flag,
we
can
extensively
check
this
thing
out
and
staging
and
then,
if
everything
goes
well,
we
can
enable
it
on
production,
so
yeah.
C
My
opinion
is
to
get
refactoring
out
of
the
way
for
now
and
get
feature
flagging,
plus
feature
changes
rolling
in
the
meantime,
there's
also
a
security
issue
that
is
related
to
this
so
and
we
have
made
a
quite
a
few
changes
in
the
security.
Mr,
so,
unless
the
changes
from
security
mr
lance
on
master,
we
don't
necessarily
have
a
way
to
keep
building
on
this,
because
if
we
start
cherry
picking,
then
the
changes
would
become
public.
So
it
does
not
serve
the
purpose.
C
B
C
Will
slow
down
as
well,
because
when
you
have
feature
flags,
you
can
use
the
same
feature
flag
across
multiple
mars.
C
Do
like
you
can
build
on
separate
areas
as
well
like
there's
an
area
where
you
have
to
invite
a
project
to
a
group,
and
you
can
change
the
access
levels
of
that
specific
feature
alone
in
a
separate
marvel
and
its
feature
flag.
Then
you
pick
up
inviting
members
to
the
project
itself.
That
can
be
a
separate,
mr.
B
Okay,
I
support
your
decision
on
this
like
if
we
need
to
do
it
to
if
we're
not
like
just
keeping
their
factor
just
like,
but
we
need
to
move
with
this
and
otherwise
it's
not
possible.
That's
the
only
electrical.
C
Thing
to
do
yeah,
okay,
but
we
will
again
face
delays
on
that,
because
somebody
discovered
the
security
issues.
So
now
we
have
to
deal
with
that
first
and
then
wait
for
it
to
land
on
master
to
build
further.
So
maybe
we
can
pick
up
something
else
in
the
meanwhile
I'll
talk
with
charlie.
B
C
B
A
A
I
didn't
have
anything
on
there,
but
I
just
thought
about
this
now
and
now
that
we
have
a
lot
of
future
flights
because
in
our
spoke
about
feature
flags,
I
know
we
have
a
lot
of
feature
flags
related
to
traversal
ideas
like
is
there
a
plan
somewhere
or
an
issue
like
when
we
are
starting
to
like
enable
by
default
those
feature
flags?
I
can,
I
think,
that's
wrong
good
improvements,
but
most
of
those
flags
are
disabled
by
default.
B
Yes,
they
are
disabled
by
default,
but
we
have
an
issue
about
like
that.
Gathers
all
the
future
flags
and
you
know
because
some
some
of
them
were
like
long-living
feature
flags,
and
some
of
them
were
like
very
short-living
feature
flags,
so
they
were
like
enabled
checked,
like
enabled
check
if
they
perform
well
and
then
removed
all
together.
B
But
but
there
are
also
just
like
long
living
feature
flags
and
nice
like
youtubers
ids,
and
they
are
still
disabled
by
default.
I
believe.
A
B
A
B
Yes,
they
are
developed
they're
like
based
on
the
therefore
development,
because
we
are
also
running
into
like.
We
need
to
wait
for
like
major
release
to
remove
some
of
the
database
things.
A
Yeah,
I
can
see
some
of
them
are
scenes
like
milestone,
13,
11,
yeah
and
still
not
given
okay.
I
was
just
curious
if
we
have
something
like
tracking
this
soil.
Well,
it
would
be
easier
to
follow
up
on
a
lot
of
the
blockers
to
enable
them
by
default,
like
we
can
keep
the
feature
flag
on
like
in
right,
but
enabling
it
by
default,
and
then,
if
anything
goes
wrong,
we
can
turn
it
off
or
anyone
in
self-managed
can
can
turn
it
off.
A
Yeah
the
the
problem
is
like
as
we
it's
not
a
problem
right
now
like
we
have
a
lot
of
stuff
to
do,
but,
as
we
start
moving
forward
with
the
this,
consolidation
is
where
we
will
have
to
improve
the
queries
and
rely.
B
A
Ideas
for
the
for
the
self-managed
will
be
one.
I
think,
big
aspect
of
that
and
not
having
the
future
flags
enabled
by
default
makes
it
impossible
basically
to
go
that
route
start
thinking
about
like
turning
that
feature
flag
on
by
default,
still
keeping
it
there
for
any
reason
to
just
get
reports
back.
If
anything
doesn't
work
or
anything
like
that,
I
will.