►
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
All
right,
so
I
just
want
to
do
a
brief
walkthrough
of
the
initial
thoughts
that
I
have
in
mind
for
the
new
single
person
group
to
handle
merge
request
approvals.
Certainly
none
of
this
is
finalized
is
sort
of
the
big
caveat.
A
In
fact,
I
don't
think
we
even
have
a
whole
lot
of
issues
or
epics
or
even
designs,
yet
around
this
area
other
than
just
a
rough
prototype
and
there's
a
little
bit
out
there,
but
it
certainly
is
not
organized
yet
so
just
take
all
of
this
as
notional
thinking
highly
subject
to
change
and
we'll
be
working
out
the
details
in
the
future,
but
as
of
today,
we
should
probably
start
with
what
exists.
B
C
A
It
all
right
well
licensed
compliance.
I
did
find
this
so
licensed
compliance.
You
can
go
in,
you
can
specify
a
branch
and
you
set
up
specific
approvers
that
you
want
to
have,
and
it
looks
for
any
dependencies
with
a
software
license,
that's
specified
as
denied.
So
basically,
if,
if
you're
trying
to
merge
in
a
new
dependency,
that's
not
approved
it
routes
it
to
this
specific
group
of
approvers
that
you've
defined
here
and
requires
their
approval
before
it
can
be
merged
in
and
the
security
approvals
is
very
similar.
A
You
set
up
this
project
approval
rule
in
here
and
you're
able
to
specify
you
know
who's
allowed
to
approve
it.
It's
just
a
little
bit
odd
because
all
of
this
great
functionality
is
off
on
its
own
by
itself.
Under
this
settings,
general
tab-
and
it's
a
little
bit
hard
to
find-
and
perhaps
the
biggest
problem
is
all
of
this-
is
done
at
the
project
level.
A
So
if
you
have
an
organization-wide
policy
about
the
licenses
that
are
allowed
to
you
be
used
or
vulnerabilities
that
that
are
allowed
to
be
merged
in
you
have
to
go
and
do
this
for
every
single
project.
And
you
know
this
is
going
to
sound
like
a
very
familiar
story
for
the
container
security
group
anyway.
But
you
know
once
again
for
customers
with
14
000
projects
to
go
and
do
all
of
this
thousands
of
times
at
the
project
level
and
then
make
sure
it
stays.
That
way
is
just
not
sustainable.
A
So
the
idea
would
be
to
take
this
functionality
and
we're
probably
going
to
have
to
figure
out
some
way
to
do
a
migration
of
some
sort
from
where
it's
at
now,
but
where
we
wanted
to
end
up
is
as
a
scan
result
policy
so
that
you
can
go
in
and
say
if
a
scan
finds
x,
number
of
critical
vulnerabilities.
This
would
be
the
this
would
be
the
vulnerability
check
piece
you
know,
then
I
want
to
add.
A
An
action
here
require
approval
from
one
or
more
individuals,
and
presumably
there
would
be
somewhere
in
the
product
that
you
can
pre-define.
These
approval
groups
basically
say
this
set
of
users
can
has
the
authority
to
approve
these
license
checks?
It
may
be
a
legal
department,
it
may
be
the
application
security
team
and
maybe
both
but
you're,
able
to
go
in
and
require
approval
from
them,
and
then
the
same
would
be
true
if
it
was
a
licensed
compliance
scan.
A
You
know
if
you
find
one
or
more
of
these
licenses,
or
perhaps
we
change
this
to
match
the
current
functionality
of
just
you
know
any
license.
That
was
on
the
not
approved
list,
so
it
would
be
taking
that
and
moving
it
here
and
then
also
providing
this
at
the
group
and
workspace
level.
So
that
would
be
that
person's
sole
focus.