On 14/06/2016 17:14, Anita Kuno wrote: > On 06/14/2016 10:44 AM, Hayes, Graham wrote: >> On 14/06/2016 15:00, Thierry Carrez wrote: >>> Hi everyone, >>> >>> I just proposed a new requirement for OpenStack "official" projects, >>> which I think is worth discussing beyond the governance review: >>> >>> https://review.openstack.org/#/c/329448/ >>> >>> From an upstream perspective, I see us as being in the business of >>> providing open collaboration playing fields in order to build projects >>> to reach the OpenStack Mission. We collectively provide resources >>> (infra, horizontal teams, events...) in order to enable that open >>> collaboration. >>> >>> An important characteristic of these open collaboration grounds is that >>> they need to be a level playing field, where no specific organization is >>> being given an unfair advantage. I expect the teams that we bless as >>> "official" project teams to operate in that fair manner. Otherwise we >>> end up blessing what is essentially a trojan horse for a given >>> organization, open-washing their project in the process. Such a project >>> can totally exist as an unofficial project (and even be developed on >>> OpenStack infrastructure) but I don't think it should be given free >>> space in our Design Summits or benefit from "OpenStack community" branding. >>> >>> So if, in a given project team, developers from one specific >>> organization benefit from access to specific knowledge or hardware >>> (think 3rd-party testing blackboxes that decide if a patch goes in, or >>> access to proprietary hardware or software that the open source code >>> primarily interfaces with), then this project team should probably be >>> rejected under the "open community" rule. Projects with a lot of drivers >>> (like Cinder) provide an interesting grey area, but as long as all >>> drivers are in and there is a fully functional (and popular) open source >>> implementation, I think no specific organization would be considered as >>> unfairly benefiting compared to others. >>> >>> A few months ago we had the discussion about what "no open core" means >>> in 2016, in the context of the Poppy team candidacy. With our reading at >>> the time we ended up rejecting Poppy partly because it was interfacing >>> with proprietary technologies. However, I think what we originally >>> wanted to ensure with this rule was that no specific organization would >>> use the OpenStack open source code as crippled bait to sell their >>> specific proprietary add-on. >>> >>> I think taking the view that OpenStack projects need to be open, level >>> collaboration playing fields encapsulates that nicely. In the Poppy >>> case, nobody in the Poppy team has an unfair advantage over others, so >>> we should not reject them purely on the grounds that this interfaces >>> with non-open-source solutions (leaving only the infrastructure/testing >>> requirement to solve). On the other hand, a Neutron plugin targeting a >>> specific piece of networking hardware would likely give an unfair >>> advantage to developers of the hardware's manufacturer (having access to >>> that gear for testing and being able to see and make changes to its >>> proprietary source code) -- that project should probably live as an >>> unofficial OpenStack project. >>> >>> Comments, thoughts ? >>> >> >> >> From our perspective, we (designate) currently have a few drivers from >> proprietary vendors, and would like to add one in the near future. >> >> The current drivers are marked as "release compatible" - aka someone is >> nominated to test the driver throughout the release cycle, and then >> during the RC fully validate the driver. >> >> The new driver will have 3rd party CI, to test it on every commit. >> >> These are (very) small parts of the code base, but part of it none >> the less. If this is passes, should we push these plugins to separate >> repos, and not include them as part of the Designate project? >> >> As another idea - if we have to move them out of tree - could we have >> another "type" of project? >> >> A lot of projects have "drivers" for vendor hardware / software - >> could there be a way of marking projects as drivers of a deliverable - >> as most of these drivers will be very tied to specific versions of >> OpenStack projects. >> >> I fully agree with the sentiment, and overall aim of the requirement, >> I just want to ensure we have as little negative impact on deployers >> as possible. >> >> -- Graham > > I highly recommend you spend some time interacting with the Neutron, > Nova, Cinder and Ironic communities to learn how they approach this > issue. Each community has a slightly different approach to interacting > with vendors with different pain points in each approach. I think > learning from these projects regarding this issue would be a great way > to formulate your best plan for designate. Also time spent with Mike > Perez on this issue is an investment as far as I'm concerned. > > Thank you, > Anita. >
Yup, and I have looked at each of these projects before. I am more concerned about how this particular governance change will affect the project. Thanks Graham >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
