►
From YouTube: Argo Contributor Experience Office Hour 14th Jan 2020
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
So
so
far,
only
two
topics
were
proposed.
One
is
by
me:
I
wanted
to
talk
about
argo,
cd,
old
pull
requests
and
basically
we
can
decide
what
we
want
to
do
with
some
of
good
old
old,
but
good
pies,
and
then
next
we
worked
recently
on
reorganizing
argo,
cd,
binaries
and
basically
the
discussion
happened
mostly
within
intuit
team,
and
we
wanted
to
share
what
we
decided
to
do
and
what
we're
proposing
to
do
with
the
community
so
and
I'm
going
to
jump
to
the
first
topic
which
I
wanted
to
discuss.
A
So
as
you
might
notice
that
we
have
a
lot
of
outstanding
prs
like
62,
open
cars
and
most
of
them
are
kind
of
old
and
hard
to
merge,
and
so
we
would
kind
of
we
do
this
treasuring
process
every
day
and
we
trying
to
at
least
currently
review
new
pairs.
But
this
one's
kind
of
just
hanging
here
and
basically
we
were
thinking
to
just
close
them,
because
it's
really
hard
to
unlikely.
We
can
find
contributors
who
created
these
pairs
like
a
year
ago.
A
A
A
I
started
working
on
this
as
an
experiment
just
to
see
what
it
takes
and
apparently
it's
not
that
bad.
So
I'm
pretty
sure
I'm
going
to
either
take
over
this
pr
or
push
my
basically
changes
for
my
own
comments
into
the
fork
of
this
contributor,
and
this
is
basically
one
way
to
you-
know
kind
of
get
rid
of
that
pr,
but
not
close
it
and
instead
merge
it
kind
of
complete
it
and
merge
it
into
argo,
cd
yeah.
A
B
A
Yes,
yes,
you're
right
and
I
feel
like
it's
almost
this
same
amount
of
work.
If
you
reach
out
to
that
person,
but
to
reach
out
get
a
new
portion
of
improvements
and
then
forget
about
again
about
that
that
they
are
so
to
me
it
it's
basically
the
same
amount
of
work,
yeah
you're
right,
it's
yeah,
let's
let's
say
either,
take
over
or
reach
out
and
work
with
original
contributor
or
close
yeah.
So
but
it's
kind
of
yeah
to
me.
It's
almost
the
same
decision.
A
And
I
feel
like
we
kind
of
I'm
pretty
sure
everyone
agree,
that
we
want
to
merge
good
peers,
it's
just
yeah
we're
looking
for
volunteers
and
I'm
kind
of
I
I
pretty
much
volunteered
to
work
on
this
one
already
and
yeah.
So
if
anyone
who
wants
to
help
that
would
be
useful
and
pretty
much
at
least
like
all
of
most
of
these,
those
pr's
are
good
and
we
can.
A
Yeah,
maybe
I
don't
know
the
best
way
how
to
there
are
some
pr's
that
that
are
not
going
to
be
merged
and
sitting
there,
because
you
know
there
was
some
discussion
and
basically,
we
kind
of
disagreed
with
the
proposal
and
didn't
close
pr
these
ones.
We
should
close.
I
think
right
away
and
remaining.
A
A
B
Yeah
and
and
how
will
we
make
the
decision,
whether
to
to
close,
close
it
or
to
further
work
on
it?
So,
for
my
part,
I
can
say,
I
see
one
of
mine
there.
I
think
it's,
that's
that's
one
to
close,
it's,
it's
quite
intrusive
change
and
I
think,
with
the
with
the
same
side
cookie,
we
mitigated
the
csrf.
B
Attack
vector
almost
to
zero,
so
this
this
one
is,
I
think,
if
it
if
it,
if
I
would
think
it's
important
and
useful,
I
would
have
completed
it
by
now.
So
contact
with.
A
B
We
should
make
decision
for
each
figure.
Can
we
can
we
maybe
put
up
a
doodle
or
something
like
that?
You
know
a
voting.
I
mean
leverage
github
to
do
reporting,
there's
no,
some
some
some
external
tools.
So
just
like
I
don't
know
if
people
want
to
vote.
A
Yeah
I'm
open
to.
Basically
I
don't
know
what
tool
we
could
use.
Google
docs
is
the
simplest
possible
one.
You
know
we
just
kind
of
bought
using
comments
if
there
is
better
one.
Okay,
no,
no
make
sense.
A
Okay,
then
let
me
yeah,
so
maybe
can
we
chat
again
offline
if
you
know
that
tool
that
you're
referring
to
we
could
the
tool?
If
not,
then
google
doc
will
work,
I
mean
it.
Will
it
won't
be
perfect,
but
it
can
yeah
and
then
I
think,
we'll
just
try
to
kind
of
in
some
free
form,
put
our
thoughts
and
explain
why
the
pr
has
to
be
closed
and
yeah,
and
then
next
week
we
will
have
it's
going
to
be
pretty
much.
A
It's
like
it's
pretty
much
our
backlog
and
but
good
thing
about
that
backlog
is
that
there
is
already
useful
discussion
and
some
design
decisions
were
made
which
closed
into
the
plus
step
to
merge
the
pair.
A
E
So
as
part
of
new
feature,
we
are
reorganizing
the
binaries
in
order
to
reduce
the
image
size.
So
the
idea
was
to
merge
all
the
backend
binaries
into
single
binary,
which
would
also
include
the
ago
cd
cli
image
and
to
and
to
split
out
the
dex
wrapper
from
the
argo
cd
url
and
move
it
to
the
back
in
binary
in
order
to
save
the
space.
E
So
after
we
the
suggestion
from
the
yarn
on
the
busy
box
approach,
so
what
how
it
works
is
a
single
binary
can
behave
differently
depending
on
how
it
is
being
called
so
based
on
the
symbols.
It
can
change
its
behavior.
So
finally,
we
decide
we
we
propose.
We
we
are
proposing
that
we
would
merge
all
the
binaries,
that
is,
argo,
cdcli,
util
server,
application
controller
and
the
repo
server
into
one
single
binary.
E
So
what
it
would
do
is
so
right
now,
each
one
each
one
of
these
binary
is
approximately
70
megabyte.
So
if
we
come
like,
if
we
combine
all
like,
if
instead
of
building
seven
binaries,
we
build
one,
it
would
save
us
approximately
420
megabytes
of
image,
size
and-
and
it
would
also
reduce
the
build
time.
So,
instead
of
building
seven
main
dot
go
files,
we
would
be
building
only
one
and
also
we
would
be
moving
the
decks
from
our
logo,
cd
uter
to
a
new
command.
E
E
If
I
can
call
the
binary
as
our
go
cd
repo
server,
then
it
would
behave
as
the
repo
server
and
so
on,
like
just
the
argo
cd,
then
it
would
behave
as
as
the
cli
augustine
image.
E
A
And
I
wanted
to
highlight
that
our
so
as
sharma
mentioned,
there
are
basically
two
ways
you
can
control,
how
binary
behaves.
One
is
environment,
variable
and
second,
just
the
name
of
the
binary
itself.
So
end
users
won't
notice
any
difference
because
we're
going
to
create
symlinks
with
different
names.
Basically,
it
will
look
like
we
still
have
seven
binaries,
but
in
reality
they
are
all
going
to
be
sim
links,
but
developers
will
be
affected.
A
We
will
have
to
use
that
environment
variable
so
because
now
we
have
seven
main.gov
files
and
each
main
will
go
kind
of
knows
what
to
do
after
pair
is
merged.
There
will
be
just
one
main.go
file
and
it's
of
course
painful
to
create
symlinks
because-
and
you
want
to
use
basically
go
run
to
develop
and
as
a
workaround
there
is
this
environment
variable.
D
A
D
Okay,
yeah,
that's
the
most
likely
scenario:
it's
like
someone
downloads,
the
c
binary
and
then
renames
it
because
I
sometimes
like
I'll
rename.
Oh
I
like
this
version,
1.7
I
want
to
keep
that
around
because
it
has
it
and
I'll
rename
it
ago,
cd,
oh
yeah,
or
something
I.
D
Exactly-
and
they
won't
do
that
for
like
repo
server
or
back-end
stuff,
okay
yeah-
they
might
do-
I
don't
know
they
might
deal
with
aggro
city
util,
but
that's
probably
not
a
case
we
care
about.
I
guess,
will
figure
that
out.
B
A
Sub
commands
yeah,
so
the
the
original
goal
was
to
kind
of
merge
all
the
binaries
into
one,
and
the
reason
is
because
each
binary
pretty
much
has
the
same
code,
which
is
golden
standard,
govern
gold
and
current
time,
plus
kubernetes
client,
which
we
import.
So
this
is
why
each
binary
is
quite
big,
but
it
has
the
same
same
code.
So
if
we
merge
them
into
one,
we
save
a
lot
of
disk
space
plus
we
don't
have
to
build
the
same
binary,
same
goal
and
code
again
and
again
yeah.
A
So
we,
if
we
merge
them
into
one
next
problem,
is
how
do
we
preserve
all
behavior
so
and
in
sharma's
pr
there
is
a
code
which
checks
how
the
binary
name.
Basically.
So
if
binary
name
looks
like
argo
cd
server,
then
it
behaves
like
argo,
cd
server
so
and
finally,
to
answer
your
question:
environment
variables
are
for
us
for
developers,
it's
kind
of
a
shortcut
to
change
quickly.
A
G
Yeah
cool,
my
bad
is
working
now
kind
of
just
thinking
about
it
because
you
can
do
go
run
just
I'm
just
looking
at
the
pr
right
now.
So
it's
like
you
can
do,
go
run
space,
argo,
cd,
repo
server,
just
as
an
example
and
then
pass
whatever
flags
that
you
want
from
there.
So
I
was
just
curious
why
the
decision
was
made
to
use
environment
variables
versus
just
kind
of
like
a
normal
sub
command
understood.
Yes,
that's.
A
At
least
for
I
think
we
could
do
it
for
back-end
clies,
but
we,
it
would
be
strange
like
if
we
package
everything
into
one
binary,
then
user
and
and
if
we
use
sub
commands
user
would
have
to
deal
with
client
side,
sub
commands
and
server
side
sub
commands.
So,
instead
of
just
typing
argo,
cd
up,
create
user
would
have
to
say
argo
cd,
client
app
create
so
just
to
get
rid
of
that
client.
We
wanted
to
use
environment
variables
because
yeah.
G
Basically,
to
improve
user
experience
gotcha
if
you're
interested,
I
do
have
an
idea
how
to
work
around
that,
but
I
don't
want
to
like
muddy
up
the
the
meeting.
G
A
C
D
I
guess
use
cases,
so
the
first
one
is
that
upgrading
to
this
new
style,
like
I
have
a
repo
server
from
1.8
and
then
and
1.9
will
have
this
new
feature
right
when
we
would
like
the
the
existing
repo
servers
not
to
change
how
they
are
involved
from
the
deployment
manifest
like
the
pod
spec
for
the
command
and
args.
D
It
should
still
be
argo,
cd,
repo
server
and
then
whatever
the
the
flags,
are
to
start
the
server
so
that
that
will
be
taken
care
of
this
sim
linking
approach.
Then
there's
the
the
developer
like
when
you
just
say,
make
start
or
make
test
dd
or,
like
all
those
developer
use
case.
D
That
experience
is
the
one
that
we
don't
necessarily
need
to
optimize
for
the
best
experience,
because
really
that's
just
the
you're,
either
doing
an
environment
variable
with
the
binary,
the
version
that
you
want
to
run
in
or
you're
using
a
sub
command,
the
user
end
users
never
actually.
D
Experience
that
only
the
maintainers
or
contributors,
I
should
say
to
the
project,
and
rather
than
having
like
a
different
ways
to
achieve
this
same
thing,
I
like
sub
command
or
sim
link.
I
think
there
would
be
three
different
ways
right.
If
we
were
to
do
this,
I
think
we
should
reduce
the
number
of
ways
to.
D
I
was
actually
against
environment
variables
initially,
and
then
I
did
then
I
felt
like
there
might
be
too
many
different
ways
to
invoke
the
binary
like.
Sometimes
a
sub
command
is
in
place
and
then
other
times
it's
not
in
place,
so
it
felt
like
the
the
environment
variable
would
at
least
give
you
a
consistent,
cli
experience,
because
you
know
the
second
word
of
your
command
is
going
to
be
the
command
specific
to
a
binary.
A
And
to
kind
of
clarify,
let's
say
this
pr
is
merged.
Now
we
would
have
to
so.
If
you
use
gorman
to
start
service
or
make
commands,
then
basically
you
have
you
don't
have
to
do
anything
because
we
will.
You
know
this
pr
will
preset
these
environment
variables
in
in
the
script.
But
if
you
use
let's
say
intellij
or
golang
to
start
the
repo
server
for
example,
then
you
just
need
to
modify
your
launch
configuration
and
add
one
more
environment
variable
once
and
kind
of,
and
then
just
forget
about
it.
A
A
H
What
is
the
current
size
again,
like
does
on
like
the
client
just
decline?
How
big
is
the
client.
H
Yeah,
I
tend
to
think
maybe
we
can
have
a
client,
the
argo
cd
command,
so
the
user
can
continue
renaming
to
version
that
that
they
like
so
and
then
we
can.
We
can
merge
the
servers,
the
server,
then
you
can
combine
it
with
one.
H
So
yeah
you
can
use
sub
command
or
you
can
do.
Oh
there's
only
on
this
other
server.
So
probably
you
just
don't
even
see
it
if
it
is
yeah,
so
the
power
subcommand
probably
make
more
sense
on
the
server.
I
think
that
way
you
have.
Okay,
you.
You
reduce
your
total
size
together,
but
you
know
it
doesn't
really
have.
C
H
D
So
so,
with
the
unified
binary
for
all
all
six
tools
for
seven
six
tools,
the
user
will
be
able
to
rename
their
file.
So
in
other
words,
they
won't
notice
any
difference
in
the
experience,
because,
when
we're
going
to
default
the
behavior
like,
if
the
binary
is
named
weirdly
it
will,
it
will
act
as
the
client.
The
only
difference
the
user
would
see
is
that
it's
inflated
by
10
megabytes,
but.
A
It's
still
that
was
motivation
to
start
merging
is
because
so
we
needed
to.
If
we
want
to
make
argo
cd,
util
kind
of
famous,
then
we
should
start
publishing
it
as
a
release.
A
Artifact
so-
and
I
think
you
merged
that
pr-
you
approved
it
recently,
so
we
started
building
basically
three
more
binaries
in
ci,
and
then
we
realized,
oh
okay,
like
we're
building
the
same
code
so
many
times
so
argo
cd
client
we
built
three
times
into
for
windows
for
linux,
for
mac
are
good
util
for
linux,
for
windows
for
mac
and
then
several
back-end,
binaries
yeah.
So
now
it's
if
it's
just
the
one
kind
of
fred
penny
which
includes
everything
we
can
build
it
once.
A
B
Yeah,
but
so
if
someone
uses
the
argo
cd
util
and
we
are
all
agreeing
on
that,
the
users
will
be
using
it
more
and
more
in
the
in
the
future,
because
we
are
giving
some
more
features
so
now
the
users
they
just
cannot
rename
their
binary
as
they
want,
because
otherwise
they'll
get
aggro
cd
cli.
A
Yeah
and
oh,
you
think
now
user
lose
ability
to
kind
of
rename
rcd
sorry
to
rename.
B
D
Consequences
you
we
basically
have
two
user-facing
clies
that
are
affected
by
how
they're
named.
A
I
think
augustine
util
is
kind
of
it's
for
people
who
know
what
they're
doing.
D
Choose
your
way
to
the
pro
problem
by
guessing
what
the
their
intent
is
based
on
the
binary
name
right,
if,
if
the
argo
cdu
does
incorporate
into
them,
if
you're
I
know
okay,
I
don't
recognize
this
binary
name.
Well.
If
it
has
argo
cd
law,
it
probably
means
they
want
to
run
it
in
the
util
fashion
and
not
the
the
client
doesn't
want
the
lcd
but
yeah.
I
think
these
are
probably
discussions
we
can
take.
I
think
we
all
agree.
D
We
should
merge
the
back
end
binaries
right
and
I
think
there
is
debate
about
whether
the
clients
should
merge.
I
had
to
actually
my
thought
process
was
actually
the
exact
same
as
a
lot
of
the
ones.
I
think
I'm
hearing
like
I.
I
originally
said
how?
How
are
you
going
to
make
the
client
side
one
unified,
because
you're
going
to
upload
the
same
binary
multiple
times
just
with
different
names,
when
in
the
as
a
release,
artifact
and
alex
said
yeah?
D
That's
I
mean
why
should
the
user
care
that
it's
it's
actually
the
same
release
artifact
just
renamed
in
our
downloads
and
that's
a
good
point
like
they
shouldn't
care?
It's.
I.
A
I
thought
about
it
too,
and
I
feel
like
now
we
upload
technically
two
different
binaries,
but
they
are
99
the
same
and
just
one
percent
is
that
switch
which
says
oh
you're,
supposed
to
use
this
set
of
commands?
Not
this
and
that's
why
I
was
thinking
like
why.
Why
don't
we
watch
them
and
basically
get
rid
of
so
much
repetition
in
our
image.
A
But
I
think
it's
worth
to
you
know,
discuss
how
to
make
sure
that
user
experience
is
good.
I
agree
about
the
point
that
argo
cd
util
might
cause
problems,
and
maybe
we
can
add
objects
right
into
the
cli
and
explain
to
user
how
he
can
switch
between
options
like
yeah.
H
Maybe
we
should
merge
the
the
command
line
like
why
we
would
have
separate
like
ago,
city,
yoto
and
rc,
maybe
maybe
which.
D
Immersed
that
them
that's
a
that's
a
separate
topic,
we
can
discuss
about
the
combining
those
the
reason
it
was
at
least
for
now
kept
separate
was
a
lot
of
the
functionality
of
the
util
was
really
intended
for
operators.
People
have
access
to
the
namespace
of
the
control
plane,
argo
cd.
D
And
then,
whereas
the
re,
all
the
other
argo
cds
are
actually
more
end
user
operations
who
are
managing
their
apps,
there's,
there's
yeah
there's
an
argument
that
you
can
make
about.
Maybe
all
the
operators
actually
go
and
you
know
operate
their
sub
command,
and
so
you
only
have
one
cli
that
that
that
could
be
an
option.
But,
okay,
I
I
thought
exposing
users
to
operators
stuff
might.
H
H
We
can
there's
a
way
he
should
document
it.
C
H
This
set
of
command
is
for
for
different,
different
audience,
either
way.
It
looks
like
it's
in
the
binary
right,
yeah.
D
Okay
but
yeah,
I
think
that
also
the
util.
We
expect
it
to
kind
of
keep
changing
and
breaking
and
and
whereas
the
cli
we
expect
people
are
going
to
rely
on
that
for
automation
and
scripts
like
for
as
a
stable
thing
and
the
util
was
actually
meant
for
operators,
but
that
that
that's
evolving
because
peop
we
are
now
going
to
start
encouraging
operators
to
use
util,
for
you
know,
declarative
management
of
configuration
like
convenience
stuff,
so
so
yeah.
It's
something
to
reconsider.
A
A
A
D
A
Think
about
okay:
this
is
actually
that's
the
end
of
our
list.
We
don't
have
any
more
topics
and
if
anything,
one
wants
to
discuss
on
flake.
A
And
all
right
so
yeah,
if
there
is
nothing
else,
we
can
finish
our
day
today
again.