►
From YouTube: Argo Contributor Experience Office Hour 29th Oct 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
We
had
several
topics
today.
One
is
carry
over
from
previous
meeting,
which
is
a
writing
test
for
application,
and
I
cannot
see
isaac
in
the
list,
so
I
guess
we
have
to
skip
it.
A
Right
and
I
myself,
I
proposed
two
topics:
one
was
to
just
go
through
1.8,
milestone
and
basically
just
look
for
issues
which
we
want
to
have
in
1.8,
but
they're
in
a
bad
shape,
and
you
know
we
can
discuss
what
we
can
do
about
them
and
two
follow-up
topics.
Kind
of
so
we
spoke
about
improving
release,
process
of
github's
engine
and
ui
library
and
for
both
we
had
a
short
discussion
in
github,
and
I
just
wanted
to
kind
of
finalize
the
final
decision.
A
Okay,
so
and
if
you
don't
mind,
I
want
to
start
from
1.8
milestone
so
and
feel
free
to
stop
me
at
any
time.
But
my
goal
was
to
just
go
through
all
these
issues
and
I'm
going
to
basically
say
what
I
know
about
each
issue
and
if
you
have
anything
to
it,
just
let
me
know
please
yeah
and
I
will
try
to
give
a
short
summary
about
issues.
A
All
right
so
so
this
is
1.8
milestone
and
we
have
17
remaining
items
open.
So
first
one
is
repo
server
performance
and
basically,
I
think
it's
in
a
good
shape.
The
pull
request
to
close
the
last
improvement
is
open
and
it's
in
review
plus.
We
know
how
to
test
it.
So
we
have
one
argo,
cd
user
and
they
really
kind
of
suffer
from
performance
issues.
A
It's
a
new
relic,
so
they
have
to
run
more
than
100
instances,
instances
of
repo
server.
So
basically
we
have
I'm
hoping
to
convince
them
to
do
some
early
testing
of
pre-release,
and
so
we
can
confidently
say
if
the
changes
which
we've
made
are
enough
for
them
or
not
enough
all
right.
So
I
think
this
one
is
in
a
good
shape
and
the
next
one
is
logarithmic.
A
So
it's
not
really
like
a
blocking
blocking
issue
for
1.8,
but
it's
related
to
security,
and
that's
why
I
think
it
was
kind
of
prioritized
in
1.8
release
and
I
know
gender
is
working
on
it
and
I
feel
like
we
kind
of
clear
on
what
to
do
and
we
basically,
we
identified
two
cases.
So
the
original
issue
was
requested
for
external
odc
provider
and
we
know
how
to
deal
with
it.
Basically,
we
know
how
to
work
with
external
odc
provider.
We
also
run.
B
A
And
then,
when
jd
he
was
investigating.
Basically,
he
realized
that
there
is
decks
as
well,
so
we
do
not
really
know
how
to
delete
tokens
in
decks
during
logo
process,
but
it
is
also
not
very
critical,
so
I
feel
like
it's
still
in
a
good
shape.
If
we
cover
oadc
and
we
know
how
to
do
it,
we
could,
and
we
can
just
create
a
second
ticket
for
future
to
work
with
decks.
A
That
makes
sense
it.
Okay,
so
seems
like
this
is
good
as
well,
so
the
next
one
this
is
it.
It
was
kind
of
inserted
into
1.8
release.
We
didn't
plan
to
work
on
it,
but
this
is
basically
jc
discovered,
a
missing
feature
in
argo
cd
to
support
rollouts
and
because
we
are
very
friendly
with
rollouts,
and
we
want
to
you.
C
A
Deliver
the
feature
as
well
as
possible
that
ticket
was
created
and
idea
that
in
argo
cd
we
have
actions
and
it
is
beneficial
to
use
a
status
sub
resource
to
change
status
instead
of
just
regular,
kubernetes,
patch
and
jc
is
taking
care
of
it.
The
request
is
already
open,
so
I
think
it's
in
a
good
shape.
A
Okay,
so
next,
two
tickets
are
pretty
much
not
really
blocking
release,
but
I
think
we
want
to
get
them
them
to
test
release
well,
and
I
know
that
both
are
in
progress
right
now,
so
I'm
just
going
to
keep
both
of
them.
So
basically
we
I
think
we
know
what
we're
doing.
First
already
has
pr
actually
two
pairs
and
second
thing
to
be
started.
A
Okay,
the
next
ticket-
I
don't
think
it's
working,
but
we
edited
because
it
was
kind
of
such
a
bad
gap
in
the
documentation,
yeah
and
think
it
was
started.
At
least
it
was
assigned.
But
I
have
not
heard
about
progress.
So
I'm
sure
this
is
in
the.
A
Call,
oh,
no,
she
isn't
okay
yeah
and
then
I
think
it's
basically
it's
totally
fine
to
move
it
to
the
next.
You
know
208
release
and
then
maybe
we
can
follow
up
a
flag.
So
I'm
just
going
to
put
it
aside
and
then
send
a
message
or
maybe
just
to
ask
for
update.
C
A
Okay,
the
next
is
so
that
was
a
feature
request.
It's
not
critical,
I
think
we
can
release
1.8
without
it,
but
I
guess
we
just
want
the
feature
as
soon
as
possible.
Just
because
of
it's
like
every
way.
It
happens
more
and
more
frequently.
We
want
to
make
some
changes
in
argosy
and
we
want
to
update
our
users.
A
C
Alex,
when
is
the
one
one
not
eight
release
due?
I'm
sorry
when's
the
when's
the
last
date.
We
can
work
on
the
one
actually.
A
I
think
we
don't
have
like
a
hard
hard
deadline:
okay,
and
we
just
kind
of
we
approaching
the
typical.
You
know
two
months
for
the
full
release.
A
So
I
feel
like
I
expect
us
to
spend
maybe
another
week
to
close
all
the
tickets
just
based
on
previous.
You
know,
experience
and
maybe
another
week
or
two
to
test
and
fix
all
the
bugs
okay,
yeah
and
maybe
basically
I
was
hoping
to
go
through
at
least
with
everyone.
And
maybe
you
can
correct
my
expectations
because
I
might
be
making
something
and
that's
the
kind
of
whole
collect
information
and
sharing.
A
All
right,
okay,
so
the
next
ticket
it's
kind
of
it's
usually
we
just
have
great
film
every
release
just
to
be.
You
know
up
to
just
to
have
up-to-date
versions,
and
hopefully
this
will
take
like
10
minutes
of
someone's
time,
so
we
can
do
it
at
the
very
last
moment.
I
don't
expect
any.
You
know
no
surprises
here
yeah,
but
someone
just
have
to
pick
it.
D
Up
regarding
the
the
home
version-
2-
maybe
maybe
it
might
sense
to
to
drop
it
all
together
in
the
near
future,
right.
A
I'm
kind
of
I
don't
mind
doing
that.
I'm
just
scared
that
we
might
get
a
lot
of
frustrated
user
who
not
ready.
A
D
A
Okay
agreed
so
sounds
good.
Okay,
I
think,
and
this
basically
this
is
the
list
of
all
the
remaining
enhancements
so
going
forward,
they're
just
bugs
okay.
So
this
is
one
bug
and
I
think
maybe
this
is
one
of
the
few
who
never
worked
on
yet.
So
the
good
thing
about
that
bug
is
that
it's
not
an
aggression,
it's
like
a
day,
zero
bug
and
we
know
how
to
fix
it.
So
it
was
kind
of.
A
Easy
win
to
in
improve
user
experience
and
just
to
give
some
some
background
so
right
now,
if
user
click
on
resource
in
the
ui,
we
should
show
a
resource
and
a
version
that
is
in
git,
but
we
show
just
latest
preferred
version
of
that
resource,
so
yeah,
and
there
was
some
basically
I
feel
like
we
can
move
it
on
in
1.9.
A
But
you
know
if,
if
we
get
redundant
great
so
even
though
it
doesn't
have
assignee,
I'm
not
really
worried
about
this
buck.
Yet
all
right
so
next
ticket
is.
This
is
again
it
was
discovered
during
rollout
integration.
So
it's
a
pretty
much
day
zero
bug
and
the
problem
is
that
argo
cd,
sync
waves
might
falsely
move
to
the
next
wave,
basically
might
move
to
the
next
wave
too
early
because
of
racing
condition
in
kind
of
kubernetes.
So
it
was
like
a
thing
we
discovered
recently,
and
I
know
that
jc.
A
I
think
he
already
said
he,
oh
no.
He
he
has
not
sent
pr
yet,
but
we
expect
pull
requests
in
like
today,
basically
yeah.
So
I
think
this
one
is
in
a
good
shape.
We'll
have
a
fix
next,
one
is
a
critical
1.8
bug
and
pull
request
is
open
already.
So
this
is
good
it's
basically.
This
is
a
it's
a
change
that
prevents
argo
cd
from
accidentally
delete
resources
and
due
to
some
issues,
yes
and
the
next
bug,
they
are
pretty
much
the
same.
A
A
The
next
one
is
so
we
have
the
regression
in
1.7,
we
implemented
the
change
and
then
that
change
was
not
enough.
We
reverted
change,
and
this
is
pretty
much
continuation
of
the
1.7
change
and
may
already
send
pull
requests
to
support
it.
So
this
one
is
good
as
well.
A
A
Okay
and
so
far,
it
seems
to
me
that
nothing
is
like
really
wearing
nothing
in
a
bad
shape
and
we
have
these
three
issues,
and
I
mean
I
don't
really
know
a
good
answer
for
these
three.
So
for
two.
Basically,
this
is
it's
a
this
one.
We,
I
think
we
should
just
get
it
done,
it's
a
just,
a
documentation,
improvement
and
it's
not
critical
yeah.
A
There
is
a
known
issue
of
ipi
applications,
so
it's
extremely
slow
if
your
argo
cd
has
a
lot
of
applications
and
you
have
a
lot
of
our
backgrounds,
so
this
combination
makes
I
you
know
that
api
can.
It
can
take
like
10
seconds
to
return
the
data
and
there
was
a
it
feels
like
something
like
a
day,
zero
bug
which
still
exists
and
we
tried
to
work
on
it
in
1.7
and
it
didn't
really.
A
A
A
D
A
D
D
I'm
unsure
I
I
didn't
have
a.
I
didn't,
have
a
detailed
look
at
those
two
issues
on
the
bottom,
yet
I
can.
A
Yeah
so
yeah
I
was
trying.
I
think
I
tried
to
give
a
summary,
but
this
is
basically
it's
a
performance
issue,
and
that
worries
me
is
because
the
whole
kind
of
you
know
the
goal
of
that
release
was
to
increase
performance,
and
I
think
we
did
a
lot
of
performance
improvements
except
this
one,
and
this
is
like
the
last
thing
which
we
could
not
do
well
and
yeah,
but
at
the
same
time
it
doesn't
affect
all
the
users.
It's
like
only
a
few.
I
mean
not
few.
Only
some
users.
C
A
Decided
to
manage
her
back
in
a
declarative
play
in
git,
so
they
introduced
a
lot
of
groups
in
urban
configuration
and
they
have
a
lot
of
users
with
multiple
groups
yeah.
So
that's
why
that
api
is
really
slow.
D
A
A
Okay-
and
I
wanted
to
really
discuss
with
you
like
how
are
we
going
to
test
it,
because
I
think
this
is
a
very
first
one
that
so
rbcd
release,
which
has
so
many
people
ready
to
you
know,
help
and
contribute,
and
I
can't
tell
what
we
did
before
so
we
literally
we
used
to
go
through
all
the
changes
manually,
just
parse
git
log
and
we
would
create
a
shared
document.
A
Just
a
google
spreadsheet
is
all
the
kind
of
features
which
we
have
to
test
and
then
rbc
team
members
go
through
each
and
every
change
and
manually
verifies
yeah,
and
then
whoever
finds
some
problem
works
on
the
fix,
and
maybe
this
is
enough.
I
want
to
hear
if
anyone
has
any
better
suggestion
like
better
way
to
organize
it.
A
The
issues
yes
and
I
feel
like
yeah,
I
want
to
know
who
wants
to
volunteer
to
participate
in
the
process.
A
You
have
noticed,
I
think,
and
then,
if,
if
there
are
any,
I'm
happy
to
you
know
work
on
the
spreadsheet
and
share
it
with
you,
I'm
going
to
do
it
for
myself
either
way,
so
it
would
be
typically,
it's
like
a
100
lines.
A
D
A
F
Yeah,
so
we
are
verifying
the
issues
manually
right,
so
we
have
the
steps.
We
are
somehow
recording
the
steps
like
how
we
verified
that.
So
is
there
any
plan
to
automate
that
to
automate
it?
I
feel
like
it's
more.
It's
not
really.
A
Kind
of
just
the
testing
this
is
to
this
is
so
everyone
understand
what
was
changed
in
the
release
and
then
kind
of
make
sure
that
change
at
least
makes
sense
and
and
then
also
it's
good
to
check.
If
we
already
have
automated
tests
for
the
change
and
if
change
is
missing,
it's
totally
fine,
I
think,
to
create
tickets
and
kind
of
create
automated
tests
if
it's
missing
for
a
change
yeah,
but
it's
like,
even
though,
even
if
we
find
that
everything
is
already
automated,
we
still
need
to.
A
At
least
you
know,
verify
all
the
changes
at
least
once
manually
and
make
sure
that
we
didn't
introduce
any
logical
problems.
For
example,
there
might
be
two
features
and
if
each
feature
is
perfectly
implemented,
fine,
but
together,
those
two
features
might
create,
might
have
a
bad
effect.
For
example,
some
use
case
might
be
working,
so
the
goal
is
to
verify
the
whole.
You
know,
release
as
a
whole
and
make
sure
we're
delivering
meaningful
set
of
changes
and
nothing
kind
of
critical
is
missing
or.
D
We
didn't
miss
anything,
and
maybe
it
would
also
make
sense
if
so,
if,
when
we
look
at
the
issues
to
note
whether
whether
this
issue
needs,
for
example,
an
entry
in
the
upgrade
nodes
right
yeah,
this.
D
If
it's,
if
it's
a
slightly
backwards,
incompatible
change
or
something
like
that,
something
that
the
user
needs
to
take
action
yeah,
maybe
this
this
should
be
noted
in
this
sheet
as
well,
because
I
know
it's
it's
so
many
issues,
it's
it's
hard
to
to
to
to
re,
remember
all
of
them
and
which
one
needs,
but
they
were.
I
think
they
were
a
couple
already
yeah.
A
Yeah
and
yeah
this
really
needs
to
have
some
kind
of
not
breaking
changes,
but
some
manual
steps
that
people
have
to
do
during
upgrade,
and
it's
not
it's
again
kind
of
to
clarify.
It's
not
typical,
like
we're
not
going
to
do
just
qa.
C
A
I
think
we
should
assume
that
every
issue,
every
change
which
we
can
merge
that
was
tested,
and
you
know
whoever
did
the
change
and
if
we
were
tested
already
the
improvement
of
bug
fix,
but
we
need
to
kind
of
just
do
it
again
and
typically,
at
the
end
of
release,
we
need
to
communicate
to
our
users.
What
are
we
releasing,
and
so
it
will
really
help
us
to.
A
You
know:
come
up
with
meaningful
release
notes.
So
in
this
release
notes
we
can
group
all
the
issues
kind
of
effectively
and
we
can
describe
that.
Okay,
there
were
set
of
things
which
improved
performance.
I
know
we
did
a
lot
of
ui
improvements
and
unless
we
tell
about
these
ui
improvements-
and
we
can,
in
a
in
a.
A
End
users
won't
have
any
source
of
data,
so
I
know
yeah
team,
for
example,
he
did
the
changes
in
multiple
places.
I'm
pretty
sure
we
can
not
just
give
a
list
of
issues,
but
we
can
say:
oh
application
list
page
was
improved
significantly
because
of
it
has
built
a
bunch
of
filters
and
some
user-friendly
improvements
as
well.
Yeah.
A
H
G
Oh,
you
mean
the
cluster
like
gke
or
openshift
or
whatever
cluster.
Oh.
H
Helpful
to
this
this
sheet,
the
sign
up
sheet
or
the
record-
are
they
to
stretch
it
that
maybe
you
have
a.
A
A
Okay
right,
so,
if
you
have
any
other
idea
to
help
this
testing,
just
let
me
know
please
offline.
I
will
be
happy
to
do
as
much
as
possible
and,
as
I
mentioned.
A
Several
tasks
to
create
automation,
it's
not
blocking
release,
but
I
think
I
will
I
I'm
happy.
We
have
already
prs
going
and
we'll
need
to
so
the
sooner
we
get
them
the
better.
I
think,
once
we
have
a
first
smoke
test,
we
can
configure
it
and
run
it
against
cg.targo
brushes
dot
ios,
so
we
can
hopefully
catch
some
bugs.
I
A
There
were
two
other
topics
and
I
feel
like
I
just
wanted.
I
felt
like
we
have
to
make
some
decisions
about
these
topics,
so
we
wanted
to
improve
release,
process
of
ui
library
and
team,
created
a
proposal,
and
I
feel
like
no
one
had
any
objections.
So
basically,
we've
got
second
idea
to
so
the
proposal
was
to
create
either
stable
or
release
branch
in
argo,
ui
library
and
then
consumers
should
get
should
consume
stable
version,
the
code
from
either
stable
or
release
branch,
and
this
would
kind
of
simplify
making
changes
in
in
our
ui.
A
So
the
goal
is
to
kind
of
batch.
This
upgrade
work
and
there
was
additional
proposal
later
on
to
also
start
publishing
the
changes
into
npm
and
that
improvement
would
help
to
simplify
build.
So,
basically
consumer
don't
have
to
rebuild
the
whole
library.
Consumer
could
just
consume
just
just
a
javascript
file
and
css
instead
of
typescript
and
cells.
So
I'm
I
totally
fine,
I'm
totally
fine.
With
that
proposal.
I
think
it's
clear
and
if
anyone
has
any
objections,
please
let
us
know-
or
we
can
just
start
and
implement
it.
A
And
we've
got
response
from
gitlab,
so
gitlab
consumes
github's
engine
and
we
want
to
start
creating
release
branches
and
release
text
for
github's
engine,
but
we
do
not
want
to
kind
of
break
and
change
our
development
process,
so
argo
cg
would
keep
using
master,
and
only
after
we
create
release
version
of
argo
cd,
then
we
create
it.
The
release
version
of
arbor
city
must
point
to
a
release
deck,
so
it
would
be
really
minor
change
for
us
and
we
did
ask
gitlab
and
they
say
so.
A
Basically,
mikhail
is
the
only
developer
from
gitlab
who
works
a
lot
on
github's
engine,
and
at
this
point
he
don't
really
care
because
he,
I
think,
he's
the
most
active
contributor
to
github's
engine.
So
I
I
got
his
responses,
I
don't
mind
even
if
you
do
breaking
changes,
because
we
are
kind
of
still
working
closely
together.
So.
A
A
A
Now
we
have
30
minutes
to
do
anything.
Anyone
have
any
questions
and
for
him.
J
Yeah,
since
we
have
some
time-
I
I
didn't
want
to
put
this
in
the
agenda,
but
I
added
a
link
yeah
for
this
link.
If
you
see
this,
there's
a
warning
banner
that
the
documentation
is
out
of
date,
so
someone
mentioned
like
the
documentation
is
actually
fine.
It's
just
the
banner
that
needs
to
be
updated,
but
I
was
wondering
if
we
need
to
create
an
issue
to
actually
verify
if
all
the
steps
work
and
then
we
can
remove
that
banner.
A
Yeah,
that's
a
good
point.
I
think
we
should
create
issue
with
this
for
that
and
also
so,
I
think
we
had
the
discussion
last
time,
so
we
wanted
to
simplify
making
changes
in
developer,
yeah
books
and
the
ticket.
Sorry
that
had
created
a
git
repository-
and
I
know
that
we
this
week,
we
plan
to
add
finally
add
all
contributors
to
argus
approach
members
and
basically
everyone
will
have
just
direct
right
access
to
that
documentation.
Repository.
D
A
J
A
And
then
I
think,
once
you
have
once
you
configure
the
communication
repo,
I
think
we
were
playing
to
just
start
moving
moving
that
whole
documentation
into
the
people.
I
feel
like
there
is
no
harm
to
remove
it
from
here
because,
like
end
users,
don't
care
about
developer
yeah.
We.
D
Can
keep
we
can
we
can
just
we
can
just
link
it
or
something
like
that,
and
I
think
we
have
also
there's
basically
a
community
standard,
this
contribution
dot
md
the
top
level
directory
of
the
repository.
Maybe
we
should
just
reference
the
new
documentation
repository
from
there
as
well
and
yeah,
I'm
with
you
to
to
just
move.
A
A
All
right,
and
since
we
have
some
time
left,
I
maybe
we
can
discuss
topics
for
the
next
meeting,
so
one
possibility
was
to.
I
think
we
will
need
to
talk
about
testing
next
week
because
hopefully
we'll
be
ready
to
start
testing,
so
we
can
kind
of
just
recap.
You
know
what
is
the
plan,
and
maybe
we
can
work
kind
of
talk
together
about
1.9
features
and
basically
we
can
either
vote
or
somehow
figure
out.
How
are
we
going
to?
A
A
Okay,
either
way
we
have
whole
week,
so
don't
hesitate
to
add
anything
if
you
want
to
discuss
into
the
community
document.
A
H
Yeah,
I
think
we
we
we
have
some
some
some
like
some
question
as
to
how
like
we
want
yeah.
We
want
to
find
some
some
area
that,
maybe
maybe
we
we
couldn't
contribute
more
more
in
the
fashion
that
is
more
organized,
so
right.
A
H
Could
pretty
much
pick
up
pick
up
whatever
fixed
whatever,
although
we
don't
receive.
A
I
H
H
I
think
I
think
we
need
to.
We
probably
want
to
think
about,
like
maybe
in
a
1.9
time
thing,
maybe
there's
any
one
area
or
on
you
know,
one
common
area
that
that
how
how
we
can
contribute.
H
A
A
lot
of
different
types
of
experiences,
so
some
people
wanted
to
focus
on
back-end
some
people
on
front-end.
So
I
think
we
will
come
up
with
kind
of
separate,
like
one
big
feature
for
for
your
people
and
big
feature
for.
A
To
be
honest,
I
have
good
understanding
about
backhand
work
and
maybe
you
can
even
give
us.
Maybe
you
have
more
ideas
about
ui
work
because
so
far
there
was
a
lot
of
tickets
created
proactively
by
red
hat
team
until
for
for
your
investments,
so.
A
H
Well,
we
actually
heavier
on
the
back
end
than
the
front
end
yeah
yeah.
I
think
I
think
yeah.
We
also,
I
mean
you've,
seen
our
team
and
give
it
just
the
contribution
from
the
end
themselves
yeah,
so
yeah.
This
is
just
yeah
one.
We
want
to
explore.
Maybe
in
one
night
one
night
there's
many
particular
feature.
A
G
A
Yeah
that'd
be
awesome,
okay,
and
we
should
maybe
that's
the
good
discussion
for
the
next
meeting.
So
we
should
do
some
kind
of
homework
and
then,
in
next
office
hour,
meeting
quick
and
update
everyone.
J
Another
point
or
idea,
I'd
like
to
share
is
we're
talking
in
the
team
about
some
sort
of
developer,
advocacy
type
work
or,
for
example,
tecton
project.
They
have
these
blog
or
podcast.
Series
is
where
they
engage
the
community
on.
What
are
the
work?
That's
been
going
on,
let's
see
if
someone
is
completely
new
to
the
the
community,
videos
and
tutorials,
but
not
just
posting
on
the
on
the
website,
but
more
engaging
like
podcasts
or
videos
or
weekly
shows.
Is
that
something
that
we
can?
J
We
can
talk
about
doing
from
from
the
community
level,
let's
say
like
creating
issues
and
tracking
who's
going
to
take
up
some
work
around
that.
A
J
J
I
think
it
was
a
weekly
or
monthly
podcast
series
or
we
talked
about
different
projects
within
the
city
foundation,
but
it
started
with
tecton
but
then
even
like
other
dev
advocates
had
their
own
channel
where
they
were
creating
weekly
videos
or
like
techdown
101
or
checked
on
in-depth
or
in
like
details.
So
if
someone
lets
us
try
to
find
something
online,
they'd
have
all
those
videos
or
podcasts,
basically
a
lot
more
resources
than
just
the
developer
guide
for
some
people.
It's
much
more
easier
to
learn
in
that
way.
A
It's
it's
kind
of
it's
a
great
idea,
it's
hard
to
implement
it
because
it
requires
you
know
a
lot
of
time
and
effort,
but
I'm
hoping
we'll
get
there
as
soon
as
we
get
more
reviews
and
our
progress,
and
I
think
what
team
proposing
is
a
good
idea.
Basically,
if
you
find
now
a
big
areas
that.
A
People
can
own
and
then
they
the
owners,
they
can
start
creating
content
for
you
know
and
share
it
with
the
community.
It's
just
I'm
trying
to
say
that
I
would
not
commit
myself
to
do
it
right
now,
because
I'm
like
overloaded,
but
I
really
like
the
idea-
and
hopefully
hopefully
we'll
get
several
reviewers
soon
and
later
on.
These
people
can
get
approval
permission,
so
they
can
just
work
on
their
own
features
without
asking
you
know
me
and
young
to
review
each
and
every
pr
and
then
yeah.
A
A
Yeah,
so
basically,
I
feel
like
I'm
right
now
we're
kind
of
doing
the
best
we
can
and
it's
because
we
have
kubecon
that
takes
a
lot
of
time.
So
pretty
much
every
time
we
have
something.
You
know
we
need
to
share
some
content.
We
prioritize
coupon
because
it
has
the
highest
visibility
and
just
to
share
with
you.
It
like
it
took
several
days
to
prepare
a
20
minute,
long,
video.
A
But
yeah
overall,
let
me
stop
sharing,
I
feel
like
it's
been
like
1.8
milestone
is
really
exciting
and
I'm
really
happy
with
all
the
fixes
and
ui
improvements.
We've
made
together.
Yeah,
that's
been
a
big.
A
H
Same
here,
thank
you
so
much
for
you,
guys,
guidance
and
yeah
make
our
journey
to
to
to
the
community
enjoyable.
So
far
here.
H
Yes,
yes,
that's
just
of
you
know
here,
you
know
we
also
collect
glad
to
be
be
working
on,
go
cd,
contributing.
A
I
think
sooner
will
I
really
see
how
we
kind
of
getting
better
and
better,
and
we
just
need
to
go
for
that
exercise
and
keep
working
wait
for
you
know
when
people
have
expertise
and
knowledge
about
the
project
and
then
at
some
point
you
will
get
owners
of
areas
and
then
finally,
like
we,
we
won't
have
a
kind
of
bottleneck
like
me
who,
like
now
I'm
supposed
to
do
and
it's
not
because
I
want
to
review
each
and
every
api
just
we
need
to
work
a
little
bit
longer.
A
I
H
Yeah
yeah,
we
we
very
much
appreciate
you
know
having
this
opportunity
to
have
like
an
office
hour
and
make
really
make
us
getting
around
a
lot
easier
and
thanks
to
all
those
presentations
and
yeah,
it's
very
helpful.
J
A
Thank
you.
Yes,
by
the
way,
speaking
of
presentations,
anyone
is
going
to
give
a
talk
at
cubecon,
someone
from
redhead.
H
Oh
well,
I
don't
think
anyone
here
going
to,
but
certainly
people
from
whitehead,
yeah.
A
Do
you
usually
watch
videos
like
participate
now,
it's
much
easier.
I
think
now
it's
kind
of
almost
for
free,
you
can.
That
is,
join
cubecon
and
watch
all
the
presentations.
H
Yeah,
you
know
yeah
actually,
right
now,
it's
easier.
You
know
you
don't
have
to
travel
yeah,
so
yeah
we
we
usually
have
like.
I
know
people
from
techcon
and
yeah
just
folks
that
know
that
they
they
participate,
but.
H
Yeah
so
you'd
be
preparing.
So
how
how
how
then
goes
on
the
on
the
alco
cd.
A
A
So
there
is
a
way
you
can
connect,
rcd,
argo
events
and
go
workflows
and
algorithms
and
kind
of
combine
a
whole
like
application
out
of
it.
So
that's
what
our
talk
is
going
to
be
about,
and
I
know,
alex
kodens
and
jessie
are
going
to
present
as
well.
Each
one
has
a
separate
talk.
I
know
jc
is
going
to
talk
about
how
to
manage
yaml
in
a
how
to
manage
kubernetes
configuration
in
a
big
enterprise.
So
it's
a
lot
about
config
management
tools
and
challenges.
A
E
I'm
actually
not
speaking
this
year,
we
were
wait
listed,
but
we
didn't
get
accepted.
Oh,
it's
gonna,
be
machine
learning.
A
C
A
Okay,
I
know
what
is
it
about?
It's
a
there
is
a
team
at
intuit
and
they
do
chaos,
engineering
and
they
leverage
argo
workflows.
I
think
they're
going
to
demo
how
they
do
it.
H
A
Yes,
we,
it
was
kind
of
easier
this
way,
because
we
could
just
record
the
presentation
and
be
done
with
it.
If
you
do
it
live
it
kind
of.
You
have
to
stay.
J
A
H
Yeah,
so
I'm
wondering
flex
cd.
So
so
you
guys
were
collaborating.
A
Then
yeah
I
can
give
a
bit
about
this,
so
flux
team,
they
kind
of
they
changed,
focus
right
now.
I
think
they
work
on.
They
want
to
focus
on
pretty
much
expanding
scope,
and
this
is
just
my
understanding.
So
it's
not
like
official,
but
that's
what
I
this
is,
how
I
understood
it.
They
decided
to
work
on
even
big.
They
want
to
extend
scope,
so
they
want
to
include
whole.
A
They
want
to
answer
a
question:
how
do
you
introduce
gitobs
process,
so
the
building
github
toolkit,
which
is
a
set
of
tools
and
it's
going
to
kind
of
replace
flux,
v1
and
so
part
of
github's
tools
is
going
to
do
githubs
and
there
will
be
other
things
like
how
to
connect
pipeline,
how
to
apply
manifest
modifications,
how
to
do
a
bunch
of
things.
A
So
maybe
at
some
point
they
get
back
to
github's
engine,
but
it's
like
no
longer
a
priority
for
them,
yeah
so,
and
that
the
change
there
was
a
change
which
was
kind
of
ready
to
be
merged
in
flux,
v1
to
use
github's
engine,
but
it's
no
longer
important
for
them,
because
flux
v1
is
end
of
life.
It's
no
longer
maintained,
so
that's
why
they
didn't
want
to.
A
You
know,
break
it
and
and
then
so,
if
they
migrate
to
github's
engine,
there
would
be
some
period
of
time
where
there
will
be
some
bugs
and
they
would
have
to
support
users
and
fix
all
these
bugs.
So
they
decided
just
not
to
merge
it
focus
on
what's
important
for
them
and
then
at
some
point,
maybe
they
will
get
back
to
github
syndrome
again
and
they
can
start
working
on.
You
know.
A
Maybe
leverage
github's
engine
yeah
and
another
update
is
about
gitobs
engine
is
that
gitlab
uses
it?
I'm
personally
very
excited
about
it,
so
gitlab
they
use
it
and
they
contribute
a
lot.
I
know
just
so
michael
from
gitlab
contributed
51
commit
to
github's
engine.
So
it
feels
like
to
me
it's
not
like
they
contribute
they.
They
drive.
A
H
A
Yes,
so
we
didn't
get
anything
yet
from
from
flux,
we
were
hoping
to
get
things
related
to
working
with
git,
so
flux
has
more
features
related
to
writing
back
to
git
and
then
monitor
docker
docker
registry,
but
now
jan
already
implemented
docker
registry
monitoring
in
a
gitlab
gitlab
project,
and
we
I
think
we
will
need
to
maybe
in
1.8
we
can
add
some
missing
features
in
our
go
cd,
repo
server
to
make
changes
in
kind
of
in
git
repository.
A
A
Flux
can
watch,
it
can
wait
for
new
image
stacks
in
docker
register
and
when
a
new
tags
get
pushed,
flux
can
go
and
push
changes
back
to
git
and
then
trigger
normal
github
cycle,
and
we
already
have
ps
that
can
monitor
and
watch.
You
know
wait
for
new
images,
but
instead
of
pushing
changes
to
git,
it
updates
argo
parameters
in
the
cld.
A
D
D
And,
and
why
why
we
are
already
we're
talking
about
this-
the
image
updater
I
just
want
to
to
make
some
advertisement
because
yeah
it
could.
It
could
need
some
help
as
well.
A
Same
with
vargo
notifications,
it's
another
feature
in
argo
cd.
I
think
it's
really
needed
a
lot
of
people
asking
for
notifications,
and
I
I
worked
on
notifications
a
lot
and
then
I
had
to
switch
on
argo,
cd
and
work
on
performance
improvements
and
big
thanks
to
oleg
for
helping
with
it
and
I'm
really
hoping
we'll.
A
So
I
I
was
hesitating
to
advertise
that
project
a
lot
because
it's
it
it
works,
it
can
be
used,
and
I
know
that
companies
use
it
in
production
already,
but
there
are
bugs
that
have
to
be
fixed
and
I
don't
have
to
time
to
fix
it.
Hopefully
we'll
get
it
in
a
better
shape.
Soon
too
yeah.
A
D
A
I
think
we
actually
like
it's
a
good
point,
so
I
think
we
should
I
feel
like
I
can't
I
hesitated
to
talk
too
much
about
our
quantifications
and
you
know
advertise
it
to
end
users,
but
I
should
share
about
it
more
in
contributors,
community
to
yeah,
agreed
and
same
with
updater.