►
From YouTube: Kubernetes WG LTS 20181127
A
B
B
B
Welcome
everybody
to
what's
technically
our
second
workgroup
LTS
meeting.
We
had
a
initial
one
with
just
a
couple
of
attendees
two
weeks
ago
that
was
sort
of
like
unannounced,
yet
because
we're
still
getting
things
in
line
to
get
announced,
but
the
we
actually
had
a
pretty
good
discussion.
I
feel
like
in
the
recording
of
that
is
on
YouTube
already.
We
were
still
dealing
with
zoom
credentials
and
YouTube
credentials
and
all
of
that
startup
stuff.
B
So
it's
out
there,
but
this
I
feel
like
is
kind
of
the
first
real
meeting,
because
we've
had
a
little
bit
more
of
an
announcement
and
obviously
have
more
folks
here.
So
welcome
to
everybody.
I
don't
know
if
folks
want
to
do
a
little
bit
of
a
short
intro,
since
we've
got
more
people
here,
just
kind
of
mention.
Why
you're
here?
What
you're
interested
in
would
folks
like
to
do
that
for
a
start
for
a
few
minutes
or
just
dive
in
to
topics.
C
B
C
B
And
I
should
mention
I'm,
Tim
pepper.
If
you
don't
know
me
how
to
change
my
name
from
work
group
LTS
to
Tim,
pepper,
I
worked
at
VMware,
we
have
an
interest
in
how
one
operates
and
deploys
kubernetes
and
supports
it
over
time.
So
that's
kind
of
our
angle
on
this,
but
why
don't
we
I
guess
nobody
said
yes
or
no,
but
I'm
just
gonna
go
through
and
call
it
people
so
Roger
you're.
Next
in
in
my
list.
B
C
I
am
a
programmer
at
VMware
and
mine.
Just
an
idea
started
when
I
sit
with
a
pitch
with
the
working
group
started
when
I
joined
in
1.12,
Willy's
and
I
found.
There
were
a
lot
of
things
that
people
were
raising
about
the
release
cycle
and
I
thought
there
were
a
lot
of
problems
that
needs
to
be
fixed
yeah.
So
that's
why
I
thought
that
working
group
to
discuss
all
the
different
possible
solutions
to
this
problem
needs
to
be
discussed.
It
needs
to
be
a
single
platform
where
all
of
his
different
stakeholders
can
connect
and
join.
D
I'm
Jim
angel
McCloud
administrator
at
General
Motors
supporting
the
kubernetes
deployment,
also
pivotal
Cloud
Foundry,
we're
currently
on
196
in
production
and
we're
having
struggles
with
the
upgrade
strategy
and
the
release
cycle
there
and
being
part
of
the
release
cycle.
I
see
all
what
goes
into
it
and
kind
of
have
a
good
pulse
on.
D
What's
going
on,
I
was
coming
through,
so
it's
not
really
an
issue
as
far
as
knowing
what's
coming
down
the
road,
it's
the
enterprise
roadblocks
have
been
able
to
upgrade
every
three
months
and
so
I'm
not
saying
that
long
term
or
the
LTS
long
term.
Support
is
really
what
we
need
per
se,
but
I'm
really
interested
in
discussion
in
the
direction
of
where
it's
going
and
kind
of
the
general
thoughts
of
the
community.
So
I
can
be
in
line
with
that,
as
we
crater
on
up
great
strategy
here
at
General,
Motors
I.
B
Think
that's
one
of
the
key
things
we
want
to
do
is
just
be
understanding
what
people
are
seeing,
cataloging
that
and
then
doing
some
definitions
like
one
of
the
the
initial
questions
is
well.
What
do
you
mean
by
LTS
and
certain
people
here
are
certain
things
there
and
is
that
the
answer
or
is
something
else,
the
answer
that
we
explore
this
openly
Jordan
Liggett.
E
Hey
I'm
Jordan,
like
it
I'm
at
Google,
now
I
was
at
Red
Hat
for
a
few
years
before
that.
So
I've
worked
with
a
lot
of
posted
and
on-premise
installations
and
look
a
lot
at
API
and
compatibility.
Config
compatibility
across
releases
and
I'm
really
interested
in
trying
to
reduce
pain
of
upgrades
and
find
out
what
is
painful
about
upgrades.
And
how
can
we
make
those
non-events
both
in
how
we
prepare
for
them
and
what
we
do
in
the
kinetics
project
and
how
we
communicate
out
to
our
users
cool.
F
B
G
Yes,
hi
I'm,
a
software
engineer
at
the
Texas
Advanced
Computing,
Center
I'm,
actually
relatively
new
contributor
to
the
whole
kubernetes
community,
so
I'm
still
getting
I'm
still
trying
to
get
the
whole
thing.
Hang
of
a
all
the
working
group
six
and
all
that
food
yeah
I
got
interested
in
the
working
group
also
to
try
to
to
try
to
see
where
I
can
help
and
try
and
make
upgrades
as
painless
as
possible.
Cool.
H
I
B
K
Yes
and
sorry,
I'm
late,
I'm,
Quentin
I
think
I
probably
have
run
into
more
than
one
of
you
more
than
once.
Tim
asked
me
to
kind
of
provide
some
insight
here
and
also
from
always
side.
We
have
lots
of
communities
based
products,
both
on-premise
and
public
cloud,
and
all
of
them
struggle
with
version
compatibility
issues
and
managing
long-term
support,
particularly
for
enterprise
customers
and
Tim
Sinclair.
L
L
For
those
who
don't
know,
I
have
a
long
history
in
this
space
of
long
term,
support,
in
fact,
Tim
Hopkins
and
I
started
may
best
be
described
as
a
nerd
fight
a
long
time
ago,
and
then
we
started
an
email
thread
which
had
this
conversation
piece,
which
then
led
into
his
talk
and
then
also
sprawled
into
the
other
topics
and
I
know
I
kind
of
poked
the
hornet's
nest
repeatedly
on
this.
The
reason
why
I
care
about
this
so
much
is
and
being
a
sequester
lifecycle
lead.
B
Totally
agree
on
Tim's
talk,
Tim
Tim
Hawkins
talk
last
year
at
cube,
cotton
like
totally
resonated
with
me,
but
then
somehow
you
got
to
start
driving
this
into
action.
We
can
mean
throw
some
ideas
out
there
talk
about
what
it
might
be,
but
then
at
some
point
some
of
us
have
like
the
it's
open
source.
We
got
to
make
it
happen.
If
we
like
it
want
it,
and
then
we
see
the
user
pain,
Zach,
Shepard,
hi.
M
B
B
And
I
think
encourage
people
to
like
I'm,
somewhat
surprised.
The
number
of
vmware
people
call
today,
but
help
start
spreading.
The
word
like
one
of
the
things
that
I
really
want
to
get
here
is
a
good
diversity,
not
just
in
like
the
corporate
sponsor
side
of
things,
but
in
the
kubernetes
user
base
or
developer
base.
Both
of
those
need
to
be
present
here
and
like
that
was
part
of
the
reason
I'd
reached
out
to
Quinton,
as
somebody
as
a
co
organizer,
really
the
huawei
company
perspective
and
the
set
of
users
that
they
support.
C
B
This
is
something
else:
I
guess
we'll
need
to
talk
about
eventually,
but
we
have
people
in
broader
time
zones
who
are
interested
in
participating.
Also
so
I
want
to
set
up
a
second
time
meeting
to
try
and
pull
in
some
of
those
folks,
so
I'll,
maybe
do
a
doodle
or
something
and
try
and
get
more
focus
on
Nick
is
in
Australia,
particularly
but
two
weeks
ago
now
it
cube
con
China
I
talked
to
a
number
of
folks
who
are
interested
in
being
involved
in
these
discussions
and
are
interested
in
the
outcomes
as
well.
B
So
yeah,
we'll
figure
that
out
we've
got
cube
con
coming
up
in
just
a
little
while
again
North
America
and
then
the
end
of
your
holidays
around
the
world
as
well.
So
I
think
things
were
probably
going
to
be
a
little
disjointed,
but
hopefully
in
January.
We
can
then
start
regular
meetings
on
a
schedule
that
pulls
in
people
broadly,
so
it
thrown
a
couple
things
on
the
agenda
for
the
day
to
try
and
talk
about
I
guess
so,
the
three
of
them
there's
a
version
skew
documentation,
PR
out
against
the
website.
B
B
So
have
folks
here,
seeing
that
first
one,
the
website
poll
1106
t-to
people
have
thoughts
on
it.
Jordan
do
you
have
things
you
want
to
bring
up
here.
E
I
tried
to
kind
of
call
out
some
of
the
open
questions
that
were
being
raised
by
people
in
comments
and
also
questions
that
I
asked
myself.
While
I
was
writing
it
there's
kind
of
break
down
into
two
categories.
One
is
around
like
specific
components,
so
I'm
still
hunting
down
representatives
that
maintain
those
components
to
try
to
understand
what
what
they
test,
what
their
expectations
are,
what
they
support.
But
then
there
were
a
few
broader
questions,
specifically
around
kind
of
upgrade
testing.
E
E
B
B
Guess
kind
of
echoing
Tim
Sinclair,
like
you
you're
kind
of
kicking
the
nest
with
this
and
it,
but
it's
it's.
It's
really
timely
and
needed.
So
the
the
conversation
has
started
out
good
and,
like
you
say,
going
out
and
finding
the
people
to
in
nudging
them
to
chime
in
one
question
that
I
had
that
I
don't
know
if
I
put
this
in
the
PR,
but
there'd
been
a
little
bit
of
discussion
about
as
we
catalog
this
where
it
should
live
like
do
you
feel
website
is
the
right
place
or
I
mean.
B
E
Of
authoritative
documentation,
somewhere
else
and
website
documentation,
that
is
like
a
projection
or
an
updated
copy
of
that
those
are
inevitably
going
to
drift
exactly
formal
guarantees
and
what
we
support
are
not
the
kinds
of
documents
you
want
to
drift
like
you
want
everyone's
understanding
to
be
the
same.
So
so.
B
B
The
other
thing
then,
with
that
is
some
of
I,
don't
know
if
how
much
this
is
going
to
end
up
being,
like
I,
think
you've
done
a
good
job
of
being
agnostic
and
not
getting
into
like
a
list
of
components
and
version
specifically
but
I.
Wonder
like
the
the
kernel
versus
distro
talk
at
some
point.
Like
things
start
looking
like
a
distro,
and
you
end
up
with
a
list
of
support,
supported
like
a
support
matrix.
E
E
E
L
Had
this
conversation
in
the
sequester
lifecycle
space
for
a
long
time
of
what
support
means
and
what
things
are
in
purview
and
when
things
are
out
of
purview
and
we
explicitly
in
the
in
the
creation
of
Kuby
DM,
we
explicitly
stated
that
it's
only
the
management
of
the
control
plane,
components
that
are
required
right
in
the
version
ski
within
the
control
plane.
Anything
else
has
been
punted
to
add-ons
so
even
CNI
integration
or
CSI
integration
or
what,
whatever
you
want
to
call
it,
because
that
limits
and
binds
it
bounds
the
scope.
L
But
then
you
still
have
some
things
that
are
in
that
space,
like
the
CRI
which
are
required
in
order
for
you
to
actually
do
validation
and
verification
right,
so
I
think
in
numerating
I,
don't
think
it's
required
for
your
document
to
get
merged
and
I
think
that's
not
even
necessary
for
that
duck.
Butt
or
not.
E
L
E
E
B
From
a
support
perspective
like
I,
flew
with
a
release,
team
hat
on
I
would
argue
that
downgrade
is
not
supported
with
its
relief
locking
yeah
but
who
owns
fixing
it.
Somebody
at
Google
cares
about
that.
We
can't
reliably
get
them
to
care
about
it.
Last
week
a
week
before
cube
con
China
Google
folks
told
me
like.
Actually
they
don't
care
about
it.
They're
thinking
about
spinning
sometime
next
year,
trying
to
make
it
work
reliably.
E
I
would
disagree
with
that
actually
I
think
anyone
who
does
rolling
upgrades
cares
about
downgrade
working,
whether
they
know
it
or
not.
If
you
are
upgrading,
if
you're
doing
a
rolling
upgrade
and
you
expect
to
be
able
to
roll
back
if
the
first
one
that
comes
up
encounters
problems,
then
you
rely
on
downgrade
working.
Yes,
sir.
B
L
If
we
we
want
to
take
up
that
conversation
here,
I
do
think
that
a
kind
of
blood
bleeds
over
this
space.
We
could
have
an
entire
discussion
just
on
downgrades
and
immutability
downgrades
for
rolling
updates
versus
immutability
and
how
you
do
a
versus
B,
and
why
a?
What
are
the
requirements
and
what
are
the
benefits
and
where
that
cost
right?
L
E
Library
I
want
to
recognize
where
we
are
and
make
clear
what
scenarios
are
currently
tested
so
that
users
understand
where
we're
at,
and
we
are
aware
of
the
consequences
of
any
changes
people
propose.
So
if,
if
we're
testing
a
rolling
upgrade
downgrade
and
someone
wants
to
make
a
change,
that
would
break
that.
We
need
to
consider
that
proposal
with
eyes,
open,
saying
this.
This
is
going
to
lose
us
this
level
of
support.
E
I,
don't
disagree
that
the
support
is
weak,
but
it
is
present
and
we
need
to
decide
if
we
want
to
strengthen
that
or
abandon
it
and
both
of
those
there
are
reasons
in
favor
of
both
of
those
that
we
need
to
think
through.
What
I
don't
want
to
do
is
to
say
the
support
is
weak.
So
let's
equate
that
with
we
don't
support
it
at
all
and
as
soon
as
you
give
up
that
test,
it
will
immediately
be
broken,
and
then
the
decision
has
kind
of
been
made
without
consideration.
So
I.
C
B
E
B
K
You
know
two
hours
figuring
this
area
out
and
then
we're
gonna
move
on
to
the
next
area,
and
we
know
we've
got
you
know
five
areas
or
whatever
they
are
and
therefore
the
end
goal
is
February.
We
have
five
of
these
areas
fleshed
out,
because
I've
got
a
fear
that
that
there
is
so
much
detail
in
here
that
we
could
just
wander
around
aimlessly
in
the
detail
for
months
on
end
and
perhaps
not
end
up
yeah.
B
I
think
that's
a
good
transition,
maybe
to
the
next
thing
that
probably
should
have
been.
First
then,
on
the
agenda.
I
mean
Jordans
be
are
being
in
flight
like
it's
good
to
get
documented
where
we
are
today,
but
then,
as
a
working
group
charter.
What
what
are
we
going
to
declare
in
scope
and
out
of
scope,
deliverables,
timeline,
sorts
of
stuff?
B
K
I
personally,
have
not
I
was
just
wondering
I
mean
it
seems
like
if
we're
dealing
there
with
version
compatibility
and
skews
between
masters
and
nodes,
and
these
kinds
of
things
I'm
not
even
necessarily
convinced
that
that
is
the
core
of
the
antrum
support.
I,
think
I
think
it's
a
potentially
a
small
part
of
it,
but.
L
Think
we
should
probably
break
down
and
numerate
the
state
space
of
problems
and
I
think
that
kind
of
leads
into
the
next
topic
that
Tim
wrote
down.
There
is
like
the
questionnaire
like
I
I
have
a
lot
of
feedback,
but
it's
it's
very
noisy
opinionated
feedback
from
customers
and
users
and
I.
Think
having
you
know,
actual
good
signal
from
a
wider
swath
of
the
ecosystem
would
be
super
beneficial
to
make
informed
decisions.
B
H
I'm,
just
like
I
presume
Jordans
goal
was
to
was
the
LTS
would
mean
skipping
versions,
and
we
have
to
would
presumably
mean
skipping
versions,
and
we
have
to
be
aware
of
the
skew
policy.
I
also
wanted
to
clarify
that
or
question
asked
a
question
which
is
I,
think
Jordans
done
a
great
job
of
documenting
the
current
skew
policy,
but
I
wanted
to
be
that
we
were
not.
Could
we
consider
changing
that
skew
policy
to
be
in
scope
right?
In
other
words,
if
we
decide
we
need
seamless
upgrade
downgrade
across
multiple
skipping
versions.
We
can.
B
Yeah
I
think
that's
one
of
the
outcomes
and
what
I
want
to
try
to
do
so,
because
this
is
has
the
potential
to
ramble
and
also
rat's
nest,
get
very
opinionated.
A
working
group
isn't
necessarily
required
to
have
a
charter,
but
by
putting
something
out
there.
That
says
like
here
are
the
things
we
think
are
in
scope
out
of
scope
possible
deliverables.
B
This
could
be
just
a
set
of
point
changes
to
how
we
do
things
in
cluster
lifecycle
in
release,
or
it
could
be
something
broader
like
changing
the
skew
policy,
but
that
it's
open,
because
you
gotta
have
a
name
for
the
group
and
when
you
say
working
group
LTS,
like
people
kind
of
have
a
sense
of
it.
But
then
some
of
the
people
are
gonna,
be
like
oh
you're,
talking
about
multi-year
support
with
virgin
jumping
skews
and
oh
wow.
E
Part
of
I
had
lots
of
goals
for
that
dock.
One
was
to
help
users,
one
was
to
help
us
know
what
was
in
bounds
for
changes
made
in
a
release
and
one
is
to
expose
ways
that
our
test
matrix
is
not
covering
what
we
say.
We
support
today
so
that
to
help
us
to
help
inform
questions
like
oh
well,
sure,
let's,
let's
increase
skew
policy
to
four
versions
or
six
versions
or
whatever
and
kind
of
have
a
light
on
okay.
E
What
what
do
we
actually
need
to
test
if
we're
going
to
do
that,
and
how
do
our
change
policies
need
to
be
adjusted
if
we're
going
to
do
that
so
that
we
don't
make
a
decision
based
on?
Oh
well,
users
want
it.
We
want
it.
We
want
a
check
box
on
our
LTS
page
sure.
Let's
do
it
and
not
realize
what
are
we
actually
and.
B
There's
the
whole
cost
aspect
to
there
like
I
mean
what
is
the?
Does
it
slow
down,
pre
submits?
Does
it
slow
down?
Does
it
cost?
Does
it
literally
cost
more
in
dollars?
Do
we
all
need
to
pull
money
into
the
CNC
F
for
testing
for
like
how
do
we?
If
we
go
there
they're,
there
would
have
to
be
a
very
detailed,
concrete
plan
that
makes
it
viable
and
that
that's
not
something
we're
going
to
quickly
easily
decide
yeah.
K
What
are
we
assumed
to
be
the
responsibility
of
destroy
vendors
essentially
and-
and
you
know
obviously,
there's
some
incentive
to
if
every
one
of
the
hundred
district
vendors
is
going
to
go
and
solve
exactly
the
same
problem
in
a
different
way
somewhere
out
there,
then
you
know
there's
some
argument
for
pushing
that
upstream,
but
at
the
same
time
we
can't
try
and
do
everything
that
all
destroyed
vendors
want
done,
because
that's
you
know
very
expensive
for
an
open-source
project
to
do
so.
I
think
trying
to
figure
out
where
that
line
is,
is
pretty
useful.
E
Something
I
brought
up
last
last
meeting
I
know
several
folks
weren't
able
to
make
it,
but
just
thinking
in
terms
of
api's
rather
than
binary
versions.
So
today,
people
think
in
terms
of
oh
I,
have
a
111
cluster
I
have
a
112
cluster
I
have
a
113
cluster
and
our
REST
API
is
are
versioned
and
have
pretty
detailed
compatibility
requirements.
If
you
write
something
against
the
apps
of
v1
deployments
API,
you
expect
submitting
that
deployment
to
behave
the
same,
even
if
you're
on
a
1/9,
110
111,
it
doesn't
matter
what
version
API
server.
E
Your
expectation
is
that
it
continues
working
the
same
way.
Getting
to
the
same
place
for
driving
configuration
of
the
components.
I
think
would
be
a
really
positive
outcome
so
that,
rather
than
thinking
in
terms
of
I,
have
a
111
API
server
or
a
113
API
server,
you
say
I.
This
is
my
API
server
config
and
it's
versioned
and
I
expect
when
I
start
the
API
server
that
this
will.
E
I,
think
thinking
in
terms
of
api's
makes
a
lot
more
sense
over
over
the
lifespan
of
a
cluster
and
for
people
who
are
kind
of
writing
to
it.
Whereas
today
we
have
like
a
thousand
ad-hoc
flags
and
it's
very
difficult
to
know
whether
a
new
flag
is
going
to
be
required
or
something
like
that.
It's
hard
to
sketch
out
kind
of
an
upgrade
plan
or
a
close
to
lifecycle
plan.
B
B
The
Linux
came
from
a
easier
space,
I
feel
like
the
user
space
boundary
versus
the
kernel
was
more
well
known
and,
like
nobody
talks
about
what
version
of
POSIX
their
kernel
supports
like
we
should
have
the
same
sort
of
thing
like
that.
They
guys
are
just
stable
and
mature
enough
that
you
can
rely
on
them.
H
Sort
of
was
I
just
went
like
today.
We
don't
have
like
a
v1
of
the
pot.
Api
is
not
sufficient
right
because
we
add
fields
to
v1
of
pod
right.
So
that's
sort
of
I
think
why
people,
maybe
that's
one
of
the
reasons
why
people
consider
the
kubernetes
version
and
we
would
have
to
start
getting
stricter
about
that
question.
Mark
some.
E
E
H
We
certainly
need
to
tackle
that
back.
I
mean
today.
If,
if
I
have
a
pod,
that,
like
we
introduced
the
taint
field,
for
example,
with
the
Toleration
field
and
I
bring
back,
it
still
be
one
of
pod.
I
could
put
it
at
that
part
against
an
older
cluster
and
it
would
not
work
and
it
would
still
be
v1
upon
such
a
Devi
one
of
crepey
eyes,
not
sufficient.
H
I'm
saying
that
the
API
version
is
not
sufficient
to
make
that
guarantee
today
and
I
used
a
slightly
specious
example
where
we
spend
like
I
think
what
setting
versions
of
kubernetes
but
I
think
the
point.
That's
sort
of
the
the
problem
that
I
think
that's
one
of
the
reasons
why
API
version
today
is
not
sufficient
and
we
rely
on
the
kubernetes
version.
Some
of
the.
E
Is
would
be
easier
with
config,
because
we
don't
have
to
round-trip
them
and
serve
them
out
to
components
of
different
skewed
like
you
provide
a
config
to
the
to
the
component,
and
it
can
do
things
like
warn
you
or
you
can
run
in
strict
mode
and
it
can
fail,
and
so
some
of
the
some
of
the
things
that
we
did
and
the
rest
of
jobs
are
easier
with
config
Tim,
Tim
Addison.
If.
L
B
Totally
agree
and
I
was
trying
to
in
my
initial
draft
of
the
Charter
I
tried
to
stay
away
from
some
of
those
lower
level
details,
but
Brian
grants
comment
was
like
no,
you,
you
must
declare,
they
are
your
key
stakeholders
and
yes
like
at
the
technically.
Whatever
is
decided.
That's
those
are
gonna,
be
the
SIG's
that
are
implementing
stuff
yeah,
but
there's
a
higher-level
architectural.
B
What
do
we
want
the
shape
of
things
to
be
question
and
sure
it's
got
to
be
doable,
but
I
think
we
have
a
set
of
people
here
who
are
gonna,
understand
that
part
as
well
and
and
pull
in
representation
from
those
sakes
not
like
just
come
at
them
and
say,
like
you,
must
now
implement
this
policy.
That
has
been
like
that.
That's
not
how
the
community
works
in
the
first
place,
either
so
I.
E
Think
the
questions
we
asked
at
the
beginning
are
going
to
shape
the
direction
that
we
go
so
asking
question.
I.
Think
the
survey
is
a
good
starting
point
and
asking
questions:
how
do
you
interact
with
upgrades?
What's
painful,
what
is
broken?
What
are
you
doing
to
address
it?
How
often
are
you
upgrading,
how
are
you
upgrading
without
kind
of
presuming
mechanisms
or
strategies
for
staying,
up-to-date
or
handling
migrations,
or
whatever
people
are
doing
I?
Think
the
information
gathering
step
is
really
important
as
a
starting
point.
So.
B
Survey
then,
and
also
officially
I,
was
trying
to
keep
this
meeting
to
45
minutes,
so
people
can
actually
have
a
break
between,
but
the
that
was
next
on.
The
agenda
was
to
talk
about
the
survey,
so
I
guess
I'll
just
say,
like
folks,
try
and
review
that
and
think
about
the
things
that
we
were
just
discussed
there
and
whether
there's
gaps
and
what
we've
got
there
initially
is
some
things
that
we
want
to
try
to
capture,
as
we
put
it
out
for
discussion
and
then
I.
B
Think
the
last
item
on
the
agenda.
We
should
the
next
meeting
or
a
later
meeting,
but
if
folks
could,
especially
on
the
Charter
discussion,
do
some
reviewing
in
scope
out
of
scope
and
like
Quinton
was
saying
like,
let's
think
about
some
actual
time
line.
What
should
we
focus
on
first
and
second
and
third,
a
little
bit
to
have
a
little
bit
of
clarity
over
the
first
few
months?
B
C
B
We
have
barely
two
weeks,
then
we
would
need
to
really
get
people
to
pounce
and
review
and
and
and
then
see
if
we
can
actually
get
it
out
ahead
of
that
I
think
if
we
have
it
solidified
and
ready
to
go
and
socialize
the
idea
that
it's
coming
AQ
Khan
that
could
be
available
to
Tim
anyone,
muted,
yeah,
I
think.
L
We
need
to
start
the
socialization
process.
I,
don't
think
you
can
time
box,
yet
things
way
too
early,
given
the
fact
that
this
is
a
community-based
project,
you
need
to
have
that
shared
distributed
understanding
which
takes
a
long
time
and
you
need
to
evangelize
in
multiple
forums.
This
is
only
one
forum
of
a
group
of
people
who
are
interested
in
this
topic,
but
it
will
have
vast
implications
across
the
entire
project,
so
you
need
to
be
able
to
socialize
across
that
whole
horizontally
across
all
the
SIG's.
B
L
B
Make
sense
yeah,
so
we
can,
for
the
coming
weeks
to
get
out
to
other
SIG's.
Do
some
of
that
and
then
also
at
cube
con
and
I've
mentioned
this
in
the
the
sock
channel,
but
we
are
on
the
agenda
for
the
contributor
summit.
We've
got
a
50
minute
slot
to
talk.
It
said,
release
engineering,
but
the
idea
is
they
wanted
us
to
kind
of
present
where
we
are,
what
we're
thinking
the
start
of
this
workgroup
and
get
some
some
more
socialization
of
things.
So
we've
got
some
good
opportunity
for
that
coming
up
all
right.