►
From YouTube: Argo Contributors Office Hours Aug 18th 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).
A
Hello:
everyone
welcome
to
the
contributors
meeting.
I'm
gonna
be
your
host
today,
I'm
Leo
and
starting
off
with
triage
in
discussions.
For
this
week
we
had
Jan
and
Justin
for
doing
triage.
I,
see
Justin
in
the
call
I,
don't
see
Yan
just
seeing
anything
to
to
add
anything.
You
found
this
week.
B
A
No
problem,
okay,
so
moving
forward.
We
need
to
find
who's,
gonna
be
doing
triage
for
next
week.
Any
volunteers
for
primary
and
secondary.
A
Sounds
good
thanks,
Justin
all
right,
so
moving
forward,
so
Michael's
not
going
to
be
able
to
join
today
he
has
another
appointment,
but
he
added
a
few,
a
few
topics
for
discussion
and
what
he
meant.
What
he
mentioned
to
me
is
if
we
don't
reach
an
agreement,
he
will
be
okay
to
to
bring
those
next
week
as
well
right.
So
the
first
one
is
about.
A
You
open
here
real
quick,
it's
about
issue.
You
opened
both
yeah.
C
Just
to
rename
the
master
Branch
domain,
which
I
think
most
projects
have
done
already,
GitHub
has
a
pretty
easy
process
to
do
it
as
well,
I.
Think
now,
apart
from
what
I've
mentioned,
that
I
think
you
don't
really
have
to
change
it
locally
yourself
and
then
push
it.
Github
makes
it
pretty
easy
to
change
the
branch
name,
but,
of
course,
people
might
have
to
do
something
locally
to
cancel
it's
working.
A
A
Every
every
maintainer
would
have
to
update
the
branch,
which
is
very
minimal,
very,
very
easy
thing
to
do.
The
only
thing
that
rings,
a
bell
to
me
is
the
the
less
topic
is
you
mentioned
here,
the
fix
subci,
which
my
break,
so
someone
would
have
to
be
assigned
to
double
check.
Everything
is
working
as
expected
in
our
release,
processing
in
our
CI
process
as
well.
C
Yeah,
that's
probably
the
most
critical
bits,
I
would
say:
yeah
yeah
GitHub
usually
makes
things
easier
by
sometimes
redirecting
Master
domain
kind
of
things.
I
haven't
checked
it,
though
recently,
because
I
think
this
is
a
pretty
long
time
ago.
That
time
we
didn't
have
all
those
fancy
things
but
I
think
that's
the
bit.
That's
probably
worth
checking
the
most
right.
A
A
So
Michael
was
mainly
asking
to
see
if,
if
you're,
okay
with
doing,
if
someone
has
any
concerns
or
think
that
any
anything
else
could
break
that,
could
block
this
personally
I'm
not
opposed
to
this,
but
yeah
just
go
ahead.
Well,
I'll
go
read
the
issue.
Actually,
sorry
I
was
just
trying
to
understand
the
motivation.
A
Well,
it's
mainly
to
yeah
to
remain
from
us
or
to
to
me
right.
C
Yeah
I
think,
if
you
I
just
I'm
just
trying
to
think
can
you
click
on
the
link
on
the
Argo
project.
Link
on
top
I
think
sure.
Is
there
something
to
do?
Okay,
no
I
just
made
a
uber
issue
there,
but
then
I
think
in
general.
Yes,
I
think
there's
been
a
general
Community
friendly
practice
about
moving
away
from
the
Torah
Master
to
Main.
B
I
think
one
other
thing
we
might
want
to
discuss
is:
if
people
out
there
are
pulling
from
the
master
Branch,
it
may
break
their
CI.
C
Trying
to
remember
I
think
for
Forks
I
think
Forks
would
wouldn't
get
disconnected
from
what
I
remember.
It
probably
have
to
check
this
out,
but
they
do
not
get
disconnected
like.
Let's
say
if
you
have
forked
a
repo
on
GitHub
GitHub
still
lets
you
have
that
sync
mechanism.
C
A
Then
I
don't
think
it's
an
issue
for
fork,
because
when
you
Fork
you
Fork
a
remote
right,
you
don't
Fork
a
specific
Branch.
The
only
thing
you
need
to
do
is
to
make
sure.
A
A
C
Go
ahead,
no,
no
I!
Think
the
question
is
you
know
it's,
let's
say:
I
I
have
a
fork
already
and
I
have
a
branch
which
is
Master
now
right,
the
remote
no
longer
has
a
master.
It
is
now
main
right,
so
I
think
for
Forks.
You
would
probably
get
an
error
but
worst
case
that
there
is
no
master
in
remote
anymore.
C
That's
when
you
go
in
and
look
hey,
there
is
no
master
and
I.
Think
it's
pretty
well
known
right
now
that
most
Masters
have
become
main
right
now,
so
you
basically
rename
your
local.
C
So
basically
you
rename
your
branch
locally
in
your
fork
and
then
you
push
that
to
your
local
and
then
you
push
that
to
your
corresponding
remote
and
then
you're
again
back
to
being
in
sync
100
percent,
and
this
is
all
if
there
is
no
easy
way
for
GitHub
to
just
understand
that
Master
is
made
because
GitHub
typically
handles
such
renames
and
migrations,
pretty
gracefully.
A
I
haven't
tried
it
myself,
but
if
what
you
said
is
true,
the
redirection
should
make
things
easier
for
customers
who
who
pull
directly
from
from
our
Master
Branch.
If
this
redirection
is
in
place.
A
All
right
so
yeah
in
order
to
to
start
this
work,
someone
is
to
to
pick
it
up
basically,
but
personally,
as
a
maintainer
I'm
not
opposed
to
this.
A
Okay,
moving
forward
annotated
tags
commit
shut
up
resolved
properly,
so
this
is
an
issue
identified
by
one
of
the
users,
I
I,
suspect,
related
to
multi-source,
I,
think
yeah,
Target
revision,
Target
revision,
Target
revision
and
basically,
what
the
person
is
saying
is
that
there
is
a
section
in
the
code
where
we
we
get
a
commit
pointing
to
the
Head
instead
of
honoring,
the
the
target
revision
that
was
configured
and
this
is
causing
an
issue.
A
So
it's
probably
a
bug
in
the
code
and
is
saying
a
person
is
saying
that
if
the
community
is
okay,
it
would
be
happy
to
to
push
VR
for
fixing
this.
That
looks
pretty
reasonable.
A
I'm
I
just
answer
to
him
say
saying
that
he
could
yeah
try
to
push.
If
you
are
fixing
this
okay,
I
can
reply
later.
No
I
have
to.
D
A
Right
now,
but
I'll
reply
back
to
him.
Okay,
so
the
other
topic
Michael
wants
to
bring
is
the
lead
namespace.
True,
there's
no
rules
requested
feature
right
now,
so
there's,
let's
see,
I
haven't
looked
at
it
yet
namespace
created
by
creating
space,
trees.
A
Oh
I
see
yeah
so
the
feature
that
we
have
to
create
namespace
when
the
application
is
deleted.
It
should
also
delete
the
namespace
if
it
was
matched.
That's
my
understanding.
C
D
A
Yeah
RDO
city
has
the
prune
option
right
so
by
default
doesn't
delete
things,
but
when
you
delete
the
application
entirely,
what
you
should
do
with
the
namespace
It's
tricky,
because
we
could
have
more
things
living
in
the
namespace
that
wasn't
created
by
the
application
itself.
So
I
think
it's
a
yeah.
It's
a
little
tricky
proposal,
I'm,
not
sure.
If
they're.
A
So
let's
say
they
created
a
namespace
with
Argo
CD,
so
it
was
originally
managed
by
article
City,
but
but
then
someone,
someone
else,
some
other
team
that
shares
the
same
name.
Space
for
some
reason
creates
additional
resource
in
a
different
application,
which
is
possible.
A
So
when
the
first
application
was
deleted,
I'm
not
sure
if
we
should
bother
with
the
entire
namespace
deletion
or
at
least
at
the
very
minimum
provider,
some
some
message
to
the
user
saying
yes,
this
application
space
doesn't
have
only
the
resource
managed
by
this
single
application,
but
it
has
more
resources.
What
do
you
want
to
do
right
so
I,
don't
think
it's
safe
to
just
hit
a
flag
and
and
allow
our
city
to
delete
the
entire
name
space,
because
we
might
delete
things
that
we
shouldn't
in
some
match
cases.
A
I
will
I
will
read
the
proposal
and
that
and
add
this.
This
concern
in
the
as
a
comment
here.
Does
anybody
else
has
any
other
concern
regarding
this.
E
Yeah
I'm
thinking,
because
this
was
an
outstanding
test
from
managed
main
space
metadata.
If
we,
because
this
was
something
which
we
wanted
to
be
able
to
display
in
the
UI
but
I'm
wondering
if
we
couldn't
piggyback
on
that
to
be
able
to
like.
If,
if
we
add
the
the
typical
managed
like
the
typical
label
or
annotation
on
the
namespace
itself,
then
maybe
that
could
be
a
part
of
solve
itself
so
to
speak.
But
that,
of
course
it's
a
bit
of
testing.
A
A
Logic
needs
to
be
a
little
bit
more
conservative
and
check
if
the
namespace
has
additional
resources
before
going
ahead
and
deleting
it.
A
Just
to
avoid
you
know
this,
hitting
someone
badly
in
the
future
and
yeah
blaming
the
project
for
deleting
things
that
you
when
it
shouldn't
right.
So
that's
my
only
concern
with
this.
C
D
C
Good
news,
plus
equal
to
True
is
more
of
a
helper
convenience
thing.
I
would
say
so
you
know
that
we
have
it.
C
For
obvious
reasons,
then
I
think
the
other
alternative
is
to
create
the
namespace
with
yaml
in
your
github's
repo
itself,
so
that
when
you're
deleting
the
application,
the
namespace
also
goes
away.
So
right,
that's
the
alternative
to
ensure
we
are
not
left
with
those.
But
this
is
a
helper
method.
It's
a
risk
to
stretch
that
helper
thing
into
deletion,
space
which
has
other
problems.
A
Okay,
cool
I'll,
I'll,
add
a
comment
here
with
some
concerns
that
we're
raising
cool
all
right
anything
else
about
this
one.
Anyone
I
wasn't
looking
on.
A
D
So
can
we
have
some
kind
of
annotation
to
the
namespace
to
say
it's
okay,
to
delete
as
part
of
the
application
cleanup.
A
D
A
If
we
go
that
route,
I
think
we
would
need
this
logic
to
validate
if
there
is
additional
resource
in
the
namespace
before
deleting
it.
C
C
If
you
string
into
the
territory
of
namespace
management
gradually,
that
does
make
me
uncomfortable,
but
then
you're
right.
We
have
to
check
if
that's
empty
and
then
the
venue
hit
delete
it
might
get
scheduled
for
deletion
but
actually
not
get
deleted
because
other
finalizers
around
so
right.
C
A
Yeah
but
I
I,
remember
in
the
original
ticket
when
Community
was
pushing
for
having
this
feature
is
because
they
they
didn't,
have
the
means
to
to
provide
the
namespace
themselves
like
it
was
a
Helm
chart
that
they
are
creating
right.
So
in
this
case
they
they
want
article
City
to
help
in
some
in
some
ways.
A
So
there
are
some
use
cases
where
this
feature
makes
sense
to
be
there
so
yeah.
Now
we
need
to
think
about
how
to
properly
address
the
deletion.
A
Cool
all
right,
okay,
so
no
more
topics.
Does
anybody
has
any
last
minute
topic
you
want
to
discuss.