►
From YouTube: Argo Contributors Office Hours Feb 23rd 2023
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).
C
Morning,
everyone
I
think
we
can
go
ahead
and
get
started
all
right.
So
welcome
back
to
the
contributor
office
hours
meeting
I'm
your
host
for
today.
So
let's
get
started
as
usual.
We
have
the
discussion
moderators
for
this
week,
so
first
Leo
and
Justin
did
you
want
to
take
it
away
with
looks
like
a
couple
issues
you
listed
here.
E
Not
on
Leo
won't
be
able
to
join,
but
I
think
the
main
thing
he
wanted
to
talk
about
was
issue
one
two:
five,
eight,
nine
okay.
So
someone
commented
on
a
pull
request,
saying
that
they
had
had
an
incident
because
we
changed
the
a
Proto
buff
spec
to
to
change
the
name
of
a
field
from
Project
to
projects.
E
E
So
I
don't
know
if
it
was
a
CI
process
or
they
were
just
sitting
at
their
CLI,
but
they
deleted
some
applications
expecting
the
project
filter
to
apply
it,
but
since
they
were
using
an
old
version
of
the
CLI
with
the
old
protobuf,
the
field
was
never
used
to
filter
the
application
so
deleted
all
their
applications,
not
great
so
Leo
opened
this
issue,
which
is
basically
find
some
way
to
make
sure
that,
like
breaking
API
changes
don't
slip
through
the
cracks.
E
Okay,
I'm,
not
sure
the
best
way
to
do
that,
but
we
should
think
about
it.
The
other
thing
that
we
should
consider
I
think
is
like
re-adding,
the
singular
form
as
an
additional
field,
so
that
the
API
continues
to
be
backwards
compatible,
and
we
just
you
know,
pick
whichever
one
is
actually
populated.
C
Yeah
I'm
on
board
for
for
re-adding
the
the
projects
or
sorry,
the
project
field
that
yeah
I,
think
that
makes
the
most
sense,
yeah
and
I'm
in
agreement
with
an
API
contract
test,
as
as
a
concept
yeah
I,
don't
have
any
ideas
at
the
moment.
The
best
way
to
do
that,
but
yeah
any
open
to
the
floor.
If
anybody
has
suggestions.
F
Just
about
this
specific
issue,
so
first
I
had
one
major
I'm,
more
cat,
I'm
working
at
I'm
working
at
and
we
had
this
issue.
That's
why
the
so
much
for
my
team
contacted
Hong
Kong
on
the
dinner
and
indeed
we
are
ready
to
Taco
City,
but
we
had
a
script
that
that
was
listing
applications
for
a
specific
project
to
delete
it
to
delete
all
the
applications
belonging
to
a
project
and
the
field
was
changed
to
projects.
F
So,
instead
of
listening
only
the
project,
the
application
for
the
given
project,
it
returns
everything
and
we
deleted
66
000
applications,
which
was
a
kind
of
bad.
But
it's
okay.
Now
it's
we
fixed
the
solution
outside,
but
we
indeed
miss
it
when
we
read
the
change
log
and
also
on
the
agrocity
applied
procedures,
but
so
indeed,
but
it
was
visible
in
the
in
the
mesh
request,
because
we
found
the
the
commits
which
introduced
the
issue
and
it's
visible
on
the
serger
spec
update.
F
C
So
actually
I
have
a
question
from
Michael
is:
was
this
not
expected
so
like
it
was
changed
and
it
wasn't
documented,
and
that
was
the
problem
and
that's
why
we
need
this
test
or
I
guess
when
this
API,
when
this
breaking
API
change
got
made,
was
it
not
thought
that
it
might
be
breaking,
and
that
was
why
we
need
a
test
to
detect
if
it's
going
to
be
a
breaking
change
or
yeah,
go
ahead.
E
Yeah,
so
at
the
time
that
it
was
merged,
I,
think
Leo
and
the
reviewers
saw
a
like
there's
a
tag
on
that
field.
That
sets
a
custom
name
and
the
custom
name
said
project.
E
So
just
hit
a
quick
glance.
The
expectation
was
oh
well.
Projects
is
the
same
as
projects,
because
we
set
a
custom
name,
but
in
reality,
like
protobuf
itself,
pays
no
respect
to
that
tag.
Custom
name
it
only
once
or
it
only
uses
the
field
name,
so
it
just
kind
of
slipped.
By
afterwards
we
noticed
places
where,
like
our
UI
code,
expected
the
old
project
instead
of
projects
field
and
we
went
through
and
updated
all
those,
but
as
we
did
that
it
just
never
occurred
to
anyone
that
this
would
break
backwards.
F
F
You
know
we
expect
that
the
old
script
will
continue
to
work
to
skip
writing
for
the
previous
release.
C
Right,
yeah,
okay,
yeah
I
mean,
like
I,
said
I'm
in
agreement
that
this
is
something
we
should
do
instead
of
a
priority
label,
not
really
okay,
but
yeah.
I
think
Michael,
like
you
said,
will
probably
need
to
think
about
the
best
way
to
do
this,
probably
the
offline.
C
Okay,
Michael:
is
it
okay?
If
we
move
on.
E
C
Great
thanks,
thanks
for
bringing
that
up
until
Leo.
Thank
you
as
well.
Okay
and
then
Justin
are
you
here
yet
or
I.
C
It
okay
great
did:
you
have
I,
see
your
we're
secondary
for
this
week.
Did
you
have
any
issues
that
popped
up.
G
C
Okay,
yeah,
no
problem
great
thanks
all
right.
So
let's
pick
the
primary
for
this
week,
then
first
we
have
any
volunteers.
C
No
okay,
in
that
case,
I.
C
And
do
it
for
this
week
all
right,
so
moving
on
to
the
next
item
on
the
agenda
looks
like
Nate
Nate.
Are
you
here
you
had
a
topic
for
supporting
multiple
aob
Ingress.
H
Hi
there
yeah
hey
nice,
to
meet
everyone
thanks
for
your
time
today,
yeah
I
can
give
a
quick
summary.
That's
okay!
Basically,
it's
supporting
multiple
Ingress
objects
based
on
albs.
Recently,
we've.
I
H
H
The
POC
patch
on
the
engine,
X
patch
by
T,
Perdue
there
and
I
I-
realize
you
guys
are
we're
working
on
that
PR
in
the
past
couple
months,
or
so
so,
yeah
I
I'd,
like
any
thoughts
on
that
internally.
This
was
kind
of
a
deal
breaker
for
us,
because
the
workarounds
were
kind
of
clunky.
H
A
H
We've
had
this
running
for
about
four
to
five
months
now
in
about
half
a
dozen
apps,
so
yeah
I
was
wondering
if
it
was
appropriate
to
submit
a
PR
with
the
POC
code
at
this
time
or
or
if
we
should
wait
or
what
we
could
do
next.
J
J
I
think
the
exact's
on
here
right
but
looks
like
Zach,
is
on
board
with
this
since
he's
targeting
it
to
the
next
Milestone
and
then
managing
the
issue.
So
it
seems
appropriate
that
you
can
send
the
pull
request
for
this
and
it
should
be
accepted.
It
looks
like
I
even
commented
on
the
other
issue.
Okay
thing
that
makes
sense.
H
Appreciate
that
yeah
I'll
get
that
in
this
week.
Thank
you.
C
Thanks
for
thanks
for
that,
Nate,
okay,
we're
moving
on
to
next
agenda
topic,
Zach
I
think
somebody
said
Zach's
not
here,
but
did
you
did?
Somebody
else
want
to
talk
about
the
CLA
for
Argo
approach,
Labs.
E
I
think
I
know
what
the
issue
is:
there's
some
defaults
in
Argo
proj
labs
for
how
new
repos
are
set
up
and
I
think
they're
all
set
up
to
require
a
CLA
instead
of
dco
but
like
as
far
as
I
know,
all
the
other
main
repos
just
require
dco.
So
I
don't
know
who
can
make
that
change,
but
it
seems
like
we
should.
C
J
J
J
Yeah
I
can
do
that.
C
Cool
all
right
thanks
Jesse.
So
next
topic
is
from
Michael
logs
viewer
improvements.
I
know,
Alex
Collins
has
I
can't
remember
if
it's
an
enhancement
proposal
or
a
PR
of
it,
but
is
that
what
this
is
about?
People
yeah.
E
E
Okay,
so
on
the
left
is
I'm.
Sorry,
this
is
kind
of
small,
but
hopefully
you'll
get
the
sense.
The
left
is
the
current
state
and
some
of
the
issues
I've
encountered.
Are
it's
just
a
lot
of
buttons,
particularly
in
this
row
here
with
the
pagination
up
down,
left
right
I
to
this
moment,
I'm,
not
sure
what
the
left
and
right
and
the
double
right
buttons
do.
E
E
E
I
think
this
is
new
Alex
added
this
thing
to
show
the
Pod
names
looks
a
little
bit
broken,
but
ideally
you
would
just
see
this
I
think
everything
else
Remains
the
Same.
It's
just
got
sort
of
the
copy
download
pop
out
buttons
off
to
the
right
now.
E
It
did
replace
the
check
boxes
with
a
more
sort
of
loud,
yellow
active
state,
which
I
think
is
fine,
like
these
check
boxes
are
kind
of
a
non-standard
way
to
do
things.
Inside
of
these
pills,
yeah
I
think
there's
still
work
to
do,
but
I
think
this
is
enough
of
an
improvement
that
if
there
aren't
strong
objections,
I'd
like
to
clean
up
these
last
few
bugs
in
it
and
get
it
merged.
C
Yeah,
so
I
have
a
few
a
few
thoughts
on
this.
So,
like
you
said,
I
think
that
there's
a
few
bugs
and
just
polish
issues
which
I
would
I'd
be
okay
with
taking
a
look
and
maybe
taking
care
of
some
of
them
like
it's
a
little
bit
unclear
with
the
way
that
it's
laid
out
like
some
of
the
filters
and
the
text
field.
Just
looks
a
little
bit
too
close
to
me
and
it's
kind
of
confusing.
C
C
The
infinite
scrolling
is
ideal,
but
yeah
I
think
I
think
you're
right
that
this
overall
is
an
improvement,
but
I
think
it's
still
not
ideal
and
I
would
actually
love
to
get
potentially
a
designer
to
take
a
look
at
this
and
come
up
with
some
suggestions,
because
yeah
I
I
think
it's
improving
on
the
current
state.
But
it
still
has
a
lot
of
issues
from
the
current
state.
So
yeah
I
agree.
If
we
can
get
some
of
that
polished,
it
would
be
good
to
merge
but
yeah.
E
E
C
I,
don't
think
we
should
block
on
getting
a
designer
to
take
a
look
at
it.
I
think
we
can
as
long
as
we
get
the
bugs
removed
and
I
mean,
like
I,
like
I,
said
I
I'm
willing
to
take
a
look
at
it
and
try
to
polish
some
of
the
clunkiness,
like
the
like
I
said,
the
Overflow
and
the
layout.
So
I'll
take
a
look
at
that
and
just
you
know
kind
of
do
the
best
that
I
can
but
I
think
we
can
get
it
merged.
C
Based
on
that
and
then,
as
a
next
step,
to
improve
the
long
viewer
overall,
I
think
we'll
talk
to
a
designer.
So.
J
Can
you
do
you
know,
follow
mode
and
see
once
show
me
one
so.
C
J
Back
sorry,
go
back
to
the
Frozen
mode,
so
actually,
when
experience
that
seems
worse
than
before,
it
was
just
going.
Let's
say:
I
I
just
missed
the
log
line
that
I
needed
to
see,
whereas
the
other
experience
you
could
actually
page
left
or
to
see
like
the
line.
I,
don't
know
how
to
query
with
using
the
new
controls
to
see
like
okay
I
want
to
see
the
line
like
right.
The
one
I
just
missed.
B
E
To
me,
that's
bump
into
a
thousand
logs
surge
for
a
term.
Indeed,
in
the
line
that
you
missed.
The
my
problem
with
pagination
is
I.
Don't
know
like
logs
are
a
they're
they're
constantly
moving,
so
if
I
page
back
am
I
going
to
be
seeing
the
page
before
or
am
I
going
to
be
seeing
the
page
before,
as
now
evaluated
with
new
log
lines,
having
been
added.
E
It's
not
with
confidence,
I
think
that
it
does
if
I
click
back.
My
expectation
is
I'll,
probably
see
the
previous
line
that
I'm
trying
to
see
but
I'm,
not
confident
that,
like
new
logs,
haven't
moved
my
line.
J
In
the
other
way,
it
doesn't
have
weight,
I
see,
I
mean
at
the
end
of
the
day.
This
is
just
using
the
kubernetes
API
for
the
logs,
which
also
is
limited
in
that
regard.
J
C
C
I
can't
remember
if,
when
you
click
the
back
button,
if
it
recalls
the
API,
because
if
it
does
then
Michael's
concerned
that,
like
you
write
Michael,
your
log
line
could
move
and
then
you
wouldn't
be
able
to
see
it,
but
I
don't
think
that
it
Greek
various
API
on
clicking
the
back
buttons,
in
which
case
nothing
would
move.
It
would
just
for
me
the
same,
but
yeah
I
would
have
to
look
to
confirm.
J
That
would
just
be
my
concern
if
we
are
breaking
that
experience
or
it's
like
someone
who
is
used
to
going
looking
at
the
logs
and
then
say:
okay,
my
line
is
not
there,
I
go
back
another
page
and
go
back
another
page.
J
That's
experience
is
a
little
bit
a
lot
different
in
this
new
one.
They
have
to
search
for
things,
I
guess.
E
J
E
E
C
I
so
I
had
a
PR
open
and
I
thought
it
got
merged.
Maybe
it's
just
because
this
is
running
2.6.1,
that
added
labels
to
these
buttons,
and
it
says
you
know
it
says
what
they
do
so
I
think
the
one
on
the
left
is
just
the
back
button.
Then
the
one
the
down
arrow
on
the
left
is
to
go
to
the
bottom.
Then
the
up
arrows
would
go
to
the
top,
then
on
the
right.
C
The
the
far
right
with
the
double
arrows
is
to
go
to
the
the
most
recent
page
and
then
the
one
right
arrow
is
just
to
go
to
the
next
page,
but
yeah
I,
I,
think
I
merged
people
to
add
labels
to
these,
but
maybe
I
misremembering
but
yeah
I
agree.
Another
thought
about
the
new
log
viewer
that
I'm,
not
a
huge
fan
of,
is
having
a
tooltip
describing
that
you
should
add
an
exclamation
point
to
your
text
field.
If
you
want
to
negate
it.
I
feel
like
that.
C
That's
just
a
little
bit
more
confusing,
like
I,
think
that
the
button
is
just
a
little
bit
clearer
and
easier.
We
can
add
a
tool
to
it
to
the
button
to
make
it
obvious
what
the
button
is
doing
but
or
maybe
don't
use
an
exclamation
point
use
something
else
like
a
like
another
icon
or
something
on.
C
Yeah
I
think
that's
a
good
idea
as
well
and
I
I
think
yeah
yeah.
That's
that's
a
lot
better.
C
E
Anyway,
okay
well
we'll
hold
off
on
the
VR,
then
and
Remington.
If
you
could
just
comment
on
the
pr
and
let
Alex
know
what
your
concerns
are:
yeah.
C
Yeah,
absolutely
and
I
would
even
be
happy
to
you
know,
put
some
commence
as
well
so
cool
thanks
guys.
Let
me
get
my
gender.com.
D
C
K
I
think
maybe
it's
Justin,
because
Justin
wasn't
couldn't
make
it
well.
He
said
he
couldn't
make
it,
but
now
he's
here.
So
maybe
it's
better
since
he
was
suggesting
to
talk
about
this.
K
Otherwise
I
can,
but
the
gist
of
it
is
anyway
just
to
try
to
have
a
better
triaging
for
for
all
the
incoming
PRS
and
issues
that
we
have
really
and
and
Justin
the
suggestion
to
have
a
like
a
dedicated
channel
for
maintainers
reviewers
to
be
able
to
triage
and
view
incoming
PRS,
but
I,
don't
know
if
anything
more
specific
Justin
would
have
to
say
something
more
specific
about
that.
C
Sure
Justin
do
you
have
any
thoughts
there.
G
Yeah
I'm,
just
trying
to
brainstorm
with
Blake
I,
know
I
got
to
give
a
lot
of
credit
to
Blake
he's
been
putting
in
a
lot
of
hard
work,
doing
reviews
and
helping
out
I'm
gonna
try
to
join
him,
so
we
can
get
some
of
these
PRS
down
I'm.
Just
thinking
should
we
have
a
private
slack
channel,
so
we
could
communicate
with
the
reviewers
better
and
we
don't
flood
the
other
channels.
C
I
think
I'm
on
board
with
that
idea.
I
think
the
only
thing
that
I
want
to
make
sure
of
is
that
there's
not
already
something
that
exists
out
there.
So
I
know
that
there's
in
Argo
contributors
Channel.
So
perhaps
that
would
be
a
good
place
to
do
this
unless
there's
just
too
much
noise
there,
but
yeah
I'm
on
board
for
the
general
idea
of
being
able
to
communicate
about
issue
triage
and
PR
review
in
a
channel
but
yeah
before
we
create
a
new
one.
C
I
think
I
would
want
to
make
sure
that
there's
nothing
that
exists
already.
Oh
showbig
asked
private
Channel
or
a
different
public
channel,
so
I'm
not
sure
Blake
I.
G
Was
hoping
for
a
private
Channel
just
for
members
and
approvers
and
reviewers.
C
Okay,
yeah
I,
don't
think
that
that
exists
at
the
moment,
I'm,
not
sure
if
anybody,
if
anybody
else
knows
definitively
but
I,
don't
think
that
exists.
So
if
that's
the
case,
then
yeah
I
think
that's
a
good
idea.
G
That
way
well,
the
approvers
can
maybe
get
a
more
general
idea
of
what's
going
on
and
which
PRS
have
been
reviewed
or
ready
for
a
second
look.
G
I
just
think
it
would
cause
a
lot
of
noise.
We
could
make
it
public.
I
just
was
hoping
like
a
lot
of
the
public.
Just
didn't
come
in
hey.
My
PR
is
ready
for
review
just
for
us
to
improve
the
workflow.
A
I
K
Yeah,
that's
a
very
good
point
actually
because
I
was
thinking
the
same
as
young
a
bit,
but
but
there
is
just
having
something:
I
mean
people
who
want
their
PR's
reviewed
I
mean
they're
already
going
to
contributors
right
so
yeah.
So
it
would
make
sense.
D
L
Yeah
I
mean
we
would
set
rules
for
the
public
Channel
and,
if
somebody
violence,
effectively,
Point
them
to
the
rules
and
discourage
such
Behavior,
but
going
for
a
private
Channel
feels
a
little
opposite
from
the
direction
that
you
would
like
to
have
as
an
openness
as
that's
an
open
source
project,
unless
it's
private
for
a
very
strong
reason
like
security
or
internal
conversations,
which
cannot
be
public.
Oh.
I
D
Where
do
you
have
public
channels
right?
You
can
contributor,
so
I
think
a
reason
maybe
for
public
channel
is,
you
may
become,
it
is
a
public
and
then
someone
wants
to.
They
may
become
too
too
chatty
because
someone
wants
to
they
have
their
PR
reviewed
and
we
may
be
shot.
A
D
Know
advertising
in
that,
so
we
we
all
have
public
or
whatever
public
channel.
So
we
we
can
use
that.
You
know
if
you
private,
maybe
you
know,
maybe
we
can
or
know
that
you
can
balance.
You
know.
Maybe
talk
to
you
know
your
someone
here.
D
C
Yeah
I
agree
with
the
the
thought
that
we
could
just
continue
to
use
the
Argo
contributors
channel,
but
somebody
in
the
chat
mentioned
that
we
could
potentially
have
a
public
channel.
That
is
read
only
unless
you
have
explicit
permission
to
write.
I
think
that
might
be
a
good
idea.
C
I'm,
not
sure
if
that's
possible
in
slack
but
yeah
I
I,
agree
that
if
we're
just
going
to
open
and
in
public
Channel,
then
perhaps
we
can
just
use
our
code
contributors
because
I
think
that's
sort
of
the
point
of
our
good
contributors.
At
the
moment.
L
I
mean
if
we
have
admin
on
the
Argo,
slack
and
I
think
the
suggestion
that
panels
gave
would
work.
I
think
we
do.
But
then,
if
you
were
to
do
the
same
thing
on
CNC
of
slack,
we
wouldn't
be
able
to
do
what
one
was
recommended.
I.
C
L
C
Exactly
okay,
I
think!
That's
it.
Unless
anybody
has
strong
objections,
I
think,
maybe
that's
the
good
middle
ground,
where
we
we
requested
cncf,
to
create
a
channel
where
it's
reading
only
to
the
public,
but
certain
members,
I,
guess
it
would
be
members
approvers
reviewers
for
our
project
would
have
right
access
slate
congestion.
Does
this
sound
like
a
good
compromise.
C
Okay,
yeah,
if
you
would
you
guys
be
willing
to
request
with
the
cncf
about
getting
that
Channel
created.
C
Great
sounds
good
thanks,
guys,
okay,
so
moving
on
to
the
next
agenda
topic.
A
A
And
Justin
I
think
yeah.
C
Yeah,
okay,
great
so
manually,
labeling
NPR's,
with
t-shirt
sizing
and
moving
the
FAQ
to
the
main
map
section.
K
Let's
continue
on
the
same
topic,
so
in
better
triaging
for
for
both
issues,
incoming
issues
and
as
well
as
making
it
more
clear
for
the
world,
because
there
are
there's
been
quite
a
few
issues
where
it's
not
well
to
put
Mali.
It's
not
great
great
quality,
so
maybe
just
putting
putting
the
FAQ
more
into
the
Forefront
in
the
pr
templates.
This
is
as
well
as
expanding
upon
the
FAQ
to
kind
of
encourage
better
PR's,
basically,
as
for
exactly
how
how
that
will
look
like
it's
to
be
determined.
C
Sure
so,
firstly,
I
think
that
t-shirt
sizing
is
a
great
idea
and
that's
fairly
easy
to
implement.
We
can
just
add
new
labels,
in
addition
to
t-shirt
sizing
for
triage
I.
Think
one
of
the
issues
that
came
out
before
I
was
looking
for
a
priority
label.
I
think
kubernetes
does
this.
They
have
like
priority
low
medium
high,
urgent
things
like
that.
C
I
think
that
would
potentially
be
another
good
way
of
triaging
and
yeah
I
completely
agree
about
getting
more
visibility
onto
the
developer
guide,
I
think
putting
it
in
the
the
issue.
Template
would
be
good
or
the
pr
template.
C
Cool
unless
there's
any
objections,
I
think
you
guys
have
to
go
ahead
to
do
that,
and
that
would
be
really
helpful.
B
B
C
I
think
it
would
be
really
difficult
to
quantify
that
and
I
think
by
by
Nature.
It
would
just
have
to
be
sort
of
subjective,
I
I.
Don't
think
that
there's
really
an
objective
way
to
to
quantify
that
I
mean
you
could
do
things
like
number
of
files
changed
or
lines
of
code
change,
but
I.
Don't
think
that
that's
a
great
heuristic,
because
you
know
it
could
be
a
two-line
change
that
would
break
the
API
and
then
it's
like
you
know
that
needs
to
be
an
Excel.
But
it's
a
really
small
change
like
something
like
that.
C
I
think
would
be
difficult,
so
I
think
it
would
have
to
be
up
to
probably
the
reviewers
to
decide
who
and
whoever's
triaging
I
think.
That's,
maybe
the
the
point
of
this
that
it
sounds
like
Blake
and
Justin
are
trying
to
review
more
and
triage
more
so
people
like
them
that
are
actively
reviewing
PRS
looking
at
PR's.
C
G
A
C
Okay,
great
yeah,
so
if
you
guys
want
to
implement
that
then
you're
more
than
welcome
to
that's
a
that's
a
great
idea.
Thank
you!
Okay.
So
it
looks
like
we're
on
the
last
agenda
topic
so
adding
more
to
the
dev
FAQ
I.
Think
you
guys
just
mentioned
this
briefly.
Was
there
anything
more
you
wanted
to
talk
about
here
or
no.
C
Okay,
yeah
I
think
that
would
be
a
great
Improvement
to
make.
A
C
So
it
looks
like
that's
the
end
of
our
agenda
so
far,
does
anybody
have
any
last
minute
topics
or
thoughts
on
previous
agenda
topics
that
we
didn't
cover.
C
Foreign
that
case
we
will
end
a
little
bit
early
and
we'll
see
you
next
week.