►
From YouTube: Charts Chat 20180123
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
B
A
Wall
goes
down
on
our
permanent
records.
This
will
all
go
down
on
your
permanent
records.
That's
right
and
let
me
grab
the
charts,
chat,
meeting
stuff
and
toss
it
here
into
the
text,
so
y'all
can
follow
along
and
so
the
first
thing
we
had
is
github
IDs
ID.
None.
Since
you
threw
this
up,
you
want
to
pick
it
off.
Yeah.
C
So
my
idea
was
that
I
think
everyone
who
is
signing
up
to
being
owners
should
essentially
be
in
the
chart,
but
ya
know
as
well.
There's
no
reason
why
they
shouldn't
be
and
I'd
kind
of
like
for
those
two
things
to
match
up
and
not
you
know,
differ
too
much.
The
one.
The
one
thing
where
I
think
we
can
vary
is
if
someone
wants
to
add
an
organisation
which
I
think
we
discussed
last
time
as
well
and
I.
C
Think
we
decided
organize
organizations
are
fine,
I
think
as
long
as
they
their
github
orgs
as
well,
so
that
people
can
find
more
things
there
and
that
would
be
mostly
for
metadata
purposes.
Obviously,
you
wouldn't
have
an
organization
in
the
onus
file,
so
so
yeah
so
I
think
could
be
fine
to
have
extra
maintainer
zin
in
the
onus
file
that
not
sorry
in
the
chocolate
yellow
filed
a
nine-year.
C
As
far
as
long
as
their
organizations
I
talked
to
Josh
offline
and
his
main
concern
was
like
he
didn't
want
his
email
address
in
the
chat,
llamo
Robin
and
just
having
his
github
ID.
So
he
was
fine
having
this
github
ID,
which
is
fine,
because
he
didn't
realize
that
the
email
was
actually
optional.
Should.
A
We
point
out,
then,
maybe
in
the
documentation
that
your
name
github
ID
for
at
least
one
real
person
is
required,
and
then
you
can
optionally
add
either
an
email
address
or
URL
okay,
because
there's
a
URL
field
as
well
to
another
location
such
as
an
issue
queue
or
things
like
that
or
your
personal
website.
However,
you
want
to
do
things,
but
you
can
do
either
of
those
right
mm-hmm.
C
A
In
owners
to
get
in
to
the
owners
file,
you
have
to
become
and
to
be
able
to
do
anything,
you
have
to
become
a
member
of
the
kubernetes
organization,
so
you've
actually
had
to
contribute
stuff
and
sometimes
people
stick.
People
who've
never
contributed
anything
or
been
in
a
pull
request
in
the
chair
maintains
file.
I've
discovered.
A
A
C
A
C
C
C
B
A
A
B
A
A
A
C
C
A
C
A
Some
incubator
charts
depend
on
other
incubator
charts,
so
if
you
move
it
from
incubator
to
stable,
then
we
either
need
to
update
the
other
incubator
charts
at
the
same
time,
to
point
to
the
stable
repo
now
or
we've
got
to
do
something
like
that,
because
if
you
move
an
incubator
chart
to
stable
and
other
incubator
charts
depend
on
it
now,
you've
broken
those
incubator
charts
just
because
of
the
requirement
dependencies
and
I
wasn't
sure
how
we
wanted
to
handle
that
do
we
leave
the
old
incubator
one
there
and
market
is
deprecated.
Do
we
go
update?
A
A
C
Think
that
is
true,
but
but
in
general
I,
don't
think
that
any
stable
shot
chart
should
include
anything
from
incubator.
I.
Think
that
inherently
makes
it
incubate
if
it's
anything
from
the
one,
the
one
place
where
I
did
see
this,
which
is
the
chart
museum
PR,
is
using
the
common
chart.
So
that's
somewhat
of
a
special
case
where
I'm
inclined
to
just
let
it
let
it
pull
the
incubator.
Remember
it
packages
the
dependency
and
and
vendors
it
in
in
in
the
actual
fact.
A
A
No,
but
there
are
charts
an
incubator
that
point
to
other
incubator,
and
there
was
one
today
that
I
was
looking
and
I'm
like
you
know
this
one
might
be
ready
to
move
to
stable,
but
it's
depending
on
to
other
incubator,
charts
and
I'm
like
well.
If
it
moves
over,
then
what
do
you
do
and
what,
if
you
move
one
of
its
dependencies
over
from
an
incubator
to
stable,
so
I'm,
looking
at
a
chart
that
depends
on
two
incubator
charts:
what
if
one
of
those
dependencies
is
moved
to
stable?
How
does
that
continue
to
work?
A
Because
the
next
time
they
go
to
work
on
it
right,
their
dependency
has
moved
and
date
they
don't
have
an
update.
They
don't
know
all
the
sudden
it's
broken,
and
so
it's
being
able
to
manage
that
we
shouldn't
leave
dead
links
when
we
move
something,
and
so
do
we
either
copy
the
chart
over
and
mark
the
incubator
one
as
deprecated
with
a
note
saying
this
has
been
moved
to
stable
or
do
we
update
the
links
in
the
other
dependent
charts
that
are
that
we're
managing
here
to
say:
okay,
this
is
now
in
the
stable
repository.
C
C
So
this
adults
actually
have
more.
That's
that's
what
we
discussed
a
lot
of
time,
which
we
were
supposed
to
do,
but
haven't
really
been
doing
when
a
chart
moves
so
so
far
when
we've
moved
charts
from
stable
to
incubator,
we
kind
of
just
moved
them
over
and
left
no
source
behind
in
the
incubator,
which
caused
some
issues
and
so
and
I
still
have
the
the
action
item
to
go
back
and
deprecated
some
of
those
old
which
also
have
been
moved,
but
I
lost
my
trainer
for
now.
A
C
B
C
Going
for,
if
we're
moving
stuff
from
from
incubators
stable,
we
mark
the
incubator
charters
as
deprecated,
and
this
you
know
this
makes
it
not
conflict
with
other
with
the
witness
table
chart
like
it
doesn't
in
monocular.
If
you
leave
them,
if
you
leave
the
month,
okay
monocular
can
actually
handle
that
because
remember
the
the
actual
chart
in
the
repository
will
still
be
there.
C
So
if
you're
reading
from
the
incubator
upholstery,
you
won't
really
notice
that
it's
deprecated,
unless
you
actually
add
that
and
that
tag
and
of
course,
if
the
chart
moves
from
incubate
disable,
it's
kind
of
implied
that
the
incubator
chart
is
it's
deprecated.
No,
and
it's
no
longer
gonna
be
to
bed
up
there
right,
but
a
dependency
case
is
a
little
yeah
I'm
a
little
unsure
about
that
I
think
in
general
we
don't
want
stable
charts
to
reference
yeah.
A
B
Doing
so,
do
we
have
procedures
section
of
the
docs?
Yes
like
deprecating
a
chart
or
moving
to
stable
or
something
like
that,
because
it
seems
like
we're
starting
to
get
into
some
complex
workflows
where
either
we
need
automation,
or
at
least
some.
You
know
detailed
steps
on
what
to
do
so.
We
don't
screw
it
up.
Yeah.
B
C
So
far,
the
deprecation
policy
has
been
in
the
helm,
Docs,
it's
kind
of
just
mentioned
there
and
when
it's
describing
the
deprecated
field.
I
just
mentioned
that
this
is
what
we
do
in
Java,
which
actually
is
out
of
date,
because
it
used
to
say
that
we
would
remove
the
source
from
the
repository.
But
that's
not
known
on
the
true
and
I
think
it
makes
sense
to
have
to
have
a
procedures
Docs
in.
C
A
C
Right
but.
C
A
All
right,
the
next
one,
so
there's
this
Prometheus
pull
request
and
I
was
gonna.
Bring
it
up
more
in
general
to
it
seems,
mr.
goodness,
has
not
been
around
lately
and
here's
a
bunch
of
charts
and
some
of
this
stuff
is
more
complicated
than
or
I'm
just
not
familiar
with
the
charts
or
the
applications
and
so
I'm
worried
to
look
you
know.
B
Yeah
I
mean
on
this
I'm
good
to
kind
of
let
it
let
it
fly.
It
looks
like
there's
tens
of
people
interested
in
this
getting
in
so
I'd.
Imagine
those
tens
of
people
will
be
interested
in
patching
it,
or
at
least
one
of
the
ten
will
be
interested
in
patching
it
to
to
get
it
up
to
date.
As
long
as
there's
a
major
version
bump,
you
know,
I,
don't
know
how
much
more
we
can
do.
I
mean
not
knowing
you
know,
probably
kiss
internals
super
super
deeply.
B
A
I've
tried
to
ping
him
a
few
times
I'm
a
few
of
the
different
cards
he's
a
case
where
he
actually
own
easy.
The
owner
of
a
bunch
of
charts
and
I
hadn't
been
able
to
get
ahold
of
him
for
any
of
them.
He's
just
whatever's
going
on
he's,
not
engaged
right.
Now,
that's
one
of
the
things
that
I
might
be
a
good
recommendation
for
folks
to
is
try
to
have
more
than
one
chart
maintainer,
because
people
come
and
go
things
happen.
A
If
you
look
at
projects
over
time,
you'll
see,
sometimes
one
person
is
more
engaged
other
times
other
people.
We
were
even
talking
about
that
recently
on
how
kubernetes
cores
that
way.
Right
from
from
release
release,
you
might
seem
different
people
doing
a
lot
of
the
reviews
and
stuff
because
of
what's
going
on,
and
so
that
might
be
a
good
recommendation
for
folks
all
right,
yeah.
C
B
C
For
adopting
charts
that
you
know,
we've
lost
maintain
us
for
so
we
may
want
to
decide
on
a
certain
mountain
time
where
we
considered
maintain
us
to
have
abandoned
and
chart
and
then
maybe
create
an
issue
or
something
for
it
and
ask
people
if
they
want
to
adopt
it
and
then
get
an
you
maintain
it
for
it.
That
way,
because
you
know,
as
you
said,
there's
quite
a
few
people
interested
in
this
as
I'm
seeing
44
comments.
C
A
A
B
A
All
right
so
the
next
one
I
had
was,
should
we
run
the
meetings
like
the
helm,
one
I've
kind
of
been
going
through
the
last
few
meetings
and
making
sure
we've
got
discussion,
agendas
and
trying
to
curate
stuff.
So
we
have
those
and
then
I
come
in
and
I
hit
record
and
I
go
upload.
The
video
should,
we
kind
of
you,
know
I
I'm,
okay,
doing
this,
but
I
think
we
should
democratize
it
and
maybe
have
more
folks.
A
Do
it
that
way
and
just
curate
it
and
make
sure
everything's
done
and
and
I'm
not
sure
whether
it
cuz
they
felt
like
the
issue
share.
Boo,
says:
I
will
go.
Do
this
and
one
of
the
things
just
sees
my
next
topic
is:
how
do
we
encourage
more
reviews
because
right
now,
I'm
noticing
the
maintainer
--zz?
Many
of
us
are
not
getting
a
lot
of
reviews.
Vic
are
up,
renard
is
killing
it,
but
he
can't
known
oh
yeah.
B
B
We
don't
really
have
a
carrot
in
this
situation,
for
getting
people
to
do
reviews
so
I
think.
Maybe
we
can
start
with
that.
What
is
that?
What
is
the
benefit
of
doing
reviews
personally
I'm
just
invested
in
in
charts
and
have
seen
this
grow
so
I
have
personal
attachment
to
it.
So
that's
why
I
do
it
and
I
stick
around
what?
What
other
reasons
can
we
have
for
for
folks
to
want
to
do
this
stuff
or
to
for
companies
or
or
creators
of
software
to
want
to
maintain
their
own
right?
B
A
There
are
several
that
I've
helped
I've
actually
got
an
open
PR
for
one,
that's
several
weeks
old,
that
nobody's
merged
to
just
add
an
owner's
file.
There's
a
couple
of
really
easy
ones
like
that
that
folks
haven't
merged.
In
fact,
that's
actually
been
one
of
my
frustration.
I've
got
to
one
that
improves
the
debug
logs
by
grabbing
all
the
pod
logs,
actually
all
the
container
logs
on
all
the
pods,
because
you
can
have
more
than
one
container
per
pod.
A
A
B
B
So
yeah
I
think
what
other
thing
we
could
do
is
we
tried
a
while
back
to
have
some
sort
of
prioritization
mechanism?
I,
don't
know
that
we
have
that
anymore
of
saying,
like
hey,
if
you
do
have
a
car.
These
are
the
six
things
to
look
at
first
to
see
if
you
can
help
with.
Sometimes
we
want
to
implement
something
like
that.
Have
like
a
hot
list
or
something
like
that.
That
says:
hey,
you
know
when
you
do
that
time.
This
is
the
first
thing
to
look
at
and
look
at
your.
C
Think,
as
we
positively
maintain
is-
and
this
will
obviously
become
easier
once
we
have
earnest
files
across
the
board-
and
we
have
you
know
other
people
merging
their
own
POS
for
their
own
charts.
Our
focus
will
be
on
the
sorts
of
thinking
these
automated
and
things
owned
as
files
and
approving
those
kind
of
things
that
that
our
chart
mean
other
taught
me
to
him
is
not
repairmen.
Containers
will
be
able
to
do
so
and
I
think
Vic.
The
the
prioritization
thing
you're
referring
to
is
the
milestone
stuff
that
we
tried
before
yeah.
B
C
C
A
I
brought
it
up
in
a
couple
of
other
venues
and
it
is
linked
off
of
the
community
repo
if
people
want
to
go,
find
it
there.
So
the
details
are
shared
and
a
couple
of
times
I
did
have
early
on
when
we
were
doing
this
and
I
first
shared
it.
There
were
weeks
where
I
was
the
only
one
who
showed
up
and
then
some
other
people
in
the
community
showed
up
okay,
because
once
we
got
the
new
time
we
started
organizing
more.
A
A
C
A
B
B
B
A
Need
to
select
the
link
that
I
dropped
in
to
you
and
slack
was
for
somebody
who's
waiting.
They
listed
you
as
the
second
one,
with
their
contributions
and
they're
just
waiting
for
a
plus-one
reply
to
that
from
you
and
then
they'll
get
the
invite,
but
that's
it
yeah.
You
need
to
sponsors
who
are
already
members.
Oh.