►
From YouTube: 20210819 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
All
right
here
we
go
so
this
is
a
code
organization
call
for
august
19th
2021.
There
are
not
many
people
here
and
there's
not
much
on
the
agenda,
so
it
might
be
a
short
meeting,
but
welcome.
B
A
A
Well,
all
right
go
7,
117
changes
to
go
path,
so
go
117
got
released
and
they
didn't
actually
end
up
making
changes
to
gopath.
So,
oh
did
you
do
that?
No,
they
that
got
deferred.
A
A
Find
hey
the
vermeer
hello
yep,
so
I
linked
to
the
the
issue
where
we
were
tracking
the
the
need
to
do
this.
Yeah.
C
I
was
actually
tracking
that
issue,
so
I
wanted
to
have
a
conversation
I
was
trying
to
like
port.
Some
of
the
support
generator.
Has
this
hard
dependency
on
go
path
to
determine?
Where
is
the
boilerplate
header
file,
and
that
is
like
a
big
limitation
right
now,
because
that
gets
the
path
using
reflect
just
it
does
reflect
on
an
empty
start
and
gets
the
package
path
of
that.
So
when
yeah
I
try
to
go
mod
mode,
it
does
not
work
with
go
modules,
one
so.
A
A
A
A
A
So
eight
two
five
three
one
is
the
tracking
issue.
So
this
is
the
tracking
issue
for
go
module.
Building.
This
was
a
generator
fixed
to
the
boilerplate
path.
A
So
that
merged
and
then
there's
a
work
in
progress.
A
I
can't
talk
and
type
at
the
same
time,
this
is
terrible.
There's
a
work
in
progress,
pull
request
which
basically
just
turned
on
modules
and
then
is
seeing.
What
breaks
and
trying
to
trying
to
fix
is
that
the
big.
A
No,
that's
that's
separate
from
go
117.,
so
the
one
I
just
linked
99226
that
yeah,
that
that's
that
just
enabled
modules-
and
this
like
see
seeing
what
breaks
or
seeing
what
takes
forever.
So
there
are
some
things
that
are
straight
up,
broken
and
we're
getting
to
the
point
where
most
of
those
are
fixed
and
then
the
ones
that
are
remaining
are
performance
problems
with
the
way
we
were
using.
Some
of
the
go
build
libraries.
C
Yeah,
I
remember
there
was
an
issue
with
jungo,
so
since
django
uses
the
old
way
of
doing
things
and
still
does
not
have
packages
to
load
but
there's
a
big
issue
on
the
go
repository
about
packages
that
load
having
like
multiple
go
list,
calls
which
eventually
making
it
slow
because
of
file
system
bottlenecks.
C
A
A
I
don't
know
that
yet,
so
I'm
proceeding
on
the
assumption
that
we
should
get
ourselves
to
a
place.
That
is
reasonable
in
case
gopath.
Support
goes
away
and
and
keep
raising
the
issue
with
the
go
team
to
say
this
is
impactful
to
us
and
probably
other
people,
and
it
would
be
helpful
if
you
would
help
us
solve
this
problem.
So
in
the
work
in
progress
pull
request,
I
have
sort
of
a
workaround
for
that
performance
issue.
If
you
look
at
the
last
two
commits
work
around
the
gengo
use
of
whoops
go
build.
A
That
is
like
a
hundred
times
slower,
so
we
could
rewrite
all
our
code
generators
like
to
work
instead
of
going
package
by
package.
A
We
could
we
could
rewrite
all
of
them
to
like
switch
to
doing
the
whole
tree
at
once,
and
maybe
we
want
to
do
that
eventually,
but
that's
a
lot
of
work
to
bite
off,
and
so
I
was
experimenting
with
sort
of
band-aid
fixes
like
if
the
first
thing
we
do
is
say,
look
at
all
the
packages
that
we're
about
to
process
one
by
one
and
resolve
their
directories
on
disk
using
the
new
go
packages.
A
Resolver,
that's
pretty
quick
like
that,
takes
a
few
hundred
milliseconds
and
then
we
have
a
mapping
from
package
name
to
directory
on
disk
and
we
can
instead
of
calling
the
slow
import
function
that
has
to
re-resolve
everything
we
can
call
the
import
dur
function
and
pass
in
the
directory
we
already
resolved
so
that
took
that
made
it
so
that
calling
like
make
generated
files
instead
of
taking
about
30
minutes,
took
about
three
minutes.
So
that's
still
like
three
times
slower
than
today
on
master,
like
you
say,
make
generated
files.
It
takes
about
a
minute.
C
A
If
you
like,
run
a
build,
it
calls
make
generated
files.
This
is
this
is
like
open
api
and
default
regen
and
defaults
deep
copies
things
like
that.
So
it's
pretty
much
every
time
you
do
anything
you're
actually
going
to
call
this
makefile,
so
yeah,
I'm
not
happy
with
it
being
slower,
but
did
that
that
would
come.
Boned
like
if
go
118
drop
to
go
path,
support
I
could
merge
this
and
we
could
survive
and
those
things
being
slow
would
probably
motivate
us
to
rewrite
them.
A
C
A
The
contracts
are
probably
best
effort,
but
I
would
assume
that
people
are
using
them
the
same
way.
Kubernetes
kubernetes
is
using
them,
and
so
the
piece
by
piece
changes
that
we've
been
making
we've
been
ensuring
work
both
in
module
mode
and
in
go
path
mode.
A
So
when
we
pull
it
into
kubernetes
kubernetes,
I'm
pulling
it
into
the
existing
master,
build
that's
still
using
gopath
and
I'm
pulling
it
into
this
work
in
progress
branch
that
is
using
go
modules,
places
where
gengo
is
doing
things
that
we
know
will
break
once
module
modes
is
completely
enabled.
I'm
adding
warnings
for
because,
like
at
whatever
point,
go
drops
go
path.
Support
like
regardless
of
what
jingo
is
doing,
people
will
be
people
will
be
affected.
So
here's
an
example
of.
A
A
It
doesn't
feel
like
you've
accomplished
much,
but
at
least
the
go
team
is
aware,
and
so
I
don't
think
they
will
just
drop
it
without
at
least
syncing
with
us,
but
these
are
the
issues
to
watch
if
you're
interested
or
affected
or
no
or
if
you
know
of
issues
that
aren't
mentioned
there,
please
like
link
to
it.
So
we
so
we
make
sure
we're
addressing
everything.
C
Yeah
the
reason
I
brought
it
brought
this
up
was
like
I
was
trying
to
have
a
dick
at
like
moving
from
the
older
way
of
loading
packages
to
the
new
uploading
packages,
and
I
myself
like
hit
all
those
roadblocks,
and
I
was
curious
like
how
do
I
go
about
them?
I
plan
to
discuss
this
in
one
of
the
meetings
and
it's
good
that
we
think
on
this,
and
I
know
like
what
is
happening.
A
Yeah
I
mean,
at
the
very
least,
like
add,
add
the
label
to
the
to
the.
If
you,
if
there's
an
issue
open
an
issue
for
it,
make
sure
there's
an
issue
for
it,
add
the
label
tag
tim
hawkin
or
I
or
dimms
just
so.
We
can
kind
of
the
label
is
the
big
thing.
So
we
can
see
the
issues
people
are
having
if
it
is
outside
of
kubernetes,
then
also
servicing
it
up
to
the
the
go
repository.
There
are
some
issues
there
around
like
use
of
the
packages
stuff.
A
So
there's
one
around
the
performance
and
then
tim
hawkin
has
opened
a
couple
issues.
So
if
it's
outside
kubernetes
I'd
be
interested
to
know
about
it,
just
for
my
own
information
but
making
sure
the
go
team
has
visibility
is
important
too.
C
If
I
was
actually
looking
looking
on
behalf
of
the
kubernetes
project
itself,
I
was
trying
to
investigate
that
and
like
fix
that,
because,
like
I
saw
like
several
people
had
commented
on
the
issue
like
they
would
love
to
see
see
this
happen
see
this
migration
happens.
So
I
was
like
okay,
let's
just
take
it
up.
I
was
interested
in
understanding
that
stuff
so
yeah,
that's
where
I
was.
A
Yeah
I
yeah
I
get
frustrated
with
people
who
wait
to
the
last
minute
to
get
off
of
deprecated
stuff,
but
then
I
realized
I
do
the
same
thing
with
like
kubernetes
build
stuff.
It's
like
oh
go
path
is
going
away.
It's
like!
Oh
well,
I'll
worry
about
that
the
release
it
goes
away
because
I've
got
too
much
else
to
do
so.
I
I
do
the
same
thing.
A
A
So
the
dependency
stats
pre-submit
in
kubernetes
kubernetes
uses
go
mod
graph
to
figure
out
what
our
direct
dependencies
are
and
what
our
indirect
dependencies
are
and
to
check
information
about
our
dependencies
and
go
117.
C
So,
let's
say
like
we
have
b
as
a
dependency
right
and
c
b
depends
on
c,
so
c
is
essentially
a
transitive
definition.
So,
right
now
I
see
an
edge
between
a
and
c
right
in
the
new
go
mod
yeah,
but
will
I
see
an
etching
on
b
and
c
as
well
in
the
comment
graph
or
that
line
is
removed?
Now
that
is
removed?
Is
it
no
no
there's
still
an
edge
between
b
and
c?
A
Okay,
now
it
it's
decorated
like
if
you
go
look
at
the
root
gomod
file,
it
it's
decorated
and
it
says
like
this
is
an
indirect
reference,
but
that
doesn't
show
up
in
go
mod
graph.
Gomod
graph
shows
all
edges
whether
they're
direct
or
indirect.
It's
it's
whether
it's
included
in
the
gomod
file
at
all
the
reason
they
did
this
was
so
that
the
top
level
module
records
all
the
transit
of
dependencies,
so
that
when
you
do
go
operations,
it
doesn't
have
to
go
out
and
fetch
all
the
intermediate
gomod
files.
A
So
I
I
don't
know
if
you've
seen
like
when
you're
working
in
module
mode,
sometimes
you'll
say
like
go
test,
something
or
other
and
it'll
like
go
fetch
35
dependencies
and
right
now
it
has
to
fetch
not
only
the
dependencies
you're
actually
using
code
from
like
for
the
packages
you're
using
it
has
to
fetch
all
dependencies
in
the
tree,
even
ones
you're
not
using,
so
that
it
can
figure
out
the
minimum
version
selected
for
things
and
so
by
denormalizing
up
to
the
top.
A
They
remove
the
need
to
transitively
fetch
things
you're,
not
actually
using
in
your
build.
So
there's
a
reason
they
did
this,
but
the
side
effect
is
that
it
messes
up
our
use
of
go
mod
graph.
It's
this
won't
happen
immediately.
We
we
can
still
in
our
go
mod
files.
We
can
still
say,
go
116,
even
if
we're
building
with
go
117-
and
we
won't
get
this
behavior
yet,
but
we
need
to
start
thinking
about.
A
A
I
I
don't
know
on
previous
versions
if
you
did
go
mod
tidy
and
then
called
go
mod
graph.
You
got
useful
information
and
now
I
feel
like
you
don't
so
I
it
doesn't
seem
great
to
me,
but
it
also
doesn't
seem
like
something
that
will
be
walked
back.
So
they
provided
a
couple
examples
of
how
to
use
go
list
to
get
the
same
information,
and
so
we'll
probably
want
to
track
switching
our
dependency
stats
to
use
that,
and
once
that's
done,
then
we
can
update
our
gomod
files
to
go
117.
A
I
think
you
would
go
list
everything,
so
you
would
say
like
go
list,
dot,
slash,
dot,
dot
in
json
format,
and
then
you
you
can
build
the
graph
you
want
based
on
that
which
go
mod
graph
used
to
do
for
you
sort
of
if
you
used.
If
all
your
dependencies
were
tidied
like
it
would
do
it
for
you
and
now
you
sort
of
have
to
build
it
yourself,
which
so
it's
a
pain.
Can't
we
use.
C
A
A
So
basically,
the
presence
of
an
indirect
dependency
in
our
root
gomod
file
means
that
we
have
an
opinion
about
what
version
it
should
be,
and
so,
if
we
are
explicitly
selecting
that
version,
that
seems
reasonable
to
have
as
an
edge
in
the
graph.
Even
if
we
don't
have
a
go
file
that
imports
that
package-
and
so
I
guess
today,
it
shows
up
as
a
direct
dependency,
even
if
we're
not
technically
using
it
in
go
code
directly.
A
In
case
I
or
kubernetes
but
hand
wavy,
it
seems
fair
to
have
an
edge
there
if
we
specifically
selected
that
version
for
some
reason
so
yeah
anyway.
So
I
think
the
the
first
action
item
here
is
to
open
issue
to
switch
dependencies
stats
to
use,
go
list
instead
of
graph
and
then,
after
that's
done,
switch
our
go
mod
files.
D
A
That's
a
good
point
or
external
cool
like
I,
I
I
looked
at
the
docs
for
it
a
little
bit,
but
I
didn't
dig
into
playing
with
it.
So
I
don't.
I
hadn't
had
a
chance
to
dig
into
it
yet.
A
The
good
news
is
it
this
isn't
urgent
like
we
can
do
this
after
we
switch
to
building
with
go
117.,
so
that's
nice,
but
if
what
we're
doing
now
isn't
going
to
work
long
term,
it's
easier
to
do
that
change
gradually,
instead
of
at
the
last
minute.
So.
A
C
D
How
about
you,
luberman
hello,.
A
I
didn't
hear
anything,
but
I
will
take
the
silence
to
me.
No,
are
you
not
hearing
me
hello?
Oh
no,
now
I
can
there.
You
are.
That
was
weird
all
right,
oh
in
terms
of
like
forward-looking
stuff,
so
we're
at
the
beginning
of
the
123
cycle.
A
My
big
push
for
code
organization.
This
cycle
is
trying
to
get
the
go
module
build
stuff
done,
so
we
kind
of
had
a
scare
with
go
117
and
a
reprieve,
and
so
I
would
like
to
be
in
better
shape
at
the
end
of
123,
so
that,
even
if
we
have
to
slow
down
generated
stuff
a
little
bit
as
we
transition,
how
that's
written
will
at
least
still
be
able
to
build
and
release
so
that
that
go
module
issue
that
I
linked
to
is
my
main
focus
for
123
for
code
organization.
A
I
think,
as
someone
who
has
to
review
a
lot
of
dependency
updates,
a
lot
of
things
are
caught
by
being
able
to
see
the
code
that's
actually
coming
in,
instead
of
it
just
looking
like
a
three
or
four
line
change
in
a
gomod
file,
but
in
reality
it
pulling
in
like
a
lot
of
concerning
changes.
A
So
from
a
review
perspective,
I
like
having
visibility
to
that.
D
A
The
the
other,
the
other
thing
is
reproducibility,
so
the
the
go
module
proxy
will
cache
versions
of
modules,
but
the
policy
around
how
long
those
cached
versions
are
available
is
pretty
unclear.
A
A
But
the
idea
that
if
I
check
out
the
repo
I
can
build
it
even
if
I
don't
have
access
to
the
go
module
proxy
or
even
if
the
original
sources
went
away,
that's
still
really
nice
and
maybe
I'm
just
old
school.
But
I
get
pretty
uncomfortable
when
I
have
to
pull
things
from
a
remote
source
in
order
to
build.
But
maybe
I
need
to
get
over
that.
D
D
A
Their
their
retention
policy
is
not
very
clear
that
that's
a
significant
question
like
I
think
we
would
have
to
answer
that
before
we
dropped
bender.
B
A
So
dropping
vendor
is
not
on
my
radar
as
part
of
the
go
module
build
changes
I
this
is
pretty
much
scoped
to
building.