►
From YouTube: Argo Contributors Office Hours Dec 1st 2022
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
B
My
God
I
was
muted
all
the
time.
Okay,
welcome
to
the
contributor
meeting,
I'm
gonna
be
your
host
today,
I'm
Leo
and,
as
usual,
we're
gonna
start
with
triage
in
discussion,
and
for
this
week
we
had
Jan
and
Remington
I.
Think
I
see
Remington
in
the
call,
not
sure
about
Yan
anything
for
this
week.
B
Okay,
okay,
cool
yeah,
all
right!
Thank
you!
So
I
don't
think
Jan
is
here
all
right.
So
let's
move
forward
and
decide
who's
going
to
be
doing
triage
for
the
next
week.
So
any
volunteers.
D
B
B
E
Okay,
hi
everyone,
so
yeah
I
believe
we
are
not
the
only
org
that
that
is
using
Helm
charts
instead
of
Kit,
so
for
every
git
commit
or
code
change.
We
we
get
a
new
version
about
the
first
version
of
our
hand,
chart
uploaded
to
to
ECR
and
then
I'll
go
reconciles
it
and
deploy
it
in
the
cluster.
So
the
idea
here
is
to
make
use
of
annotations
on
on
the
chart
itself
to
enrich
the
version
with
stuff.
E
B
B
Require
Helm
authors
to
add
a
nargo
CD
proprietary
annotation
am
I
understanding
this
correctly
Alex
exactly.
E
B
Okay
is:
is
it
possible
for
us
to
inspect
the
helm
charts
metadata
instead
of
asking
Helm
chart
others
to
use
another
annotation
I'm
thinking?
If,
let's
say
Helm
chart
authors,
don't
know
they
don't
know
anything
about
Argo
CD
or
they
don't
know
where
that
that
Helm
chart
will
be
deployed.
If
they
will
ever
add
this
annotation
in
their
house.
E
Well,
for
for
generic
current
charts
out
there
yeah,
you
could
use
the
author
and
the
description
you
could
overload
it
with
this,
but
I
I
doubt
anyone
will
will
do
something
like
this.
This
is
more
meant
for
charts
that
an
organization
Builds
on
on
demand,
like
like
we
and
I,
saw
others
in
the
channel
do
so
so
it
will
be
for
custom
charts
of
species
of
bespoke
services
in
an
organization,
but
not
for
charts
like
nginx
or
or
anything
public,
but
sure
there
are
at
least
two
Fields
you
could
overload.
B
Yeah-
and
maybe
thinking
about
more
of
you
know
a
general
purpose
use
case,
not
only
for
you
know
in-house
Helm
charts
and
how
the
community
could
leverage
this
type
of
functionality
as
well,
so
I'm
I'm,
still
debating
with
myself
it's
possible
to
just
get
the
Helm
metadata.
That
is
already
there.
Instead
of
you,
know,
reading
annotations
in
application
resource
this
way
and
make
it
more
a
general
purpose
kind
of
solution.
E
Yeah,
technically,
we
would
use
the
same
mechanism.
It's
it's.
A
Helm,
inspect,
CLI
or
Helm
show
I
have
a
preference
for
for
using
annotations,
because
then
you
can
tailor
it
to
to
your
needs.
But
if
we
want
to
to
make
it
generic,
if
you
see
value
or
other
members
of
the
community,
see
value
in
making
it
generic
and
that's
also
a
fair
enough
option.
B
G
B
A
Sure
so
I've
talked
about
it,
I
think
at
the
last
contributor
meeting,
but
I've
written
up
a
proposal
for
how
to
track
releases
and
sort
of
formalizing
the
release
process.
I
think
that
the
maintainers
are
going
to
look
at
this
proposal
and
hopefully
merge
it
at
the
next
maintainers
meeting,
which
I
think
is
next
Tuesday.
A
But
I
wanted
to
go
ahead
and
start
the
conversation
about
who
might
actually
want
to
take
on
the
role
of
sort
of
spearheading
the
2.6
release,
because
we're
getting
close
to
kind
of
the
time
where
we
were
looking
at
actually
starting
that.
Ideally,
it
would
be
someone
with
approver
status,
because
a
lot
of
the
checklist
items
for
pushing
a
release
require
approver
permissions.
A
But
we
could
also
couple
someone
without
approver
status,
just
a
reviewer
or
even
just
a
member
with
an
approver
and
have
the
member
slash
reviewer
do
a
bunch
of
sort
of
the
the
housekeeping
work
and
then
the
approver
actually
push
the
buttons
for
the
release.
So,
if
anyone's
interested
in
taking
on
either
of
those
roles,
I
think
now
would
be
a
good
time
to
get
a
get
a
volunteer,
not
necessarily
start
doing
anything,
but
at
least
know
that
someone's
interested
and
then
hopefully
we
can
get
the
2.6
process
moving.
A
And
if
we
don't
identify
anyone
today,
we
can
also
figure
someone
out
Tuesday
at
the
maintainers
meeting,
but
sooner
is
better
and
you
can
also
ping
me
or
the
contributors
Channel
and
select
to.
Let
us
know
if
you're
interested.
F
A
I
will
I'll
be
in
touch
with
you
to
talk
about.
You
know
what
the
steps
look
like
it'll
be
easier
once
we
get
this
PR
merged
and
we
have
like
a
checklist
to
follow.
Okay,.
B
Cool
thanks,
Michael
anything
else
from
this
topic.
I
I
I
just
had
one
thing
like
I
just
wanted
to
know.
Like
till
what
date
are
we
planning
for
the
2.6
features
to
go
in
so.
A
So
the
way
I've
got
the
pr
written
now
we
would
release
the
first
rc
on
December.
The
19th
I
just
put
up
a
a
suggestion
on
my
own
PR
to
push
it
back
a
week.
I
think
that
makes
sense.
Just
given
the
cycle
of
sort
of
when
we're
adopting
this
proposal,
so
I
think
December
19th
for
the
RC
and
then
January
9th
for
GA
would
probably
be
reasonable.
A
Yeah,
so
part
of
the
process
would
be
two
weeks
before
December
19th,
either
one
or
two
weeks.
I
forget
what
my
checklist
says,
but
we
would
have
a
meeting.
We
would
look
at
PR's
that
people
want
to
get
into
2.6
and
then
basically,
an
approver
has
to
claim
that
PR
and
say
that
they're
gonna,
you
know,
review,
approve
and
merge
it
or
it
gets
dropped
from
the
206
release
and
we
track
it
for
2.7,
and
that
would
happen
about
a
week
from
now.
I
think.
I
B
Okay,
anything
else
from
the
release,
2.6
2.6
release
anyone
and
we
are
sticking
with
the
new
process
right
Michael
by
looking
at
that
project
that
Justin
created
and
we're
going
to
be
tracking
from
there.
A
B
Yeah,
we
don't
have
any
more
topics
in
the
agenda
any
last
minute
topic.
Someone
wants
to
bring
up.
H
H
H
So
if
there
are
folks
who
might
find
that
of
Interest,
I
might
find
a
way
to
put
that
out
in
the
public
domain.
So
that's
about
it.
B
Thank
you.
We
have
one
meeting
dedicated
for
Argo,
workflows
and
I.
Think
it'd
be
interesting.
If
you
could
maybe
join
that
meeting
and
present
what
you
had
I
think
folks
will
be
interested
in
in
hearing
from
that.
B
Is
CDN
rollouts,
but
it
is
the
whole
Argo
family
yeah,
so
we're
close
together.
It's
just
that
for
the
for
the
workflow
contributors.
There
is
a
dedicated
meeting
for
that
and
that's
totally
fine
great.
B
All
right
and
welcome
cool
anything
else.
Anyone
yeah.
D
No
I
I
would
ask
like
I,
am
reviewing
award,
pull
request
right
now
in
a
notification
core
that
core
for
our
notification,
part
of
Fargo
City
and
like
here
coming
here,
happens
that
you
will
have
10
15,
interesting
Fuller
customers
soon
here
and
like
what
is
a
release.
Creation
process
for
this
service
should
I
just
handle
it
by
my
own
or
someone
specific,
or
what
is
life
cycle
of
releases
in
a
notification
notification
engine
like
I?
Guess
it's
a
similar
as
to
github's
engine,
for
example.
B
I
do
to
be
frank,
Pasha
I,
don't
know,
I,
don't
I,
don't
even
think
it's
the
same
as
github's
engine
because
get
Ops
engine
is
a
very
ad
hoc
kind
of
library
that
we
that
we
centralize-
and
we
manage
ourselves
for
this.
This
one
is
a
is
a
bigger
project.
D
D
B
D
B
D
B
Like
if
I'm
not
mistaken,
there
is-
or
there
is
a
release
process
for
that
project-
I'm,
just
not
aware
of
as
I'm
I
I,
never
contributed
to
it
myself.
If
somebody
else
knows.
B
Okay,
if
not
I'm
gonna,
give
you
those
minutes
back
from
your
day
and
see
you
all
next
week.