►
From YouTube: Helm Developer Call 20180426
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
Hey
everyone
welcome
to
the
helm
developer
call
we
are.
We
are
on
day
26
of
April.
2018
will
first
do
some
announcements
and
stand-ups.
If
you
have
any
discussion
items
we'll
ask
for
those,
we
have
a
demo
today.
If
Josh
shows
up
he'll
he'll
give
us
some
give
us
a
cool
demo
and
yeah
and
then
we'll
do
a
silence
at
the
end.
So
let's
get
started.
Does
anybody
have
announcements.
B
A
A
That's
correct,
I
think
a
lot
of
us
will
be
there.
Usually
the
kubernetes
community
doesn't
do
a
meeting
like
the
week
after
coop
khonshu.
So
is
that
something
that
we
have
done
in
the
past
and
want
to
do?
Oh,
my
god,
how
are
you
changing
your
backgrounds?
Do
you
have
a
green
screen
behind
you,
a
butcher?
That's
so
Deb,
that's,
ok,
cool!
A
So
something
to
consider
is:
do
we
want
to
have
a
meeting
the
week
after
coop
kind,
usually
the
helm,
folks,
everybody
and
anybody
in
the
helm
community
generally
like
meets
up
and
hangs
out
during
coop
Connie
you.
So
we
should
just
like
talking
slack
about
if
we
want
to
do
that
and
where
we
want
to
do
that
and
like
we
want
to
do
that
and
yeah.
So
anybody
else
I've
been
announcements
before
we
get
started
with
stand-ups
Oh
Kim
silence
means
no
Adam.
You
want
to
kick
us
off.
E
There's
the
Mia
button,
sorry,
okay,
so
I
haven't
done
much.
The
reason
behind
that
is
yes,
announcement,
I'm
working
at
Microsoft
now
so
I
have
been
kind
of
busy
getting
like
plugged
into
the
mothership
and
all
those
types
of
things
that
happen
with
new
jobs.
So
I
haven't
done
nothing
and
then
I'm
attending
my
sister's
graduation
this
week.
So
I
will
not
be
doing
much
this
week
next
week.
E
I
promise
I'll
be
back
in
there
feel
free
to
get
me
involved
with
any
of
the
health
rework
like
you
want
me
to
tell
supervise
or
get
over
one
of
like
the
main
like
review.
Any
other
things
have
to
deal
with
specific
parts
of
it
or
and
also
try
to
keep
digging
through
as
many
pr's
as
I
can
also
OneNote
for
discussion.
I
I'm
wondering
if
we
need
some
more
people
who
would
be
maintained
errs
because
of
how
many
of
these
things
we
need,
and
so
like
I,
just
look
at
the
PRQ
and
I
go.
E
Oh
my
gosh.
So
anyway,
I
think
it'd
be
good,
maybe
to
at
least
talk
publicly
and
just
not
about
specific
people
we
want,
but
just
how
we
might
see
if
we
can
get
some
more
people
involved
in
the
process
and
what
we
could
do,
even
if
it's
not
more
contributors.
So
we
can
talk
about
that
later.
FariƱa.
C
So
I've
been
kind
of
digging
into
the
chart,
scalability
problem,
particularly
the
community
charts
and
companies
and
organizations,
and
how
do
we
make
all
of
this
work
a
little
bit
better
long
term?
If
you
go
look
at
the
community
charge
repo,
we
have
way
too
many
PRS
and
we
just
can't
keep
up
with
it
anymore,
and
so
people
are
waiting
on
us
and
it's
companies
trying
to
distribute
their
vendor
stuff,
and
how
do
we
make
all
of
this
work
more
smoothly?
C
I've
been
digging
into
that
alongside
repos
and
index
files
and
stuff,
like
that,
like
one
of
the
things
that
you're
going
to
see
that
I'm
gonna
probably
propose
here
after
I
do
a
little
more
digging
is
maybe
index
JSON
instead
of
index
diamo,
mostly
because
the
parser
uses
one
tenth,
the
memory
that
we
use
today
and
it's
faster.
So
when
it
comes
to
scalability
issues,
that's
a
great
way
to
solve
it.
Let's
get
one
tenth.
The
RAM
use
right
by
just
switching
to
JSON,
I'm
gonna
start
poking
at
some
of
those
things.
C
F
So
those
were
getting
closer
to
having
continual
deployments
on
that
continuous
deployment
on
that
stuff.
Then,
when
I
get
back
or
while
I'm
out
in
Copenhagen
I
have
a
couple
items
to
work
on
on
that
home,
three
spec
dock
and
community
I
think
that's
it
yeah
I
think
that's
it
Justin!
You
wanna
go
yeah.
G
G
A
H
B
What
I'd
like
to
do
is
to
get
a
helm
2.9
release
out
by
the
end
of
the
week,
based
on
just
how
long
the
RC
has
been
out
there
for
I
think
we
basically
beaten
this
ten
worst
all
the
way
down.
If
we
have
any
other
bugs,
we
should
probably
cut
a
2.91
I
think
at
this
point.
So
maybe
that
could
be
a
discussion
point
that
we
want,
but
that's
it
for
this.
For
me
this
week,.
A
A
C
C
A
C
So
obviously
you
can
have
multiple
selections,
but
we
did
get
a
fair
number
of
cluster
operators
involved
in
that
and
we're
also
pretty
early
on
the
early
adopter
phase
of
this.
Let
me
see
dashboard
at
one
of
the
things
that
I
think
mini
cube
came
up
afterwards.
Sorry
I'm
scrolling
to
this.
Just
to
give
you
context
of
what
this
is
in,
if
we
go
to
mini
cube,
one
of
the
things
we
see
about
mini
cube
is
usage
right,
meaning
cube,
which
is
which
you
use
on
your
developer
system.
C
It's
primarily
used
on
Mac,
OS
and
then
Linux
and
then
Windows.
But
if
you
actually
look
at
like
the
stack
overflow
survey
and
you
see
the
primary
developer
operating
systems,
you
see
that
Windows
has
like
forty
nine
point,
nine
percent
of
the
market,
and
so
you
see
we
might
still
be
on
the
early
part
of
the
majority
in
the
adopters
curve,
and
you
can
see
that
we're
still
not
hitting
your
average
developer
because
a
lot
more
of
them
use
Windows
and
not
as
many
are
using
mini
cube
here
and
so
whatever
you
see.
C
C
C
C
This
is
not
like
a
well-documented
templating
system
was
one
of
the
things
that
I
picked
out
of
this
and
some
follow-up
conversations
so
when
we
here
know
actually
digging
into
some
of
the
reasons
for
that
can
bubble
up
some
things
that
we
might
be
able
to
do
to
make
it
better.
So
it's
worth
digging
into
this.
All
of
this
is
in
the
raw
data
as
well.
How
would
you
describe
uses
repository,
so
the
number
one
is
the
community
stable
and
incubator.
C
Then
27
percent
use
something
like
a
prejudice
tree
or
chart
museum
object,
storage
or
static
web
servers
used
by
about
20
percent
19.4,
but
the
next
big
one
on
here
was
using
git
with
no
index
file
or
anything
just
sticking.
Your
church
didn't
get
as
your
deployment
system,
and
that
was
45
percent
and
then
25
percent
just
stuck
it
somewhere
else.
No
version
control,
no
repository,
nothing
else.
C
Plugins,
most
people
don't
use
plugins.
In
fact,
we
you
can
see
some
of
the
plugins.
They
used.
It's
a
variety
of
them,
but
most
people
also
did
even
know.
There
were
plugins
was
not
very
discoverable,
and
so
that's
something
we
might
be
able
to
help
with,
and
then
we
got
into
questions
like
what
do
you
like
about
how
templating
a
common
thing
in
here
was
actually
config
management?
C
C
Well,
you
got
a
hundred
and
twenty
five
of
what
do
you
like,
and
so
there's
a
lot
of
wealth
of
information
here,
community
charts
there
you
know
25
percent
or
more
than
25
percent
of
people
are
operating
community
charts
in
production
and
then
a
lot
of
people
actually
use
it
even
more
use
it
as
the
foundation
for
what
they
do
want
and
they
stored
elsewhere
and
only
20
about
20
percent
use
it
for
demo
purposes.
This
copying
thing
is
more
than
I
actually
anticipated.
C
So
this
was
neat
for
me
to
pluck
this
out,
and
then
we
got
some
quick
things
about
what
do
you
like,
and
what
do
you
want
to
see
change
and
we
got
a
bunch
of
feedback
on
that.
Also,
as
you
can
see,
we
going
to
compose
compose
is
not
highly
used.
All
of
this
data
and
all
these
charts
are
gonna
end
up
showing
up
in
a
slide
deck.
We're
gonna,
try
and
make
it
easy
to
come
to,
but
I
thought
I
would
just
share
that
with
you
all
here.
C
C
C
C
And
we
do
have
it
in
a
spreadsheet
form
where
all
of
the
stuff
is
in
a
spreadsheet
and
then
we
can.
You
can
make
a
copy
of
it
and
slice
and
dice,
and
do
you
want
it's,
not
the
easiest
and
I'm
looking
to
pull
out
some
of
these
to
make
it
little
easier.
That's
what
are
we
doing
the
rest
of
this
week
and
next
week
trying
to
make
the
information
more
consumable?
A
D
E
Okay,
I
actually
have
that
done
that
too.
So,
we'll
start
with
this,
so
I'm
interested
on
people's
thoughts
about
either
getting
more,
maintain,
errs
or
finding
I
know
finding
a
solution
to
managing
all
the
uptick
in
usage.
Because,
as
that,
the
survey
showed
some
more
interesting
light
that
two-thirds
of
the
respondents
I
don't
know,
statistically
how
much
we
could
apply
that
across
to
the
kubernetes
community
or
not
because
it's
not
a
random
sample.
E
But
suffice
it
to
say
that
there's
lots
and
lots
of
like
work
going
on
around
this
and
I'm,
not
sure
I
want
to
keep
responding
to
the
community
and
I
know.
We've
been
slow
on
some
of
these
things
and
not
intentionally
because
we
just
always
are
bogged
down
with
getting
ourselves
out
of
a
hole
of
PRS
and
issues,
and
so
I'm
just
wondering
if
we
can
start
either
enabling
certain
people
who
are
contributing
a
lot
to
the
to
the
queue
who'd
be
willing
to
at
least
like
help
us
with
some
of
the
reviews
and
stuff.
E
C
I
I
had
a
I
had
a
kind
of
a
comment
about
that:
Adam
mm-hmm,
so
I
take
a
look
occasionally
at
issues
that
pop
up
and
I
don't
think
we
have
a
and
ER
great
alaikum.
You
know
list
your
helm
version,
standard,
troubleshooting
or
diagnostic
output,
so
I'm
not
sure.
If
maybe
we
have
a
lot
of
duplicate
issues
or
maybe
we're
assuming
that
it's
in
a
certain
version.
But
you
know
the
issue
is
actually
the
different
one.
If
that
makes
sense,
yeah.
B
We
did
do
an
issue
template,
but
also
something
else
that
was
kind
of
interesting.
That's
actually
stuff
you
brought
up,
which
is
nice,
is
diagnostic
information
in
the
sense
of
like
not
just
the
helm
version,
but
also
just
like
a
lot
of
the
time
slogging
through
the
issue.
Queue
seems
to
be
going
through
and
trying
to
reproduce
the
bug
or
going
through
that
or
going
through
the
steps,
or
at
least
trying
to
figure
out
how
to
go
through
and
reproduce
the
steps.
B
If
there
is
a
way
that
we
could
somehow
reproduce
the
steps
in
a
more
automated
fashion
for
issued
triaging.
That
might
make
a
little
bit
simpler,
but
going
back
to
the
point
about
and
pushing
back
on
features
and
that
kind
of
stuff
and
I
think
that
attests
a
lot
to
like
I
think
it's
just
kind
of
like
a
natural
contention
between
what
is
a
feature
that
we
should
ship
and
what
is
the.
When
do?
B
G
Such
so
subjective,
if
you
don't
want
to
put
someone
in
the
community,
don't
want
to
this
way,
they're
contributing
but
the
same
time
we
can't
be
all
things
to
everyone
and
and
especially
as
we
head
towards
film
3,
you
know,
we've
still
got
a
lot
of
bugs
and
regressions
and
film
to
that.
We
want
to
shore
up.
So
how
do
we
like
kind
of
tone
down
the
feature,
requests
and
get
everybody
on
the
bug?
Train,
yeah,
I,
don't
know
the
answer,
but
I'd
see.
G
A
I,
like
I,
think
about
the
issue,
the
cues
all
differently,
like
my
big
concern
with
the
PRQ,
is
you
know,
I,
don't
really
know
what
where
to
start,
and
it
seems
like
we
and
you
alluded
to
this,
but
it
seems
like
we
just
kind
of
like
get
as
much
as
possible
into
like
the
next
release
and
I.
Think
I
think
we
need
to
like
slow
down
a
little
bit
and
set
expectations
for
the
community
like
just
because
you're.
A
You
know
you
got
your
PR
and
you
got
your
future
and
doesn't
mean
that
it's
going
to
go
out
in
this
next
release.
Maybe
you
know
we
have
too
many
features
and
we
only
feel
comfortable
shipping
X
many
features
together
out
in
a
release
and
and
we
could
like
label
a
future
even
if
it's
reviewed
like
this.
A
This
goes
out
in
the
next,
not
not
in
this
release,
but
the
next
release,
because
it's
maybe
too
close
to
this
to
this
release
or-
or
we
could
just
say
like
you
know
this-
this
is
gonna
take
some
time
and
we
we
just
aren't
going
to
be
able
to
get
it
out
on
this
release.
I
think
I
thought
we
have
to
be
more
comfortable
setting
those
kinds
of
expectations
and,
and
maybe
labeling
like
what
exactly
needs
to
go
in
to
release
I
can't.
A
E
Farina
normally
seems
to
volunteer
himself
for
these
things,
but
I'm
gonna
take
a
stab
at
maybe
defining
the
criteria
for
this,
as
we've
kind
of
talked
about
like
what
what
we
would
consider
ready
for
a
release
and
and
how
we'll
put
it
in
there
and
what's
required
to
get
it
to
that
state
and
then
also
put
together
a
PR
template
all
right.
Sorry,
not
PR
template
issue
template
into
the
repo
I
can
volunteer
to
do
that
next
week.
Not
this
week
and
move
us
forward.
E
A
A
A
Conditions
another
another
stab
at
it
is
excusing
stuff,
I.
Think
you're
talking
also
I
have
a
habit
of
talking
over
people.
So
another
another
ideas,
like
you
know
we
have,
we
could
have
different
levels
of
issue
queue.
A
Triage
errs
like
someone
who
reproduces
and
like
quits
the
label
on
it
and
someone
else
who
maybe
like
needs
to
be
called
to
dig
deeper
because
they
think
this
is
more
like
critical,
but
maybe
it
seems
that
first
facet
I,
don't
know
what
the
levels
would
be,
but
that's
just
another
thought
stuff
did
you
did
you
have
something
you
wanted
to
say?
Oh
I,.
I
Was
just
gonna
say:
even
if
they're
not
contributors,
I
mean
it
takes
more
people
to
say,
go
through
the
bugs
and
label
them
like.
If
you
want
to
go
as
formal
as
issuing
like
a
CBE
score,
it
could
I'm
just
saying
it's
time-consuming,
but
it
could
be
helpful
in
determining
like
which
bugs
are
important
for
a
release.
I.
G
A
F
If
we're
done
with
that,
one
I
think
it's
fine
to
just
go
straight
to
the
two
point:
9.0
release.
Okay,
because
we've
had
I
mean
these.
The
our
CSR
I
mean
at
some
point.
You
got
to
cut
the
Gordian
knot
on
the
RC
and
just
say:
okay,
we're
not
gonna.
Leave
it
open
anymore
to
see
if
anybody
comes
up
with
bugs.
So
let's
just
do
the
release.
Okay,
Astrid
I,
know
and
then
start
then
start
the
to
911
fixes
for
the
next.