►
From YouTube: Charts Chat 20171109
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
Christine
to
a
minimum
we
are
now
recording.
This
is
charts
chat
for
Thursday,
November,
9th
2017
good,
so
I
just
dropped
the
minutes
from
a
way
past
meeting
in
I
might
as
well
update
it
and
go
I.
Think
the
first
thing
o
that
I'd
like
to
do
here
is
actually
discuss.
Recording
of
these
meetings
have
we.
B
C
A
B
A
C
They
have
to
have
a
nominee
or
you
know,
maintainer
and
then
owner
and
all
that
kind
of
stuff
to
come
back
because
I
think
there's
some
charts
that
are
just
kind
of
there.
They
were
put
in
someone
you
know
put
in
a
few
weeks
work
and
then
they
just
got
left
there
and
maybe
did
not
get
download
it
or
use
ever
and
have
not
been
maintained
and
I
did
a
while
back
do
some
work
to
turn
on
bucket
logging
for
our
charts
bucket.
C
C
C
A
A
C
C
That
is
active,
because
some
charts
do
to
get
kind
of
organic
growth
and
organic
and
maintainer
ship
from
different
books
who
contributed
pieces
here
and
there,
and
some
of
us
have
kind
of
taken
that,
on
like
the
Redis
HJ
chart
right
now,
I'm
kind
of
sponsoring
pseudo
sponsoring
despise
making
sure
that
it's
getting
the
love
that
I
mean
I
think
we
should
have
some
thing
like
that,
but
that
pins
an
actual
chart
maintainer
to
that
as
well.
Okay,.
A
A
Then
there
was
this
one
of
when
we
bump
a
version
and
don't
bump
a
version
which
we
talk
a
little
about
on
the
list
and
it
was
kind
of
you
know:
do
we
keep
them?
Can
they
can
they
a
version
ever
change
right
and
I?
Think
what
we
came
to
was.
You
should
never
change
a
version
once
it's
out
there,
yep.
B
B
A
Version,
okay,
then
my
question
becomes
and
I
was
looking
at
the
sinc
script
and
from
reading
the
sinc
script
right,
it
actually
builds
all
of
the
sub
charts
on
every
run
and
then
actually
puts
those
up
there
right
and
so
that's
another
place
where
it's
actually
rebuilding
a
package.
So
it
could
go
through
and
do
the
sync
again
am
I
right
on
this,
and
so
it
could.
D
C
B
A
D
A
A
Was
I
gonna
say
it's
just
me:
well,
the
next
one
on
there
I'll
create
and
document
the
object
version
upgrade
process
so
kubernetes.
Let
me
get
into
this
one.
It
may
not
be
obvious.
Kubernetes
supports
the
latest
version,
the
last
two.
So
right
now,
there's
one
eight
one.
Seven
and
one
six
are
supported.
A
Write
for
beta
api's
kubernetes
says,
will
keep
the
AP
around
for
two
months
or
I'm,
sorry
for
six
months
or
two
releases,
six
months
or
two
releases,
and
so
when
you
think
about
that,
the
beta
ap
is
when
you
look
at
the
rolling
versions
and
what
charts
are
gonna
support?
How
do
we
upgrade
charts?
Because,
right
now
we
put
out
there
and
I
only
put
this
out
there,
because
I
didn't
have
a
better
way
was
to
say
that
the
charts
repo
supports
current
and
current
minus
one.
A
So
one
eight
one,
seven,
but
not
one
six,
because
if
you're
dealing
with
rolling
updates
of
charts,
how
do
you
deal
with
objects
that
work
across
three
versions?
If
you're
only
guaranteed
two
versions
of
support
for
an
API
with
like
the
workload
so
like
with
apps,
you
might
have
Apps
V
1
beta
2
for
a
deployment
right.
You're,
not
gonna,
have
that
across
three
whole
versions.
You
may
not
have
that
across
three
versions
of
kubernetes.
A
So
how
do
you
come
in
with
an
upgrade
cycle
and
then
how
do
we
go
ahead
and
audit
the
charts
repo
to
say?
Oh
all,
these
ones
that
have
you
know,
say
apps
v
1
beta
2.
How
do
we
now
say?
Oh,
we
need
to
go
switch
them
to
apps
v
1,
and
when
do
we
do
those
kinds
of
things,
because
when
one
9
comes
out,
we'll
now
have
two
versions
that
support
apps,
B
1
and
we
can
say:
okay
for
those
now
we'll
do
an
audit
of
everything
and
do
PRS
to
change
those
right.
C
It's
a
lot
of
work
on
the
maintainer
side
to
proactively
go
out
and
do
this.
The
approach
was
so
I
think
it's
still
running.
We
had
CI
again
the
latest
head
of
kubernetes
proper
for
a
subset
charts,
and
that
was
going
to
increase
over
time.
The
number
of
charts
that
got
in
there
and
those
were
charts
that
had
tests
as
well,
and
so
the
idea
was
you
could
know
ahead
of
time
right
now.
We
know
what
will
work
in
1/9
or
some
period
of
time.
C
C
I
want
to
be
able
to
do
a
branch,
for
example,
for
a
major
update
or
a
minor
update
of
a
chart
and
put
a
few
PRS
in
there
and
then
roll
that
out,
rather
than
one
minor
version,
bumper
incremental
change,
and
that
would
allow
us
to
kind
of
bundle
these
future
forward
changes
so
that
we
could
hit
the
button
like
ok,
this
version
of
this
chart,
this
minor
bump
is
now
to
get
us
one,
nine
and
one
eight
support
and
then
hit
go
when
one
nine
is
released.
So
I
don't
know
if
we've.
A
Ya
know,
and
that
makes
sense,
in
fact,
the
window
between
1,
9
and
110
have
like
all
of
that
time
to
upgrade
all
of
the
charts
before
110
rolls
out
and
the
beta
api's
are
gone
and
then
you
know
all
the
church
start
breaking
there.
So
we
do
have
a
small
window
there
of
time
to
do
that.
So
yeah
I,
like
your
idea
of
feature
branches,
though
do
you
think
we
should
have
what
kind
of
pattern
do
you
think
you
look
for
that?
We
have
like
a
very.
B
C
Museum,
for
example,
for
jenkin
I,
see
that
there's
six
things
in
flight
I
want
to
take
an
hour
of
my
day
and
bundle,
those
all
together,
get
them
all
right,
merge,
conflicts
and
everything
and
then
push
one
major
version,
rather
than
what
I
do
now,
with
a
lot
of
charts
that
have
multiple
things
in
flight
is
merge
version
0,
3,
1,
then
0,
3,
twos
and
0,
3,
3
and
really
most
people
are
only
going
to
see
0
3
3
anyway.
So
instead
of
strange
for
folks,
they
go
from
zero.
C
Three
zero,
two
zero
three
three
in
one
day,
so
that's
that's.
What
I
seen
I
haven't
really
thought
of
a
mechanism
that
this
repo
can
provide.
That
scales
well
with
the
number
of
charts
and
versions
that
we
have
I.
Think
convention
on
branch
names
is
about
as
good
as
we
could
do
right
now
and
then
how
do
you
tell
people
sending
PRS
that
that's
where
they
should
go?
Unless
you
do
that
ad
hoc
to
begin
with?
And
then,
hopefully,
the
convention
spins
up.
C
A
C
C
A
C
B
B
Wasn't
it
wasn't
moving,
client-side
or
or
being
able
to
spoof
it?
There
was.
There
was
an
issue.
I'm
feel
this
capabilities
so
that
you
could
do
a
debug,
sure,
I,
run
or
a
template,
and
but
you
know
and
specify
your
API
version.
B
And
then
yeah
and
then
of
course,
having
Javier
templates
render
according
to
their
capabilities.
A
B
A
C
A
A
B
Because
right
now,
I'm
required
if
a
required
variable
is
missing,
rendering
fails,
not
you
know
not
deployment
but
rendering.
So,
as
you
know,
so,
as
we
run
it
through
the
linter
and
in
the
case
of
cube
Lego
I
used
to
provide
a
default
value
for
the
email,
but
then
people
weren't
bothering
to
read
the
readme
kind
of
change
that
email
address
and
the
upstream
project
was
getting
complaints
that
people
weren't
getting
notifications
when
they're
when
their
certificate
expired.
B
C
Roached
that
the
other
terms
that
require
stuff
in
order
for
things
to
function
properly
and
even
if
the
upstream
is
to
just
not
actually
deploy
the
thing.
So
if
you
you,
you
can
have,
you
know
a
fake
email
in
there,
but
it
just
won't,
deploy
the
deployment
or
whatever
right
and
then
people
won't
be
able
to
use
that.
D
C
A
B
C
A
C
Yeah
so
I
have
a
few
contact
coming
up
about
the
patterns
we've
seen
in
in
this
repo
and
and
it's
kind
of
strange,
because
I
think
there
are
like
for
creating
a
public
shirt.
There
are
different
best
practices
than
for
creating
you
know.
Maybe
there's
a
super
set
of
best
practices
in
creating
a
private
chart,
so
I
think
we
should
start
to
get
our
own
list
of
public
chart
repository
best
practices
in
our
repo
like
like
this
one.
Okay,.
C
A
A
I'm
gonna
keep
going
here
because
we've
only
got
a
few
minutes
left
and
there's
three
bullet
items.
I'm
gonna
see
if
we
can
get
through
them
all
so
there's
one
was
to
the
prowl,
can
automatically
close
old
issues
and
PRS
that
have
not
had
any
activity
on
them.
Should
we
see
about
getting
that
implemented?
It.
B
C
C
Let
me
get
the
data
out
there
and
get
a
simple
report
to
say
these
are
the
bottom
most
and
say:
here's
a
10,
bottom,
most
or
or
I.
Think
we
detective
yes
anyway
and
try
to
present
in
the
in
the
next
charts
chat
and
see
what
we
want
to
do
and
and
how
many
there
are.
We
might
find
that
there's
only
two
or
three
and
we
just
do
it
and
be
done
with
it.
We
might
find
that
there's
20
and
we
need
to
actually
do
a
lot
more
work.
A
A
D
First
time
joining
and
I
just
this
is
a
question
that
I've
had
I
want,
like,
for
example,
to
kafka
chart
is
something
that
I've
been
looking
at
incubator
channel.
It
looks
kind
of
stale
some
thing
I
want
to.
You
know,
help
pick
up
and
make
a
bunch
of
improvements
to,
and
this
kind
of
relates
to.
The
first
thing
you
guys
talked
about
as
far
as
like
an
owner's
file
go
so
like
what
are
what
are
best?
Practices
is
sort
of
a
new
new
wannabe
contributor,
I.
C
C
Others
have
just
submitted
a
PR
or
a
set
of
the
ours,
and
those
have
eventually
gotten
attention
if
you're
going
to
just
take
ownership
of
it,
of
something
that
stale
I
would
make
a
you
know
best
case.
Pr
like
this
is
the
end
state
that
I
want
to
get
to
and
say
you
know.
This
is
a
work
in
progress.
Okay,
I'm
done
I'm
happy
to
do
be
a
sponsor
on
the
cat
:
and
that
one
is
of
interest
in
I.
C
A
C
C
The
other
thing
that
I
do
is
kind
of
sponsor
particular
charts
for
the
stage
a
cop
car.
Now
at
the
top
of
my
list,
concours
is
in
the
past.
So
that's
just
my
approach.
If
people
do,
you
know
find
themselves
with
30
minutes
or
an
hour
time,
I
think
it's
a
really
good
way
to
just
get
the
cue
down,
which
is
my
anxiety,
Rises
with
the
the
size
of
the
park
you.
So
that's.
C
B
A
Yeah
I'm,
actually
looking
at
this
going
over
the
last
month,
we've
closed
136,
PRS
or
merge
136
PRS
and
there
have
been
95
new
ones,
so
we're
keeping
we're
actually
improving,
but
on
the
issue,
sized
we've
closed
15
issues
and
opened
56
new
ones,
but
I
can
never
get
myself
into
the
issues
because
I'm
trying
to
keep
us
ahead
way
in
the
PRS
and
that's
all
I
really
think.
There's
a
lot
of
old
issues.
Can
they
be
auto
closed?