►
From YouTube: 20210121 SIG Arch Code Org
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
jordan,
this
is
jan
21st.
This
is
the
code
organization
sub
meeting
for
the
sig
architecture.
Hopefully
we
can
adhere
to
the
code
of
conflict
since
it's
just
the
two
of
us.
A
A
C
All
right,
so
I
opened
up
this
issue.
C
We've
had
a
lot
of
people
confused
by
the
old
versions
of
client.
Go
that
we
had
so
for
history.
This
is
these
are
all
the
old
versions
that
we
published
sort
of
back
before
go
modules
were
a
thing
back
when
we
were
trying
to
follow
december
and
indicate
that
there
were
go
api
changes
between
releases
of
client
go
things
like
that.
C
C
Something
like
that.
I
ever
get
the
exact
correspondence,
but
all
of
these
versions
are
basically
versions
that
people
should
not
be
using.
At
this
point
I
mean,
if,
if
they
compiled
against
them,
they
could
still
compile
against
them
if
they
were
happy
with
them.
But
if
they
were
going
to
start
using
client
go
today,
we
would
not
recommend
any
of
these
versions.
C
There
we
go
so
like
0.20.2
corresponds
to
kubernetes1.20.2
1.20.2.
C
However,
because
all
of
these
are
semantically
larger
than
the
versions
we're
tagging
now
go
will
never
automatically
select
the
versions
we
want,
it
will
always
default
to
either
the
latest
december
version
like
this
11.0.0
or
there's,
actually
something
I
forget
if
it
was
go
115
or
116
that
prefers
versions
that
don't
have
the
incompatible
bit
added,
which
means
it
would
go
back
to
151,
which
is
actually
even
older
right,
and
so
we
would
like
that
not
to
happen.
C
C
A
Okay,
so
that
is
not
going
to
break
people
who
already
depend
on
these
versions.
C
Correct
and
anyone
who
already
has
one
of
these
versions
referenced
and
vendored
and
linked
or,
however,
they're
referencing
it
if
they're
already
pointing
at
one
of
these
versions,
it
doesn't
make
it
unavailable,
it
doesn't
remove
it
from
availability,
it
doesn't
prevent
fetching
it.
It
doesn't
prevent.
Building
against
it.
All
it
does
is
inform
the
version
selection
mechanism
used
by
go
modules
so
that,
if
you
say
go,
get
client
go
and
you
don't
give
it
a
version.
C
It
would
not
pick
these
or,
if
you
say,
go,
upgrade
or
go
mod
upgrade
or
go,
get
dash.
U
or
whatever
it
would
not
upgrade
to.
One
of
these
I
mean
upgrading
is
not
a
great
idea
anyway,
because
we,
a
lot
of
our
dependencies,
do
incompatible
things.
So,
just
blindly
upgrading
is
probably
not
going
to
work,
but
we
could
at
least
make
go.
Get
client
go
work
for
new
folks
who
will
be
searching
for
new
books.
B
C
C
C
That's
what
you
have
to
do
today
to
make
it
work,
but
what
everyone
does
is
that
and
then
they
get
like
a
three-year-old
version.
A
Right,
so
this
this
update
will
only
work
when
somebody
is
using
go
116
when
it
gets
released.
Sure
yeah
I
mean.
C
It,
the
the
protracted
module
versions,
will
only
be
understood.
A
By
ghost
116
and
up,
and
what
what
do
we
have
to,
let
do
we
have
to
create
a
file
or
something
like
that?
How
do
we
mark
these
as
retracted.
A
A
Okay,
that's
going
to
be
a
little
bit
hard
on
our
tools
right
because
the
go
mod
for
client
go
is
generated.
C
The
go
mod
for
current
versions
is
generated.
Retractions
are
only
read
from
the
latest
version,
so
we
would
actually.
I
think
we
would
need
to
release
a
1.5.2.
C
Thing
that
we
are
trying
to
do,
or
is
it
it's
a
one
time
thing
we're
basically
trying
to
get
rid
of
these
versions
like
from
being
auto
selected,
and
so
I
think
it's
1.5.2
or
any
any
cement
december
release
higher
than
1.5.1.
C
C
The
the
tricky
thing-
and
this
is
what
I
need
to
check-
is
that
we
wouldn't
actually
want
1.5.2
to
be
used
either.
So
we
would
have
to
retract
ourselves,
like
the
1.5.2
release
would
have
to
extract.
A
The
dates
and
then
yeah
yeah,
then
the
next
question
is
we
don't
need
to
wait
for
like
121
to
do
this.
Rightly
we
can
do
it
by
hand
ad
hoc.
C
A
C
C
No,
if
we're
doing
it
by
hand,
we
could
do.
We
don't
need
the
new
branch
publicly.
We
could
create
a
branch,
do
it
locally
and
then
push
a
tag.
The
tags
don't
have
to
be
on
branches.
C
A
A
Is
there
anything
else
we
can
do
like
instead
of
doing
0
22
we
can,
we
can
start
doing
122..
We
shouldn't
do.
C
C
Don't
actually
follow
sunburr,
right
and
and
like
right
now
the
v0.whatever.whatever
actually
indicates
the
compatibility
between
versions,
which
is
go
signatures
change?
Yes.
So
if
we
started
enforcing
go
signature
compatibility,
then
we
could
start
tagging
1.x
releases,
but
we
don't
have
a
credible
plan
to
do
that.
So
we
shouldn't
tag
one.x
releases.
Yet.
A
A
C
C
I
said?
Well,
we
were
trying
to
follow
simver
before
go,
modules
were
a
thing
and
then
you
released
go
modules
and
you
don't.
Let
us
release
major
versions
without
renaming
our
module,
which
we
can't
do
for
various
reasons
right.
What
we
really
want
to
do
is
just
like
mark
these
old
versions
as
bad
okay,
and
so
this
is
the
mechanism
that
allows
that
to
happen.
So.
A
A
A
So
another
thing
is
we:
if
we
do
this-
and
there
is
a
problem
we
would
have
to-
I
mean
we
would
go,
delete
the
tag
manually
and
go
tell
the
goproxy
people
to
delete
it
on
their
back
end.
I.
C
C
Oh,
I
I
wouldn't
do
it
without
like
trying
it
and
checking
with
the
go
folks
to
say
this
is
what
we're
planning
to
do.
Does
this
sound
right
to
you
and
then
actually
trying
it
on
like
a
test
repo
to
make
sure
like
I
would
set
up
a
test
repo
with
all
of
these
same
tags,
to
make
sure
it
behaves
the
way
we
expect
before
we
did
it
on
client
go.
D
A
C
Will
probably
start
experimenting
with
this
with
the
go
116
rc?
Okay,
let
me
make
a
list
of
things
to
verify,
verify
the
retractions.
Don't.
C
I
think
it
actually,
that
was
one
of
the
examples.
C
B
C
Good
and
then
we
need
to
verify
the
format
for
retracting.
C
Incompatible
version
tag,
so
the
tags
for
these
are
actually
like
tag
2.0.0,
but
the
module
version
is
2.0.0.
B
C
A
A
Sounds
good,
thank
you.
So
the
other
question
I
had
for
you
was:
did
you
get
a
chance
to
rustle
up
somebody
for
the
grpc
version
of
upgrade
yeah.
C
This
is
he's
on
the
td
team.
Okay,
so
he's
been
chasing
a
bunch
of
stuff
between
gogo
and
grpc
and
google
protobuf,
and
so
he's
he's
summarizing.
C
This
is
the
latest
summary
looks
like
there
were
performance
benefits
to
gogo
protobuf
at
one
point,
but
the
gap
has
been
closed
there.
C
C
I'm
going
to
check
to
see
if
dropping
gogo
would
be
possible,
so
that
was
the
first
piece.
The
second
piece
was
also
the
way
gogo
generates.
Code
is
different,
and
so
assuming
the
performance
issues
have
been
resolved,
then
it
would
be
a
matter
of
mechanically
switching
to
drop
gogo.
A
People
using
existing
versions
that
we
have
put
out
they'll
have
to
be
compiled.
C
Not
that
it's
that
all
of
the
dependencies
in
our
tree
that
do
protobuf
stuff
have
to
make
this
transition
like
we.
We
before
we
can
upgrade
the
underlying
library
to
1-4,
whatever
all
of
the
dependencies
that
do
protobuf
stuff
have
to
rebuild
their
proto
libraries
on
the
current
version
of
protobuf
and
drop
goku.
C
C
Putting
the
links
and
sorry
about
that
good
organization,
let
me
throw
the
link
in
there
as.
C
C
Coordinating
this
will
be
hard.
I
had
not
looked.
B
D
A
So
peter
has
the
pen
and
then
he
come
back
to
us.
He
then
we
have
to
go
see
what
he's
doing
and
make
sure
that
everything
else
can
switch
to.
C
A
C
A
So
yeah
also
even
if
hcd
switches
they
have
to
make
a
one
release.
I
think
in
a
full,
it's
a
1.5
right
or
3.5
yeah,
so
3.5,
so
they
have
to
release
that
they
don't
have
a
three
four
three
five
zero.
Yet
as
far
as
I
know
so
right,
so
they
have
to
release
that
and
then
we
have
to
switch.
A
So
there
is
time
you
know,
even
after
they
put
out
a
release,
there's
going
to
be
time
before
we
switch
to
it.
So
the
other
question
I
had
is
the
the
wire
protocol
does
not
mean
right,
correct.
A
Okay,
so
the
so
basically
the
handshakes
with
older
gogo
protobuf
based
stuff
will
continue
to
work.
C
Yeah
across
the
wire,
if
you
have
a
wire
boundary,
it
works,
it
works
fine.
The
issue
is
purely
like
passing
structs
that
have
pointers
or
don't
don't
have.
The
expect
aren't
aren't
following
the
expected
generation
to
something
and
saying
please
please
serialize
this
and
then
serializer
is
optimized
for
what
it
expected
to
be
generated
and
you
handed
a
struct
generated
by
some
other
random
version
of
some
other
random
thing.
That
says
like
anik
like
I
I
wasn't,
this
should
be
a
pointer.
It's
not
a
pointer
blow
up
so.
A
So
when
we
so
the
sequence
would
be
they
make
this
change
in
hcd,
then
we
have
to
run
calibrated
tests
against
this
lcd.
A
And
then
I
don't
know,
would
we
run
scalability
test
without
switching
the
vendor
directory
or
with
vendor?
You
know
both
should
work
right
before
rendering
the
new
lcd
client
we
should.
We
should
still
continue
to
work
right.
A
C
Know
how
to
I
think
the
performance
tests
that
they
were
referring
to
were
not
like
our
scalability
tests.
I
think
they
were
like
unit
test
benchmark
types
of
things
like.
A
Understood
yeah,
no,
I
mean
for
our
side
right
like
before.
We
can
switch
to
a
new
version
of
xcd
yeah.
We
like
we
do
a
bunch
of
things
and
one
of
them
is
running
the
existing
code,
as
is
against
a
new
version
of
http
yeah.
Assuming
that's
where
the
wire
protocol
stuff
comes
in
right,
where
we
bump
the
server.
A
The
client
yeah
and
then
once
we
are
sure
that
there
is
no
regression
on
the
server
side.
Then
we
switch
the
client
to
the
directory
and
then,
when
we
switch
the
client
to
the
new
version,
that's
when
we
want.
We
need
to
be
sure
that
our
other
dependencies
are
switched
away
from
google
protobuf
yeah.
Okay
sounds
good.
A
I'm
sorry
say
it
again:
have
you
heard
anything
from
the
customized
folks,
k-u-s-t
or
m-I-e-c
on
on
when
they
can
separate?
They
depend
on
kubernetes
and
we
depend
on
them
the
circular
dependency?
No,
I
haven't.
No,
I
haven't
I.
I
can
poke
poke
them
this
week.
Put
on
that
smile
like
yeah.
A
And
then
the
other
other
few
things
that
are
coming
down
the
pike
is
run
c,
is
going
to
be
there's
going
to
be
either
a
rc
or
a
one.
Zero
zero,
so
run
c
is
going
coming
up
container
d,
one
one
five
is
coming
up.
A
So
we'll
need
to
bump
to
those
I'll
have
to
go
back,
go
to
them
and
check.
If
we
are
using
a
newer
dependency
than
they
are,
then
I
need
to
switch
them
over
to
the
ones
that
we
are
using.