►
From YouTube: Argo Contributor Experience Office Hour 10th Jue 2021
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
Okay,
good
morning,
good
evening,
everyone
one
more
time
I
might
be
wrong
again,
but
I
think
we
have
some
people
who
joined
for
the
first
time
today.
At
least
I
don't
recognize
some
names
like
suba,
basically,
if
any,
if
you're
joining
for
the
first
time,
can
you
please
introduce
yourself.
B
A
B
This
is
subhan
I'm
from
india,
so
I
work
for
f5
networks,
hyderabad
and
I'm
part
of
the
team
which
develops
ingress
controllers
and
related
tools
for
f5
big
ip
load
balancer.
So
that's
brief
about
me.
I
just
brought
through
cncf
projects
like
like
last
year.
I
have
attended
qcon
so
from
yeah.
Just
like
that,
I
was
browsing
through
cncf
projects
and
I
found
this
one
to
be
interesting,
so
just
wanted
to
learn
and
if
possible
like
like
interested
in
contributing
to
this
one.
So
just
join
this
meeting.
D
A
I
would
I
propose
to
talk
about
process
enhancements
and
the
talk
was
written
before
jan
brought
up
his
improvements.
So
that's
why
there
will
be
a
lot
of
overlap
and
if
you
don't
mind,
I
will
start
from
sharing
my
document
and
I
do
not
want
to
go
through
the
whole
document,
because
I
can't
afford
a
lot
of
text
like,
but
you
know
to
make
it
easier.
I
brought
up
these
six
kind
of
sentences
to
the
top
just
to
explain
what
that
is
about,
and
basically
I'm
not
proposing
to
change.
A
We
kind
of
do
pretty
much
everything
already.
All
of
these.
You
know
processes
already
in
place,
but
you
know
some
of
them
can
be
improved
a
little
bit
some
of
them.
We
don't
follow.
Sometimes
we
just
forget-
and
I
thought
it
would
be
nice
to
document
it.
Okay
and
let
me
just
jump
into
it,
so
the
first
one
we
already
kind
of
agreed
to
do
and
jan
proposed
it
first.
A
Basically,
the
idea
is
to
identify
component
owners-
and
I
think
jan
proposed
it,
because
he
wanted
to
make
sure
code
review
is
reviewed
by
the
right
people
and
I
came
to
the
same
kind
of
proposals
from
slightly
different
angle.
I
wanted
to
propose
it
just
to
you
know,
make
it
easier
to
get
ready
for
releases.
Basically,
if
we
split
components
by
owners,
we
automatically
know
who
will
make
sure
the
quality
you
know
and
is
good
and
all
the
bugs
are
fixed,
and
that's
why
yeah?
A
A
C
I
mean
this:
will
this
will
change
over
time
anyway,
right
so
new
new
contributors
come
and
new
components,
maybe
also
come
and
yeah.
I
think
the
the
names
this
is
just
like
yeah,
a
starting
point
to
be
discussed,
and
but
it's
it's
good
that
it's
it's
like
you
know
not
written
in
stone
but
written
on
a
piece
of
digital
paper.
So.
A
Okay,
the
next
is
so,
I
think
so
next
proposal
is
to
have
a
plan
for
two
releases
ahead
of
time
instead
of
one,
and
that
was
just
so
last
time
when
we
finished
1.8
release
and
then
I
feel
like
I
was
tired
and
then
people
got
distracted,
but
basically
for
couple
weeks
he
almost
had
no
plan
for
the
next
release.
It
was
just
empty
milestone,
2.0
and
yeah,
and
that's
it
so
and
I'm
afraid
same
thing
will
happen
at
2.1
to
the
after
2.1
got
released
yeah.
A
A
But
what
do
you
think
and
yeah?
Let
me
open
the
tx
that
I
wrote
to
justify
it,
but
yeah
this
is
pretty
much
this
is
it
okay
and
the
one
point
about
discussion
is
yeah.
So
henrik
added
the
question-
and
I
didn't
resolve
it
because
I
didn't
know
the
answer
yeah.
So
the
question
is.
A
I
think
it's
supposed
to
be
yeah
I'll
fix
the
dog,
but
basically
what
do
you
think
about
planing
for
two
releases
ahead?
Oh
yeah?
Okay,
so
I
just
changed
the
name,
so
I
made
the
topic
a
little
bit
more
broad
and
basically
renamed
it
into
release
milestones,
but
inside
of
it.
So
yes,
we
we
need
to
have
plan
for
two
releases
and
then
I
try
to
clarify
you
know
what
you
know.
A
The
meaning
of
release-
and
I
mentioned
that
you
know
basically
what's
in
the
release-
is
something
we
commit
to,
and
I
mentioned
that,
if
we're
unable
to
deliver,
then
you
know
we
can.
Basically,
if
we're
unable
to
finish
on
time,
what
we
committed
to.
We
can
move
the
date
of
release
and
hendrick
asked
so
maybe,
instead
of
moving
the
release
date,
we
should
move
the
feature
itself
to
the
next
release.
But
you
know
sorry,
I
kind
of
let's
get
to
the
first
question.
E
I
think
just
a
quick
comment.
I
think
the
goal
here
is
just
to
be
more
predictable
right.
I
think
right
now,
like,
like
alex,
said
it's
it's
a
little
bit
late
in
the
game,
trying
to
figure
out
what
goes
internationally.
So
having
things
figured
out,
a
little
bit
more
in
advance
would
hopefully
make
the
planning
process,
and
I
know
that
that
people
in
the
community
have
asked
for
more
transparency
in
what's
coming
in
the
roadmap.
E
So
having
this
planned
out,
a
little
bit
further
would
benefit
a
lot
of
people,
but
I
think
to
your
earlier
point,
jan
as
well.
This
is
also
this
is
a
road
map
right,
it's
not
it's
not
necessarily
set
in
stone.
I
mean
it
would
have
to
be
some
adjustments
as
people
come
and
go
when
and
new
ideas
come
up
as
well,
but
at
least
you
know
have
a
better
a
better
plan
and
a
little
bit
more
transparency
and
just.
A
I
will
be
quick,
so
I
wanted
to
clarify
that
I
talked
about
those.
I
wrote
my
platform
and
this
was
kind
of
short-term
planning.
Basically,
my
main
goal
was
to
avoid
you
know
two
weeks
of
unorganized
work
yeah,
but
you
know
I
agree
with
brought
up
as
well.
C
Yeah,
and
just
can
you,
can
you
scroll
up
so
to
the
to
the
agenda
so
basically
document
agenda
because,
okay,
I
was
thinking
that
so
in
in
this
I've
read
this
sentence
that
we
can
use
the
the
items
on
the
milestone
to
estimate
the
delivery
time
of
the
release
right,
but
wouldn't
wouldn't
it
make
sense
to
turn
it
like
around
like
have
a
time
box,
because
what
I
hear
from
the
community
very
often
is
when,
when
can
we
expect
the
release?
C
C
Is
something
users
rely
on
to
like
set
out
their
updates
schedule
and
and
stuff
like
that,
and
maybe
maybe
it
would
make
sense
for
us
as
well
as
when
we
say
okay,
we
make
a
minor
release
every
three
months
and
then
look
what
we
can
fit
into
into
the
milestone,
just
as
an
additional
idea
for
for
planning
that.
F
Yeah
and
that's
what
hendrick
was
saying
as
well,
that
we
would
scope
releases
down
to
a
particular
cadence
and
then,
if
something
didn't
fade,
it
would
just
move
to
the
next
one.
E
E
Strong
strong
proponent
of
of
having
time
box
releases,
instead
of
and
by
identifying
features
and
owners
for
those
features,
you
know
we'll
get
a
little
bit
more
clearly
on
on
who
does
what
for
each
release,
but
back
to
your
earlier
point,
yes,
I
would
definitely
prefer
to
see
you
know
a
more
release,
train
release,
train
schedule
with
fixed
dates.
If
you
missed
the
date,
then
you're
just
on
the
next
train.
Instead.
G
G
That's
a
good
way
to
make
people
feel
comfortable
that
you
know
things
will
start
showing
up,
and
on
top
of
that,
the
second
thing
that
I
find
good
about
time
boxing
is
that
it
helps
us
also
plan
enhancement,
proposals
in
advance,
which
means,
if
we
know
something,
is
going
to
happen
two
releases
down.
We
might
as
well
have
the
enhancement
proposal
done
early
on.
So
then
we
can
get
the
design
first
out
so
plus
one
on
that
yeah.
E
And
and
in
addition,
it
helps
it
helps
people
to
figure
out
their
upgrades.
They
know
when
you
release
are
coming
out.
They
can,
you
know,
do
set
that
up
as
a
quarterly
process.
You
know
that
every
quarter
we're
going
to
update
our
argo
instances
on
roughly
this
date
and
also
for
for
vendors
that
have
products
that
are
integrating
or
shipping
with
argo.
Then
you
know
it
makes
them,
makes
it
easier
for
them
to
plan
their
releases
as
well.
F
Yeah
and
then
that
second
release
that
release
plus
one
would
be
a
waiting
room
for
enhancements
or
fixes
that
we
don't
think
will
fit
in
the
current
release,
but
our
high
priority
enough
that
we
want
to
do
it
in
the
next
release.
So
this
change
would
also
solve
that
plan
for
two
releases
thing
as
well.
A
A
A
A
We
will
have
to
see
how
much
we
can
fit,
and
you
know,
and
should
not
be
too
difficult
to
come
up
with
two
backlogs
for
current
and
upcoming
release.
Okay,
I
guess
I
can
move
on
to
the
next
next
point.
E
It
was
just
just
just
two
quick
compliments
and
there's
nothing
preventing
a
feature
from
spanning
over
more
than
one
milestone
right.
So
if
there's
something
that
the
the
only
thing
is
gonna
last
more
than
one
one
released
and
then
they'll
just
show
up
in
the
later
one.
The
the
second
is
more
of
a
question.
So
if
we
say,
for
example,
if
the
decision
is
not
due
every
every
quarter,
are
we
going
to
do
a
an
endless
stream
of
minor
releases?
A
Have
a
smooth
process
to
create
patch
releases
which
can
deliver
just
bug
fixes
so
like
we
don't
have.
We
have
basically
two
just
two
type
of
releases:
major
and
bug
fixes
yeah,
and
I
I
was
thinking
that
if
we
really,
we
might
have
to
start
introducing
like
feature
flags.
A
You
know
just
so
that
people
can
keep
moving
pushing
code
to
master
branch
yeah.
So
I
I
mean
I
think
it
would
be
really
inconvenient
if
we
get
lots
of
pull
requests
that
stay
open
forever,
because
we
cannot
merge
that
code
since
it
doesn't
fit
into
release
and
we
might
start
using
feature
flux.
You
know
so
and
merge
new
features,
but
just
don't
expose
them,
and
this
will
unblock
us
and
we
can
make
maybe
more
frequent
major
releases
with
new
features.
G
So
so
did
you
so
henrik?
Did
you
mean
sorry,
I
think,
I'm
speaking
to
both
you,
you
know
alex
and
henrik.
So
did
you
mean
by
major
religious?
Do
you
mean
like
argo,
three.
G
E
I
mean
we
basically
have
a
a
type
of
made
release,
that's
basically
a
dot
release,
and
then
we
have
the
patch
let's
decide
where
in
reality,
most
products
really
have
three
types
of
releases
to
have.
You
know
a
patch
or
patch
that
release
a
minor
release
and
then
a
major
release
where
a
minor
release
doesn't
have
any
breaking
changes,
not
too
many
huge
features,
whereas
a
major
release.
You
know
you
can
potentially
expect
you
know
bigger
architectural
changes
and
potentially
breaking
things
like
that.
But.
C
E
G
G
C
You
know
I
was
thinking
that
that
henrik's
proposal
was
pretty
good.
So
if
we
say
we
do
so,
we
we,
let's
reserve
the
right
that
we
have
one
major
release
per
year
and
then
to
your
idea.
It
should
be
ad
hoc,
but
so
I
think
I
mean
the
2.0
release
came
pretty
surprising
to
me
at
least
so
I
was
expecting
a
1.9
and
I
think
there
are
a
few
changes
in
mind
that
would
require,
or
that
are
breaking,
and
that
would
require
a
major
change
right.
G
I
mean
yan,
I
mean,
I
think
we
should
definitely
you
know
not
do
it
one
year.
I
think
we
can
come
up
with
that
cadence
in
general,
because
one
year
means
roughly
we
would
have
three
or
four
minor
releases
prior
to
that,
and
if
we,
if
we
do
too
many
major
releases,
we'll
reduce
the
value
of
a
major
release
or
a
breaking
release.
G
So
it
should
be
kind
of
like
you
know
now.
There
are
way
too
many
breaking
things
happening
and
it
does
look
like
you
know
we
need
to
or
we
need
to
break
things
because
well,
it's
just
accumulating
tech
debt.
I
think
that
should
be
a
ceremony
where
we
come
in
and
you
know
some
somebody
makes
a
proposal
to
say
hey.
It
is
time
to
make
a
breaking
change
now,
a
breaking
release.
G
D
G
Yeah
I
mean
once
a
year
would
be
extremely
hard
for
enterprises.
I
would
say
so
so
that's
not
go.
I
mean
I'll.
Take
that
off
the
table
for
now,
but
then
I
would
say
in
general
I
I
would
kind
of
do
it
like
it
should
be
on
demand
or
catching
up
with
the
market.
Any
of
these
two
catching
up
with
the
market
would
include
like.
We
definitely
know
that
we
are
behind
on
a
lot
of
things
and
we
need
to
move
on.
So
what
that
means
is
the
work
for
argo.
G
G
I
mean
I
wouldn't
put
a
cadence
on
that
rather
like
it
has
to
be
a
very
strong
reason
like
for
us
m3
to
help
for
right
now
the
the
planning
for
helm4
is
beginning,
and
I
think
the
general
conversations
you're
having
there
is
that
if
at
some
point
somebody
feels
that
helmford
is
not
needed
and
makes
a
strong
case
we'll
just
stop.
So
it
I
mean
in
general,
life
which
are
arguably
bigger
than
that,
because
it
has
so
many
moving
parts.
So
yeah
major
ones
have
to
be
very
well
thought
out.
B
C
E
And
the
major
release
doesn't
necessarily
have
to
mean
breaking
changes
right.
It's
just
a
it's!
It's
it's
just
something
to
to
signify
that
it's
a
larger
number
of
changes
and
an
opportunity
to
make
a
little
bit
more
splash
around
it.
But
if
I
think
the
important
thing
is
getting
to
a
cadence
with
a
minor
release
is
an
indicate.
The
major
releases,
I
think,
is
something
we
can
figure
out,
but.
A
A
E
G
Yeah,
I
think
so
too
I
mean,
if
we
can
time
box
that
in
a
way
that
it's
deterministic,
I
think
that's
good
enough.
Let's
not
make
I
mean
nobody
likes
frequent
breaking
changes.
I
mean
frequent
change
is
coming
in
with
potential
regression.
So
it's
fine.
A
A
So
we
can
plan
for
two
releases
and
we
kind
of
committed
to
what
we're
going
to
deliver
and
at
the
same
time
we
have
long
things
of
improvements
and
feature
requests
that
community
can
contribute,
and
I'm
proposing
to
you
know
basically
make
sure
we
figure
out
what
we
want
community
to
work
on
next
and
next
time
is
and
make
sure
current
release
milestone,
have
a
good
backlog
backlog
of
those
things
yeah,
so
does
it
make
sense
this
sentence?
That's
just
it
will
try
to
repeat
again.
A
So
basically,
let's
say
we
work,
you
know
all
maintainers
figure
out
what
we
committed
to
work
on
in
the
next
release,
and
then
we
do
one
more.
You
know
we
spend
another
hour
and
we
go
through
most
popular
feature.
Requests
that
we
don't
plan
to
work
on,
but
we
hope
community
can
contribute,
and
basically
we,
if
we
add
this
into
the
current
milestone,
that
increases
chances
of
those
contributions
happen.
A
A
I'm
pretty
sure
they
just
look
for
you
know
for
like
a
good
starter,
there
is
a
label
that
pretty
much
all
open
source
projects
use
to
identify.
You
know
this
type
of
tickets.
I
think
it's
helped
me
that
yeah
label
and
yeah
and
then
another
first
issue.
A
We
always
have
such
issues
help
needed
and
we
and
we
for
sure,
have
someone
to
review
prs
for
for
those
issues
because
yeah
we
have
a
problem,
we
keep
getting
few
pull
requests.
A
I
think
almost
every
day
and
number
of
open
pr's
that
unlikely
going
to
be
closed,
keep
growing,
and
this
is
to
address
that
problem
kind
of
wait.
I
think
at
least
you
know
if
someone
send
us
pull
requests.
That
is,
for
you
know
something
that
we
didn't
ask
anyone
to
work
on.
At
least
we
have
excuse-
and
we
can
say
sorry
we
will
get
to
it
but
later,
because
we
have
a
backlog
of
other
things
that
we
plan
for.
C
Right
now,
I
I
think
I
I
understand
what
so
the
the
motivation
behind
it
and
basically
put
them
in
the
in
the
backlog
in
the
might.
What
in
milestone
is
like
a
stretch
goal
yes
for
people
to
work
on
so,
but
we
at
the
same
time,
we
commit
to
reviewing
a
pr
that
would
be
submitted
for
this
feature
right.
G
G
A
Yeah,
I
think
you
you're
right.
Yes,
I
was
talking
about
just
current
release.
Basically,
I
didn't
want
to
assign
this
community
issues
to
releases.
I
was
just
thinking
to
mark
a
bunch
of
issues
that
we
are
right.
Okay,
basically
just
just
mark
issues
that
we
are
hoping
to
get
help
with
from
community
now,
and
if
someone
pick
it
up,
there
is
a
high
chance
that
some
one
of
us
will
review
pr
and
get
it
merged
eventually,
and
I
think.
E
Yeah
so
basically
a
way
to
see
it
is
that
so
let's
say
we
have.
You
know
the
two
next
releases
mapped
out.
We
have
a
bunch
of
features
with
with
owners
to
them
and
those
would
be
the
must-haves
for
those
two
releases
and
then,
in
addition
to
those
there's
a
number
of
nice
to
haves,
that
we
don't
have
any
commitment
from
owners
to
and
those
are
basically
listed
for
each
release
for
for
other
people
that
haven't
committed
to
to
pick
up.
You
know
in
those
releases.
F
C
An
opener
like
like
an
offer,
if
you
want
to
get
involved,
you
can
take
a
look.
If
that's
the
correct
challenge
for
you.
C
A
C
A
A
Okay,
I
will
go
to
move
to
the
next
one.
We
have
two
more
release:
testing
process
and
android
map
yeah.
So
the
release
testing
is
tightly
coupled
with
component
owners,
so
release
dating
is
simple.
I
was
just
going
to
propose
that
we
divide
testing
responsibilities
and
pretty
much
component
owners
should
help
to
test
their
own
components
and
and
keep
track
of
changes.
A
So
let's
say
I'm
going
to
pick
myself
like
the
core
features
and
we
should
document
what
core
features
is
somewhere,
but
I
was
referring
to
thinking
and
diffing
and
if
I'm
the
owner
and
the
only
owner
of
that
component,
that
means
I
must
watch
for
each
and
every
change
that
we
just
keep
an
eye
on
prs,
and
maybe
you
know,
keep
some
notes
somewhere
that
I
know
we
introduced
a
couple
more
sync
options:
we
improved
different
performance
and
then,
when
the
time
comes
to
test
the
release,
I
will
be
the
one
who
will
be
testing
difficult
thinking
and
then
and
everyone,
and
basically
the
good
thing
is
that
no
one
else
have
to
do
it.
A
You
can
rely
on
me
that
I
will
do
the
same,
and
then
you
know
kid
and
help.
Usually
we
work
with
young
on
this.
You
know
integration
with
git
and
it's
already
happening
effectively
like
very
often
when
we
make
improvements
and
kids.
We
typically
expect
that
jan
will
test
it
and
same
with
security,
like
jan,
usually
takes
care
about
security
changes,
and
I'm
just
proposing
to
make
it
a
little
bit
more
formal
and.
A
Yeah
and
have
it
as
expectation
so
when
we,
when
it
comes
to
the
time
come
for
for
for
the
next
release,
we
should
not
ask
for
you
know
we
should
not
start
looking
for
volunteers.
We
should
already
have
a
list
of
people
who
is
going
to
help
his
testing,
and
we
know
you
know
area
of
responsibility,
yeah
and
that
that
will
help
to
make
release
more
predictable,
because
now
it's
kind
of
when
we
are
getting
ready
for
the
next
release.
A
We're
like
okay
fingers
crossed
let's
start
testing
and
see
how
it
goes
yeah,
and
if
we
have
a
lot
of
people
who
are
kind
of
trying
to
keep
an
eye
on,
you
know
getting
ready
for
the
release.
We
can
get
more
realistic
picture.
You
know
before
testing.
A
A
And
I
feel
like
this
is
basically
a
question
to
owners
like
so
if
we
will
get
enough
of
owners
who
volunteers
to
help
this
testing,
and
I
need
to
help
his
you
know.
Yes,.
C
A
Yeah-
and
I
did
want
to
highlight
that
we
already
kind
of
have
owners
and
it's
you
know.
I
know
that
upset
work
that
maybe
will
happen
in
next
release.
Most
likely
jonathan
will
be
working
on
it
and
like
may,
she
usually
kind
of
she
fixed
bunch
of
boxes,
home
integration,
customized
integration
and
most
likely
she
kind
of
tends
to
pick
tickets,
yeah
and.
J
Yeah,
I
think
it's
a
good
idea,
so
in
case
we
have
questions
that
we
need
to
figure
out.
We
know
who
to
who
to
approach
right.
I
think
it's
the
ownership
of
component
help.
So,
like
you
know,
if
you,
you
know,
get
a
question
from
the
community
and
you
know
the
discussion
that
you
made
any
further
investigation.
Maybe
you
know
there's
a
listen,
you
can.
C
Yeah,
so
maybe
we
can
even
can
we.
C
Can
we
help
this
with
tooling?
Like
I
mean
the
previous
releases,
it
was
like
a
list
of
pr's
that
went
in
right
and
someone
had
to
test
it.
So
if
we,
if
we
can
agree
that
before
we
merge
a
pr
we
just
assign
the
owner
and
then
we
can,
we
can
just
filter
out
by
the
owner
right.
Oh.
A
A
C
C
D
A
Yeah
I
like
that
very
snakes.
I
forgot
that
pr
already
has
kind
of
assignee
and
that
assignee
I
never
understood.
So
there
are
two
fields
like
you
can
request
review
and
you
can
assign
pull
requests
and
I
think
we.
D
A
A
K
K
J
So,
based
on
the
change
of
the
co
and
then
we
can
assign
assign
owner,
but
but
when
you
appear
right
you
you,
don't
you
don't
you
based
on?
Basically
you
allow
a
human
because
you
get
a
pr
and
then
there's
no
change
yet
right
that
that's
from
that
point
at
the
beginning,
it
could
be
some
human
like
doing
an
assignment
but
yeah.
When
you
have
a
when
you,
when
you
have
already
changed
some
some
files,
some
under
some
some
directory
and
then
we
can.
J
A
I
think
this
owner
files
will
make
it
easier
because,
if
a
profile,
it
helps
to
figure
out
who
you
know.
Okay,
all
the
files
are
in
the
folders
and
pr
touches
some
files
in
some
folders.
So
if
you
see
that
so
most
likely
owners
of
the
folder
that
is
affected
the
most
by
the
player
are
going
to
be
assigned
to
to
the
pair
okay.
J
Is
it
automated
already,
if
you
ever
own
a
photo,
the.
A
Photo
kind
of
semi-automated,
I
think
github
will
request
review
from
owners.
It
won't
ascend
owners
to
the
period.
I
C
But
we
we
cannot,
so
we
can.
We
can
set
up
like
a
weekly
process
that
queries
the
github
api
for
merger
changes
and
list
those
that
do
not
have
an
assignee
and
just
you
know,
send
out
email
or
slack
like
please
assign
the
owner
yeah.
Well,
that's
that's
just
same.
A
C
To
it
would
be
great
if,
if
github
would
have
an
like
constraint
for
that
right,
like.
A
A
C
That,
maybe
maybe
we
can,
we
can
put
in
a
github
action
that
looks.
C
A
C
A
J
Okay,
my
question
again
so
in
the
branch
connection
I
think,
is
it
already
enabled
the
if
you
have
reviewed
it.
A
A
I
A
A
A
Our
roadmap
was
not
updated
for
like
a
year,
I
think,
and
it
started
causing
confusion.
I
personally,
I
found
a
couple
blogs
that
were
referring
to
outdated
and
information
in
a
roadmap
yeah.
So
you
know
I
feel
like
we
should
document
somewhere
that
at
the
end
of
each
release,
we
should
go
ahead
and
update
roadmap,
remove
absolute
items
and
add
yeah.
So
it's
it's
kind
of
it's
not
a
question.
Roadmap
should
be
updated
up
to
date
and
I'm
proposing
to
commit
to
update
it
after
each
release.
A
C
C
Another
thing
we
keep
constantly
forgetting
is
moving
the
stable
tag.
C
C
F
Yeah
the
applications
that
release
prose
test
is
based
on
the
argo
cd
release
process
and
the
image
updater
release
process,
which
basically
worked
the
same
way
and
yeah.
I
have
a
release
checklist
that
includes
those
two
exact
items,
among
others,
just
because
it's
easy
to
forget
them
so
release
checklists.
I
found
in
the
past
on
previous
projects
and
also
with
application,
sets
to
be
a
really
good
idea,
so
plus
one
for.
A
A
C
Maybe
we
we,
we
should
maybe
migrate
to
google
meet
for
for
our
sessions
because
they,
I
don't
know
if
they
save
it,
but
they
have
this
transcript.
You
know
live
transcript.
You
don't
have
to
re-watch
the
video
you
just
have
to.
J
The
chat
so
so
you
don't
have
to
like
manually
turn
and
paste
to
the
file
yeah
and
the
meeting
the
recording
is,
will
automatically
attach
to
the
to
your
to
your
meeting.
Like
you
know
your
calendar,
so
yeah.
A
J
Look
for
a
particular
meeting
yeah,
so
I
think.
C
J
Google
me,
like
the
subtitle,
I
don't
know,
I
don't
think
that
I
don't
know,
I
don't
think
it's
recorded.
I
think
it's
like
a
real
time
thing.
J
You're
talking
about
the
challenge,
yeah
that
I
don't
think
you
get
fit
with
google
me
as
a
red
card,
but
yeah,
but
I
yeah,
I
like
commit
better
myself
over
soon.
I
know.
A
A
It
seems
like
we're
saying
before
we
start
release,
we
must
have
plan
for
current
release
and
the
next
release.
We
need
to
make
sure
so
it's
kind
of
a
bunch
of
check
boxes,
for
you
know
that
we
have
to
check
before
we
start
before.
We
should
say
we're
ready
for
for
the
next
release
and
then
few
check
boxes
that
we
must
check
to
close
current
release
and
move
on
so
is
it?
Is
it.
A
F
A
Please
yeah
it's
in
the
chat.
Thank
you
yeah.
I
will
make
sure
to
copy
it
before
it
goes
away.
Okay,
right
thanks
a
lot,
I
think
I
I
I'm
like
extremely
satisfied,
this
all
feedback
from
the
doc
and
yeah.
If
there's
nothing
else,
we
can
move
on
to
the
next
item.
A
A
Yeah,
okay,
never
mind
so
someone
just
did
the
topic
updated
yeah.
So
the
next
item
is
application
resource
tracking
proposal
and
we
have
10
minutes
to
discuss
it,
and
I
do
not
know,
I
think
maybe
maybe
it
will
be
enough
to
you
know.
Maybe
10
minutes
will
be
enough
to
discuss
that
proposal.
Yeah.
What
do
you
think.
A
D
A
C
A
C
A
All
right-
and
so
I
will
I
can
quickly-
you
know,
give
a
summary
of
what
I
did.
I
just
I
tried
to
create
a
fake
github
work
and
create
a
couple
users.
So
I
realized-
and
I
validated
that
each
and
every
member
of
that
fake
github
work
had
access
to
work
level,
projects
and
and
that's
why
I
created
work
level
project
in
apple
approach
as
well.
So
it's
not
part
of
argo
cd,
it's
kind
of
a
project,
level,
org
level
project
and
it
references
to
three
positives.
A
So
in
theory
we
can
add
here:
tickets
from
github
engine
and
notification,
engine
and
anarcho
cd
yeah,
and
I
just
copied
same
set
of
columns
as
yes
github
as
a
go
link,
enhancement
proposal
taking
project
have
so
it
has.
Basically,
here
I
have
incoming
feature
request,
which
is
just
a
backlog
of
features
with
master,
and
then
I
put
10
into
active,
and
this
is
kind
of
for
for
today's
meeting
and
then
today
we
can
just
drag
and
drop
this
into
either
accepted
or
declined.
A
A
C
A
C
A
D
A
Added
intentionally
very
different
ones
here,
some
of
them
straightforward,
some
of
them
not
straightforward
at
all
and
yeah,
let's
start
and
see
what
happens
and
one
more
thing
before
we
start.
So
I
think
we
agreed
last
time
not
to
add
too
many
things
from
the
past,
because
we
want
to
stay
kind
of
on
top.
What's
of
what's
coming,
okay,
yeah!
That's
why
we
have
only
like
25
here
but-
and
I
went
back
maybe
a
couple
months
just
so.
Basically,
you
won't
see
old
feature
requests
in
that
list.
A
Okay,
so
here
is
here's
the
first
one.
So
this
I
think
to
me
this
is
straightforward
requirement,
so
the
request
is
to
make
our
ocd
up
unset
command
at
important,
and
one
example
here
is:
if
you're
trying
to
remove
environment
variable
that
is
not
there.
It's
already
removed
currently
cli
fails,
and
I
think
it's
kind
of
inconvenient,
because
if
you
have
some
automated
process,
you
need
to
start
writing
like
e-files
using
bash,
and
instead
we
can
just
you
know,
make
the
comment
itself.
Other
important.
A
C
This
idea
of
importance,
so
maybe
it
prints
a
warning,
but
it
will
not
error
right.
So.
A
Yeah,
I
I
just
I
realized
we
already
have
few
such
commands
like
we
have
create
application
up,
create
and
cluster
add
and
I
think
replay
it
and
all
of
them
have
dash
absolute
commands
but
absurd
and
that's
what
makes
them
important
and
maybe
we
can
come
up
with
a
similar
flag
for
onset.
A
I'm
trying
to
decide
you
know,
if
is
it
good,
to
go
ahead
and
move
that
issue
into
accepted
column,
or
this
one
requires
discussion?
I
agree
with
you,
it's
not
just
you
know.
I
would
not
just
blindly
make
it
and
important
and
change
behavior.
Maybe
we
need
environment
variable
or
flag
yeah,
and
I'm
I
propose
to
just
I'm
going
to
add
a
comment
right
now
and
just
say
yes,
but
we
should
introduce
cli.
C
A
J
A
I
A
Okay
and
I
I
must
switch
to
my
own
account
because
argobot
cannot
move
tickets.
Okay,
so
accept
it
all
right.
The
next
one
is,
I
think
this
we
should
not
much
argue
about.
Basically,
we
have
like
a
ton
of
requests
to
support
mark
arm
images,
not
not
mac.
Just
you
know,
I
think
it's
just
arm.
J
A
C
I
Or
cross
build,
or
something
like
that,
you
know.
C
A
Okay,
let's
let's
move
on,
we
have
two
more
minutes
and
maybe
we
can
stay
a
couple
more
minutes
after
okay,
so
that
request,
I'm
just
going
to
give
a
summary
because
I
I
read
for
it
idea
is
to
introduce
filters
that
can
you
know
you
can
quickly
find
recently
synced
resources.
So
it's
a
ui
change
and
I
think
we
already
had
a
volunteer
to
work
on
it.
C
Nothing
against
it
right,
so
I
mean
I
mean
if
we
move.
If
we
move
the
the
cards
to
accept
it,
it's
it's
not
like
a
commitment
that
will
do
it
yeah.
So,
as
we
discussed
last.
I
A
A
C
C
The
power
power
pc
platform,
like
the
big,
the
big
boxes
from
ibm.
F
You
may
have
seen
it
referred
to
as
power
eight
power,
nine,
the
upcoming
power
ten,
it's
yeah,
an
enterprise
processor
that
aims
to
compete
with
intel,
xeon
and
amd's
epic.
A
Okay,
yes-
and
I
I
so
I
added
there-
was
a
pull
request
that
makes
changes
to
compile
argo,
cdo
and
pp
on
this
platform,
but
it's
awesome,
but
I
know
that
we
will
break
it
pretty
soon,
so
I
feel
like
if
we
agree
to
do
it.
That
means
we're
kind
of
committing
to
I
mean
we're
saying:
yes,
we
should
one
day
have
a
ci
for
for.
C
Yeah,
I
think
there
are
many
other
things
to
consider,
because
I
have
I
have
looked
into
this
and,
for
example,
customized.
They
don't
have
any
binaries
for
for
power,
pc,
okay,.
D
C
This
is
this
is
basically
we.
We
would
also
have
to
build
customized
binaries
then
or
go
to
the
customized
people
and
kindly
ask
them:
hey
we're
shipping,
your
binaries
and
we're
shipping
powerpc
images,
and
would
you
be
so
kind
to
provide
us,
but
I
think
in
general
we
if,
if
there's
demand
for
powerpc
platform,
we
can,
we
can
say:
okay,
that's
something
we
want
to
do,
but
the
details
have
to
be
figured
out
later
right.
So
I
I
mean
what
we,
what
we
should
avoid
is
cross
compiling
on
github
actions,
yeah.
D
C
This
this
is
this
is
this
is
not
going
to
work,
especially
if
you,
if
you
go
and
build,
the
images
like
with
with
docker
x
or
with
with
builder,
has
support
for
cross-platform
builds
as
well,
but
they
take
like
ages
to
to
cross-compile.
A
C
Yeah
I
mean
this.
I
think
this
would
need.
Maybe,
like
you
said
at
the
beginning,
you
know
this.
I
think
this
is
something
that
would
require
a
fully
fledged
proposal.
Okay,.
C
Because
yeah
all
the
details
need
to
be
figured
out
and
they
need
someone
to
donate
the
build
infrastructure.
For
that,
and
probably
that's
the
same
for
the
army
images
as
well.
A
Okay,
that
sounds
good,
so
we
can
move
it
into
needs
discussion
and
we
yeah.
We
run
out
of
time
there.
It
is
yeah
and
we
know
that
basically,
it
took
us
10
minutes
to
talk
about
four
of
these.
So
it's
not
as
easy
as
we
expected
like
before.
I
think
assumption
was
that
we
spent
literally
a
minute
on
each
and
every
and
quickly
move
them
back
and
forth.
It's
not
the
case,
so
yeah.
C
A
I
feel
like,
I
think,
let's
get
back
to
it
in
the
next
meeting,
and
maybe
we
can
maybe
it's
okay,
like
I
didn't
try
to
I
added
here.
That
list
has
issues
for
longer
than
a
week.
So
it's
like
several
weeks
of
feature
requests
and
I
think
our
goal
is
just
to
catch
up
with
you
know
with
one
week
because
we
have
been
meeting
once
a
week.
A
A
C
Yeah,
I
think
I
forgot
I
was
I
was
this
week
right,
yeah
and
I've
seen
it
in
the
document.
I
was
marked
and
bold,
so
I
didn't
do
anything
so
I
just
take
the
the
week
the
coming
week.