►
From YouTube: TC DefCore Interlock 2014 03 28
Description
Meeting to discuss Designated Sections
https://etherpad.openstack.org/p/openstack-designated-sections
A
Everybody
looks
like
we
have
a
quorum
for
the
tcf
core
interlock
about
those
agentic
sections,
and
so
people
could
make
sure
you
you
get
your
roll
call
information
on
the
etherpad
that
we
built
up
the
cedar
pad
wasn't
designed
for
this
meeting,
but
it
seemed
like
a
good
place
to
start,
so
we
left
it
there
and
then
Josh
and
I
had
talked
briefly
yesterday
about
an
agenda.
But
I
want
to
review
the
agenda
before
we
started
and
then
we
can
sort
of
go
through
and
if
you
there.
A
A
A
C
A
A
This
is
at
the
result
of
hours
and
hours
of
meetings.
Sometimes
we
call
this
the
spider,
because,
where
we
started
with
all
the
the
Cape
the
pieces
to
it
and
I
would
suggest
it
read,
read
this
document,
because
the
designated
sections
is
actually
specifically
from
this
document.
We
usually
use
this
cheat.
This
cheat
sheet,
which
makes
things
sort
of
simple.
The
core
principles
broke
into
three
majors
three
major
components:
one
basically
saying
that
we
wanted
to
find
core
in
a
way
that
applies
to
the
whole
project.
A
There's
a
side
note
that
we
recognize,
as
after
we've
done,
that
we
will
probably
have
to
have
more
specialized
marks,
but
right
now
we're
just
trying
to
get
definition
that
everybody
can
use
to
say
what
is
OpenStack
and
it's
very
important.
This
there's
a
commercial
implication
for
this.
So
it's
if
you
want
to
use
trademark
as
a
commercial
implementation
or
a
distro
or
a
cloud,
that's
running
OpenStack
or
product,
that's
using
OpenStack.
We
have
to
be
able
to
tell
you
that
you
can
describe
it.
A
C
A
A
C
A
Expect
that
there,
the
full
function
of
the
cloud
will
be
implemented
in
an
open
way
by
OpenStack.
There
will
be
a
reference
implementation
and
we
also
expect
that
vendors
or
anybody
else
could
substitute
in
those
those
non-designated
sections
alternate
implementations
that
would
accomplish
the
same
result,
and
as
long
as
and
now
we
get
into
the
next
block
as
long
as
they
pass
the
tests
that
the
reference
implementations
pass,
and
so
the
idea
is
that
we
have
a
community
body
of
tests.
Those
tests
can
be
remotely
yourself
administered
I'll
pause
for
a
second.
A
We
sometimes
get
trapped
a
little
bit
here.
We
are
not
trying
to
create
a
police
state
for
OpenStack
in
this
I
think
it
actually
says
that
in
the
details
this
is
supposed
to
be
a
self
police
activity.
You
say
that
you're
using
designated
sections,
you
say
that
you're
passing
the
tests,
there's
it's
so
easy
to
validate.
A
Most
of
those
things
we're
not
trying
to
create
another
authority
that
says
yes
or
no
to
this,
if
that's
necessary,
we'll
do
it,
but
for
now
we're
making
the
assumption
that
people
will
comply
out
of
community
pressure
out
of
their
own
risk
of
getting
caught,
we're
not
trying
to
create
police
state.
That's
number,
eight!
So
of
those
tests.
We
have
lots
and
lots
of
tests.
A
Not
all
of
them
would
be
required,
for
course,
so
there's
needs
to
be
a
process
by
which
we
say
they're.
Some
of
those
tests
are
the
required
tests
and
some
are
not
that's
another
part
of
the
work,
we're
doing.
Restack
work
and
a
lot
of
the
criteria
scoring
process
that
we're
doing
is
a
whole
nother
conversation
to
pick
those
tests.
And
then,
if
you
pass
all
the
must
pass
tests,
then
you
would
be
able
to
use
the
OpenStack
brand.
G
So
just
always
emphasized
using
the
opens
Dec
brand
in
the
in
the
world
of
deathcore
were
only
dealing
with
commercial
use
of
the
mark
right.
So
there
are
the
three
different
uses
of
the
mark
that
are
defined
in
the
bylaws.
There
is
the
right
for
the
community
to
call
themselves
OpenStack,
which
is
non-commercial
use
and
is,
is
widely
protected.
There's
the
right
for
the
projects
that
are
under
development
to
use
the
opens
Dec
mark
to
talk
about
themselves.
A
Which
brings
up
the
boiling
the
ocean
approach
we
hit.
We
are
intentionally
boiling
a
pot
of
water
right
now.
We
know
that
there
are
other
conversations
that
we
are
surfacing
and
some
of
those
were
very
deliberately
pushing
down
down
the
field
because
they
tend
to
make
a
sloop
and
we
don't
get
consensus
on
it.
So
we've
narrowed
the
field
of
discussion
intentionally
and
we
will.
We
will
point
that
out
if
we
start
getting
off
field
because
it
it
sucks
up
a
lot
of
meeting
time.
If
we're
not
careful.
A
A
Sorry,
neighbor
alert
in
my
area,
some
of
the
some
of
the
things
that
we've
talked
about
are
using
a
set
of
principal
sort
of
stepping
up
to
a
higher
level
piece
as
a
way
to
help
define
what
what
we
need
for
opens
for
designated
sections
generally
I
was
useful
to
look
at
the.
What
do
we
sort
of
did
a
straw
man
as
part
of
that,
as
part
of
that
are
people
interested
in
talking
about
the
principles
for
designated
sections?
C
B
G
There
are
folks
who
would
like
to
see
all
of
the
code
as
a
designated
section
and
have
a
much
more
GPL
like
experience,
and
there
are
folks
who
have
argued
that
none
of
the
code
should
be
designated
and
what's
important
is
API
compatibility
and
the
designated
section
concept
that
the
board
voted
on
was
what
we
could
get
as
a
reasonable
compromise.
To
say.
Some
of
this
clearly
should
be
common
and
it
would
be
best
for
OpenStack
if
the
community
all
contributed
to
that
common
code
base.
G
C
G
Are
a
little
bit
the
sort
of
universe
repositories
in
in
the
Linux
world
as
far
as
what
we
actually
mean
on
a
technical
basis,
again,
Robin
emphasized
that
this
is
this
is
not
audited.
This
is
not
intended
to
power
some
set
of
tests
where
we
are
checking.
This
is
a
self-certification
effort
with
the
big
hairy
stick
of
public,
shaming
and
possibly
loss
of
the
license,
if
you're,
if
you're,
trying
to
be
violating
it.
So
these
are
fairly
rough
guidelines
to
provide
to
a
vendor
to
say,
hey.
G
We
really
think
the
code
that
provides
the
API
should
be
a
designated
section,
and
you
know
you
can
anyone
who's
building
a
distro
is
going
to
be
able
to
say
we
get
what
that
code
pad.
Is
it's
this
thing
with
this
whiskey
middleware
and
it's
the
best
phase
effort
that,
if
we're
improving
that
we
should
be
submitting
those
patches
upstream
and
therefore
we're
running
code
that
is
common
with
the
rest
of
the
community
and.
B
C
B
Differences
are
not
actually
it's
not
possible
to
discover
that
there
is
a
different
driver
in
there,
because
it's
using
the
same
API
I
mean
in
essence,
that's
what
you're
going
for
commercial
use.
Somebody
would
say:
hey
guys,
we're
using
awesome
plugin
rather
than
the
open
plug-in
and
it's
different,
and
we
claim
that
it
matches
all
the
api
functionality.
You
can
use.
G
G
G
It
is
of
cinder
and
Nova,
but
I'm
running
Havana
horizon
or
whatever
the
mix
and
match.
Maybe
that's
required
to
be
available
as
part
of
documentation.
This
is
intended
to
also
elucidate
that
to
say
your
consumer
has
to
have
in
their
documentation
or
discover
all
from
the
API
to
understand
what
is
the
backend?
What
are
the
drivers
that
they're
actually
using,
whether
it's
a
public
cloud
or
a
private
cloud?
G
Some
of
those
drivers
expose
additional
capabilities,
and
so
we
see
cases
where
the
consumer,
it's
kind
of
a
right
to
know,
issue
of
em
I,
actually
consuming
capabilities
that
are
beyond
what
I'm
going
to
be
able
to
get
in
other
OpenStack
environments
or
am
I
consuming
something
that
I
can
expect
to
be
in
all
of
the
drivers.
We
see
this
with
snapshotting
and
thin
provisioning
and
and
copy-on-write
functionality
and
different
silver
backends.
G
We
might
see
this
live
migration
support
across
different
hypervisors,
so
you
know
that
the
the
goal
of
this
in
the
interop
side
of
desk
or
is
that
the
end
users
have
a
way
of
understanding.
These
are
the
functions
on
consuming
in
this
cloud
environment.
These
are
the
ones
that
will
be
portable
because
they
are
OpenStack
core,
and
these
are
the
ones
that
may
not
be
portable
but
maybe
commonly
available.
So
you
see
the
the
issue
we're
kind
of
addressed
there.
Yeah.
B
G
It
will
something
like
that.
It
may,
though
you
know
in
a
sense
of
if
Seagate
has
implemented
an
error,
checking
method.
That
means
you
know
according
to
see
gates
marketing
literature.
You
never
need
to
do
snapshots,
because
you
know
there's
some
other
error
detection
and
you
don't
need
backups,
it's
just
going
to
be
magically
often
for
you,
then
the
consumer
needs
to
know
that
they're
being
trained
by
their
cloud
provider
to
have
a
set
of
best
practices
that
may
not
be
the
same
against
a
separate,
API
and
I.
G
Think
the
the
if
the
system
is
different
from
reference
is
really
the
again
it's
the
best
I
faith.
Question
is
back
on
the
vendor
if
you're
picking
a
particular
driver,
because
you
believe
it's
more
awesome,
the
more
awesomeness
is
a
different
from
reference.
If
it's
not
that
I
difference
from
reference,
you
are
not
required
to
tell
your
consumer
what
driver
you're
using
I.
C
G
Most
of
the
SDN
components,
plum
grated
contrail
and
intersex
have
additional
api's
that
are
not
exposed
through
Neutron
that
allow
you
to
do
other
different
things
with
your
networks
and
if
those
are
exposed
to
the
neutron
extension
that
meets
the
613
requirement,
if
they're
not,
it
would
need
to
be
documented,
because,
if
folks
are
being
trained
to
use
those
api's
and
they're
rolled
up
in
the
same
dashboard,
but
they're
not
open
stacked,
the
users
need
to
understand
that
that's
a
not
openstack
functionality,
they're
not
going
to
see
elsewhere
right.
That
makes
complete
sense.
Ok,.
A
F
Had
two
questions
about
that,
one
has
to
do
with
the
level
of
detail
and
I.
Think
that's
been
answered
pretty
well
based
on
these
examples,
but
the
other
one
is
there
at
the
bottom
of
the
etherpad
about
how
tightly
this
is
tied
to
the
designation
of
which
capabilities
are
going
to
be
part
of
core,
and
the
thing
that
made
me
raise.
F
That
question
was
to
comment
under
the
rationale
for
horizon,
saying
that
no
part
of
horizon
is
designated
as
core,
because
we're
not
going
to
require
that
anyone
use
horizon
and
if
we're
really
separating
those
two
things,
then
maybe
we
should
consider
what
parts
of
horizon
really
are
core.
Even
if
we're
going
to
then
say
well,
you
don't
have
to
use
that
in
order
to
use
the
mark
so.
A
G
This
or
the
question
around
horizon
I
mean
the
reality
of
how
we're
doing
ref
stack
is
we're
relying
on
temp
tests
to
determine
capabilities,
and
it's
because
it's
the
only
mechanism
we
have,
that
is
community
owned
and
can
be
applied
evenly
across
both
private
and
public
clouds,
which
is
one
of
the
goals
of
definition
of
core.
And
unfortunately,
we
don't
have
tempest
tests
that
exercise
horizon
enough
to
to
read
to
measure
the
capabilities
as
being
must
have
now.
That's.
G
A
Judgment
I've
but
hold
on.
I
think
I
think
this
is
your
right
to
call
this
out.
This
is
mixing
the
streams
and
I
actually
would
ask
that.
We
omit
that
statement,
because
josh
is
entirely
right.
There
aren't
enough
tests
to
bring
it
as
capability,
but
that's
different
than
it's
saying
what
parts
of
horizon
are
designated.
That's
a
different
question,
and
so
I
well,
but
I'm.
G
This
the
goal
of
ordering
this
and
saying,
let's
define
designated
sections
for
the
projects
that
look
like
they
will
have
capabilities
in
core.
As
of
this
first
set
of
certifications,
is
just
so
that
we
don't
get
swamped
trying
to
do
designated
sections
for
every
project.
It's
not
to
say
we
don't
move
along
with
fine
yeah,
that's
nothing.
We
don't
need
to
define
the
expectation
is
many
of
these
projects
will
probably
have
capabilities
that
end
up
in
court
in
the
future,
and
when
that
happens,
we
will
need
designee.
G
F
A
G
G
B
A
So
do
people
feel
like
we
have
a
better
idea
on
what
designate
it
is
because
I
just
from
a
time
perspective,
I
would
love
to
see
people
editing
this
as
we
talk
and
not
spending
not
try
and
hammer
it
out
as
much
in
this
meeting.
I
think
we've
got
other
topics
to
cover,
but
I'm
happy
to
keep
talking
about.
If
somebody
still
says
I,
don't
it
just
doesn't
make
sense.
G
There
is
one
clarification,
I
wanted
to
add:
I,
don't
know
if
John
Griffiths
is
on
the
call,
but
in
the
cinder
section
there
was
some
confusion,
saying
api's
designated
section
what
what
I
meant
was
as
a
code
that
exposes
the
API,
not
API
compatibility,
so
literally
the
binary
for
cinder
a
pee.
I
would
be
required
to
be
shipped
binary
being
the
wrong
term,
but
I
think
you
get
what
about
and
I
know.
That's
led
to
confusion
and
people
thinking
we're
talking
about
a
bi
compatibility
where
act.
D
G
I
would
keep
it
I
mean
I
would
love
to
keep
it
at
the
module
level.
I
think
individual
file
I
mean
we
don't
want
to
be
so
prescriptive
that
this
becomes
onerous
either
on
the
TC
or
ptl's
or
on
the
vendors.
So
we
really
need
to
be
keeping
this
fairly
lightweight
and
say
guys.
You'll
know
if
you're
doing
the
right
thing
or
not,
but
if.
G
B
Thing
is
clarified
it
for
me
at
the
last.
The
last
board
meeting
was
originally.
It
seems
like
we
are
talking
about
like
going
through
and
making
a
taxonomy
of,
like
you
know,
methods
and
stuff
like
that
inside
of
the
code
base,
which
is
clearly
insanity,
so
I
think
that
the
idea
of
calling
out
it
like
big
ticket
items
and
then
we
can
address
it.
If
something
is
an
issue
later
on
down,
the
road
sounds
perfectly
sane.
H
G
G
G
B
Have
to
point
out
of
the
core
layer.
That
is
what
you
said
earlier,
which
is
that
this
is.
There
is
an
amount
of
of
self-policing
and
you
know
best
we're
getting
we're
letting
people
self-certify
and
use
some
judgment
right.
So,
like
yeah,
you,
you
probably
know
if
you're
running
the
nova,
scheduler
or
not,
you
know
like.
If
you
passed
a
few
files,
you
know
you're,
probably
still
running
the
nova
scheduler.
If
you
replaced
it
with
something,
you
wrote
in
haskell,
you're,
probably
not
running
the
nova
scheduler.
You
know.
G
G
G
We
said:
hey
we've
been
supporting
this,
it's
in
a
branch,
but
it's
not
our
go
forward
without
supporting
you
know,
contrail
and
plum
grid
and
other
commercial
vendors
we're
not
going
to
fight
with
Neutron
about
trying
to
land
that
patch.
But
if
somebody
was
really
concerned
about
what
was
being
run
in
a
previous
version,
our
software,
it
is
upstream
we
can
go,
find
and
I
think
that's
the
level
of
best
faith
effort
we're
expecting
from
people.
So.
B
G
B
Yeah
because
that,
because
you
can
make
the
argument
there
too,
you
know
that
if
we're
talking
about
inventing
upstream
and
we've
got,
you
know
the
efforts
that
keep
not
getting
off
the
ground
upstream
to
get
a
unified
scheduler.
Then
you
know
we
trying
to
figure
out
how
to
you
know,
incentivize
those
folks
to
make
help
make
a
unified
schedulers
and
then
they
can
plug
into
I.
Don't
know
like
yeah:
this
is
we
can
go.
B
E
A
G
So
the
thing
about
this
that
makes
it
tricky
to
address,
which
is
why
we're
you
know
three
years,
four
years
in
the
governance
and
now
wrestling
with
it
is
because
the
details
of
this
decision
have
impact
on
the
technical
decisions
about
the
project
in
the
sense
of
which
vendors
are
incentivized
to
work
on
which
sections,
but
they
also
have
business
chilling.
Impact
on
offenders
can
therefore
engage
in
the
commercial
ecosystem
or
not
and
I.
G
Is
a
great
example
here:
I
think
there
are
identity
management
providers
that
took
a
keystone
that
are
good
examples
and
so
principles
are
tricky
because
I
don't
want
to
define
anything
that
restricts
the
scope
of
the
PTL
to
say
this
is
what
we'd
like
to
do:
that's
best
for
the
project,
but
I'm
very
concerned
about
the
commercial
impacts
and
the
and
the
public
and
the
users
perception
of
those
commercial
impacts.
Disabled.
A
G
A
In
back
and
attend,
or
that's
actually,
the
reason
why
I'm
trying
to
switch
us
to
principles
is
because
I
think
that
the
question
you
guys
were
talking
around
is
if
a
vendor
says
I
want
to
replace
this
part
of
OpenStack,
because
I
have
another
way
to
do
it.
That
to
me
might
indicate
that
the
code
is
not
designated.
It's
not
that
this
isn't
black
or
white.
But
if
a
vendor
saying
I
want
to,
I
have
a
substitute
scheduler
like
what
you're
describing
then
the
code
they're
trying
to
replace
we
should
be
asking.
A
A
A
You
know
so
you're
looking
at
a
module
right,
we're
taught
we're
trying
to
be
big
bucket,
big-ticket
items.
You
know
if
that
big
ticket
item
you
know,
if
we're
yes
to
all
five
of
these
you're,
like
that's
a
designated
section,
if
you're
no
to
all
five
of
them,
then
it's
you
know
it's
not,
and
so
right.
A
G
G
Okay,
that
makes
way
more
sense
to
me,
so
I
would
start
with
with
a
sort
of
meta
principle,
which
is
that
you
know,
let's
acknowledge
that.
The
thing
that
we're
doing
right
now
has
to
create
a
balance
between
the
commercial
ecosystem
and
the
community
ecosystem,
that
it
is
a
goal
for
both
at
the
board
and
the
pp
and
in
the
community
to
have
community
contribution
to
a
common
code
base.
That
is
good
for
OpenStack
and
good
for
users.
G
G
E
G
A
G
C
G
A
Going
to
say
that
the
purpose
with
the
designated
sections
is
actually
to
create
some
balance
between
apache
do
whatever
you
want
and
GPL
you
must
upstream
everything-
and
so
this
is.
This
is
I,
think
my
mind,
a
very
deliberate
attempt
to
try
and
find
some
balance
between
helping
people
upstream
and
requiring
people
to
jump
street.
E
I
think
I
think
that's
all
well
and
good
and
I.
You
know
I,
don't
want
to
distract
from
this
too
much
but
I.
Since
the
topic
has
come
up,
I
mean
we're
not
actually
talking
about
changing
the
license.
The
license
is
what
it
is.
It's
an
apache
license,
which
means
that
you
can,
by
and
large,
do
whatever
you
want
with
the
code,
but
that
doesn't
necessarily
mean
that
whatever
you
do
with
the
code
should
end
the
end
be
called
OpenStack
and
I.
E
G
That
I
mean
it.
It
was
an
open
question
which
is
sort
of
the
you
know.
As
far
as
the
community
discussion,
the
process,
the
proposal
to
the
board,
the
board
vote
and
then
moving
forward
on
on
setting
up
the
process
to
do
it.
That
I
mean
took
us
a
year
and
a
half,
but
it
was
largely
resolved
last
November
unanimously
at
the
board
level
that
this
the
designated
sections
concept
is
agreed
upon.
So
this
is
a
GPL
esque
aspect
of
the
use
of
the
OpenStack
mark.
G
What
we're
trying
to
to
determine
or
what
this
joint
effort
is,
is
how
broad
sweeping
is
that
you
know
in
the
sense
of
is
it?
Is
it
a
hundred
percent
of
the
code
in
one
project,
because
the
ppl
of
that
code
feels
like
that
would
be
the
best
thing
and
they
care
about
GPL
or
is
it
you
know
zero
code
in
other
projects,
because
they
feel
that
the
opportunity
for
commercial
ecosystem,
for
that
particular
piece
of
infrastructure
of
the
service
is
part
of
what
will
keep
opens
Dec
healthy.
G
F
So
it
seems
like
we
should
be
looking
at
each
project
and
picking
what
parts
of
it
are
actually
useful,
irreplaceable
right
now
and
whether
or
not
somebody
goes
and
decides
to
build
a
business
around
that
or
whether
that
cuts
out
somebody
who
has
decided
to
build
a
business
around
something
that
we
think
is
critical,
I'm
not
I
mean
we
should
yeah
not
much.
We
should
put
you
know
how
much
we
should
weigh
that.
If
I
could.
I
agree.
B
Because
I
think
there's
a
technical,
I
think
there's
a
technical
aspect
and
the
best
when
I
can
the
best
stupid
example
I
can
think
of
and
granted
both
of
these
are
entry.
But
you
know,
HP
is
running
its
public
cloud
on
kvm
and
Rackspace
is
running
its
public
cloud
on
on
them.
Now
is
that
interface
perfect
know
like
there's
really
weird
stuff.
B
That
happens
because
Rackspace
is
running
on
zen
and
I'd
like
to
find
somebody
because
of
that,
but
in
general
the
the
difference
in
choice
they
beach
made
as
a
deployer
there,
I
don't
think,
makes
either
of
those
clouds
less
more
or
less
OpenStack.
Right,
like
that's
a
that's
a
choice,
point
that
that's
an
actually
natural
choice
point
you
know
and
I
think
that
one's
a
reasonably
obvious
one
you
know,
and
so
from
the
technical
perspective,
I
think
sort
of
Doug's
point.
B
If
there's
a
if
there's,
if
there's
actual
choice,
points
that
make
sense
that
don't
that
mostly
don't
you
know,
impact
the
users
thing
and
I
think
we
could
consider
the
sum
of
the
stuff
in
the
vert
layered
separation
to
be
thugs
rather
than
you
know
whatever.
Then
you
know
then
there's
actually
there's
we
can
make
that
in
technical
rather
than
saying
somebody
might
want
to
commercialize
this
in
the
future.
So,
let's
not
step
on
their
toes.
B
A
A
What
we're
trying
to
do
is
give
give
the
community
some
guidance
when
they
look
at
a
module
or
a
piece
of
you
know,
block
of
code
to
say
you
know
what
I
understand
that
this
one's
shades
of
grey,
this
one's
black
and
black
white,
that
all
we're
trying
to
do
is
give
people
guidance
so
that
it
doesn't
end
up
being
somebody
standing
in
one
corner
shouting.
It
is,
and
somebody
on
the
of
its
inning
and
another
corridor,
shouting
it
isn't
and
because
that
is
not
productive.
A
G
I
mean
let's,
let's,
let's
turn
it
around
in
the
reverse.
The
reason
to
have
a
set
of
principles
at
all
is
not
because
we
really
eat
a
lot
of
guidance
and
putting
these
together,
but
it's
because
we
need
something
we
can
point
out
later
when
we
have
inevitable
debate
about
why
and
how
certain
sections
were
designated.
We
can
point
back
and
say:
well,
these
are
the
principles
we
apply.
This
decision
we
came
to.
G
We
had
to
do
the
same
thing
with
gold
member
membership
at
the
board
level
and
the
first
batch
of
gold
member
applicants
came
in
before
we
had
written
out
the
gold
member
selection
criteria
and
it
was
a
nightmare
because
whether
we
said
yes
or
no,
we
were
going
to
be
in
a
position
where
we
were
scrutinized
and
we
had
no
defensive
criteria.
We
ended
up
deferring
decision,
running
around
running
criteria
and
then
coming
back
to
the
decision,
even
though
we
had
a
good
sense
that
we
could
have
had
unanimous
decision,
the
first
place,
don't.
G
F
I
I,
don't
think
we're
arguing.
I'm
certainly
not
arguing
that
we
shouldn't
have
principles.
I
think
I
look
at
doing
about
how
much
weight
to
attach
to
number
four
in
which
direction,
and
I
would
rather
look
at
the
intent
of
the
developers
who
have
contributed
code
and
whether
or
not
they
expect
a
piece
of
code
to
be
replaced
by
someone
for
whatever
purpose,
rather
than,
and
I
understand
that
the
business
concerns
of
the
community
fall
into
this
too,
but
placing
more
weight
on
the
intent
of
the
original
developers
rather
than
current
or
future
vendors.
H
G
Well,
here's
a
classic
example
is
scaling
out
code
in
Nova.
Is
it
about
cells?
Is
it
about
regions
and
Aziz?
Is
it
about
hosts
aggregates?
What's
the
future
looking
plan
for
scale
out,
because
there
are
tests
and
their
AP
is,
and
there
are
people
using
those
in
many
different
ways
in
many
different
contexts
and
vendors
have
deployed
them
in
all
sorts
of
scenarios
and
on
the
Deaf
course
side
we
don't
know
what
the
TCS
forward-looking
plan
is
as
far
as
how
should
open
set
clods
be
scaled
in
the
future.
G
C
F
Right
well,
this
may
feed
back
into
some
of
those
developer
discussions
too,
because
just
because
people
are
not
in
this
meeting
doesn't
mean
they're
not
interested
in
these
questions.
So
if
we
have
these
set
of
principles-
and
we
say
you
know
think
about
what
you're
doing
when
you
design
something
and
what
parts
of
it
you
expect
someone
to
be
able
to
replace
we're
going
to
end
up
with
better
designs
anyway,
but
we'll
also
have
a
clearer
path.
As
we
add
new
features
for
selecting
what's
designated
well,
it's
not
yeah.
A
A
B
B
A
But
what
I
would
what
I
would
ask
is
actually
I
thought.
That's
the
bottom
that
we
set
a
date
by
which
we
say
the
principles
will
be
official
like
that.
I
would
love
to
see
the
TC
actually
have
a
vote
or
something
and
make
it
an
official
TC
guidance
that
you
know
some
screening
process
a
date
just
crystallizes
things.
It
forces
people
to
pay
attention.
If
that's
the
summit,
that
summit
I
don't
matter
to
me,
it's
just
some
some
specific
date.
C
G
C
G
I
guess
I
know
the
only
other
piece
I
wanted
to
bring
up
because
I'm
I'm
a
little
confused
about
it,
and-
and
maybe
rub
you
can
help
me
with
this
I'm.
Looking
at
specifically
the
glance
designated
sections
proposed
by
Mark
wash
and
the
Swift
file
system
in
HTTP
stores,
as
designated
I,
agree
that
improvements
to
that
code
should
be
in
the
common
code
base,
so
I'm
not
suggesting
they
should
be
not
designated,
but
I.
Think
what
we
need
to
emphasize
is
designated
sections
only
apply
when
they
are
enabling
capabilities
that
are
must-haves.
G
In
other
words,
if
the,
if
the
Swift
store
for
glance
is
not
a
must-have
capability
or
if
there's
some
capability
that
only
if
there
isn't
a
capability
that
only
that
store
demonstrates
the
code
is
not
guaranteed
to
be
in
products
that
need
the
core
definition.
It's
simply
that
if
they're
exposing
the
Swift
capability,
they
need
to
be
using
that
code.