Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-22 Thread Adam Lawson
Let me toss out my perspective (FWIW) from a cloud planning perspective as
relates to single-vendor projects:

As an established OpenStack and cloud SDN architect and by extension a
working owner, I do design work for lots of the companies who read this
list. Let me just say that from where I sit, there is rarely a time where I
or any of my colleagues have been able to recommend using an open source
project developed by single vendor driving development for obvious reasons.
Companies usually consider OpenStack because of the open standard, modular
framework and vendor avoidance (not tied to one that is). If part of your
cloud strategy uses a tool developed by one vendor, your entire cloud is
tied to that tool and unfortunately, organizations end up doing this as a
result of politics, partner commitments and/or perceived safety of projects
developed by a familiar entity. Software developed by a single company is a
risk which affects adoption[1]. Who is driving an open source project is a
key consideration by cloud consumers. The biggest exception to this that
I've seen is Ceph given the staying power of RHEL (and/or the perceived
safety in using a product developed by a recognized Linux distro).

I'm glad we're discussing this and I want to re-iterate that project
diversity within the big tent is more important than how each project
integrates into OpenStack's development process. There's a perception that
comes with the association with membership. Projects in the big tent and
the evangelized reasons for they're there are being closely watched by more
than just our community. And cloud planners such as myself and many others
are watching for our own reasons as well.

Just adding that there's a perception that drives adoption by how we
structure and evangelize the Big Tent idea.

Anyway, ; )

[1]
http://www.zdnet.com/article/google-intel-and-mirantis-rewrite-openstacks-life-cycle-management-tool/

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Fri, Aug 5, 2016 at 6:26 AM, Zane Bitter  wrote:

> On 04/08/16 23:00, joehuang wrote:
>
>> I think all the problem is caused by the definition "official OpenStack
>> project" for one big-tent project.
>>
>> I understand that each OpenStack vendor wants some differentiation in
>> their solution, while also would
>> like to collaborate with common core projects.
>>
>
> Nobody wants this. We want to build a fully-featured cloud that can run
> the same kinds of apps that users might develop for AWS/Azure/GCE, and we
> want those apps to be portable substantially everywhere. It's all right
> there in the Mission Statement.
>
> If we replace the title "official OpenStack project" to "OpenStack
>> ecosystem player", and make "big-tent"
>> as "ecosystem play yard" ( no close roof ), TCs can put more focus on
>> governance of core projects
>> (current non-big-tent projects), and provide a more open place to grow
>> abundant ecosystem.
>>
>
> You're describing the exact situation we had before the 'big-tent' reform.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-05 Thread Zane Bitter

On 04/08/16 23:00, joehuang wrote:

I think all the problem is caused by the definition "official OpenStack 
project" for one big-tent project.

I understand that each OpenStack vendor wants some differentiation in their 
solution, while also would
like to collaborate with common core projects.


Nobody wants this. We want to build a fully-featured cloud that can run 
the same kinds of apps that users might develop for AWS/Azure/GCE, and 
we want those apps to be portable substantially everywhere. It's all 
right there in the Mission Statement.



If we replace the title "official OpenStack project" to "OpenStack ecosystem player", and 
make "big-tent"
as "ecosystem play yard" ( no close roof ), TCs can put more focus on 
governance of core projects
(current non-big-tent projects), and provide a more open place to grow abundant 
ecosystem.


You're describing the exact situation we had before the 'big-tent' reform.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread joehuang
I think all the problem is caused by the definition "official OpenStack 
project" for one big-tent project.

I understand that each OpenStack vendor wants some differentiation in their 
solution, while also would
like to collaborate with common core projects.

If we replace the title "official OpenStack project" to "OpenStack ecosystem 
player", and make "big-tent"
as "ecosystem play yard" ( no close roof ), TCs can put more focus on 
governance of core projects
(current non-big-tent projects), and provide a more open place to grow abundant 
ecosystem. The bigger the 
ecosystem is, the more scenario and demand for cloud operators(public, private, 
hybrid) can be fulfilled
with different choices, and the competition will also help to grow the best one.

Best Regards
Chaoyi Huang (joehuang)


From: Erno Kuvaja [ekuv...@redhat.com]
Sent: 05 August 2016 1:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On Thu, Aug 4, 2016 at 9:56 AM, Duncan Thomas <duncan.tho...@gmail.com> wrote:
> On 1 August 2016 at 18:14, Adrian Otto <adrian.o...@rackspace.com> wrote:
>>
>> I am struggling to understand why we would want to remove projects from
>> our big tent at all, as long as they are being actively developed under the
>> principles of "four opens". It seems to me that working to disqualify such
>> projects sends an alarming signal to our ecosystem. The reason we made the
>> big tent to begin with was to set a tone of inclusion. This whole discussion
>> seems like a step backward. What problem are we trying to solve, exactly?
>
>
> Any project existing in the big tent sets a significant barrier (policy,
> technical, mindshare) of entry to any competing project that might spring
> up. The cost of entry as an individual into a single-vendor project is much
> higher in general than a diverse one (back-channel communications,
> differences in vision, monoculture, commercial pressures, etc), and so
> having a non-diverse project in the big tent reduces the possibilities of a
> better replacement appearing.
>

Actually I couldn't disagree more. Since big tent and stackforge move
under the openstack name space the effect has been exactly the
opposite. Competitors have way less needs to collaborate with each
other to be part of OpenStack as anyone could just kick up their own
project and do it in their way still being part of the
community/ecosystem/what-ever-you-want-to-call-it.

We see projects splitting more when they do not share the core
concepts (which is good thing) but we do not see projects combining
their efforts when they do overlapping things. Maybe we do see this
lack of diversity just growing as long as we don't care about it (tag
here, another there is not going to slow the company behind the
project pushing it to their customers even there was more diverse or
better options, it's still part of OpenStack and it's "ours"). If we
start pushing the projects that are single vendor out of the big tent,
we give more pressure for multiple of those to combine their efforts
rather than continue competing for same thing and if they don't want
to play together I don't see anything wrong to send clear message that
we don't want to share the cost of it.

I personally see the proposed as not limiting the competition to
appear but rather the single-vendor competition might not stick around
when the competing projects would be under a threat to be thrown out.
If someone brings competing project into the ecosystem, 18 months is
also pretty decent time to see if that approach is superior enough (to
attract the diversity) and justify it's existence or if those people
just should try to play with others instead of doing their own thing.

I'm all for the selective inclusion based on meritocracy, not only on
person level, but on project level as well.

- Erno

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Chris Friesen

On 08/04/2016 01:52 PM, Jay Faulkner wrote:


Ironic does have radosgw support, and it's documented here:
http://docs.openstack.org/developer/ironic/deploy/radosgw.html -- clearly it's
not "first class" as we don't validate it in CI like we do with swift, but the
code exists and I believe we have users out in the wild.


If it's not validated in CI, it's broken.  At least that's my experience with 
nova and cinder...


Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Fox, Kevin M
Awesome. Thanks for letting me know. :) This does raise it back up on my 
priority list a bit, as i know its more likely to work now with less effort.

Thanks,
Kevin

From: Jay Faulkner [j...@jvf.cc]
Sent: Thursday, August 04, 2016 12:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects


On Aug 4, 2016, at 12:43 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:

The problem is, OpenStack is a very fractured landscape. It takes significant 
amounts of time for an operator to deploy "one more service".

So, I spent a while deploying Trove, got it 90% working, then discovered Trove 
didn't work with RadosGW. RadosGW was a done deal long ago, and couldn't be 
re-evaluated at that point. (Plus you cant have more then one swift endpoint in 
a cloud...). So, for now, I'm supporting a 90% functional Trove.

If I went and installed Ironic tomorrow, would it work with the radosgw I 
already have? I have no idea. The, "it supports swift" implies but doesn't 
answer. If I want to consider deploying it now, I have to block out even more 
time to experiment in order to try. and then do a bunch of manual testing to 
verify.


Ironic does have radosgw support, and it's documented here: 
http://docs.openstack.org/developer/ironic/deploy/radosgw.html -- clearly it's 
not "first class" as we don't validate it in CI like we do with swift, but the 
code exists and I believe we have users out in the wild.

I know this is orthogonal to the discussion, but I wanted someone seeing this 
thread to know it does work :).

Thanks,
Jay Faulkner
OSIC

This kind of thing makes it even harder on operators to deploy new services.

Yes, it could be solved at the Ceph level, where they deploy a complete 
OpenStack with all the advanced services and test everything, but OpenStack is 
already doing that. It is significantly easier for OpenStack to test it instead 
of Ceph.

Thanks,
Kevin





From: Ben Swartzlander [b...@swartzlander.org<mailto:b...@swartzlander.org>]
Sent: Thursday, August 04, 2016 12:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 03:02 PM, Fox, Kevin M wrote:
Nope. The incompatibility was for things that never were in radosgw, not things 
that regressed over time. tmpurls differences and the namespacing things were 
there since the beginning first introduced.

At the last summit, I started with the DefCore folks and worked backwards until 
someone said, no we won't ever add tests for compatibility for that because 
radosgw is not an OpenStack project and we only test OpenStack.

Yes, I think thats a terrible thing. I'm just relaying the message I got.

I don't see how this is terrible at all. If someone were to start up a
clone of another OpenStack project (say, Cinder) which aimed for 100%
API compatibility with Cinder, but outside the tent, and then they
somehow failed to achieve true compatibility because of Cinder's
undocumented details, nobody would proclaim that the this was somehow
our (the OpenStack community's) fault.

I think the Radosgw people probably have a legitimate beef with the
Swift team about the lack of an official API spec that they can code do,
but that's a choice for the Swift community to make. If users of Swift
are satisfied with a the-code-is-the-spec stance then I say good luck to
them.

If the user community cares enough about interoperability between
swift-like things they will demand an API spec and conformance tests and
someone will write those and then radosgw will have something to conform
to. None of this has anything to do with the governance model for Ceph
though.

-Ben Swartzlander



Thanks,
Kevin

From: Ben Swartzlander [b...@swartzlander.org<mailto:b...@swartzlander.org>]
Sent: Thursday, August 04, 2016 10:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 11:57 AM, Fox, Kevin M wrote:
Ok. I'll play devils advocate here and speak to the other side of this, because 
you raised an interesting issue...

Ceph is outside of the tent. It provides a (mostly) api compatible 
implementation of the swift api (radosgw), and it is commonly used in OpenStack 
deployments.

Other OpenStack projects don't take it into account because its not a big tent 
thing, even though it is very common. Because of some rules about only testing 
OpenStack things, radosgw is not tested against even though it is so common.

I call BS on this assertion. We test things that outside the tent in the
upstream gate all the time -- the only requirement is that they be
released. We won't test against unreleased stuff that's outside 

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Jay Faulkner

On Aug 4, 2016, at 12:43 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:

The problem is, OpenStack is a very fractured landscape. It takes significant 
amounts of time for an operator to deploy "one more service".

So, I spent a while deploying Trove, got it 90% working, then discovered Trove 
didn't work with RadosGW. RadosGW was a done deal long ago, and couldn't be 
re-evaluated at that point. (Plus you cant have more then one swift endpoint in 
a cloud...). So, for now, I'm supporting a 90% functional Trove.

If I went and installed Ironic tomorrow, would it work with the radosgw I 
already have? I have no idea. The, "it supports swift" implies but doesn't 
answer. If I want to consider deploying it now, I have to block out even more 
time to experiment in order to try. and then do a bunch of manual testing to 
verify.


Ironic does have radosgw support, and it's documented here: 
http://docs.openstack.org/developer/ironic/deploy/radosgw.html -- clearly it's 
not "first class" as we don't validate it in CI like we do with swift, but the 
code exists and I believe we have users out in the wild.

I know this is orthogonal to the discussion, but I wanted someone seeing this 
thread to know it does work :).

Thanks,
Jay Faulkner
OSIC

This kind of thing makes it even harder on operators to deploy new services.

Yes, it could be solved at the Ceph level, where they deploy a complete 
OpenStack with all the advanced services and test everything, but OpenStack is 
already doing that. It is significantly easier for OpenStack to test it instead 
of Ceph.

Thanks,
Kevin





From: Ben Swartzlander [b...@swartzlander.org<mailto:b...@swartzlander.org>]
Sent: Thursday, August 04, 2016 12:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 03:02 PM, Fox, Kevin M wrote:
Nope. The incompatibility was for things that never were in radosgw, not things 
that regressed over time. tmpurls differences and the namespacing things were 
there since the beginning first introduced.

At the last summit, I started with the DefCore folks and worked backwards until 
someone said, no we won't ever add tests for compatibility for that because 
radosgw is not an OpenStack project and we only test OpenStack.

Yes, I think thats a terrible thing. I'm just relaying the message I got.

I don't see how this is terrible at all. If someone were to start up a
clone of another OpenStack project (say, Cinder) which aimed for 100%
API compatibility with Cinder, but outside the tent, and then they
somehow failed to achieve true compatibility because of Cinder's
undocumented details, nobody would proclaim that the this was somehow
our (the OpenStack community's) fault.

I think the Radosgw people probably have a legitimate beef with the
Swift team about the lack of an official API spec that they can code do,
but that's a choice for the Swift community to make. If users of Swift
are satisfied with a the-code-is-the-spec stance then I say good luck to
them.

If the user community cares enough about interoperability between
swift-like things they will demand an API spec and conformance tests and
someone will write those and then radosgw will have something to conform
to. None of this has anything to do with the governance model for Ceph
though.

-Ben Swartzlander



Thanks,
Kevin

From: Ben Swartzlander [b...@swartzlander.org<mailto:b...@swartzlander.org>]
Sent: Thursday, August 04, 2016 10:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 11:57 AM, Fox, Kevin M wrote:
Ok. I'll play devils advocate here and speak to the other side of this, because 
you raised an interesting issue...

Ceph is outside of the tent. It provides a (mostly) api compatible 
implementation of the swift api (radosgw), and it is commonly used in OpenStack 
deployments.

Other OpenStack projects don't take it into account because its not a big tent 
thing, even though it is very common. Because of some rules about only testing 
OpenStack things, radosgw is not tested against even though it is so common.

I call BS on this assertion. We test things that outside the tent in the
upstream gate all the time -- the only requirement is that they be
released. We won't test against unreleased stuff that's outside the big
tent and the reason for that should be obvious.

This causes odd breakages at times that could easily be prevented, but for 
procedural things around the Big Tent.

The only way I can see for "odd breakages" to sneak in is on the Ceph
side, if they aren't testing their changes against OpenStack and they
introduce a regression, then that's their fault (assuming of course that
we have good test c

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Fox, Kevin M
The problem is, OpenStack is a very fractured landscape. It takes significant 
amounts of time for an operator to deploy "one more service".

So, I spent a while deploying Trove, got it 90% working, then discovered Trove 
didn't work with RadosGW. RadosGW was a done deal long ago, and couldn't be 
re-evaluated at that point. (Plus you cant have more then one swift endpoint in 
a cloud...). So, for now, I'm supporting a 90% functional Trove.

If I went and installed Ironic tomorrow, would it work with the radosgw I 
already have? I have no idea. The, "it supports swift" implies but doesn't 
answer. If I want to consider deploying it now, I have to block out even more 
time to experiment in order to try. and then do a bunch of manual testing to 
verify.

This kind of thing makes it even harder on operators to deploy new services.

Yes, it could be solved at the Ceph level, where they deploy a complete 
OpenStack with all the advanced services and test everything, but OpenStack is 
already doing that. It is significantly easier for OpenStack to test it instead 
of Ceph.

Thanks,
Kevin





From: Ben Swartzlander [b...@swartzlander.org]
Sent: Thursday, August 04, 2016 12:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 03:02 PM, Fox, Kevin M wrote:
> Nope. The incompatibility was for things that never were in radosgw, not 
> things that regressed over time. tmpurls differences and the namespacing 
> things were there since the beginning first introduced.
>
> At the last summit, I started with the DefCore folks and worked backwards 
> until someone said, no we won't ever add tests for compatibility for that 
> because radosgw is not an OpenStack project and we only test OpenStack.
>
> Yes, I think thats a terrible thing. I'm just relaying the message I got.

I don't see how this is terrible at all. If someone were to start up a
clone of another OpenStack project (say, Cinder) which aimed for 100%
API compatibility with Cinder, but outside the tent, and then they
somehow failed to achieve true compatibility because of Cinder's
undocumented details, nobody would proclaim that the this was somehow
our (the OpenStack community's) fault.

I think the Radosgw people probably have a legitimate beef with the
Swift team about the lack of an official API spec that they can code do,
but that's a choice for the Swift community to make. If users of Swift
are satisfied with a the-code-is-the-spec stance then I say good luck to
them.

If the user community cares enough about interoperability between
swift-like things they will demand an API spec and conformance tests and
someone will write those and then radosgw will have something to conform
to. None of this has anything to do with the governance model for Ceph
though.

-Ben Swartzlander



> Thanks,
> Kevin
> 
> From: Ben Swartzlander [b...@swartzlander.org]
> Sent: Thursday, August 04, 2016 10:21 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> On 08/04/2016 11:57 AM, Fox, Kevin M wrote:
>> Ok. I'll play devils advocate here and speak to the other side of this, 
>> because you raised an interesting issue...
>>
>> Ceph is outside of the tent. It provides a (mostly) api compatible 
>> implementation of the swift api (radosgw), and it is commonly used in 
>> OpenStack deployments.
>>
>> Other OpenStack projects don't take it into account because its not a big 
>> tent thing, even though it is very common. Because of some rules about only 
>> testing OpenStack things, radosgw is not tested against even though it is so 
>> common.
>
> I call BS on this assertion. We test things that outside the tent in the
> upstream gate all the time -- the only requirement is that they be
> released. We won't test against unreleased stuff that's outside the big
> tent and the reason for that should be obvious.
>
>> This causes odd breakages at times that could easily be prevented, but for 
>> procedural things around the Big Tent.
>
> The only way I can see for "odd breakages" to sneak in is on the Ceph
> side, if they aren't testing their changes against OpenStack and they
> introduce a regression, then that's their fault (assuming of course that
> we have good test coverage running against the latest stable release of
> Ceph). It's reasonable to request that we increase our test coverage
> with Ceph if it's not good enough and if we are the ones causing the
> breakages. But their outside status isn't the problem.
>
> -Ben Swartzlander
>
>
>> I do think this should be fixed before we advocate s

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Ben Swartzlander

On 08/04/2016 03:02 PM, Fox, Kevin M wrote:

Nope. The incompatibility was for things that never were in radosgw, not things 
that regressed over time. tmpurls differences and the namespacing things were 
there since the beginning first introduced.

At the last summit, I started with the DefCore folks and worked backwards until 
someone said, no we won't ever add tests for compatibility for that because 
radosgw is not an OpenStack project and we only test OpenStack.

Yes, I think thats a terrible thing. I'm just relaying the message I got.


I don't see how this is terrible at all. If someone were to start up a 
clone of another OpenStack project (say, Cinder) which aimed for 100% 
API compatibility with Cinder, but outside the tent, and then they 
somehow failed to achieve true compatibility because of Cinder's 
undocumented details, nobody would proclaim that the this was somehow 
our (the OpenStack community's) fault.


I think the Radosgw people probably have a legitimate beef with the 
Swift team about the lack of an official API spec that they can code do, 
but that's a choice for the Swift community to make. If users of Swift 
are satisfied with a the-code-is-the-spec stance then I say good luck to 
them.


If the user community cares enough about interoperability between 
swift-like things they will demand an API spec and conformance tests and 
someone will write those and then radosgw will have something to conform 
to. None of this has anything to do with the governance model for Ceph 
though.


-Ben Swartzlander




Thanks,
Kevin

From: Ben Swartzlander [b...@swartzlander.org]
Sent: Thursday, August 04, 2016 10:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 11:57 AM, Fox, Kevin M wrote:

Ok. I'll play devils advocate here and speak to the other side of this, because 
you raised an interesting issue...

Ceph is outside of the tent. It provides a (mostly) api compatible 
implementation of the swift api (radosgw), and it is commonly used in OpenStack 
deployments.

Other OpenStack projects don't take it into account because its not a big tent 
thing, even though it is very common. Because of some rules about only testing 
OpenStack things, radosgw is not tested against even though it is so common.


I call BS on this assertion. We test things that outside the tent in the
upstream gate all the time -- the only requirement is that they be
released. We won't test against unreleased stuff that's outside the big
tent and the reason for that should be obvious.


This causes odd breakages at times that could easily be prevented, but for 
procedural things around the Big Tent.


The only way I can see for "odd breakages" to sneak in is on the Ceph
side, if they aren't testing their changes against OpenStack and they
introduce a regression, then that's their fault (assuming of course that
we have good test coverage running against the latest stable release of
Ceph). It's reasonable to request that we increase our test coverage
with Ceph if it's not good enough and if we are the ones causing the
breakages. But their outside status isn't the problem.

-Ben Swartzlander



I do think this should be fixed before we advocate single vendor projects exit 
the big tent after some time. As the testing situation may be made worse.

Thanks,
Kevin

From: Thierry Carrez [thie...@openstack.org]
Sent: Thursday, August 04, 2016 5:59 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

Thomas Goirand wrote:

On 08/01/2016 09:39 AM, Thierry Carrez wrote:

But if a project is persistently single-vendor after some time and
nobody seems interested to join it, the technical value of that project
being "in" OpenStack rather than a separate project in the OpenStack
ecosystem of projects is limited. It's limited for OpenStack (why
provide resources to support a project that is obviously only beneficial
to one organization ?), and it's limited to the organization itself (why
go through the OpenStack-specific open processes when you could shortcut
it with internal tools and meetings ? why accept the oversight of the
Technical Committee ?).


A project can still be useful for everyone with a single vendor
contributing to it, even after a long period of existence. IMO that's
not the issue we're trying to solve.


I agree with that -- open source projects can be useful for everyone
even if only a single vendor contributes to it.

But you seem to imply that the only way an open source project can be
useful is if it's developed as an OpenStack project under the OpenStack
Technical Committee governance. I'm not advocating that these projects
should stop or disappear. I'm just saying that if they are very unlikely
to grow a more diverse affiliation in the future, they

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Fox, Kevin M
Nope. The incompatibility was for things that never were in radosgw, not things 
that regressed over time. tmpurls differences and the namespacing things were 
there since the beginning first introduced.

At the last summit, I started with the DefCore folks and worked backwards until 
someone said, no we won't ever add tests for compatibility for that because 
radosgw is not an OpenStack project and we only test OpenStack.

Yes, I think thats a terrible thing. I'm just relaying the message I got.

Thanks,
Kevin

From: Ben Swartzlander [b...@swartzlander.org]
Sent: Thursday, August 04, 2016 10:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 11:57 AM, Fox, Kevin M wrote:
> Ok. I'll play devils advocate here and speak to the other side of this, 
> because you raised an interesting issue...
>
> Ceph is outside of the tent. It provides a (mostly) api compatible 
> implementation of the swift api (radosgw), and it is commonly used in 
> OpenStack deployments.
>
> Other OpenStack projects don't take it into account because its not a big 
> tent thing, even though it is very common. Because of some rules about only 
> testing OpenStack things, radosgw is not tested against even though it is so 
> common.

I call BS on this assertion. We test things that outside the tent in the
upstream gate all the time -- the only requirement is that they be
released. We won't test against unreleased stuff that's outside the big
tent and the reason for that should be obvious.

> This causes odd breakages at times that could easily be prevented, but for 
> procedural things around the Big Tent.

The only way I can see for "odd breakages" to sneak in is on the Ceph
side, if they aren't testing their changes against OpenStack and they
introduce a regression, then that's their fault (assuming of course that
we have good test coverage running against the latest stable release of
Ceph). It's reasonable to request that we increase our test coverage
with Ceph if it's not good enough and if we are the ones causing the
breakages. But their outside status isn't the problem.

-Ben Swartzlander


> I do think this should be fixed before we advocate single vendor projects 
> exit the big tent after some time. As the testing situation may be made worse.
>
> Thanks,
> Kevin
> 
> From: Thierry Carrez [thie...@openstack.org]
> Sent: Thursday, August 04, 2016 5:59 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> Thomas Goirand wrote:
>> On 08/01/2016 09:39 AM, Thierry Carrez wrote:
>>> But if a project is persistently single-vendor after some time and
>>> nobody seems interested to join it, the technical value of that project
>>> being "in" OpenStack rather than a separate project in the OpenStack
>>> ecosystem of projects is limited. It's limited for OpenStack (why
>>> provide resources to support a project that is obviously only beneficial
>>> to one organization ?), and it's limited to the organization itself (why
>>> go through the OpenStack-specific open processes when you could shortcut
>>> it with internal tools and meetings ? why accept the oversight of the
>>> Technical Committee ?).
>>
>> A project can still be useful for everyone with a single vendor
>> contributing to it, even after a long period of existence. IMO that's
>> not the issue we're trying to solve.
>
> I agree with that -- open source projects can be useful for everyone
> even if only a single vendor contributes to it.
>
> But you seem to imply that the only way an open source project can be
> useful is if it's developed as an OpenStack project under the OpenStack
> Technical Committee governance. I'm not advocating that these projects
> should stop or disappear. I'm just saying that if they are very unlikely
> to grow a more diverse affiliation in the future, they derive little
> value in being developed under the OpenStack Technical Committee
> oversight, and would probably be equally useful if developed outside of
> OpenStack official projects governance. There are plenty of projects
> that are useful to OpenStack that are not developed under the TC
> governance (libvirt, Ceph, OpenvSwitch...)
>
> What is the point for a project to submit themselves to the oversight of
> a multi-organization Technical Committee if they always will be the
> result of the efforts of a single organization ?
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Ian Cordasco
 

-Original Message-
From: Fox, Kevin M <kevin@pnnl.gov>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 4, 2016 at 13:40:53
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [tc] persistently single-vendor projects

> Sorry, I was a bit unclear here. I meant the radosgw in particular. I've seen 
> multiple  
> OpenStack projects fail to integrate with it.
>  
> The most recent example I can think of is Trove can't do database backups to 
> it as the namespacing  
> is slightly different in the older radosgw versions. (I think this is made 
> more uniform  
> in Jewel, but I haven't tested it). I know tempurl's work slightly 
> differently too so  
> may affect services that work with them.
>  
> I don't think the differences are really intentional, more that there isn't 
> an official  
> swift api spec and no cross testing is done because the OpenStack api test 
> suite doesn't  
> run against radosgw as its not in the tent.

And yet there's nothing stopping the radosgw developers (who are apparently 
aiming for Swift compatibility) from running those tests themselves in their 
testing infrastructure. The tests are open source even if there's no written 
specification for the API.

--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Fox, Kevin M
Sorry, I was a bit unclear here. I meant the radosgw in particular. I've seen 
multiple OpenStack projects fail to integrate with it.

The most recent example I can think of is Trove can't do database backups to it 
as the namespacing is slightly different in the older radosgw versions. (I 
think this is made more uniform in Jewel, but I haven't tested it). I know 
tempurl's work slightly differently too so may affect services that work with 
them.

I don't think the differences are really intentional, more that there isn't an 
official swift api spec and no cross testing is done because the OpenStack api 
test suite doesn't run against radosgw as its not in the tent.

Thanks,
Kevin

From: Erno Kuvaja [ekuv...@redhat.com]
Sent: Thursday, August 04, 2016 9:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

Kevin,

What do you mean by "Other OpenStack projects don't take it into
account because its not a big tent thing"? I think there is pretty
decent adoption of Ceph across the projects where it would make sense.
Also I doubt none of them would be against 3rd party Ceph gates to
those project if the Ceph community felt that the testing is not
sufficient. We have for example Cinder being brilliant example of
demanding driver providers providing CI for their backends.

Would such demand for 3rd party CI across OpenStack rather than just
Cinder answer your concerns of the testing and how far we are willing
to take that?

- Erno

On Thu, Aug 4, 2016 at 4:57 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> Ok. I'll play devils advocate here and speak to the other side of this, 
> because you raised an interesting issue...
>
> Ceph is outside of the tent. It provides a (mostly) api compatible 
> implementation of the swift api (radosgw), and it is commonly used in 
> OpenStack deployments.
>
> Other OpenStack projects don't take it into account because its not a big 
> tent thing, even though it is very common. Because of some rules about only 
> testing OpenStack things, radosgw is not tested against even though it is so 
> common. This causes odd breakages at times that could easily be prevented, 
> but for procedural things around the Big Tent.
>
> I do think this should be fixed before we advocate single vendor projects 
> exit the big tent after some time. As the testing situation may be made worse.
>
> Thanks,
> Kevin
> 
> From: Thierry Carrez [thie...@openstack.org]
> Sent: Thursday, August 04, 2016 5:59 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> Thomas Goirand wrote:
>> On 08/01/2016 09:39 AM, Thierry Carrez wrote:
>>> But if a project is persistently single-vendor after some time and
>>> nobody seems interested to join it, the technical value of that project
>>> being "in" OpenStack rather than a separate project in the OpenStack
>>> ecosystem of projects is limited. It's limited for OpenStack (why
>>> provide resources to support a project that is obviously only beneficial
>>> to one organization ?), and it's limited to the organization itself (why
>>> go through the OpenStack-specific open processes when you could shortcut
>>> it with internal tools and meetings ? why accept the oversight of the
>>> Technical Committee ?).
>>
>> A project can still be useful for everyone with a single vendor
>> contributing to it, even after a long period of existence. IMO that's
>> not the issue we're trying to solve.
>
> I agree with that -- open source projects can be useful for everyone
> even if only a single vendor contributes to it.
>
> But you seem to imply that the only way an open source project can be
> useful is if it's developed as an OpenStack project under the OpenStack
> Technical Committee governance. I'm not advocating that these projects
> should stop or disappear. I'm just saying that if they are very unlikely
> to grow a more diverse affiliation in the future, they derive little
> value in being developed under the OpenStack Technical Committee
> oversight, and would probably be equally useful if developed outside of
> OpenStack official projects governance. There are plenty of projects
> that are useful to OpenStack that are not developed under the TC
> governance (libvirt, Ceph, OpenvSwitch...)
>
> What is the point for a project to submit themselves to the oversight of
> a multi-organization Technical Committee if they always will be the
> result of the efforts of a single organization ?
>
> --
> Thierry Carrez (ttx)
>
> _

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Ben Swartzlander

On 08/04/2016 11:57 AM, Fox, Kevin M wrote:

Ok. I'll play devils advocate here and speak to the other side of this, because 
you raised an interesting issue...

Ceph is outside of the tent. It provides a (mostly) api compatible 
implementation of the swift api (radosgw), and it is commonly used in OpenStack 
deployments.

Other OpenStack projects don't take it into account because its not a big tent 
thing, even though it is very common. Because of some rules about only testing 
OpenStack things, radosgw is not tested against even though it is so common.


I call BS on this assertion. We test things that outside the tent in the 
upstream gate all the time -- the only requirement is that they be 
released. We won't test against unreleased stuff that's outside the big 
tent and the reason for that should be obvious.



This causes odd breakages at times that could easily be prevented, but for 
procedural things around the Big Tent.


The only way I can see for "odd breakages" to sneak in is on the Ceph 
side, if they aren't testing their changes against OpenStack and they 
introduce a regression, then that's their fault (assuming of course that 
we have good test coverage running against the latest stable release of 
Ceph). It's reasonable to request that we increase our test coverage 
with Ceph if it's not good enough and if we are the ones causing the 
breakages. But their outside status isn't the problem.


-Ben Swartzlander



I do think this should be fixed before we advocate single vendor projects exit 
the big tent after some time. As the testing situation may be made worse.

Thanks,
Kevin

From: Thierry Carrez [thie...@openstack.org]
Sent: Thursday, August 04, 2016 5:59 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

Thomas Goirand wrote:

On 08/01/2016 09:39 AM, Thierry Carrez wrote:

But if a project is persistently single-vendor after some time and
nobody seems interested to join it, the technical value of that project
being "in" OpenStack rather than a separate project in the OpenStack
ecosystem of projects is limited. It's limited for OpenStack (why
provide resources to support a project that is obviously only beneficial
to one organization ?), and it's limited to the organization itself (why
go through the OpenStack-specific open processes when you could shortcut
it with internal tools and meetings ? why accept the oversight of the
Technical Committee ?).


A project can still be useful for everyone with a single vendor
contributing to it, even after a long period of existence. IMO that's
not the issue we're trying to solve.


I agree with that -- open source projects can be useful for everyone
even if only a single vendor contributes to it.

But you seem to imply that the only way an open source project can be
useful is if it's developed as an OpenStack project under the OpenStack
Technical Committee governance. I'm not advocating that these projects
should stop or disappear. I'm just saying that if they are very unlikely
to grow a more diverse affiliation in the future, they derive little
value in being developed under the OpenStack Technical Committee
oversight, and would probably be equally useful if developed outside of
OpenStack official projects governance. There are plenty of projects
that are useful to OpenStack that are not developed under the TC
governance (libvirt, Ceph, OpenvSwitch...)

What is the point for a project to submit themselves to the oversight of
a multi-organization Technical Committee if they always will be the
result of the efforts of a single organization ?

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread John Griffith
On Thu, Aug 4, 2016 at 9:57 AM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> Ok. I'll play devils advocate here and speak to the other side of this,
> because you raised an interesting issue...
>
> Ceph is outside of the tent. It provides a (mostly) api compatible
> implementation of the swift api (radosgw), and it is commonly used in
> OpenStack deployments.
>
> Other OpenStack projects don't take it into account because its not a big
> tent thing, even though it is very common. Because of some rules about only
> testing OpenStack things, radosgw is not tested against even though it is
> so common. This causes odd breakages at times that could easily be
> prevented, but for procedural things around the Big Tent.
>
​I think this statement needs some fact checking.  The reality is that Ceph
is a PERFECT example of a valuable and widely used project in the OpenStack
eco system but doesn't not officially reside in the eco system.  I can
assure you that Cinder and Nova inparticular take into account, almost to
the point of being detrimental to other storage options.

I suspect part of your view stems from issues prior to Ceph being an active
part of CI, which now it is.  The question of testing isn't the same here
IMO.  In the case of Block storage in particular we have all drivers (none
of which but the ref LVM driver being a part of OpenStack governance)
running CI testing.  Granted it's not pretty, but there's nothing keeping
them from implementing CI, running and reporting.  In the case of open
source software based options like Ceph, Gluster, SheepDog etc... those are
all project maintained outside of OpenStack Governance BUT they all have
Infra resources running CI etc.
​


>
> I do think this should be fixed before we advocate single vendor projects
> exit the big tent after some time. As the testing situation may be made
> worse.
>
> Thanks,
> Kevin
> 
> From: Thierry Carrez [thie...@openstack.org]
> Sent: Thursday, August 04, 2016 5:59 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> Thomas Goirand wrote:
> > On 08/01/2016 09:39 AM, Thierry Carrez wrote:
> >> But if a project is persistently single-vendor after some time and
> >> nobody seems interested to join it, the technical value of that project
> >> being "in" OpenStack rather than a separate project in the OpenStack
> >> ecosystem of projects is limited. It's limited for OpenStack (why
> >> provide resources to support a project that is obviously only beneficial
> >> to one organization ?), and it's limited to the organization itself (why
> >> go through the OpenStack-specific open processes when you could shortcut
> >> it with internal tools and meetings ? why accept the oversight of the
> >> Technical Committee ?).
> >
> > A project can still be useful for everyone with a single vendor
> > contributing to it, even after a long period of existence. IMO that's
> > not the issue we're trying to solve.
>
> I agree with that -- open source projects can be useful for everyone
> even if only a single vendor contributes to it.
>
> But you seem to imply that the only way an open source project can be
> useful is if it's developed as an OpenStack project under the OpenStack
> Technical Committee governance. I'm not advocating that these projects
> should stop or disappear. I'm just saying that if they are very unlikely
> to grow a more diverse affiliation in the future, they derive little
> value in being developed under the OpenStack Technical Committee
> oversight, and would probably be equally useful if developed outside of
> OpenStack official projects governance. There are plenty of projects
> that are useful to OpenStack that are not developed under the TC
> governance (libvirt, Ceph, OpenvSwitch...)
>
> What is the point for a project to submit themselves to the oversight of
> a multi-organization Technical Committee if they always will be the
> result of the efforts of a single organization ?
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Erno Kuvaja
On Thu, Aug 4, 2016 at 9:56 AM, Duncan Thomas  wrote:
> On 1 August 2016 at 18:14, Adrian Otto  wrote:
>>
>> I am struggling to understand why we would want to remove projects from
>> our big tent at all, as long as they are being actively developed under the
>> principles of "four opens". It seems to me that working to disqualify such
>> projects sends an alarming signal to our ecosystem. The reason we made the
>> big tent to begin with was to set a tone of inclusion. This whole discussion
>> seems like a step backward. What problem are we trying to solve, exactly?
>
>
> Any project existing in the big tent sets a significant barrier (policy,
> technical, mindshare) of entry to any competing project that might spring
> up. The cost of entry as an individual into a single-vendor project is much
> higher in general than a diverse one (back-channel communications,
> differences in vision, monoculture, commercial pressures, etc), and so
> having a non-diverse project in the big tent reduces the possibilities of a
> better replacement appearing.
>

Actually I couldn't disagree more. Since big tent and stackforge move
under the openstack name space the effect has been exactly the
opposite. Competitors have way less needs to collaborate with each
other to be part of OpenStack as anyone could just kick up their own
project and do it in their way still being part of the
community/ecosystem/what-ever-you-want-to-call-it.

We see projects splitting more when they do not share the core
concepts (which is good thing) but we do not see projects combining
their efforts when they do overlapping things. Maybe we do see this
lack of diversity just growing as long as we don't care about it (tag
here, another there is not going to slow the company behind the
project pushing it to their customers even there was more diverse or
better options, it's still part of OpenStack and it's "ours"). If we
start pushing the projects that are single vendor out of the big tent,
we give more pressure for multiple of those to combine their efforts
rather than continue competing for same thing and if they don't want
to play together I don't see anything wrong to send clear message that
we don't want to share the cost of it.

I personally see the proposed as not limiting the competition to
appear but rather the single-vendor competition might not stick around
when the competing projects would be under a threat to be thrown out.
If someone brings competing project into the ecosystem, 18 months is
also pretty decent time to see if that approach is superior enough (to
attract the diversity) and justify it's existence or if those people
just should try to play with others instead of doing their own thing.

I'm all for the selective inclusion based on meritocracy, not only on
person level, but on project level as well.

- Erno

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread James Bottomley
On Thu, 2016-08-04 at 10:10 +0200, Thierry Carrez wrote:
> Devdatta Kulkarni wrote:
> > As current PTL of one of the projects that has the team:single
> > -vendor tag, I have following thoughts/questions on this issue.
> 
> In preamble I'd like to reiterate that the proposal is not on the 
> table at this stage -- this is just a discussion to see whether it 
> would be a good thing or a bad thing.

I think this is fair enough, plus the idea that the tagging only
triggers review not an automatic eviction is reasonable.  However, I do
have a concern about what you said below.

> > - Is the need for periodically deciding membership in the big tent
> > primarily stemming from the question of managing resources (for the
> > future design summits and cross-project work)?
> 
> No, it's not the primary reason. As I explained elsewhere in the 
> thread, it's more that (from an upstream open source project 
> perspective) OpenStack is not a useful vehicle for open source 
> projects that are and will always be driven by a single vendor. The 
> value we provide (through our governance, principles and infra 
> systems) is in enabling open collaboration between organizations. A 
> project that will clearly always stay single-vendor (for one reason 
> or another) does not get or bring extra technical value by being 
> developed within "OpenStack" (i.e. under the Technical Committee
> oversight).

I don't believe this to be consistent with the OpenStack mission
statement:

to produce the ubiquitous Open Source Cloud Computing platform that 
will meet the needs of public and private clouds regardless of size,
by 
being simple to implement and massively scalable.

OpenStack chooses to implement this mission statement by insisting on
Openness via the four opens and by facilitating a collaborative
environment for every project. I interpret the above to mean any
OpenStack project must be open and must bring technical benefit to
public and private clouds of any size; so I don't think a statement
that even if a project satisfies your openness requirements, the fact
that it must also derive technical benefit from the infrastructure
you've put in place can be supported by any construction of the above
mission statement.

The other thing that really bothers me is that it changes the
assessment of value to OpenStack from being extrinsic (brings technical
benefit to public and private cloud) to being intrinsic (must derive
technical benefit from our infrastructure) and I find non-extrinsic
measures suspect because they can lead to self-perpetuation.

James


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Erno Kuvaja
Kevin,

What do you mean by "Other OpenStack projects don't take it into
account because its not a big tent thing"? I think there is pretty
decent adoption of Ceph across the projects where it would make sense.
Also I doubt none of them would be against 3rd party Ceph gates to
those project if the Ceph community felt that the testing is not
sufficient. We have for example Cinder being brilliant example of
demanding driver providers providing CI for their backends.

Would such demand for 3rd party CI across OpenStack rather than just
Cinder answer your concerns of the testing and how far we are willing
to take that?

- Erno

On Thu, Aug 4, 2016 at 4:57 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> Ok. I'll play devils advocate here and speak to the other side of this, 
> because you raised an interesting issue...
>
> Ceph is outside of the tent. It provides a (mostly) api compatible 
> implementation of the swift api (radosgw), and it is commonly used in 
> OpenStack deployments.
>
> Other OpenStack projects don't take it into account because its not a big 
> tent thing, even though it is very common. Because of some rules about only 
> testing OpenStack things, radosgw is not tested against even though it is so 
> common. This causes odd breakages at times that could easily be prevented, 
> but for procedural things around the Big Tent.
>
> I do think this should be fixed before we advocate single vendor projects 
> exit the big tent after some time. As the testing situation may be made worse.
>
> Thanks,
> Kevin
> 
> From: Thierry Carrez [thie...@openstack.org]
> Sent: Thursday, August 04, 2016 5:59 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> Thomas Goirand wrote:
>> On 08/01/2016 09:39 AM, Thierry Carrez wrote:
>>> But if a project is persistently single-vendor after some time and
>>> nobody seems interested to join it, the technical value of that project
>>> being "in" OpenStack rather than a separate project in the OpenStack
>>> ecosystem of projects is limited. It's limited for OpenStack (why
>>> provide resources to support a project that is obviously only beneficial
>>> to one organization ?), and it's limited to the organization itself (why
>>> go through the OpenStack-specific open processes when you could shortcut
>>> it with internal tools and meetings ? why accept the oversight of the
>>> Technical Committee ?).
>>
>> A project can still be useful for everyone with a single vendor
>> contributing to it, even after a long period of existence. IMO that's
>> not the issue we're trying to solve.
>
> I agree with that -- open source projects can be useful for everyone
> even if only a single vendor contributes to it.
>
> But you seem to imply that the only way an open source project can be
> useful is if it's developed as an OpenStack project under the OpenStack
> Technical Committee governance. I'm not advocating that these projects
> should stop or disappear. I'm just saying that if they are very unlikely
> to grow a more diverse affiliation in the future, they derive little
> value in being developed under the OpenStack Technical Committee
> oversight, and would probably be equally useful if developed outside of
> OpenStack official projects governance. There are plenty of projects
> that are useful to OpenStack that are not developed under the TC
> governance (libvirt, Ceph, OpenvSwitch...)
>
> What is the point for a project to submit themselves to the oversight of
> a multi-organization Technical Committee if they always will be the
> result of the efforts of a single organization ?
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Fox, Kevin M
Ok. I'll play devils advocate here and speak to the other side of this, because 
you raised an interesting issue...

Ceph is outside of the tent. It provides a (mostly) api compatible 
implementation of the swift api (radosgw), and it is commonly used in OpenStack 
deployments.

Other OpenStack projects don't take it into account because its not a big tent 
thing, even though it is very common. Because of some rules about only testing 
OpenStack things, radosgw is not tested against even though it is so common. 
This causes odd breakages at times that could easily be prevented, but for 
procedural things around the Big Tent.

I do think this should be fixed before we advocate single vendor projects exit 
the big tent after some time. As the testing situation may be made worse.

Thanks,
Kevin

From: Thierry Carrez [thie...@openstack.org]
Sent: Thursday, August 04, 2016 5:59 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

Thomas Goirand wrote:
> On 08/01/2016 09:39 AM, Thierry Carrez wrote:
>> But if a project is persistently single-vendor after some time and
>> nobody seems interested to join it, the technical value of that project
>> being "in" OpenStack rather than a separate project in the OpenStack
>> ecosystem of projects is limited. It's limited for OpenStack (why
>> provide resources to support a project that is obviously only beneficial
>> to one organization ?), and it's limited to the organization itself (why
>> go through the OpenStack-specific open processes when you could shortcut
>> it with internal tools and meetings ? why accept the oversight of the
>> Technical Committee ?).
>
> A project can still be useful for everyone with a single vendor
> contributing to it, even after a long period of existence. IMO that's
> not the issue we're trying to solve.

I agree with that -- open source projects can be useful for everyone
even if only a single vendor contributes to it.

But you seem to imply that the only way an open source project can be
useful is if it's developed as an OpenStack project under the OpenStack
Technical Committee governance. I'm not advocating that these projects
should stop or disappear. I'm just saying that if they are very unlikely
to grow a more diverse affiliation in the future, they derive little
value in being developed under the OpenStack Technical Committee
oversight, and would probably be equally useful if developed outside of
OpenStack official projects governance. There are plenty of projects
that are useful to OpenStack that are not developed under the TC
governance (libvirt, Ceph, OpenvSwitch...)

What is the point for a project to submit themselves to the oversight of
a multi-organization Technical Committee if they always will be the
result of the efforts of a single organization ?

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Thierry Carrez
Thomas Goirand wrote:
> On 08/01/2016 09:39 AM, Thierry Carrez wrote:
>> But if a project is persistently single-vendor after some time and
>> nobody seems interested to join it, the technical value of that project
>> being "in" OpenStack rather than a separate project in the OpenStack
>> ecosystem of projects is limited. It's limited for OpenStack (why
>> provide resources to support a project that is obviously only beneficial
>> to one organization ?), and it's limited to the organization itself (why
>> go through the OpenStack-specific open processes when you could shortcut
>> it with internal tools and meetings ? why accept the oversight of the
>> Technical Committee ?).
> 
> A project can still be useful for everyone with a single vendor
> contributing to it, even after a long period of existence. IMO that's
> not the issue we're trying to solve.

I agree with that -- open source projects can be useful for everyone
even if only a single vendor contributes to it.

But you seem to imply that the only way an open source project can be
useful is if it's developed as an OpenStack project under the OpenStack
Technical Committee governance. I'm not advocating that these projects
should stop or disappear. I'm just saying that if they are very unlikely
to grow a more diverse affiliation in the future, they derive little
value in being developed under the OpenStack Technical Committee
oversight, and would probably be equally useful if developed outside of
OpenStack official projects governance. There are plenty of projects
that are useful to OpenStack that are not developed under the TC
governance (libvirt, Ceph, OpenvSwitch...)

What is the point for a project to submit themselves to the oversight of
a multi-organization Technical Committee if they always will be the
result of the efforts of a single organization ?

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Thomas Goirand
On 07/31/2016 05:59 PM, Fox, Kevin M wrote:
> This sounds good to me.
> 
> What about making it iterative but with a delayed start. Something like:
> 
> There is a grace period of 1 year for projects that newly join the big tent. 
> After which, the following criteria will be evaluated to keep a project in 
> the big tent, evaluated at the end of each OpenStack release cycle to keep 
> the project for the next cycle. The project should not have active cores from 
> one company in the amount greater then 45% of the active core membership. If 
> that number is higher, the project is given notice they are under diverse and 
> have 6 months of remaining in the big tent to show they are attempting to 
> increase diversity by shifting the ratio to a more diverse active core 
> membership. The active core membership percentage by the over represented 
> company, called X%, will be shown to be reduced by 25% or reach 45%, so 
> max(X% * (100%-25%), 45%). If the criteria is met, the project can remain in 
> the big tent and a new cycle will begin. (another notification and 6 months 
> if still out of compliance)
> 
> This should allow projects that are, or become under diverse a path towards 
> working on project membership diversity. It gives projects that are very far 
> out of wack a while to fix it. It basically gives projects over represented:
>  * (80%, 100%] -  gets 18 months to fix it
>  * (60%, 80%] - gets 12 months
>  * (45%, 60%] - gets 6 months
> 
> Thoughts? The numbers should be fairly easy to change to make for different 
> amounts of grace period.
> 
> Thanks,
> Kevin

I strongly disagree with this kind of procedure. A project with a single
vendor can still be a very good addition to the big tent. The tagging
which we already have in place is IMO enough.

Also, rating projects by the % of commits from a single vendor wont cut
it: it's very bad metrics. Let me attempt to take an example to explain
my thoughts.

Let's say company Alice does the biggest majority of patches in project
Bob, which makes her company the top committer by far. If Alice leaves
the project (maybe for personal reasons, or because her company assigned
her to something else), then maybe suddenly, we get the diversity
percentages correct, just because she left and her company's
contribution ratio dropped. Does that makes project Bob healthier just
because she left? I don't think it does. And that's not what our ruleset
should enforce. Our rules should push for more contributions, not less. [1]

If we want to make collaboration going better, it's going to be a social
thing. Attempting to add rules will only make things more complicated
for new projects.

Cheers,

Thomas Goirand (zigo)

[1] I'm not sure I made myself clear here, if I was not, let me know and
I'll attempt to write in a better way.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Duncan Thomas
On 1 August 2016 at 18:14, Adrian Otto  wrote:

> I am struggling to understand why we would want to remove projects from
> our big tent at all, as long as they are being actively developed under the
> principles of "four opens". It seems to me that working to disqualify such
> projects sends an alarming signal to our ecosystem. The reason we made the
> big tent to begin with was to set a tone of inclusion. This whole
> discussion seems like a step backward. What problem are we trying to solve,
> exactly?
>

Any project existing in the big tent sets a significant barrier (policy,
technical, mindshare) of entry to any competing project that might spring
up. The cost of entry as an individual into a single-vendor project is much
higher in general than a diverse one (back-channel communications,
differences in vision, monoculture, commercial pressures, etc), and so
having a non-diverse project in the big tent reduces the possibilities of a
better replacement appearing.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Thomas Goirand
On 08/01/2016 09:39 AM, Thierry Carrez wrote:
> But if a project is persistently single-vendor after some time and
> nobody seems interested to join it, the technical value of that project
> being "in" OpenStack rather than a separate project in the OpenStack
> ecosystem of projects is limited. It's limited for OpenStack (why
> provide resources to support a project that is obviously only beneficial
> to one organization ?), and it's limited to the organization itself (why
> go through the OpenStack-specific open processes when you could shortcut
> it with internal tools and meetings ? why accept the oversight of the
> Technical Committee ?).

A project can still be useful for everyone with a single vendor
contributing to it, even after a long period of existence. IMO that's
not the issue we're trying to solve.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-04 Thread Thierry Carrez
Devdatta Kulkarni wrote:
> As current PTL of one of the projects that has the team:single-vendor tag,
> I have following thoughts/questions on this issue.

In preamble I'd like to reiterate that the proposal is not on the table
at this stage -- this is just a discussion to see whether it would be a
good thing or a bad thing.

> - Is the need for periodically deciding membership in the big tent primarily 
> stemming
> from the question of managing resources (for the future design summits and 
> cross-project work)?

No, it's not the primary reason. As I explained elsewhere in the thread,
it's more that (from an upstream open source project perspective)
OpenStack is not a useful vehicle for open source projects that are and
will always be driven by a single vendor. The value we provide (through
our governance, principles and infra systems) is in enabling open
collaboration between organizations. A project that will clearly always
stay single-vendor (for one reason or another) does not get or bring
extra technical value by being developed within "OpenStack" (i.e. under
the Technical Committee oversight).

> If so, have we thought about alternative solutions such, say, using the 
> team:diverse-affiliation
> tag for making such decisions? For instance, we could say that a project will 
> get
> space at the design summit only if it has the team:diverse-affiliation tag? 
> That way, projects
> are incentivized to purse this tag/goal if they want to participate in the 
> design summit.
> Also, adding/removing tag might be simpler than trying to get into big tent 
> again (say, after a project
> has been removed and then gains diverse affiliation afterwards and wants to 
> participate in the
> design summit, would they have to go through big tent application again?).

Actually this is being considered for the Project Teams Gathering
events: we may not provide space for single-vendor projects (since the
value for contributors from one single organization to travel to a
remote location to have a team meeting is limited). Final decision will
be taken based on space availability at the chosen venue.

> - Another issue with using the number of vendors as a metric 
> to decide membership in big tent is that it rules out any project which may 
> be 
> independently started in the open (not by any specific vendor, but by a team 
> of independent contributors),
> and which is following the 4 opens, to be a part of the big tent.

The main issue I now see with this idea is that you REALLY don't want to
flip-flop between in and out based on reaching 89% or 91% on an abstract
metric. Which is why I'd suggest 18 months at single-vendor should only
trigger a *review* by the TC of the affected project. That review would
assess if there is any significant chance that the project grows a
diverse contributor base in the future (and if there is, the project
should stay in).

I expect we'll see two cases in those reviews. On one hand, smallish
projects that struggle to attract contributors or grow diversity, but
are trying and have nothing structural in them discouraging
contributions from other organizations. Those should definitely stay in.
On the other hand, projects that are clearly part of the marketing
strategy of one particular vendor, and the project is not generally as
useful to the rest of the community, and I'd advocate that those should
not stay under TC governance as an official OpenStack project.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-03 Thread Fei Long Wang

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/08/16 21:15, Flavio Percoco wrote:
> On 02/08/16 15:13 +, Hayes, Graham wrote:
>> On 02/08/2016 15:42, Flavio Percoco wrote:
>>> On 01/08/16 10:19 -0400, Sean Dague wrote:
 On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
> Thierry, Ben, Doug,
>
> How can we distinguish between. "Project is doing the right thing, but
> others are not joining" vs "Project is actively trying to keep people
> out"?

 I think at some level, it's not really that different. If we treat them
 as different, everyone will always believe they did all the right
 things, but got no results. 3 cycles should be plenty of time to drop
 single entity contributions below 90%. That means prioritizing bugs /
 patches from outside groups (to drop below 90% on code commits),
 mentoring every outside member that provides feedback (to drop
below 90%
 on reviews), shifting development resources towards mentoring / docs /
 on ramp exercises for others in the community (to drop below 90% on
core
 team).

 Digging out of a single vendor status is hard, and requires making that
 your top priority. If teams aren't interested in putting that ahead of
 development work, that's fine, but that doesn't make it a sustainable
 OpenStack project.
>>>
>>>
>>> ++ to the above! I don't think they are that different either and we
might not
>>> need to differentiate them after all.
>>>
>>> Flavio
>>>
>>
>> I do have one question - how are teams getting out of
>> "team:single-vendor" and towards "team:diverse-affiliation" ?
>>
>> We have tried to get more people involved with Designate using the ways
>> we know how - doing integrations with other projects, pushing designate
>> at conferences, helping DNS Server vendors to add drivers, adding
>> drivers for DNS Servers and service providers ourselves, adding
>> features - the lot.
>>
>> We have a lot of user interest (41% of users were interested in using
>> us), and are quite widely deployed for a non tc-approved-release
>> project (17% - 5% in production). We are actually the most deployed
>> non tc-approved-release project.
>>
>> We still have 81% of the reviews done by 2 companies, and 83% by 3
>> companies.
>>
>> I know our project is not "cool", and DNS is probably one of the most
>> boring topics, but I honestly believe that it has a place in the
>> majority of OpenStack clouds - both public and private. We are a small
>> team of people dedicated to making Designate the best we can, but are
>> still one company deciding to drop OpenStack / DNS development from
>> joining the single-vendor party.
>>
>> We are definitely interested in putting community development ahead of
>> development work - but what that actual work is seems to difficult to
>> nail down. I do feel sometimes that I am flailing in the dark trying to
>> improve this.
>>
>> If projects could share how that got out of single-vendor or into
>> diverse-affiliation this could really help teams progress in the
>> community, and avoid being removed.
>>
>> Making grand statements about "work harder on community" without any
>> guidance about what we need to work on do not help the community.
>
> Zaqar has had the same issue ever since the project was created. The
team has
> been actively mentoring folks from the Outreachy program and Google
Summer of
> code whenever possible.
>
> Folks from other teams have also contributed to the project but
sometimes these
> folks were also part of the same company as the majority of Zaqar's
> contributors, which doesn't help much with this.
>
> It's not until recently that Zaqar has increased its diversity but I
believe
> it's in the edge and it's also related to the amount (or lack there of) of
> adoption it's gotten.
>
As for the adoption, IMHO, it's really depends on the service type and I
think which is one of the main reasons of lacking adoption for some
projects. For example,  you shouldn't expect every cloud deploying a
messaging service, like Zaqar. But every cloud based on OpenStack will
have Nova for sure. So it brings an interesting point,  and I think it's
related to an spec Equal Integration Chances for all Projects
 In that spec, seems(may I read it
by a wrong way) we got an agreement that not all the projects are equal.
However, we're always applying the same rules for every projects. That's
fine, actually my point is for those projects which are not *equal* as
Nova, Neutron or Cinder, it would be nice if we could give them more
time, more space, more support to help them grow. I would like to say
that again, OpenStack is a cloud ecosystem, the goal is not creating a
better VM-creator. Though it's not good if a project is single-vendor,
it's worse if we lost a useful service on the list, because we(at least
me) want to see a reasonable diversity for the service coverage.

> To me, one of the most important items is 

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-03 Thread Devdatta Kulkarni
Hi,

As current PTL of one of the projects that has the team:single-vendor tag,
I have following thoughts/questions on this issue.

- Is the need for periodically deciding membership in the big tent primarily 
stemming
from the question of managing resources (for the future design summits and 
cross-project work)?
If so, have we thought about alternative solutions such, say, using the 
team:diverse-affiliation
tag for making such decisions? For instance, we could say that a project will 
get
space at the design summit only if it has the team:diverse-affiliation tag? 
That way, projects
are incentivized to purse this tag/goal if they want to participate in the 
design summit.
Also, adding/removing tag might be simpler than trying to get into big tent 
again (say, after a project
has been removed and then gains diverse affiliation afterwards and wants to 
participate in the
design summit, would they have to go through big tent application again?).

- Another issue with using the number of vendors as a metric 
to decide membership in big tent is that it rules out any project which may be 
independently started in the open (not by any specific vendor, but by a team of 
independent contributors),
and which is following the 4 opens, to be a part of the big tent.

- About diversity -- as Flavio has suggested on this thread, participating in 
Outreachy is a good option.
We have done it in Solum. However, that does not necessarily help with 
obtaining the diverse-affiliation
tag as defined currently (since Outreachy participants are students and not 
necessarily affiliated with
any vendor).

Regards,
Devdatta



From: Amrith Kumar <amr...@tesora.com>
Sent: Wednesday, August 3, 2016 10:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

To Steven's specific question:

> If PTLs can weigh in on this thread and commit to participation in such a
> cross-project subgroup, I'd be happy to lead it.

I would like to participate and help get this kind of a group going.

-amrith


> -Original Message-
> From: Steven Dake (stdake) [mailto:std...@cisco.com]
> Sent: Tuesday, August 02, 2016 11:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> Responses inline:
>
> On 8/2/16, 8:13 AM, "Hayes, Graham" <graham.ha...@hpe.com> wrote:
>
> >On 02/08/2016 15:42, Flavio Percoco wrote:
> >> On 01/08/16 10:19 -0400, Sean Dague wrote:
> >>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
> >>>> Thierry, Ben, Doug,
> >>>>
> >>>> How can we distinguish between. "Project is doing the right thing,
> but
> >>>> others are not joining" vs "Project is actively trying to keep people
> >>>> out"?
> >>>
> >>> I think at some level, it's not really that different. If we treat
> them
> >>> as different, everyone will always believe they did all the right
> >>> things, but got no results. 3 cycles should be plenty of time to drop
> >>> single entity contributions below 90%. That means prioritizing bugs /
> >>> patches from outside groups (to drop below 90% on code commits),
> >>> mentoring every outside member that provides feedback (to drop below
> >>>90%
> >>> on reviews), shifting development resources towards mentoring / docs /
> >>> on ramp exercises for others in the community (to drop below 90% on
> >>>core
> >>> team).
> >>>
> >>> Digging out of a single vendor status is hard, and requires making
> that
> >>> your top priority. If teams aren't interested in putting that ahead of
> >>> development work, that's fine, but that doesn't make it a sustainable
> >>> OpenStack project.
> >>
> >>
> >> ++ to the above! I don't think they are that different either and we
> >>might not
> >> need to differentiate them after all.
> >>
> >> Flavio
> >>
> >
> >I do have one question - how are teams getting out of
> >"team:single-vendor" and towards "team:diverse-affiliation" ?
> >
> >We have tried to get more people involved with Designate using the ways
> >we know how - doing integrations with other projects, pushing designate
> >at conferences, helping DNS Server vendors to add drivers, adding
> >drivers for DNS Servers and service providers ourselves, adding
> >features - the lot.
> >
> >We have a lot of user interest (41% of u

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-03 Thread Amrith Kumar
To Steven's specific question:

> If PTLs can weigh in on this thread and commit to participation in such a
> cross-project subgroup, I'd be happy to lead it.

I would like to participate and help get this kind of a group going.

-amrith


> -Original Message-
> From: Steven Dake (stdake) [mailto:std...@cisco.com]
> Sent: Tuesday, August 02, 2016 11:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
> 
> Responses inline:
> 
> On 8/2/16, 8:13 AM, "Hayes, Graham" <graham.ha...@hpe.com> wrote:
> 
> >On 02/08/2016 15:42, Flavio Percoco wrote:
> >> On 01/08/16 10:19 -0400, Sean Dague wrote:
> >>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
> >>>> Thierry, Ben, Doug,
> >>>>
> >>>> How can we distinguish between. "Project is doing the right thing,
> but
> >>>> others are not joining" vs "Project is actively trying to keep people
> >>>> out"?
> >>>
> >>> I think at some level, it's not really that different. If we treat
> them
> >>> as different, everyone will always believe they did all the right
> >>> things, but got no results. 3 cycles should be plenty of time to drop
> >>> single entity contributions below 90%. That means prioritizing bugs /
> >>> patches from outside groups (to drop below 90% on code commits),
> >>> mentoring every outside member that provides feedback (to drop below
> >>>90%
> >>> on reviews), shifting development resources towards mentoring / docs /
> >>> on ramp exercises for others in the community (to drop below 90% on
> >>>core
> >>> team).
> >>>
> >>> Digging out of a single vendor status is hard, and requires making
> that
> >>> your top priority. If teams aren't interested in putting that ahead of
> >>> development work, that's fine, but that doesn't make it a sustainable
> >>> OpenStack project.
> >>
> >>
> >> ++ to the above! I don't think they are that different either and we
> >>might not
> >> need to differentiate them after all.
> >>
> >> Flavio
> >>
> >
> >I do have one question - how are teams getting out of
> >"team:single-vendor" and towards "team:diverse-affiliation" ?
> >
> >We have tried to get more people involved with Designate using the ways
> >we know how - doing integrations with other projects, pushing designate
> >at conferences, helping DNS Server vendors to add drivers, adding
> >drivers for DNS Servers and service providers ourselves, adding
> >features - the lot.
> >
> >We have a lot of user interest (41% of users were interested in using
> >us), and are quite widely deployed for a non tc-approved-release
> >project (17% - 5% in production). We are actually the most deployed
> >non tc-approved-release project.
> >
> >We still have 81% of the reviews done by 2 companies, and 83% by 3
> >companies.
> 
> By the objective criteria of team:single-vendor Designate isn't a single
> vendor project.  By the objective criteria of team:diverse-affiliation
> your not a diversely affiliated project either.  This is why I had
> suggested we need a third tag which accurately represents where Designate
> is in its community building journey.
> >
> >I know our project is not "cool", and DNS is probably one of the most
> >boring topics, but I honestly believe that it has a place in the
> >majority of OpenStack clouds - both public and private. We are a small
> >team of people dedicated to making Designate the best we can, but are
> >still one company deciding to drop OpenStack / DNS development from
> >joining the single-vendor party.
> 
> Agree Designate is important to OpenStack.  But IMO it is not a single
> vendor project as defined by the criteria given the objective statistics
> you mentioned above.
> 
> >
> >We are definitely interested in putting community development ahead of
> >development work - but what that actual work is seems to difficult to
> >nail down. I do feel sometimes that I am flailing in the dark trying to
> >improve this.
> 
> Fantastic its a high-prioiirty goal.  Sad to hear your struggling but
> struggling is part of the activity.
> >
> >If projects could share how that got out of single-vendor or into
> >diverse-affiliation this could really help teams progress in the
> >communit

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-03 Thread Flavio Percoco

On 02/08/16 15:13 +, Hayes, Graham wrote:

On 02/08/2016 15:42, Flavio Percoco wrote:

On 01/08/16 10:19 -0400, Sean Dague wrote:

On 08/01/2016 09:58 AM, Davanum Srinivas wrote:

Thierry, Ben, Doug,

How can we distinguish between. "Project is doing the right thing, but
others are not joining" vs "Project is actively trying to keep people
out"?


I think at some level, it's not really that different. If we treat them
as different, everyone will always believe they did all the right
things, but got no results. 3 cycles should be plenty of time to drop
single entity contributions below 90%. That means prioritizing bugs /
patches from outside groups (to drop below 90% on code commits),
mentoring every outside member that provides feedback (to drop below 90%
on reviews), shifting development resources towards mentoring / docs /
on ramp exercises for others in the community (to drop below 90% on core
team).

Digging out of a single vendor status is hard, and requires making that
your top priority. If teams aren't interested in putting that ahead of
development work, that's fine, but that doesn't make it a sustainable
OpenStack project.



++ to the above! I don't think they are that different either and we might not
need to differentiate them after all.

Flavio



I do have one question - how are teams getting out of
"team:single-vendor" and towards "team:diverse-affiliation" ?

We have tried to get more people involved with Designate using the ways
we know how - doing integrations with other projects, pushing designate
at conferences, helping DNS Server vendors to add drivers, adding
drivers for DNS Servers and service providers ourselves, adding
features - the lot.

We have a lot of user interest (41% of users were interested in using
us), and are quite widely deployed for a non tc-approved-release
project (17% - 5% in production). We are actually the most deployed
non tc-approved-release project.

We still have 81% of the reviews done by 2 companies, and 83% by 3
companies.

I know our project is not "cool", and DNS is probably one of the most
boring topics, but I honestly believe that it has a place in the
majority of OpenStack clouds - both public and private. We are a small
team of people dedicated to making Designate the best we can, but are
still one company deciding to drop OpenStack / DNS development from
joining the single-vendor party.

We are definitely interested in putting community development ahead of
development work - but what that actual work is seems to difficult to
nail down. I do feel sometimes that I am flailing in the dark trying to
improve this.

If projects could share how that got out of single-vendor or into
diverse-affiliation this could really help teams progress in the
community, and avoid being removed.

Making grand statements about "work harder on community" without any
guidance about what we need to work on do not help the community.


Zaqar has had the same issue ever since the project was created. The team has
been actively mentoring folks from the Outreachy program and Google Summer of
code whenever possible.

Folks from other teams have also contributed to the project but sometimes these
folks were also part of the same company as the majority of Zaqar's
contributors, which doesn't help much with this.

It's not until recently that Zaqar has increased its diversity but I believe
it's in the edge and it's also related to the amount (or lack there of) of
adoption it's gotten.

To me, one of the most important items is engaging with mentees from other
programs. I see this also as a way to give back to the communities and the rest
of the world.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Tim Bell

> On 02 Aug 2016, at 17:13, Hayes, Graham  wrote:
> 
> On 02/08/2016 15:42, Flavio Percoco wrote:
>> On 01/08/16 10:19 -0400, Sean Dague wrote:
>>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
 Thierry, Ben, Doug,
 
 How can we distinguish between. "Project is doing the right thing, but
 others are not joining" vs "Project is actively trying to keep people
 out"?
>>> 
>>> I think at some level, it's not really that different. If we treat them
>>> as different, everyone will always believe they did all the right
>>> things, but got no results. 3 cycles should be plenty of time to drop
>>> single entity contributions below 90%. That means prioritizing bugs /
>>> patches from outside groups (to drop below 90% on code commits),
>>> mentoring every outside member that provides feedback (to drop below 90%
>>> on reviews), shifting development resources towards mentoring / docs /
>>> on ramp exercises for others in the community (to drop below 90% on core
>>> team).
>>> 
>>> Digging out of a single vendor status is hard, and requires making that
>>> your top priority. If teams aren't interested in putting that ahead of
>>> development work, that's fine, but that doesn't make it a sustainable
>>> OpenStack project.
>> 
>> 
>> ++ to the above! I don't think they are that different either and we might 
>> not
>> need to differentiate them after all.
>> 
>> Flavio
>> 
> 
> I do have one question - how are teams getting out of
> "team:single-vendor" and towards "team:diverse-affiliation" ?
> 
> We have tried to get more people involved with Designate using the ways
> we know how - doing integrations with other projects, pushing designate
> at conferences, helping DNS Server vendors to add drivers, adding
> drivers for DNS Servers and service providers ourselves, adding
> features - the lot.
> 
> We have a lot of user interest (41% of users were interested in using
> us), and are quite widely deployed for a non tc-approved-release
> project (17% - 5% in production). We are actually the most deployed
> non tc-approved-release project.
> 
> We still have 81% of the reviews done by 2 companies, and 83% by 3
> companies.
> 
> I know our project is not "cool", and DNS is probably one of the most
> boring topics, but I honestly believe that it has a place in the
> majority of OpenStack clouds - both public and private. We are a small
> team of people dedicated to making Designate the best we can, but are
> still one company deciding to drop OpenStack / DNS development from
> joining the single-vendor party.
> 
> We are definitely interested in putting community development ahead of
> development work - but what that actual work is seems to difficult to
> nail down. I do feel sometimes that I am flailing in the dark trying to
> improve this.
> 
> If projects could share how that got out of single-vendor or into 
> diverse-affiliation this could really help teams progress in the
> community, and avoid being removed.
> 
> Making grand statements about "work harder on community" without any
> guidance about what we need to work on do not help the community.
> 
> - Graham
> 
> 

Interesting thread… it raises some questions for me

- Some projects in the big tent are inter-related. For example, if we identify 
a need for a project in our production cloud, we contribute a puppet module 
upstream into the openstack-puppet project. If the project is then evicted, 
does this mean that the puppet module would also be removed from the puppet 
openstack project ? Documentation repositories ? 

- Operators considering including a project in their cloud portfolio look at 
various criteria in places like the project navigator. If a project does not 
have diversity, there is a risk that it would not remain in the big tent after 
an 18 month review of diversity. An operator may therefore delay their testing 
and production deployment of that project which makes it more difficult to 
achieve the diversity given lack of adoption.

I think there is a difference between projects which are meeting a specific set 
of needs with the user community but are not needing major support and one 
which is not meeting the 4 opens. We’ve really appreciated projects which solve 
a need for us such as EC2 API and RDO which have been open but also had 
significant support from a vendor. They could have improved their diversity by 
submitting less commits to get the percentages better...

Tim

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Hayes, Graham
On 02/08/2016 16:48, Steven Dake (stdake) wrote:
> Responses inline:
>
> On 8/2/16, 8:13 AM, "Hayes, Graham"  wrote:
>
>> On 02/08/2016 15:42, Flavio Percoco wrote:
>>> On 01/08/16 10:19 -0400, Sean Dague wrote:
 On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
> Thierry, Ben, Doug,
>
> How can we distinguish between. "Project is doing the right thing, but
> others are not joining" vs "Project is actively trying to keep people
> out"?

 I think at some level, it's not really that different. If we treat them
 as different, everyone will always believe they did all the right
 things, but got no results. 3 cycles should be plenty of time to drop
 single entity contributions below 90%. That means prioritizing bugs /
 patches from outside groups (to drop below 90% on code commits),
 mentoring every outside member that provides feedback (to drop below
 90%
 on reviews), shifting development resources towards mentoring / docs /
 on ramp exercises for others in the community (to drop below 90% on
 core
 team).

 Digging out of a single vendor status is hard, and requires making that
 your top priority. If teams aren't interested in putting that ahead of
 development work, that's fine, but that doesn't make it a sustainable
 OpenStack project.
>>>
>>>
>>> ++ to the above! I don't think they are that different either and we
>>> might not
>>> need to differentiate them after all.
>>>
>>> Flavio
>>>
>>
>> I do have one question - how are teams getting out of
>> "team:single-vendor" and towards "team:diverse-affiliation" ?
>>
>> We have tried to get more people involved with Designate using the ways
>> we know how - doing integrations with other projects, pushing designate
>> at conferences, helping DNS Server vendors to add drivers, adding
>> drivers for DNS Servers and service providers ourselves, adding
>> features - the lot.
>>
>> We have a lot of user interest (41% of users were interested in using
>> us), and are quite widely deployed for a non tc-approved-release
>> project (17% - 5% in production). We are actually the most deployed
>> non tc-approved-release project.
>>
>> We still have 81% of the reviews done by 2 companies, and 83% by 3
>> companies.
>
> By the objective criteria of team:single-vendor Designate isn't a single
> vendor project.  By the objective criteria of team:diverse-affiliation
> your not a diversely affiliated project either.  This is why I had
> suggested we need a third tag which accurately represents where Designate
> is in its community building journey.
>>
>> I know our project is not "cool", and DNS is probably one of the most
>> boring topics, but I honestly believe that it has a place in the
>> majority of OpenStack clouds - both public and private. We are a small
>> team of people dedicated to making Designate the best we can, but are
>> still one company deciding to drop OpenStack / DNS development from
>> joining the single-vendor party.
>
> Agree Designate is important to OpenStack.  But IMO it is not a single
> vendor project as defined by the criteria given the objective statistics
> you mentioned above.

My point is that we are close to being single vendor - it is a real
possibility over then next few months, if a big contributor was to
leave the project, which may happen.

The obvious solution to avoid this is to increase participation - which
is what we are struggling with.

>>
>> We are definitely interested in putting community development ahead of
>> development work - but what that actual work is seems to difficult to
>> nail down. I do feel sometimes that I am flailing in the dark trying to
>> improve this.
>
> Fantastic its a high-prioiirty goal.  Sad to hear your struggling but
> struggling is part of the activity.
>>
>> If projects could share how that got out of single-vendor or into
>> diverse-affiliation this could really help teams progress in the
>> community, and avoid being removed.
>
> You bring up a fantastic point here - and that is that teams need to share
> techniques for becoming multi-vendor and some day diversely affiliated.  I
> am a super busy atm, or I would volunteer to lead a cross-project effort
> with PTLs to coordinate community building from our shared knowledge pool
> of expert Open Source contributors in the wider OpenStack community.
>
> That said, I am passing the baton for Kolla PTL at the conclusion of
> Newton (assuming the leadership pipeline I've built for Kolla wants to run
> for Kolla PTL), and would be pleased to lead a cross project effort in
> Occata on moving from single-vendor to multi-vendor and beyond if there is
> enough PTL interest.  I take mentorship seriously and the various single
> vendor (and others) PTL's won't be disappointed in such an effort.
>
>>
>> Making grand statements about "work harder on community" without any
>> guidance about what we need to work on do not help the community.
>
> Agree - 

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Steven Dake (stdake)
Responses inline:

On 8/2/16, 8:13 AM, "Hayes, Graham"  wrote:

>On 02/08/2016 15:42, Flavio Percoco wrote:
>> On 01/08/16 10:19 -0400, Sean Dague wrote:
>>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
 Thierry, Ben, Doug,

 How can we distinguish between. "Project is doing the right thing, but
 others are not joining" vs "Project is actively trying to keep people
 out"?
>>>
>>> I think at some level, it's not really that different. If we treat them
>>> as different, everyone will always believe they did all the right
>>> things, but got no results. 3 cycles should be plenty of time to drop
>>> single entity contributions below 90%. That means prioritizing bugs /
>>> patches from outside groups (to drop below 90% on code commits),
>>> mentoring every outside member that provides feedback (to drop below
>>>90%
>>> on reviews), shifting development resources towards mentoring / docs /
>>> on ramp exercises for others in the community (to drop below 90% on
>>>core
>>> team).
>>>
>>> Digging out of a single vendor status is hard, and requires making that
>>> your top priority. If teams aren't interested in putting that ahead of
>>> development work, that's fine, but that doesn't make it a sustainable
>>> OpenStack project.
>>
>>
>> ++ to the above! I don't think they are that different either and we
>>might not
>> need to differentiate them after all.
>>
>> Flavio
>>
>
>I do have one question - how are teams getting out of
>"team:single-vendor" and towards "team:diverse-affiliation" ?
>
>We have tried to get more people involved with Designate using the ways
>we know how - doing integrations with other projects, pushing designate
>at conferences, helping DNS Server vendors to add drivers, adding
>drivers for DNS Servers and service providers ourselves, adding
>features - the lot.
>
>We have a lot of user interest (41% of users were interested in using
>us), and are quite widely deployed for a non tc-approved-release
>project (17% - 5% in production). We are actually the most deployed
>non tc-approved-release project.
>
>We still have 81% of the reviews done by 2 companies, and 83% by 3
>companies.

By the objective criteria of team:single-vendor Designate isn't a single
vendor project.  By the objective criteria of team:diverse-affiliation
your not a diversely affiliated project either.  This is why I had
suggested we need a third tag which accurately represents where Designate
is in its community building journey.
>
>I know our project is not "cool", and DNS is probably one of the most
>boring topics, but I honestly believe that it has a place in the
>majority of OpenStack clouds - both public and private. We are a small
>team of people dedicated to making Designate the best we can, but are
>still one company deciding to drop OpenStack / DNS development from
>joining the single-vendor party.

Agree Designate is important to OpenStack.  But IMO it is not a single
vendor project as defined by the criteria given the objective statistics
you mentioned above.

>
>We are definitely interested in putting community development ahead of
>development work - but what that actual work is seems to difficult to
>nail down. I do feel sometimes that I am flailing in the dark trying to
>improve this.

Fantastic its a high-prioiirty goal.  Sad to hear your struggling but
struggling is part of the activity.
>
>If projects could share how that got out of single-vendor or into
>diverse-affiliation this could really help teams progress in the
>community, and avoid being removed.

You bring up a fantastic point here - and that is that teams need to share
techniques for becoming multi-vendor and some day diversely affiliated.  I
am a super busy atm, or I would volunteer to lead a cross-project effort
with PTLs to coordinate community building from our shared knowledge pool
of expert Open Source contributors in the wider OpenStack community.

That said, I am passing the baton for Kolla PTL at the conclusion of
Newton (assuming the leadership pipeline I've built for Kolla wants to run
for Kolla PTL), and would be pleased to lead a cross project effort in
Occata on moving from single-vendor to multi-vendor and beyond if there is
enough PTL interest.  I take mentorship seriously and the various single
vendor (and others) PTL's won't be disappointed in such an effort.

>
>Making grand statements about "work harder on community" without any
>guidance about what we need to work on do not help the community.

Agree - lets fix that.  Unfortunately it can't be fixed in an email thread
- it requires a cross-project team based approach with atleast 6 months of
activity.

If PTLs can weigh in on this thread and commit to participation in such a
cross-project subgroup, I'd be happy to lead it.

Regards
-steve


>
>- Graham
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Hayes, Graham
On 02/08/2016 15:42, Flavio Percoco wrote:
> On 01/08/16 10:19 -0400, Sean Dague wrote:
>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
>>> Thierry, Ben, Doug,
>>>
>>> How can we distinguish between. "Project is doing the right thing, but
>>> others are not joining" vs "Project is actively trying to keep people
>>> out"?
>>
>> I think at some level, it's not really that different. If we treat them
>> as different, everyone will always believe they did all the right
>> things, but got no results. 3 cycles should be plenty of time to drop
>> single entity contributions below 90%. That means prioritizing bugs /
>> patches from outside groups (to drop below 90% on code commits),
>> mentoring every outside member that provides feedback (to drop below 90%
>> on reviews), shifting development resources towards mentoring / docs /
>> on ramp exercises for others in the community (to drop below 90% on core
>> team).
>>
>> Digging out of a single vendor status is hard, and requires making that
>> your top priority. If teams aren't interested in putting that ahead of
>> development work, that's fine, but that doesn't make it a sustainable
>> OpenStack project.
>
>
> ++ to the above! I don't think they are that different either and we might not
> need to differentiate them after all.
>
> Flavio
>

I do have one question - how are teams getting out of
"team:single-vendor" and towards "team:diverse-affiliation" ?

We have tried to get more people involved with Designate using the ways
we know how - doing integrations with other projects, pushing designate
at conferences, helping DNS Server vendors to add drivers, adding
drivers for DNS Servers and service providers ourselves, adding
features - the lot.

We have a lot of user interest (41% of users were interested in using
us), and are quite widely deployed for a non tc-approved-release
project (17% - 5% in production). We are actually the most deployed
non tc-approved-release project.

We still have 81% of the reviews done by 2 companies, and 83% by 3
companies.

I know our project is not "cool", and DNS is probably one of the most
boring topics, but I honestly believe that it has a place in the
majority of OpenStack clouds - both public and private. We are a small
team of people dedicated to making Designate the best we can, but are
still one company deciding to drop OpenStack / DNS development from
joining the single-vendor party.

We are definitely interested in putting community development ahead of
development work - but what that actual work is seems to difficult to
nail down. I do feel sometimes that I am flailing in the dark trying to
improve this.

If projects could share how that got out of single-vendor or into 
diverse-affiliation this could really help teams progress in the
community, and avoid being removed.

Making grand statements about "work harder on community" without any
guidance about what we need to work on do not help the community.

- Graham


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Steven Dake (stdake)


On 8/2/16, 7:17 AM, "Ed Leafe"  wrote:

>On Aug 2, 2016, at 8:50 AM, Steven Dake (stdake)  wrote:
>
>> For example tripleo is single-vendor, but is doing all the right things
>>to
>> dig out of single vendor by doing actual community building.  They
>>aren't
>> just trying, but are trying *very* hard with their activities.  They
>>have
>> the right intent but how to measure intent objectively?  That would be
>>my
>> major concern.
>
>This is exactly the sort of reason why an automatic expulsion is not
>being proposed, but rather a review by humans.
>
>-- Ed Leafe
>
Ed,

Concern answered.  Thanks!

-steve

>
>
>
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Flavio Percoco

On 02/08/16 09:17 -0500, Ed Leafe wrote:

On Aug 2, 2016, at 8:50 AM, Steven Dake (stdake)  wrote:


For example tripleo is single-vendor, but is doing all the right things to
dig out of single vendor by doing actual community building.  They aren't
just trying, but are trying *very* hard with their activities.  They have
the right intent but how to measure intent objectively?  That would be my
major concern.


This is exactly the sort of reason why an automatic expulsion is not being 
proposed, but rather a review by humans.


Also the reason why neither the single-vendor or the diverse-affiliation tags
are applied automatically.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Flavio Percoco

On 01/08/16 10:28 -0400, Davanum Srinivas wrote:

Sean,

So we will programatically test the metrics (if we are not doing that
already) to apply/remove "team:single-vendor" tag:

https://governance.openstack.org/reference/tags/team_single-vendor.html

And trigger exit when the tag is present for more than 3 cycles in a
row (say as of release date?)


We update these tags frequently enough and yes, I guess it would be possible to
programmatically check for how long a project has had the single-vendor tag.

Flavio


Thanks,
-- Dims

On Mon, Aug 1, 2016 at 10:19 AM, Sean Dague  wrote:

On 08/01/2016 09:58 AM, Davanum Srinivas wrote:

Thierry, Ben, Doug,

How can we distinguish between. "Project is doing the right thing, but
others are not joining" vs "Project is actively trying to keep people
out"?


I think at some level, it's not really that different. If we treat them
as different, everyone will always believe they did all the right
things, but got no results. 3 cycles should be plenty of time to drop
single entity contributions below 90%. That means prioritizing bugs /
patches from outside groups (to drop below 90% on code commits),
mentoring every outside member that provides feedback (to drop below 90%
on reviews), shifting development resources towards mentoring / docs /
on ramp exercises for others in the community (to drop below 90% on core
team).

Digging out of a single vendor status is hard, and requires making that
your top priority. If teams aren't interested in putting that ahead of
development work, that's fine, but that doesn't make it a sustainable
OpenStack project.

-Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Flavio Percoco

On 01/08/16 10:19 -0400, Sean Dague wrote:

On 08/01/2016 09:58 AM, Davanum Srinivas wrote:

Thierry, Ben, Doug,

How can we distinguish between. "Project is doing the right thing, but
others are not joining" vs "Project is actively trying to keep people
out"?


I think at some level, it's not really that different. If we treat them
as different, everyone will always believe they did all the right
things, but got no results. 3 cycles should be plenty of time to drop
single entity contributions below 90%. That means prioritizing bugs /
patches from outside groups (to drop below 90% on code commits),
mentoring every outside member that provides feedback (to drop below 90%
on reviews), shifting development resources towards mentoring / docs /
on ramp exercises for others in the community (to drop below 90% on core
team).

Digging out of a single vendor status is hard, and requires making that
your top priority. If teams aren't interested in putting that ahead of
development work, that's fine, but that doesn't make it a sustainable
OpenStack project.



++ to the above! I don't think they are that different either and we might not
need to differentiate them after all.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Ed Leafe
On Aug 2, 2016, at 8:50 AM, Steven Dake (stdake)  wrote:

> For example tripleo is single-vendor, but is doing all the right things to
> dig out of single vendor by doing actual community building.  They aren't
> just trying, but are trying *very* hard with their activities.  They have
> the right intent but how to measure intent objectively?  That would be my
> major concern.

This is exactly the sort of reason why an automatic expulsion is not being 
proposed, but rather a review by humans. 

-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Steven Dake (stdake)


On 8/1/16, 8:38 AM, "Doug Hellmann"  wrote:

>Excerpts from Adrian Otto's message of 2016-08-01 15:14:48 +:
>> I am struggling to understand why we would want to remove projects from
>>our big tent at all, as long as they are being actively developed under
>>the principles of "four opens". It seems to me that working to
>>disqualify such projects sends an alarming signal to our ecosystem. The
>>reason we made the big tent to begin with was to set a tone of
>>inclusion. This whole discussion seems like a step backward. What
>>problem are we trying to solve, exactly?
>> 
>> If we want to have tags to signal team diversity, that's fine. We do
>>that now. But setting arbitrary requirements for big tent inclusion
>>based on who participates definitely sounds like a mistake.
>
>Membership in the big tent comes with benefits that have a real
>cost born by the rest of the community. Space at PTG and summit
>forum events is probably the one that's easiest to quantify and to
>point to as something limited that we want to use as productively
>as possible. If 90% of the work of a project is being done by a
>single company or organization (our current definition for
>single-vendor), and that doesn't change after 18 months, then I
>would take that as a signal that the community isn't interested
>enough in the project to bear the associated costs.
>
>I'm interested in hearing other reasons that we should keep these
>sorts of projects, though. I'm not yet ready to propose the change
>to the policy myself.

Doug,

As a community, we need to carefully consider this action.  The costs to
OpenStack are high for single vendor projects but they do add value if
they behave with community in mind.  I don't think removal from Big Tent
is all that big of a deal as long as the projects can still participate in
the openstack namespace and use gerrit/ci and still be part of OpenStack
as you have previously stated.  My biggest concern is some projects are
really trying hard to increase their diversity while others are not trying
so much.  Unfortunately measuring intent objectively is difficult.  I
severely dislike exceptions, but perhaps projects could apply for
exceptions to this policy change if they are actively digging out of
single vendor by their activities.  Forgive me for singling out a single
project, but deployment is where I've spent the last 3 years of my life
and have an intimate understanding of what is happening in these
communities.

For example tripleo is single-vendor, but is doing all the right things to
dig out of single vendor by doing actual community building.  They aren't
just trying, but are trying *very* hard with their activities.  They have
the right intent but how to measure intent objectively?  That would be my
major concern.

There are more single vendor projects then non-single-vendor projects (the
last time I looked which was several months ago) covering many areas, so
tripleo is just one example of many that may be doing the right things to
build more diverse affiliations.

I don't have any insight into the community building going on in various
communities outside of deployment - perhaps some of those teams PTLs could
weigh in on this thread?

All that said the proposal for 18 months is super generous; Nearly any
project can dig out of single vendor in a 18 month window if they
prioritize it.  It would be better for these projects in the long run to
prioritize moving to more diversity for a whole slew of reasons.  In my 20
years of training, team affiliation diversity is _more_ important than
starting from an empty repository and is a best practice.

To fix the problem, perhaps another tag is needed - something between
single-vendor and diverse-affilliation (spitball -
single-vendor-with-diverse-affiliation.  Single-vendor would have an 18
month window associated with it, while the new tag would guarantee big
tent as long as the objective 90%  percentages were maintained.  The only
problem there is that could put OpenStack back on an
incubation/integration track which from my experience with founding Heat
was a serious hurdle for OpenStack in general and Ceilometer and Heat
specifically.

Regards,
-steve
>
>Doug
>
>> 
>> --
>> Adrian
>> 
>> > On Aug 1, 2016, at 5:11 AM, Sean Dague  wrote:
>> > 
>> >> On 07/31/2016 02:29 PM, Doug Hellmann wrote:
>> >> Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28
>>+:
>> >>> Kevin,
>> >>> 
>> >>> Just assessing your numbers, the team:diverse-affiliation tag
>>covers what
>> >>> is required to maintain that tag.  It covers more then core
>>reviewers -
>> >>> also covers commits and reviews.
>> >>> 
>> >>> See:
>> >>> 
>>https://github.com/openstack/governance/blob/master/reference/tags/team_d
>>iv
>> >>> erse-affiliation.rst
>> >>> 
>> >>> 
>> >>> I can tell you from founding 3 projects with the
>>team:diverse-affiliation
>> >>> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high
>>bar 

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Doug Hellmann
Excerpts from Chris Dent's message of 2016-08-02 11:16:29 +0100:
> On Mon, 1 Aug 2016, James Bottomley wrote:
> 
> > Making no judgments about the particular exemplars here, I would just
> > like to point out that one reason why projects exist with very little
> > diversity is that they "just work".  Usually people get involved when
> > something doesn't work or they need something changed to work for them.
> > However, people do have a high tolerance for "works well enough"
> > meaning that a project can be functional, widely used and not
> > attracting diverse contributors.  A case in point for this type of
> > project in the non-openstack world would be openssl but there are many
> > others.
> 
> In a somewhat related point, the kinds of metrics we use in OpenStack to
> evaluate project health tend to have the unintended consequence of
> requiring the projects to always be growing and changing (i.e. churning)
> rather than trending towards stability and maturity.
> 
> I'd like to think that we can have some projects that can be called
> "done".
> 
> So we need to consider the side effects of the measurements we're
> taking and not let the letter of the new laws kill the spirit.
> 
> Yours in cliches,

Sure. I think I'd want to set things up to trigger a review, and not an
automatic "expulsion". The TC at the time would be able to recognize a
stable project and take into account whether the level of activity is
appropriate for the maturity and nature of the project.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Sean Dague
On 08/02/2016 06:16 AM, Chris Dent wrote:
> On Mon, 1 Aug 2016, James Bottomley wrote:
> 
>> Making no judgments about the particular exemplars here, I would just
>> like to point out that one reason why projects exist with very little
>> diversity is that they "just work".  Usually people get involved when
>> something doesn't work or they need something changed to work for them.
>> However, people do have a high tolerance for "works well enough"
>> meaning that a project can be functional, widely used and not
>> attracting diverse contributors.  A case in point for this type of
>> project in the non-openstack world would be openssl but there are many
>> others.
> 
> In a somewhat related point, the kinds of metrics we use in OpenStack to
> evaluate project health tend to have the unintended consequence of
> requiring the projects to always be growing and changing (i.e. churning)
> rather than trending towards stability and maturity.
> 
> I'd like to think that we can have some projects that can be called
> "done".
> 
> So we need to consider the side effects of the measurements we're
> taking and not let the letter of the new laws kill the spirit.
> 
> Yours in cliches,

I do understand that concern. Metrics games definitely can have
unintended consequences. Are there instances of software in our
ecosystem that you consider done, single vendor, and would be negatively
impacted by not being called OpenStack?

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-02 Thread Chris Dent

On Mon, 1 Aug 2016, James Bottomley wrote:


Making no judgments about the particular exemplars here, I would just
like to point out that one reason why projects exist with very little
diversity is that they "just work".  Usually people get involved when
something doesn't work or they need something changed to work for them.
However, people do have a high tolerance for "works well enough"
meaning that a project can be functional, widely used and not
attracting diverse contributors.  A case in point for this type of
project in the non-openstack world would be openssl but there are many
others.


In a somewhat related point, the kinds of metrics we use in OpenStack to
evaluate project health tend to have the unintended consequence of
requiring the projects to always be growing and changing (i.e. churning)
rather than trending towards stability and maturity.

I'd like to think that we can have some projects that can be called
"done".

So we need to consider the side effects of the measurements we're
taking and not let the letter of the new laws kill the spirit.

Yours in cliches,
--
Chris Dent   ┬─┬ノ( º _ ºノ) http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread James Bottomley
On Mon, 2016-08-01 at 13:43 -0400, Sean Dague wrote:
> On 08/01/2016 12:24 PM, James Bottomley wrote:
> > Making no judgments about the particular exemplars here, I would 
> > just like to point out that one reason why projects exist with very
> > little diversity is that they "just work".  Usually people get 
> > involved when something doesn't work or they need something changed 
> > to work for them.  However, people do have a high tolerance for 
> > "works well enough" meaning that a project can be functional, 
> > widely used and not attracting diverse contributors.  A case in 
> > point for this type of project in the non-openstack world would be 
> > openssl but there are many others.
> 
> I think openssl is a good example of what we are actually trying to
> avoid. Over time that project boiled down to just a couple of people.
> Which seemed ok, because everything seemed to be working fine, but 
> only because no one was pushing on it too hard. Then folks did, and 
> we realized that there was kind of a house of cards here, that's
> required special intervention to address some of the issues found.

The original problem was lack of security audits leading to heartbleed
mistakes.  Now that that's been remedied by investment from the CII,
the project is still very monoclonal and run by a small group ... and
still just as essential.

> Keeping a diverse community up front helps mitigate some of this. 
> It's not a silver bullet by any means, but it does help ensure that 
> the goals of the project aren't only the goals of a single product 
> team inside a single entity.

The point I'm making is that Company led projects tend to be much
better connected with the end user base (because companies want
customers) which, ipso facto, means they tend to fall into the "good
enough" bucket and fail to attract many more outside contributions.

James



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Ed Leafe
On Aug 1, 2016, at 10:14 AM, Adrian Otto  wrote:

> I am struggling to understand why we would want to remove projects from our 
> big tent at all, as long as they are being actively developed under the 
> principles of "four opens". It seems to me that working to disqualify such 
> projects sends an alarming signal to our ecosystem. The reason we made the 
> big tent to begin with was to set a tone of inclusion. This whole discussion 
> seems like a step backward. What problem are we trying to solve, exactly?

Many projects that are largely single-vendor are approved for the big tent with 
the understanding that they need to diversify. I believe that it is these types 
of projects that we are discussing.

-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Sean Dague
On 08/01/2016 12:24 PM, James Bottomley wrote:
> On Mon, 2016-08-01 at 11:38 -0400, Doug Hellmann wrote:
>> Excerpts from Adrian Otto's message of 2016-08-01 15:14:48 +:
>>> I am struggling to understand why we would want to remove projects
>>> from our big tent at all, as long as they are being actively
>>> developed under the principles of "four opens". It seems to me that
>>> working to disqualify such projects sends an alarming signal to our
>>> ecosystem. The reason we made the big tent to begin with was to set
>>> a tone of inclusion. This whole discussion seems like a step
>>> backward. What problem are we trying to solve, exactly?
>>>
>>> If we want to have tags to signal team diversity, that's fine. We
>>> do that now. But setting arbitrary requirements for big tent
>>> inclusion based on who participates definitely sounds like a
>>> mistake.
>>
>> Membership in the big tent comes with benefits that have a real
>> cost born by the rest of the community. Space at PTG and summit
>> forum events is probably the one that's easiest to quantify and to
>> point to as something limited that we want to use as productively
>> as possible. If 90% of the work of a project is being done by a
>> single company or organization (our current definition for
>> single-vendor), and that doesn't change after 18 months, then I
>> would take that as a signal that the community isn't interested
>> enough in the project to bear the associated costs.
>>
>> I'm interested in hearing other reasons that we should keep these
>> sorts of projects, though. I'm not yet ready to propose the change
>> to the policy myself.
> 
> Making no judgments about the particular exemplars here, I would just
> like to point out that one reason why projects exist with very little
> diversity is that they "just work".  Usually people get involved when
> something doesn't work or they need something changed to work for them.
>  However, people do have a high tolerance for "works well enough"
> meaning that a project can be functional, widely used and not
> attracting diverse contributors.  A case in point for this type of
> project in the non-openstack world would be openssl but there are many
> others.

I think openssl is a good example of what we are actually trying to
avoid. Over time that project boiled down to just a couple of people.
Which seemed ok, because everything seemed to be working fine, but only
because no one was pushing on it too hard. Then folks did, and we
realized that there was kind of a house of cards here, that's required
special intervention to address some of the issues found.

Keeping a diverse community up front helps mitigate some of this. It's
not a silver bullet by any means, but it does help ensure that the goals
of the project aren't only the goals of a single product team inside a
single entity.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread James Bottomley
On Mon, 2016-08-01 at 11:38 -0400, Doug Hellmann wrote:
> Excerpts from Adrian Otto's message of 2016-08-01 15:14:48 +:
> > I am struggling to understand why we would want to remove projects
> > from our big tent at all, as long as they are being actively
> > developed under the principles of "four opens". It seems to me that
> > working to disqualify such projects sends an alarming signal to our
> > ecosystem. The reason we made the big tent to begin with was to set
> > a tone of inclusion. This whole discussion seems like a step
> > backward. What problem are we trying to solve, exactly?
> > 
> > If we want to have tags to signal team diversity, that's fine. We
> > do that now. But setting arbitrary requirements for big tent
> > inclusion based on who participates definitely sounds like a
> > mistake.
> 
> Membership in the big tent comes with benefits that have a real
> cost born by the rest of the community. Space at PTG and summit
> forum events is probably the one that's easiest to quantify and to
> point to as something limited that we want to use as productively
> as possible. If 90% of the work of a project is being done by a
> single company or organization (our current definition for
> single-vendor), and that doesn't change after 18 months, then I
> would take that as a signal that the community isn't interested
> enough in the project to bear the associated costs.
> 
> I'm interested in hearing other reasons that we should keep these
> sorts of projects, though. I'm not yet ready to propose the change
> to the policy myself.

Making no judgments about the particular exemplars here, I would just
like to point out that one reason why projects exist with very little
diversity is that they "just work".  Usually people get involved when
something doesn't work or they need something changed to work for them.
 However, people do have a high tolerance for "works well enough"
meaning that a project can be functional, widely used and not
attracting diverse contributors.  A case in point for this type of
project in the non-openstack world would be openssl but there are many
others.

James



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Doug Hellmann
Excerpts from Michael Krotscheck's message of 2016-08-01 16:06:45 +:
> FYI- I'm totally in favor of eviction. But...
> 
> On Mon, Aug 1, 2016 at 8:42 AM Doug Hellmann  wrote:
> 
> >
> > I'm interested in hearing other reasons that we should keep these
> > sorts of projects, though. I'm not yet ready to propose the change
> > to the policy myself.
> 
> 
> ...if the social consequences result in that entire team's development
> staff effectively exiting OpenStack altogether? This in particular is
> pertinent to myself - if Fuel is evicted from the big tent, then it's very
> likely that the JavaScript SDK collaboration (which includes several
> Fuel-UI developers and has _finally_ taken off) will grind to a halt.
> 
> There's a halo effect to having a project under the big tent - contributors
> are already familiar with infra and procedure, and thus the barriers to
> cross-project bugfixes are way lower. Perhaps (using Fuel as an example)
> the "should this be in the big tent" metric is based on how many
> contributors contribute _only_ to Fuel, as opposed to
> Fuel-and-other-projects.

Remember that the big tent is projects governed by the TC. Projects can
still use gerrit, CI, etc. even if they are not in the big tent.

> As a countersuggestion - perhaps the solution to increasing project
> diversity is to reduce barriers to cross-project contributions. If the
> learning curve of project-shifting was reduced (by agreeing on common web
> frameworks, etc), it'd certainly make cross-project bug fixes way easier.

I certainly support that, though as Jay points out in his thread on the
goals proposal we still want to leave room for experimentation.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Michael Krotscheck
FYI- I'm totally in favor of eviction. But...

On Mon, Aug 1, 2016 at 8:42 AM Doug Hellmann  wrote:

>
> I'm interested in hearing other reasons that we should keep these
> sorts of projects, though. I'm not yet ready to propose the change
> to the policy myself.


...if the social consequences result in that entire team's development
staff effectively exiting OpenStack altogether? This in particular is
pertinent to myself - if Fuel is evicted from the big tent, then it's very
likely that the JavaScript SDK collaboration (which includes several
Fuel-UI developers and has _finally_ taken off) will grind to a halt.

There's a halo effect to having a project under the big tent - contributors
are already familiar with infra and procedure, and thus the barriers to
cross-project bugfixes are way lower. Perhaps (using Fuel as an example)
the "should this be in the big tent" metric is based on how many
contributors contribute _only_ to Fuel, as opposed to
Fuel-and-other-projects.

As a countersuggestion - perhaps the solution to increasing project
diversity is to reduce barriers to cross-project contributions. If the
learning curve of project-shifting was reduced (by agreeing on common web
frameworks, etc), it'd certainly make cross-project bug fixes way easier.

Michael
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Doug Hellmann
Excerpts from Adrian Otto's message of 2016-08-01 15:14:48 +:
> I am struggling to understand why we would want to remove projects from our 
> big tent at all, as long as they are being actively developed under the 
> principles of "four opens". It seems to me that working to disqualify such 
> projects sends an alarming signal to our ecosystem. The reason we made the 
> big tent to begin with was to set a tone of inclusion. This whole discussion 
> seems like a step backward. What problem are we trying to solve, exactly?
> 
> If we want to have tags to signal team diversity, that's fine. We do that 
> now. But setting arbitrary requirements for big tent inclusion based on who 
> participates definitely sounds like a mistake.

Membership in the big tent comes with benefits that have a real
cost born by the rest of the community. Space at PTG and summit
forum events is probably the one that's easiest to quantify and to
point to as something limited that we want to use as productively
as possible. If 90% of the work of a project is being done by a
single company or organization (our current definition for
single-vendor), and that doesn't change after 18 months, then I
would take that as a signal that the community isn't interested
enough in the project to bear the associated costs.

I'm interested in hearing other reasons that we should keep these
sorts of projects, though. I'm not yet ready to propose the change
to the policy myself.

Doug

> 
> --
> Adrian
> 
> > On Aug 1, 2016, at 5:11 AM, Sean Dague  wrote:
> > 
> >> On 07/31/2016 02:29 PM, Doug Hellmann wrote:
> >> Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +:
> >>> Kevin,
> >>> 
> >>> Just assessing your numbers, the team:diverse-affiliation tag covers what
> >>> is required to maintain that tag.  It covers more then core reviewers -
> >>> also covers commits and reviews.
> >>> 
> >>> See:
> >>> https://github.com/openstack/governance/blob/master/reference/tags/team_div
> >>> erse-affiliation.rst
> >>> 
> >>> 
> >>> I can tell you from founding 3 projects with the team:diverse-affiliation
> >>> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
> >>> meet.  I don't think its wise to have such strict requirements on single
> >>> vendor projects as those objectively defined in team:diverse-affiliation.
> >>> 
> >>> But Doug's suggestion of timelines could make sense if the timelines gave
> >>> plenty of time to meet whatever requirements make sense and the
> >>> requirements led to some increase in diverse affiliation.
> >> 
> >> To be clear, I'm suggesting that projects with team:single-vendor be
> >> given enough time to lose that tag. That does not require them to grow
> >> diverse enough to get team:diverse-affiliation.
> > 
> > The idea of 3 cycles to loose the single-vendor tag sounds very
> > reasonable to me. This also is very much along the spirit of the tag in
> > that it should be one of the top priorities of the team to work on this.
> > I'd be in favor.
> > 
> >-Sean
> > 
> > -- 
> > Sean Dague
> > http://dague.net
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Doug Hellmann
Excerpts from Sean Dague's message of 2016-08-01 10:31:44 -0400:
> On 08/01/2016 10:28 AM, Davanum Srinivas wrote:
> > Sean,
> > 
> > So we will programatically test the metrics (if we are not doing that
> > already) to apply/remove "team:single-vendor" tag:
> > 
> > https://governance.openstack.org/reference/tags/team_single-vendor.html
> > 
> > And trigger exit when the tag is present for more than 3 cycles in a
> > row (say as of release date?)
> > 
> > Thanks,
> > -- Dims
> 
> An approach like that would be fine with me. I'm not sure we have a
> formal proposal yet, but 3 cycles seems like a reasonable time frame.
> I'm happy to debate if people think there are better timeframes instead.
> 
> -Sean
> 

Yes, I think 3 cycles works and we are supposed to be reviewing that tag
periodically anyway.

I also agree that there's no need to differentiate between the reasons
for not being able to drop the tag (lack of trying or lack of success),
for the reasons Sean gave.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Adrian Otto
I am struggling to understand why we would want to remove projects from our big 
tent at all, as long as they are being actively developed under the principles 
of "four opens". It seems to me that working to disqualify such projects sends 
an alarming signal to our ecosystem. The reason we made the big tent to begin 
with was to set a tone of inclusion. This whole discussion seems like a step 
backward. What problem are we trying to solve, exactly?

If we want to have tags to signal team diversity, that's fine. We do that now. 
But setting arbitrary requirements for big tent inclusion based on who 
participates definitely sounds like a mistake.

--
Adrian

> On Aug 1, 2016, at 5:11 AM, Sean Dague  wrote:
> 
>> On 07/31/2016 02:29 PM, Doug Hellmann wrote:
>> Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +:
>>> Kevin,
>>> 
>>> Just assessing your numbers, the team:diverse-affiliation tag covers what
>>> is required to maintain that tag.  It covers more then core reviewers -
>>> also covers commits and reviews.
>>> 
>>> See:
>>> https://github.com/openstack/governance/blob/master/reference/tags/team_div
>>> erse-affiliation.rst
>>> 
>>> 
>>> I can tell you from founding 3 projects with the team:diverse-affiliation
>>> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
>>> meet.  I don't think its wise to have such strict requirements on single
>>> vendor projects as those objectively defined in team:diverse-affiliation.
>>> 
>>> But Doug's suggestion of timelines could make sense if the timelines gave
>>> plenty of time to meet whatever requirements make sense and the
>>> requirements led to some increase in diverse affiliation.
>> 
>> To be clear, I'm suggesting that projects with team:single-vendor be
>> given enough time to lose that tag. That does not require them to grow
>> diverse enough to get team:diverse-affiliation.
> 
> The idea of 3 cycles to loose the single-vendor tag sounds very
> reasonable to me. This also is very much along the spirit of the tag in
> that it should be one of the top priorities of the team to work on this.
> I'd be in favor.
> 
>-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Sean Dague
On 08/01/2016 10:28 AM, Davanum Srinivas wrote:
> Sean,
> 
> So we will programatically test the metrics (if we are not doing that
> already) to apply/remove "team:single-vendor" tag:
> 
> https://governance.openstack.org/reference/tags/team_single-vendor.html
> 
> And trigger exit when the tag is present for more than 3 cycles in a
> row (say as of release date?)
> 
> Thanks,
> -- Dims

An approach like that would be fine with me. I'm not sure we have a
formal proposal yet, but 3 cycles seems like a reasonable time frame.
I'm happy to debate if people think there are better timeframes instead.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Davanum Srinivas
Sean,

So we will programatically test the metrics (if we are not doing that
already) to apply/remove "team:single-vendor" tag:

https://governance.openstack.org/reference/tags/team_single-vendor.html

And trigger exit when the tag is present for more than 3 cycles in a
row (say as of release date?)

Thanks,
-- Dims

On Mon, Aug 1, 2016 at 10:19 AM, Sean Dague  wrote:
> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
>> Thierry, Ben, Doug,
>>
>> How can we distinguish between. "Project is doing the right thing, but
>> others are not joining" vs "Project is actively trying to keep people
>> out"?
>
> I think at some level, it's not really that different. If we treat them
> as different, everyone will always believe they did all the right
> things, but got no results. 3 cycles should be plenty of time to drop
> single entity contributions below 90%. That means prioritizing bugs /
> patches from outside groups (to drop below 90% on code commits),
> mentoring every outside member that provides feedback (to drop below 90%
> on reviews), shifting development resources towards mentoring / docs /
> on ramp exercises for others in the community (to drop below 90% on core
> team).
>
> Digging out of a single vendor status is hard, and requires making that
> your top priority. If teams aren't interested in putting that ahead of
> development work, that's fine, but that doesn't make it a sustainable
> OpenStack project.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Sean Dague
On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
> Thierry, Ben, Doug,
> 
> How can we distinguish between. "Project is doing the right thing, but
> others are not joining" vs "Project is actively trying to keep people
> out"?

I think at some level, it's not really that different. If we treat them
as different, everyone will always believe they did all the right
things, but got no results. 3 cycles should be plenty of time to drop
single entity contributions below 90%. That means prioritizing bugs /
patches from outside groups (to drop below 90% on code commits),
mentoring every outside member that provides feedback (to drop below 90%
on reviews), shifting development resources towards mentoring / docs /
on ramp exercises for others in the community (to drop below 90% on core
team).

Digging out of a single vendor status is hard, and requires making that
your top priority. If teams aren't interested in putting that ahead of
development work, that's fine, but that doesn't make it a sustainable
OpenStack project.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Davanum Srinivas
Thierry, Ben, Doug,

How can we distinguish between. "Project is doing the right thing, but
others are not joining" vs "Project is actively trying to keep people
out"?

Thanks,
Dims

On Mon, Aug 1, 2016 at 9:32 AM, Ben Swartzlander  wrote:
> On 08/01/2016 03:39 AM, Thierry Carrez wrote:
>>
>> Steven Dake (stdake) wrote:
>>>
>>> On 7/31/16, 11:29 AM, "Doug Hellmann"  wrote:

 [...]
 To be clear, I'm suggesting that projects with team:single-vendor be
 given enough time to lose that tag. That does not require them to grow
 diverse enough to get team:diverse-affiliation.
>>>
>>>
>>> That makes sense and doesn't send the wrong message.  I wasn't trying to
>>> suggest that either; was just pointing out Kevin's numbers are more in
>>> line with diverse-affiliation than single vendor.  My personal thoughts
>>> are single vendor projects are ok in OpenStack if they are undertaking
>>> community-building activities to increase their diversity of
>>> contributors.
>>
>>
>> Basically my position on this is: OpenStack is about providing open
>> collaboration spaces so that multiple organizations and individuals can
>> collaborate (on a level playing ground) to solve a set of issues. It's
>> difficult to have a requirement of a project having a diversity of
>> affiliation before it can join, because of the chicken-and-egg issue
>> between visibility and affiliation-diversity. So we totally accept
>> single-vendor projects as official OpenStack projects.
>>
>> But if a project is persistently single-vendor after some time and
>> nobody seems interested to join it, the technical value of that project
>> being "in" OpenStack rather than a separate project in the OpenStack
>> ecosystem of projects is limited. It's limited for OpenStack (why
>> provide resources to support a project that is obviously only beneficial
>> to one organization ?), and it's limited to the organization itself (why
>> go through the OpenStack-specific open processes when you could shortcut
>> it with internal tools and meetings ? why accept the oversight of the
>> Technical Committee ?).
>
>
> Thierry I think you underestimate the value organizations perceive they get
> from projects being in the tent. Even if a project is single vendor, the
> halo effect of OpenStack and the access to free resources (the infra cloud,
> and more importantly the world-class infra TEAM) more than make up for any
> downsides associated with following established processes.
>
> I strongly doubt any organization would choose to remove a project from
> OpenStack for the reasons you mention. If the community doesn't want these
> kinds of projects in the big tent then the community probably needs to push
> them out.
>
> -Ben Swartzlander
>
>
>> So the idea is to find a way for projects who realize that they won't
>> attract a significant share of external contributions to move to an
>> externally-governed project. I'm not sure we can use a strict deadline
>> -- some projects might still be single-vendor after a year but without
>> structurally resisting contributions. But being able to trigger a review
>> after some time, to assess if we have reasons to think it will improve
>> in the future (or not), sounds like a good idea.
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Ben Swartzlander

On 08/01/2016 03:39 AM, Thierry Carrez wrote:

Steven Dake (stdake) wrote:

On 7/31/16, 11:29 AM, "Doug Hellmann"  wrote:

[...]
To be clear, I'm suggesting that projects with team:single-vendor be
given enough time to lose that tag. That does not require them to grow
diverse enough to get team:diverse-affiliation.


That makes sense and doesn't send the wrong message.  I wasn't trying to
suggest that either; was just pointing out Kevin's numbers are more in
line with diverse-affiliation than single vendor.  My personal thoughts
are single vendor projects are ok in OpenStack if they are undertaking
community-building activities to increase their diversity of contributors.


Basically my position on this is: OpenStack is about providing open
collaboration spaces so that multiple organizations and individuals can
collaborate (on a level playing ground) to solve a set of issues. It's
difficult to have a requirement of a project having a diversity of
affiliation before it can join, because of the chicken-and-egg issue
between visibility and affiliation-diversity. So we totally accept
single-vendor projects as official OpenStack projects.

But if a project is persistently single-vendor after some time and
nobody seems interested to join it, the technical value of that project
being "in" OpenStack rather than a separate project in the OpenStack
ecosystem of projects is limited. It's limited for OpenStack (why
provide resources to support a project that is obviously only beneficial
to one organization ?), and it's limited to the organization itself (why
go through the OpenStack-specific open processes when you could shortcut
it with internal tools and meetings ? why accept the oversight of the
Technical Committee ?).


Thierry I think you underestimate the value organizations perceive they 
get from projects being in the tent. Even if a project is single vendor, 
the halo effect of OpenStack and the access to free resources (the infra 
cloud, and more importantly the world-class infra TEAM) more than make 
up for any downsides associated with following established processes.


I strongly doubt any organization would choose to remove a project from 
OpenStack for the reasons you mention. If the community doesn't want 
these kinds of projects in the big tent then the community probably 
needs to push them out.


-Ben Swartzlander



So the idea is to find a way for projects who realize that they won't
attract a significant share of external contributions to move to an
externally-governed project. I'm not sure we can use a strict deadline
-- some projects might still be single-vendor after a year but without
structurally resisting contributions. But being able to trigger a review
after some time, to assess if we have reasons to think it will improve
in the future (or not), sounds like a good idea.




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Doug Hellmann
Excerpts from Fox, Kevin M's message of 2016-07-31 15:59:56 +:
> This sounds good to me.
> 
> What about making it iterative but with a delayed start. Something like:
> 
> There is a grace period of 1 year for projects that newly join the big tent. 
> After which, the following criteria will be evaluated to keep a project in 
> the big tent, evaluated at the end of each OpenStack release cycle to keep 
> the project for the next cycle. The project should not have active cores from 
> one company in the amount greater then 45% of the active core membership. If 
> that number is higher, the project is given notice they are under diverse and 
> have 6 months of remaining in the big tent to show they are attempting to 
> increase diversity by shifting the ratio to a more diverse active core 
> membership. The active core membership percentage by the over represented 
> company, called X%, will be shown to be reduced by 25% or reach 45%, so 
> max(X% * (100%-25%), 45%). If the criteria is met, the project can remain in 
> the big tent and a new cycle will begin. (another notification and 6 months 
> if still out of compliance)
> 
> This should allow projects that are, or become under diverse a path towards 
> working on project membership diversity. It gives projects that are very far 
> out of wack a while to fix it. It basically gives projects over represented:
>  * (80%, 100%] -  gets 18 months to fix it
>  * (60%, 80%] - gets 12 months
>  * (45%, 60%] - gets 6 months
> 
> Thoughts? The numbers should be fairly easy to change to make for different 
> amounts of grace period.

I think I understand the motivation behind a progressive deadline like
this, but I'd rather keep the implementation simple with a single
deadline, even if that means we give some teams what appears to be a
more generous amount of time than they need.

Doug

> 
> Thanks,
> Kevin
> 
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: Sunday, July 31, 2016 7:16 AM
> To: openstack-dev
> Subject: [openstack-dev] [tc] persistently single-vendor projects
> 
> Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
> Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
> 
> Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
> > Doug Hellmann wrote:
> > > There is only one way for a repository's contents to be considered
> > > part of the big tent: It needs to be listed in the projects.yaml
> > > file in the openstack/governance repository, associated with a
> > > deliverable from a team that has been accepted as a big tent member.
> > >
> > > The Fuel team has stated that they are not ready to include the
> > > work in these new repositories under governance, and indeed the
> > > repositories are not listed in the set of deliverables for the Fuel
> > > team [1].
> > >
> > > Therefore, the situation is clear, to me: They are not part of the
> > > big tent.
> >
> > Reading this thread after a week off, I'd like to +1 Doug's
> > interpretation since it was referenced to describe the status quo.
> >
> > As others have said, we wouldn't even have that discussion if the new
> > repositories didn't use "fuel" as part of the naming. We probably
> > wouldn't have that discussion either if the Fuel team affiliation was
> > more diverse and the new repositories were an experiment of a specific
> > subgroup of that team.
> >
> > NB: I *do* have some concerns about single-vendor OpenStack projects
> > that don't grow more diverse affiliations over time, but that's a
> > completely separate topic.
> 
> I'm starting to think that perhaps we should add some sort of
> expectation of a time-frame for projects that join the big tent as
> single-vendor to attract other contributors.
> 
> We removed the requirement that new projects need to have some
> minimal level of diversity when they join because projects asserted
> that they would have a better chance of attracting other contributors
> after becoming official. It might focus the team's efforts on that
> priority if we said that after a year or 18 months without any
> increased diversity, the project would be removed from the big tent.
> 
> Doug
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Sean Dague
On 07/31/2016 02:29 PM, Doug Hellmann wrote:
> Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +:
>> Kevin,
>>
>> Just assessing your numbers, the team:diverse-affiliation tag covers what
>> is required to maintain that tag.  It covers more then core reviewers -
>> also covers commits and reviews.
>>
>> See:
>> https://github.com/openstack/governance/blob/master/reference/tags/team_div
>> erse-affiliation.rst
>>
>>
>> I can tell you from founding 3 projects with the team:diverse-affiliation
>> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
>> meet.  I don't think its wise to have such strict requirements on single
>> vendor projects as those objectively defined in team:diverse-affiliation.
>>
>> But Doug's suggestion of timelines could make sense if the timelines gave
>> plenty of time to meet whatever requirements make sense and the
>> requirements led to some increase in diverse affiliation.
> 
> To be clear, I'm suggesting that projects with team:single-vendor be
> given enough time to lose that tag. That does not require them to grow
> diverse enough to get team:diverse-affiliation.

The idea of 3 cycles to loose the single-vendor tag sounds very
reasonable to me. This also is very much along the spirit of the tag in
that it should be one of the top priorities of the team to work on this.
I'd be in favor.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Swapnil Kulkarni (coolsvap)
On Mon, Aug 1, 2016 at 1:09 PM, Thierry Carrez  wrote:
> Steven Dake (stdake) wrote:
>> On 7/31/16, 11:29 AM, "Doug Hellmann"  wrote:
>>> [...]
>>> To be clear, I'm suggesting that projects with team:single-vendor be
>>> given enough time to lose that tag. That does not require them to grow
>>> diverse enough to get team:diverse-affiliation.
>>
>> That makes sense and doesn't send the wrong message.  I wasn't trying to
>> suggest that either; was just pointing out Kevin's numbers are more in
>> line with diverse-affiliation than single vendor.  My personal thoughts
>> are single vendor projects are ok in OpenStack if they are undertaking
>> community-building activities to increase their diversity of contributors.
>
> Basically my position on this is: OpenStack is about providing open
> collaboration spaces so that multiple organizations and individuals can
> collaborate (on a level playing ground) to solve a set of issues. It's
> difficult to have a requirement of a project having a diversity of
> affiliation before it can join, because of the chicken-and-egg issue
> between visibility and affiliation-diversity. So we totally accept
> single-vendor projects as official OpenStack projects.
>
> But if a project is persistently single-vendor after some time and
> nobody seems interested to join it, the technical value of that project
> being "in" OpenStack rather than a separate project in the OpenStack
> ecosystem of projects is limited. It's limited for OpenStack (why
> provide resources to support a project that is obviously only beneficial
> to one organization ?), and it's limited to the organization itself (why
> go through the OpenStack-specific open processes when you could shortcut
> it with internal tools and meetings ? why accept the oversight of the
> Technical Committee ?).

+1 to track this.

>
> So the idea is to find a way for projects who realize that they won't
> attract a significant share of external contributions to move to an
> externally-governed project. I'm not sure we can use a strict deadline
> -- some projects might still be single-vendor after a year but without
> structurally resisting contributions. But being able to trigger a review
> after some time, to assess if we have reasons to think it will improve
> in the future (or not), sounds like a good idea.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


The idea of externally-governed projects is very good since there are
and will be projects which want the status of being part of
"OpenStack" community but cannot have diverse-affiliation due to
inherent nature of development/testing/ci or whatsoever requirements.
If it remains or is known to remain a single vendor project in its
future, it does not need to be dependent on any of the community
resources, be it contributors/infrastructure.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-08-01 Thread Thierry Carrez
Steven Dake (stdake) wrote:
> On 7/31/16, 11:29 AM, "Doug Hellmann"  wrote:
>> [...]
>> To be clear, I'm suggesting that projects with team:single-vendor be
>> given enough time to lose that tag. That does not require them to grow
>> diverse enough to get team:diverse-affiliation.
> 
> That makes sense and doesn't send the wrong message.  I wasn't trying to
> suggest that either; was just pointing out Kevin's numbers are more in
> line with diverse-affiliation than single vendor.  My personal thoughts
> are single vendor projects are ok in OpenStack if they are undertaking
> community-building activities to increase their diversity of contributors.

Basically my position on this is: OpenStack is about providing open
collaboration spaces so that multiple organizations and individuals can
collaborate (on a level playing ground) to solve a set of issues. It's
difficult to have a requirement of a project having a diversity of
affiliation before it can join, because of the chicken-and-egg issue
between visibility and affiliation-diversity. So we totally accept
single-vendor projects as official OpenStack projects.

But if a project is persistently single-vendor after some time and
nobody seems interested to join it, the technical value of that project
being "in" OpenStack rather than a separate project in the OpenStack
ecosystem of projects is limited. It's limited for OpenStack (why
provide resources to support a project that is obviously only beneficial
to one organization ?), and it's limited to the organization itself (why
go through the OpenStack-specific open processes when you could shortcut
it with internal tools and meetings ? why accept the oversight of the
Technical Committee ?).

So the idea is to find a way for projects who realize that they won't
attract a significant share of external contributions to move to an
externally-governed project. I'm not sure we can use a strict deadline
-- some projects might still be single-vendor after a year but without
structurally resisting contributions. But being able to trigger a review
after some time, to assess if we have reasons to think it will improve
in the future (or not), sounds like a good idea.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] persistently single-vendor projects

2016-07-31 Thread Steven Dake (stdake)


On 7/31/16, 11:29 AM, "Doug Hellmann" <d...@doughellmann.com> wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +:
>> Kevin,
>> 
>> Just assessing your numbers, the team:diverse-affiliation tag covers
>>what
>> is required to maintain that tag.  It covers more then core reviewers -
>> also covers commits and reviews.
>> 
>> See:
>> 
>>https://github.com/openstack/governance/blob/master/reference/tags/team_d
>>iv
>> erse-affiliation.rst
>> 
>> 
>> I can tell you from founding 3 projects with the
>>team:diverse-affiliation
>> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
>> meet.  I don't think its wise to have such strict requirements on single
>> vendor projects as those objectively defined in
>>team:diverse-affiliation.
>> 
>> But Doug's suggestion of timelines could make sense if the timelines
>>gave
>> plenty of time to meet whatever requirements make sense and the
>> requirements led to some increase in diverse affiliation.
>
>To be clear, I'm suggesting that projects with team:single-vendor be
>given enough time to lose that tag. That does not require them to grow
>diverse enough to get team:diverse-affiliation.
>
>Doug
Doug,

That makes sense and doesn't send the wrong message.  I wasn't trying to
suggest that either; was just pointing out Kevin's numbers are more in
line with diverse-affiliation than single vendor.  My personal thoughts
are single vendor projects are ok in OpenStack if they are undertaking
community-building activities to increase their diversity of contributors.

Regards
-steve

>
>> 
>> The 45% core requirement sort of goes against the tag name
>> "single-vendor".
>> 
>> I know of many single vendor projects that would like to have a diverse
>> affiliation, strive for it, and actively promote the integration of new
>> community members into their respective sub-communities.  We don't want
>>to
>> send these folks the wrong message they aren't welcome.
>> 
>> Regards
>> -steve
>> 
>> On 7/31/16, 8:59 AM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:
>> 
>> >This sounds good to me.
>> >
>> >What about making it iterative but with a delayed start. Something
>>like:
>> >
>> >There is a grace period of 1 year for projects that newly join the big
>> >tent. After which, the following criteria will be evaluated to keep a
>> >project in the big tent, evaluated at the end of each OpenStack release
>> >cycle to keep the project for the next cycle. The project should not
>>have
>> >active cores from one company in the amount greater then 45% of the
>> >active core membership. If that number is higher, the project is given
>> >notice they are under diverse and have 6 months of remaining in the big
>> >tent to show they are attempting to increase diversity by shifting the
>> >ratio to a more diverse active core membership. The active core
>> >membership percentage by the over represented company, called X%, will
>>be
>> >shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%).
>>If
>> >the criteria is met, the project can remain in the big tent and a new
>> >cycle will begin. (another notification and 6 months if still out of
>> >compliance)
>> >
>> >This should allow projects that are, or become under diverse a path
>> >towards working on project membership diversity. It gives projects that
>> >are very far out of wack a while to fix it. It basically gives projects
>> >over represented:
>> > * (80%, 100%] -  gets 18 months to fix it
>> > * (60%, 80%] - gets 12 months
>> > * (45%, 60%] - gets 6 months
>> >
>> >Thoughts? The numbers should be fairly easy to change to make for
>> >different amounts of grace period.
>> >
>> >Thanks,
>> >Kevin
>> >
>> >From: Doug Hellmann [d...@doughellmann.com]
>> >Sent: Sunday, July 31, 2016 7:16 AM
>> >To: openstack-dev
>> >Subject: [openstack-dev] [tc] persistently single-vendor projects
>> >
>> >Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
>> >Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
>> >
>> >Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
>> >> Doug Hellmann wrote:
>> >> > There is only one way for a repository's contents to be considered
>&

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-07-31 Thread Doug Hellmann
Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +:
> Kevin,
> 
> Just assessing your numbers, the team:diverse-affiliation tag covers what
> is required to maintain that tag.  It covers more then core reviewers -
> also covers commits and reviews.
> 
> See:
> https://github.com/openstack/governance/blob/master/reference/tags/team_div
> erse-affiliation.rst
> 
> 
> I can tell you from founding 3 projects with the team:diverse-affiliation
> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
> meet.  I don't think its wise to have such strict requirements on single
> vendor projects as those objectively defined in team:diverse-affiliation.
> 
> But Doug's suggestion of timelines could make sense if the timelines gave
> plenty of time to meet whatever requirements make sense and the
> requirements led to some increase in diverse affiliation.

To be clear, I'm suggesting that projects with team:single-vendor be
given enough time to lose that tag. That does not require them to grow
diverse enough to get team:diverse-affiliation.

Doug

> 
> The 45% core requirement sort of goes against the tag name
> "single-vendor". 
> 
> I know of many single vendor projects that would like to have a diverse
> affiliation, strive for it, and actively promote the integration of new
> community members into their respective sub-communities.  We don't want to
> send these folks the wrong message they aren't welcome.
> 
> Regards
> -steve
> 
> On 7/31/16, 8:59 AM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:
> 
> >This sounds good to me.
> >
> >What about making it iterative but with a delayed start. Something like:
> >
> >There is a grace period of 1 year for projects that newly join the big
> >tent. After which, the following criteria will be evaluated to keep a
> >project in the big tent, evaluated at the end of each OpenStack release
> >cycle to keep the project for the next cycle. The project should not have
> >active cores from one company in the amount greater then 45% of the
> >active core membership. If that number is higher, the project is given
> >notice they are under diverse and have 6 months of remaining in the big
> >tent to show they are attempting to increase diversity by shifting the
> >ratio to a more diverse active core membership. The active core
> >membership percentage by the over represented company, called X%, will be
> >shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). If
> >the criteria is met, the project can remain in the big tent and a new
> >cycle will begin. (another notification and 6 months if still out of
> >compliance)
> >
> >This should allow projects that are, or become under diverse a path
> >towards working on project membership diversity. It gives projects that
> >are very far out of wack a while to fix it. It basically gives projects
> >over represented:
> > * (80%, 100%] -  gets 18 months to fix it
> > * (60%, 80%] - gets 12 months
> > * (45%, 60%] - gets 6 months
> >
> >Thoughts? The numbers should be fairly easy to change to make for
> >different amounts of grace period.
> >
> >Thanks,
> >Kevin
> >
> >From: Doug Hellmann [d...@doughellmann.com]
> >Sent: Sunday, July 31, 2016 7:16 AM
> >To: openstack-dev
> >Subject: [openstack-dev] [tc] persistently single-vendor projects
> >
> >Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
> >Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
> >
> >Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
> >> Doug Hellmann wrote:
> >> > There is only one way for a repository's contents to be considered
> >> > part of the big tent: It needs to be listed in the projects.yaml
> >> > file in the openstack/governance repository, associated with a
> >> > deliverable from a team that has been accepted as a big tent member.
> >> >
> >> > The Fuel team has stated that they are not ready to include the
> >> > work in these new repositories under governance, and indeed the
> >> > repositories are not listed in the set of deliverables for the Fuel
> >> > team [1].
> >> >
> >> > Therefore, the situation is clear, to me: They are not part of the
> >> > big tent.
> >>
> >> Reading this thread after a week off, I'd like to +1 Doug's
> >> interpretation since it was referenced to describe the status quo.
> >>
> >> As others have said, we would

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-07-31 Thread Steven Dake (stdake)
Kevin,

Just assessing your numbers, the team:diverse-affiliation tag covers what
is required to maintain that tag.  It covers more then core reviewers -
also covers commits and reviews.

See:
https://github.com/openstack/governance/blob/master/reference/tags/team_div
erse-affiliation.rst


I can tell you from founding 3 projects with the team:diverse-affiliation
tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
meet.  I don't think its wise to have such strict requirements on single
vendor projects as those objectively defined in team:diverse-affiliation.

But Doug's suggestion of timelines could make sense if the timelines gave
plenty of time to meet whatever requirements make sense and the
requirements led to some increase in diverse affiliation.

The 45% core requirement sort of goes against the tag name
"single-vendor". 

I know of many single vendor projects that would like to have a diverse
affiliation, strive for it, and actively promote the integration of new
community members into their respective sub-communities.  We don't want to
send these folks the wrong message they aren't welcome.

Regards
-steve

On 7/31/16, 8:59 AM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>This sounds good to me.
>
>What about making it iterative but with a delayed start. Something like:
>
>There is a grace period of 1 year for projects that newly join the big
>tent. After which, the following criteria will be evaluated to keep a
>project in the big tent, evaluated at the end of each OpenStack release
>cycle to keep the project for the next cycle. The project should not have
>active cores from one company in the amount greater then 45% of the
>active core membership. If that number is higher, the project is given
>notice they are under diverse and have 6 months of remaining in the big
>tent to show they are attempting to increase diversity by shifting the
>ratio to a more diverse active core membership. The active core
>membership percentage by the over represented company, called X%, will be
>shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). If
>the criteria is met, the project can remain in the big tent and a new
>cycle will begin. (another notification and 6 months if still out of
>compliance)
>
>This should allow projects that are, or become under diverse a path
>towards working on project membership diversity. It gives projects that
>are very far out of wack a while to fix it. It basically gives projects
>over represented:
> * (80%, 100%] -  gets 18 months to fix it
> * (60%, 80%] - gets 12 months
> * (45%, 60%] - gets 6 months
>
>Thoughts? The numbers should be fairly easy to change to make for
>different amounts of grace period.
>
>Thanks,
>Kevin
>____
>From: Doug Hellmann [d...@doughellmann.com]
>Sent: Sunday, July 31, 2016 7:16 AM
>To: openstack-dev
>Subject: [openstack-dev] [tc] persistently single-vendor projects
>
>Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
>Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
>
>Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
>> Doug Hellmann wrote:
>> > There is only one way for a repository's contents to be considered
>> > part of the big tent: It needs to be listed in the projects.yaml
>> > file in the openstack/governance repository, associated with a
>> > deliverable from a team that has been accepted as a big tent member.
>> >
>> > The Fuel team has stated that they are not ready to include the
>> > work in these new repositories under governance, and indeed the
>> > repositories are not listed in the set of deliverables for the Fuel
>> > team [1].
>> >
>> > Therefore, the situation is clear, to me: They are not part of the
>> > big tent.
>>
>> Reading this thread after a week off, I'd like to +1 Doug's
>> interpretation since it was referenced to describe the status quo.
>>
>> As others have said, we wouldn't even have that discussion if the new
>> repositories didn't use "fuel" as part of the naming. We probably
>> wouldn't have that discussion either if the Fuel team affiliation was
>> more diverse and the new repositories were an experiment of a specific
>> subgroup of that team.
>>
>> NB: I *do* have some concerns about single-vendor OpenStack projects
>> that don't grow more diverse affiliations over time, but that's a
>> completely separate topic.
>
>I'm starting to think that perhaps we should add some sort of
>expectation of a time-frame for projects that join the big tent as
>single-vendor to attract other contributors.
>
>We removed the requir

Re: [openstack-dev] [tc] persistently single-vendor projects

2016-07-31 Thread Fox, Kevin M
This sounds good to me.

What about making it iterative but with a delayed start. Something like:

There is a grace period of 1 year for projects that newly join the big tent. 
After which, the following criteria will be evaluated to keep a project in the 
big tent, evaluated at the end of each OpenStack release cycle to keep the 
project for the next cycle. The project should not have active cores from one 
company in the amount greater then 45% of the active core membership. If that 
number is higher, the project is given notice they are under diverse and have 6 
months of remaining in the big tent to show they are attempting to increase 
diversity by shifting the ratio to a more diverse active core membership. The 
active core membership percentage by the over represented company, called X%, 
will be shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). 
If the criteria is met, the project can remain in the big tent and a new cycle 
will begin. (another notification and 6 months if still out of compliance)

This should allow projects that are, or become under diverse a path towards 
working on project membership diversity. It gives projects that are very far 
out of wack a while to fix it. It basically gives projects over represented:
 * (80%, 100%] -  gets 18 months to fix it
 * (60%, 80%] - gets 12 months
 * (45%, 60%] - gets 6 months

Thoughts? The numbers should be fairly easy to change to make for different 
amounts of grace period.

Thanks,
Kevin

From: Doug Hellmann [d...@doughellmann.com]
Sent: Sunday, July 31, 2016 7:16 AM
To: openstack-dev
Subject: [openstack-dev] [tc] persistently single-vendor projects

Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"

Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
> Doug Hellmann wrote:
> > There is only one way for a repository's contents to be considered
> > part of the big tent: It needs to be listed in the projects.yaml
> > file in the openstack/governance repository, associated with a
> > deliverable from a team that has been accepted as a big tent member.
> >
> > The Fuel team has stated that they are not ready to include the
> > work in these new repositories under governance, and indeed the
> > repositories are not listed in the set of deliverables for the Fuel
> > team [1].
> >
> > Therefore, the situation is clear, to me: They are not part of the
> > big tent.
>
> Reading this thread after a week off, I'd like to +1 Doug's
> interpretation since it was referenced to describe the status quo.
>
> As others have said, we wouldn't even have that discussion if the new
> repositories didn't use "fuel" as part of the naming. We probably
> wouldn't have that discussion either if the Fuel team affiliation was
> more diverse and the new repositories were an experiment of a specific
> subgroup of that team.
>
> NB: I *do* have some concerns about single-vendor OpenStack projects
> that don't grow more diverse affiliations over time, but that's a
> completely separate topic.

I'm starting to think that perhaps we should add some sort of
expectation of a time-frame for projects that join the big tent as
single-vendor to attract other contributors.

We removed the requirement that new projects need to have some
minimal level of diversity when they join because projects asserted
that they would have a better chance of attracting other contributors
after becoming official. It might focus the team's efforts on that
priority if we said that after a year or 18 months without any
increased diversity, the project would be removed from the big tent.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tc] persistently single-vendor projects

2016-07-31 Thread Doug Hellmann
Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"

Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
> Doug Hellmann wrote:
> > There is only one way for a repository's contents to be considered
> > part of the big tent: It needs to be listed in the projects.yaml
> > file in the openstack/governance repository, associated with a
> > deliverable from a team that has been accepted as a big tent member.
> > 
> > The Fuel team has stated that they are not ready to include the
> > work in these new repositories under governance, and indeed the
> > repositories are not listed in the set of deliverables for the Fuel
> > team [1].
> > 
> > Therefore, the situation is clear, to me: They are not part of the
> > big tent.
> 
> Reading this thread after a week off, I'd like to +1 Doug's
> interpretation since it was referenced to describe the status quo.
> 
> As others have said, we wouldn't even have that discussion if the new
> repositories didn't use "fuel" as part of the naming. We probably
> wouldn't have that discussion either if the Fuel team affiliation was
> more diverse and the new repositories were an experiment of a specific
> subgroup of that team.
> 
> NB: I *do* have some concerns about single-vendor OpenStack projects
> that don't grow more diverse affiliations over time, but that's a
> completely separate topic.

I'm starting to think that perhaps we should add some sort of
expectation of a time-frame for projects that join the big tent as
single-vendor to attract other contributors.

We removed the requirement that new projects need to have some
minimal level of diversity when they join because projects asserted
that they would have a better chance of attracting other contributors
after becoming official. It might focus the team's efforts on that
priority if we said that after a year or 18 months without any
increased diversity, the project would be removed from the big tent.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev