►
From YouTube: Kubernetes SIG CLI 20220907
Description
Kubernetes SIG CLI bi-weekly meeting on September 7th, 2022.
Agenda and Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=kix.4g7uha1bhyiu
A
A
Let's
keep
that
in
mind
and
in
addition,
there
is
a
different
process
that
we're
going
to
organize
this
or
sig
release
is
going
to
organize
these
enhancements,
and
so
I
put
in
the
one
link
for
the
you
have
to
be
signed
in
for
github
for
the
automated
github
project
board,
and
so
the
leaders
of
the
six
cli
will
be
adding
labels
to
caps
in
order
for
them
to
automatically
be
included
in
this
automated
automated
project
board,
so
that
the
google
sheets
spreadsheet
that
what
that
used
to
organize
our
caps
is
out,
and
so
we're
going
to
try
something
new.
A
So
our
code
freeze
for
this
particular
release,
is
going
to
be
happening
on
wednesday
november
9th
and
the
actual
release
is
in
early
december
december,
6th
on
a
tuesday.
A
So
so
now
we
have
the
information
we
need
in
order
to
to
organize
our
deadlines,
have
fun
so
for
kubecon,
which
is
coming
up
in
october
24th
through
the
28th
we're
going
to
provide
some
awards
to
our
outstanding
six
eli
contributors,
and
we
want
to
get
feedback
from
you
from
the
community
on
who
you
think
some
outstanding
contributors
have
been
to
the
six
eli
for
the
last
year,
so
we
actually
have
very
short
notice
on
this.
A
We
apologize,
but
we
only
have
until
tomorrow,
end
of
day
in
order
to
get
this
feedback
to
swift,
sig
contrib
x,
and
so
what
we're
asking
is
that
you
please
reach
out
to
myself
or
katrina
or
mate
or
eddie
through
slack
within
the
next
day,
or
so.
If
you
think
you'd
like
to
mention
someone
who
who's
been
a
strong
contributor
for
the
last
year,
this
is
for
the
contributor
awards
that
should
be
happening
at
kubecon
shortly.
A
So
yeah
just
reach
out
to
some
of
to
one
of
us
in
leadership
and
we
will,
through
slack
and
and
we
like,
I
said
we
only
have
a
day.
So
we
apologize
for
that.
A
Okay,
why
don't
we
move
on
to
the
next
item,
which
is
that
the
the
steering
committee
election
is
now
open?
I've
put
a
couple
links
in
there,
so
the
list,
the
voting-
is
open
until
the
end
of
the
month
september
30th.
A
A
So
before
I
move
on
those
are
the
announcements
that
I
thought
should
be
announced,
but
is
there
anything
else
anyone
else
thinks
should
be
announced?
Is
there
anything
else
you'd
like
to
bring
up
to
the
six
eli.
A
Okay,
so
the
next
item
is
that
we're
going
to
introduce
new
members.
So
if
you
are
a
if
you're
new
to
the
6cli
or
you
haven't
been
here
for
a
while
and
you,
this
is
your
opportunity
to
meet,
formerly
meet
your
six
cli
colleagues,
and
if
you
don't
want
to
do
this,
that's
fine
too,
but
if
you'd
like
to
say,
hi
and
raise
your
profile
with
your
colleagues,
now
is
your
opportunity
to
do
it.
So
if
anybody
like
to
pipe
in
go
ahead.
A
So
let's
move
on
to
the
topics
and
the
first
one
is
brian-
is
going
to
talk
about
internationalization
and
I'm
going
to
try
to
bring
up
the
link.
Okay.
Is
that
visible
right.
B
Yes,
yeah
so
yeah,
so
this
this
is
a
pull
request
that
was
opened.
I
don't
know
how
long
ago
recently
I
guess
10
days
ago,
and
I
don't
know
that
the
pull
request
itself
is
so
the
spirit
behind
the
pull
request
is
that
our
translations
are
incomplete
and
when
they
are
so
incomplete
for
a
certain
language.
So
in
this
case,
japanese,
that
it's
just
not
a
good
experience,
and
so
the
the
pull
request
was
to
take
out
internationalization,
which
I'm
not
proposing,
but
I
guess
the
the.
B
I
think
the
point
is
valid,
that
and
if
you
scroll
down
sean
to,
I
asked
him
for
if
he
could
post
an
example
or
maybe
there's
an
example
in
the
ed
in
the
yeah
scroll
down
he.
He
gave
some
examples
down
at
the
bottom
here
yeah
next,
please
expand
one
of
that.
Maybe
that
first
little
carrot
there
in
yeah
there
you
go,
and
so
you
can
see
here
like
most
of
it
is
english,
but
then,
like
one
or
two
of
the
help
texts
are
are
in
japanese.
B
B
A
So
so
I
have
a
couple
of
points
that
I'd
like
to
make
number
one.
I
believe
we
have.
A
We
have
some
support
from
the
entire
cncf
or
from
kubernetes,
where
we
initially
solicited
some
help
from
a
separate
committee
to
get
us
the
translations,
and
so
this
this
also
obviously
looks
like
it's
not
helpful.
A
I
think
you
need
to
get
like
a
pretty
large
set
of
of
these
of
this
text.
Translated
before
it's
gonna
actually
be
useful,
but
we
we
can
actually,
I
think,
ask
we,
don't
have
to
do
it
ourselves
there.
I
think
that
there's
like
some
resources
that
we
can
appeal
to
in
order
to
to
complete
this
or
do
a
better
job
and
yeah.
I
guess
that's
all.
The
only
point
I
wanted
to
make
is
that
you
know
we're
not
the
ones
that
would
actually
organize
these
translators.
C
This
is
an
interesting
topic,
for
example,
my
native
language
is
turkish
and
I
can
translate
all
of
cube
control
commands
to
turkish,
but
I
need
to
find
someone
to
approve.
My
peer
also
should
know
turkish
to
evaluate
it
right.
A
A
So
the
the
the
translations
themselves
are
text
just
text
files
and
so
and
I
to
be
honest,
I'm
not
sure
if
we
actually
have
the
permissions
to
approve
them
because
they're
in
a
strange
directory
or.
C
A
A
A
D
But
like
I
don't
know
how
to
approve
that
exactly
so,
machia
recommended
that
I
that
I
try
sig
dogs,
because
they
have
a
lot
of
folks
who
work
on
internationalization
for
the
documentation
more
generally,
and
I
kind
of
wonder
if
they
would
have
an
opinion
about
this
as
well.
A
A
I
think
that
we
should
probably
come
up
with
some
percentage
that
we
agree
makes
sense
to
to
be
able
to
approve
a
particular
language
and
and
then
reach
out,
maybe
to
sync
docs,
to
to
see
what
resources
they
have
for
translating,
because
I'm
pretty
sure
that
they
have
to
translate
all
all
the
docs
and
they
may
know
the
professional
translators
for
which
particular
languages
which
ones
that
they
could
lean
on
and
which
ones
that
we'd
be
able
to
solicit
in
order
to
get
a
full
translation,
or
at
least
close
to
a
full
translation.
B
Yeah
and
I
think
there's
some
probably
they
have
more
there's
a
few
down
there,
but
I
guess
another.
It
brings
up.
Another
thing
that
comes
to
mind
is,
I
know
like
if
times
that
I've
changed
the
text
of
something,
and
I
I
see
the
i18n
marker
in
the
code
or
the
function
that
converts
it,
but
it's
not
really
something
I
think
about
like
hey.
I
need
to
go.
B
Tell
anybody
who's
translated,
this
text
that
I
just
changed,
that
they
need
to
re-translate
it,
and
I
don't
know
what
the
right
way
is
to
prompt
that
or
if
there's
some
review
period
that
we
need
to.
Like.
I
mean
it's
easy
for
me
to
say
I
guess
it's
great,
that
we
have
resources,
and
maybe
we
need
to
be
more
connected
to
those
resources
that
will
do
the
translations,
so
we
can
periodically
ask
them
if
they
would
review
or
if
we
had
some
way
of
telling
them
which
things
changed.
B
We
could
target
that
and
say:
hey.
We
changed
these
five
things.
Can
you
go?
Please
update
the
translations
and
I
I
don't
know
what
that
process
is.
I
feel
like
there's,
probably
not
a
good
answer
there,
but
in
an
ideal
world
there
would
be
some
trigger.
That
would
say
these
are
the
things
you
need
to
look
at
again.
A
Yeah,
I
would
say
that
there
may
even
be
like
an
extra
label.
We
should
add
to
a
pr
that
said:
needs
translation
in
fact,
I'll
put
that
on
the
in
the
meeting
notes
and-
and
if
it
says,
needs
translation,
then
we
know
that
at
least
in
the
future-
maybe
not
in
that
particular
pr,
but
the
future
prs.
A
You
know
this.
It's
touching
text
that
needs
to
be
internationalized,
or
that
has
been
internationalized
previously,
that
we
need
updates
on.
C
D
You
know
you
might
if
every
single
time
one
of
the
strings
are
touched,
we
need
to
recruit
an
army
of
people
to
translate
all
of
these
different
languages,
and
it's
probably
a
small
string.
It
could
make
more
sense
to
have
well,
ideally
be
like
automation
that
dispatches
to
like
paid
translators
that
could
be
reliably
available
to
make
this
happen
when
whenever
we
need
it,
otherwise
I
just
don't
see
how
the
the
translations
individually
aren't
going
to
rot
whether
or
not
we
label
it.
A
So
so
why
don't
I
and
the
leadership
take
on
the
the
role
of
investigators
to
see
how
this
is
it's
been
so
long
since
I've
touched
this,
I've
forgotten
the
process,
but
it's
we
could
definitely
raise
the
profile
of
this
particular
process
and
see
that
we
could
do
see
if
we
could
do
better.
This
just
hasn't
really
been
on
anybody's
radar,
at
least
not
on
my
radar.
B
And
I
haven't
even
looked
up.
I
haven't
spent
a
lot
of
time
looking
at
how
the
internationalization
works.
I
know
it's
got
the
english
text
in
there
and
maybe
that's
why
internationalization
gets
broken,
because
if
we
go
and
change
the
english
text
and
then
it
no
longer
can
map
to
it,
can't
find
what
it's
supposed
to
map
to.
So
then
it
just
falls
back
to
that
english
text,
so
it
might
just
be
a
case
of
being
aware
of,
or
it
seems
almost
seems
like
the
international
it
when
something
is
internationalized.
B
It's
it's
like
english
should
be
also
a
language,
that's
in
internationalization
and
then
there's
like
a
token
that
just
points
to
that
and
that
token
never
changes.
So
it
could
be
like
you
know,
the
token
would
be
like
run
help
or
something
and
that
and
that
it
would
go
look
up.
The
english
version
of
run
help
from
english.
So
I
think
that
maybe
that's
what's
missing
is
like
english
is,
is
the
key
as
opposed
to
english
being
a
language
just
like
all
the
other
languages.
B
A
A
This
is
the
japanese
text.
This
is
the
turkish
text.
This
is
the
english
text.
So
so,
unless
we
code
the
variables
the
string
variables
to
have
this
particular
property,
which
I
again
I
haven't
looked
at
it
in
a
long
time,
then
it's
it.
It
won't
be
translatable.
A
C
Yeah,
I
think
the
problem
still
stays
the
same.
For
example,
if
you
have
a
text
to
something-
and
you
add
optional
in
english,
it
should
discard
the
other
languages
that
they
don't,
because
they
don't
have
it.
So
I
don't
know
if
we
can
help
this
if
we
had
the
key,
because
right
now
the
key
is
the
whole
string
is
the
key
okay.
A
B
Yeah
it
does,
and
I
can
do
some
more
research
into
it
as
well
and
maybe
come
back
with
some
more
information,
so
so
yeah.
I
think
there
was
some
good
discussion
today
and
I
learned
that
that
we
have
resources
available
outside
of
our
team
that
can
do
the
translations
and
it's
a
good
starting
conversation.
I
guess
if
other
people
come
up
with
ideas
we
can.
That
would
be
great
for
next
time
too.
A
And,
and
what
do
we
think
about
kind
of
reverting
translations
that
are
really
sparse
and
probably
not
very
helpful?
I
I
would
support
that,
like,
in
particular,
the
japanese
translations
for
control.
Look
so
sparse
as
to
be
not
helpful.
C
Because
I
think
it's
the
small,
mostly
the
small
updates,
when
somebody
just
updates,
maybe
adds
a
dot
to
the
string.
It
discards
the
translation
completely.
So
maybe
the
translation
was
there
and
just
somebody
needs
to
make
sure
it's
still
the
correct
one.
So
most
of
them
were
discarded
over
time.
If
there
is
no
maintenance
of
it.
A
Okay:
okay,
I'll
put
this
item
on
the
on
our
next
meeting
and,
and
we
should
investigate
and
look
in
deeper
into
how
we
can
we
do
better
here
and
I'll
put
off
make.
We
should
put
off,
I
think,
making
any
decisions
on
whether
or
not
we
remove
these
translations
until
that
time
at
the
earliest.
Does
that
sound,
reasonable.
B
Yeah,
it
sounds
good
to
me
what
I'm
also
curious.
I
guess
maybe
it's
just
some
takeaway
too
is
like
maybe
just
look
at
some
other
tools
in
the
ecosystem
and
what
they
do
for
internationalization.
Do
they
attempt
it?
Is
it
worth
doing
and
that
and
that's
I
don't
know,
that's
a
question
I
can
answer,
but
is
this
something
worth
doing
and
if
it
is,
how
do
other
tools
do
it.
A
Better:
okay,
I'm
going
to
put
that
this
item
on
the
next
meeting,
so
we
can
revisit
it
so
katrina.
Would
you
like
to
talk
about
pedal
customize?
What
we're
going
to
do
for
v5
of
customize.
D
Yeah
so
where
this
discussion
comes
from
is
there's
a
series
of
things
in
issues
recently
that
came
to
the
attention
of
myself
from
the
other
maintainers,
where
somebody's
reporting,
something
as
a
bug
that
I
would
say,
is
a
long-standing
behavior
that
the
maintainers
agree
is,
is
incorrect
or
harmful
so
similar
to
some
things
that
we
see
on
cube
control
for
sure.
D
The
most
recent
example
is
one
where
one
of
the
transformer,
so
just
a
piece
of
functionality
that
you
can
that
you
can
enable
in
your
customization
will
silently
know
up,
whereas
the
reporter
and
and
our
opinion
is
that
it
should
actually
throw
an
error
if,
if
the
target
was
missing
so
that
the
person
who
is
writing
that
you
know
they
asked
us
to
do
something,
and
then
we
weren't
able
to
do
it.
So
so
that
should
be
an
error.
D
But
that
would
that
would
break
people
who
were
relying
on
the
silent
know
for
whatever
reason,
because
it's
been
there
for
a
long
time.
So
because
customize
is
built
externally
and
we
are
a
less
mature
piece
of
software
right
where
beta
quality
technically
one
option.
D
That
comes
to
mind
is
that
we
could
flip
that
behavior
and,
like
we
cut
a
v5,
run
before
right
now
and
we
could
fix
the
behavior
with
that
and
then
folks,
you
know
when
you,
when
you
cut
a
new
major
version,
they're
prone
to
noticing.
D
You
expect
there
to
be
a
breaking
change
right,
but
that
doesn't
really
work
for
cube
control,
customize
quite
so
easily,
because
cube
control
itself
is
obviously
not
going
to
inherit
that
that
major
version
bump
we
as
of
two
releases
ago,
expose
directly
what
version
we're
embedding.
So
you
can
go,
keep
control
version
and
you'll
see
that
the
customized
version
is
whatever
we
brought
in
so
yes,
technically
they.
They
will
be
able
to
check
that.
D
But
my
question
for
the
sig
is
whether
or
not
we
would
consider
that
acceptable
like
if,
if
we
fixed
a
behavior
like
that
made
a
big
loud
release,
note
customized
v5.
This
thing
that
before
failed
silently,
will
now
throw
an
error
et
cetera.
We
have
a
short
ish
list
of
things
that
we'd
like
to
change
and
then
had
cube
control,
customize,
updated
to
version
five
and
the
cube
control,
release,
notes,
and
you
know
the
version's,
showing
with
cube
control
version.
Is
that
enough?
D
Or
are
we
effectively
unable
to
make
changes
like
that
because
of
the
crew
control
integration.
A
I
I
think
we
have
to
be
able
to
to
update
customize,
so
I
think
that
customizes
in
a
very
different
place
than
this,
this
is
not
pure
coup
control.
As
you
mentioned,
it
is
an
external
binary,
that's
going
to
be
executable
through
control,
and
I
think
you
have
to
be
able
to
to
update
behaviors
and
customize.
A
Yeah,
I
understand
how
you'd
want
to
be
more
conservative
when
you're,
invoking
it
through
control,
but
but
I'm
gonna.
I
would
vote
that.
You
would
have
to
be
able
to
to
make
fixes
of
this
nature
and
doing
it
on
when
you
ship,
major
versions
of
customize
seems
reasonable
to
me.
A
I
don't
know
how
we
would
how
we
normally
communicate
that
we're
going
to
update
control
customize.
Actually,
actually
we,
when
we
got
to
work
for
customized
version
four
was.
It
was
really
out
of
date
for
the
longest
time
and
was
quite
a
bit
of
work
that
you
guys
all
put
in
to
get
it
to
work
with
version
four
of
customize,
and
I
don't
that
that
wasn't.
A
Yeah
that
wasn't
broken,
that
was,
you
know.
We
we've,
I
kind
of
feel
like
we've
done
this
before,
where
we've
updated
the
version
of
customize,
and
there
was
actually
some
pretty
significant
functionality
changes,
so
I
I
would
think
that
you
would
be
able
to
to
do
that
again.
What
do
you
think
katrina.
D
Yeah
the
precedent
is
interesting.
It's
it's
not
as
clear
as
I'd
hoped.
Natasha
pointed
out
that
when
we
made
that
giant
pr
to
upgrade
from
v2
to
before
some
breaking
changes
were
identified,
as
must
revert.
Basically,
there
was
in
the
customization
api
itself.
There
was
something
that
used
to
be
plural,
that
no
it
used
to
be.
D
It
was
originally
plural
by
v4
it
had
been
made
singular
and
they
had
to
restore
the
plural
version
which
maybe
that
was
on
the
basis
of
like
that
is
very
easy
to
support
both
just
reduce
user
pain.
Why
not?
But
the
fact
is,
two
major
versions
had
passed
between
there
and
they
were
still
asked
at
the
time.
We're
still
asked
to
make
that
change
for
compatibility.
D
The
alternative
is
essentially
to
say,
like
we
can't
make
any
breaking
changes
without
bumping
the
customization
api
itself,
which
we
are
planning
to
do
for
for
something
like
field
changes
right.
So
if,
for
example,
we
have
the
vars
field
right
now
that
field
causes
tons
of
confusion,
folks
think
it's
variables
which
it
can't
be
because
it's
customized
customized
as
template
free
but
the
name.
The
name
understandably
causes
a
lot
of
confusion.
D
The
feature
doesn't
work
like
people
expect
so
a
couple
years
ago
we
introduced
or
yeah,
maybe
just
over
a
year
ago,
we
introduced
replacements
to
replace
the
virus
feature
in
a
more
powerful
and
customized
native
way.
So
the
plan
is
for
when
we
do
a
customization,
v1,
beta,
2
or
customization
v1,
we
will
actually
remove
support
for
the
vars
field
entirely
because
that's
that's
like
a
field
in
the
customization
api.
That's
easy
to
say
like
that
is
the
the
correct
strategy.
D
That
would
be
something
that
we
would
normally
consider
using
a
major
virgin
bump
to
cover
and
yeah,
because
the-
and
that
would
mean
that
we
could
make
this
fix
sooner
for
our
users
from
a
from
a
customized
perspective
right,
we
could
cut
for
we
five
more
easily
than
like
supporting
two
different
client-side
apis
like
having
v1
beta,
1,
customization
and
v1
customization.
D
D
So
I
guess,
does
anyone
disagree
with
the
opinion
sean
voiced
earlier
that
we
we
can
make
changes
like
that
like
cause,
causing
an
error
to
be
thrown
where
one
wasn't
thrown
before
there's
another
one
where
there
was
a
sort
of
environment,
variable
consumption
bug
in
like
deep
in
our
code
that
we
have
a
deprecation
warning
out,
that
is
in
the
current
cube
control
customize.
D
That
would
just
like
to
patch
and
do
that
as
part
of
v5,
like
potentially
put
for
inclusion
in
the
next
release.
So
anyone
think
that
that
will
be
a
serious
problem.
D
Yeah,
I
think
that
wouldn't
be
possible
because
it's
it's
not
actually
it
doesn't
shell
out
right.
It's
actually
integrated
at
the
api
level,
so
we're
bringing
in
customized
code
into
keep
control.
A
Right
and
and
we're
gonna
want
to
be
able
to
rev
the
major
versions
of
customize,
so
how
we
communicate
that
you
know
I'm
not
100
sure
what
the
best
way
to
to
do.
That
is,
but
like
the
ability
to
be
able
to
rev
it
and
not
be
completely
stuck
with
an
api
like
we.
If
we,
if
we've
already
gotten
to
a
point
where
we
can't
modify
the
customize
api,
then
kind
of
it's,
we
are
not
in
a
position
to
rev
customize
within
coop
control.
B
Is
there
katrina
you
mentioned
that
it
doesn't
shell
out
and
is
there
a
reason
why
it
doesn't
shell
out
versus
why
it
has
to
be
baked
into
coop
cuddle
versus
something
that
it
shells
out
to?
Does
that
help
at
all?
If
it
does.
D
I
think
that
wouldn't
work
very
well
like
it
would
be
a
he
we
couldn't
do
it
without
being
either
very
confusing
or
breaking
change
one.
This
is
like
intended
to
be
a
very
like
control
native
solution,
so
it
integrates
not
just
with
cube
control
customize,
but
also
with
like
dash
k,
for
example,
so
that
really
needs
the.
I
don't
know.
I
feel
like
that.
Wouldn't
that
wouldn't
work
terribly
smoothly.
D
If
we
were
shelling
out,
then
we
would
have
to
deal
with
multiple
version
compatibility
on
the
cube
control
side,
which
could
be
messy
and
the
last
one
problem
would
be
well
yeah.
The
these
are
having
to
install
a
version
of
customize
would
be
another
one
and
then
the
last
problem
that
the
command
structure
that
was
chosen
when
the
integration
was
originally
made
doesn't
actually
match
the
command
structure
of
of
the
standalone.
D
D
The
customization
kind
version
and
the
cli
version
they're
actually
three
different
ones,
and
we
sort
of
try
to
make
our
users
lives
simpler
by
referencing
the
cli
version
in
a
queue
control
version,
even
though
that's
sort
of
a
lie
because
it
isn't
the
exact
same
thing.
It's
like
the
equivalent
cli
version.
A
A
Oh
go
ahead.
Sean
sorry,
just
one
more
drawback
to
shelling
out
would
probably
be
security
for
shelling
out
to
some
particular
binary.
You
know
if
whether
it's
customized
or
whatever,
then
you
also
have
might
have
some
kind
of
security
breaches
where
we're
running.
You
know
some
random
binary
that
has
permissions
to
talk
to
the
cluster.
A
B
I'm
just
thinking
of
it
like
as
equivalent
to
a
plug-in,
but
it,
but
it's
not
just
equivalent
to
a
plug-in
because
of
the
things
that
katrina
mentioned
and
not
just
well
the
dash
k,
but
also
the
remapping
of
the
command
to
the
sub
command
build
and
that
that
changes
things
a
little
bit
so.
But
your
point
is
right:
yes,
basically
we're
shelling
out.
That's
another
security
potential
security
hazard.
D
Yeah
and
customize
itself
like
has
features
that
we've
really
wanted
to
keep
tabs
on
in
the
past.
Like
we've
one,
a
breaking
change
that
we
really
did
make
was
to
the
helm
integration
with
customize,
even
though
yeah
it
broke
tons
of
people,
we
had
to
change
it
because
it
was.
It
was
insecure
in
the
way
that
it
was
shelling
out.
D
There
might
be
some
a
few
more
folks
that
I'd
like
to
check
with
who
don't
typically
attend
this
segment
sick
meetings
but
who's
to
show
up
on
our
approvers
when
we
go
to
update
the
integration
just
to
make
sure
they're
on
the
same
page.
But
it
sounds
like
the
sort
of
changes
that
I
have
in
mind
would
be
acceptable
to
those
present,
which
is
definitely
useful
feedback
to
have,
because
I
think
that
would
ultimately
help
customize
users
because,
as
like
less
mature
software
than
cubepedal,
we
have.
D
A
Yeah,
it
feels
like
to
be
honest
because
cuddle
customize
or
the
minus
k
is,
has
a
slightly
different
standard
on
the
on
whether
or
not
we
break
particular
users
just
because
it
is
a
completely
separate
set
of
people
who
are
using
this
and
and
we've
we've
modified
it
actually
in
major
ways
before.
A
Okay,
great,
is
it
okay
to
move
on
katrina,
yep,
okay,
so
looks
like
nick
has
a
very
large
stand
up
and
I
saw
nick
around
earlier.
Is
he
still
here.
A
Oh
okay,
okay!
Well,
why
don't?
I
just
try
to
just
I'll
mention
this
myself.
I
hope
I
could
do
nick
proud,
so
this
is
a
stand-up
on
kui
ui
version
of
control
that
nick
works
on
nick
mitchell
ibm,
and
so
it
looks
like
the
12.0
version
has
been
released.
A
lot
of
bug
fixes
it
adds
a
nifty
tray
menu,
so
so
nick
had
mentioned
this
tray
menu
in
the
previous
meeting.