►
From YouTube: 20210318 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
B
B
That
ends
up
touching
a
lot
of
module
package
related
things
so
like
the
the
build
and
the
make
files
and
the
code
generation
pieces
right
all
sort
of
have
gopath
assumptions
baked
into
them
at
various
places,
so
that
that
issue
is
sort
of
listing
the
the
known
issues,
it's
sort
of
an
umbrella
issue
like
I
said,
I'm
not
I'm
not
exactly
sure
how
much
of
that
is
code
organization
like
the
build,
is
great
release,
but
tim
hawkin
wrote
most
of
it.
So
I
don't
know
code.
A
C
A
Or,
and
or
hunt
people
who
can
like
go
fix,
cogen
whatever
right.
B
The
reason
this
is
increased
in
priority
is
because
the
go
lang
project
has
at
least
said
they're
going
to
drop
support
for
gopath
mode
in
go
117.,
we'll
see
if
that
actually
sticks,
but
there's
at
least
the
potential
that
we
would
not
be
able
to
pick
up
go
117
until
we
completed
this
work.
A
B
They
don't
actually
so.
Okay,
our
our
build
like
creates
a
fake
go
path
like
if
you
look
it,
we
have
a
run
and
go
path,
task
which,
like
creates
a
directory
structure
and
then
does
like
sim
links
or
copy
files
or
like
it.
It
does
things
internally
so
that
wherever
you
check
out
kubernetes
kubernetes.
A
B
Like
inside
the,
I
think,
output
directory
underscore
output,
like
it'll
it'll,
make
it
look
like
a
go
path
there
and
be
happy
okay.
So
so,
as
far
as
the
rest
of
the
world's
concerned,
like
you
can
clone
kubernetes
kubernetes
anywhere,
I
think
it
doesn't
have
to
be
in
your
go
path,
but
that
only
works
as
long
as
the
go
tooling
like
actually
still
honors
the
past
stuff.
So
right.
A
Yeah
I'm
asking
because,
like
the
we
still
in
our
documentation,
we
say
that
people
need
to
check
out
under
a
certain
path:
yeah
yeah,
okay.
I
I
will
cross-check
this
after
the
meeting
to
see
if
it
actually
works.
B
So
the
other,
the
other
item
that
is
at
the
top
of
my
list
is
the
protobuf
grpc
stuff.
B
B
So
yeah
again,
the
reason
I
this
is
becoming
more
urgent
is
that
if
we
ever
get
a
transitive
dependency
that
pulls
in
the
rpc
130
or
higher,
we'll
be
stuck
it's
like
we
won't.
We
won't
be
we'll
start
to
not
be
able
to
pick
up
new
versions
of
dependencies
and
as
soon
as
that
means
we
can't
pick
up
a
critical
bug,
fix
or
security
fix.
That's
going
to
become
an
emergency,
so.
A
Yeah
continuity
is
getting
there
jordan,
you
know
they
are
relying
on
other
things,
and
people
are
like
updating
like
leaf
libraries.
Just
because
you
know
somebody
made
an
update
and
they
were
not.
They
didn't
know
this
and
it
gets
pulled
into
container
d
and
then
we
end
up
pulling
continuity.
So
that's
happening
already.
A
A
So
on
the
well
we've
talked
about
the
google
protobuf.
Before
do
we
have
any
update
on
like
we
are
able
to
take
it
out
or.
B
I
mean
we
can't
take
it
out
without
rewriting
how
kubernetes
handles
proto
off
so
okay,
so
nail,
we
it
yeah.
It
is
deeply
entrenched
in
how
we
work
with
protobuf
stuff
right.
I
think
the
effort
to
fix
gogo
protobuf
to
be
compatible
with
the
newer
grpc
stuff
would
be
significantly
smaller
and
safer,
but
that
means
like
going
to
that
project
and
seeing
if
they
will
accept
changes
or
fixes.
So
I'm
not
I
I
haven't
gotten
there
yet,
but.
A
Yeah
hi
ash.
Is
there
anybody
to
help
you,
jordan,
with
this
google
protobuf.
B
Yeah
so
peter
has,
and
tim
hawkin
have
been
involved
in
discussions
between
the
grpc
team
and
trying
to
figure
out
if
it's
a
p-I-o-t-r.
B
So
I
peter
has
been
coming
at
this
from
the
etsy
side
and
has
really
been
driving
discussions
at
least
internally.
So
I
would,
I
would
probably
look
to
one
of
them
to.
B
B
Right,
they're
yeah,
I
think
they've,
I,
the
the
feeling
I
get
from
the
issues
that
I
saw
over
there
is
that
they
would
be
receptive
to
someone
sort
of
taking
on
adapting
it
and
making
it
work,
but
they're
not
driving
it.
It's
not
a
blocker
for
them.
I
don't
even
know
if
they're
using
it
anymore,
they.
A
They
want
some
from
what
I
remember
they
want
somebody
who
will
take
over
the
maintainership
in
all
aspects,
and
not
just
this
one
targeted
fix
for
newer
grpc.
I
think
yeah.
E
A
Which
we,
I
don't
think
anyone
any
one
of
us
want
to
take
yeah
at
this
point.
B
B
A
Right,
how
can
we
get
an
update
from
peter
and
tim.
A
A
I
up
digging
into
why
continuity
go.
Some
still
has
a
kubernetes
category
version
13
in
gosam
not
in
go
mod,
just
go
some,
so
I
tracked
it
down
to.
E
Okay,
so.
A
So
the
continuity
main
repository
depends
on
these
four
continuity
repositories,
which
are
on
the
older
version
of
continuity
and
they
end
up
pulling
hcs,
hcs,
shim
image,
script
and
various
versions
of
continuity
and
ends
up
with
the
older
version
of
continuity.
A
So
in
the
end,
if
you
go
back
here,
you
end
up
with
v,
0
h,
7
of
h,
h,
c
s,
h
c
s
shim,
which
depends
on
q,
k,
sayo,
kubernetes,
v,
113.
B
A
So
I
was
able
to
automate
generating
this
graph,
so
it
will
be
easier
next
time
so
me
and
sebastian
from
docker.
We
are
working
on
the
kubernetes
maintainers
slack
channel,
trying
to
clean
this
up.
B
A
Yes,
so
we
need
to
get
v15
out
of
continuity
that
will
clean
up
a
bunch
of
things.
Okay,
but
then
what
we'll
have
to
do
is
we
have
to
go
around
fixing
everything
else
to
use
v150
just
doing
that
is
not
going
to
be
enough,
we'll
have
to
do
one
more
iteration
to
clean
it
up,
so
we
need
at
least
two
iterations
from
the
way
I
see
it,
so
we
are
working
on
like
a
few
projects.
A
At
this
point
we
are
talking
to
the
microsoft
hcs
shim
guys
as
well,
and
we
have
some
issues
open
with
them
and
sebastian
has
a
we
are
open
with
them.
She
he
got
three
pr's
merged
over
the
last
two
days
to
clean
some
stuff
up,
so
we'll
we'll
need
continuity,
release
we'll
need
the
hcs
shim
release
and
then
we'll
have
to
do
one
more
time
of
both
going
around
updating
all
the
repositories.
A
So
it's
going
to
be
like
a
couple
of
steps
of
tango.
B
A
So
this
is
a
python
script.
So
another
example
that
I
did
was
you
know
you
know
we
pull
in
our
cio
pdf
right.
I
know
we
used
to.
I
thought
that
got
cleaned
up.
A
We
haven't
merged
the
pr.
Yet
there
was
a
pr
open
from
d,
lauren
c
and
and
we
haven't
merged
it
yet
for
121,
so
we'll
have
to
reopen,
but
I
use
this
as
a
exercise
to
see.
If
I
can
do
this
in
hours
too-
and
this
is
the
python
script.
A
Works
arch
also
kicked
the
tires
on
this,
so
he
cannot
test
that
it
gives,
you
know
decent
output,
so
it
just
goes
through
the
go
mode
graph
and
you
know,
builds
up
for
this
path.
For,
for
this
specific
dependency,
what
are
the
relevant
packages
and
then
it
goes
through
one
more
round
of
go
mod
graph
and
pick
make
sure
that
it
we
keep
the
version,
numbers
and
stuff
like
that,
and
it
ends
up
drawing
it.
So
it's
pretty
easy
to
use
so
I'll,
throw
the
link
here.
E
E
For
why
something
ended
up
in
go
some
file.
A
Okay,
so
this
was
what
I
was
doing
for
the
last
couple
of
days.
G
A
Thank
you,
jordan,
anything
else
or
we
just
limit.
B
A
Okay,
internship
arsh:
how
far
have
you
gotten
do
you
have
an
update
for
us.
D
Yes,
so
I
was
able
to
fix
the
issue
where
we
like
for
the
finding
out
the
max
depth
of
dependency
chain.
Each
time
I
was
running
the
script
which
I
wrote.
It
generated
a
new
number
and,
like
I
realized
that
was
because
I
was
storing
all
the
dependencies
in
the
map
and
the
way
maps
are
iterated
in
golang.
D
Is
it's
it's
not
a
fixed
order
each
time
so,
but
from
that,
I
found
out
that,
like
my
script
can
be
simplified
because
whatever
the
longest
dependency
chain
will
be,
it
will
always
start
at
the
main
module
right
because,
like
it's
yeah,
so
we
don't
need
to
iterate
and
all,
but
other
than
that.
D
I
have
been
pretty
much
stuck
in
how
to
like,
find
my
way
around
like
how
to
find
the
longest
path
in
a
graph
when
there
are
so
many
cycles
there
and
they
are
like
intertwined
with
one
another
and
I've
mostly
been
reading
stuff
about
graph
theory
and.
A
So
did
you
look
at
the
graph
packages
that
I
showed
you.
D
Yes,
the
ones
you
mentioned
in
slack,
I
did
go
over
them,
but
like
for
most
of
their
like
use,
I
was
not
able
to
use
them
here
because,
like
they
were
dealing
with
much
simpler
stuff,
I'd
say
so.
I
was
kind
of
hoping
like
if
I
could
like
show
you
what
the
brief
algorithm
is
and
maybe
something
obvious,
I'm
missing.
E
D
Yeah,
okay,
it's
saying:
host
disabled
participants.
B
Yes,
it's
probably
daylight
savings
time.
It's
us
daylight
savings
time
based
yeah,
but
and
that
doesn't
give
everything
an
hour.
B
B
D
D
I
get
the
output
in
a
string
and,
like
I
read
that
line
by
line,
and
I
separate
the
versions
from
it
and
I
add
all
these
dependencies
to
a
list
and
then
basically,
I
create
a
graph
in
an
adjacency
list
form
which
is
a
map
of
string
to
an
array
of
strings
where,
like
for
each
dependency,
I
store
it's
like
whatever
it
depends
on
so
now
for
printing
the
longest
path.
D
What
I
am
currently
doing
is
that
I
run
a
depth
first
search
from
the
main
module
and
I,
at
the
same
time
I
like
have
a
array
to
keep
track
of
which
nodes
I've
already
visited
and
like
a
lot
of
from
what
a
lot
of
stuff
I
read,
they
were
all
like
about
using
dynamic
programming
to
optimize
this.
D
So
there's
a
dynamic
programming
array
which
will
like
store
so
dp
of
x,
will
store
what
is
the
max
length
of
dependency
chain
when
I
start
from
x
right.
So
this
depth
first
search
is
the
code
is
pretty
simple,
but
it's
giving
the
results.
It's
like
mark
the
current
dependency
as
visited
then
iterate
through
all
of
the
things
it
depends
upon
and
if
you
haven't
visited
them,
then
run
a
depth
first
search
on
that
and
whatever
like
the
length
you
get
so
like
if
a
depends
on
b.
D
A
D
A
So
at
this
point,
are
you
trying
to
count
the
max
depth
or
are
you
trying
to
print.
C
D
Initially
I
was
about
printing,
it
was
all
about
printing
it.
So
when
I
do
printed,
I
like
get
28
as
a
result
for
the
coupon.
It
is
repo,
but
to
like
verify
this,
we
talked
about
adding
a
verbose
mode
which
will
print
out
the
longest
dependency
chain.
But
the
thing
is
when
I
do
that,
I
get
this
chain
and,
like
its
length,
is
14,
and
that
has
nothing
to
do
with
28..
D
So
I
don't
know
which
output
to
trust
this
one
or
this
when
I
track
this
chain
manually-
and
this
does
exist.
D
B
So
when
you're,
when
you're
computing
max
depth,
like
one
one
of
the
useful
things
to
be
able
to
do,
is
to
like,
as
you're
figuring
out
a
depth
like
record
the
path
that
got
you
that
depth.
D
Yeah,
that's
what
I'm
doing
in
this
video
but
like
whenever
I
update
like
so
like
I
said
you
take
a
then
you
iterate
through
its
dependencies,
and
then
you
say
that
you
know
like
let's
say
it
depends
on
b
and
c.
So
you
say
that
if
the
chain
starting
from
b,
is
greater
than
whatever
value
is
already
present
in
a
add
one
to
it
and
update
it
in
a
and
when
you
do
that,
updation
then
in
longest
path
of
k
store?
D
A
So
one
thing
you
could
do
like
quickly
is
in
a
hard
code
when
you
reach
28
what
node
you
are
on
right
and
then
we
can
go
back
from
there.
If,
if
that
itself
is
not
the
big
query
one
then
you
know
there's
a
problem
right.
There.
A
Okay,
so
let
me
frame
it
another
way
when
you
visit
a
node
right
print,
the
full
path
right
doesn't
matter
where
you
are
right.
So
when
you
visit
another
node
print,
the
full
path
to
the
root
right
print,
one
on
each
line
with
the
depth.
A
A
So
that's
a
simple
way
of
debugging,
because
right
now,
you're
printing,
only
one
and
you
don't
know
whether
it's
the
right
one
or
not
right
so.
D
You're
saying
like
each
time
I
go
into
this
dfs
function,
I
just
print
out
what
the
longest
chain
is
from
the
current
dependency.
It
is
visiting.
A
B
B
D
Yeah
a
bit
like
one
thing
like
as
I
kept
reading
more
about
it
like.
Can
this
even
be
solved
because
a
lot
of
like
people
were
saying
like
this
is
supposed
to
be
an
np,
hard
problem
or
something,
and
it
has
no
like
computation
in
a
reasonable
time
when
there
are
so
many
cycles
and
stuff.
So
we
skip
the
cycles.
A
D
B
I
mean,
if
you
step
through
the
dependencies
in
a
deterministic
order
and
you
handle
cycles
in
a
consistent
way
like
if
there's
a
cycle
you,
you
record
the
length
of
the
cycle,
and
then
you
say,
like
I'm,
not
going
to
recurse
that
anymore.
Then
it
will
at
least
be
reproducible
yeah.
So
the
the
key
is
handle
cycles
in
a
consistent
way
and
traverse
the
list
of
dependencies
in
the
same
order
so
like
out.
D
So
for
that
like
if
we
go
by
alphabetical
order,
like
the
problem
comes
here
like
if
you
you
know
like
this
is
a
change.
So
if
you
let's
say
like
a
is
also
connected
to
c
all
right,
if
you
start,
if
you
start
visiting
dependencies
of
a
and
let's
say
you
come
at
c
first,
then
you
will
say
that
you
know
c
has
a
length
of
one
two
and
three
right
and
that
will
affect
all
your
other
results
of
b,
e
and
d.
A
Yeah
that
that's,
why
I'm
saying
like
if
you,
when
you
visit
a
node,
if
you
have
all
its
parents
right
and
if
this,
if
this
is
the
current
longest,
then
you
store
it
right.
A
Okay
and
you
go
to
and
while
you're
doing
this
visiting,
if
the
current
visited
node
is
longer
than
the
previously
stored
chain,
then
replace
it.
A
Yeah
we
stopped
the
cycles
already
and
you
know
we
don't
really
care
whether
you're,
visiting
b,
first
or
c.
First,
because
we
have
we
visit
both
and
we
know
e
whether
we
visited,
b
or
c
the
longest
one
is
you
know
we
we
we're
going
to
end
up
with
the
one
which
is
the
longest.
A
A
Print
account
of
how
many
nodes
were
there
and
do
this
again
and
again
it's
going
to
be
very
verbose,
but
then
you
can
sort
because
the
first
one
is
a
number
right.
You
yeah,
you
can
do
like
sort
command
and
you
can
sort
it
as
a
number
and
then
you
will.
Then
you
can
eyeball,
which
one
was
the
longest,
and
you
can
compare.
A
A
Okay,
if
you,
if
you
don't
get
the
hang
of
it,
I
will
prototype
it
in
python
and
then
you
can
turn
it
into
go.
If
you
want
okay,.
E
B
Talk
about
like
the
cycles
thing
is
actually
a
good
signal.
So
if
you
encounter
a
cycle
recording
that
so
that,
like
we
know,
there's
a
cycle
cycles
are
not
generally
something
we
want.
So
as
you
encounter
them,
that's
also
a
useful
signal
to
dump
out.
A
Back
and
we'll
you
know
chat
about
this
again,
okay!
Yes,
I
will
do
that
thanks
thanks.
Okay,
are
you
finding
this
useful
interesting?
Yes,
it's
a
lot
of
fun!
Okay,
good!
I'm
glad
to
hear
that.
So
we
have
sick
testing
and
nabarun
hi.
F
F
A
You
have
anything
to
talk
about
today.
We
made
a
notes
about
like
what
we
were
going
to
do
for
122..
One
was
the
go.
Build
no
longer
depends
on
gopath
thing,
the
other
one
was
proto
buff,
grpc
versions.
C
Not
in
particular
I
I
just
came
to
listen
today.
I
do
think
the
the
ghost
statement
thing
is
something
we
might
want
to
look
at
at
some
point,
but
it
seems
we
have
a
lot
of
other
things
already.
B
C
It
I
dug
through
a
bunch
of
issues,
and
it
seems
that
it
controls
if
a
module
is
allowed
to
use
language
features,
but
there's
still
some
debate
going
forward
as
to
whether
or
not
like,
for
example,
like
a
transitive
module
versus
the
root
module.
I
believe.
Currently
it
only
affects
the
root
that
said,
if
your
test,
even
if
it
doesn't
affect
through,
like
if
you're
running
tests
that
is
currently
the
root,
you
probably
want,
like
it's
still
an
assertion
that
like.
C
If,
if
you
have
a
module-
and
it
declares
a
version,
then
it
can.
It
controls
whether
I
can
access
that.
So
I
think
the
idea
is
more
like
if
they
have
added
functionality
to
go,
and
you
declare
like
a
lower
version.
Then
it'll
say
okay
well,
like
that
this
isn't
allowed
in
this
module,
because
I
don't
know
we
remove
this
functionality
or
something
so.
C
B
C
B
C
C
C
C
I'm
not
actually
sure
where
to
start
there
beyond
like
the
existing
issues,
I'm
not
sure
how
helpful
it
is
to
show
up
and
like
comment
be
like
hey,
we
still
still
need.
I
don't
understand.
A
So,
who
is
the
closest
a
familiar
person
to
kubernetes
on
the
go?
Go
team?
A
A
C
Yeah,
since
he
used
to
he
used
to
do
rules
go
so
that
would
be
my
guess,
but
I
I
haven't
really
had,
but
I
didn't
actually
know
who's
on
the
go
team
at
the
time.
I
haven't
really
had
any
direct
interaction
with
myself.
C
Okay
and
I'm
definitely
I'm
keeping
times
on
the
the
go
path
thing,
there's
a
whole
lot
of
hack
script,
stuff
that
wants
to
go
path
everywhere.
A
B
A
B
Make
there's
the
code
generators
which
I
think
like
if
we
fix
some
of
the
things
in
gen,
go
like
there
might
be
bits
and
pieces
that
are
on
the
individual
generators,
but
I
think
most
of
it
is
sort
of
the
guts
of
jengo.
So
if
we
fix
those
two
things,
is
there
a
lot
else
that
cares.
C
I
think
there's
going
to
be
a
long
tail,
because
a
pretty
standard
thing
that
we
do
is
we
like
set
up
a
fake,
gopath
and
stuff
is
not
we're
not
consistent
at
all
about
how
we
specify
packages
like
do
we
use
the
full
file
path?
Do
we
use
the
relative
path?
Do
we
use
the
actual
module
import
path?
C
There's
going
to
be
a
tail
on
that.
There's
also,
I'm
sure,
there's
other
fun
things
that,
like
any
one
of
us,
doesn't
know
about.
Like
surprise
kind
actually
looks
up
where
the
kubernetes
source
tree
is
by
asking
go
where
the
import
is,
which
only
works
in
go
path
mode.
C
So
we
want.
We
want
to
find
the
repo
root
and
then
start
building
from
there.
So
we're
gonna
have
to
make
sure
that
I
believe
we
are,
but
we
have
to
make
sure
that
everywhere
in
ci,
we're
like
explicitly
passing
that
in
because
we're
not
going
to
be
able
to
safely
rely
on
auto,
detecting
it.
It's
also
going
to
be
kind
of
hard
to
find
these
things
in
ci,
because
ci
is
like
hard
coded
developed
to
check
out
things
to
a
go
path.
B
A
Yeah,
okay,
so
or
is
there
a
environment
variable.
C
The
other
thing
I
found
is
that
we
don't
quite
consistently
call
the
like
ghost
setup
in
all
of
the
scripts
so
like
like
when
we
were
looking
at
some
of
the
structured
logging
testing.
Stuff
alana
was
finding
that
various
verified
scripts
didn't
work
for
her
because
she
doesn't
have
a
normal
gopath.
C
A
C
A
A
The
code
generator
does
not
work
for
me
if
I
am
not
in
gopats,
it
just
creates
some
arbitrary,
like
gener,
like
generated
files
in
the
go
path
that
I
traditionally
have
and
also
like.
I
faced
the
same
issue
with
kind
as
well,
so
I,
whenever
I
build
a
node
image
using
my
modified
code,
I
pass
the
argument
explicitly
that
here
is
my
cube
root,
so
I
dumped
a
bit
down,
but
then
I
am
really
new
to
django
and
the
code
generator.
So
I'm
digging
something
on
my
free
time
on
those.
A
C
I
can
yes,
the
severity
is
that
one
seven
go.
117
is
probably
going
to
require
us
to
have
this
solved,
so
we
have
about
six
months.
C
C
So
yeah
you
had
followed
up
with
the
go
team
a
bit.
I
think,
as
well
as
tim
on
the
performance
of
list
calls
in
our
generators.
Do
we
get
any
movement
on
that?
No.
B
C
B
B
B
But
it
requires
basically
rewriting
sort
of
the
loop
of
some
of
our
tools
like
the
code
generators
or
the
make
file
generator
to,
instead
of
being
like
file
driven
or
directory
by
directory,
driven
to
say,
like
here's,
the
stuff
I
want
to
generate,
let
me
slurp
in
all
these
packages
once
and
then
use
that
information
like
it's,
not
a
bad
change,
but
it
it's
basically
like
restructuring
those
tools
which
is
not
a
targeted
like
change
these
three
lines
and
it
works
now.
B
So
that's
what
tim
had
run
into
when
he
was
trying
to
fix
the
make
file
generation.
That's
what
I
ran
into
when
I
was
trying
to
fix
the
code
generation.
I
was
anticipating.
It
would
be
like
a
yeah
change,
these
three
lines
and
then
we'll
work,
and
it's
not,
and
it
hasn't
gotten
high
priority
enough
for
anyone
to
sit
down
and
actually
go
through
rewriting
those
tools.
I
think
tim
is
probably
the
best
resource
for
the
makefile
stuff,
either
to
do
it
or
to
pair
with
to
give
guidance,
because
he
originated
that.
B
I
think
stefan
probably
is
the
best
one
for
the
code
generator,
because
he
originated
a
lot
of
that
and
understands
like
how
those
are
wired
together.
B
So
if
you
are
wanting
to
start
diving
in
I
to
the
code
generator,
I
would
reach
out
to
stuff
on.
So
you
don't
spin
your
wheels
trying
to
understand
stuff
that
he
could
explain
in
10
minutes.
A
I
got
it
yeah.
I
think
we
are
referring
to
that
migration
to
x
tools,
packages,
issue
that
we
have
been
running
for
some
time
so
yeah
thanks
jordan.
For
that
insight,
like
I
reach
out
to
stefan
for
an
overview
that
would
be
like,
I
think,
helpful.