►
From YouTube: 20210218 SIG Arch Code Org
Description
GMT20210218 190500 SIG Archit 1942x1092
A
A
B
A
How
about
how
about
now,
yep,
okay,
okay,
so
kubernetes
community
has
a
sig
architecture.
Sig
architecture
is
responsible
for
architecture,
so
there
is
five
sub-projects
in
music
architecture
so
enhancements.
You
can
read
there
so
well,
four
plus
the
main
meeting.
So
currently
we
are
talking
about
the
code
organization
part
here
and
switching
back.
This
is
our.
D
D
D
Our
client
go
repo
has
some
weird
versioning
issues,
and
because
of
that,
if
someone
just
says
go,
get
client
go,
they
get
like
a
super
old
version
of
it
that
doesn't
actually
work
well
with
latest
versions
of
other
stuff.
Go
116
gives
us
a
way
to
fix
that
by
basically
marking
those
old
versions,
as
ones
that
shouldn't
be
preferred
anymore,
so
that
the
latest
current
one
current
versions
are
preferred.
D
F
D
In
order
to
mark
these
versions
as
bad,
we
actually
need
to
tag
a
new
version
that
includes
those
directives
saying
these
versions
are
bad
and
that
version
has
to
be
the
latest
valid
semver
tag.
So
it
would
be
1.5.2
question
is
what
should
the
content
of
the
1.5.2
tag
be,
which
will
be
used
by
go
versions
older
than
go
116.
D
D
A
D
A
D
D
A
A
D
It's
thursday,
I
will
summarize
this
tag,
stefan
for
comment
and
plan
to
do
it
next
week,
sometime
assuming
like
a
friday,
no,
maybe
mid-week,
so
that
if
there's
an
issue,
we
don't
go
to
work
in
the
weekend
time
to
address
it
before
the
weekend.
Yeah,
let's
say
next
wednesday.
Just
I
just
pulled
that.
A
A
What
do
I
remember?
I
I
yes,
this
was
the
last
thing
that
I
did.
I
I
looked
at
it.
I
looked
at
the
files.
There
was
only
one
file
and
the
file
had
didn't
have
too
many
things,
the
the
directory
looked
scary,
but
you
know
when
you
look
looked
at
the
directory.
There
was
literally
nothing
there
except
for
this
one
file.
So,
and
you
know,
I
think
we
should
just
go
ahead
with
this
all
right.
A
A
D
A
D
A
A
A
D
A
D
I
I
mean
at
this
point
I
think
the
cloud
provider
integration
has
a
target,
I
want
to
say
124
yeah,
if
there's
a
an
actual
target
release
for
dropping
that,
and
that
would
resolve
both
of
the
two
remaining
items.
I
would
probably
close
this,
like
nothing
specific
is
going
to
happen
on
those
two
libraries
between
now
and
124
is
my
guess.
A
D
A
A
We
got
rid
of
one
of
we,
we
got
it
off
golan
right
yeah.
We
still
have
govet
and
static
correct,
so
what
I
ended
up
doing
was.
I
went
down
another
path
which
is
to
see
I
wanted
to
introduce
gold,
golang,
ci
lint
in
some
fashion,
and
what
I
ended
up
doing
was
checking
if
we
could
run
just
these
three
dead
code
unused
and
var
check
right,
so
dead
code
unused
and
var
check
basically
pop
up
things
that.
A
Unused
code,
so
so
a
new
I
I
I
messed
around
with
struct
check
and
I
decided
okay,
we
are
not
going
to
do
struct
check
because
it's
finding
stuff
that
is
actually
valid
users
and
which
you
know
you
stuff
in
something,
and
then
you
serialize
it.
You
know
and
it's
not
understanding
that
it
is
still
being
used.
So.
A
Right
yeah,
the
point
here
also
was
to
gently:
introduce
it
so
so
definitely
aircheck
and
enough
assign.
I
will
go
next,
but
the
idea
here
was
to
do
at
least
these
three
then
see
how
many
places
we
need
to
fix
up,
and
with
these
just
so,
we
found
like
a
two
dozen
places,
which
are
all
simple
delete
line,
delete
a
line,
delete
a
bunch
of
lines,
kind
of
thing.
A
D
A
A
I
was
like
going
through
each
line
by
line
and
I
made
sure
that
it
doesn't.
That
is
exactly
the
problem
we
had
lubomir
when
we
were
telling
people
to
fix
golan
and
people
who
are
changing
public
stuff
right.
So
we
don't
want
to
repeat
the
same
mistake
here.
I
agree.
Okay,
so,
and
also
this.
This
will
help
get
more
people
into
trying
things
out
with
kubernetes
filing
prs
and
doing
actually
things
that
we
would
like
them
to
fix.
So.
D
D
I
don't
know
I
mean
we,
we
can
know
that
that
is
like
we
shouldn't
remove
public
stuff
or
we
can
look
at
and
say.
Okay,
that's
not
actually
that's
a
file
that
we're
not
publishing
in
a
module
for
consumption.
It
would
be
nice
if
you
could
say
like
unused
private
or
unused
public,
but
I
don't
know
if
it
has
that
level
of
granularity
well,.
A
Yeah
the
problem
lubomir
is
when
we
tell
people
who
are
just
calling
kubernetes
to
run
the
script
and
fix
the
errors
that
it
shows
right.
They
will
end
up
just
deleting
the
method
because
they
don't
understand,
they
might
not
see
the
problem
that
this
is
like
a
public
method.
It
might
be
called
by
somebody
else
in
the
ecosystem.
Right.
D
I
mean,
alternatively,
if
you
have
a
public
method,
that
you
have
no
tests
around,
that's
pretty
questionable,
so
I
think
even
just
adding
a
test
would
make
that
be
used
so
yeah,
if
you're,
if
you're
exporting
a
public
api
and
not
testing
it,
that's
really
questionable.
Actually,
but
the
right
thing
to
do
there
is
probably
test
it
not
remove
it.
A
A
Let
me
see
how
many
things
we
can
fold
into
this
script
and
delete
duplicate
scripts,
and
the
other
problem
to
think
about
here
is
like
how
much
time
this
takes
by
itself
and
how
much
time
does
the
other
ones
take,
and
then
we
have
to
figure
out
whether
we
need
to
run
another
job
and
how
to
divvy
up
where
to
run
the
scripts
and
stuff
like
that.
Anyway,
that's
far
down
the
line,
so,
but
you
know,
started
the
process
here,
I
don't
think
there
was
any
update.
A
F
F
A
A
D
Jordan,
the
discussions
around
that
are
continuing-
I
don't
know
yet
it
it
hasn't
stalled
out
like
there
are
still
people
paying
attention
to
it.
So
peter
is
working
on
trying
to
force
a
decision
there
in
terms
of
like
migration
or
maintenance
or
fixing
or
patching.
Like
he's
continuing
to
push
on
that,
I
don't
have
a
good
answer
yet
for
what
we'll
need
to
do?
D
A
Alina
alina,
what
never
mind
elena
katz
said
that
she
might
be
help
interested
in
helping
a
student
with
this
program
as
well.
So
we
ended
up
trying
to
expand
on
the
things
that
we
were
looking
at
as
background
research
and
a
couple
of
people
chimed
in
saying
that
they'll
be
interested,
including
harsh
harsh.
B
Yeah
hi
everyone,
so
what
I
was
like
discussed
with
emanum
was
like
the
blog
you
wrote,
which
used
like
grep
and
wn
w
gate
and
all
these
scripts.
So
basically
we
could
have
a
custom
cli
where
we
try
to.
You
know,
have
a
single
command
for
all
of
these,
whereas
internally
we
are
using
something
similar
to
crep
and
duplicate.
I
actually
posted.
F
D
B
A
A
B
A
A
I
needed
this
right
like
I
wanted
to
see
what
are
the
new
packages
that
are
getting
added
and
what
is
the
call
stack
basically
for
for
the
for
the
ones,
so
I
ended
up
putting
together
this
hackmd,
which
is
what
ash
was
talking
about
right,
but
I
want
to
flip
the
thing
back
to
the
original
problem
that
we
were
trying
to
discuss.
Is
this
one
right?
What
is
the
information
that
we
need
to
print
in
a
report
for
every
pr
that
gets
logged,
and
that's
where
I
want
to
start
jordan?
D
D
D
So
those
those
are
the
three
sort
of
categories
of
transitive
dependencies,
and
so
what
that
looks
like
is
those
don't
show
up
in
our
vendor
directory,
but
it
does
show
up
in
our
go
mod
files
and
it
makes
those
relationships
way
more
complicated
and
so
like
dependencies
that
we
don't
vendor,
but
do
that
are
still
in
the
dependency
tree.
Like
that's
an
interesting
metric.
D
So
before
you
know,
before
this
pull
request,
there
were
100
things
in
our
dependency
tree
that
we
don't
vendor,
and
after
this
there's
200
things
in
our
dependency
tree
that
we
don't
vendor.
That's
a
smell
that
we
probably
don't
want
to
take
this
update
without
at
least
going
to
the
upstream
component.
Saying
can
you
like
carve
some
of
those
off
or
drop
some
of
those
release?
Engineering
tools
move
those
to
a
tools,
sub
module
or
yeah.
D
So
we
we've
seen
that
in
c
advisor
c
advisor,
the
c
advisor
binary
had
a
ton
of
dependencies
that
we
didn't
even
use,
and
so
we
got
them
to
split
that
off.
The
customized
thing
is
a
good
example
of
that,
where
we're
not
actually
using
this,
but
some
other
bit
of
it,
depended
on
it
so
number
dependencies
depth
of
dependencies
dependency.
Is
we
don't
vendor
but
do
on
in
our
go
mod
file?
Now
those
are
the
three
most
obvious
ones
that
tend
to
get
noticed
manually
and
spur
like
pushback
or
discussion.
A
D
A
D
B
A
Okay,
so
what
I
would
then
say
is
start
a
google
doc
write
your
thoughts
about
you
know
what
we
discussed
just
now
and
have
lou
bomer
me
and
jordan,
pika
and
alina,
of
course,
right
give
examples
of
give
examples
of
exactly
what
you,
what
end
user
is
going
to
see
and
then
we'll
work
backwards,
to
figure
out
how
to
get
that
information
and
how
to
collect
what
code
to
write.
What
you
can
reuse,
that
kind
of
stuff.
B
B
A
A
F
A
F
F
F
A
A
F
To
buy
the
setting
originally
the
system
d
and
a
package
specs
were
in
kk.
At
some
point,
we
moved
we
duplicated
the
the
specs
in
the
k,
release
repository
and
bazel
built.
The
basic
build
were
producing
from
kk
was
producing
artifacts
in
one
way.
The
other
one
was
the.
What
was
the
other
build
like?
The
other
group
built
was
producing
from
k,
release.
D
Release
tooling,
living
in
k
release
makes
sense
if
there's
anything
that
would
be
version
specific,
like
component
invocations,
then
that
should
be
in
kk
or
in
a
repository
which
matches
kk
versioning
so
has
a
release,
118
1920
branch-
I
don't
have
a
strong
opinion
about
which
approach
to
follow.
I
think
it's
easier
for
the
cubelet
invocation
to
live
where
the
cubelet
code
is
defined.
D
I
think
the
only
reason
the
current
system
has
worked
as
long
as
it
has
is
that
the
cubelet
invocation
changes
so
rarely,
but
that
doesn't
mean
this
is
a
good
approach,
so
either
the
cubelet
invocation
piece
should
live
in
kk
or
the
place
it
lives
in
k.
Release
should
be
versioned
by
branch
or
by
folder,
along
with
the
kubernetes
releases,
I
will
defer
to
the
node
and
the
release
folks
about
which
approach
they
want,
but
I
agree
that
a
single
unversioned,
cubelet
systemd
spec
in
some
other
repo,
is
not
workable.
Long
term.
D
Yeah,
I
would
gather
the
examples
of
that
happening
in
the
past
and
open
an
issue
saying
the
spec
needs
to
be
per
kubernetes
version
and
point
to
the
problems
that
have
been
caused
in
the
past
and
then
kind
of
lay
out
those
three
options
like
keep
it
where
it
is,
but
make
a
folder
for
each
version,
keep
it
where
it
is,
but
make
a
branch
for
each
version
or
pull
it
from
kubernetes
kubernetes
as
the
source.
I
would.