►
From YouTube: sig-testing weekly for 20230207
Description
sig-testing weekly for 20230207
A
Okay,
I
think
they
can
at
least
get
some
intros
from
folks,
and
if
we
have
nothing
else
to
discuss,
that's
fine,
we
can
break
early,
but
yeah,
usually
hey
anybody
who's
new
to
this
meeting.
If
you
want,
feel
free
to
raise
your
hand
and
unmute
and
just
give
a
brief
introduction
to
yourself
and
what
you're
interested
in
remind
me,
we
can
always
follow
up
through,
like
the
Sig
testing,
Channel
and
whatnot
for
more
specifics,
but
yeah
go
ahead.
B
B
A
A
A
C
Oh
yeah
I
had
opened
the
issue
I
think
in
two
weeks
ago,
and
it
was
for
political
issue,
it's
not
a
biggie
and
it's
for
a
response
of
pro
at
the
response
of
CI
but
actually
and
it's
kind
of
annoying
I.
Think
because
when
we
are
deleting
things
it's
going
to
like
not
do
you
think
the
CI
response
so
I
just
wanted
to
know
the
people
you
know
response
about
it.
Is
it's
useful
because
I
think
no
one
accept
me.
A
A
A
All
right,
hey
folks,
yeah,
reminder
again
link
here
for
the
notes,
and
currently
we
do
not
have
anything
else
on
the
agenda.
So
if
anybody
else
has
things
that
they
want
to
add,
please
feel
free,
otherwise,
I
will
call
it
good
and
leave
you
all
the
rest
of
the
morning
or
whatever
time
it
is
in
your
time
zone.
D
I
had
a
sort
of
a
broad
question
that
I
can
add
to
the
agenda.
If
you
like
feel
free,
do
you
have
a
sort
of
a
hand?
Wavy
sense
of
Sig
testing
was
only
my
second
meeting
so
I'm.
Basically
there,
how
does
Sig
testing's
involvement
tend
to
interact
with
the
larger
kubernetes
release
cycle?
That
is,
you
know,
does
work
ramp
up
in
response
to
what
other
things
are
doing.
E
E
A
Yeah
I,
my
position
is
a
little
bit
weird
because,
as
mentioned
like
I,
do
work
on
test
grid,
largely
which
means
that
a
lot
of
my
stuff
is
more
study
work,
but
I
I
think
that
matches
what
I've
observed
at
least
like
there
might
be
some
ramp
up
a
ramp
down,
but
I
think
it
might
be
I.
Think
testing
tends
to
be
a
little
bit
more
steady,
especially
with
like
the
major
tooling,
like
test
grader
prowl.
E
I
I
thought
of
another
useful
example.
If
a
release
is
coming
and
there
are
tests
that
are
broken
and
are
blocking
a
release,
obviously
action
is
needed,
but
frequently
that
those
breakages
would
be
due
to
a
new
feature
or
some
kind
of
a
change,
and
then
the
owner
of
the
change
would
come
in
and
fix
the
test.
F
Just
to
so
just
to
complete
what
brands
say:
testing
is
not
responsible
for
maintaining
the
project.
I
think
that's
the
one
thing
I
think
the
to
quickly
answer
to
you.
You
should
check
the
charter
of
the
sake
and
that's
going
to
define
the
mission
and
the
overall,
basically
responsibility
of
seed
testing,
so
in
my
basically
with
my
Act
of
of
seed
testing
membership,
I
I
would
say
that
six
testing
responsible
to
maintain
and
improve
the
test
infrastructure,
basically,
which
is
all
those
components
around.
That's
the
main
responsibility
and
we
provide
help
on
other
C.
F
Basically,
in
order
to
up
then
consume
a
community
CI
system,
that's
the
main
responsibility
right
now.
So
in
some
case,
when
there's
an
issue
affecting
the
CIA,
we
have
to
basically
investigate
solve
the
problem.
I
think
that's
what
Ben
did
last
week.
Basically,
it
was
like
if
you're
impacting
the
entire
system,
it
came
up
inside
to
fix
and
that's
the
one
thing
we
we
do
and
that's
because
the
chat
or
defined
role
of
responsibility
of
the
thing
and
based
on
that
we
Define
the
relationship
between
the
sick,
the
differences
so
most
of
it
I.
G
So
I
think
one
thing
that
I
don't
see
in
the
notes
so
far
is
there's.
Also
the
there's
a
test
freeze,
step
in
the
release
life
cycle
Sig
for
the
E
to
e
test.
We
have
a
number
of
people
in
sick
testing
that
own
the
the
like
entirety
of
the
e2e
test.
So
stick
testing
tends
to
be
pretty
involved
with
helping
get
the
last
bit
last
push
of
tests
through
so
the
during
the
release
life
cycle.
There's
a
Code
freeze
for
General
code.
G
Earlier,
after
which
point
it
should
only
be
bug
fixes,
but
there's
a
slightly
extended
window
for
continuing
to
get
tests
in
for
new
code
or
other
test
fixes.
So
there's
a
week
or
two
there,
where
Sig
testing
kits
pretty
busy
with
release
cycle,
helping
get
various
e2e
test
related
things,
in
particular,
as
opposed
to
like
unit
tests
which
are
going
to
be
scoped
to
some
package
owned
by
the
Sig
that
owns
the
code
under
test.
G
There's
also
a
pretty
big
trunk
crunch
on
the
like
Ci
infrastructure,
at
points
in
the
release
cycle
like
when
code
freeze
is
lifted
or
when
we're
going
into
code
freeze,
then
people
have
a
huge
block
of
PRS
trying
to
get
through,
so
there's
usually
some
keeping
an
eye
on
that
infrastructure.
It's
been
a
lot
smoother
in
the
past
couple
years,
but
in
the
past
it
was
a
lot
more
Hands-On
to
keep
those
things
moving.
G
G
And
also,
of
course,
the
the
whole
release
cycle
depends
heavily
just
on
the
CI
infrastructure.
Kubernetes
only
Cuts
released
on
green
of
the
release,
blocking
test
dashboard
and
there's
also
an
informing
dashboard,
which
is
things
that
aren't
quite
blocking
yet
but
are
worth
looking
at
and
there's
a
lot
of
like
General,
not
owned
by
any
particular
Sig
test
related
things
that
tend
to
come
back
to
us,
including
even
to
an
extent
the
like
test
clusters.
E
That
was
obviously
a
task
he
took
on
himself
and
it
was
quite
large
and
when
he
pushed
it
and
it
broke
so
there
was
a
lot
of
interactions
to
fix
that
it
was
a
surprisingly
large
break
and
I.
Think
Ben
was
in
there
trying
to
patch
it
up
to
anyway.
I
just
wanted
to
give
you
that
example
of
how
this
is
there's
always
something
going
on,
especially
when
you
got
something
running
the
show
who
wants
to
improve
things.
G
One
right
yeah
we've
had
we
had
that
one
we
had
another
one
Docker,
we
just
a
regular
upgrade
of
the
CI
images
which,
like
most
people,
just
tend
to
use
the
images
that
we
build
and
provide.
They
also
Implement
some
things,
not
necessarily
the
best
need
to
get
back
to
the
runner
that
does
like
Docker
and
Docker.
Some
things
like
that,
the
we
we
had
numerous
Pro
numerous
projects
use,
build
X
for
building
and
the
build
X
plugin
was
no
longer
included
in
the
standard.
G
Docker
C
install
it's
a
separate
package
that
you
explicitly
need
to
request
to
install
and
that
just
kind
of
slipped
through,
and
then
only
that
thread.
We
found
other
things
that
someone
yaml
coding
issues,
not
quoting
a
string
in
it
being
1.20
becoming
1.2,
go
instead
of
1.20
go,
there's,
there's
a
somewhat
Rube
Goldberg
bit
of
infrastructure.
For
all
of
that,
how
do
we
keep
all
this
test
glue
running
it's
it's
hard
to
staff,
especially
now,
because
it's
kind
of
just
a
cost
center.