►
From YouTube: 20220602 SIG Architecture Community 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
Hi,
everybody
today
is
june
2nd
and
we
are
trying
to
restart
the
sikh
architecture
after
cube
call
and
it's
been
a
hard
journey
after
cubecon
and
the
memorial
day
weekend
and
all
that
so
welcome
back
to
the
few
of
us
who
were
able
to
make
it.
A
We
have
one
agenda
on
the
item
which
is
generics.
Do
we
want
to
allow
generics
in
125.
for
124?
I
think
we
just
said:
hey
don't
use
generics
even
if
we
are
doing
go
118
we
switched
the
compiler
very
late
into
124
release,
so
we
we
essentially
told
people,
please
don't
use
generics
right
now
and
we
are
on
125.
Master
is
open
for
125
and
now
is
the
time
to
figure
out
what
is
the
best
way
to
for
us
to
move
forward
with
generics.
A
Do
we
want
to
use
generics
in
125?
Is
there
an
approach
that
we
would
recommend?
Where
do
we
start
and
what
kind
of
things
do
we
want
to
work
on
first?
So
that
is
the
agenda
on
the
table.
B
I
don't
have
firm
opinions
on
yes
or
no.
I
do
have
a
pretty
firm
opinion
on
take
it
slow.
I
think
we
should
be
careful,
and
I
think
I
don't.
I
believe
everybody
here
from
what
I've
heard
said
in
the
past
is
probably
on
the
same
page,
but
like
let's
understand
what
we're
doing
before
we
get
too
far
down
the
path.
A
C
I
think
that
prs
that
switched
to
generics
have
are
suspect
for
performance
considerations
like
we
should
probably
be
checking
that
trade-off
from
everything
I've
found
with
them.
So
far,
I'm
also
wondering
if
this
filters
into
things
like
that,
the
impact
to
external
users
beyond
kubernetes
itself,
like
client
library,
user
consumers,
we
would
essentially
force
them
to
have
to
upgrade
to
at
least
118.
C
B
We
need
somebody
to
take
the
initiative
to
write
up,
and
maybe
maybe
somebody
already
did
and
I'm
just
ignorant
write
up
a
a
cap
or
an
I
don't
know
if
it's
a
cap,
but
a
a
policy
document
sort
of
hear
pros
here,
cons,
you
know,
don't
use
this
in
client
go.
You
know,
for
I
don't
know
five
releases
or
something
ridiculous
right
like
like.
Where
do
we?
Where
do
we
set
up
those
policies
and
and
we
can
debate
them?
B
A
Yeah,
I
have
a
feeling
that
we
should
start
with
libraries
for
sure,
but
then
I
don't
know
whether
libraries
on
the
client
side
or
on
the
server
side
before
we
touch
the
core
of
a
kk.
A
A
So
picking
you
know,
picking
a
project
like
that
where
we
experiment
before
we
start
making
changes
within
kk
might
might
be
like
a
safer
thing
to
do.
I
guess.
B
A
Stim
just
to
catch
you
up,
we
are
talking
about
generics
and
what
are
the
pros
and
cons
of
allowing
generation
125?
When
do
we
want
to
do
it,
and
what
are
the
issues
that
we
have?
You
know
gotten
to
know
so
far.
D
If
I
may
does,
it
only
include
generics
like
there
is
a
pr
for
strings
card,
for
instance,
and
this
is
explicitly
saying
that
strings
cut
will
be
used
but
like
if
somebody
just
used
it
in
their
pr
and
we
missed
it
like
do.
We
have
any
ways
to
control
that.
A
No,
we
don't
so
here
is
the
deal
right
like
the
root
go.
Mod
already
asserts
118.,
so
I
think
the
strings
cut
might
might
still
be
okay,
because
we
are
saying
that
we
are
using
go
180
in
the
root.
Go
mod
file.
C
Sorry
go:
go
will
restrict
language
features
by
the
value
in
the
root
module,
but
for
like
standard
library
things
at
best
the
go
version
not
matching.
The
version
used
to
compile
just
gives
like
a
hint
warning,
whereas,
like
standard
library
functions
is
just
whatever
is
available
in
the
current
go
version,
it
isn't
nothing.
I
don't
think
there's
any
tooling
to
enforce
this.
A
The
easiest
thing
to
do
is
like
hey:
go
wild
right
like
switch
everything
to
go
over
18
and
let's
you
know,
let's
say
that
if
somebody
wants
to
use
125,
it's
got
to
be
118,
there's
no
going
back.
From
that
point
of
view.
C
If
we
wanted
to
force
language
features
at
a
certain
level,
we
could
set
the
go
pod
version
like
you,
don't
have
to
keep
updating
it.
We
I
believe
we
updated
it
because
of
because
go
format,
changes
behavior
and
we
wanted
that
not
because
of
of
the
language
version
changes.
We
could
revisit
that
change.
A
Yeah
I
want
to
so,
if
you
have
to
put
in
safety
checks
and
like
make
sure
that
pr's
are
not
going
to
break,
I
I
want
to
do
it
only
if
required.
We
already
have
too
many
of
those,
and
just
adding
to
the
pile
of
verify.
Scripts
is
not
well.
C
A
C
A
Yeah
at
this
point,
unless
we
have
enough
data
to
say,
hey,
don't
do
generics,
I'm
inclined
to
say,
go
experiment,
but
you
do
small
experiments
and
not
big
experiments
like
I.
I
don't
want
prs
that
is
going
to
change
like
everything
in
kk.
Right
like
it
has
to
be
focused,
it
has
to
be
small,
it
has
to
be
well
contained.
A
C
Go
back
to
circus
point:
if
we
let,
if
we
let
people
use
things
like
string,
cut,
we're
already
also
requiring
go
118
and
consumers.
If
any
of
that
code
filters
into
like
client
go.
Do
we
have
we
had
a
policy
about
this
before
I'm
not
aware
of
one.
A
No,
we
don't
so,
let's
check
the
golang
sunset,
the
golang
version
support.
C
Go
keeps
two
versions
supported,
so
whatever
is
whatever
is
the
current
version
and
then
the
previous
version,
minor
version,
are
supported,
so
118
and
117
are
supported
yeah.
The
moment
119
is
released.
117
goes
out
of
support.
C
We
can't
know
exactly
because
you
know
it's
like
us:
they
get
deferred
dates
and
whatever
and
they
don't
spin
down
the
old
one
until
the
new
ones
out.
A
So
looks
like
another
14
months:
117
will
be
around
no.
What
is
dinos?
What
is
this
never
mind?
Hang
on
I'm
looking
at
the
wrong
information.
This.
B
Would
be
what
are
the
reasons
to
limit
the
use
of
the
language
features,
and
you
know,
is
it
we're
afraid,
they're
unstable?
Is
it
that
we
don't
know
how
to
use
them?
Yet?
Is
it
that
we
don't
want
to
force
things
that
consume
our
modules
to
run?
Go
118
like
those
are
all
three
different
reasons,
and
there
may
be
three
different
answers
for
there
may
be
three
different
approaches
to
addressing
each
of
those.
A
So,
for
me
the
top
is
cherry
picks.
It
should
be
easy
if
we
do
a
lot
of
changes,
a
problem
other
than
that.
I'm
fine,
like
you
know,
if
you
tell
people
to
update,
update
the
versions
of
go
because
they're
rendering
in
our
stuff,
like
I'm
fine
with
it
yeah.
You
know
I'm
fine
with
imposing
that
as
a
penalty
to
the
users
who
want
to
go
there,
but
my
practical
issue
is
with
cherry
picks.
B
C
I
think
front
end.
We've
already
done
some
similar
cherry
pick
not
capable
changes
with
things
like
the
new
net
ip
types
it
seems
like.
If
we
want
to
go
with
that
reasoning,
we
should
probably
write
a
more
general
rule
than
generics
that
says,
like
don't
adopt
new
go
features
until
it's
in
all
of
our
branches
that
are
supported,
yeah
or
just
not
say
that
and
let
people
use
generics
the
same
as
we
did
with
like
net
ip.
A
C
No,
I
mean
the
you
can't
use
a
go
feature
until
it's
available
in
the
in
our
release
branches.
So
because
we
don't
cherry
pick
past
a
certain
versions
back
right.
That
would
slow
things
down
quite
a
bit,
but
so
it
doesn't
have
to
be
like
the
current
go
version
it
would
be.
We
shouldn't
use,
features
newer
than
whatever
we're
using
in
the
cherry
pick
branches.
C
B
So
today
I
guess
that's
a
good
question
right.
Do
we
like,
if
go
on
when
16
is
now
out
of
support,
like
we
can't
be
building
our
old
releases
with
the
l116
right,
so
we
have
to
advance
them
for
the
patch
releases.
B
So
maybe
it's
not
as
as
much
of
a
drag
as
we
as
we
think
all
right
we
were
already
advancing,
so
you
get
to
one
eight
like
the
way
that
ben
stated
it
right,
I
think,
would
cover
that.
It's
once
we're
using
that
golang
in
our
all
of
our
supported
branches.
Then
you
can
start
using
those
features
that
doesn't
mean
a
year
after
you
know
the
the
first
time
we
used
that
building.
A
Right,
kubernetes
releases
one
end
off
okay,
so
I
go
into
kubernetes
dot,
io,
slash
releases
and
it
says.
C
B
C
I
think
most
of
these
changes
wind
up
being
internal
they're
things
like
go.
Changing
the
formatting
or
like
libraries
code
that
we're
using
in
implementation.
Details
of
core
controllers,
like
I
think,
most
of
for
other
reasons
we
wouldn't
be
able
to
change
most
of
these
places
because
they
would
like,
if
we
switched
to
a
new
standard
library,
ip
type
like
that
is
itself
a
breaking
change.
Regardless.
A
A
So
how
about
we
do
this,
then
you
and
me:
we
write
it
up
and
then
we
can
put
it
to
vote.
C
A
Yeah,
what
we'll
do
is
we'll
write
it
up,
we'll
post
it
to
devote
kubernetes,
and
then
we
wait
for
feedback.
If
we
don't
get
any
feedback,
then
we
do
a
lazy
consensus
and
punch
it
fair
enough.
B
B
A
C
C
D
A
Okay,
so
you
you
want
to
take
the
first
cut,
then
write
a
paragraph
and
you
know
I
hack
and
b
or
something,
and
then
we
can
collab.
A
Yeah
put
it
in
some
community
specific
architecture
thing
somewhere.
A
B
A
Thank
you.
So
that's
all
I
had
for
today,
everybody's
safe
home
and
no
issues
yeah.
B
I
heard
you
got
stuck
in,
you
got
stuck
in
amsterdam
or
something
for
a
while.
A
A
Yeah
anything
else
you
all
wanted
to
talk
about
today.
A
Going
once
going
twice:
well,
I
can,
since
we
have
y
tech,
we
can
ask
why
tech
was
there
any
other
feedback
on
that
kept
for
re
resiliency.
F
Now
I
think
what
we
are
doing
now
is
is
we
are
proceeding
with
those
like
smaller
changes,
like
updates
to
the
caps
to
to
to
the
cap,
to
require,
like
more
sophisticated
testing
plan,
things
like
ensuring
that
approvers
will
pay
more
attention
to
to
staff,
and
I
think
that
the
biggest
action
item
is
that
we
need
to
start
gathering
more
data
and
more
like
yeah
figure
out
some
dashboards
or
metrics
or
whatever.
That
will
better
show
us
like
how
big
the
problems
and,
if
it's,
and
even
more
importantly,
it's
improving.
F
So
if
what
we
already
did
is
actually
bringing
some
effect
and
get
back
to
it
like
if
it's
not
improving
or
even
worse
getting
worse.
So
I.
B
Think
we
are
a
little
preview
on
our
survey,
our
pr
survey.
We
asked
the
question
of
is
kubernetes
more
reliable
than
it
was
a
year
ago
and
that
cervical
is
tomorrow.
So
hopefully
I'm
not
polluting
my
sample,
but
it
came.
It
came
in
at
like
more
than
75
saying
yes,
it's
more
reliable
than
it
was
a
year
ago.
So
that
seems
like
improving.
A
Yeah,
okay:
rhian
did
you
have
any
requests
for
the
team
here
from
the
conformance
side,
conformance.
E
E
A
Yeah,
so
I
don't
have
anything
else
tim
all
claire
did
you
have
anything
to
talk
about
today.
A
A
Okay,
thanks
for
showing
up
here
for
sure,
okay
thanks
a
lot,
everyone
see
you
thank.