►
From YouTube: OpenStack DefCore Meeting Elephant.2
Description
OpenStack Core Definition Committee Meeting
See https://etherpad.openstack.org/p/DefCoreElephant.2
B
B
A
A
We
we
are
going
to
allow
and
empower
the
foundation
to
to
fight
back
on
that
and
to
to
participate
in
a
legal
defense
fund
around
that
which
case
what
people
are
going
to
say.
Well,
what
is
included
in
that
sort
of
program,
for
example,
would
Savannah
be
included,
or
would
someone
as
someone
that
you
did
patent
infringement
in
the
queue
Savannah?
Would
that
be
included
or
not?
The
idea
is
that
whatever
is
we
ultimately
end
up?
C
So
the
goal
is
actually
is
not
as
clear
to
me,
because
the
purpose
that
we're
defining
with
death
with
death
core
is
the
minimum
set,
that's
required.
If
you
want
to
claim
the
trademark
I
think
there's
clearly
things
that
are
beyond
that
and
we
want.
We
want
to
be
beyond
it
right.
We
discussed
and
he
previously
account
the
concept
of
Commons
and
I
would
expect
things
that
are
officially
in
commons
would
be
included
in
this
in
the
trademark.
Lunch.
B
Any
other
challenge,
the
other
potential
challenges
that
there
is
no
logical
association
between
OpenStack
and
Linux,
in
the
sense
that
OpenStack
can
be
run
on
a
Windows
machine
using
hyper-v
and
hosting
windows
VMs,
so
I
don't
object
to
including
it
in
Linux
system
definition.
But
I
think
we
are
stretching
the
linux
system
definition
specifically
what
we're
doing
things
like,
including
the
hyper-v
driver
in
it
sorry
layers,
are
negative
impacts
on
what
on.
D
D
Just
one
question
here
is
from
a
def
core
point
of
view,
so
let's
just
remember
that
oin
did
this
on
their
own.
I
completely
agree
that
they're
taking
the
linux
definition
and
just
well
in
extending
it
in
a
way
which
I
don't
think
people
anticipate
it,
but
that
is
what
it
is.
I'm,
not
sure
you
know
so
from
an
I
think
getting
the
coverage
from
the
lion
is
very
helpful.
D
I'm,
not
sure
how
big
an
issue
it
is
for
deaf,
korg's
I,
think
def
core
is
focused
on
what
do
we
think
the
trademark
should
be
used
on
so
the
fact
that
we
have
a
patent
cross-license
and
that
patent
cross-license
covers
things
that
are
may
not
be
within
the
scope
of
the
trademark?
I,
don't
think,
is
critical.
D
I
just
mean
I,
don't
you
know
in
particular,
since
oh
I
am
is
a
third
party
who
has
demonstrated
a
certain
independence
I
think
it's
the
kind
way
of
putting
it.
You
know
they
didn't
actually
come
to
us
prior
prior
to
doing
this,
I
would
be
loath
to
yeah
to
you
know
back,
you
know,
give
them
more
power
right,
so
yeah
I
would
suggest.
B
And
just
put
this
in
the
etherpad,
which
I
think
is
a
great
suggestion-
that
if
we,
if
oh
I
n,
is
asking
for
our
input
at
this
point,
we
would
suggest
that
they
should
include
everything
that
is
declared
integrated
by
the
TC
and
not
attach
it
to
what's
declared
as
core
by
def
core,
because
that
will
give
them
the
broadest
coverage
without
undue
influence.
On
on
how
we
manage
the
trademark
use
the
most.
A
Okay,
we
can
certainly
make
that
we
can
certainly
make
that
choice
and
I
would
be
surprised
if
in
some
ways
they
I
think
that
that
would
be
an
easy
and
good
way
to
do
it.
The
one
thought
is
that
it
may
that
does
open
up
a
possible
when
you're,
when
this
is
this
whole
idea
of
coordination
with
oin
is
to
help
put
some
sort
of
bounds
around
them,
as
opposed
to,
and
have
them
act
more
importance
with
our
wishes,
because
otherwise
they'll
sort
of
do
whatever
they
want,
as
they
have.
C
D
I
mean
I
would
agree
with
van
on
this
I
think
you
know
what
we're
getting
is.
Basically,
you
know
a
defense
to
patent
infringement.
You
know
kind
of
free
from
oin
I
think
we
should
try
to
make
that
extend
as
far
as
possible
and
I
think
it
should
be
completely
independent
from
what
deaf
court
thinks
is.
I'm
need
to
use
the
term
core,
but
let's
use
the
term
trademark
or
something
like
that.
A
In
thinking
through
it,
I
can't,
I
think,
that
the
negative
impacts
for
having
the
oin
definition
be
very
broad
are
very,
very
small
to
us,
one
that,
in
I
seen
this
happen,
plays
it
and
play
this
out
later.
Is
we
know
that
there
are
certain
companies
that
are
already
in
our
community
that
are
not
going
to
join
oin
and
one
of
the
reasons
why
and
one
of
the
reasons?
Why
is
because
of
the
breadth
of
what
is
covered?
A
And
the
idea
is
that
we
would
have
a
have
a
smaller
definition
and
cross-license
focusing
just
on
OpenStack,
and
we
would
try
and
get
those
companies
into
now
if
we,
as
a
policy
decision,
wanted
to
say,
that's
anything
and
integrated,
I'm,
okay,
there,
but
I
think
that
we
may,
in
the
future,
want
to
make
sure
that
there's
parity
between
any
specialized
cross-license
that
any
specialized
cross
Lawson
says
OpenStack
only
and
whatever's
in
oin,
and
just
being
aware
that
there
may
the
broader
we
make
it
the
more
pushback
we
will
get
from
large
patent
holders.
Yeah.
D
B
Frank
from
a
death
quarter,
standpoint
I
think
we're
best
positioned
to
say
we
are
happy
to
let
you
know.
What's
in
the
definition
of
core,
when
we
finalize
it,
we
will
also
keep
you
apprised
of
what
ends
up
being
and
it's
that
common
or
whatever
else
is
those
terms
come
up,
and
you
can
talk
to
the
TC
about
what's
in
the
integrated
release
button,
the
rest
of
this
should
be
left
to
the
legal
affairs
committee
for
now,
I.
C
C
That
our
decision
process
should
be
influenced
by
OEM
needs.
I,
agree
with
that
yeah,
so
I
I
think
this
is
really
interesting.
I
actually
think
that
our
program
versus
project
discussion-
it
might
be
more
helpful
for
oh
I
n,
as
we're
gonna
get
into
that
then
you're
thin
anything
anything
else.
Yeah.
B
Awesome
I,
just
as
I
note,
it
is
worth
considering
to
think
about
Microsoft
and
if
Microsoft
becomes
a
member
of
OpenStack
at
some
points,
they
clearly
are
unlikely
to
agree
not
to
pursue
patents
against
the
Linux
system
and,
as
the
Linux
system
definition
starts,
to
include
Microsoft
code.
That's
confusing.
F
B
More
the
issue
of
they
are
unlikely
to
join,
though
I
n.
Now
they
want
and
the
foundation
itself
is
now
a
member
of
a
lion
and
so
I.
Don't
know
there
are
community
of
properties
there,
but
they're.
There
is
definitely
something
confusing
in
that,
and
I
think
we
should
leave
it
out
of
deaf
core
since
most
I.
F
A
A
D
A
I
basically
wanted
to
I
suggest
that
we
we
summarize
the
oin
portion
in
three
ways
number
one
a
couple
people
made
the
point
that
this
is.
We
should
be
doing
this
for
our
needs
and
not
oin.
I
said
I
would
suggest
that
we
adopt
that
as
a
consensus
point.
I
definitely
agree
there,
but
you
know,
as
I
would
say.
Number
two
is
our
interaction
with
with
oh
I
n
is,
is
our
interaction
with
oin
is
in
terms
of
okay?
A
How
can
we
guide
them
to
do
things
that
we
are
like
and
there's
probably
a
an
inclination,
at
least
in
the
oin,
tend
to
push
their
the
coverage
there
as
broadly
as
possible?
Number
three
is
just.
We
should
be
aware
that
the
things
that
we're
doing
in
terms
of
defining
core,
eventually
we'll
probably
have
some
impact
in
the
future
on
some
aspect
of
patent
protection.
B
Right
well
again:
I
think
that
is
more
for
the
legal
affairs
community
come
to
you
def
core
and
say
this
is
what
we
think
are
the
impacts
that
you'd
be
aware
of
the
rat
in
the
reverse.
It's
not
for
us
to
think
of
the
legal
impacts
because
we're
not
qualified
it
would
be
for
legal
affairs
committee
to
come
to
us
and
say
we
believe
these
are
the
impacts.
These
are
our
recommendations
specifically.
A
B
B
I
I
think
Catherine's
also
on
as
well
I
think
the
set
we
were
looking
at.
One
of
the
things
we're
trying
to
figure
out
was
whether
you
know
I
think
this
is
about
650
total
tests
and
the
base
we're
looking
at,
of
which
you
know
roughly
half
are
sort
of
I
guess
you
can
go
to
negative
or
error
case
tests
young
we
Whittle
it
down.
We
get
somewhere
around
300
API
level
has
to
go
across
the
the
core
of
of
the
OpenStack.
I
So
there's
a
few
things
I
think
it
would
be
interesting
to
get
to
get
a
group
view
on
here.
As
we
drill
is,
we
can
certainly
drill
down
more
on
a
function
by
function.
Basis
and
say:
is
this
reasonably
well
covered
or
we
could
just
take
that
set
and
take
their
I
think
with
Josh
when
Rob
we're
suggesting
a
few
weeks
back
and
do
a
community
voting
style
on
them?
I
But
there's
a
couple
things
I
think
are
worth
it
may
be
discussing
quickly
as
a
group
one
is
you
know:
do
we
want
to
push
for
the
likely
to
seed
on
the
things
that
tend
succeed,
interop,
where
we
we
don't
focus
so
much
on
implementations
that
are
out
consistently?
We
focus
on
the
cores
and
the
productive
behaviors,
or
do
we
want
to
have
a
separate
test
suite
that
focuses
on
you,
know,
hardening
and
edge
cases
and
make
sure
that
you
know
a
tool
set
that
has
erroneous.
I
I
I
B
B
I
I
I'm
the
reason
I
brought
this
up.
Is
that
a
bit
of
history-
and
maybe
we
shouldn't
speak
of
a
web
service
days,
but
it
actually
required
quite
a
bit
of
development
investment
by
some
companies
to
get
to
get
failure
cases
to
report
consistently
in
such
a
way.
If
you
were
doing
you
know
full
comparisons,
and
and
and
it's
in
terms
of
how
the
systems
would
respond,
you
know
on
unrest,
calls
and
stuff
like
that,
so
I
was
leaning
more
towards
the.
J
I
Of
tests
and
all
that
kind
of
stuff,
but
I
didn't
know
if
we
wanted
to
give
any
any
sorts.
I
understand
the
comment
from
that
for
the
last
def
court
meeting,
but
just
in
terms
of
you
know
getting
people
to
absolutely
agree
on
on
something
that
they'll
be
sensitive
about
with
respect
to
product
branding
or
product
trademarking.
I
I
C
I
C
Of
the
things
that
became
obvious
to
us
is
that
these
the
criteria
really
aren't
well
suited
to
the
absolutes
necessarily,
but
really
a
weighted
set,
and
one
of
the
ways
that
we
handle
this
type
would
handle
the
type
of
question
that
way.
Topics
have
higher
than
negative
tests.
But
I
think
that
I
can
imagine
negative
tests
that
we
definitely
want
in
because
they
are
things
that
we
have
to
fail
in
predictable
way
and
that's
good
yeah.
B
B
Think
we
need
to
think
about
it,
the
be
careful
about
the
context
of
what
we
said.
The
least
possible
set
we're
talking
about
the
smallest
set
of
capabilities,
not
the
smallest
set
of
tests.
We
need
the
largest
set
of
tests
that
validate
the
most
comprehensively,
the
smallest
set
of
capabilities,
good.
C
Right
so
we're
testing
a
small
set
of
capabilities
trying
to
keep
their
capabilities.
This
short
list
hi,
and
so
from
that
perspective
we
almost
want
to
look
at
these
tests.
The
test
coverage
as
the
capabilities
is
a
core
capability
because
it
has
five
tests
on
it.
If
we
have
10
negative
tests
that
also
cover
it,
those
would
want
to
include
so
I
think
does
that.
Does
that
address
your
question?
Andrew
yeah.
I
H
C
Think
that
Josh
drove
us
in
the
right
direction,
which
is
these,
are
capabilities,
and
if,
if
we're
testing
capability
include
the
negative
test,
that's
great
don't
bring
in
a
negative
test
that
exposes
a
new
capability
just
because
it's
a
because
it's
a
popular
it's
a
highly
weighted
negative
test.
So
I
think
that
the
thing
that
surfaces
here
is
actually
a
decision
that
I
want
to
make
as
a
committee.
C
Is
that
we're
looking
at
we're
going
to
we're
going
to
try
and
group
test
by
capability
by
the
capability
being
tested
and
that
will
actually
be
there'll,
be
a
clustering
algorithms
that
we
need
to
apply
to
this
so
totally
agree!
Okay
on
this,
can
we
just
make
you
very
close
this
issue,
because
I
actually
think
that
that's
a
reasonable
thing
to
document
as
a
target
yeah.
I
B
So
I'm
less
concerned,
in
other
words,
I
think
the
explicit
statement
by
deaf
core
is
that
we
trust
the
TC
and
the
project
members
of
each
of
the
OpenStack
projects
to
continue
to
add
tests
until
they
are
happy
with
it,
and
we
will
always
work
off
of
the
tests
that
are
available.
We
don't
have
a
mandate
to
go
and
write
new
tempest
tests.
B
My
concern
the
reason
I
put
this
on
the
agenda
for
today
is
that
we
do
have
a
mandate
to
not
include
things
in
court
that
they
don't
have
test
coverage
and
I
had
can't
seem
to
figure
out
what
our
state
of
test
coverage
is,
and
so
I
was
hoping.
You
might
be
able
to
give
me
some
insight,
or
maybe-
and
gentle
has
some
insight
or
someone
in
what
what
percentage
of
our
AP
is.
Do
we
actually
have
good
tempest
coverage
for
right
now?
Did.
J
Only
see
if
we
happen
calculate
ourselves,
but
I
do
see
that
for
the
most
coverage
coverage
we
have
is
for
Nova
and
the
percentage
is
about
eighty
percent
and
from
from
Santa
top,
it
seems
like
ten
percent
is
not
testable,
that
the
coverage
right
now
is
eighty
percent,
so
so
intent
us
right
now.
There
is
two
major
test
category
right
now.
One
is
the
api
test,
which
is
what
we
talked
so
far:
the
gate,
the
negative
gate,
the
smoke
tests,
etc.
J
B
Will
be
as
long
as
we
can
map
it
to
a
specific
capability,
in
other
words,
let's
take
and
and
these
originally
the
the
original
scenario
tests
were
the
smoke
tests
that
we
had
NASA
and
the
we
did
things
like
a
definable
volume
attach
it
to
an
instance
write
data
to
it,
detach
it
attach
it
to
a
different
instance,
read
the
data
to
catch
and
delete
it.
That
was
a
really
common
scenario
that
test
both
cinder
and
Nova.
Ap
is
so.
We
have
one
test
that
actually
expresses
multiple
capabilities,
but
that's
fine.
B
We
might
say
we
believe
this
scenario
is
part
of
core
and
therefore
this
test
that
they
must
have
for
core,
which
is
why
core
is
not
a
this
project
as
they
were
in
or
out,
but
this
capability
is
in
a
rod
and
a
capability
could
be
easily
expressed
by
a
scenario:
even
it
spans
projects
and
programs.
Those.
F
J
Not
those
those
what
you
just
described
is
right
now
in
Scenario
test
in
an
ABI
test
is
/
/
/
past.
So
you
just
say:
query
volume.
If
you
pass
that's
past
the
connection
of
the
api
test
typically,
is
not
a
prerequisite
of
previous
action.
The
scenario
test
is
and
that
you're
like
it
is.
We
didn't
see
that
kind
of
grouping
in
the
past
in
grizzly
we
saw
that
in
Havana
Tempest.
J
J
B
J
B
B
Mean
that
would
be
is
that
using
that
spreadsheet,
as
part
of
the
criteria
would
be
really
useful
for
us.
So
as
we're
waiting
through
some
of
these
things
and
we're
looking
at,
let's
say:
neutron
is
an
example.
We
can
look
at
the
spreadsheet
and
say:
oh
well.
We
have
no
tests
for
these
sets
of
capabilities.
Therefore,
a
those
capabilities
can't
be
part
of
core
and
be
it
puts
some
concern
on
the
other
capabilities
that
we
maybe
do
have
tests
for,
because
they're
not
comprehensive
enough
yeah.
I
Yeah,
so
there's
probably
a
few
things
will
want
to
add
Katherine
one
is
like
an
extension
or
not,
and
I
don't
know.
If
we
want
to
do
a
rough
grouping,
the
way
have
we
thought
about
how
we
named
capabilities.
Do
we
want
to
name
them
according
the
way
we
roll
them
up
in
the
API
Docs
or
something?
Oh.
B
Sure
that
is
a
very
good
question.
I
think
the
original
goal
for
ref
stack
before
we
defined
F
core
was
to
be
able
to
use
the
links
from
the
scorecards
to
the
API
Docs.
That
version,
so
the
bending
would
have
to
map
exactly
and
I
think
that
probably
still
the
easiest
way
to
do
it,
because
if
it's
not
in
the
docs,
it
doesn't
exist.
H
L
C
J
L
C
B
I
think
blue
from
volume
is
capability.
I,
think
this
scenario
wouldn't
be
volumes
and
volumes
attaching
two
instances
because
attached
detached,
read
and
write.
The
problem
is
the
API
call
to
create
a
volume
can
return
correctly
and
yet
the
volume
would
never
created
any
way.
I
can
attach
a
create
and
attach
sequence
can
return
correctly,
but
not
do
anything.
The
only.
F
A
I
have
an
idea
that
is
probably
a
stupid
idea,
so
please
everyone
feel
free
to
say
so.
My
reason
this
doesn't
work,
sorry
go
ahead,
so
one
of
the
things
that
I
was
thinking
about
is
we're
talking
about
positive,
positive
capabilities
things
that
should
happen.
What
about
trying
flipping
it
around
and
saying
if
this
is
designed
to
describe
a
common
set
of
functionality?
Is
there
something
to
be
gained
by
focusing
on
a
on
a
test
at
something
that
would
be
a
compatibility
barrier
between
different
implementations
or
instances
of
installed
instances
of
OpenStack.
B
I
I
hear
what
you're,
saying
and
I
think
it's
it's
a
relevant
perspective,
but
I
think
we
will
get
ourselves
into
trouble
if
we
start
trying
to
second-guess
which
things
will
be
a
barrier
in
which
one
I
mean
I.
Think
we
should
assume
that
if
we're
considering
it
and
it
passes
the
criteria,
then
it
is,
it
is
potentially
an
interoffice
you.
B
A
B
B
C
B
A
Just
you
said
it
I
agree
that
it's
not
the
job
here
to
write
the
test.
It's
our
job
to
define
that
something
is
his
core.
Not
I.
Do
I,
don't
think
it's
out
of
the
realm
of
of
what
this
group
is
supposed
to
decide
to
say
if
something
is
not,
it
has
not
been,
then
is
something
that
testable
is
something
not
verifiable,
and
maybe
it
doesn't
belong
as
parkour.
What
have
recordings
of
being
yeah.
C
C
B
B
I
think
the
right
way
to
do
that
is
to
take
the
spreadsheet
that
Catherine
and
Andrew
have
and
work
with
and
gentle
to
look
at.
Are
there
other
things
that
are
in
the
docs
that
are
not
in
the
spreadsheet
and
then
are
there
things
in
the
spreadsheet
for
which
there
are
no
tests?
That
should
give
us
that
gap
I
just
wish
that
was
somebody
else's
job.
That's
a
lot
of
work
so.
C
I
think
this
is
going
to
fall
out.
Naturally,
okay,
and
from
my
perspective,
this
is
a
pressure.
It's
a
pressure,
release
valve
okay,
so
because
I
think
what
it's
going
to,
let
us
do.
Is
they
look?
Yes,
we
know
that
at
your
favorite
project
is
not
included
in
core,
and
one
of
the
reasons
is
that
there
wasn't
sufficient
testing
and
by
providing
a
list
we
actually
have
a
mechanism
to
click.
You
know
people
giving
a.
B
B
B
H
B
B
H
H
B
C
Thing
we
can
do
is
come
back
and
say
this
API
a
lot
of
people
want,
but
there's
not
enough
coverage
for
it.
Therefore,
it's
not
core
I,
actually
think
that's
the
right
stick
and
carrot
frankly,
the
people
who
believe
this
is.
You
know
the
exactly
the
thing.
If
somebody
believes
that
this
is
a
core
capability,
literally
move
his.
F
F
G
D
B
Did
have
issues
previously
with
the
process
to
expand
test
coverage
on
older
releases.
So
again,
we
need
to
make
sure
that
our
our
focus
is
always
on
encouraging
people
to
add
tests
in
the
current
cycle
for
the
current
code,
because
there
actually
isn't
a
process
to
backport
things
into
stable,
very
well.
C
B
C
C
B
We
don't
define
the
test,
I
mean
I,
think
it's.
The
criteria
committee
will
end
up
saying
these
are
the
slate
of
tests
that
we
believe
these
are
the
criteria
we
believe
should
be
applied,
we'll
go
through
and
say
these
are
the
tests
that
we
believe
should
be
used
to,
as
must
have
if
some
of
those
are
quite
our
quality
tests.
B
A
I
guess
part
of
what
I'm
thinking
is
because
we're
approaching
this
from
this
is
ultimately
a
trademark
exercise.
That
is
it.
It
really
has
I.
Guess
I
think
this
is
trade,
trade,
trade
mark
and
interop,
but
when
you
approach
this
from
a
trademark
perspective-
and
you
have
that
frame
on
this-
is
about
what
do
we
want
to
establish
as
what
does
the
brand
OpenStack
mean
in
various
senses?
G
A
Say
that
we
are,
you
know
we
think
that
in
we
think
that
saying
that
there's
a
certain
quality
of
implementation
that
is
required
to
be
open,
stacker
opens
a
compatible
or
whatever
the
marks
are,
because
we
want
people
to
be
able
to
say
with
a
certain
degree
of
assurance.
Oh
that
such-and-such
public
cloud
is
built
on
OpenStack
they're
branded
OpenStack
I
know
that
I
can
count
on
a
certain
level
of
quality
and
quality
associated
with
that
I.
Don't
think
there
are
eight.
B
I
agree
me
personally,
but
I
also
know
that
that
debate
is
what
derailed
the
fits
process.
The
first
time
we
tried
to
do
deaf
core
two
years
ago,
some
very
cautious
about
introducing
it
again
without
without
a
little
bit
of
further
thought,
I
think
we
should
put
it
into
the
criteria
so
comedian
and
come
back
at
it.
Is
that
make
sense.
A
C
B
B
C
B
C
B
C
C
C
B
C
C
C
B
C
B
C
Would
be
helpful,
alright,
so,
back
to
the
stage
two
I
I
learned,
something
when
we
started
doing
this:
the
startup,
the
kickoff
for
this
that
helped
eliminate
it
and
then
consequently
watch
us
really
mangle
this
in
the
community,
which
was
the
difference
between
programs
and
projects
and
the
application
of
the
OpenStack
trademarks.
So
there's
a
couple
things
that
are
very
easy:
the
cause
of
the
words
OpenStack
compute
OpenStack,
networking,
our
programs.
There
is
no
dispute
about
that
and
those
clearly
have
the
trademark
OpenStack
p.m.
C
networking
of
the
SEC
TM
compute,
and
it
is
completely
clear
that
you
can
use
the
trademark
to
describe
the
programs
in
that
sense
and
there's
a
there's.
A
set
of
programs
that
have
been
defined
I
suspect,
probably
need
to
be
for
gratified,
so
I
don't
remember
voting
on
them,
but
that
that
seems
very
clear.
It's
also
very
clear
that
we
have
a
set
of
projects
and
OpenStack
that
are
very
clearly
defined
boundaries
with
TCS
and
things
like
that.
C
So
with
the
way
they
said
it
is
the
project.
Kilometer
is
now
known
as
OpenStack
telemetry
trademark
and
which
point
I
raise
the
flag
of
hold
on
a
second.
My
understanding
of
the
program
definition
is
that
you
would
say:
project
salamat
ER
is
a
member
of
the
OpenStack
telemetry
program,
not
that
it
is
it
then
just
like.
So
we
have
a
couple
of
programs
that
might
only
have
one
member,
so
OpenStack
compute
has
is
comprised
of
the
Nova
project.
I
found
it
also
had
clients
in
the
glass
probably
be
right
in
the
glass
project.
C
K
B
K
B
B
E
B
F
E
E
F
Being
things
where
we
don't
want
them
to
be
inherently
competitive,
but
I
wouldn't
mind
seeing
projects
petev
within
a
program
so
that
a
project
you
know
when
you've
got
somebody
could
build
another
project
that
might
be
competitive
with
another
one's
in
the
program.
But
then
the
one
that
wins
over
time
sort
of
floats
to
the
surface
like
I
know
it.
That
seems
useful
to
me.
D
D
You
know
we're
talking
about
something:
it's
a
consistent
quality,
that's
fundamental
to
trademark.
So
the
other
issue-
and
this
is
a
separate
one-
is
to
date
and
the
protection
has
been
focused
on
the
OpenStack
brand
and
certain
you
know.
Variations
on
that
generally
I
think
involving
logos
and
stuff.
D
That
means
that
somebody
else
could
have
registration
for
compute
and
they
could
object
to
the
use
of
OpenStack
compute,
and
this
is
a
problem
that
happens.
You
know,
we've
already
obviously
had
it
once
I
think
within
the
OpenStack
foundation,
but
it
also
happens
and
other
foundations
for
people
adopt
sup
informally,
it
isn't
cleared,
they
get,
they
fall
in
love
with
it
and
then
they
discover
somebody
else.
Has
it
so,
to
the
extent
that
you
are,
you
know
authorizing
the
use
of
things
like
OpenStack
compute.
D
You
need
to
think
to
consequence
that
and
risk
that
somebody
may
have
the
brand,
maybe
not
compute,
but
maybe
it's
you
know,
OpenStack
XXX,
whatever
you
know,
we
choose
in
the
future
that
if
we
don't
go
through
a
formal
clearance
process
and
we
don't
protect
it,
we
could
find
people
getting
demand,
letters
and
all
sorts
of
other
things.
So
that
is
one
of
the
consequences
of
you
know,
adding
adding
stuff
on
and
I
guess.
The
third
component,
I
would
say
is
I
think
there
has
to
be
a
very
clear,
ketek,
a
tional
campaign.
D
If
we
go
down
this
path
about
the
fact
that
there's
a
number
of
things
that
can
be
used
attached
to
open
sack,
because
my
concern
is,
as
you
know,
OpenStack
becomes
more
ubiquitous
and
people
see
open,
sac,
X
and
open
sec.
Why
an
open
set,
see
they're
going
to
just
like
the
problem
we
had
with
IBM
they're
going
to
think
well,
yeah
I
can
put
open
sac
pay
because
that's
okay,
but
you
know
that's
just
an
educational
thing.
Well,.
C
C
Right,
that's
so
mark
I
would
actually,
I
think
that
we
want
to
be
able
to
go
through
the
foundation
to
say
we're
thinking
of
using
OpenStack
X
AAS
as
a
as
a
program
clear.
It
make
sure
it's
good
right.
There's,
there's
no
surprise
programs
popping
up
here's
some
for
the
one
or
two
or
three
projects
that
we
think
are
candidates
as
members
clear
it
and
they.
D
J
D
It's
going
to
be
you're
going
to
be
adding
layering
on
some
expense.
So,
as
you
think
about
the
value
having
OpenStack
foo,
you
know
in
the
clotting
you
need
to
think
about
the
cost
of
clearing
through
and
protecting
foo.
And
you
know,
that's
just
the
nature
I
mean
now.
There
is
I,
think
alternative
we're
instead
of
doing
OpenStack
food,
you
do
the
food
program,
the
food
component
of
OpenStack
software,
or
something
like
that.
Maybe
that's
too
much
from
mouthful,
and
maybe
we
think
we
want
to
avoid
that.
D
Yeah
I
mean
you
could
still
have
people
come
after
you
and
say
well,
foo
is
actually
my
brand.
You
can't
use
the
food
component,
but
at
least
you
don't
have
it
plugged
on
to
OpenStack
I
mean
anytime.
You
anytime,
you
name
any
of
these
components.
You
have
unless
the
names
totally
generic
means.
So
you
know.
C
D
B
D
F
D
F
A
Mungus,
at
least
I
would
say
the
generic,
at
least
in
this
trade
because
of
its
used
in
so
many
areas,
it's
a
term
of
art
yet
where
it
can
be
used
in
different
senses.
But
here
it
has
a
clearly
defined
commodity
meeting,
meaning
I
I
agree
that
I
don't
think
that
orchestration
alone
can
be
protectable.
I
actually.
C
Remember
when
we
started
this
because
of
the
trademark
issue,
those
terms
were
specifically
chosen
because
they
were
considered
brand
new
neutral
and
not
not
all
right.
That's
part
of
what
we're
trying
to
do
with
this,
as
we
are
trying
to
protect
the
projects
from
trademark
issues
by
creating
by
putting
them
under
clearly
defensible
trademark
right.
So
my
understanding
of
doing
this
was
that
we
would
not
have
to
worry
about
whether
Nova
was
trademarked
full,
but
it's
OpenStack
compute.
C
It
is
our
trademark,
the
project
is
Nova,
and
so,
if
you
want
it
and
here's
the
purpose,
if
you
want
to
stay
call
it
OpenStack,
you
have
to
use
the
trademark
acceptable
term
up
and
SAT
compute
and
then
say,
project
Nova,
and
that
keeps
us
out
of
the
oh
wait.
You
you're
you're
neutron
or
sorry,
oh
I'm,
successfully
over
the
hump
quantum,
your
quantum
using
the
word
project
cause
of
infringes
on
the
trade
market.
If
we
always
said
OpenStack
necklaces
project
quantum,
there
would
have
been
no
confusion
in
my
in
my
access.
C
D
I
mean
kids,
a
tip
guys
just
to
give
you
an
example
I'm
on
the
you
know,
the
the
PTO
website
and
there's
commerce
orchestration,
which
is
a
registered
trademark
for
e-commerce
software
to
facilitate
ecommerce
and
there's
no
disclaimer
of
orchestration.
So
whatever
the
facts
are,
you
know
the
Patent
and
Trademark
Office
curly
considers
orchestration
as
something
that's
potentially
protectable.
There's
mobile
care
orchestrations,
which
is
a
service
mark,
so
I
guess
what
I'm
saying
is
I
think
we
may
need
to
drill
down
a
little
bit
more
when
we
say
well.
D
And
mother
yeah,
but
there's
no
disclaimer.
Well,
let's
not
get
into
legal
point.
The
one
is
the
patent
trademark
offices
not
said
that
orchestration
is
generic
for,
for
you
know,
for
computer
services,
so
as
we
think
so
as
we
go
back
and
I
think
we
got
to
go
back
and
look
at
everything,
we're
using
and
run
it
through
that
you
know
the
Patent
and
Trademark
what
you
know
search
base
to
make
sure
we
have
got
something
that
somebody
thinks
is
protect
all
or
that
the
patent
and
trademark
office
thinks
is
predictable.
So
so
alright.
B
So
the
the
resolution
I
think
still
stands,
which
is
that
there
is
some
confusion
around
programs
and
projects.
The
Deaf
core
committee
believes
that
it
is
appropriate
to
refer
primarily
to
programs
as
the
thing
that
can
use
OpenStack
marks
outside
of
the
commercial
market
policy
that
we
are
talking
about
as
the
purpose
of
death
Corps,
and
that
we
would
like
to
work
with
the
board
and
the
TC
on
limiting
the
proliferation
of
programs
and
resolving
this
confusion
around
there
being
a
one-to-one
mapping
between
projects
and
programs.
G
Even
if
you
Britain,
as
you
wrap,
even
if
you
wrap
those
around
one,
there
is
some
mechanism
by
which,
like
right
now,
you've
got
heat
and
salamat
ER,
for
instance,
but
can't
use
it
can't
be
called
OpenStack.
Anything
right,
they're
not
officially
tied
to
OpenStack,
because
for
the
current
limitations
of
the
core
definition.
So
we
have
to
solve
that
problem
as
well,
regardless
of
whether
we
have
the
programs
and
projects
grouping
discussion
am.
C
And
so
the
actions
are
going
to
jess's
that
we
should
recommend
to
the
board
the
lifts
of
program
names
to
be
added
to
be
used
in
the
bylaws
instead
of
project
names,
because
that
change
we
need
to
make.
We
are
actually
chartered
to
make
it
put
it
in
as
that,
and
then
ask
the
TC
to
nominate
projects
or.
B
C
Be
included
in
a
program,
and
then
so
what's
what's
happening
is
that
we
still
have.
We
still
have
the
relationship
and
the
control,
but
what
would
happen
in
this
case
is
the
board
says
opens
that
compute
OpenStack,
networking,
OpenStack
blah,
are
considered
core
OpenStack
projects
according
to
the
definition
in
the
bylaws
in
that
controversial
paragraph
period,
and
then
the
TC
can
ask
to
have
a
project
included
in
the
program,
so
they
would
be
coming
to
us
and
saying
board.
C
C
C
C
C
B
C
This
is
what
what
I'm
hoping
to
do
with
my
suggestion
is
to
just
is
to
break
this
law
Jam,
where
the
things
in
the
bylaws
or
programs,
and
they
don't
change
and
they're
very
flex,
their
very
in
this
market.
Think
this
address
is
your
concern.
We
have
a
set
of
OpenStack
capabilities,
are
clearly
delineated
at
trade
markable
level,
and
then
what
we're
really
doing
is
controlling
what
things
are
included.
Those
programs
are
not
consistent.
This
program
and.
G
G
C
L
G
B
G
G
Until
you
carry
ideas,
get
a
way
of
using
OpenStack
from
any
projects,
but
then
the
way
that
projects
get
associated
with
an
OpenStack
brand
as
they
become
officially
approved
as
part
of
an
open
side
branded
program.
I'm
just
saying
this
out
loud
because
it
helps
me
understand
it,
but
I
think
that's
what.
D
D
J
H
B
Expense,
we
are,
we
are
specifically
trying
to
not
ever
have
it
called
OpenStack
nova,
also
because
the
projects
are
likely
to
mature
and
end
of
life,
where
the
programs
will
not
end
Keystone
conversion
to
keystone
light
conversion
back
to
Keystone
is
a
great
example
of
that.
That's
33
databases.
Now
it.
G
Makes
perfect
line
is
now
sort
of
none
of
those
sort
of
celtics.
I
think
it
solves
the
tc's
problem,
which
is
they
want
a
way
to
associate
the
OpenStack
brand
with
projects.
Not
I
mean
obvious,
I
don't
think
it
needs
to
be
direct,
and
I
think
it
gives
us
that
ability
of
it
easier
to
maintain,
because
if,
if
we
had
to
do
this
for
every
potential
project
that
come
together,
piston
back
bear,
that
is
just
crazy,
so
it.
B
Also
gives
it
also
gives
the
the
separation
of
concerns
between
the
CC
and
the
board
that
we've
been
trying
to
achieve,
which
is
the
board
can
say.
These
programs
are
logically
part
of
OpenStack
and
the
TC
can
then
say
all
right.
Well,
we
believe
that
these
projects
are
the
expression
of
those
programs
crap.
It
also
makes
when
the
TC
can
kick
a
project
out,
if
it's
necessary
with
the
board
without.
G
E
B
That
is
the
confusion
right
now
about
the
fact
that
programs
and
projects
have
one-to-one
correspondence.
Yes,
glance
actually
has
an
image,
an
OpenStack
image
program
or
an
OpenStack
image
service
program
right
now,
which
seems
inappropriate,
but
it
was
to
resolve
this
issue
of
having
a
PTL
position
being
one
PTL
for.
C
B
C
K
D
D
D
G
L
To
our
discussion,
even
in
today's
BT
meeting
about
a
recent
incubation
of
class
and
the
program
project
lines,
and
especially,
is
our
end
goal
collaboration
or
is
our
end
goal.
Competition
so
definitely
need
some
shopping
around
the
TC.
But
if
you
could
put
it
in
a
mailing
list,
read
I
think
it
would
be
really
perfect
timing
strike
while
the
iron
is
hot.
If.
C
C
B
C
D
D
B
D
Actually,
the
way
it
works
is
that
the
board
you're
right
the
board
determines
what
score,
but
they
can
only
do
that
based
on
recommendation
from
a
technical
committee.
What
I'm
saying
is
we
can
delegate
to
the
technical
committee,
the
naming
of
those
programs
not
determining
what
they
are,
but
what
I'm
all
I'm
trying
to
do
is
I
would
prefer
not
to
go
from
a
situation
where
we
have
a
bunch
of
names.
D
E
And
I
think
what
we
want
to
do
is
think
about
a
process
by
which
to
add
new
programs,
because
I
agree
that
once
you
put
them
in
the
bylaws
having
any
new
ones
are
amending
them.
The
future,
like
the
one
change
the
telemetry
just
went
recently
under,
that
is
going
to
be
very,
very
hard
to
figure
open,
Tek
groves.
So.
G
D
C
You're,
here,
okay,
so
for
the
agenda
for
the
next
meeting,
I
have
two
items
right
now:
the
review,
the
staff,
the
tempest
coverage,
actually
three
we're
going
to
have
a
readout
from
the
criteria
meeting
actually
really
have
to
prove.
We
have
to
discuss
the
criteria
and
then
we're
going
to
plan
program
versus
project
actions
by
the
board.
That's
a
full
agenda
and.
C
I
F
F
C
C
B
A
That's
basically
how
it
works,
because
they
need
to
work
across
our
leases,
and
so,
let's
give
one
example,
which
I
think
maybe
clarify:
let's
say
that
a
Linux
distributor
and
took
the
OpenStack
package
and
then
they
put,
and
then
they
bundled
in
an
additional
set
of
functionality.
They
bundled
in
a
maybe
there's
as
a
new
virtualization
driver
that
they
built
they
bundle
it
that's
good,
then
what
would
be
covered
under
oin
would
be
the
functionality
associated
with
the
release
from
OpenStack
org
and
would
explicitly
exclude
that
the
vendor
added
functionality,
unless
that
was
separate.
B
B
A
What
they
walked
is,
and
the
reason
why
oin
is
important
is
because
it
is
defining
a
set
of
cross
licensed
functionality
that
if
someone
has
a
patent
that
breeds
on
something
in
one
of
those
packages,
some
functionality
in
one
of
those
packages.
As
of
the
identified
version,
then
that
is
cross
license
within
that
oin
community,
though
what
we
want
and
we're
also
working
on
a
broader
set
of
patent
patent
defenses,
both
for
with
an
OpenStack
and
for
externally
facing
so
we
need
to
decide,
hey
it.
A
A
We
we
are
going
to
allow
and
empower
the
foundation
to
to
fight
back
on
that
and
to
to
participate
in
a
legal
defense
fund
around
that
which
case
what
people
are
going
to
say.
Well,
what
is
included
in
that
sort
of
program,
for
example,
would
Savannah
be
included,
or
would
someone
had
someone
that
did
patent
infringement
and
accuse
of
Anna?
Would
that
be
included
or
not?
C
So
the
bill
is
actually
is
not
as
clear
to
me,
because
the
purpose
that
we're
defining
with
death
with
death
Corps
is
the
minimum
set,
but
it's
required.
If
you
want
to
claim
the
trademark
I
think
there's
clearly
things
that
are
beyond
that
and
we
want.
We
want
to
be
beyond
it
right,
we've
discussed
and
he
previously
account
the
concept
of
Commons.
J
C
B
The
other
challenge,
the
other
potential
challenges
that
there
is
no
logical
association
between
openstack
and
linux,
in
the
sense
that
OpenStack
can
be
run
on
a
Windows
machine
using
hyper-v
and
hosting
windows
VMs,
so
I
don't
object
to
including
it
in
Linux
system
definition.
But
I
think
we
are
stretching
the
linux
system
definition
specifically
what
we're
doing
things
like,
including
the
hyper-v
driver
in
it,
silently
there
are
negative
impacts
on
what.
D
Just
one
question
here
is
from
a
def
core
point
of
view,
so
let's
just
remember
that
oin
did
this
on
their
own.
I
completely
agree
that
they're
taking
the
linux
definition
and
just
well
in
extending
it
in
a
way
which
I
don't
think
people
anticipate
it,
but
that
is
what
it
is.
I'm,
not
sure
you
know
so
from
an
I
think
getting
the
coverage
from
the
lion
is
very
helpful.
D
I'm,
not
sure
how
big
an
issue
it
is
for
deaf,
gorgs
I,
think
def
core
is
focused
on
what
do
we
think
the
trademark
should
be
used
on
so
the
fact
that
we
have
a
patent
cross-license
and
that
patent
cross-license
covers
things
that
are
may
not
be
within
the
scope
of
the
trademark?
I,
don't
think,
is
critical.
D
I
just
mean
I,
don't
you
know
in
particular
since
oh
I
am,
is
the
third
party
who
has
demonstrated
a
certain
independence
I
think
it's
the
kind
way
of
putting
it.
You
know
they
didn't
actually
come
to
us
prior
prior
to
doing
this,
I
would
be
loath
to
get
to
you
know.
You
know,
give
them
more
power
right,
so
yeah
I
would
suggest.