►
From YouTube: Istio User Experience WG October 21, 2020
Description
This recording was started ~8 minutes late, sorry!
A
B
No
patch
releases
are
generally
okay,
yeah,
usually
for
us.
We
hit
a
lot
of
pain
in
the
minor
release
and
then
getting
the
patch
releases
out
the
door
after
that
is
relatively
simple,
because
a
lot
of
time,
those
patch
releases
are
fixing
problems
we
found
in
the
minor,
so
for
us,
iterating
over
patches
has
never
been
an
issue.
It's
always
been
the
big
changes.
B
It
does
but
it's
tied
to
the
application,
so
each
each
of
those
400
applications
has
got
its
own
configuration
so
if
they're
that
they
they
all
deploy
off
like
a
master
helm
chart.
So
we
have
like
a
an
all-encompassing
helm
chart
that
they
feed
their
values
into
it's
that
helm,
chat
that
generates
the
istio
manifests.
B
So,
for
example,
if
I
own
application
a-
and
I
want
to
increase
its
time
out-
I
put
that
in
my
repo,
my
recode
deploys
that
through
the
environment,
so
we
don't
have
separate
infrastructure
repos
if
that
makes
sense,
the
applications
pipeline,
app
code
and
all
of
the
infrastructure
concerns
get
deployed
as
a
single
pipeline,
including
the
template
history
of
resources
from
a
platform
perspective.
If
I
want
to
do
something
across
all
applications,
so
let's
say
I
want
to
enable
http
2
on
every
single
app.
B
I
don't
do
that
at
a
system
level.
I
put
it
in
that
chart
that
chat
gets
tested
and
then
the
next
time
the
application
is
released.
It
will
pull
in
the
latest
version
of
what
we
consider
our
blackout
platform
and
it
will
apply
that
http
to
upgrade
and
it'll
go
out
with
the
app,
and
that's
intentional,
because
you
know,
for
example,
if
they're
apps
using
websockets
http
2
is
going
to
break
it.
A
All
right
so
you've
linked
an
issue
that
outlines
a
number
of
problems
that
you've
had
with
the
one
five
to
one
six
upgrade
process
and
as
the
ux
working
group
I
I
looked
through
them.
I
didn't
see
any
that
were
clearly
under
our
area
of
ownership,
but
we're
more
concerned
with
kind
of
the
overall
story
of
how
we
can
improve
as
a
project
the
usability
in
terms
of
upgrading,
istio
and
operating
istio.
B
I
mean
I'm
not
too
sure
if
this
answers
the
question
directly,
but
I
think
the
biggest
ignoring
the
specifics
of
the
problems.
I
think
the
biggest
issue
that
we
face
with
istio
is
by
the
time
that
we,
as
a
user,
are
encountering
upgrade
problems.
The
istio
project
is
already
focused
heavily
on
the
next
release.
So
there's
like
there's
a
lot
of
focus
on.
B
You
know
getting
a
release
out
the
door
release
blockers
and
if
you
get
in
there
and
test
the
release
early,
you
know
you're
going
to
get
some
real
focus
on
your
issues,
but
then,
once
the
release
is
out
the
door,
it
can
be
a
lot
harder
to
get
traction
and
actually
sometimes
it's
like
well
a
lot
of
your
users
as
you've.
Seen
from
the
surveys
that
you've
done
are
running
older
versions
of
istio
in
production
environments.
So
it's
it's
almost
like
we
need.
B
We
need
a
way
in
which
to
help
them
get
up
today,
and
we
need
for
the
project
needs
to
accept
that
people
are
going
to
be
coming
with
with
upgrade
related
problems
from
your
perspective,
late
on
in
the
process,
but
in
the
real
world
at
scale
actually
sort
of
three
months
behind
the
release.
It's
not
that
long
ago,
so
you
could
be
releasing
1.8
tomorrow
and
1.6
will
be
well.
1.8
goes
out
in
a
few
weeks.
B
Many
different
things
with
the
product
that
you're
to
a
large
extent,
you
are
reliant
on
particularly
those
people.
Who've
got
complex
infrastructure
to
find
problems,
feed
them
back
to
you
and
get
them
sorted
to
enable,
then
all
those
other
users
to
to
do
the
upgrades,
because
there's
probably
a
whole
bunch
of
users
that
are
encountering
problems
but
they're,
not
raising
github
issues
either
and
just
giving
up
so
yeah.
B
From
my
perspective,
it's
like
there's
the
probably
like
the
top
ten
percent
of
tile
of
your
customers,
that
I've
got
complex
deployments
if
there
was
something
that
gave
us
confidence
that
those
upgrade
issues
were
treated
with
a
similar
sort
of
waiting
as
a
release
blocker.
I
think
that
would
help
a
lot.
Obviously,
I'm
saying
that,
without
any
understanding
of
the
priorities
in
your
your
project
behind
the
scenes
and
discovering
it
purely
from
a
customer's
perspective,.
A
B
B
You
know
so
close
to
a
release
as
an
example,
we
didn't
even
so
the
way
that
manifest
is
with
1.6.
We
decided
to
to
wait
for
for
more
patch
releases
than
we
usually
would
do
before
we
started
trying
it
because
1.4
to
1.5
was
extremely
painful
for
us
took
a
long
time
and
we
there
was
a
combination
of
things
that
we
wanted.
A
break
to
be
honest,
we
needed
to
focus
on
some
other
stuff
in
the
organization
and
two
this
time
around,
we
kind
of
wanted
to
let
it
settle
a
little
bit.
B
So
that's
what
we
actually
waited
for,
like
nine
patch
releases
of
1.6
before
we
started
even
looking
at
it.
So
that's
unusual
for
us.
We
left
it
longer
than
I
expected
and
it
was
still
super
unstable.
So
I
think
the
thing
we've
learned
from
this
most
recent
releases
there's
things
about
our
our
infrastructure
in
our
architecture
that
probably
sufficiently
different
to
the
majority
of
users
that
we
just
need
to
get
the
releases
we
need
to.
B
We
need
to
go
closer
to
the
main
release
again,
so
you
know
get
as
soon
as
we've
got
this
1.6
out
of
the
door
we're
going
to
get
1.7
into
a
testing
environment
again
to
try
and
surface
some
of
these
problems
as
quickly
as
possible.
But
realistically
1.8
is
going
to
be
out
by
the
time
that
happens.
So
we
might
end
up
with
a
similar
situation
again,
which
is
you
know.
People
are
focusing
on
stabilizing
1.8
and
thinking
about
1.9,
and
then
meanwhile,
we're
only
just
getting
onto
one
seven.
A
B
Yeah,
so
in
order
of
preference,
when
it
comes
to
a
minor
release,
it's
going
to
be
staying
in
the
support
window
is
our
most
our
biggest
concern.
You
know
knowing
that
if
something
goes
wrong,
that
people
are
going
to
be
able
to
help,
cves
is
more
of
a
patch
concern.
For
me,
it's
like
as
long
as
as
long
as
we're
in
the
support
window,
then
we're
going
to
be
getting
security
patches
and
we
have
no
issues
doing
patch
releases.
You
know
we
do.
B
We
always
release
them,
so
that
would
be
second
features
is
a
rare
one
now
for
us,
if,
I'm
being
honest,
I've
said
a
few
times
now
that
I
believe
istio
has
too
many
features.
That
might
just
be
a
historical
bias
that
I
personally
have
that
was
it
had
too
many
features
out
the
door
and
it
wasn't
very
special,
a
lot
of
the
features
weren't
stable.
B
Sometimes
it
does
feel
to
a
user
like
you've
got
like
core
features
and
like,
for
example,
in
one
point
going
from
1.4
to
1.5
and
changing
from
telemetry
really
wanted
telemetry
v2.
As
far
as
I
was
concerned,
there
was
a
whole
bunch
of
regressions
in
v2
versus
v1,
so
there
was,
there
was
aspects
of
metrics
that
just
didn't
work.
The
way
that
they
used
to
work
so
for
me,
like
observability,
is
an
absolute
core
function
of
this
video
it
shouldn't
regress,
but
I
still
see
their
new
features
getting
released.
B
So
that's
what
I
mean
by
sometimes
like
there
needs
to
be
a
little
bit
more
of
a
focus
on
the
features
that
the
vast
majority
of
your
users
are
going
to
use
are
going
to
be
observability
mutual
cls.
You
know
these
core
components
and
they
they
need
nine
percent
of
the
focus,
in
my
opinion,
and
because
to
most
of
your
customers,
they're
going
to
deliver
90
of
the
value
as
well.
A
Yeah,
that
makes
sense
so
you've
mentioned
that
that
you
guys
are
sort
of
a
power
user
and
a
little
bit
of
an
edge
case
in
terms
of
the
complexity
of
the
ways
that
you're
using
istio.
Have
you
ever
considered
trying
to
contribute
like
some
of
your
acceptance
tests
to
the
project
in
such
a
way
that
we
could
automatically
run
them
before
we
release.
B
Yeah
but,
like
I
said
to
you
a
second
ago,
it
isn't
our
acceptance,
tests
and
rsd
test
suite.
That's
really
catching
the
problems,
it's
it's
variance
of
workloads
in
from
our
users
and
yeah.
So
you
know
we
can
go
back
and
you
know
we
find
a
particular
problem
in
a
pre-production
environment.
We
can
retrospectively
go
back
and
write
a
test
post,
both
in
istio
and
our
test
suite
in
order
to
tackle
that,
but
the
the
issues
that
we
have
with
upgrades
they're
always
they're,
always
something
new.
B
If
that
makes
sense,
it's
never
a
repeat
problem
and
usually
like
the
process
that
usually
happens.
Is
I
find
a
problem.
I
end
up
talking
to
john
john
helps
me
fix
the
problem
and
then,
as
far
as
I'm
concerned,
that
that
particular
manifestation
of
the
problem
is
it's
fixed,
then
in
sdo.
The
next
problem
we
face
will
be
something
new,
so
at
least
we're
not
making
the
same
mistakes
twice
now.
I'm
trying
to
give
this.
There
is
any
examples
of
where
I
feel
like
a
bug
is
regressed.
B
It's
yeah,
like
90
of
the
problems
we
face
are
just
so
the
subtle
changes
that,
to
be
honest,
the
devs
will
have
done
without
realizing
that
it
could
affect
our
particular
edge
case,
and
that's
that's
going
to
happen.
It's
it's
fine
and
that's.
That
brings
me
back
to
my
earlier
point
of
like.
I
totally
accept
that
I'm
going
to
find
issues
that
that
your
test
suite
won't
and
probably
the
majority
customers.
Won't
it's
just
about.
Well,
what's
the
like
making
the
process
better
for
getting
those
things
addressed,
post
release,
yeah.
A
So
I'm
curious:
we've
we've
had
some
conversations
in
the
test
and
release
group
about
different
release
strategies.
You
know
right
now
we
run
t
plus
one
for
support,
so
t
plus
two
is
one
strategy
that
is
possible,
but
of
course
that
adds
a
lot
of
a
lot
more
support
burden
to
the
project.
We
discussed
the
possibility
of
various
long-term,
stable
releases
and
things
like
that.
What
are
your
thoughts?
Do
you
have
like
a
desired
support
outcome
that
you
would
like
to
see
from
the
project.
B
How
can
I
describe
it
so
like
if,
when
I'm
writing
software,
we,
I
do
mainline
trunk
development,
so
my
master
branch
is
the
branch
that
is
always
getting
worked
on
is
the
one
that
gets
released
and
I
release
features
on
that
branch.
I
don't
work
on
another
version
of
the
code,
that's
so
different
from
the
previous
version
of
the
code
that
it's
almost
big
bang
when
it
goes
out
the
door,
because
I
feel
that's
what's
happening
at
the
moment.
B
You
know
the
things
that
are
breaking
for
me:
they're,
not
new
features,
they're
existing
features
as
a
result
of
rewriting
of
code,
probably
to
facilitate
something
else
so
like
in
a
perfect
world,
and
I'm
saying
this
without
at
all
understanding
the
istio
release
process
working
from
one
code
base
and
releasing
features
and
continually
releasing
like
just
version.
One
he's
just
going
out
the
door
would
feels
better
to
me.
It
feels
like
a
lot
of
the
problems
are
coming
because
because
too
much
changes
like
release
more
frequently
and
release
smaller
subsets
of
code.
B
And
then
in
some
ways
as
well
right,
if
you
were
releasing
features
rather
rather
than
sort
of
big
branches
of
code,
you
would
be
able
to
hit
support
like
upgrade
processors.
For
a
longer
time
like,
for
example,
telemetry
v2
has
been
in
1.4
1.5
1.6
1.7
1.8,
but
it's
still
telemetry
v2
so
like.
Why
is
that
code
base
effectively
unsupported
for,
like
you
know,
t-minus
one
releases
it
feels
like
yeah.
I
don't
know
just
a
more
continual
release
process
and
then
you
won't
need
these
windowed
support,
sort
of
things.
A
C
C
We
started
encouraging
people
to
use
istio
cargo
or
the
operator
and
and
helm
sort
of
faded
away
into
the
the
background
and
we're
kind
of
bringing
it
back
now
by
popular
demand
and
just
as
sort
of
full
disclosure
here,
I'm
I
work
very
heavily
on
easter
cuddle
installs.
So
you
know,
if
there's
anybody
to
kick
for
anything.
That
goes
wrong
with
that
that
installation
and
upgrade
path.
I
I'm
the
guy,
but
I
was
wondering
in
terms
of
choosing
you
know
your
main
way
of
managing
istio.
C
B
A
few
factors,
so
we
deploy
istio
in
the
same
way
that
we
actually
deploy
all
of
our
applications
like
it's
the
same
pipelines
that
run
it's
the
same
pipeline
templates,
the
same
supporting
scripts
and
the
same
supporting
cli
infrastructure,
because,
as
far
as
we're
concerned,
it's
just
a
chart
and
so
are
all
of
our
applications.
They're
just
a
chart.
B
So,
yes,
there's
a
whole
load
of
supporting
ci
and
cd
infrastructure
that
is
based
around
using
charts.
However,
using
helm
has
got
a
couple
of
other
benefits
for
us
as
well.
We
really
like
the
ability
to
track
resources
on
the
kubernetes
cluster
specifically
to
that
chart.
So
you
know
if
we
want
to
roll
back
or
roll
forward,
we
can
use
helm
to
roll
back
our
row
forward
through
those
releases,
and
we
know
that
the
resources
on
the
cluster
attract
with
that.
So
we
we
don't
have
any
rubbish
left
left
around
on
the
cluster.
B
The
other
thing
that's
been
really
beneficial
for
us
during
istio
upgrades
in
particular,
is
because
we
use
either
your
helm
or
your
steel
ctl.
In
order
to
generate
manifests,
we
post
process
them
into
our
charts.
We're
then
able
to
do
effectively
get
differentials
of
all
of
the
manifest
changes.
So
we
don't
have
confidence
in
you
know
doing
this
to
ctl,
install
and
letting
it
do
some
stuff
against
the
cluster,
or
this
is
the
same
same
applies
to
the
operator
right.
B
We
don't
have
confidence
in
running
a
binary
on
the
on
the
cluster
and
just
letting
it
do
what
it
needs
to
do.
We
want
to
know
what
it's
doing,
because
it's
such
a
critical
part
of
our
infrastructure
so
being
able
to
do
diffs
of
the
actual
manifests
that
get
generated
as
a
result
of
this
has
has
stopped
so
many
bugs
getting
into
production
environments.
B
Like
give
you
an
example
like
the
webhook
validation
in
1.6,
so
there's
an
option
in
in
the
installer
to
disable
conflict
validation.
You
you
set
that
to
true
and
you
do
a
generate
manifests.
You
still
get
the
webhook
getting
generated,
which
means
it's
not
actually
working
and
we
don't
want
config
validation
at
runtime,
because
we
do
it
in
ci
and
cd
at
the
moment,
and
we
also
wanted
to
minimize
the
amount
of
change
in
the
1.5
to
1.6
release.
B
So
that's
a
prime
example
of
where
we
set
an
installation
option
generated
the
manifest
and
we've
only
realized
when
we've
done
that
differential
of
our
of
our
release
that
actually
that's
not
doing
what
it
says.
It's
doing.
Does
that
kind
of
make
sense.
We've
prevented
a
lot
of
bugs
with
that
diff.
C
C
C
Still
the
helm
chart,
so
so
you
know
we
that's
that's
why
we're
able
to
bring
home
back.
As
you
know,
it's
mostly
just
just
a
desire
to
limit
the
number
of
installation
paths
that
we
have
to
support
more
than
any
fundamental
compatibility
there,
but
so
so
you
know
there
there
is
a
way
to
be
able
to
generate
the
output
manifests
and
and
and
diff
them.
If
you
want
through
what.
B
We're
doing
so
and
we
will
we
want
to
continue
to
do
that,
like
we've
been
generating
the
manifests
and
post-processing
them
into
our
own
health
charts
since
alpha,
we
want
to
continue
to
do
that
moving
forward
and
for
us
it
doesn't
really
doesn't
really
matter
how
we
generate
those
manifests.
You
know
up
until
up
until
1.5
we
used
helm.
You
know
we
used
your
helm,
charts
1.6.
We
switched
to
osteoctl
1.7,
we'll
continue
to
use
this
studio
ctl.
C
Yeah,
that's
that's
good
to
know,
because
that's
that's!
The
other
thing
I
was
wondering
about
is:
is
we
we
also?
You
know
we
used
to
support
istio
cuddle
manifest
generate
as
a
as
a
sort
of
first
class
installation
path
and-
and
you
know
just
due
to
mostly
a
lack
of
feedback
from
users.
We
we
just
we
we
just
stopped
advertising
it
we're
thinking
about
bringing
it
back.
So
it
sounds
like
it's.
B
Well,
I
mean
I
will
use
whatever
your
supported
method
for
generating
the
manifestos.
So
from
my
perspective,
helm
has
been
taken
away
and
at
the
moment
istio
ctl
generate
manifests
on
manifest
generate
is
the
only
way
of
regenerating
those
manifests
unless
I'm
wrong?
No,
that's
that's
correct
yeah,
yeah,
okay.
So
as
far
as
I'm
concerned,
that's
the
only
way
I
can
do
it.
So
it's
a
bit
worrying.
I
wasn't
aware
that
it
wasn't
supported.
So
that's
another
concern
for
me.
C
Well,
it's
it's
not
it's
not
that
it's
not
supported
it's
just
we!
We
don't
openly
advertise
it
as
that
we
encourage,
because
because
we
we
just
are
seeing
just
an
explosion
of
of
different
install
methods,
so
we're
trying
to
encourage
most
users
to
use
what
you
know
just
one
or
two
different
installation
methods
rather
than
four.
B
C
Okay,
well
so
anyway,
I
think
for
for
one
eight,
we
are
planning
to
bring
back
helm
and
manifest
generators
as
fully
documented,
and
you
know,
sort
of
top
level
install
paths
and
and
we're
going
to
start
supporting
that
as
a
sort
of
like
a
first
class
method,
again
so
cool
yeah.
It's
good
to
understand
like
why
you
guys
are
preferring
that.
A
B
Absolutely
correct:
yes:
okay,
we
do
a
bunch,
we
don't
just
template,
we
don't
just
generate,
manifests
and
then
template
them
into
our
own
charts.
We
do
some
post-processing
of
those
things
as
well,
so
some
stuff
that
we
do
is
specific
to
our
organization
that
doesn't
make
sense
to
be
exposed
as
an
istio
installer
option.
We
do
that.
You
know
in
that
middle
phase,
effectively.
D
D
B
I
mean
we
want
to
do
the
least
amount
possible
in
the
post-processing
really
so
that's
kind
of
a
like
it's
a
legacy
artifact
from
back
in
the
days
when
you
couldn't,
for
example,
like
we
were
using
this
video
that
earlier
that
you
couldn't
configure
the
resources
on
pilot
properly
and
stuff
like
that,
so
we
we
had
to
do
stuff.
You
know,
after
that,
that's
the
like
escape
patch,
really
yeah
yeah,
basically
yeah.
So
we
want.
We
want
to
do
in
an
ideal
world
that
generate.
I
wish
it
would
just
go.
B
C
So
so
some
of
these
customizations
that
you're
doing
we
we
now
have
this
this
back
door
available.
I
was
wondering
if,
if
you
had
tried
by
using
the
overlays,
there
is
a
sort
of
built-in
patching
mechanism
where
you
can
reach
into
pretty
much
any
part
of
the
output
manifest,
and
you
know
patch
it
to
your
heart's
content
is:
have
you
tried
that
out
or
is.
B
C
C
All
right
so
yeah,
it's
we
do
something
similar.
It's
just
there's,
there's
just
some
path.
So
if
you
want
to
a
patch,
let's
say
a
list
element
or
something
like
that,
we
have
a
pretty
rich
way
of
traversing.
All
the
paths
that
you
would
have
to
patch
anyway.
I'd
be
curious
to
to
hear
what
what
you
think
about
that,
and
you
know
yeah.
A
A
I
will
be
taking
this
feedback
and
representing
it
back
up
to
the
technical
oversight
committee
in
the
next
couple
of
weeks,
so
your
voice
is
being
heard,
appreciate
you
taking
the
time
we're
gonna
continue
on
with
release
matters
and,
of
course,
you're
welcome
to
stick
around.
It
will
be
substantially
less
interesting
than
the
first
half
of
the
meeting.
B
A
A
A
Oh
thanks,
martin,
okay,
so
there's
only
one
p0
left
that
is
targeted
to
this
milestone
and
I'm
not
sure
I
know
that
ed
had
the
ball
on
this
and
he's,
of
course,
out
on
jury
duty
right
now.
So
I
was
wondering
if
anybody
else
had
had
context
here.
There
were
several
related
issues,
I'm
not
sure.
If
there's
any
related
pull
requests
yeah,
it
doesn't
look
like
there's
any
pr's
related
to
this
particular
issue.
A
So
I'm
inclined
in
ed's,
absence
to
probably
retarget
this
to
one
nine.
We
did
have
it
set
as
a
p0
for
this
release,
but
without
him
around
it's
kind
of
difficult
to
say
what
progress
has
or
hasn't
been
made
in
this
direction.
Anyone
have
any
objections
to
moving
this
to
the
one
nine
release
for
the
record.
A
What
this
is
is
we
lost
some
of
our
off
checks
back
in,
I
think
istio,
1,
5
or
1
6
when
pure
authentication
was
introduced,
our
off
checks
that
we
had
added
in
istio
ctl
no
longer
worked,
so
we
had
taken
out
a
task
in
one
six.
No
I'm
sorry
in
one
seven
to
correct
this
with
the
security
working
group,
it
got
kicked
to
one
eight
and
I
would
be
kicking
it
again,
which
is
not
ideal,
but
without
knowing
the
status,
I
don't
feel
like.
We
have
a
lot
of
other
options.
Any.
A
A
Does
anyone
have
anything
that
we
need
to
deal
with
before
the
release?
We?
We
saw
the
branch
cut
yesterday.
I
believe
so.
Is
there
anything
that
ux
group
needs
to
pay
attention
to
this
morning
to
try
and
tie
up
that
release
and
get
all
of
our
features.
Complete
anybody
have
any
features
they
wanted
to
talk
about
that
are
shipping
in
one
eight.
E
A
A
C
But
yeah,
I
also
I'm
a
bit
concerned
about
the
amount
of
time
that
this
pr
spent
in
review
and-
and
you
know
like
the
risk-
is
that
the
set
of
assumptions
that
it
was
originally
created
with
may
not
be
or
valid
at
the
time
that
emerged
so
yeah.
I
agree.
I
think
this
one
needs
to
be
tested
pretty
well.
E
E
A
C
E
E
So
I've
tested
this
with
six
one
point:
six
point:
eight
and
one
point
seven
point
three:
I
think
it
works
fine
with
the
different
warnings
that
is
shown
in
the
pr
comments,
but
I
just
wanted
to
make
sure
that
this
works
fine
with
other
versions.
Maybe
if
somebody
wants
to
have
some
different
views
of
upgrading
or
maybe
if
the
messages
are
look
perfect
or
not,
if
it
needs
other
improvements,.
A
E
A
E
E
A
E
Right
right,
so
the
next
command
that
they
can
do
is
pass
revision
flag
where
they
will
specify
which
revision
they
are
installing.
So
it
will
be
so
so.
The
last
latest
version
was
1.7.2
and
when
the
revision
flag
was
used
like
1.8.0,
it
will
show
a
different
message
saying
that
you
should
also
run
s2c
dell
analyze
in
order
to
check
if
there
is
any
application
warnings
in
your
previous
version
of
control,
plan
revisions.
E
E
E
A
A
Okay,
I
will
work
with
nathan
mittler,
who
is
the
author
of
our
integration
test
framework
to
understand
what
we've
got
in
terms
of
upgrade
test
infrastructure
and
what
we
can
do
there,
and
I
will
open
up
an
issue
for
right
authoring
tests
for
this.
I
feel
like
we
probably
ought
to
target
that
for
the
1
8
release.
A
E
A
A
Oh,
I
also
wanted
to
encourage
you.
I
noticed
on
the
the
list
of
maintainers,
for
the
ux
working
group
is
getting
a
little
stale.
We
have
a
few
maintainers
who
have
moved
on
that.
We
probably
need
to
clean
out
of
the
list,
and
we
have
a
few
like
yourself
champion,
who
are
contributing
frequently
but
have
not
yet
made
the
maintainer
list.
So
I
think,
based
on
what
I've
seen.
Let's
see
the
requirements
for
maintainer
are
listed
here
on
the
community
page.
A
E
E
E
A
That
would
be
great.
The
good
news
is
that
if
you
join
as
a
maintainer,
that's
one
more
person
to
review
pull
requests.
The
bad
news
is
it's
not
one
more
person
to
review
your
pull
request
says
you
can't
review
your
own,
but
we
would
be
happy
to
have
you
yeah
yeah.
I
understand
it.
Thank
you
all
right.
Anybody
have
any
other
agenda
items.
We
have
about
10
minutes
left
on
the
clock.
A
All
right,
I
think
we
can
give
everyone
10
minutes
back
thanks
everybody
for
joining
in
we'll
be
back
to
our
normal
schedule
next
week,
which
is
tuesdays
at
11
and
sean
sure.
I
know
that
you
prefer
the
9
a.m.
Time
slot.
I
think
we're
going
to
move
to
a
schedule
that
has
the
fourth
thursday
of
every
month
or
sorry,
not
thursday.
The
fourth
wednesday
of
every
month
at
9
00
a.m,
be
a
ux
meeting
that
week,
we'll
we'll
cancel
the
tuesday
meeting
and
hold
it
on
wednesdays.
A
We
would
skip
october
because
that
would
be
next
week.
I
kind
of
had
a
scheduling,
snafu
and
accidentally
scheduled
something
over.
The
extensions
meeting
need
to
not
do
that
again,
but
so
our
next
wednesday
meeting
should
be
the
fourth
wednesday
in
november
and
I'll
make
sure
our
calendar
reflects
that
awesome.
Thanks
yeah
thanks,
guys
see
you
around
thanks
mitch.