►
Description
Meeting agenda: https://docs.google.com/document/d/1ushaVqAKYnZ2VN_aa3GyKlS4kEd6bSug13xaXOakAQI/edit#bookmark=id.mc1yty2f8e9v
A
All
right
welcome.
Everyone
today
is
Wednesday
the
20th
of
September
2023,
and
this
is
the
cluster
API
project.
Meeting
cluster
API
is
a
sub-project
of
the
kubernetes
Sig
cluster
life
cycle,
and
as
such,
we
follow
their
meeting
guidance,
which
basically
means
please
treat
everyone
as
you
would
expect
to
be
treated
and
explicitly.
Please
be
kind
to
each
other
and
also
please
raise
your
hand
if
you'd
like
to
talk
and
I
will
call
on
you.
A
So
at
the
beginning
of
our
meetings,
we
like
to
welcome
new
attendees
or
people
who
haven't
had
a
chance
to
say
hi
and
in
the
community
before
to
to
say
hi.
So
if,
if
that
sounds
like
something
you'd
like
to
do,
please
raise
your
hand
and
I'll
call
on
you.
A
Okay,
I'm
not
seeing
any
hands
go
up.
So
let's
move
on
to
our
open
proposal.
Readout
I
think
we
just
have
one
open
proposal,
but
I'm
not
sure,
there's
been
any
updates
there,
I,
don't
know
Jack
or
Richard
or
Fabrizio.
Is
there
anything
to
say
about
the
the
contract
changes
for
managed
kubernetes.
A
I
love
the
reference.
Thank
you,
okay.
Well,
let's
move
on
to
our
regular
agenda.
Then
I've
got
the
first
topic,
so
I
will
just
charge
right
into
it.
A
So
last
week
we
had
a
Meetup
of
the
cluster
API
folks,
who
are
interested
in
in
Carpenter
and
Carpenter
is
a
new,
auto
scaler
that
has
been
developed
by
AWS
labs
and
they
are
currently
in
the
process
of
negotiating
a
contribution
to
Sig
Auto
scaling
in
the
kubernetes
community.
So
there's
a
lot
of
interest
in
it.
We
had
a
great
meeting
last
week.
I've
got
a
link
to
the
recording
here.
A
If
anyone
would
like
to
review
it,
I
think
we
decided
at
the
end
that
that
there
isn't
enough
enough
interest
for
us
to
continue
this
research
and
this
investigation,
but
there's
a
few
details
that
we
kind
of
need
to
look
into
in
terms
of
you
know
what
we
might
want
to
do
and
how
we
might
want
to
go
forward.
A
So
I
think
we're
going
to
probably
set
up
a
meeting
Cadence
that
might
be
like
once
every
three
weeks
or
once
every
two
weeks
at
this
point
and
we'll
try
to
organize
when
that
might
be
and
I
think
you
know
Jack,
you
had
a
great
suggestion
before
of
kind
of
like
doing
it
right
before
this
meeting
or
something,
and
so
if
that
works
for
folks,
maybe
we'll
just
try
and
propose
that
and
I'll
put
together
a
proposal
for
the
next
meeting
of
this
community
and
then
maybe
we
can
make
a
decision
from
there.
A
You
know
how
we
want
to
go
forward,
but
I
think
we're
kind
of
at
a
slow
cadence
right
now
and
it'll
probably
pick
up
as
we
make
more
decisions,
so
yeah
I
don't
know.
Does
anybody
have
questions
or
comments
about
that.
A
Okay,
I'm
not
seeing
any
hands,
go
up
so
David
you've
got
the
next
topic
about
Cappy
operator.
So
please
take
it
away.
C
Yeah
I
just
was
I,
don't
know
lightly
mentioned
this
a
while
back
about
having
kind
of
an
alternate
quick
start
path
for
using
the
operator
and
I
mean
there's
quite
a
bit
of
differences
compared
to
where
the
quick
start
is
and
so
I
just
wanted
to
get
a
feedback
on.
C
You
know
before
a
PR
starts
kind
of
getting
whipped
up
like
what
that
might
look
like
off
the
surface.
I
was
thinking
of
having
you
know
us,
maybe
like
a
linked,
separate,
quick
start,
because
as
soon
as
you
get
to
you
know,
cluster
CTL,
then
everything
kind
of
changes
quite
a
bit
but
I
mean
it
is
possible,
obviously
just
to
try
and
do
other
things.
But
it's
already
it's
already
kind
of
messy
as
it
is,
and
so
I
just
wanted
to
get
feedback
on
that.
A
Yeah,
it
sounds
like
a
great
topic
to
kind
of
dive
into.
Does
anyone
have
thoughts
on
this
or
want
to
comment
or
questions
for
David.
A
All
right,
well,
I'm
I'm
not
seeing
any
hands
going
up,
David
So
this!
This
might
be
the
kind
of
thing
where
either.
Maybe
we
want
to
open
an
issue
on
the
Cappy
operator,
repo
to
kind
of
maybe
have
a
little
more
of
an
asynchronous
discussion.
I
mean
my
general
feeling
is
the
more
quick
start
docs
we
can
put
together,
probably
the
better
right.
So
if
we
can
clean
that
up
for
the
Cappy
operator,
that
would
be
awesome.
That
said,
I'm
not
an
expert
with
the
Cappy
operators.
A
D
C
E
F
F
E
A
A
All
right
yeah,
so
Fabrizio
is
saying
yeah.
If
this
is
about
the
Cappy
book,
Let's
have
an
issue
in
Cappy.
So,
okay
I
think
that's
probably
the
action
item
here,
I'll
make
a
note
in
the
docs
or
in
the
agenda.
A
D
Yeah,
thank
you
very
much
and
thanks
again
for
hosting
Mike
I
appreciate
it
quick
one.
So
a
follow-up
of
the
last
week
I
have
submitted
request
for
us
lot
at
the
contributor
Summit
in
Chicago.
Yeah
I
will
follow
up
as
soon
as
I
have
an
answer.
A
Cool
sounds
good
I'm
excited
to
see
what
what
sessions
we
shake
out
with
there
thanks
for
brizio
Cecilia
you've
got
the
next
topic
about
the
Sig
cluster
life
cycle
self-assessment.
F
Yeah,
so
this
is
both
a
PSA
and
I
guess:
I
was
going
to
offer
that
we
do
this
together
now,
so
this
big
cluster
life
cycle
there's
are
asking
every
project
in
the
Sig
to
fill
out.
This
survey
by
I
believe
the
deadline
is
October
15th
and
this
survey
is
essentially
just
a
meant
to
gather
information.
We
already
did
one
like
this
in
2021,
and
it's
meant
for
us
to
gather
information
about
the
different
projects
what's
going
on,
what
are
the
main
challenges?
F
Where
can
we
help
and
ahead
of
kubecon
also
get
some
ideas
for
like
discussions
and
things
that
we
should
bring
up
so
yeah?
So,
first
PSA,
if
you
are
a
maintainer
of
a
project
or
you're,
actively
contributing
to
another
project
besides
cluster
API,
make
sure
that
you
nudge
the
maintainers
to
fill
out
the
survey
as
well
and
then
in
terms
of
us
doing
this
for
Cappy
I,
think
maybe
we
can
do
this
together
and
pray
through
it.
Since
that
way,
we
can
all
you
know,
discuss
what
to
answer.
A
F
F
I
think
that's
that's!
Okay,
we'll
we'll
deal
with
the
answers.
If
there's
more
than
one
answer,
but
yes,
this
is
this
is
the
one
per
project.
The
goal
is
to
like
kind
of
evaluate
project
health,
so
the
the
email
did
say
that
the
ideas
that
maintainers
would
get
together
either
in
office
hours
or
somewhere
else
and
fill
out
the
response.
B
Cool
can
we
can
we
set
up
us
like
a
maybe
a
15
or
30
minute
slot
to
do
this
and
then
welcome
contributors
to
the
project
because
it
sounds
like
this
is.
This
is
requests
from
Project
maintainers
to
the
Sig
chairs
and
Sig
Tech
lead?
Is
that
right.
B
I'm
just
trying
to
think
about
how
we
can
sort
of
formally
structure
the
feedback,
so
the
maximum
amount
of
folks
who
want
to
contribute
to
this
can
do
so.
If
we're
going
to
do
it
collaboratively
in
real
time
has
like
one
group
effort
as.
B
F
Maybe
maybe
if
Mike
goes
to
the
next
page,
it
will
be
more
clear.
This
should
be
fairly
like
straightforward.
It's
just
the
Sig
leads
are
asking
for
a
few
questions
about
the
project
and
I.
Think
most
of
them
are
factual,
not
opinion
based.
So
it's
not
about
Gathering
feedback.
It's
more
like
tell
us
more
about
the
project
and
what
it's
doing
so
I
I
mean
I'm
happy
to
schedule
this
for
next
office
hours.
F
F
B
A
F
F
A
We
we
have
had
some
of
these
meetings
right.
We
we
do
release
planning.
A
Do
we
have
a
retrospective
meeting?
I,
don't
know
about
that.
D
G
A
D
Yeah
we
did
a
lot
for
the
CI
okay.
G
D
I
would
say
not
not
at
least
planning,
we
never
decide
what
goes
in
our
at
least
foreign.
A
So
what
other
ad
hoc
meetings
have
we
run?
I
mean
we
put
the
one
from
last
week,
but
what
else
could
we
put
here.
D
The
current
proposal
from
Jack,
which.
F
G
A
G
Yeah,
we
also
don't
have
office
hours
but
yeah.
Let's
just
move
on
this
way.
D
G
A
A
Any
other
anything
else
we
should
put
here
Stefan
is
asking
what
was
the
kubecon
planning
Maybe
Jack?
You
brought
that
one
up.
A
If
anyone
remembers
more,
just
add
them
to
chat
and
we'll
come
back
here
in
the
last
six
months,
have
you
reviewed
or
updated
your
contributing.md
I
I
want
to
say
yes,
but
I
can't
confirm
it's.
A
G
Maybe
it
would
be
good
if
someone
has
time,
maybe
just
to
reread
it
at
some
point
and
just
see
if,
regarding
the
actual
contribution
parts,
we
should
do
some
updates
I
mean
the
last
changes
we
did
was
you
should
like
go
up
on
policy.
Cherry
pick
policy
I
mean
it's
all
interesting,
but
it's
not
really
that
useful
to
new
contributors,
but
that's
super
important,
that's
more
like
how
to
open
a
PR
and
that
sort
of
stuff
cool.
A
Okay
and
yes,
I,
agree
with
what
you're
saying,
though
Stefan
like
having
a
review
of
that
kind
of
regularly
is
probably
a
good
idea.
Maybe
that's
what
this
is
kind
of
implying.
A
Okay
in
the
last
six
months,
have
you
reviewed
or
updated
your
project
roadmap
I
feel
like
this
is
kind
of
a.
This
is
a
touchy
subject
around
here.
G
G
A
A
As
I'm
seeing
comments
from
Chad,
we
should
do
this
more
often,
it's
fun,
okay.
Well,
someone
will
have
to
come
up
with
more
forms
for
us
to
do
as
a
group
as
a
group,
then,
okay,
is
there
an
onboarding
and
growth
path
for
contributors
to
your
project.
I
think
this
is
an
emphatic
yes
as
a
project.
What
programs
do
you
participate
in
for
new
contributors.
D
D
D
A
D
G
It
remove
anyone
because,
usually
we
just
add
people
to
be
honest,
yeah.
G
Because
we
moved
into
another
room,
you
know
we
have
like
removers
for
sub
parts
of
the
projects
and
then
like
top
levels.
So,
for
example,
we
moved
Christian
I,
don't
know
if
you
actually
moved.
Yes,.
G
G
I
think
that
history
is
not
correct,
we
definitely
updated
it.
We
probably
should
look
at
the
owner
aliens.
F
A
A
A
Okay,
yeah:
that's
what
we
were
just
looking
at:
okay,
all
right
as
a
project
team.
Do
you
need
help
at
any
area
now,
I.
G
A
very
strong
yes
for
my
side
that
we
need
more
reviewers
we're
going
up
towards
like
60,
70,
open
PRS
and
the
people
who
are
regularly
reviewing
it
just
basically
overloaded,
all
the
time
to
be
realistic.
A
F
G
Pr's
but
I
think
that's
just
a
net
that
doesn't
really
matter.
A
G
B
Yeah
I
think
Micah
speaks
really
directly
to
you.
I
think
your
efforts
and
other
folks
efforts
with
autoscaler
and
Carpenter
are
nice
integration
points,
so
they
bring
in
community
members
from
other
projects
and
there's
like
an
integration,
and
so
now
that's
a
that's
a
nice
way
of
importing
a
lot
of
expert
contributions.
I.
F
D
Is
also
we
apply
God
for
good,
first
issue
label.
We
keep
applying
our
disabled
one
possible.
G
E
A
Okay,
what
are
the
initiatives
that
should
be
highlighted
lauded
that
your
project
is
proud
of.
D
I
think
that
we
have
for
sure
the
machine
pool
machine
effort.
D
A
lot
of
people
are
not
investing.
A
lot
of
energy
and
I
won't
also
praise
their
work
on
improving
a
release
tooling.
A
What
was
what
was
the
other
one
for
brazier.
G
Yeah,
similar
to
the
first
one
I,
would
add
the
integration
work
of
cluster
class
and
machine
pro.
It's
basically
a
huge
effort,
and
there
are
now
a
lot
of
people
helping
with
getting
the
test
coverage
up.
G
G
G
A
D
A
A
D
Yeah
I
think
that
maybe
observability
and
dressing
could
use
some
help
Stefan.
What
do
you
think.
D
G
I
would
I
would
probably
I
mean
right
now,
I
think
in
the
sense
of
like
help
wanted,
and
you
can
I
mean
you
already
have
everything
in
place
that
you
can
just
contribute
more
stuff.
It's
probably
mostly
logging,
so
I
think
Matrix
is
pretty
much
fine,
locking.
We
have
like
an
issue
a
number
of
issue
of
like
long
tail
stuff
like
hey.
We
should
improve
every
controller.
G
I.
Think
tracing
is
like
a
bit
of
like
basically
need
like
one
first
PR,
to
establish
the
pattern,
and
then
we
have
a
long
tail
of
doing
it
everywhere
on
which
is
basically
on
I,
mean
I,
don't
know
if
anyone
else
wants
to
pick
it
up,
but
that
one
first
on
first
PR
is
pretty
much
top
of
my
illustrator
and.
A
Observability,
though
Stefan
you
were
saying
like
logging,
is
the
big.
G
G
A
D
A
G
Basically,
like
an
entire
like
refactoring,
let's
start
from
scratch
and
build
something
like
yeah
I,
don't
know
like
kubernetes
has
like
this
entire,
like
website
thingy
going
on
right
and
ours
is
just
we
have
a
heap
of
documentation
and
just
add
more
and
more
and
more,
but
the
structure
is
getting
more
and
more
Messier.
D
G
A
D
D
A
A
A
Okay,
yeah,
it
looks
like
we
got
them
all
there
have
you
got
some
suggestions
for
improving
cooperation
and
coordination
at
the
Sig
level.
D
A
Is
that
does
that
capture
it?
Yes,
okay,
cool,
any
other
suggestions
that
we
would
like
to
share
with
the
at
the
Sig
level
about
cooperation
and
coordination.
A
A
A
Agreed
Cecile,
I
think
yeah
I
think
we
hit
like
15
to
20
minutes
so
next
time.
Let's
see
if
we
can
hit
15
minutes,
you
know
with
three
unit
I'm
just
kidding
okay,
so
thank
you
Cecile
for
bringing
that
up.
I
feel
better
that
we've
gotten
that
done
now
I
see
David
is
adding
a
topic
as
we
talk
here.
C
I
saw
the
links
to
what
you
had
and
those
are
more
specific
features,
and
so
I
see
that
we've
been
in
V1
beta
one
listing
it
has
in
bracket
stable
for
a
while
and
I'm
just
kind
of
curious,
because
I
actually
did
have
a
comment
from
someone
who
was
looking
at
cluster
API,
and
they
just
mentioned
oh
well,
cluster
apis,
V1,
beta
one
and
then
I
have
to
like
explain.
Well,
no,
that's
stable
and
all
that
and
that's
okay,
but
it's
just
it
is.
C
It
is
an
interesting
question
of
like
we've
been
at
V1
beta
one
for
what
a
year
and
a
half
or
I
don't
know
like
since
many
releases
and
so
I'm
just
kind
of
curious,
like
if
I,
don't
know,
reasoning,
rationing
around
that
I
think
that's
a
little
separate
than
the
actual
features
out
of
experimental
threads
that
you
had
there.
C
D
Oh
I
think
the
answer
is
nonsense
in
the
sense
that
our
project
like
kubernetes,
but
also
cluster
API
I,
think
that
it
people
should
understand
that
the
project
different
part
of
the
project
will
have
different
part
of
maturity.
This
is
why
we
declared
the
code
base
is
B1,
but
the
API
is
still
Alpha,
and
this
is
why
we
have
experiment
and
etcase.
D
So
let
me
say:
well:
when
people
ask,
we
simply
have
to
explain
a
because
the
API
is
so
big
that
different
parts
are
different.
I
have
different,
have
different
levels
of
maturity
and
the
situation
is
continuously
evolving.
It
is
part
of
the
answer.
The
second
part
of
the
answer
is:
why
do
why
don't
we
move
to
we?
We
keep
upgrading
our
API
version,
so
we
have
a
I
think
that
the
answer
is
is
kind
of
complex,
also
here
so
in.
D
This
is
my
personal
opinion
and
among
them
there
are
a
couple
which
are
really
interesting.
For
instance,
we
can
improve
our
API
to
to
make
it
more
it
up
friendly
I,
think
to
how
we
handle
honor
refs
for
machine
deployment
or
how
we
we
handle
reference
to
the
objects.
D
To
to
the
next
API
version,.
D
The
the
other
side
of
the
coin
is
that
I
think
API
versioning
copy
as
a
ripple
effect
not
only
require
a
lot
of
working
copy,
but.
D
Ultimately,
it
requires
words
and,
let
me
say
a
wider
consensus
in
the
community
and
currently
no
one
is
pushing
for
this
weapon.
So
is
an
open
source
project.
When
someone
commits
to
to
make
things
happen,
they
happen.
Otherwise
we
stick
2V1
beta
one.
E
G
Yep,
one
challenge
that
you
will
have
is
basically
figuring
out
what
we
would
want
to
do.
You
know,
probably
we
want
better
to
I
think
we
shouldn't
go
to
V1
from
base,
so
it
shouldn't
go
from
even
better
one
to
V1.
We
just
have
too
much
stuff
that
you
want
to
change
so,
but
okay,
different
discussion,
so
I
think
what
you
have
to
figure
out.
Essentially,
what
do
you
want
to
do?
G
I
think
we
have
at
least
like
30
40
50
issues
around
like
API
changes,
and
then
it's
also
a
question
of
timing,
so
I
think,
for
example,
right
now,
the
next
one
or
two
months
will
be
probably
a
good
period
to
think
about
what
we
want
to
do
so
that
we
can
then
Target
it
for,
for
example,
1.7
assuming
we
have
the
bandwidth
and
and
all
that
sort
of
stuff
and
what
would
be
probably
a
bad
time
is
like,
let's
say
two
months
before
a
minorities,
because
in
that
time
frame
you're
not
getting
enough
done
to
justify
beta
2,
I.
G
Think
so
I
think
we
shouldn't.
If
we
do
it,
we
should
do
it
like
early
in
a
recycle
or
even
like
start
planning
in
the
previous
release
cycle,
so
that
we
don't
have
to
just
rush
in
like
three
or
four
changes
in
one
or
two
months,
and
everything
else
just
has
to
wait
for
even
better
free
that
sort
of
stuff
yeah.
C
Thank
you,
one
other
I,
think
other
than
just
the
user,
bringing
it
up.
This
actually
kind
of
got
raised
on
on
the
cap
Z
side,
because
we
had
a
end-to-end
test
trying
to
upgrade
from
1.0,
and
so
you
know
I
think
that's
the
other
factor
of
you
know
our
support
of
upgrade
versions
based
on
the
API
version.
So
but
yeah,
that's
kind
of
a
tangent
related
thing.
D
G
D
That
we
really
need
to
keep
going
if
someone
wants
I
will
I
will
link
also
the
thread
that
we
had
on
the
on
the
API
version
issue.
This
is
a
nasty
problem
that
our
API
has
historically
and
is
getting
more
and
more
relevant
for
users,
because
the
adoption
of
GitHub
tools
of
server-side
apply
is
growing,
etc,
etc.
So.
D
D
C
Yeah
I
think
part
of
it
is
part
of
his
perception
too
right.
Just
like
you
know,
we
have
the
stable
next
to
V1
beta
one
and
the
and
those
two
things
kind
of
feel
mentally
different
than
what
you
know
is
listed
in
the
the
kubernetes
definition.
The
future
Gates
Right,
stable
and
stable
beta
is
beta.
You
know,
but
yeah
I
I
understand.
Thank
you
for
the
reasoning.
A
Okay
and
I
Echo
what
fabrizo
was
saying
good
topic,
good
discussion,
yeah,
please
Stefan,
go
ahead.
G
Yeah
I
think
realistically
we're
not
at
that
point.
We
are
that
we
are
like.
We
won
stable,
to
be
honest,
there's
just
too
much
stuff
going
on
so
yeah
for
whatever
definition
of
stable
we
have
I.
Think
we
don't
have
that
like
B1,
we
keep
it
like
the
same
for
two
or
three
years
level
of
stableness
stabilities
are.
C
Yeah
I
think
it's
good
that
I
think
it'd
be
good
to
just
you
know,
because
it
sounds
like
a
lot
of
you
have
ideas
in
your
head,
what
view
one
would
look
like
and
even
if
it
is
30
issues
or
whatever
like,
and
it
takes
us
a
period
of
time
to
get
there
but
I
think
it'd
be
good
to
just
kind
of
you.
E
C
C
D
I
think
that,
let
me
say
a
definition
is
stableness
is
always
difficult
in
cluster
API
I
think
that
we
are
stable
in
the
sense
that
we
have
concept
like
I,
don't
know
the
contract
which
are
well
defined
and
and
we
keep
and
they
will
not
change
in
in
the
short
term,
and
we
have
Primitives
like
machine
machine
deployment
and
so
on
and
so
forth,
which
which
are
stable
access
Etc.
So
from
this
point
on
view,
I
think
and
considering
the
fact
that
we
provide
always
provide
upgrade
paths
from
one
version
to
the
other.
D
We
we
are
stable
and
people
are
using
it
in
production.
We
we
don't
have
so
from
we,
we
don't
have
a
report
out
of
big
issue,
etc,
etc.
So
the
majority
of
the
project,
considering
that
in
in
the
Sega
we
have
80
companies
that
are
Building,
Product
or
using
cluster
API,
reads
a
lot
and
we
see
continuous
grow
in
term
of
number
of
Provider,
etc,
etc.
D
A
So
I,
just
I'll,
just
read
this
out
from
the
chat
you
know
one
thing
Stefan
is
commenting
about
is
that
you
know
the
problem
with
V1
and
kubernetes.
It
implies
these
long
guarantees
and
I.
Guess
that's
something
else.
To
kind
of
think
about
here.
I'm
really
inspired
to
hear
this
kind
of
discussion,
because
I
think
it's
cool
like
like
by
the
time
we
actually
do
get
to
V1
as
I.
A
Will
we're
going
to
be
so
stable
and
have
such
a
great,
a
great
history
of
kind
of
integration,
and
you
know
continuous
integration
and
and
processes
and
whatnot
so
yeah
we
we
might
be
able
to
be
the
stabilist
V1
when
we
actually
get
there
but
I.
It's
really
cool
just
to
hear
the
thoughtful
conversation
around
this.
A
Does
anyone
else
have
questions
or
comments.
A
I
see,
I'll,
just
read
a
comment
from
Joel
here
in
the
in
the
chat.
I
think
it
would
be
great
to
do
a
thorough,
API
conventions
review
as
we
go
through
the
next
version
as
well.
A
Yeah
I
think
and
I
agree
like
I
think
that
does
sound
good
okay.
If
there
is
no,
if
there's
no
further
comment
on
that
topic,
then
we
will
move
into
the
provider
updates.
A
Okay,
John
John
H.
Please
take
it
away.
E
Yeah
so
cap
Z
1.11.0
was
just
released
yesterday
and
that's
our
first
release
that
includes
Cappy
1.5
and
we're
also
bundling
Azure
service
operator
for
the
first
time
and
using
that
as
a
dependency
and
we've
gotten
rid
of
all
of
our
old
deprecated
SDK
references
now
we're
all
in
the
new
azure
sdks
so
yeah,
that's
it
for
the
v11
release
and
we
also
have
a
new
patch
release
out
for
v1.10.
A
All
right
great
to
hear
thanks
for
the
updates,
all
right
that
brings
us
to
the
end
of
our
agenda.
Are
there
any
other
kind
of
ad
hoc
topics
that
people
would
like
to
discuss
now
or
anything
we
should
say
before
we
go
here.
A
In
three
two
one,
all
right,
thanks
everybody
for
showing
up
and
we'll
see
you
all
around
next
week.