►
From YouTube: 2022-04-12 Compliance Weekly
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
Hello:
everyone
welcome
to
the
tuesday
april
12th
compliance
weekly.
This
is
our
first
week
of
a
more
sort
of
european
friendly
time.
So,
let's
start
on
what
the
board,
let
me
show
my
screen.
A
Okay,
so
let's
go
through
the
billboard.
Can
you
see
that
all
right
cool
all
right?
So
no
rub
this
week.
Josefa
you've
got
all
the
other
priority.
One
issues
if
you
want
to
walk
through
those.
B
So
we're
working
on
the
feature
to
add
like
in
delete
the
inactive
projects
inside
those
issues.
We
have
these
three
issues.
The
first
one
was
to
actually
add
the
settings
to
the
app
like
the
columns
to
the
application
settings
table.
This
is
now
mwps.
So
I'll
just
move
this
to
verification.
B
Now,
the
next
yeah
you
can
just
update
the
label
if
you
want
the
other
one
is
to
actually
create
a
method
to
determine
if
a
project
is
inactive
or
not,
which
is
the
last
issue
in
this
column,
the
last
one.
So
this
this
one
is
also
like
almost
done.
Workflowing
dot
I'll
just
have
to
create
an
mr
and
then
push
this
to
review
and
then
I'll
start
working
on
the
the
main
issue,
which
is
adding
the
feature
itself.
A
Awesome
nice
one
priority:
two,
that's
just
me
so
the
first
mr,
which
allows
us
to
override
the
created
attributes
and
an
audit
event
has
now
been
merged.
I'm
going
to
verify
that
well
this
morning,
hopefully,
and
then
I
can
work
on
actually
fixing
the
events
that
are
being
saved
at
the
incorrect
time,
we're
pretty
close
to
the
end
of
the
milestone.
So
I
don't
know
if
I'll
get
that
finished,
but
it
won't
be
far
behind
in
the
next
milestone.
A
If
not,
since
we've
got
a
pretty
light
agenda,
we
can
cover
priority
three
and
four
as
well
so
house
margin
will
walk
through
yours.
C
Yeah
so
for
the
add,
merge
request,
settings
changes,
part
one
so
actually
the
mr
got
merged,
but
we
have
to
revert
it
because
end
to
end
test
case
was
failing
for
it.
So
for
now
I
have
fixed
that
case
and
again
push
the
mr
for
review
so
currently
waiting
for
maintainer
review
on
it
and
for
the
second
one
delayed
group
duration,
application
setting.
So
it's
in
review,
but
I
got
to
know
that
we
have
to
run
a
migration
pipeline
before.
A
C
B
A
That
okay,
right,
we'll
leave
that
with
dennis
for
now
awesome
priority
four
one's
assigned
to
rob
and
one's
unassigned
or
an
order,
event
fix,
and
if
either
of
you
have
time
to
pick
this
up
feel
free.
Otherwise
it
can
roll
over
this
one
doesn't
have
a
priority.
Probably
should
this
is
to
refactor
some
of
the
code
to
make
it
so
that
you
can
only
assign
component
frameworks
to
group
namespaces
rather
than
using
namespaces
for
now
now
who's.
A
for.
A
Thank
you
for
your
initial
review,
I'm
working
through
those
failing
specs
now
so,
hopefully
we
can
get
that
into
maintaining
review
by
the
end
of
today.
Awesome
anything
else.
Anyone
wanted
to
cover
on
the
billboard.
A
C
Yeah,
so
this
is
managed
group
order
close
to
spec.
So
basically,
this
is
the
end-to-end
test
case,
which
was
failing.
So
we
have
reverted
the
mr
and
now
it's
closed.
A
Awesome
always
good
fantastic.
Okay,
that's
the
billboard!
Next
is
refinement
board.
I
don't
think
there's
a
lot
here.
There's
none
assigned
except
to
yarn,
there's
a
couple
of
top
priorities.
So
if
anyone
gets
the
chance
to
look
at
these
two
feel
free,
but
they're
not
assigned
yet.
So
it's
not
a
priority,
see
what
we've
got,
though
options
to
enable
pipelines
must
succeed
at
group
level.
A
Oh,
so
that's
enforcing
group
level
option
it
could
be
interesting
and
the
other
one
an
api
for
sha
specific
chain
of
custody
reports.
So
this,
I
think,
is
just
adding
an
api
for
an
existing
feature
which
I'll
click
on
once
the
zoom
thing
disappears.
There
we
go.
This
is
quite
an
old
issue
now,
so
it
might
require
a
bit
of
time
to
really
dig
into
it
looks
like
it
was
rest
specific
as
well.
Obviously
we
tend
to
focus
on
graphql
first
yeah,
okay,
awesome!
B
A
Okay,
wonderful
anything
else,
don't
talk
about
release
post
blockers.
I
actually
know
probably
do
because
it's
the
last
weekly
of
the
milestone.
But
let's
see
if
there's
anything
obvious,
might
be
tricky
without
sam.
So
new,
streaming
audit
events
for
get
actions,
that's
ready.
A
So
hopefully,
that
will
be
fixed
by
the
end
of
the
milestone.
Yes,
sure,
release
post
for
compliance
report,
individual
violation,
reporting
where
we
got
to
this.
A
But
it
doesn't
have
the
ready
label
I'm
trying
to
see
if
there's
anything
weird
engineers
can
do
to
speed
this
up.
I'm
not
sure.
A
B
This
this
was
released
in
the
previous
milestone,
but
we
missed
adding
the
release
post
so
when
sam
sanker
got
back,
he
just
created
this
release
post.
So
it's
right.
It's
a
late
release.
A
Post,
okay,
that's
fine,
but
it
looks
like
it's
ready
to
go.
At
least
it
should
be
yes,
great,
no
blockers
there.
We
go
for
merge,
method
enforcement.
A
Yeah,
this
isn't
going
to
make
it
there's
still
open
questions.
It's
community
contribution,
so
that's
going
to
remain
blocked
and
unlikely
to
make
1410
for
now,
but
we'll
discuss
that.
A
Yeah,
it's
not
gonna
make
1410,
I
wouldn't
have
thought
so
we
can
discuss
that.
Async,
awesome,
okay,
review
the
priorities
list
as
well.
I
don't
think
much
has
changed.
A
I
don't
know
if
sam
kerr
was
talking
about
possibly
not
using
this
in
the
future
anyway,
yeah
anything.
Everyone
wants
to
add
here.
B
I
know
I
mean
I
already
mentioned
in
the
last
compliance
weekly
that
the
sixth
point
over
here-
the
improving
the
auditability.
This
will
definitely
not
make
in
1410,
okay-
and
I
guess
dennis
mentioned
that
we
haven't
that
we
haven't
updated
this
issue
in
a
couple
of
weeks
like
this.
So.
C
And
also
for
the
point
four,
because
we
had
to
reward
the
original.
Mr
now,
both
the
emers
are
in
review,
but
I
have
somewhat
low
confidence
on
it.
A
Discuss
async
about
the
best
way
to
deal
with
priorities
on
a
weekly
basis
because
yeah,
I
think
this
is
falling
out
of
out
of
favor
slightly
that's
fine.
Okay,
anything
else
want
to
discuss
nice
and
quick
this
week.
B
I
just
had
like
a
generic
question
outside
the
blinds
weekly,
how
how
do
we
go
about
like
creating
mrs,
like
big,
mrs
and
then
we
just
distribute
them
into
like
feature
branches,
and
then
how
do
we
go
about
like
reviewing
those
feature
branches?
So,
for
example,
I
create
a
small
like
small
piece
of
code
in
feature
like
feature
branch
a
then
I
check
out
a
new
branch
from
feature
a
as
feature
b
and
then
like
add
some
other
small
parts
of
code,
so
feature
is
created
against
master.
B
So
reviewing
that
is
easy,
but
creating
feature
b
would
be
like
against
feature
is
so
how
do
we
go
about
review?
Like
do
we
add
a
note
to
the
reviewers
that
this
this,
mr,
is
not
created
against
the
master
branch
and
is
created
against
feature
a
and
if
we,
if
you
make
any
changes
to
feature
branches,
we'll
like
update
this
one
as
well
rebase,
so.
A
Yeah,
I
don't
know
if
there's
any
specific
method.
The
way
I've
done
it
in
the
past
is
if
I've
opened
them
both
at
the
same
time,
then,
mr
a
would
target
master
and
mrb
would
target
mra.
A
If
we
want
to
review
them
simultaneously,
because
then
you
can
see
the
the
differences,
it
sometimes
helps
as
well
to
use
the
same
reviewer.
So
they
understand
the
context
but
yeah
you
do
have
the
problem
that
if
you
make
changes
to
a
you'll
need
to
rebase
a
onto
b,
which
can
get
a
bit
confusing.
A
I
don't
know
if
there's
a
better
way
to
do
it,
but
yeah
that's
what
I've
done
in
the
past.
You
can
use
mr
dependencies
as
well
to
make
sure
that
one
doesn't
get
merged
without
the
other,
but
other
than
that.
I
don't
know
if
there's
a
better
way
to
do
it
or
you
know
a
gitlab
specific
way
that
we've
done
it
in
the
past.
A
Awesome
well,
if
there's
nothing
else,
we
can.
We
can
end
early
asmr
anything.
You
would
like
to
add.