►
From YouTube: Argo Contributor Experience Office Hour 18th Mar 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,
hello,
everyone
happy
first
day
today
is
our
next
contributor
contributors
meeting.
So
let
me
start
from
sharing
my
screen
and
we
had
a
lot
of
topics
today
and
I
think
tropical
even
had
to
get
you
know,
remove
some
topics
because
they
won't
fit.
A
Okay,
if
he's
not
here,
I
just
wanted
to
you
know
again
talk
about
to
do,
release
and
testing,
so
I
finally
created
the
document
like
we
did
last
time
so
and
we
have
300
commits
and
most
of
those
commits.
A
You
know
regressions
that
we
introduced
and
fixed
get
rid
of
all
documentation,
changes
and
only
features
and
bug
fixes
of
previous.
You
know
bugs
introduced
in
previous
releases
are
here,
and
here
we
have
around
130
kind
of
testable
items
so
and
that's
a
lot
and
I
kind
of
to
make
it
a
little
easier.
A
I
group
them
by
you
know
by
category,
so
we
have
core
functionality,
changes
such
as
difficult
syncing,
then
cli
features
features
related
to
helm,
customize
ui
and
you
know,
and
others
so,
and
I'm
just
proposing
to
everyone
who
who
wants
to
participate.
Just
add
your
name
here
and
we
simply
use
this.
You
know
cells
to
kind
of
it's
pretty
much
treated
as
your
own
notes
and
there
is
no
like
streaks
format,
but
basically
I
would
do
what
my
is
doing
right
now.
A
A
Yes
and
about
the
time
so
basically,
I
think
I'm
at
like
three
evenings
in
a
row
and
attempting
to
create
release
candidate
and
every
time
a
bulk
was
found
so
basically
release
candidate
is
not
yet
ready,
but
yesterday,
when,
finally,
it
went
smooth
and
what
I
did,
I
just
deployed
it
to
some
internal
instances
and
it's
kind
of
pretty
testing
before
creating
release
candidate
high
chance
that
will
be
created
today
evening.
Finally,.
C
The
url
to
this
spreadsheet
is
in
the
is
in
the
agenda
right.
D
A
I
I
think
I
will
you
know,
put
it
in
slack
one
more
time,
because
maybe
not
everyone
who
is
in
slack
in
that
meeting
enable
awesome.
Yeah
thanks
was
the
thing
yeah.
Actually
that's
it.
That's
the
short
update
and
I
feel
like
okay,
just
maybe
one
thing
so.
A
One
bug
which
is
here
by
the
way
it's
supposed
to
be
tested,
so
we
try
to
improve
a
ui
responsiveness
and
we
try
to
switch
to
streaming
api,
and
it
kind
of
that
was
one
of
the
reasons
why
I
could
not
create
release
candidates.
Basically,
the
changes
which
we
did
didn't
work
well
in
real
production
cluster
and
I
had
to
revert
it,
but
it's
not
really
worth
mentioning
here.
A
I
think
I
should
just
add
a
comment
next
to
the
one
of
those
items
but
yeah,
so
it
feels
like
a
2.0
is
ready,
like
you
cannot
name
a
single
blocking
bug
which
I,
which
I'm
aware
of
right
now.
A
D
Yeah,
this
is
very
quick
and
basically
recently
a
few
of
us
have
gone
through
this
security
assessment
and
we
identified
a
few
items.
They
should
be
fixed
in
2.0
and
we
already
opened
the
pr
submitted
the
fix
and
also
we
identified
a
few
items
that
should
be
fixed
in
the
future
releases.
So
I
open
the
issues
for
those
accordingly
already,
so
I
just
want
to
know
if
anybody
else
is
also
working
on
any
security
related
issues
and
that
is
planned
for
2.0.
D
C
There's
some
there's
some
ongoing
change.
I
don't
know
if
it's
targeted
for
2-0
the
gls
to
redis
features,
and
so
I
think
livio
costa
approached
me
and
he
wanted
like
to
work
on
this.
C
So
I
I
said
sure
go
ahead
and
I
pointed
him
to
the
recent
ripple
server
tls
change
and
asked
him
to
so
to
to
use
that
as
a
kind
of
blueprint
so
that
the
user
experience
will
be
similar.
C
A
C
A
A
B
B
A
And
I
feel
like
just
for
context
so
for
argo
graduation.
We
have
to
go
through
security
review
and
that
list
is
not
you
know.
A
So
a
few
things
were
found
and
obviously
we
don't
publish
you
know,
security
related
issues
and
unless
they're
you
know
safe
to
disclosure
and
what
made
it
she
created
issues
for
all
issues
which
are
not
really,
you
know
vulnerabilities
and
maybe
it
makes
sense
to
apply
a
label-
and
you
know
so,
okay
and
it's
important
to
fix
those
things,
because
it
will
help
with
argo
cd,
graduation.
So.
A
Fix
like
high
critical
vulnerabilities
must
be
fixed.
Everything
else
is
optional,
but
the
more
we
fix
the
better
and
and
yeah.
So
basically,
I.
A
E
A
A
B
Yeah,
but
I
mean,
if
I
mean,
if
it's
too
critical,
it
probably
will
not
have
an
issue.
You'll
have
a
pr
directly
yeah,
so
I
think
that's
what
it
would
be.
So
so
I
have
a
quick
question.
May
I
see
a
I
saw
one
fix
that
you
put
in
you
know
where
we
wanted
to
remove
a
lot
of
privilege
escalation
through
my
my
quick
question
would
be.
Did
you
run
the
manifest
through
a
tool
that
asked
you
to
do
so
or
was
that,
like
a
manual
inspection
that.
A
B
Right
so
so,
do
we
have
a
tool
in
our
ci
which
ensures
our
manifests
are
good.
So
I
think
my
recommendation
and
I
have
been
looking
at
it
for
a
while.
We
could
use
stack,
rocks,
cube
linter.
They
do
verify
whether
your
manifests,
don't
do
anything
nasty.
B
It
has
a
lot
of
logic
built
inside
for
you
to
not
make
mistakes
which
are
probably
legal
in
kubernetes,
but
not
legal
from
a
security
standpoint.
We
could
probably
introduce
one
such
thing
in
rci.
A
C
B
I
mean
with
with
cubelinder.
You
can
actually
like
turn
a
lot
of
knobs
to
ensure
that
you
only
look
for.
C
B
Yeah
and
and
just
a
quick
note-
and
this
is
not
related,
but
so
I've
been
working
with
that
team-
the
cubelinder
team
for
the
last
couple
of
weeks.
So
if
there
are
any
changes
that
we
need
in
cubelinter
itself,
I
can
help
influence
those
changes
in
so
just
calling
it
out.
A
C
Okay,
thank
you
all
right.
So
abhishek
is.
F
Yeah,
sorry,
sorry,
for
joining
late,
I
was
just
confused
with
the
daylight
saving
yeah.
Coming
to
the
issue
softly,
we
are
seeing
many
issues
on
users
raising
many
issues
on
argo
cd,
that
their
logging
tools,
maybe
cabana
or
stackdriver
on
gcp,
so
they
are
unable.
To
I
mean
most
of
all,
the
locks
in
august
are
by
default
to
send
by
default
set
to
hdr.
So
what
happens
is
that
they
would
see
even
the
info
logs
in
stdr
and
the
logging
tool
reports
severity.
F
So
we
have
taken
up
this
issue
and
I
have
looked
into
different.
F
I
mean
the
predominant
logging
tool
that
we
are
using
is
logress
and
I
looked
into
the
community
and
the
maintainers
of
the
loggers
are
not
actually
showing
interest
to
take
this
as
an
enhancement
that
they
do
not
want
to
split
logs
into
different
streams.
So
they
do
recommend
two
different
approaches.
One
is
to
use
hooks
or
the
other
thing
is
to
write
a
wrapper
wrapper
over
it.
F
So
I
try
to
implement
both
of
them
in
argo,
but
what
I
figured
out
is
that
more
or
less
they
would
actually
add
up
more
performance
degradation
because
you're
adding
a
new
you're,
adding
one
more
step
to
it.
So
this
particular
enhancement
request
is
actually
a
kind
of
a
question
and
enhancement
request
that,
should
we
consider
a
new
login
tool,
I'm
not
sure
which
one
it
is
because
currently
logres
and
g
log,
both
of
them
go
log.
F
Both
of
them
do
not
support
separate
log
streams
or
do
we
proceed
with
writing
a
wrapper.
So
I
thought
this
is
a
good
discussion
to
bring
on
rather
than
yeah.
A
F
When
we
write
an
album
yeah
so
when
we
write
a
wrapper
as
per
the
recommendation
from
loggers,
what
happens
is
that
it
adds
one
more
step
so
before
every
time
before
logging.
So
you
just
have
to
identify
the
log
level
and
then
it
has
to
send
it
to
the
appropriate
stream.
So
I'm
not
sure
I
mean
I
haven't
tested
it
it
with
many
applications,
but
so
more
or
less
it
would
definitely
add
some
kind
of
an
extra
layer.
You
got
it,
so
it
basically
would
be.
You
know,
delay
introduced.
C
Yeah,
I
think
so.
The
the
question
is
valid.
That
abhishek
has
brought
up
so
whether
whether
we
want
to
move
away
from
logarithms
because
the
project
itself,
they
say
they
are
in
maintenance
mode
right
and
they
don't
implement
any
new
features.
Only
critical
bug
fixes
and
even
they
recommend
other
go
libraries
to
use
for
logging.
F
Okay
yeah,
the
main
problem
is:
there
are
already
pull
requests
that
are
raised
to
solve
this
problem
into
logarithms,
but
they
do
not.
I
mean
they
seem
to
show
a
definite
towards
it
and
they
still
consider
that
logging.
Everything
to
stdr
is
the
right
approach,
so
more
or
less.
There
are
different
discussions
over
it,
but
yeah
as
so.
We
need
to
take
a
decision.
Should
we
write
a
wrapper,
or
should
we
look
into
a
new
log
tool?
F
A
It
feels
to
me
that
new
new
look
tool
is
is
better
because
you
know
wrapper
would
be
basically
we
will
be
have.
We
would
be
writing
our
own
log
tool.
Yeah
almost
like
I
mean
they.
I
don't
see
a
big
difference
between
wrapper
and
totally
new.
Look
too
yeah
so
and
it's
better
to
just
choose
something.
A
A
Error
and
reason
is,
you
know,
cli
typically
produce
some
output
to
it
out,
it
could
be
yaml
that
have
to
be
passed
and
logs
would
pollute
that
output
and
basically
because
we,
if
we
send
it
to
you,
know
if
we
send
logs,
you
know,
warnings
and
errors
into
stdr,
then
steady
out
is
kind
of
clean,
so
in
cli
we
might
want
to
keep
sending
logs
to
sdgr.
F
A
C
It's
obviously
a
lot
of
work
so
and
the
what
what
I
see
is
the
only
downside
is
so
when
people
already
set
up
some
some
lock
passes
in
their
systems
right,
they
would
have
to
re
reinvent
them
as
well.
So
this
this
will
basically
be
a
not
so
obvious
breaking
change
all
right.
A
G
B
F
No
jonathan,
so
the
upside
would
be
so
the
customers
who
are
looking
at
the
logging
tools
to
understand
if
they're
getting
any
errors
or
they
are
normal
locks.
So,
for
example,
most
of
the
customers
might
look
at
stackdriver
and
understand.
Okay,
this
is
an
error
log
or
this
is
a
normal
log.
So
now
what
happens
with
the
current
approach
is
that
they
would
see
most
of
the
logs
in
the
error
state.
C
Yeah
and
also
so
another
upset,
so
logrus
is
so
they
say
themselves,
they
are
deprecated
right.
They
are,
they
basically
say
we
don't
progress
on
this
project
any
further.
So
right
only
thing
they
they
they
will
do,
is
yeah
critical
bug,
fixes
like
security
issues
or
something
like
that,
and
I
think
they
are
not
not
very
interested
in
in
maintaining
locrus
anymore.
So.
G
That
makes
sense
kind
of
seems
like
there's
two
orthogonal
orthogonal
issues.
One
is
changing
the
framework
which
you
know.
It
can't
hurt
too
much
to
move
to
a
supported
log
framework
from
an
unsupported
one,
and
then
the
other
one
would
be
whether
or
not
to
log
to
standard
error.
It
does
make
sense
that
the
ability
to
see
to
have
some
log
statements
coded
as
standard
error
would
be
beneficial.
I
think,
in
some
cases,
you're
getting
log
statements
that
are
json
that
are
tagged
with
error
codes.
Anyways,
maybe
not
everybody
does
that.
G
However,
I'd
also
be
curious.
Generally,
the
links
that
were
linked
in
that
issue
were
about
like
cli,
where
it
looked
like.
They
were
cli
applications
like
there's
one
from
new.org
there's
one
for
python,
rather
than
four
cloud
native
applications
that
are
running
on
a
cluster.
So
I'd
be
curious.
What
other
cube
applications
or
applications
that
are
cloud
focused
or
coupe
focused
that
tend
to
run
in
containers?
What
they're
doing
in
terms
of
logging
to
standard
error
versus
the
links
there,
which
are
more
cli,
focused.
F
Yeah
so
so
the
most
I
mean
docker
itself
is
using
logres.
So
I
I
looked
into
the
code.
They
seem
to
be
using
a
wrapper.
F
Most
of
the
docker,
so
I
looked
into
the
docker
organization
itself
and
their
predominant
logging
is
loggers.
So
I
can
I
can
I
can
look
into
more.
I
mean
I
can
look
more
deeper
into
it
and
probably.
G
A
A
Okay,
but
I
feel
like
everyone
is
on
the
same
page:
it's
kind
of
it's
a
change
and
we
should
do
a
careful
investigation
before
we
move
and
we
need
to
find
the
tool
and
requirements
of
the
tool
would
be.
I
guess
it
should
be
flexible
enough
to
you
know,
so
it
can
choose
between
stdr
cd
out
based
on
bulk
level
and
and
I
think
we
should
try
to
preserve
log
formatting.
C
F
Yeah
I
can,
I
can
look
into
the
and
probably
comment
on
the
same
enhancement
request
yeah.
I
I
agree
that
it's
not
an
easy
decision
to
take
and
I
would
probably
put
more
findings
on
this.
B
F
And
I
tried
week
actually
so
we
thought
we,
we
actually
wanted
to
get
this
into
2.0,
but
it
took
far
more
investigation.
Then
yeah.
B
D
B
Sense-
and
I
think
at
this
point
we
are
figuring
out
which
path
will
make
sense,
so
whether
we
should
be
using
logrus
or
something
like
logres
and
the
other
thing
with
jonathan
brought
up
that
whatever
we
go
for.
We
need
to
evaluate,
from
the
perspective
of
the
fact
that
it's
going
to
run
in
cluster
a
lot
of
the
kubernetes
tooling,
which
use
logarithms
like
things,
may
not
be
running
in
cluster.
B
B
A
B
B
But
in
short,
if
there
is
a
well-researched
decision
that
needs
to
be
made
with
a
good
documentation
of
why
specific
parts
were
not
taken,
we
should
have
an
enhancement
proposal
that
could
be
either
a
process,
oriented
proposal
that
could
be,
let's
say,
alex
just
kind
of
proposes
that
we
do
releases
differently
altogether
and
we
need
to
put
it
down
somewhere
in
documentation
so
that
people
can
argue
about
it
and
then,
in
the
end
we
disagree.
B
We
agree
to
disagree
on
some
things
and
we
agree
to
agree
on
the
rest.
So
in
general
it
could
be
a
process
thing
or
it
could
be
a
very
new
feature
that
we
want
to
bring
in
or
it
could
be
something
like
logs,
which
is
not
a
user
face
thing,
but
it
does
impact
our
code
base.
It
does
impact
admins,
it
does
impact
how
people
would
upgrade
their
systems.
B
So
that's
what
the
enhancement
proposal
process
is
about.
I
have
inherited
this
from
the
kubernetes
enhancement
proposal
and
the
open
shift.
B
Kubernetes
distribution,
which
is
the
upstream
of
openshift,
and
I
have
basically
slashed
a
lot
of
things
from
there
to
ensure
that
it
should
not
be
as
heavy
as
what
a
kubernetes
enhancement
proposal
is,
which
can
sometimes
take
six
to
eight
months
to
go
in
the
goal
of
this
is
this
should
not
increase
the
amount
of
time
it
takes
for
basic
innovation
to
take
place,
but
at
the
same
time
we
are
able
to
have
a
well
thought
out
descriptions
of
what
we
want
to
enhance
and
also
have
enough
implementation
details.
B
So
this
is
what
the
proposal
format
would
look
like.
Of
course
you
have
a
summary.
This
is
basically
a
tldr,
and
then
you
need
to
have
a
motivation,
which
means
you
explain
the.
Why
and
you
explain
what
are
the
non-goals
of
it?
For
example,
in
in
case
of
the
whole
logging
discussion,
we
are
having.
D
B
B
This
is,
then
you
have
the
proposal
section.
This
can
also
have
a
summary
and
then
the
use
cases
go
in
as
an
example.
In
this
case,
a
use
case
would
be
as
an
admin.
I
would
want
to
turn
on
only
error
logging
and
be
able
to
see
those
the
the
other
use
case
would
be.
I
want
to
use
external
tools
to
be
able
to
for
parse
these
logs
and
visualize
in
a
different
system
that
is
more
popular
in
the
kubernetes
as
well.
B
This
could
be
two
of
my
use
cases
that
we
have
implementation
details,
notes
constraints.
So
in
the
implementation
details
we
would
basically
need
to
talk
a
little
more
of
some,
some
of
things
that
we
were
discussing
now
that
what
is
the
impact
of
this
on
the
code
base?
How
would
this
look
like
when
we
ship
it,
which
means,
if
you're
saying
that
a
lock
formatting
changes?
That
means
that's
a
that's.
That's
an
implementation
detail.
B
So
that's,
basically,
what
are
the
risks
this
is
introducing,
and
how
are
we
mitigating
it
because,
of
course,
every
new
change
does
have
a
risk
based
on
all
the
changes,
of
course,
an
upgrade
downgrade
strategy,
which
means
a
quick
example.
A
probably
a
better
example
of
this
would
be
the
new
plugin
management
system
that
we
discussed
in
the
previous
meeting,
which
is
we
want
to
include
a
more
decoupled
way
of
having
a
run
time
base
for
things
like
helm,
customize.
B
An
upgrade
strategy
for
2.0
to
2.1
could
be
that
there
is
no
impact.
Helm
and
customize
still
gets
packaged
in
your
argo
cdu
repo
server.
But
if
you
wanted
to
move
it
out,
here's
how
we
would
let
you
do
it.
That's
one.
B
The
there
could
be
a
different
scenario
there,
which
is
saying
hey
in
the
next
version
of
argo
cd.
We
will
not
have
helm
customize
in
your
argo
cd
image
at
all.
It's
going
to
be
a
different
workload
altogether,
so
be
aware
that
this
is
going
to
introduce
the
number
of
workloads
that
you
have
on
your
system.
B
That's
one
and
the
other
could
be
some
pretty
pretty
dark
changes
which
means
hey.
This
is
a
breaking
change,
which
means
that
we
need
extreme
level
of
documentation
to
ensure
that
people
should
not
be
just
operating
on
go
cd
without
being
aware
of
this.
This
is
where
you
clearly
specify
that
between
versions
of
argo
cd,
there
is
going
to
be
an
impact
if
yes,
and
if
no
impact
great,
even
that
needs
to
be
written
out
and,
of
course,
that
there's
the
next
section
on
drawbacks
and
alternatives
here
is
basically
you
need
to
be.
B
The
devil's
advocate
saying
that
if
I
were
to
not
choose
this,
this
is
the
reason,
and
you
should
call
it
out
in
many
cases
you
may
not
be
your
own
devil's
advocate.
B
It
could
be
a
reviewer
who
calls
out
that
these
are
the
drawbacks
of
this,
not
a
blocker,
but
we
should
be
aware
that
this
is
a
drawback
and
we
should
ensure
that
drawbacks
should
be
documented
here
and
then,
of
course,
alternatives
is
about
to
ensure
that
here
are
the
other
ways
that
we
could
have
done
this,
why
those
ways
are
awesome
and
why
those
ways
were
not
taken
or
whether
you
would
want
to
consider
them
as
a
future
enhancement.
B
The
goal
is
a
lot
of
these
information
already
gets
poured
into
some
of
our
github
issues
today
or
in
meetings
or
in
different
conversations.
B
But
the
idea
of
having
the
national
proposal
is
to
ensure,
while
these
conversations
are
happening,
they
need
to
be
put
in
one
place
that
six
months
down
the
line
after
abhishek
has
moved
to.
Let's
say
log
grass,
I'm
not
saying
you
should
someone
should
come
and
say
hey.
Was
it
considered
that
logras
is
not
a
maintained
project
and
did
we
go
with
that?
In
spite
of
that?
B
If,
yes,
the
drawbacks
section
would
have
explained
that
hey
drawback
is
it's
not
well
maintained,
but
we
still
went
with
it
because
for
xyz
reasons,
the
the
goal
is
to
actually
ensure
all
those
things
are
documented
and,
like
I
said,
the
idea
is
a
lot
of
these
sections
get
would
get
populated
based
on
feedback.
We
get
from
others,
which
means
the
author
may
not
have
to
write
a
10-line
drawbacks.
The
author
may
have
just
a
couple
of
lines
of
drawbacks,
but
the
reviewers
may
add
in
more
same
with
alt
alternatives.
B
Jonathan
might
say:
hey
you
even
went
for
logarithms,
but
why
not
this
one
and
all
under
and
we
should
ensure
almost
every
alternative-
should
be
pointed
out
there
in
the
alternatives
that
comes
up.
You
may
even
put
in
people's
names
in
there
just
to
give
them
credits
on
it,
but
the
goal
is
that
if
these
discussions
have
taken
place
in
github
commons
discussions
prs
maybe
on
a
com
on
a
community
channel,
and
we
have
responded
to
those
alternatives
in
a
good
way.
B
We
should
be
documenting
them
in
the
enhancement
proposal
as
well
before
we
merge
it.
The
idea
is,
we
should
not
be
merging
the
enhancement
before
merging
the
enhancement
proposal,
just
to
ensure
that
all
key
decisions,
key
discussions
have
taken
place.
Key
stakeholders
are
satisfied
with
it.
B
Of
course,
this
is
not
to
be
used
as
a
way
for
blocking
new
enhancements.
Rather,
the
approach
should
be.
We
should
encourage
you
and
you
know
new
enhancement,
proposals
and
guide
them
in
the
right
direction,
with
the
community
that
we
have.
I
doubt
any
of
us
would
be
proposing
anything
so
groundbreaking
that
we
would
have
to
block
it.
E
E
The
goals
and
use
cases
were
so
right.
Yes,
this
is
a
good
improvement
over
the
process
and.
A
I
like
that
it
it
kind
of
provides
us.
You
know,
registry
of
basically
a
single
place
where
we
can
find
information,
because
I'm,
I
know
that
a
lot
of
you
know
reasons
of
multiple
design,
design
decisions
in
argo,
cd,
just
forgotten
right
now.
I
wish
we
had
that
before.
B
Right-
and
I
think
I'll
probably
add
to
this
a
little
more,
so
I
think
my
general
argument
about
not
starting
with
writing
things
out
on
github,
sometimes
is
that
you
know
hey.
You
know
it's
a
lot
easier
to
put
things
in
a
google
doc
tag,
people
for
comments,
etc.
So
my
general
suggestion
would
be.
I
wouldn't
want
to
make
this
a
very
breaking
process.
B
So
if
you
know
shama
has
put
in
a
google
doc
for
all
this,
I
think
that's
still
a
first
grade
step
and
then
we
have
a
meeting
where
we
discuss
all
this
and
then
when
we
know
that
the
doc
is
reasonably
mature,
it
doesn't
have
to
be
extremely
mature,
which
means,
let's
say
the
dock-
is
around
for
a
week.
You
know
five
of
us
have
reviewed,
then
I
think,
let's
put
it
out
on
a
pull
request
as
soon
as
possible.
B
It's
for
request
versus
an
issue
because
in
a
pull
request
you
can
comment
in
line,
whereas
in
an
issue
it's
hard
to
have
inline
comments
and
thread
discussion
threads,
the
goal
should
be
you
know,
no
discussion
should
go
undocumented
so,
which
means
before
the
google
doc
is
flooded
with
a
ton
of
comments.
B
We
need
to
put
it
in
github
just
so
that
every
comment
that
somebody
has
made
should
be
preserved
and
if
needed,
should
also
make
it
into
the
enhancement
proposal
in
the
alternatives
or
drawbacks
just
to
ensure
it
was
a
very
well
thought
out
decision
to
even
not
consider
some
alternatives
or
go
ahead
with
things.
Even
though
there
were
drawbacks
because
they
were
not
super
important.
Let's
say.
E
Yeah,
can
I
suggest
that
by
the
time
I'm
assuming
also,
we
would
want
to
present
these
in
the
broader
community,
meaning
right
right,
yeah.
So
can
I
suggest
by
the
time
that
happens
it?
It
needs
to
be
in
the
pull
request
so
that
you
know
the
broader
community
can
comment
and
stuff.
I
think
right.
You
know
when
we're
doing
it
with
amongst
the
contributors.
E
The
the
doc
is
is
fine
for
a
rapid
kind
of,
I
guess,
development
of
that
document,
and
then,
once
that
we
get
agreement
amongst
the
contributors,
then
we
formalize
it
into
the
pull
request.
What
do
you?
What
do
you
think
about.
B
D
B
Comments
on
google
doc
are
lost,
so
I
think
the
google
docs
should
be
the
initial
validation
that
hey
are
we
putting
these
things
correctly
in
the
right
places
once
it's
a
yes,
we
move
it
to
github
so
that
there's
not
a
significant
change
in
the
whole
structure,
but
then
the
idea
is
to
have
as
much
participation
in
github
as
possible,
just
so
that
we
can.
B
We
don't
lose
the
discussions
that
would
have
been
lost
in
a
google
doc
like
they
are
not
searchable
examples.
So
I
think
I
wouldn't
want
the
google
doc
to
be
absolutely
mature
before
we
move
things
here,
but
at
the
same
time
we
can
get
started
from
there
and
then
copy
paste
it
here
after
we
are
happy
with
it.
E
Okay,
that
that's
a
good
point.
I
think
I
think
we
can
then
move
that
requirement
up
to
by
the
time
it's
presented
in
contributors
meeting.
Then
it
preferred
format
is
in
a
pull
request.
Yeah.
B
I
mean
right
and
and-
and
I
think
one
other
thing
that
we
probably
should
like
since
jesse
you
brought
you
brought
up
the
wider
meeting.
I
think
one
other
thing
we
should
probably
call
out
is
that
this
doesn't
mean
that
you're
not
going
to
open
a
github
issue
with
that.
Here's,
the
thing
that
I
wish
we
do
as
an
enhancement
proposal,
especially
because
that's
a
very
lightweight
way
of
you
know
getting
in
future
requests.
B
Like
that's
a
feature
request.
We
should
call
that
but,
like
I
said,
like
somebody
may
not
have
the
bandwidth
or
even
the
understanding
to
go
in
and
put
in
a
deep
enhancement
proposal
like
like
somebody
might
like,
I
might
say,
hey,
I
want
a
decoupled
way
of
having
plugins,
but
I
may
not
be
able
to
go
and
expand
it
to
the
level.
Shma
has
expanded
it
in
the
google
docs.
So
we
still
should
encourage
that.
B
But
then,
if
somebody
is
willing
to
probably
contribute
a
little
more
level
of
detail,
we
say
hey,
you
know
it
looks
like
you
have.
You
have
a
lot
of
deep
opinions
on
this
of
how
this
should
work
between
upgrades?
How
this
should
be
implemented
that
looks
great
as
an
enhancement
proposal,
so
the
goal
is,
we
still,
you
know,
take
the
flurry
of
enhancement,
requests
that
we
get
as
github
issues
and
then
redirect
the
right
ones
to
enhancement
proposals
but
then
like.
If
somebody
says
we
want
better
logging
and
abhishek
picks
it
up.
B
I'm
gonna
say
abhishek
now
that
you've
picked
up
the
github
issue
for
working
on.
Could
you
open
an
enhancement
proposal
for
it
just
to
differentiate
the
fact
that
not
every
reporter
needs
to
open
up
a
request?
But
if
somebody
wants
to
open
it
is
it
has
a
pull
request
awesome,
but
implementers
definitely
have
to
open
a
pull
request
because
you're
going
to
have
the
most
amount
of
details
about
how
this
impacts
between
upgrades
you're
going
to
have
a
thought
process,
that's
going
to
be
very
different
than
somebody
who's
just
opened
a
feature
request.
A
B
Right,
I
I
I
think,
like
in
general,
it
would
be
nice
if
key
features
haven't
have
an
enhancement
proposal.
So
let's
say
you
could
have
an
enhancement
proposal
to
say
we
need
a
high
level
abstraction
that
would
take
care
of
deploying
applications
in
multiple
clusters.
That's
basically
application
sets
and
somebody
might
write
a
nice
essay
around
it
and
we
may
merge
it
saying
that.
Yes,
we
want
to
have
it,
but
that
doesn't
necessarily
mean
we
need
all
the
details
in
that
proposal
itself,
especially
because
it
has
to
be
worked
out
and
then
jonathan
goes
out.
B
Let's
say
jonathan
devon
goodwin
they
go
out
and
you
know
work
out
that
hey.
You
know
this
is
how
the
api
would
be
implemented.
This
is
what
the
impact
would
be
on:
the
existing
argo
cd
code
base,
etc.
I
think
that
can
be
a
separate,
an
enhancement
proposal,
because
it
has
a
lot
of
details,
decisions
that
have
to
be
documented
somewhere.
B
So
we
can
definitely
have
you
know,
a
very
lightweight
proposal
which
is
well
thought
out,
because
this
is
a
way
for
people
to
also
express
themselves
in
a
structured
way,
and
then
you
would
have
another
one
for
the
same
as
a
follow-up.
So
that's
that's
one
kind
of
you
know
enhancement
proposal.
B
Now
what
does
not
need
a
new
enhancement
proposal?
So
let's
say
you
want
to
introduce
a
new
sub
command
in
argo
cdcli
that
that
that
is
fairly
lightweight.
D
B
B
You're,
adding
a
new
flag
definitely
doesn't
need
an
enhancement
proposal
now
you're
breaking
a
flag
which
means
you're,
removing
a
flag
that
needs
an
enhancement
proposal
because
now
you're
impacting
existing
users
and
should
be
well
documented.
So
I
think
in
general,
everything
we
break
should
have
an
enhancement
proposal,
no
matter
how
light
or
heavy
that
is,
but
if
you're
we're
extending
something
like
like,
for
example,
in
this
case
I've
written
that
internally
refactors
a
coder
component.
B
You
may
argue
that
you
know
the
plug-in
mechanism
is
an
internal
refactor
to
some
extent,
but
at
the
same
time
it
does
introduce
how
your
port
spec
looks
like
that's
a
significant
change.
It
does
also
solve
the
problem
of
how
do
you
expand
to
new
plugins
without
having
to
building
them
into
your
code,
so
that
definitely
needs
an
an
enhancement
proposal,
but
in
general
I
would
say,
like
this
is
all
guidance,
but
in
the
end
the
project
leads
and
the
maintainers
need
to
take
a
call
saying
that
hey.
B
You
know
this
is
a
heavy
change
which,
if
five
years
five
months
down
the
line,
if
all
maintainers
are
replaced,
let's
say,
for
whatever
reason:
let's
say
you
leave
your
organization,
so
you
leave
the
project.
I
just
move
on
to
something
else.
Somebody
else
should
be
able
to
come
in
and
reason
about
every
change,
every
major
change
that
has
gone
in
so.
A
C
B
Yeah,
I
I
I
think,
one
other
thing
which
I'll
probably
propose.
I
didn't
put
it
right
here,
because
that's
probably
a
high
level
governance
thing
is
that
and
we
should
probably
discuss
how
much
is
actually
possible,
which
is
we
should
try
to
have
one
or
more
reviewers
from
different
organizations
of
an
enhancement
proposal.
B
What
that
means
is
if
jonathan
makes
an
enhancement
proposal,
let's
say,
and
if
you'an
approves
it.
I
wouldn't
consider
that
to
be
enough,
because,
and
again
this
is
not
because
yan
is
a
biased
reviewer.
B
So
in
general,
the
point
I'm
trying
to
make
is
we
shouldn't,
have
a
lot
of
vendor-specific
things
going
in
and
to
protect
against
that
the
additional
knob
or
the
check
that
we
should
have
is
that
if
red
hat
is
making
an
enhancement
proposal,
somebody
from
into
it
has
to
approve
it
like
one
of
the
maintainers
from
a
different
organization.
B
I
think
that's
something
that
we
should
have
as
a
checks
and
balance
to
ensure
like
some
changes
are
easy
like
I
want
to
have
a
new
logging
framework,
I'm
pretty
sure
that's
very
easy
to
put
in.
But
let's
say
we
want
to
make
a
new
api
which
exposes
a
very
vendor
specific
feature
like
like.
Let's
say
we
want
to
explore
like
we
want
to
expose
the
route
api
somewhere
here
and
and
let's
say
all
the
red
hatters
are
happy
with
it
and
we
just
put
it
in.
B
But
if
I'm
not
a
red
hatter,
I
mean
either
like
from
a
non
red
hat
perspective.
That
is
a
horrible
thing
to
do
the
way
I
see
it,
and
so,
which
is
why
you
know
we
need
to
ensure
that
we
have
this
checks
and
these
checks
and
balances
in
every
project
like
I'm,
not
sure
how
much
is
possible
in
all
the
other
projects,
but
in
argo
cd.
Definitely
we
can
have
that,
like
one
person
from
a
different
organization
has
to
approve
it.
So
on
that
note,
I
would
say
abhishek.
B
Does
that
sound
okay,
yeah
alex.
A
B
I
mean
I
I
think
few
months
ago,
like
young,
is
in
red
hat
now,
but
I
think
jan
is
still
not
an
into
it
person.
So
I
mean
you
should
have
multiple
organizations
in
there,
but
the
goal
is
like
one
non-red
hat
or
one
non
intuit.
I
think,
has
to
do
these
things
just
to
ensure
we
don't
pull
in
a
lot
like
like.
B
Like,
for
example,
I
mean,
and
and
that's
the
same
thing
I
think
over
time,
we're
going
to
have
somebody
from
quote
fresh,
also
become
a
maintainer,
and
I
think
that's
going
to
help
us
even
further.
So
probably
that
that's
a
goal
we
need
to
have
within
the
group
that
ensure
we
have
more
diverse
maintainers.
E
There
a
section
in
the
doc
that
need
someone
has
to
discuss
the
security
concerns
about.
B
I
actually
didn't
put
it
in,
but
that's
a
good
idea.
I
actually
removed
it
thinking
that
it
might
not
be
relevant
for
a
lot
of
cases,
but
I
think
I
mean
the
the
cap
process
has
it,
but
I
think
I
slashed
out,
but
that's
a
good
point.
E
I
I
think
everyone
yeah,
I
think
everyone
should
consider.
D
E
It
impacts
security
and
at
least
putting
making
a
mandatory
section
forces
them
to
think
about
it
right.
I
think
that's
a
good
idea.
Yeah.
Definitely
I
mean
I
mean
a
lot
of
times.
It's
probably
gonna
have
zero
impact
on
security,
but
at
least
they've
thought
about
it.
B
B
Yeah,
I
think
that's
it
from
my
side
on
this
one.
I
think
so.
Some
of
the
next
steps
will
be,
of
course,
I'll
probably
present
this
in
the
bigger
community
and
also
let
them
know
that
this
doesn't
stop
them
from
creating
github
issues
with
future
requests.
They
should
still
do
that.
B
That's
extremely
helpful
and
I
think
the
other
thing
I
want
to
figure
out
how
we
should
we
are
able
to
roll
this
out
to
all
projects,
not
just
argo
cd,
especially
because
assuming
things
work
out
as
a
cnc
of
graduation
it'll
be
nice
to
have
some
level
of
consistency,
but
the
template
could
be
and
probably
should
be,
different
based
on
which
project
it
is.
So
I
think
that's
my
suggestion.
A
You
know
other
teams
to
follow,
but
if
we
just
if
we
try
it
out
on
argo
cd
and
it
shows
good
results,
then
we
can
just
communicate
it
to
let's
say
workflow
team
and
if
it
works
for
us
they
will
just
maybe
send,
can
adopt
it
easily.
You
know
because
does
that
make
sense.
B
Thank
you.
Okay,
with
that
I'll,
stop,
sharing
good
with
this
agenda
topic
back
to
you,
alex
thanks
shubik.
Thank
you.
A
Yeah,
actually
so
we
we
almost
at
the
end
of
a
meeting
and
the
next
topic.
It's
again
yours
rebic.
It
was
about
a
contributor
community
planning
meeting
and
I
think
it's.
What
do
you
feel
like?
Do
we
have
enough
time
to
complete
it
or
we
can
just
move
it
to
the
next
yeah.
B
B
We
should
consider
setting
up
a
time
slot
or
not
time
slot
just
use
one
of
these
meetings
as
planning
the
next
milestone,
based
on
a
rough
availability
of
you
know
how
many
hands
on
the
deck
we
have
with
some
wiggle
room
because
priorities
change
within
different
companies
and
probably
use
that
as
a
way
to
plan
it
plan
the
next
milestone
in.
A
B
A
I'm
just
yeah,
I'm
kind
of
so
we
I'm
just
feeling
that
you
know
a
release.
Usually
it
takes
like
three
months,
if
not
longer,
and
within
this
I
think
it
just
makes
sense
to
kind
of
plan-
okay,
shorter
periods
of
time.
So
what
my?
What
problem
I'm
hoping
to
solve
is
that
so
we
kind
of
we
only
plan
to
you
know
to
deliver
features
into
the
milestone,
but
at
the
same
time
we
have
a
lot
of
things
that
could
be
done.
A
A
You
know
that
they
really
need
it
and
we
have
no
plan,
for
you
know
nice
to
have
but
also
important
improvements
and
yeah,
so
I'm
pretty
much
proposing
to
just
use
it
to
build
backlog
for
the
next
week.
A
Assuming
that
we
have
that
many
engineers
who
who
wants
to
work
on
ui
that
many
engineers
who
also
want
work
on
back
end
and
then
we
can,
let's
say
for
the
next
two
weeks,
we
can
figure
out
that
it's
nice
to
do
that,
that
you
know
these
things.
Yeah.
B
D
B
B
A
little
bigger-
and
I
think,
like
I'm,
I'm
good-
I
mean
what
what
we
could
probably
do
is
do
both,
which
means
have
a
rough
understanding
about.
What's
going
to
happen
in
the
next
and
then
the
main
reason
I
said
milestone
because
I
think
on
github
it's
called
get
a
milestone
right,
that's
how
we
put
it
yeah,
but.
A
Right
now
we
kind
of
mix
it
I
mean
we.
Basically,
we
use
milestone
as
releases
right
now
and
right.
We
didn't
want
to
have
a
process,
so
we
made
it
as
easy
as
possible.
It
was
just
you
know,
release,
but
now,
with
more
engineers,
what
happens
is
that
you
know
lack
of
process
means
that
people
pick
totally
random
things
and
it
results
in
in
a
real.
You
know,
for
example,
I
can
give
you
a
real
example.
A
So
remington
chose
to
work
on
logs
because
he
wanted
to
he
basically
and
on
the
fly
we
decided
to
kind
of
expand
on
it
and
build
on
it
more
and
more
and
eventually,
you
know
a
small
improvements
of
logs
got
into
a
big
feature
and
it
happened
like
organically
it's
good
to
have.
You
know
some
planning.
I
don't
think
it
was
bad.
It's
great
good
with
good,
much
better
log
view
very
nervous
again,
but
we,
you
know.
G
B
A
B
Planning
right,
I
think
so,
so
I
think
there
there
are
a
couple
of
things
and
probably
will
use
the
next
meeting
for
it.
I
think
in
the
grooming
conversation
we
should
have
basically
that
okay
should
we
do
it.
You
know
in
the
next
two
releases
or
not
or
even
after
that,
like
it's
there
in
the
roadmap
but
later
or
hey.
We
are
not
going
to
do
this
at
all.
That's
what
we
think
like
these
are
the
answers,
questions
we'll
answer
and
during
planning.
B
So
I
think
in
in
general
I
think
yeah
we
should.
We
will
have
a
separate
conversation
next
week,
probably
on
how
to
put
our
issues
into
better
buckets,
and
then
this
planning
is
to
kind
of
roughly
understand
which
ones
can
we
pick
up
and
work
in
the
very
short
term.
A
A
A
B
A
A
To
you
alex
and
yeah,
thank
you
for
proposing
it.
I
feel,
like
maybe
expectation,
was
that
I
should
do
it,
but
big
thank
you
for
for
driving
it.
Thank
you
right.
I
think
yeah,
that's
it
and
we
already
one
minute
passed.
So
thanks
everyone
for
joining
the
meeting
and
see
you
next
week,
thanks.