►
From YouTube: OMR Architecture Meeting 20191212
Description
Agenda:
* OMR component testing ideas and plans for 2020 [ @smlambert ]
B
Okay,
welcome
everyone
to
this
week's
Omar
architecture.
Meeting.
This
is
likely
our
last
meeting
of
the
year
and
on
the
agenda.
For
today
we
have
one
topic:
Shelley
Lambert
will
be
talking
about
some
ideas.
She
has
for
testing
the
various
Omar
components
and
some
of
the
things
that
she
like
to
get
done
in
2020,
so
I'll
turn
it
over
to
Shelley
great.
C
C
The
benefit
of
everyone.
I
guess
I'd
also
like
to
go
back
in
time
briefly
back
to
2:14,
to
explain
why
things
are
the
way
to
where
those
of
people
on
the
project
that
look
at
FB
test
ago.
Why
and
how
it
all
started
so
I'm
gonna
just
dive
right
in
trying
to
quickly
cover
just
a
bit
of
the
background
of
the
QA
prep
work
that
happened
as
the
Omar
project
was
open
sourced.
C
Really
what
I
think
the
goals
of
a
QA
effort
in
this
open
project
are,
in
my
opinion.
Hopefully,
everyone
agrees,
or
at
least
has
input
and
feedback
and
a
specific
list
of
things
that
I
I'd
like
to
get
to
in
2020,
and
it's
a
pretty
modest
list,
because
I,
the
team
is
kind
of
spread
thinly
across
many
open-source
projects.
So
I
went
for
the
realistic
view
at
that
list,
but
obviously,
if
we
got
through
all
of
it
in
the
middle
of
the
year,
start
we'd
start
adding
more
stuff.
C
C
C
So
obviously,
framework
community
to
be
integrated
into
Omar
source.
Actually,
this
isn't
completely
true.
This
is
true
right
now,
because
how
it
is
necessarily
run
on
z/os
and
how
there
was
some
kind
of
hinky
changes
that
needed
to
happened
to
run
on
that
platform.
I
think
we
could
revisit
this
too,
but
I
didn't.
A
C
A
C
C
You
could
pick
and
choose
which
sub
components
I'm,
not
sure
that
that's
true
today,
but
at
the
time
that
was
what
was
being
said.
So
we
wanted
to
make
sure
that
the
unit
tests
were
separated
out
by
component
in
case
someone
only
needed
to
run
a
certain
set
of
tests,
only
picking
those
up,
so
we
just
stuck
with
that
kind
of
organization.
C
Again
that
can't
be
now
revisited.
I
know,
there's
an
open
issue
around
reorganizing
and
renaming
way.
Tests
are
laid
out
and
I
want
to
be
part
of
that
conversation
also
for
a
lot
of
the
components,
use
combinatorial
test
design,
mostly
with
the
development
teams
on
this,
for
some
of
the
components.
I'll
say
that
some
other
components
like
port
and
thread
components,
since
we
were
trying
to
go
very
quickly
with
very
few
resources.
C
What
we
did
with
those
was
essentially
just
make
sure
we
had
functional
coverage
with
the
existing
tests
that
we
had
from
our
internal
repos.
So
people
remember
port
tests
and
thread
tests
executive.
All's
that
we
used
to
run
those
essentially
got
very
quickly,
not
in
a
very
clean
way,
over
into
the
Google
test
framework
to
be
run
into
Omar.
C
And
I
guess
I
just
mentioned
this
here
on
the
upside.
The
wrasse
component
was
modeled
quite
thoroughly
back
when
Angela
was
part
of
that
team
very
closely
yeah,
we
actually
a
very
interesting
way
of
being
able
to
write
any
tests.
We
did
again
I'm
gonna
work
with
closely
with
Robin,
Andrew
and
others
around
this.
Hopefully
this
year,
right
now,
the
way
we
have
some
of
the
testing
for
DC
is
you?
Cannot
you
actually
create
configuration
files
that
you
can
feed
in
and
it
will?
C
C
On
that
component,
okay,
oh
okay,
so
the
the
implementation
part
was
make
sure
we
had
some
sort
of
structure
and
naming
approach
again.
That
can
be
revisited
at
any
point,
but
we
needed
something
we
identified
which
of
the
existing
tests.
We
had
that
could
be
reused.
We
ported
the
reusable
test
into
the
Google
test
framework
and
then
we
wrote
a
bunch
of
new
tests
where
there
were
gaps
and
then
that
all
was
done
prior
to
open
sourcing
and
all
came
in
as
one
giant
directory
into
the
project.
C
Okay,
so
that's
the
past
when
I
think
of
what
are
the
goals
of
QA
in
the
nomar
project.
Why
are
we
testing
all
of
our
code?
Obviously
one
of
the
big
reasons
to
find
defects
to
ensure
that
things
functionally
correct.
But
there
are
other
reasons
one
would
want
to
actually
test
code,
which
is
why
I
want
to
come
back
to
that
whole
test
story.
C
The
other
real
goal
of
a
QA
team
and
a
QA
effort
should
be
to
support
developers
so
make
it
easy
run.
Testing
make
sure
testing
has
a
covers,
the
things
that
the
development
team
are
most
concerned
about
or
feel
that
there's
most
risk
around.
We
very
limited
resources.
We
want
to
make
sure
that
we're
paying
attention
to
the
things
that
the
development
team
feels
needs
the
most
attention
about.
The
only
right
approach
here
build
confidence,
so
people
can
innovate
and
deliver
more
quickly
without
worry
and
then.
C
C
Here,
so
this
is
the
website
right
now,
if
you
go
under
testing,
so
obviously
I'd
like
to
get
some
more
stuff
in
around
this
piece.
If
we
go
into
the
repo
there's
zero
readings
right
now,
we
actually
I
believe
you
can
began
this
work
and
never
get
it
delivered
to
the
project.
So
there
are
marshal
Reid
knees
that
I
can
contribute
already,
but
I
will
revisit
everything
because
there's
probably
a
lot
of
stale
information,
then
we
have,
of
course,
the
review
of
the
portal
living
thread
load
test.
This
is
where
I.
C
Actually
we
left
off
with
this
piece
was
that
there
wasn't
full
coverage
I'd
like
to
see
coverage
on
every
piece
of
these
api's
if
possible,
rerunning
some
of
the
code
coverage
stuff
looking
at
the
existing
set
I
think
there's
also
an
opportunity
here
all
the
tests.
The
thorough
review
of
this
these
tests
would
be
the
next
item
on
the
list.
C
C
Believe
they
only
include
the
some
GC
tests
and
there
again
using
the
configuration
based
testing
that
we
have,
and
these
ones
actually
are
pulling
quite
a
large
object
model
and
running
them
running
through
them.
They
use
the
verbose
GC
logs,
then
to
verify
did.
Did
we
actually
achieve
what
we
set
out
in
the
test
itself
in
the
timeframe
that
was
expected
or
what
I
should
say?
Is
we
output
a
bunch
of
metrics
and
the
piece
that's
missing
here
and
that
we
had
prototyped
internally?
Was
let's
track
it
over
time?
C
We
call
it
test
results
summary
service,
it's
an
open
source
project
that
we're
using
heavily
to
monitor
test
results
from
other
Jenkins
servers
and
it
doesn't
matter
what
Jenkins
job
you
running.
It's
easy
to
add
parsers
to
this
service,
so
we'll
be
able
to
add
a
parser
to
parse,
Google,
benchmark
performance
output
and
show
that
in
a
graphical
way
or
at
least
store
stuff
overtime.
So
T
RSS
has
a
MongoDB
on
the
back
end
and
we
can
store
a
lot
of
data
over
time
and
show
show
trend
over
time.
C
Gc
tests
that
we
have
I
think
there's
only
a
couple
in
there,
but
I
will
also
start
a
discussion
about
other
the
other
components
to
see
what
other
things
could
we
actually
measure?
So,
maybe
there's
something
on
the
threading
side
that
could
be
measured.
What
metrics
would
be
interesting.
I
looked
when
we
began
this
project
in
2014
we
had
looked
at
LLVM
and
it
was
testing.
They
had
was
very
preliminary
very,
very
slight
at
that
we're
looking
now
there's
a
lot
of
performance
benchmarks
that
they
have
in
their
project.
C
So
I
think
I'd
like
to
more
closely
revisit
what
other
projects
are
doing
similar,
maybe
to
this
project
and
make
a
call
and
can
we
can
we
come
at
this
with
new
approach,
knowing
what
we
know?
Okay,
so
the
other
thing
I'd
like
to
look
at
again.
This
is
in
the
least
defined
category.
Ten
of
these
last
two
things
on
the
bottom:
the
GC
testing.
C
Right
now,
those
config
files
can
actually
be
populated
by
real
object
models
pulled
out,
of
course,
and
at
the
time
we
had
Java
core
Reader
and
we
still
do
and
I'd
like
to
get
it
into
source
control
somewhere.
But
I
also
want
to
look
at.
Do
we
have
other
for
this
project?
Are
there
other
languages
or
upstream
projects
that
have
a
similar
thing?
When
things
crash,
can
we
look
at
the
artifacts
of
back
and
draw
from
that
to
create
new
tests?
C
So
that
would
be
one
piece
and
then,
in
terms
of
continuing
from
you
know,
existing
issues
where
crashes
occurred.
We
could
look
at
those
to
see
if
there's
anything
interesting.
What
we
found
with
this
reader
is.
We
can
write
these
config
files
by
hand
and
create
an
object
model
in
them,
but
they're,
never
quite
as
interestingly
shaped
as
when
we
take
the
object
model
out
of
one
of
these
dramatic
crashes
from
from
users.
C
So
we
learned
quite
a
bit
when
we
started
to
use
these
oddly
shaped
models
from
real
world
use
cases
right
and
then
finally
kind
of
the
very
end-
and
this
was
has
been
a
conversation.
I've
had
with
a
few
people
that
are
on
this
wall
already
today.
Can
we
define
some
test
mechanisms
that
help
kind
of
protect
Omar
developers
and
other
projects
that
I'm
helping
out
in
the
QA
side,
so
I'm
going
to
take
an
example
from
another
project,
so
adopt
open,
JDK
producing
JDK
binaries.
C
The
upstream
projects
of
that
would
be
large
java
application
communities
that
would
consume
the
ax
binaries,
but
in
our
in
our
actual
QA
effort
we
include
some
of
those
upstream
functional
Suites
and
application
Suites,
and
we
run
them
on
a
regular
basis
to
make
sure
things
don't
fall
over
now.
That's
pretty
heavyweight
if
you
have
limited
set
of
resources,
but
is
there
something
similar
that
we
could
do
in
a
more
light
fashion?
So
we
just
as
a
note
we
used
to
reminisce
these
high
level
testing
off
for
Omar.
C
In
the
past
we
had
actual
Ruby
Python
and
Java
tests
really,
but
this
wouldn't
be
the
only
thing
we
could
do
here.
I
just
this
is
why
this
is
the
last
bullet
point
here,
the
least
defined
and
probably
the
hardest
one
to
do
correctly.
I
think
we
talked
even
about
how
upstream
projects
could
there
could
be
a
subscription
model?
There
could
be
kind
of
relationships
with
projects
so
that
you
could
connect.
C
Through
QA
so
back
to
the
goals,
and
how
do
we
grow
interest
or
participation
in
the
project?
So,
while
I
don't
have
this
very
well
defined
here?
Do
you
want
to
kind
of
approach
this
in
2020
and
figure
out
at
least
the
first
steps
to
that?
Okay
and
by
the
way,
just
for
fun,
based
on
that
high-level
view?
This
was
the
diagram
back
in
2014
talking
about
testing
and
how
we
would
have
the
component
testing
down
in
the
language
agnostic,
clear.
C
But
if
you
attach
the
slides
to
that,
the
agenda
issue
for
people
to
take
a
look
at
also
will
be
doing
a
little
bit
more
investigation
on
some
other
projects
too,
to
see
what
we
can
glean
from
our
approach
or
how,
where
we
can
grow
from
our
approach.
So
I'll
leave
those
in
here,
but
those
are
from
the
past
or
other
sources.
And
so
finally,
just
in
summary,
I
think
my
in
my
opinion,
the
QA
approach
or
the
QA
approach,
I'm
gonna
take
in
this
project
will
be
addressed.
C
I
have
recently
refreshed
my
fork
of
and
started
building
and
running
tests
again,
but
I
didn't
get
as
far
as
being
able
to
set
up
Jenkins
job
for
the
perfect
test,
so
that
I
could
show
things
and
what
that
Google
test
output
looks
like
okay
get
to
that
within
January
time
frame.
Did
anyone
have
questions
or
hope
for
more?
You
might
notice
that
JIT
test
I've
left
off
my
list
of
specific
test
enhancements.
I
was
looking
at
areas
of
the
project
didn't
have
as
much
activity.
I.
C
B
Actually,
just
you
mentioned
the
the
JIT
testing
I
guess
about
a
year
ago,
last
November
2018
I
think
we
had
a
discussion
of
this
architecture,
meeting
about
trill
and
I,
guess
sort
of
the
directions
of
it
and
wish
lists,
and
that
sort
of
thing.
So
there
is
an
issue.
That's
that
was
created
that
sort
of
outlines
a
lot
of
these
pieces
of
work
that
we
wanted
to
take
trill
I,
don't
think.
We've
made
huge
progress
on
some
of
those
fronts,
but
where
we're
not
standing
still,
but
it's
just.
C
Remember
issue
I
should
have
put
it
on,
maybe
revise
my
slides
to
put
it
in
because
it
looked
like
a
wonderful
list.
I
know
that
oh
and
Leo
has
made
some
progress
on
even
portability
and
and
some
recent
stuff
that
has
happened
this
past
term
and
it's
work
so
yeah
I
I
don't
mean
to
not
have
it
on
the
list,
because
it's
not
important
I
just
it
seemed
that
other
people
were
already
carrying
that
forward.
A
little
things
neglected.
B
C
Actually,
a
really
sweet
plugin,
so
you
need
Google
tests
to
be
able
to
use
the
benchmark
portion
and
yeah.
It
is
actually
just
a
wrapper
you.
So
it's
quite
easy.
It's
just
like
Google
tests
where
you'd
wrap
or
you
did
include
a
certain
header
and
you
grab
your
your
test
with
certain
says
here:
there's
a
lot
of
great
documentation
for
it
already
and
I.
Guess
one
of
the
other
interesting
things
a
couple
of
the
other
interesting
things
I
like
about
it
are
that
you
can
vary
what
type
of
output
it
produces.
C
So
it
has
a
pretty
print
to
the
console
if
you're
just
running
it
directly,
but
it
can
produce
JSON
and
CSV
or
being
able
to
feed
into
other
systems,
and
so
it
seems
very
nice.
It
is
what
L
then
uses
for
their
inch
marking
pieces
as
well.
It's
pretty
it's
pretty
well
used
out,
you
know
out
in
the
world,
so
there
are
other
tools
that
you
could
consider
taking
advantage
of.
If
you
use
this
and
since
we
were
already
using
Google
test,
it
plugs
in
fairly
nicely,
it
seemed
like
right.
C
So
I
guess
anyone
can
just
go
to
this
go
here
and
take
a
look
but
I'll
try
to
actually
get
a
creative
fork
can
do
some
simple
experiments
and
Brown
just
so.
People
can
take
a
look
at
what
it
would
look,
what
the
flow
might
look
like.
So
if
we
have
benchmarks
benchmark
testing,
I
presume
the
flow
of
that
could
be
that
we
run
those
in
a
separate
job
in
Jenkins
in
a
record
then
or
some
other
tool.
If
you
choose
something
else,
can
monitor
those
builds
and
store
the
stuff
over
time.
C
So
you
can
start
to
see
trends
and
in
you
may
or
may
not
want
that
as
part
of
a
pull
request,
a
build
I,
don't
that
you
would
want
it
as
part
of
a
poll
request
build,
but
I
know
at
the
moment
that
current
set
of
tests
sitting
there,
the
small
set,
doesn't
take
any
time
to
run
this.
In
my
mind,
this
is
a
separate
job
that
runs
weekly
or.
F
C
B
C
D
C
And
even
I,
you
know
for
what
we
started
using
t
RSS,
also
for
how
we
can
you
can
create
alerts.
Essentially,
so
one
of
the
things
we
now
watch
for
are
what's
the
execution
time
of
any
one
of
the
functional
test
Suites
if
it
goes
up
by
an
unexpected
amount
and
make
an
alert
to
both
that
I,
don't
know
if
that
that
ever
happens
in
the
very
fast
running
function,
som
är
but
or
if
it
would
be
meaningful,
but
it
certainly
happens
at
the
job.
C
B
B
C
C
B
C
Had
used,
we
had
used
G
cup
in
the
past,
of
course,
now
everything's
seeming
so
I,
don't
know
if
it's
gonna
be
easier
or
more
difficult
for
that.
One
of
the
other
things
is:
there's
lots
of
tools
out
there.
Now
we
played
around
with
them
or
some
of
the
other
projects
where
you
could
actually
run
coverage
as
part
of
a
pull
request.
So
it
gives
you
a
visual
indicator
of
your
current
coverage.
C
We
could
look
at
doing
that
for
the
project,
but
for
now
I
was
just
gonna
stay,
very
simple,
reproduce
kind
of
the
thing
we
had
before
and
come
through
your
numbers.
Later
we
could
add
some
bells
and
whistles
and
see,
but
I
don't
know
that
you
know.
Maybe
you
can
tell
me
this
answer
this
question.
Essentially,
if
there's
a
new
feature
going
into
Omar,
are
you
likely
see
it
going
in
without
any
testing?
C
B
A
There's,
like
trail
I,
think
is
one
component,
but
ultimately
even
trilled
by
itself
will
not
be
enough,
because
there's
there's
a
lot
of
parts
that
I'm
not
even
sure
it
will
make
sense
to
try
to
represent
and
trill.
It's
really.
It's
kind
of
really
just
about
materializing
il
from
a
string
without
having
to
go
through
on
some
intermediate
bytecode,
so
I
think
there's
definitely
improvements
that
can
go
into
trill,
but
there's
more
work,
even
just
in
the
compiler
itself.
C
C
B
A
huge
proportion
of
PRS
I'm
not
trying
to
say
that
other
components
are
not
updating,
but
there
are
a
lot
of
PRS
mating
is
the
compiler
component
in
Omar?
If
you
look
at
the
distribution
of
the
components
that
pull
requests
are
made
against,
Pilar
is
certainly
right
up
there
in
terms
of
the
number
of
changes
being
submitted,
so
so.
C
Be
this
should
it
probably
then
needs
us
to
raise
that
in
priority,
because
I
think
I
mean
obviously
I
wanna.
One
of
the
goals
is
to
de-risk
the
dev
team
and
the
project.
So
if
that
that
is
actually
the
case,
where
there's
a
lot
more
changes
happening,
I
probably
need
to
come
back
and
throw
some
things
onto
this
2020
list
or
at
least
get
that
started
well.
E
B
B
E
C
C
C
A
F
B
Not
so
much
a
question
and
I,
don't
think
it's
even
necessarily
that
something
that
needs
that
Shelley
specifically
needs
to
think
about,
but
one
of
the
things
but
I've
become
more
aware
of
having
worked
with
the
owl
projects,
but
the
side
project
that
happened
and
various
other
things
is
that
we
now
have
a
number
of
what
we
have
more
downstream
consumers
of
OMR
right.
We
have
llj
B.
We
have
opened
a
nine.
Of
course.
We
have
plasm
the
wise,
and
yet
we've
got
several
other
dams
bigger
than
J.
B
We've
got
Ravi
right,
there's
a
bunch
of
stuff.
Now
one
of
the
things
one
of
the
things
that
I'm
I'm
growing
more
concerned
about
is
that
when
we're
doing
changes
in
the
compiler,
especially
to
api's
and
as
we
start
to
try
to
evolve
toward
some
kind
of
API
stability
or
we're
looking
at
doing
API
refactoring
even
after
we
declare
alpha
stability
whatever.
B
That
means
right
that
there's
not
a
very
easy
way
at
the
moment,
or
somebody
sitting
in
Omar
to
know
which
dependence
which,
which
downstream
projects
I
just
break
yeah,
am
I
going
to
break
like
who
do
I
need
to
go
and
talk
to
and/or,
be
nice
to
and
or
go
and
help
with
whatever
it
is
that
I'm
doing,
and
there
isn't
really
a
pathway
that
I
see
at
the
moment
in
how
we're
talking
about
testing
or
anything
like
this.
That
would
help
alleviate
that
problem
now.
B
I
would
certainly
not
advocate
bringing
in
those
sub-projects
tests
directly
into
Omar,
like
that,
doesn't
make
any
sense,
but
if
there
were
a
way
for
these
projects
to
register
I,
don't
know
a
one
or
two
tests
or
a
way
like
a
script
or
something
that
there's
not
only
has
some
ideas
on
yeah.
It's
what
you
think.
If
you
a
dead-on-arrival
kind
of
thing
like
just
the
minimal,
does
it
compile?
Does
it
start
right?
Does
it
run
data
here
or
whatever.
C
Not
print
and
the
higher-level
projects
so
from
that
again
using
the
example.
It
is
slightly
obviously,
because
there
may
be
mechanism
may
may
need
to
be
more
gated,
but
for
the
hire
little
project
there's
two
ways:
we
connect
to
make
sure:
either
we
don't
break
them
or
they
don't
break,
get
broken
because
of
something.
So
though,
the
one
way
is
to
actually
take
a
small
set
of
stuff
into
the
project
and
run
it
regularly,
because
that's
easy
to
do
it
just
needs
resources.
C
Now
you
could
be
more
careful
and
say:
I,
don't
want
to
run
the
full
suite
of
their
tests.
I
want
to
I,
want
to
measure
and
look
at
where
we
normally
break
and
just
pick
a
very
smart
set
or
look
at
what
has
changed
and
determine
in
a
smarter
way
what
tests
out
of
those
higher-level
ones
to
run
or
those
consumers,
but
the
other
the
other
way
we
do
it
or
we're
going
to
start
to
do
it
is
at
the
high
level
part
of
the
adopt
project.
C
C
Subscription
model
that
we
could
open
place
that
says
anything
on
how
these
consumer
projects
are
picking
you
up.
Can
we
actually
we
make
it
dead,
easy
for
them
to
run
a
set
of
tests?
Then
we
can
monitor
and
know
oh
yeah.
Here
we
go
so
it's
owned
in
their.
You
know
in
their
servers
or
CI
setup,
but
we
actually
can
relate
it
back
to
everybody.
I,
don't
know,
I
know
how
to
do
it
at
the
higher
level
projects.
I
want
to
now
that
you
just
said
a
long
list
of
these
projects.
B
If
we
realize
that
we're
doing
something
that
is
going
to
affect
people
down
stream,
we
try
to
tell
the
people
down
the
stream
and
do
the
change
in
a
more
collaborative
manner
right.
If
your
head
is
following
something
close
to
our
head.
Let's
work
together
to
try
and
not
break
you
and
then
knowing
the
set
of
people
that
you
might
need
to
talk
to
I
think
it
is
a
challenge
right
because,
like
as
any
one
developer,
who's
working
on
Omar
and
probably
one
or
more
downstream
projects,
you're
not
going
to
know
all
the
projects.
B
C
Exactly
but
you
might
care
about
some
a
great
deal
so
the
way
we
did
it.
You
there's
no
way,
there's
no
way.
In
this
example.
For
me
to
run
every
Java
applications
functional
suite,
there
are
some
Java
applications
functional
sweets
that
we
really
care
about
because
they
exercise
a
whole
lot
of
stuff,
so
I'm
thinking
of
it
from
some.
What
helps
me
at
this
project
is
to
select
some
of
these
consumers
and
include
them
in
our
own
stuff
else.
C
C
C
G
D
D
C
Definitely
definitely
interest
not
or
did
it
go
here
here
hopefully
captured
this.
There
were
some
ideas
back
early
on
when
we
were
starting.
Some
of
that
work
with
working
with
the
JIT
team,
with
you
in
particular
that
I
haven't
paid
attention
where
we're
at
with
it,
the
notion
of
being
able
to
read
back
in
things
and
obviously
trill
and
all
this
other
stuff
has
a
long
way,
but
I
think
there
were
lots
of
other
things
on
the
list
at
the
time
we
were
talking
about
this
I'm
absolutely
interested
to
come
back
into
this.
C
As
you
know,
we
also
have
the
ASP
project
deep
Smith
project
as
well,
and
we
take
that
same
approach
and
apply
deep
learning
to
generate
IL
or
something
else
again.
I
also
want
to
take
a
look
at
probably
what
are
them,
because
I
think
different
DBMS
and
implementations
have
different
approaches
to
this.
C
C
C
B
C
B
C
But
it,
but
if
sir,
but
if
folks,
are
keen
to
work
directly
together
on
stuff
up
reach
out
out
to
me
and
I,
will
create
an
epic
in
the
in
the
project
and
I.
Think
I
mean
I.
Have
this
on
my
regular
schedule
now,
unless
it
conflicts
I'll
be
joining.
This
call
regularly
work.
Okay,
great
those
folks
thanks
everyone
thanks
so
much.