►
From YouTube: 20210902 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
Hey
folks
welcome
to
the
code
organization
sub
project
on
the
segax
bi-weekly
meeting
today
is
september
2nd,
and
this
meeting
is
recorded
and
we
abide
by
the
cncf
code
of
conduct,
which
boils
down
to
be
excellent
to
each
other,
and
we
have
two
items
on
the
agenda
for
today:
I'll
actually
take
them
out
of
the
order
because,
like
the
yeah
they
in
the
order.
A
A
So
lumumba
created
this
issue
to
track
it
and
jordan
left
some
thoughts
and
the
idea
was
to
use
coalesce
dash
json
to
recreate
the
gomod
graph
graph
output
and
we
would
then
just
say,
feed
the
same
output
to
deb
start
so
for
creating
the
output.
So
this
is
the
command
we
tested
and,
like
I'll,
show
you
how
an
output
looks
so
that
you
have
more
context.
A
So
if
we
run
go
list
json
for
each
dependency,
we
get
this
where
we
have
and
like
import
path
and
then
its
particular
dependencies
and
one
of
the
important
things
is
standard.
True,
which
tells
if
it's
a
standard
dependency
or
not
so
jordan's
approach.
Was
that
build
a
map
of
from
import
path
to
the
module
by
which
he
meant
so
import
part
would
basically
be
the
name
of
the
dependency
and.
A
So
yeah
import
path
would
be
the
name
and
we
would
map
it
to
this
thing,
and
then
we
would
also
store
that
if
a
particular
dependency
is
a
standard
dependency
or
not
in
another
map,
and
then
he
basically
suggested
to
iterate
through
all
of
the
dependencies
which
are
present
in
the
depths,
and
if
it
is
not
a
standard
dependency
which
we
would
get
from
our
map.
A
That
would
say
it's
false,
then
create
the
gomad
graph
output,
which
would
say
that
this
module
goes
to
its
test,
depends
on
that
and
then,
basically
repeat
the
whole
process.
A
A
This
is
the
main
module
for
our
project
which,
like
the
project,
go
modules
test,
and
it
only
has
two
main
dependencies
which
are
supposed
to
be
julian
smith,
http,
router
and
zap.
A
But
if
you
follow
what
like
jordan
suggested
and
go
through
this
list,
you
will
see
that
in
its
dependencies
list
is
also
this
package
called
atomic,
and
this
is
not
a
standard
package.
So
if
we
just
iterate
through
it
and
see
that
if
it's
not
a
standard
package
and
make
the
link,
then
we
would
also
be
making
the
link
that
the
main
module
depends
on
this,
and
this
becomes
a
direct
dependency,
whereas
it
is
not.
So
basically,
we
are
stuck
with
like
his
goal
is
json
the
right
choice
here.
B
B
Yeah,
and
is
there
anything
here
like
true,
remember
you
there
is
an
indirect
true
there,
indirect
true
line,
9505.
B
B
Anyway,
the
the
point
is
to
figure
out
a
way
to
replicate
exactly
the
output
we
used
to
get
from
gomond
graph
right
and,
if
pretty
sure,
that
all
the
information
you
need
should
be
here,
that's
basically
what
jordan
was
hinting
at
like
don't
go
away
exactly.
B
That
all
the
information
is
there
figure
it
out
from
the
information
in
the
json
cool
got
it.
If
there
is
more
information
in
the
json
that
we
don't
need,
it's
fine.
If
the
information
that
we
need
is
not
there,
then
it's
a
problem
right.
B
A
All
right,
yeah,
that
makes
sense
I'll,
take
another
look
at
this
all
right.
The
next
thing
on
the
agenda
is
about
it's
a
long-standing
issue
and
it
is
about
moving
components
out
of
kk,
and
this
is
a
presentation
which
lubermate
did
when
he
was
working
on
it.
So
right
now,
if
you
know
that,
like
cube,
ctl
cube
adm
code
generator,
all
of
them
are
present
in
kk,
but
a
lot
of
them
like
can
be
removed
out
and
probably
like,
should
be
removed
out
to
break
the
monoliths.
A
So
we
were
working
on
a
cap
for
that,
and
then
we
had
some
conversations
and
we
are
basically
looking
that
is
this
like?
What's
what
path
should
we
take
here,
because
there
are
a
lot
of
stakeholders
there's
like
six
cli,
so
we
were
targeting
like
cube,
ctl
first
and
so
six
cli
folks
have
views
on
that.
Sig
release
folks
have
views
on
that,
and
the
idea
is
basically
is
kept.
The
best
way
to
approach
this,
or
is
a
working
group,
a
more
better
solution.
B
Yeah,
I
think,
even
if
you
do
a
working
group,
you
will
end
up
writing
a
cap,
so
there
is
no
just
no
way
out
of
it
and
from
all
the
it's
we
all
the
discussions
we've
had
before.
Nothing
has
changed
like
there
is
no
additional
information
or
there
is
no
additional
quark
that
we
know
of
that.
We
will
end
up
discovering
going
down
the
word
group
route
right.
That's
my
feeling.
B
You
know
I
may
be
wrong,
and-
and
the
point
here
is
not
just
from
the
viewpoint
of
like
kubernetes
from
q,
what
do
we
put
in
the
kubernetes
release
from
outside?
But
it's
more
of
like
how
do
we
stand
up
standalone
communities
that
can
take
care
of
these
components?
Right,
like
cube,
ctl
6cli
will
take
care
of
it
like
cubadium
cichlids
cluster
life
cycle
already
has
too
many
things
right
it
and
I
have
feeling
that
qberium
needs
like
a
separate
set
of
people
that
are
this
not
just
lubomir
right.
B
We
need
people
who
can
help
loop
aware
to
like
own
it
and
run
it
and
do
all
the
things
that
that
are
needed
like
similar
to
what
you're
trying
to
do
with
deb
start
right,
like
you're
trying
to
get
more
people
interested
in
in-depth
stat,
and
you
know,
you're
owning.
There
is
a
group
of
people
that
are
interested
in
trying
to
do
stuff
right
so
similar
to
that
we
need
for
qbm.
I
think
I
I
I
really
don't
know
what
the
problem
is
anymore,
because
I
don't
see
a
problem
here.
B
We've
done
this
so
many
times
before
for
other
projects
we
use
hcd
from
outside,
we
use
run
cn
open
container,
open
container
currency
container
d,
like
we've,
there's
hundreds
of
components
that
we
do
this
way.
I
just
don't
know
what
what
our
problem
is
anymore.
C
Also
started
questioning
myself
like
what
are
we
trying
to
solve
with
the
whole
split
of
the
ball
on
it
and
what
was
the
original
purpose
of
staging?
Even
I,
I
guess
I
know
what
staging
is
doing.
It's
allowing
to
split
the
repositories,
but
the
control
still
remains
in
kkk
in
terms
of
what
is
pushed
into
these
repositories
in
the
case
of
cubecaro,
they
want
to
decouple
from
the
release
cycle.
I
think.
B
I'm
really
glad
that
that
is
the
motivating
factor,
and
you
know
it's
a
good
thing.
C
Yes,
but
it
creates
a
lot
of
complexities
and
I
think
we
are
pushing
a
button
without
I
mean
they're
pushing
a
button
without
asking,
for
instance,
surveying
the
users
like
what
is
going
to
be
the
level
of
disruption.
If
we
change
the
versioning
between
kubecoil
and
cuba,
we're
not
asking
anyone
about
that.
C
Instance
we,
I
guess
we
did
some
surveys
when
we
did
work
in
group
lts.
We
had
surveys
asking
people
like
how
do
you
feel
about
lts?
We
gathered
information
from
other
surveys,
but
we
we
had
something
as
a
data
point
to
create
a
kip.
B
I
I
I
got
you
there
here
is
the
thing
right
like
if
there
is
a
version
of
cube,
cube
ctrl
that
is
shipped
at
the
same
time
as
kk.
B
They
can
have
other
releases
later
or
you
know,
depending
on,
if
they're,
finding
a
bug
like
if
you
can
coordinate
a
release
at
that
certain
point
or
if
we
do
a
vendor
directory
and
the
kubernetes
release.
You
know
ships
a
binary
of
cube
ctl
along
with
our
artifacts,
then
all
those
we
don't
have
to
go
around
asking
people
for
things
that
they
don't
even
know
what
they
are
they'll
end
up.
B
B
And
if
people
have
some
problems
and
they
need
another
release
and
they
they
can
pick
off
a
release
from
the
cube
ctl
repository.
B
You
know.
That
is
the
way
I
was
thinking
about
it,
but
you
know
somebody
needs
to
drive
this
and
that
somebody
not
me
needs
to
drive
this,
and
if
6cli
is
driving
this
I'm
like
kudos
to
them
and
you
we
can
give
them
the
feedback
that
do
some
surveys
or
whatever
right,
but
I'm
not
going
to
stop
them.
I
like,
I
really
want
this
to
happen
and
it's
it's
high
time
and
we
can't
be
dragging
our
feet
forever.
C
A
C
C
Exactly
but
but
given
this
is
a
seeker
architecture
forum,
do
we
want
to
write
some
sort
of
a
policy
or
should
sig
release
all
that?
Should
it
be
a
consistent,
basically
pattern
for
all
the
components
that
extract
or
should
be,
every
sikh
is
going
to
do
whatever
they
want,
and
we
just
prep
this
kubernetes
distribution
in
the
end
of
the
day.
B
Though
the
way
I
was
thinking
about
it,
labor
matters,
we
should
we
don't
know
what
are
the,
what
are
the
kind
of
side
effects
and
what
not
right.
So
we
roll
the
dice
with
cube
ctrl.
Whatever
we
learn,
then
we
make
the
policy
there's
like.
If
we
don't
it's
hard
to
think
that
far
ahead
to
do
a
policy
now
and
we
should
iterate
all
right
like
I
don't
want
to
bake
in
a
policy
right
now
I
want
to.
B
I
want
the
6
ccli
to
experiment,
let's
learn
from
their
experiment
and
then
use
that
to
create
the
policy,
because
the
policy
should
reflect
things
that
can
be
done
and
things
that
should
not
be
done.
So
that
is
how
I
would
take
it,
but
I
would
encourage
you
to
drop
an
email
to
see
architecture
mailing
list
saying
that
you
know
what
you
just
mentioned.
C
Hopefully,
if
we
do
that,
I'm
hoping
that
six
cli
will
view
some
of
the
potential
problems
that
will
happen
because
of
this
virtual
separation
ahead
of
time.
C
A
A
lack
of
communication
is
why
the
previous
initiatives
died
because,
like
they
were
talking
about
how
to
work
with
the
releases
and
then
sig
release,
and
there
was
a
lack
of
communication
between
cli
release
and
similarly
with
cuba,
and
that
is
why
the
whole
thing
was
closed.
So
this
is
what
we
were
trying
to
solve
is
basically
if
we
could
come
up
with
a
cap
by
talking
to
everyone
and
getting
like
everyone's
concrete
opinion.
So
maybe
that
could
drive
the
effort.
B
A
So
just
to
confirm
the
cap
would
be
about
the
actual
extraction
right,
because
initially
we
were
planning
just
a
cap
about
the
policy.
But
you
know.
C
B
B
A
A
The
problems
they
are
facing
is
like
they
do
not
understand
the
release
parts
about
like
the
krell
and
everything,
and
that
is
where
I
think
said
that,
like
he
could
come
into
picture
and
help,
so
they
are
like
they
do
not
understand
like
how
the
releasing
would
work
and
cycles
and
artifacts.
So
that
is
where
it
gets
just
blocked.
But
I
think
I
get
your
point
like
talking
to
cla
folks
and
coming
up
with
the
kept
with
them.
B
Yeah,
and-
and
the
other
problem
here
is
also
is
like-
I
don't
know,
I'm
just
frustrated
with
this
whole
thing,
because
I
I
have
a
feeling
that
sig
release
is
not
helping,
you
know,
and
it's
it's
not
empowering
six
cli
to
make
a
dis
make
a
set
of
decisions
that
will
work
for
them.
So
there
is
one
set
of
frustrations
around
that
between
I
mean
six
sig
release
should
be
helping
drive
this
discussion
and
they
are
being
reactive
rather
than
proactive,
and
I
don't
like
it
right.
That
is
one
thing.
B
And
the
cli
that
owns
these
implications
of
version
skew
and
whatnot
right.
So
they
are
the
first
line
of
defense
right.
They
know
what
they
are
doing
and,
yes,
we
can
all
help
them
tweak
the
things
that
they
would
like
to
do,
but
we
shouldn't
be
driving
it
because
we
don't
know
all
the
things
like,
for
example,
even
the
anyway.
B
Let's
let
me
not
go
back
that
far,
so
I
I
would
say
the
cli
has
a
pen
whether
they
know
it
or
not,
and
six
cli
is
a
sick
release
has
to
help
whether
they
want
to
or
not.
At
this
point.
C
C
Something
else
I
think,
is
that
you,
you
would
probably
remember
the
cap
I
did
for
cuba
dm.
It
unfortunately
ended
up
as
a
as
a
bike
forum
with
200
plus
comments,
and
we
didn't
do
anything
because
I
think
one
of
the
reasons
for
that
was
that
we
didn't
talk
ahead
of
time
and
the
way
the
way
we
are
doing
with
the
approach
of
six
cli
producing
a
cap.
C
B
B
Yes,
yes,
there
has
to
be
a
kept
for
how
cube
ctl
will
look
in
the
future
and
what
are
the
phases
to
get
there
similar
to
doc?
Cushion
right
like
we
said,
122
121
we'll
do
this
122
we'll
do
this
123
we'll
do
this
124
we'll
do
this
125
it's
gone
right,
so
I
I
want
a
similar
set
of
phases
to
get
to
the
point
where,
like
okay,
four
four
releases
down,
the
line
is
exactly
when
we'll
be
able
to
do
this
and
what
the
users
can
expect
at
that
point
in
time.
C
Yeah,
we
have
to
announce
it
ahead
of
time.
It's
going
to
be.
C
I
guess
a
quick
comment
about
staging
like
we
couldn't
the
core
process.
Is
we
have
these
repositories,
but
do
you
see
them
completely
decoupling
in
a
similar
similar
way
in
the
future.
B
Yeah,
the
cra
api
is
the
next
one
I'm
shooting
for
because
there
is
a
need
for
c
advisor
to
call
yeah
kubernetes.
You
know
cubelet
and
and
whatnot
so
yeah.
B
C
B
B
The
releases
for
cuba
dm
like
run
it
as
a
separate
thing,
which
is
useful
in
its
own,
like
including
the
things
that
you've
been
talking
about,
like
using
cubadium
as
a
library
and
whatnot
right,
so
that
that
angle
should
probably
drive
the
need
for
cubanium
being
a
separate
project
rather
than
oh.
We
need
to
kick
a
code
out
of
kk
right
like
so.
C
Either
said,
I
said
what
you
mean,
of
course,
the
palette.
The
number
of
colors
from
the
palette
is
what
there's
so
many
different
flavors.
So
many
different
aspects
of
what's
going
to
happen
to
that
yeah,
I
think
if
you
look
at
projects
like
cops
or
cubespray
other
deployers,
you
know
they
try
to
decouple
the
release
cycles
from
that
of
kk,
but
eventually
they
end
up
normalizing
towards
the
same
cadence,
which
is
and.
B
B
Just
getting
anybody
to
be
useful
and
valuable
in
maine
kkk
is
a
losing
losing
proposition
right.
We
can't
do
good
first
issues
they
get
snapped
up
and
like
it's,
it's
a
nightmare
trying
to
do
get
anybody
started
in
maine
kk.
So
if
we
have
a
smaller
area
where
okay,
there
is
a
set
of
ci
jobs
around
this,
there
is
you
know
it
has
its
own
life
outside
of
kkk.
It
can
have
its
own
set
of
things
right,
like
a
community
around
it,
that
that's
what
I'm
looking
for
at
this
point,
blue
bomber.
C
I
can
definitely
see
that
the
greater
aspect
of
the
level
of
noise
that
kk
has
right,
but
you
know,
even
if
we
move
cube
adm
completely.
There's
also
the
aspect
that
finding
contributors
without
stuffing
who
are
on
a
salary
is
slightly
difficult
in
coordination.
B
Understood
yeah:
we
are
getting
better
at
this
a
little
bit
like
getting
some
students.
That
kind
of
we
are
having
some.
B
We
allow
to
establish
some
kind
of
mentorship
program
to
be
able
to
do
that
for
sure
yeah
and
it's
a
chicken
and
egg
problem
right,
like
people
won't
show
up,
because
it's
still
not
like
a
separate
thing
and
then
so
we
have
that
issue
too,
and
if
staffing
is
the
limitation,
then
we
need
to
raise
that
up
the
chain
like,
for
example,
when
we
were
doing
the
annual
report
kind
of
thing
right.
So
we
should
have
like
added
that
as
a
thing
like.
Okay,
we
need
more.
Did
we
already
do
that?
B
B
B
C
Yeah
right,
yes,
I
I
see,
I
see
the
benefits
there
are
also
more
downsides.
For
instance,
currently
signal
network,
for
instance,
is
patching,
cube
adm
for
us
with
the
removal
of
the
door
stack
feature
gate.
We
get
a
free
change
from
someone,
because
cuba
dm
is
pipe
of
a
part
of
the
pipeline
of
tests
and
part
of
the
source
code,
and
somebody
else
has
to
do
it.
Otherwise,
we
have
potential
for
these
drifts
in
the
coupling
which
will
because,
if
we
have
something
in
a
separate
repo,
but
that's
a
side
effect.
B
Yeah
and
it's
definitely
something
that
you
have
to
lead
like:
if
you
want
to
do
it,
then
we
can
like
figure
out
how
to
do
it,
and
you
know
you
will
have
to
end
up
taking
the
lead
on
it.
C
Yeah,
it's
a
communication
has
to
be
enhanced
if
we
separate
right
it's
going
to.
I
I
at
this
point,
like
I
told
you
the
beginning,
I
told
you
at
the
beginning.
I'm
fine
either
way
staining
kk
moving
out
of
kk.
Who
is
right
in
the
caps?
I
I
don't
have
strong
opinions
at
this
point.
It's
a
lot
of
time
passed
yeah,
but
if
that's
that's
the
way
you
see
it
yeah
I
mean
that's
the
way
we're
going
to
go.
B
Let's
talk
to
like
vince
and
some
other
folks
in
cluster
life
cycle
too,
to
see
if
they
have
any
opinions
on
it
and
see.
C
Yes,
the
question
api
folks
have
been
mostly
silent,
but
we
can
bring
him
into
the
discussion.
Hey.
We
have
this
release
meeting.
Please
join
if
you're
interested.
A
B
Don't
waste
time
doing
anything
more
because
then
it's
just
like
you
know
just
like
the
cap,
he
was
talking
about
where
there
was
all
bike
shedding
200
comments.
Nobody
wants
to
do
anything,
nobody
wants
to
help,
but
they
have
to
put
in
their
2
cents
right
so
and
that's
becoming
worse
over
time.
So
do
what
you
can
and
we
can
talk
again.