►
From YouTube: 2022-03-02 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).
B
C
B
Yeah
so
mostly
updates
the
fix
for
the
locking
seems
to
be
working.
I've
pasted
their
link
with
some
of
the
stats,
so
all
that
stuff
has
been
merged.
The
future
flags
that
we
use
to
test
it
out
have
been
cleaned
out
and
matched.
B
So
we
are
what
seems
to
be
ready
to
merge
the
backfilling
of
the
namespaces.
Mr
there
is
some
last
minute
discussions
about.
Do
we
need
to
communicate
this
stuff
to
the
self-managed
clients?
How
do
we
actually
do
that?
Is
there
a
process
there
or
or
something
along
those
lines?.
B
B
Aside
this
discussion
on
the
backfilling
migration,
how
do
we
handle
the
communication
and
some
last
minute,
questions
that
seem
to
have
raised
up
there?
I
I
can
I'm
hopeful
that
we'll
merge
this
this
week
or
early
next
week,
unless
we
find
some
blockers
there,
which
doesn't
seem
to
be
about
just
saying
like
it,
should
be
very
much
ready
to
be
managed.
B
B
B
I
think
it's
sequential,
but
again,
I'm
not
100
sure,
I'm
not
sure
if
you
can
run
several
batched
migrations
kind
of
in
parallel
at
the
same
time,
which
will
then
kind
of
be
a
slightish
problem,
because
we
need
to
make
sure
that
that
first
one
finishes,
and
only
after
that
can
we
do
the
other
migrations.
B
So
yeah
I'll.
Look
into
that.
B
I've
seen
all
this
video
and
there
seems
to
be
a
slide,
or
at
least
that
was
my
understanding
of
the
video
that
we
are
kind
of
past
phase,
one
which
is
not
exactly
true.
We're
we're
we're
somewhat
right
there,
but
the
migration
did
not
run
yet.
So
I
I'm
kind
of
let's,
let's
get
over
that.
So
that
seems
what
what
is
the
biggest
step
within
these.
The
first
phase
right
actually.
C
So,
let's
pause
alexandria,
that's
first,
so
my
understanding
is
that
the
only
project
that
migrated
up
until
now
is
gitlab.org
is
that
correct,
yeah,
okay,.
C
Completely
to
make
sure
that
we're
alive,
I
know
that
we
finishgate
live.org,
I'm
excited
about
that,
because
it
means
that
any
development
that
we
do
on
gitlab.org
already
is
in
the
namespace
convention.
That's
what
excited
me
and
why
I
am.
B
We
need
to
migrate
everything
before
we
are.
We
are
in
the
project
name,
spaces
convention.
If
you
will
like,
we
cannot
do
it
per
name
space
and
that's
why
we
are
kind
of
sort
of
blocked
by
this
entire
migration.
We
need
to
have
the
data
in
before
we
can
start
adding
code
that
relies
on
the
project
name
space
right
on
on
the
namespaces
in
general,
because
like
right
now
we
just
have
small
chunks
of
the
data
and
we
cannot
generalize
our
code.
B
C
B
Because
we
cannot,
we
cannot
condition
the
code
like
in
code.
We
will
need
to
write
if
it's
gitlab.org
then
go
this
path.
If
it's
not
gitlab,
gitlab
work
then
go
to
other
paths,
so
that
adds
a
lot
of
complexity
and
a
lot
of
place
for
bugs.
So
we
need
to
have
everything
in
place
and
then
we
would
only
say
well.
We
know
that
there
is
a
project
namespace,
give
me
the
project
namespace
and
do
the
stuff
as
if
there
is
project
namespace
right.
So
so.
C
That
makes
sense
to
me:
let's,
let's
it's
okay,
I
just
let
me
ask
questions
before
you
continue
to
the
next
point,
so
it
makes
sense
to
me
that
we
have
to
differentiate
somehow.
I
I
think
that
putting
ugly
if
statements
for
every
namespace
isn't
scalable
or
anything
that
we
want
to
do.
However,
I
am
a
little
bit
scared
that
we
need.
We
will
complete
migrating
everything,
then
we'll
move
on
to
the
policy
part
and
we'll
see
that
something
is
wrong
and
we'll
we'll
lose
a
few
weeks
of
work.
C
B
Any
policies
are
not
based
on
specific
unspecific
groups.
Policies
are
based
on
specif
on
different
objects.
So
to
say
groups,
projects
issues
in
general,
like
policies,
are
not
linked
to
a
specific
project
like
git.
Lab
policies
are
not
linked
to
specific
issue.
Number
74
right
policies
are
defined
on
issues
in
general
like
if
you
can
read
the
project,
then
you
can
probably
read
the
issues
within
that
project.
Right.
B
It's
not,
and
it
doesn't
say
if
you
can
read
project
gitlab,
because
then
you
need
to
do
that
hard
coded
in
the
code
as
well,
so
so
yeah.
We
can
not
really
do
it
in
that,
like
that
throughout
of
of
specified
labor
only
what
gitlab
work
migration
helped
us
understand
is
how
the
the
backfilling
will
work
in
general.
B
I
don't
think
we'll
lose
any
kind
of
time,
but
now
we
can
work
in
parallel
on
routes
on
policies
on
members
also
so
split
the
work
in
that
way,
rather
than
split
it
into
into
like
working
on
a
specific
group
and
test
everything
on
a
specific
group.
If
that
makes
sense,
it.
C
B
C
Concern
is
that
gilad.org
is
one
name
space
out
of
a
lot.
It
is
the
minority,
and
so
I
think
it's
going
to
take
us
a
really
long
time
to
backfill
everything.
Maybe
I'm
wrong,
but
I
think
it's
going
to
take
us
a
while,
and
I
would
like
to
know
what
our
plan
is.
If
we
are
working
in
parallel,
how?
How
is
that
going
to
work
if
we
have
to
wait
for
everything
to
be
complete?
First.
A
But
we
want
like
with
gitlab
we
are
like.
We
are
ready
to
backfill
the
one
group.
Now
we
will
be
lay
back
filling
groups
in
badges,
so
it
won't
be
like
we'll
backfill
group
by
group
by
group
will
compress
it
so
it
it
won't,
be
it
won't.
Be.
You
know
that
long.
We
wanted
to
test
this
migration
for
one
group
to
make
sure
that
you
know
everything
works.
So
that's
why
we
started
with
gitlab.github.com.
A
B
Yeah,
so
we
did
continue
to
work
like
onto
things
that
go
into
phase
two.
So
what
we
were
saying
further
on
that
we
do
work
on
the
phase
two,
where
we
do
work
on
these
car
functionalities.
That's
correct!
We
continue
to
work
that
that's
still
that
that's
just
the
problem
is
that
we
cannot
yet
match
that
code
into
master
and
and
go
with
that
into
production,
because
we
need
the
big
feeling.
B
We
need
the
other
backfill
links
to
run
and
then
merge
the
other
code,
but
there
are
still
things
to
be
solved
in
dell
in
in
kind
of
those
areas
we're
still
working
on
code
as
like,
as
in
development,
sort
of
thing
right.
C
So,
just
just
so
I
understand
yeah
backfilling,
there's,
there's
backfilling
project
name
space.
Then
we
have
fixing
routes,
we
have
to
move
members
and
users,
I'm
not
exactly
sure
what
the
difference
between
them
is.
But
let's
just
say
for
now.
A
Members
remember
this
is
the
correct
terminology.
B
Like
policies
can
be
worked
on
after
the
project,
namespaces
backfilling
is
done
it
so
so
policies
are
not
very
much
linked
to
the
database.
If
that
makes
sense
what
what
the
policies
work
involves
is
that,
once
we
have
this
project,
namespaces
backfilled
for
every
project,
we
have
a
namespace
and
now
the
policies
that
are
defined
at
the
project
level,
as
for
the
project,
can
be
redefined.
B
As
for
the
namespace
right
because,
like
we
can
take
it
and
get
that
associated
namespace
and
move
that
code
into
the
namespace,
so
basically
kind
of
remove
the
code
that
relates
to
the
project
and
only
use
the
code
that
relates
to
the
namespaces.
It's
not
that
easy.
I'm
just
like
trying
to
give
the
general
picture
because-
and
the
problem
comes
into
the
all
these
small
differences
between
projects
and
and
groups
and
namespaces
and
all
that
stuff.
So
you
need
to
you.
We
will
get
a
lot
of
these
well.
B
B
It's
just
like
kind
of
consolidating
the
code
around
that
cleaning
up
some
of
the
code
that
is
related
to
the
projects
themselves
and
so
on.
C
A
Oh
no
places
are
phase
two,
because
this
is
a
big
part
of
the
face
too.
It's
just
it's
like
consolidating
the
code
around
one
one
idea
like
because
right
now
we
have
different
code
for
groups
and
projects
and
with
policies
work
in
phase
two,
we'll
we'll
be
able
to
make
it
more
make
it
more
coherent
and
get
rid
of
some
differences
between
how
projects
in
the
groups,
projects
and
groups
work.
C
A
little
bit
confused
of
what
is
phase
two
and
what
it
contains.
Can
we
just
put
on
that
epic
of
phase
two
just
what
we
need
to
do?
Policies
members
routes,
whatever
we
need
just
so
that
we
can
mentally
check
them
off.
B
What
I
just
wanted
to
say
is
that
there
is
no
clear
line
that
divides
like
phase
two
from
phase
three
from
phase
one,
it
it's
more
of
a
blush
line,
if
you,
if
you
wish
right
and
that's
because
let
me
breed
up
I'll
share
my
screen
in
a
second.
Let's.
A
I
would
also
like,
for
example,
back
thing
for
members
will
be
like
the
like:
first
part
of
backfilling
for
members
will
be
starting
all
backfield
members
for
like
will
modify
members
for
groups
just
a
little
bit.
It
won't
be
visible
to
users,
but
that
way,
we'll
prepare
for
backfilling
members
for
project
namespaces.
Once
project
namespaces
are
in
place,
so
we
are
working
on
phase
two
already.
A
A
A
Except
where
you
can
like
switch
it
on
and
off
again,
so,
like
re
rejoin,
the
call.
B
So
yeah,
what
what
what's
your
questions
are
around
this
phase
too
epic.
C
My
main
concern
is
that
I
don't
understand
what
it
holds,
there's
a
lot
of
different
issues
and
epics
linked
to
it.
I
would
just
like
to
know
like
in
order
to
complete
phase
two.
We
have
to
complete
routes.
Members
policies-
I
don't
know-
probably
there's
more
here-
queries
whatever
we
need
to
do
just
so
that
mentally.
I
know
that,
like
what
are
the
blocks.
B
Yes,
so,
like
my
understanding
is
like
there
is
no
clear
line
that
says
well,
this
is
where
we
end
phase
two
right
like
for
me.
If
we
do
the
routing
and
membership,
we
can
basically
start
passing
on
to
the
phase
three
and
have
other
teams
start
to
migrate
their
stuff
into
project
namespaces
we're
using
namespaces,
because
this
will
give
a
clear
example:
sort
of
how
we've
migrated
the
membership
and
routing
feature
towards
the
namespaces
from
the
project.
B
Okay,
so
so
like
for
me,
I
think
that's
that's
where
we
can
start
implicating
other
teams
into
doing
these
migrations,
but
the
the
other
stuff
that
is
in
phase
two
is
just
something
that
is
feels
sort
of
generic
and
like
relates
to
a
lot
of
other
things
where
other
teams
will
probably
not
jump
in
and
do
this
stuff.
So
we
will
need
to
do
them
as
a
workspace
group.
B
If
you
will
so
like,
I
cannot
see,
I
don't
know
some
some
group
or
some
stage
doing
a
lot
of
these
policies,
migration
towards
the
namespace,
even
though
a
lot
of
the
teams
will
contribute
to
that,
because
they
have
their
own
permissions
that
relate
somehow
to
the
to
the
project
that
needs
now
to
be
moved
to
the
namespaces.
B
But
this
this
was
more
of
a
let's
do
some
of
the
generic
stuff
that
affects
a
lot
of
the
places
as
a
different
phase,
and
then
we
can.
We
can
call
the
phase
three,
as
as
people
as
the
entire
company
can
get
into
involved
into
moving
the
features
into
the
namespace
from
the
project.
C
No
not
really
and
I'll
explain
why
so
my
the
way
that
we
faced
the
whole
workspace
mvc
was
to
enable
people
to
start
migrating
things
over
right.
My
understanding
was
that
phase
two
needs
to
be
complete
before
we
start
the
migration,
meaning
which
is
phase
three.
So
if
we're
saying
that
there's
things
here
that
are
not
necessary
for
that,
they
should
move
out
to
a
different
epic.
C
This
needs
to
be
the
minimum
that
we
need
in
order
to
help
other
teams
migrate
things
over.
If
we
have
generic
things
like,
for
example,
the
admin
panel,
which
is
totally
unrelated,
it
has
its
own
epic,
and
so,
if
we
have
similar
things
like
that,
let's
move
them
out
of
here.
This
should
be
the
bare
minimum
that
we
need
in
order
to
enable
other
groups
to
move
their
stuff
over.
A
All
right,
how
do
you?
How
do
you
feel
about
us
we're
collaborating
on
cleaning
out
this
epic
because,
as
you
said,
there
are,
there
are
places
that
we
can
probably
can
like
move
move
to
like
phase
three
or
to
other
teams,
and
once
once
we
get
the
first
cleanup,
we
will
ask
the
team
alexandru
will
ask
manoj
will
ask
charlie
to
just
make
sure
that
we
haven't
removed
too
much
or
let
or
we
haven't
like.
A
We
did
not
leave
something
so
like,
let's
start
with
ourselves
and
then
we'll
just
check
with
the
team.
C
Yeah,
I
think
that's
a
great
idea.
It's
also
spring,
so
it's
time
for
cleaning,
and
so
yes,
let's,
let's
try
to
understand
like
what
is
the
minimum,
because
really
the
way
that
we've
been
presenting
it
also
as
part
of
the
video
that
I
uploaded
today
is
that
this
is
impediment
for
moving
on
over
to
phase
three,
and
my
understanding
is
that
without
moving
without
moving
routes,
for
example,
no
one
can
move
over
anything.
So
I
understand
that
has
to
be
in
this
in
this
space.
C
C
That
we,
we
just
placed
them
correctly,
so
that
everyone
can
be
aligned,
there's
a
lot
of
eyes
on
this
workspace
project.
Everyone
want
is
really
eager
to
move
over
their
stuff
and-
and
you
know
I
want
to
make
that
happen.
So
let's
make
sure
that
this
is
transparent,
and
we
know
that
what
what
is
the
scope
of
work
where
we
are
and
what
can
be
moved
over
to
another
place.
B
Yeah
I
I
would
just
say
that,
like
phase
two
and
phase
three
can
go
in
parallel,
like
the
only
blocker
is
really
completing
the
phase
one
but
like
having
some
of
this
phase.
Two
stuff
done
will
give
a
good
understanding
an
example
for
the
rest
of
the
teams
on
how
to
do
it.
What
are
some
of
the
problems
that
we've
encountered
and
how
we
kind
of
solved
it,
and
so
on?
So
really
we
could
like.
After
we
have
the
the
project.
Namespace
is
backfilled.
B
You
can
start
doing
implementing
stuff
at
the
game
space
level,
if
you
wish,
as
a
stage
or
as
a
group
where,
like
as
a
team
right
and
we've
had
someone
from
the
protect
group,
I
think
was-
was
already
starting
to
look
into
that.
Even
though
we
didn't
kind
of
officially
complete
the
phase
two
right.
C
Oh,
yes,
absolutely
and
I
think,
that's
exciting.
I
think
we
have
a
lot
of
lessons
learned
here
that
we
should
probably
write
down
somewhere
and-
and
I
think
that,
having
an
added
value
from
the
fact
that
moving
these
policies
and
moving
these
members
giving
us
a
framework
of
how
to
do
it
correctly,
will
absolutely
shorten
the
time
for
other
teams
and
help
them
onboard.
So
I'm
all
excited
about
that
idea.
A
Okay,
all
right,
we
will
be
in
touch
and
we
will
also
be
in
touch
with
the
team
just
to
make
sure
that
everyone
are
on
the
same
page,
and
I
think
it's
a
good
idea
and
great
initiative
of
like
cleaning
it
up,
because
those
epics
grow,
because
we
are
finding
new
and
new
stuff,
and
this
is
obvious,
but
by
cleaning
it
up.
It's
amazing
idea.
B
Yeah-
and
I
I
think
next
is
if,
if
we
are
done
with
this,
I've
got
the
next
point
related
to
the
workspaces
or
workspace
concept,
and
I
don't
think
we
discussed
this
as
part
of
this
group.
This
was
more
of
consolidate
groups
and
projects
work
rather
than
rather
than
workspaces,
and
I
was
just
curious
if
there
is
something
that
I
can
read
on
about
or
how
is
it?
How
is
it
different
really
from
a
root
group
and.
B
Like
I
just
have
this
problem
of
thinking
about
the
workspace
as
moving
the
problem
off
of
of
merging
two
root
groups-
kind
of
one
step
up
rather
than
solving
this
problem,
so
I
I'm
trying
to
understand:
does
this
actually
try
to
solve
that
problem?
What
kind
of
problem
does
the
workspace
try
to
solve,
because
it's
if
it
doesn't
solve
the
problem
of
at
least
do
reporting
across
multiple
route
groups
right,
then
it
feels
like
we're
just
adding
another
layer
layer
on
top.
So
what
next
is
what,
if
the?
B
If,
if
user,
wants
to
combine
two
workspaces,
you
really
add
yet
another
object
on
top
of
that
and
so
on.
So
so
this
is
kind
of
move
to
an.
C
Oh
yes,
this
is
a
very
high
fidelity
and,
like
two
years
down
the
road
we're
talking
about
a
single
worst
place
right
now,
maybe
nick
you
want
to
share
these
were
your
designs.
This
is
a
ways
out
so
I
didn't
want.
I
didn't
mean
to
confuse
anyone.
This
is
just
the
designs
we
currently
have,
so
I
just
wanted
to
kind
of
to
explain
like
where
we
will
be
maybe
somewhere
down
the
road.
C
I
don't
think
that
there
is
really
a
big
difference
between
the
root
group
and
the
workspace
for
today.
I
think
the
biggest
difference
that
users
are
going
to
have
right
now
is:
what
are
they
going
to
see
at
the
workspace
level?
The
workspace
level
may
also
be
a
project
namespace.
It
might
not
be
a
group,
it
might
be.
You
know
it's
the
highest
name
space,
so
I'm
not
sure
we
should
think
about
it
as.
B
C
It
can
be
the
workspace
can
have
multiple
groups
in
it
right
or
multiple
subgroups.
It
can
have
flat
projects,
it
can
have
different
hierarchies
conceptually
there's
a
few
terminologies
that
we're
playing
around
with
workspace
is
a
good
way
to
to
describe
like
an
organization's
entry
point.
I
think
that
microsoft
calls
it
spaces.
I
might
be
wrong.
What
for
sure
is
the
terminology?
We're
not
going
to
use
is
namespace.
C
Namespace
means
nothing
to
our
users,
so
we're
all
using
namespace.
As
you
know,
the
core
constructs
we're
going
to
need
to
figure
out
how
to
call
that
that's
just
to
be
tbd
right
now,
but
what
I
do
want
to
say
is
that
workspace
group
there's
nothing
special
about
it.
It
just
happens
to
be
at
that
top.
C
What
we
want
to
accomplish
with
this
whole
simplified
projects
and
groups
concept,
is
that
everything
should
look
the
same.
The
only
difference
is
the
hierarchy.
Where
am
I,
and
so
that
top-level
name,
space
or
top-level
group
or
root
group
or
whatever
you
want
to
call
it?
It
shouldn't
really
be
that
different.
There
might
be
very
small
things
that
are
unique
to
that
group,
but,
generally
speaking,
it
should
be
exactly
the
same
as
any
other
group.
A
I
think
we
are
using
with
alexandria
the
terminology
root
group.
You
will
hear
us
from
engineers
because
this
is
like
what
it's
called
in
the
code.
So
that's
why
we
are
using
it.
So
that's
why
so
I
just
want
to
under,
like
tell
you
why
we
have
this
terminology
where
it
calls
for
group,
because
this
is
in
the
code
and
right
now
the
root
group
like
works
like
that.
A
This
is
the
group
that
has
this
like
small,
different
differences,
and
I
think
this
will
like
stay
that
way,
except
for
like
that,
we'll
just
call
it
workspace
or
whatever.
B
In
the
future,
okay,
like
I
guess
my
understanding
was
wrong-
that
because
my
understanding
was
that
workspaces
all
solve
this
problem
of
connecting
two
root
groups
like
making
it
possible
so
like
a
lot
of
the
time
I'll
give
this
symbol.
Well,
this
example,
where
you
have
basically
two
companies,
let's
say
right,
fruit
group,
a
and
root
group
b,
and
then
they
merge,
and
then
you
want
the
reporting
from
the
both
companies
to
go
to
some
higher
level.
So
that's
where
my
understanding
goes
about.
B
C
The
real
problem
we're
trying
to
solve
is
efficiency
and
parity
between
self-managed
and
sas
users.
That's
the
real
problem
to
solve
the
way
that
we
decided
to
do.
That
is
currently
we're
kind
of
in
the
mid
step
right
now,
which
is
we're
migrating
whatever
we
can
to
the
group
level,
but
really
every
feature
that
we
want
that
we
we
create
users
want
it
everywhere.
They
want
another
project
level.
They
want
it
out
of
the
group
level.
They
want
it
on
an
instance
level.
C
B
A
Yeah,
I
think
it's
it's
very
common,
because
people
are
looking
like.
I
know
that
a
lot
of
people
from
product
group
are
looking
at
from
like
top
up,
so
they
are
looking
for.
Looking
more
of
this
like
workspaces
workspace.
That
already
is
mentioning
and
from
the
engineering
side
we're
looking
at
from
like
bottom
to
the
top.
So
we
are
first
consolidating
groups
of
projects
and
then
we
can
think
of
like
movie
of
like
providing
the
parity
between
projects,
groups
and
instance
level.
A
C
Well,
I
also
like
the
fact
that
people
get
confused,
so
that
makes
us
dig
deeper
and
make
everyone
aligned
on
the
same
page
because
alexandria,
I
just
want
you
to
know
that
I've
got
pink
about
that
question
also
on
slack
from
different
people.
The
multiple
workspace
concepts
is
really
confusing.
Really
we
haven't
thought
it
through.
C
Yet
it's
way
down
the
line,
we're
not
even
at
that
single
workspace,
yet
so
that
I
just
do
want
to
make
sure
that
everyone's
aligned,
because
we're
working
on
this
simplify
groups
and
projects
project,
but
that's
not
our
end
goal.
This
is
just
the
foundation
level.
Our
end
goal
is
to
create
that
workspace
level.
B
Well,
will
there
be
well,
I
guess
there
will
be
some
feature,
differences
between
a
workspace
and
a
group
right
because
there
are,
if
we
are
like
we
are
drawing
this
equal
sign
between
an
instance
level
and
a
workspace
for
sas.
Then
there
are
some
features
that
are
only
at
the
instance
level.
I
don't
know
like
setting
the
licenses
or
or
stuff
like
that
that
doesn't
go
into
a
group
for
a
sub
group,
so.
C
C
I
would
like
to
see
that
in
any
name
space,
even
on
the
project
like
there,
there
is
a
use
case
where
a
big
organization
has
an
I.t
department.
Someone
needs
to
manage
all
the
users
and
work
inside
their
organization,
but
then
you
know
they
have
no
idea
who
needs
permissions
and
whatnot
in
the
specific
group
or
subgroup
or
whatever.
So
it
makes
sense
that
there
will
be
a
group
owner
that
has
higher
controls
to
do
those
types
of
things,
especially
around
billing
and
licensing.
C
If
you
want
to
go
into
nuances,
I've
already
had
customer
conversations
with
organizations
that
have
multiple
sites
like
in
different
countries,
and
so
they
want
on
one
hand,
to
have
someone
controlling
all
the
seats
and
licenses,
but
on
the
other
hand
they
want
a
local
admin
per
country,
and
so
so
think
about
that
you
would
have
that
group
owner
per
country
and
they
could
manage
their
own
licenses.
I
mean
this
is
really
complex
and
we're
not
there
yet,
but
the
idea
is
giving
the
users
maximum
flexibility
in
any
name
space
that
they
are.
C
There
has
to
be
really
very
specific
features
that
will
remain
at
that
workspace
that
won't
cascade
downtown
namespace.
There
are
some
things
that
we
might
not
move
over,
for
example,
hardware,
since
we're
talking
about
sas.
It
doesn't
make
sense
to
move
over
the
hardware
settings
into
into
the
settings,
so
that
will
probably
stay
self-managed
and
will
be
different,
but
on
the
other
hand,
there's
a
bunch
of
things
that
makes
total
sense.
Why
don't
we
have
that
today,
like
like,
create
the
ui,
the
color
of
the
background
of
git
lab
today?
B
Can't
I
say,
though,
those
things
do
make
sense.
I
was
more
thinking
about
license
and
billing,
but
I
guess
that
also
makes
sense
to
move
to
subgroups
to
some
level
right.
As
you
said,
if
you
have
a
different
branch
in
europe,
they
can
manage
their
own
subgroup
and
their
own
licenses
and
their
own
payment
versus
a.