►
From YouTube: 2022-04-29 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).
A
B
C
Jack
is
that
your
personal
kanban
board
on
the
table
beside
you.
D
D
I
did
that
for
a
while
and
but
then,
like
you
know,
unimportant
tasks
would
end
up
being
like
five
pages
back
10
pages
back
and
then
they
just
they
just
get
forgotten
about
completely.
Maybe
that's
a
good
thing
just
like
you
know,
yeah.
C
I
usually
copy
over
when
I,
when
I
change
pages,
this
is
actually
a
notebook
that
I
got
when
I
worked
out
at
nike
like
many
like
well
like
15
years
ago.
I'm
still
been
working
my
way
through
it
has
notes
from
all
the
places
I've
worked
at.
C
It
has
some
funny
drawings
that
jason
plum
did.
When
we
worked
together
a
couple
times,
he
would
steal
my
notebook
and
during
meetings
and
doodle.
C
A
Rabbit
hole
of
naming
max
versus
limit
jack
is.
E
A
Open
a
spec
issue
to
see
if,
when
we
have
min
max,
if
there's
any
kind
of
like
I
always
said
I
like
I,
I
like
this
guidelines,
it
gives
us
something
to
answer
some
of
those
fall
back
on
for
naming
questions
but
yeah.
It's
not
clear
what
to
do
for
mid
max.
A
A
A
lot
of
discussion
about
logs
api,
so
I
think
there
was
pretty
good
consensus
sticking
with
john's
john's
forever.
No
logging
api,
nothing
called
the
logging
api.
A
So
I
think
jack
is
going
to
take
that
back
to
the
logs
or
the
spec,
because
it
sounded
like
tigran
was
sort
of
floating
the
idea
of
having
something
called
a
log
api.
D
Yeah
they
very
much
are
so
that's
that's
being
proposed,
and
you
know
the
original
use
case
of
it
was
for
events,
but
you
know
the
natural
place
that
everyone's
heads
go
is
like
hey,
why?
Why
should
we
just
limit
this
to
events
and
in
java
we
have
a
good
reason
to
do
that
and
other
languages.
I
think
it's.
It's
sometimes
the
case
that
you
know
the
logging
environment
is
rich,
but
you
know,
maybe
not
in
in
other
languages,.
A
D
We
we
do
do
some
of
that
already,
so
we
have
the
like
the
console
exporter,
so
you
know
you
can
you
can
get
your
logs
through
the
open,
telemetry
log
sdk
into
the
council?
We
don't
have
four
matters
so
and
I
don't
anticipate
that
we
would
so.
I
think
that
would
always
be
like
a
feature
gap.
D
A
And
then
john
threw
a
wrench
and
everything
calling
out
causality
and
how
logs
can't
have
children,
and
so
the
rum
is
toying
with
the
idea
of
zero
duration
spans.
Because
of
that.
D
C
For
example,
in
the
rum
use
case
clicking
a
button,
it
doesn't
have
a
duration,
and
yet
that
can
definitely
spawn
events
and
cause
things
to
happen
that
you
might
want
to
track.
D
Maybe
that's
a
differentiator
between
like
a
key.
A
key
feature
of
events,
though,
is
that
they
they
don't
have
this
hierarchical
relationship.
They
don't
have
causality
and
so,
if
you're
proposing
to
use
them
for
something
that
that's
a
requirement
for
you
use
something
else.
Our
zero
duration
spans
not
allowed.
I
I
I
know
they
answer,
but
they're
allowed
yeah.
I
mean
they're
totally
alive.
C
Zipkin
export
doesn't
support
zero
duration
spans.
It
requires
you
to
make
them
into
a
microsecond
in
length,
but
I
think,
like
otlp,
doesn't
have
a
problem
with
zero
duration.
D
Yeah,
because
what
I
don't
want
to
see
happen
is
that
events,
you
know
kind
of
have
this
hierarchical
structure
like
spans.
Do
you
know,
or
just
recreate
spans
with
events
I
think
that'd
be
weird
and
confusing
so
yeah?
What
are
the
distinct
distinguishing
features
of
each
of
the
the
core
types
that
I
think
hard
about?
That.
C
D
Yeah,
it's
super
well,
so
the
the
use
case
that
I
have
in
mind
is
for
like
jfr,
so
there's
lots
of
things
that
we're
interested
in
in
bringing
into
open
telemetry
from
the
jfr
space
and
they
don't
make
sense
as
metrics
or
spans,
and
so
for
those
things.
You
know
we
need
an
api
and
that
you
know
using
slf
or
j,
and
you
know
the
log
api
to
capture
things
that
are
fundamentally
kind
of
events
in
nature
where
they
have
a
type
and
a
series
of
attributes
and
not
a
body,
it's
awkward.
A
D
I
imagine
that
events
are
going
to
either
have
top
level
fields
for
an
open
telemetry
to
represent
like
type
and
the
namespace
of
that
type
or
semantic
inventions.
For
those
attributes-
and
you
know,
I
think,
having
a
dedicated
api
to
record
events
just
makes
it
it
much
easier
to
abide
by
whatever
that
structure
is
rather
than
you
know
you
needing
to
know
this
kind
of
implementation
detail,
which
is
I'm
using
the
log
for
j
api.
D
But
in
order
for
this
to
map
into
an
open,
telemetry
event,
I
need
to
record
it
in
just
the
right
way.
D
Telemetry
event:
well,
I
think
that
will
be
defined
by
semantic
inventions.
I
think
that's.
B
D
D
Sdk,
so
if
the
what
would
you
say,
then,
if
the
spec
were
to
move
forward
and
spec
a
a
log
api?
That
was
general
purpose
and
you
know
we
and
I
think
java
have
the
would
probably
choose
not
to
implement
a
traditional
application
level
logs
api,
but
we
we
would
be
interested
in
events.
Would
you
advocate
for
us
doing
that?
Just
at
the
in
the
is
an
instrumentation
api,
and
do
you
think
that
that
would
be
compliant.
C
E
A
C
B
E
C
Yeah,
I
think
if
we
want
to
design
an
ap
excuse
me,
an
events.
Api
like
jack
has
suggested,
like
there's
a
there's,
a
name
for
a
type
on
the
event,
but
that'll
end
up
getting
mapped
by
the
sdk
into
an
attribute
some
sort
of
attribute,
because
there
is
no
name
anymore
on
the
data
model.
Unless
that
comes
back
again,.
D
That
might
come
back,
but
you
know
I
don't.
I
think
it
had
to
go
when
it
did,
because
it
wasn't
clear
enough
how
it
was
to
be
used,
and
I
think
it
was
missing
this
critical
aspect,
which
is
like
a
namespace
feature.
So
it
might
come
back
as
a
top
level
field,
but
that's
a
bridge
that
we
cross
when
we
get
there.
E
Okay,
I
guess
maybe
then
the
another
answer
to
jack's
question,
though,
is
if
the
functionality
for
events
could
just
be
our
own
custom.
For
example,
like
our
own
custom
implementations
of
logs
log
4g
structured
messages,
so
it's
still
sort
of
it
provides
the
user
event
api
because
it's
like,
I
guess
what
sort
of
events
are.
The
click
events,
so
click
event.
B
E
Builder,
dot
set
source
dot
set.
Something
like
these
are
semantic
attributes,
I
guess,
and
they
could
also
be
implemented
with
logo4j.
Probably
they
don't
necessarily
need
a
logs
api
and
so
whether
that's
a
good
approach
or
not,
it's
a
different
question.
I
think,
but
that's
also
an
approach,
if
that's
all
that's
needed.
D
Yeah
that
that
was
discussed
in
the
log
sig
was
you
know:
can
we
just
implement
a
an
event
api
that
delegates
to
the
existing
log
apis
that
exists?
Make
choose
one.
D
You
know,
I
think
I
think
log4j
has
a
better
api
for
structured
logs
than
slr
for
j.
I
think
it's
a
bit.
Awkward
to
do,
you
know,
is
to
set
specific
attributes
in
slf
for
j,
and
so
that
I
think
that
would
have
to
be
like
a
consideration
us
a
lot
for
jay,
I
think
maps
better
to
to
whatever
framework
you're
using,
but
but
its
api
is
weaker
for
what
we
need.
C
D
Yeah
it
and
that's
and
that's
the
thing
so
I'm
wondering
if
it's
like
possible
because
like
when
you
set
map
diagnostic
context,
you
set
it
like
statically,
and
so
you
know
what
happens
if
you
have.
If
you,
if
you're
doing
this
concurrently
on
the
same
thread,
could
you
are
not
on
the
same
thread
but.
C
Yeah,
no,
I
don't
think
sls
has
really
has
the
structure
we
want
for
events
now
I
think
log4j2
probably
does
I
don't
know
if
log
logback
does
or
not,
but
I
think
because
slf,
which
I
think
has
kind
of
become
at
least
at
some
level.
The
standard
logging
api
for
java
doesn't
support
this.
I
think
we
do
need
some
sort
of
this
would
be
an
actual
value.
Add
to
the
community
to
have
this
event
atm,
and
it
is
something
that's
not
particularly
representable
using
the
most
prevalent
logging
api.
D
Yeah
and
the
distinct
the
the
distinguishing
characteristics
that
we've
come
up
with,
or
you
know
a
name
and
a
type
and
a
name
space,
and
then
a
bag
of
attributes
that
that
concept
doesn't
really.
You
know
you
can
do
it
with
with
with
log
for
j
and
maybe
slf
for
j,
but
they
certainly
weren't
like
designed
with
that
in
mind.
A
Exactly
yeah,
so
I
mean
this
is
kind
of
the
option,
for
I
think
the
sort
of
there
is
an
option,
a
decent
option
for
slf
4j
that
doesn't
require
mdc
you
kind
of
fake.
It,
though,
like
you,
create
this
structured
object
and
you
pass
it
and
then
you
rely
on
the
fact
that
you're
using
a
particular.
E
A
B
E
A
E
D
Oh
go
ahead
check,
you
got
it,
you
got
it
well,
okay,
so
jonathan
was
on
our
call
earlier
today
and
he
said
that
they
have
given
up
on
micrometer
two,
and
so
I
think
they
went
to
their
users
and
the
the
feedback
was
that,
like
that
type
of
breaking
change,
their
api
would
be
unacceptable
and
so
they're
gonna
they're
gonna
ride
it
out
with
their
existing
api
right
now
and
make
the
set
of
changes
that
they
want
to
make
within
the
constraints
of
you
know,
backwards
compatibility,
and
he
said
that,
if
the
like
that,
if
they
do
want
to
go
forward
with
micrometer
too,
it
would
be
at
some
later
point
in
time,
maybe
when
they
decide
to
bump
from
java
8
to
java
11
or
17
whatever.
E
D
F
E
E
A
But
it's
so
coupled
to
spring
boot
right
that
as
people
upgrade
and
people
are
always
needing
to
upgrade
spring
boot
because
of
say
security.
That
might
be
one
problem
that
would
force
upgrades.
A
F
E
D
And
so
you
know,
that's
not
that's
not
symmetric
with
our
api,
where
a
metric
name
has
its
own
description
and
unit
and
then
lots
of
different
distinct
sets
of
tags
underneath
it,
and
so
that
that,
like,
when
you
run
a
spring
boot
application
with
the
spring
boot
actuator
and
the
micrometer
shim,
you
get
a
million
warnings
from
all
the
situations
where
they
have
the
same
metric
name,
but
a
different
description,
because
that
produces
a
warning
in
our
metrics
sdk,
and
what
I
learned
that
was
interesting
is
is
that
they
prometheus
doesn't
deal
with
this
either.
D
So
in
the
same
way
that
our
metrics
sdk
throws
a
warning.
When
you
have
a
different
description,
prometheus
can't
cope
with
that
either,
and
so
their
solution
in
prometheus
is
just
to
take
the
first
description
that
comes
in
and
use
that
as
the
description
when
you're
exporting
and
so
jonathan
said
that
what
they
would
do
is
if
I
can
give
him
a
list
of
all
the
places
where
this
happens
in
their
code
base,
that
I
can
see
reasonably
they'll
go
up
and
they'll
go
and
fix
this
and
make
sure
that
they
don't
have
different
descriptions.
D
D
E
E
E
D
So,
even
if
we
fix
that
in
the
micrometer
shim,
we
would
want
to
keep
your
fix
around,
because
you
know
it's
only
a
warning
in
the
sdk,
but
it's
like
an
error
in
prometheus
and
so
yeah
yeah
for
hotel.
D
We
say
that
it's
on
the
back
end
to
figure
out
how
to
deal
with
that,
whereas
prometheus
will
produce-
and
you
know
the
scraping
will
produce
an
error.
If
you
try
to,
we
decided.
A
D
So
it's
it's
a
semantic
error
to
have
different
descriptions
like
in
in
open
telemetry.
If
you
have
the
same
metric
name
with
a
different
description,
that's
that's.
You've
created
an
a
metric
identity
conflict
and
so
you
know
we
allow
that
to
pass
through,
and
you
know
you
can
decide
how
to
deal
with
it
either
on
export
or
in
your
back
end.
But
it's
not
it's
not
a
situation
we
think
is
good,
which
is
why
we
warn.
A
A
Oh,
you
were
at
the
jvm
metrics
meeting
yesterday
or
two
days
ago
right
honorable
yeah,
I
mean
we'll
wait,
it
sounded
like
tommy
was
going
to
get,
but
I
I
I
liked
that
this
topic
came
up
because
yeah
it
is
confusing,
but
it
it's
equally
confusing,
because
I
remember
when
the
pr
came
out.
The
micrometer
is
equally
confusing.
The
jmx
metric
name
is
equally
confusing,
so
we're
not
introducing
any
new
confusing
confusion,
but
if
we
that's
not
exactly
the
best
excuse.
B
D
D
E
D
Of
understandable,
maybe
there
should
be
a
different
designation
between
stable
and
experimental,
like
so
the
resource
semantic
conventions.
You
know
they're
still
they're
marked
as
experimental
too,
but
you
know
they've
gained
enough
momentum
around
them
that
the
the
cost
of
changing
them
is
high.
You
know
the
the
cost
of
changing
our
experimental
semantic
inventions
is
cheap,
like
we're
the
only
implementers
and
and
there's
probably
not
a
lot
of
consumers
of
it.
Yet
so
it
shouldn't
yeah.
B
E
E
E
A
E
We
have
precedence
for
instrument
or
api
being
something
we
developed
there
that
I
think
in
general,
though,
telecommunity
doesn't
like
that
much
having
a
separate
api.
So
we
have
precedence
in
that.
You
can
have
some
symmetric
inventions
that
follow
that
lane,
because
we
need
it
in
java.
They
don't
need
it
elsewhere.
So
we
should
have
a
good.
D
You
think
I
I
I
didn't
know
that
sentiment
existed,
but
the
instrument
right.
E
There
they
sort
of
like
why
isn't
this
opened
or
why
isn't
it
added
to
inflammatory
okay,
it
was
sort
of
it
seemed
like
our
instrumentary.
Api
does
have
some
cross
cutting
concerns
so
especially
like.
I
think
they
did
eventually
warm
up
to
that.
We
just
need
to
have
this
to
be
able
to
write
our
instrumentations
and
can't
be
blocked
or
anything,
but
there
was
still
some
sentiment
that
the
instrumentary
api
should
be
a
properly
specced
open,
concrete
guy,
not
just
their
own
thing.
D
I
mean
you
definitely
need
something
to
enforce
standards
across
how
many
libraries
there
are.
You
know
worst
case
scenario.
You
could
treat
it
as
a
library,
that's
like
private
to
to
the
agent
and
not
meant
for
external
consumption,
but.
A
E
There
was
some
like
the
point
that
opened
on
jk
was
to
have
that
api
that
everyone
used
to
put
in
java.
It's
not
going
to
be
that
it's
going
to
be
an
instrument,
what
we
recommend.
So
I
think
that's
where,
like
there
is,
that's
really
like.
Why
did
this
happen,
but
I
think
that's
we
weren't
going
to
be
able
to
spec
up
the
instrument
or
api
in
any
meaningful
way
to
be
able
to
share
that.
A
A
A
I
think
I
mean
from
what
I
recall
python
has
something
you
know
like.
I
don't
think
people
have
done
metrics
much
metrics
instrumentation,
yet
so
the
crosscutting's
not
there,
but
I
think
other
languages
probably
have
some
common.
You
know
whether
it's
just
utilities
that
they
use
across
instrumentations.
A
But
yeah
everything,
no,
no,
no
massive
metrics
discussions,
anymore
metrics
is
feeling
good
and
solid
right
now.
D
I
did
just
open
up
my
batch
callback,
pr
for
like
review,
and
so
I'm
in
no
rush
to
get
that
in
you
know
it's
new
api,
so
we
should
approach
it
with
a
fair
degree
of
caution,
but
you
know
it's
it's
on
the
table.
If,
if,
if
folks
have
a
need-
and
I
I
think
I
have
heard
of
some
people
on
the
instrumentation
side
that
are
interested
in
it-
I
think
it's
reasonably
ready.
A
C
Fancy
fancy
fancy
yeah.
This
is
where
we,
I
think
we
really
need
to
get
joshua
if
he
is
able
to
take
a
look
at
this.
B
C
Did
you
end
up
with
with
the
the
on
the
build
call
or
whatever
the?
What?
What?
What
did
we
kind
of?
Where
is
where
does
it
stand
right
now,.
D
A
D
C
A
I
was
just
thinking
if
there
was
a
way
to
like
how
and
going
forward
with
things
like
this
sort
of.
Is
there
a
way
for
us
to
get
user
feedback
so.
C
We're
doing
that
a
little
bit
with
with
that
by
or
putting
the
exception,
having,
like
that
exception
data,
which
is
not
officially
part
of
the
api
that
is
internal
and
available.
C
Well,
then,
maybe
that's
sdk,
they
don't
remember
for
sure,
but
I
think
there's
also
the
the
exponential
histogram
is
an
example
in
the
sdk,
where
it's
there
in
the
internal
package
implementing
a
public
a
stable
interface,
but
in
the
in
an
internal
package
so
that
it
can
be
used
if
people
are
willing
to
take
that
risk
like
it's
something
experimental
right,
you
could
grab
it
and
play
with
it
as.
E
E
E
E
D
Are
you
all?
Are
you
all
super
opposed
to
using
annotations
to
like
comply,
experimental.
D
Api
annotation
yeah
like
grpc,
does
that
and
I
think
guava
does,
that.
I'm
saying
that
there.
B
E
E
B
D
I
think
it's
I
think
it's
you
know
we
talked
about
having.
We
have
all
these
experimental
features
in
the
sdk
and
those
are
nice.
But
you
know,
as
we
mentioned,
instrumentation
users
and
the
agent
can't
really
take
advantage
of
those,
but
maybe
that's
okay,
maybe
it's
okay,
just
to
like
have
it
at
the
sdk
level
and
it's
enough
to
like
kind
of
play
around
with
it
and
and
get
used
to
the
ergonomics
without
actually
like
using
it
in
in
an
actual
instrumentation
that
you
plan
on
publishing.
C
Another
another
thing
we
could
consider
is,
I
think,
honorary
we're
kind
of
suggesting
this.
If
we
had
a
incubator
module,
which
I
think
we
do,
I
don't
know
if
we
haven't
used
it
for
a
while,
but
that
incubator
module
could
have
additional
api
interfaces
that
extend
the
existing
ones
and
add
additional
methods
that
could
be
implemented
by
the
sdk.
E
B
C
Yeah,
so
if
you
wanted
to
use
this
new
thing,
you
would
pull
in
your
incubator
api
and
then,
instead
of
it'll,
be
a
little
tricky
to
figure
out
how
to
get
it
like.
If
you
need
to
get
your
meter
provider
to
return,
one
of
those
incubator,
you
might
need
to
have
an
incubator
meter
provider
as
well
that
you
then
pull
in
and
do
the
work.
So
there's
a
little
bit
of
a
like
how
many
layers
do
you
need
to
implement
and
as
part
of
the
incubator,
api.
D
Well,
let's
keep
talking
about
the
meter
example,
the
sdk
meter
example.
So
s
sdk
meter
implements
meter.
It
could
implement
the
experimental
meter
as
well.
Do
you
yeah?
I
guess
I
guess
the
metrics
sdk
could
take
a
dependency
on
the
incubator,
module
with
a
compile,
only
dependency,
not
an
api
dependency
and
then,
like
all
you
have
to
do,
is
cast
your
sdk
meter
to
your
sure.
C
Yeah,
you
could
do
you
could
cast
it.
I
was
thinking
it
might
be
nice
to
have
like
I
can
just
pull
in
my
incubator
api.
It
just
has
extensions
for
all
of
the
like.
Some
of
them
could
be
like
it
has
all
of
the
api
interfaces
just
extend
like
with
extensions
of
the
existing
interface,
and
they
might
have
no
additions
to
them,
or
they
might
have
a
couple
of
the
commuter
things
and
then,
if
you
wanted
to,
you
could
kind
of
use
this
whole
incubator
api
as
your
api,
with
additional
features.
D
Stable
this
ends
up,
like
you
know
how
many
changes
do
we
find
ourselves
wanting
to
make
you
know
once
the
apis
are
out
there.
C
E
C
Yeah
that
clock
is
going
to
be
sure,
no
idea
what
we're
going
to
do.
A
I
I
don't
want
to
imply
that
this
change
needed
a
incubation
period,
because
I
think
it's
it's
pretty
seems
pretty
s
isolated
right.
It's
just
this
build
with
the
callback
and
the
the
the
firearm
stuff.
C
Anyway,
yeah
that
I
may,
if
I,
depending
on
my
last
day
at
splunk
tomorrow,
depending
how
much
I,
how
quickly
they
cut
off
my
access
I
may
play
around
with
seeing
if
I
could
do
an
incubator,
api
or
and
add
that
to
the
sdk
implementation
just
for
fun
something
stupid.
Just
as
a
tour,
you
don't.
C
A
D
There's
a
matrix
incubator
module
already.
It's
just.
I
think
it's
under
sdk
extensions,
but
I
don't
know.
Oh,
it
makes
sense
to
throw
an
api
incubation
interface
in
there
as
well.
C
A
pass
through
a
pass-through
propagator
and
an
extended
tracer
actually
passed
the
propagator.
C
It's
a
final.
The
interesting
thing,
the
extended
tracer
is
a
final
class
rather
than
so
it's
basically
so
they
took
a
different.
It
took
a
different
approach.
We
took
a
different
approach
here.
I
don't
even
remember
how
this
worked,
but
it's
basically
a
final
class
that
implements
tracer
that
you
can
then
use
as
a
part
of
your
api
that
provides
a
little
bit
of
additional
functionality,
but
it's
only
functionality.
You
can
implement
fully
already
with
the
api.
F
C
So
this,
if
we
took
this
approach,
we
could
instead
of
having
this,
be.
I
probably
wrote
this
that's
my
name.
C
Right,
yeah,
there
you
go,
we
could
change
the
implement
changes
here
to
be
an
interface
and
if
they're,
if
we
can
just
implement
the
interface
with
existing
api
methods
internally,
those
could
be
default
methods
right
and
then
and
then
we
could
provide
again
like
a
tracer
provider.
C
D
Yeah,
it
would
be
a
good
you
know,
tool
in
the
in
the
bag
of
tricks.
In
case
we
do
have
something
that's
more
controversial.
We
want
to
add
to
the
api.
A
C
Yeah,
it
was
a
bit
nerve-wracking.
Speaking
of
none
of
all,
none
of
any
of
this.
I
saw
this
morning
that
jetbrains
and
was
it
called
getpod.io,
now
have
a
partnership
and
gitpod
lets.
You
basically
do
remote
development
and
they
now,
basically,
you
can
use
gitpod
as
your
remote
id,
which
plugs
into
the
jetbrains
client
and
it's
totally
free
for
up
to
50
hours
a
month.
If
you
want
to
like,
if
you're
running,
running
your
vm
on
git
pod
50
hours
a
month
for
free-
and
I
think
you
can
apply
for.
D
Traffic,
how
big
are
the
machines
that
you
develop
on,
like
I
find
myself
completely
crippled
whenever
I
try
to
like?
You
know,
work
on
the
the
instrumentation
project
and
you
know
it
needs
to
index
or
something?
Oh,
my
gosh.
E
A
No,
I
I
exercise
a
lot
of
patience.
A
D
Yeah
looking
forward
to
that,
oh
my
gosh,
it's
I've
been
looking
forward
to
it.
So
much
like
I
I
find
myself
whenever
I
have
to
do.
One
of
these
builds.
It's
like
okay.
I
got
three
minutes.
What
what
do
I
do?
I'm
gonna
get
distracted
and
like
get
out
of
focus,
it's
brutal.
What
do
you
build?
Memories.
A
D
A
D
Depends
on
how
invasive
my
changes
are.
D
C
Yeah
all
right,
I'm
gonna,
take
off
we'll
see,
hopefully
see
you
all
next
week.
C
For
my
last
yeah
I'll
enjoy
my
last
date
actually
to
ask
everyone
we're
going
to
be
getting
together
for
lunch
at
noon.
I
think
at
60th
and
no
oh
tomorrow,
yeah.