►
From YouTube: 2021-08-19 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).
C
A
C
So,
do
you
play
a
lot
of
like
kind
of
like
rpg
funny
games,
yeah,
yeah.
F
C
Yeah
hi
everybody
yeah,
so
we
were
kind
we
kind
of
like
kept
progressing
in
the
log
exporter
frontier.
So
I
wrote
some.
I
wrote.
Actually
the
log
adapter
class
kind
of
had
some
problems
with
the
with
the
gradle
builds
and
recognition
of
files,
but
I
got
got
it
under
control
and
and
now
we
have
a
pr,
we
have
actually
a
question
about
which
is
exactly
how
it's
written
here.
The
first
question
about
the
logia
exporter
implementation.
C
So
we
wanted
to
like
me
and
ohad
which
which
didn't
come
here
and
today,
but
basically
we
wanted
to
ask
what
do
you
think
about
like
what
is
the
preferred
way
to
implement
the
exporter
in
terms
of
like
the
actual
like
export
functionality?
Should
we
use
some
sort
of
like
a
many
channel
or
like
a
stub
like
the
grpc
implementation,
that
they
saw,
for
example
in
the
in
other
exporters,
in
the
jrpc
spam
exporters,
or
should
we
maybe
use
some
url
or
some
of
some
sort
and
then
maybe
maybe
later
on
you?
A
Think
the
answer
is
yes,
what
you
have
what
you
have
described
as
three
different
exporter
implementations
and
I
think
we're
going
to
want
all
of
them.
Okay.
So
so,
if
you
look
right
now,
we
have
in
the
main
repo
for
tracing.
We
have
the
grpc
exporter.
We
have
the
http
protobuf
exporter.
A
We
have
a
logging
exporter
that
will
dump
otlp
out
as
a
log.
A
log
entry
there's
been
talk
about
an
http
json
exporter,
but
it's
unlikely
that
we'll
build
that
unless
somebody
donates
it
so
having
as
many
modalities
to
get
the
data
to
the
user
as
possible
is
going
to
be
good,
so
I
think
we
generally
have
considered
the
grpc
protobuf
exporter
as
the
primary
one,
but
not
for
not
for
any
great
reason,
just
because
that's
kind
of
what
got
built
first
so
having,
I
think,
having
http
protobuf.
A
I
think
you
missed
that
one
drastic,
your
notes,
hdb
protobuf,
is
actually
also
a
really
fantastic
option.
There
are
definitely
we've
definitely
had
users
who
don't
want
to
be
using
grpc
would
rather
use
http,
but
still
won't
be
able
to
send
sending
proto
is
still
yeah.
Yeah.
C
And
you
said
there
are
examples
for
for
like
the
this
kind
of
implementation
of
the
http
protobuf
in
the
open
intellectual
java
report.
Yes,
we
have.
We.
A
Okay,
recently
jack
actually
was
on
the
call
donated
and
did
implemented
the
http
protocol
exporter
for
us
so
okay,
and
that
is
there
and
as
of
1.5,
I
think
it's
actually
being
published
as
an
official
exporter
as
well.
D
C
A
What
I
would
do
I
would
I
would
pick
one
I
mean
you
might
even
just
pick
the
logging
one
first,
because
it's
going
to
be
the
absolute
simplest,
it's
kind
of
weird
to
have
a
logging
exporter
that
just
logs
again,
but
it
still
would
be
a
good
exercise,
at
least
to
to
just
get
a
feel
for
writing
an
exporter,
and
you
know
managing
the
protobots.
A
C
We
actually
thought
about
just
slogging
it,
but
it
sounded
a
bit
silly,
as
you
said
so
yeah,
but
we
will
start
moving
stuff
in
this
direction
and
it's
good
to
know
that
we
can
implement
all
of
those
options
and
probably
when
we
will
get
to
actually
like
trying
to
initiate
the
pull
requests
and
stuff
like
that.
I
might
like
want
to
like
use.
One
of
you
guys
have.
C
Maybe
you
just
like
understand
how
the
flows
works
and
he's
working
like
in
in
terms
of
like
the
prs
and
stuff,
but
it
will
take
some
time
yeah
yeah.
So
this
is
even.
C
So
you
can
actually
see
like
the
the
the
log
is
adapting
to
like
is
like
converting
to
the
protobuf
yeah
cool
so
and
about
like
the
the
prs
I
guess
like.
If
we
have
one
tracking
issue
like
the
main
tracking
issue,
so
that
the
preferred
way
to
work
is
like
to
create
like
a
single,
for
example
like
small
pr
or
something,
and
then
like,
have
someone
initially
like
go
over
it
right
like
not
like
a
big
chunk
or
like
a
few
pr.
Something
like
that.
C
Yeah
yeah
cool
cool,
so
all
that
are
like
answers
that
are
informative
and
like
will
help
us
and
one
more
thing
I
just
wanted
to
ask
you
see
this
like
I
just
wrote
down
the
second
one
log
up
their
test.
So
basically,
if
you
want,
I
can
maybe
share
my
screen
or
just
like
explain
what
I
saw
so
I
I
looked
at
the
spa
stand
data.
C
You
know
the
span
adapter
test
and
I
saw
that
there
is
like
a
builder
for
the
spam
data,
a
test
if
you,
if
you
are
familiar
with
it,
so
how
like,
if
I
want
to
share
my
screen,
I
should
just
do
it
from
from
here
from
the
zoom,
so
try
to
show
you,
okay.
So
basically,
let's
try
to
find
it.
So
I'm
trying
to
right
now.
Like
start
writing
the
logarithmic
test-
and
I
looked
at
the.
C
Span
adapter
test,
okay,
so
essentially
in
in
the
span
adapter
test
we
use
like
here.
This
test
span
data
with
like
auto
value
and
builder,
and
I'm
still
like
not
very
familiar
with
the
the
auto
value
and
kind
of
like
way
to
work.
But
I
I
read
just
a
little
bit
about
it
and
it
seems
like
when
I
try
to
kind
of
implement
something
similar
in
here
and
I've.
C
I'm
have
some
problem
with
this
builder
because
actually
there
is
already
because
the
log
record
is
is
an
abstract
class
and
not
like
a
an
interface.
There
are
there's
already
a
builder
here,
so.
A
A
C
C
A
C
G
C
C
B
Cool
we
do
not
have
much
on
the
agenda
today.
B
Let's
see
we
can
do
I
put
a
couple
of
small
items
on
one
was
I
wanted
to
introduce
an
option
to
suppress
internal
spans
for
our
our
back
end,
you
pay
by
ingestion,
so
a
lot
of
several
people
have
asked
not
to
they
don't
see
value
in
the
internal,
the
controller
spans,
and
so
I
was
hoping
to
put
in
some
kind
of
option.
The
problem
is
you
can't
really
just
turn
off
the
instrumentation
itself
since
it?
B
This
is
what
provides
the
nice
span
names,
the
route-based
band
names,
and
so
I
know,
there's
a.
I
think
it
makes
sense
to
keep
that
routing
and
the
span
creation
in
the
same
module
the
same
instrumentation
instead
of
splitting
them
out,
since
that
is,
I
guess
that
is
one
option
to
split
them
out,
so
you
could
suppress
one
of
the
instrumentations.
B
The
other
option
is
just
to
create
an
option.
Some
kind
of
setting
that
you
could
suppress.
B
C
B
If
somebody
used
width
span
wouldn't
want
to
suppress
that
that
seems
like
an
opt-in
saying,
I
do
want
that
internal
span.
B
All
right,
just
my
two
cents,
I
like
the
option
here
to
suppress
and
not
splitting
it
out
in
this
particular
case,
and
I
worry-
or
I
start
start
thinking
about
how
we
will
track
if,
if
we
continue
doing
this
across
instrumentations,
how
we're
gonna,
how
we're
gonna
manage
all
of
these
configuration
directives,
because
there
will
potentially
be
a
lot
like.
Oh
if
this
has
one
but
hibernate
doesn't,
is
that
potentially
confusing.
B
Yeah,
you
know
so
there's
yeah
and
I
was
thinking
of
calling
it
like
suppress
handler
span
or
suppress
controller
span,
but
then
I
was
implementing
it
and
realized
that
there's
also
model
view.
There's
a
view
span
that
we
create.
B
I
mean
we
could
have
two
different.
We
could
have
controller,
also
like
handler
versus
controller
any
I
was
trying
to
think
of.
What's
the
better
name
for
those
spans,
I
think
I
was
I
was
sort
of
leaning
towards
controller
seemed,
maybe
a
more
that
users
would
understand
that
what
that
meant
better,
a
little
bit
more
specific
and
if
it's
sitting
along
with
model
and
view
yep.
E
So
my
question
was
kind
of
kind
of
a
loaded
question.
Would
it
be
possible
to
use
our
new
spam
suppression
mechanism
for
this?
Like
disable
all
controller,
slash
view
spans.
B
So
it
could
oh
if
we
had
a
type
of
spare.
Oh,
if
this
type
of
span
was
controller,
yeah.
E
F
B
Yeah,
the
the
ones
that
that
users
have
specifically
asked
for
well
are
the
mvc
type
ones,
because
we're
not
even
pulling
in
into
our
distro
a
lot
of
the
miscellaneous
instrumentations
that
produce
internal
spans
like
we
don't
pull
in
hibernate
instrumentation.
At
this
point
kind
of,
because
of
that.
E
B
E
B
Cool,
I
think
that
gives
me
some
good
thoughts
to
go
move
forward
with
this
one.
I
just
wanted
to
make
sure
we
got
unblocked.
B
B
Cool
guys,
I
want
to
get
it
working
first
before
I
worry
about
the
display.
Looking
good
yeah,
I
will
hit
merge
after
thank
you.
We
do
need
a.
We
do,
need
a
new
pet
can
pet
clinic
base
image
after
that
action
got
updated.
B
It
was
the
one
that
watson
kicked
off
yesterday
that
failed.
Oh
after
this,
after
merging
this
I
mean
probably
well.
I
guess
that
that
thing
runs
nightly
so
yeah
we
just
have
to
sorry,
I'm
still
not
awake.
Yet
there
was
a
pr
I
put
in
yesterday
to
fix
the
action
that
was
referring
to
the
old
directory
name
and
it
didn't
run
correctly.
That's
what
produces
the
the
base
image
that
the
one
that
you're
about
to
merge
will
use
okay.
So
we
need
to
run
here
yeah
all
right,
thanks,
yeah,
exactly.
H
Yeah,
so
I
think
we
got
to
resolve
this
asynchronously,
but
yeah,
just
questioning
whether
we
should
add
an
option
to
the
auto
configure
module
to
use
the
otlp,
http
exporters
and
yeah.
So
there's
no
spec
support
for
it
yet,
but
I
can
go
ahead
and
open
an
issue
in
the
spec
and
prototype
it.
A
And
john
yeah,
so
I
just
wanted
to
to
highlight
some
work
that
honorak
has
been
doing,
which,
hopefully
so
just
back
up
a
little
bit.
A
The
the
protobuf
based
exporters
up
to
this
point
have
all
kind
of
utilize:
the
generated
protobuf
classes
that
are
generated
by
the
product
compiler
and
those
bring
in
as
a
requirement
of
the
protobuf
library,
like
the
actual
photograph
java
library,
as
a
dependency,
which
is
not
small
and
also
have
for
at
least
one
user
has
caused
a
conflict
with
their
their
version
of
the
protobuf
library
that
they
had
in
their
android
app.
A
So
and
it's
not
any
of
the
android
work
I've
been
doing.
This
is
some
somebody
must
have
logged
an
issue
about
it,
and
so
there
has
been
kind
of
floating
around
for
a
long
time
that
it
would
be
much
more
efficient
for
us
to
directly
write
bytes
to
the
wire
in
the
protobuf
format,
rather
than
using
the
the
build.
The
kind
of
the
generated
protobuf
classes,
which
are
quite
heavyweight
and
used
an
enormous
number
of
allocations.
A
A
A
If
people
need
that
library,
why
is
there
something
that's
stopping
them
from
publishing
it
themselves
or
generating
themselves,
because
that
would
be
greatly
preferable
to
us
maintaining
a
library
in
our
kind
of
in
our
published
artifacts
that
we're
not
even
using
and
have
no
need
for
so,
and
I
think,
actually
onorag's
latest
pr
actually
changes
the
way
that
it's
generated
to
have
an
extremely
minimal
implementation,
just
a
few
constants.
A
So
we
might
be
able
to
depend
on
that
artifact
without
having
to
depend
on
the
proto
library
at
all,
which
of
course
would
make
it
completely
not
useful
to
anyone
externally
who's
trying
to
use
it
for
actually
generating
photo
classes
anyway.
So
I
just
wanted
to
kind
of
bring
it
up,
and
I
don't
know
whether
anyone
here
on
this
call
would
be
impacted.
But
it
is
something
that
to
be
aware
of.
This
is
going
on.
E
A
Yeah-
and
I
think,
there's
actually
another
reason
that
we
probably
want
to
continue
well,
I
think
that
we
would
probably
want
to
have
a
similar
back-end
implementation
in
in
the
java
repository
itself,
just
as
a
way
to
validate
that
the
bytes
were.
Writing
directly
actually
are
consumable
by
an
endpoint
that
we
stood
up,
that
you
know
jrpc
endpoint,
that
received
those
bytes
correctly,
and
then
it
would
be
a
great
sanity
check
to
make
sure
that
those
two
things
were
in
alignment
yeah.
So
it's
a
good
question.
I
don't
know
the
answer.
A
We
haven't
merged
the
pr
that
honorable
put
in
that.
I
think
breaks
that
proto
library
to
not
work,
and
maybe
I'm
misunderstanding,
the
pr
so
I'll
also
be
talking
to
you
this
evening
about
it
at
the
afternoon
meeting
so.
H
Anyway,
so
right
now,
so
any
tests
that
you
write,
you
know
if
you're
using
a
hand
rolled
serialization
library,
you
would
be
able
to
use,
still
use
the
the
you
know,
the
proto
deserialization
on
the
server
side,
so
you'd
be
able
to
check
compatibility
that
way,
but
like
if
you're
one
one
good
thing
of
keeping
the
proto
generation
around
is
you
know
you
can
serialize
the
bytes
and
compare
the
raw
serialized
bytes
from
your
hand,
rolled
version
to
the
proto
version
and
like
validate
that
they're
exactly
the
same,
so
not
just
that
they
deserialize
to
the
same
values,
but
the
serialized
bytes
are
actually
equivalent.
A
Right,
although
I
mean
I,
we
could
could
argue
that
maybe
there's
that
we
might
be
able
to
write
more
optimized
versions
of
those
fights.
I
don't
know,
I'm
not
I'm
not
a
proto
buff
expert
yeah,
but
they
need
to
be.
I
The
same,
I
just
want
to
call
that
out.
So
that's
that
that's
a
choice
you
could
make
in
your
implementation,
for
example,
how
repeated
fields
get
serialized
is
kind
of
a
big
deal.
H
So
two
other
quick
thoughts
or
just
one
note
new
relic,
also
uses
the
has
a
dependency
on
the
proto
library
for
some
internal
stuff
and
then,
but
looking
at
the
proto
module
source
code,
it
I
don't
think
it
would
be
difficult
for
us
to.
You
know,
generate
those
protos
ourselves
internally.
If
it
came
to
that.
A
A
A
I
Oh,
no
just
that,
having
implemented
my
own
protocol
buffer
implementation
like
there's
a
there's,
a
bunch
of
subtle
decisions
that
you
can
make,
and
I
think
the
best
the
best
test
you
can
do
here
is
you
know
serialize
and
deserialize
sure,
but
also
make
sure
that,
like
sending
to
the
collector,
for
example,
with
their
custom,
deserialization
is
efficient
and
then
sending
to
like
a
default.
Chrono
implementation
is
useful
too,
but
yeah.
There's
the
trade-offs
are
all
fine
and
I
really
like
the
library
you
chose.
A
Yeah
yeah
josh,
I'm
actually
leaning
really
hard
on
you
to
review
those
pr's,
because
I
am
not
a
proto
buff,
even
remotely
close
to
an
expert.
I
barely
understand
it
at
all.
So
all
the
help
you
can
provide
on
on
those
vrs
is
very,
very
useful.
I
I
I
don't
I
don't
know
if
we
care,
but
what
I'm
curious
about
is
we
have
our
own
proto-generation,
that's
different
from
what
wire
does
right?
A
A
All
right
cool
anyway,
we
can
discuss
offline
and
slack
as
well
or
even
in
a
github
discussion.
Now
that
you
know
what
they
are.
C
And
john
out
of
there
curiosity
again,
it's
like
super
new
to
me
all
this,
like
robot
stuff
and
also
like
how
we
use
it
in
internally
in
our
project
but
like
what
is
the
basically,
what
is
the
difference
so
from
what
I
understood
from
you,
you
mean
that
we
we
are,
we
don't
want
to
like
auto,
generate
those
classes
like
from
the
protobuf.
I
guess
specification
you
can
say
and
just
like
write
directly
to
a
byte
buffer,
but
how?
How
like
does
it
work
on
high
level?
I'm
not
sure
like.
A
I
am
certain
I
do
not
understand
it
at
all.
This
is
why
I'm
leaning
on
honorary
and
josh,
I
think
for
the
first
implementation
that
you're
doing
haven't
be
having
it
be
based
on
the
generated.
Protobuf
is
totally
fine
and
we
can
work
on.
I
mean
it's
really
an
optimization
to
write
the
bytes
directly
and
obviously
a
lot
trickier.
C
Yeah,
because
I'm
trying
to
I'm
trying
to
like
figure
out
in
my
head,
how
like,
because
it's
probably
completely
different,
not
maybe
not
completely
different
but
like
as
far
as
like
what
I
saw
it,
it
looks
like
it's
it's
very
it's
very
like
it's
very
nice
to
have
those
objects
in
terms
of
like
writing
the
code,
because
it's
super
like
straightforward
and
simple.
A
C
C
Yeah
and
also
one
more
question:
where
do
we
store
those
like
I'm
not
sure,
what's
the
correct
like
professional
theorem,
but
where
do
you
store
the
specification
of
those
like
the
protobuf
auto
generated
class
like
where
is
the
blueprint
for
what
is
being
generated
so.
A
There's
a
there
is
a
repository
called
open,
telemetry
dash
proto
that
has
all
the
actual
protobuf
definitions
in
it
and
what
the
way
that
our
build
work
is
we
actually
just
pull
that
down,
pull
that
repository
down
as
a
part
of
the
build
and
then
build
then
use
the
proto
compiler
to
generate
the
classes.
C
Cool,
so
so,
if
at
some
point
I
see
that
we
we
might
want
to
like
add
something
like
modify
something
in
terms
of
like
naming
or
because
we
saw
some
stuff
that
are
kind
of
like
where
they're,
like
a
good
good
example,
might
be
the
the
log
record
which
we
have
like
a
protobuf,
auto
generated
class
and
also
we
have
the
abstract
class
in
the
code.
C
C
A
To
that
they
require
backward
compatibility,
there's
a
lot
of
there's
it's
it's
a!
It
is
a
difficult
long
process
to
get
make
changes
yeah,
just
as
a
warning.
Yeah.
C
G
I
Remember
beta
it's
beta,
I
I
I
don't
anticipate
any
major
changes
unless,
like
they're
driven
from
implementations,
so
at
this
point
it's
more
if
you
go
to
implement
it,
you're
like
holy
crap.
It's
missing
this
major
feature,
then
there's
a
possibility
of
change,
but
otherwise
I
would
not
expect
any
changes
to
that
program
going
forward.
C
A
Is
also
why
I
want
to
make
sure
that
openflow
entry
java
has
our
own
log
model.
That
is
not
exactly
the
same
as
the
proto,
because
that
gives
us
flexibility
to
make
the
names
friendly
and
make
the
name
like
actually
involve
that
independently
of
the
protobuf
and
then
the
mapping
to
the
proto
is
what
needs
to
be
stable.
C
So
so
like
what
you're
saying
is
you
mean
having
our
own
like
declaration
like
definitions
for
for
protobuf
internally,
or
just
like,
as
you.
C
A
C
Yeah
and
then,
like
the
the
issue
again,
is
like
to
to
kind
of
like
connected
to
what
you
said
about
the
writing.
It
directly
to
the
buffer
is
like
how
we
serialize
that,
in
a
like
actual
like
easy
way
or
not
like
super
complicated
manner,
yep
cool
thanks.
B
Right
we
hit
the
end
of.
I
had
a
topic
if
there's
time.
I
I
hope
it's
clear.
There
is
time
okay,
but
you
were
typing,
so
I
didn't
want
to
copy
paste
stuff
in
there.
So
real
quick,
I'm
I'm
working
on
the
the
new
sdk
spec
and
I
have
a
draft
pull
request
for
updating
view
wiring.
I
So
let
me
post
that
in
here
this
is
metric.
Metrics
related
metric.
Sorry
metric
views.
Yes,
so
if
you
take
a
look
at
this,
there's
there's
a
couple
to
do's
on
this
and
what
I'm
wondering
is:
there's,
there's
a
choice
to
be
made
here.
I
I
feel
like
this
is
at
a
decent
size
for
people
to
take
a
look
at
it,
but
it
has
some
really
bad
user-facing
behavior
on
errors
that
I'd
like
to
clean
up
that,
I
think,
will
actually
involve
major
major
amounts
of
code
depending
on
depending
on
how
it
turns
out.
So
what
I'm
asking
basically
is.
Should
I
send
this
for
review
now
where
effectively,
what
this
does
by
the
way
is
it
allows
views
to.
I
It
allows
you
to
have
multiple
views
per
metric
instrument
and
it
allows
sorry
it
doesn't
allow
multiple
views
for
metric
instrument.
That's
the
crazy
heart
change!
I
I
So
what
I'd
like
to
do
is
go
through
and
expand
the
providence
of
these
things
and
then
go
through
and
allow
multiple
views
per
instrument
as
long
as
there's
no
name
conflicts
going
forward,
do
a
little
bit
of
performance
evaluation
on
that,
because
I
think
that's
going
to
be
a
little
fun
and
it's
also
going
to
remove
crashes
when
there
is
a
metric
name
conflict,
which
is
something
that
happens
today.
I
A
Say
absolutely
in
fact,
if
one
one
way
that
we
have
liked
to
work
in
the
past
is
to
create
issues
for
each
of
those
items
in
your
to-do
list,
we
can
pick
them
off
and
track
what
still
needs
to
be
done.
You
know
in
a
way
that
everyone
can
see,
but
we're
I
mean
all
this
stuff
is
still
alpha
right,
metrics
are
unstable
and
we
just
did
a
release,
and
so
we've
got
at
least
three
weeks
before
we're
planning
on
doing
another
release
to
get
things
tightened
up.
A
I
I
can
open
a
bug
around
views
or
like
a
series
of
bugs
to
kind
of
track
the
work
a
little
bit
better.
One
of
the
things
that
I'm
really
bad
at
is
I've
been
kind
of
piecemeal,
designing
the
components
of
the
of
this.
From
that
one
prototype,
I
did,
I
think
I
mentioned.
I
would
write
a
design
dock
eventually
I'll
get
there.
I
promise
maybe.
A
This
is
this,
I
don't
know
if
you
want
this
is
this
is
totally
fine.
I
have
no
problem
with
this.
I
mean,
as
I
said,
metrics
are
unstable,
we're
trying
to
sort
this
out.
This
is
really
this
is
well.
The
whole
purpose
of
this
is
to
you
know,
work
through
the
sdk
spec
and
make
sure
that
we
can
implement
it
and
get
it
working.
So
this
is
absolutely
perfect.
That's
fine.
I
Okay,
there's
going
to
be
some
major
changes
hitting
aggregators
when
we
start
doing
exemplar
stuff,
so
I'm
trying
to
get
to
the
point
where
we
can
open
up
that
work,
but
they
keep
getting
uglier
every
pull
request.
I'm
not
really
happy
about
it.
So,
just
as
an
fyi,
I
believe
it
okay
right.
The
last
thing
I
just
wanted
to
say
was:
I
updated
the
google
exporters
to
1.5.0
and
not
1.5
whatever
0.25,
whatever
the
latest
one
is.
Is
it
15
25.?
I
There
was
a
5
in
there
1.5
and
1.5.2.5
yeah
yeah,
so
1.5
and
it
was
gravy.
So
we
got
them
wired
into
the
auto.
Config
got
everything
working
with
the
auto
agent.
The
new
documentation
is
awesome,
so
I
just
wanted
to
say
like
great
work.
That
was
actually
really
seamless
and
easy.
So
super
happy
with
it.
B
Yeah,
that's
a
good
topic.
Yeah.
A
Because
I
want
to
pull
in
my,
my
okhttp
call
call.
B
Right
any
so
we
are,
I
think,
tentatively,
planning
to
release
one
five
zero
tomorrow.
So
if
there's
any
changes
that
you
want
any
last
minute
changes
you
want
in
there.
Let
us
know
on
slack
and
we
will
do
our
best.