Overall, I see this as a very positive development for the OVS community. The 
charter looks to be comprehensive and, as mentioned by Flavio, shouldn't cause 
any major change to the day-to-day development work by the community. 
 
I remember at the OVS conference last year, there was a good presentation by 
Thomas from Noiro on the openness of the OVS community - 
https://www.youtube.com/watch?v=J0zpnScZW7g - in which he talked about the 
perception that the community is "closed" and "dominated by vmware". The data 
showed among other things that a) "Ben is a coding machine" :)  b) "majority of 
commits still come from Nicira team but it is balancing out". I think this 
"balancing out" is a good trend as we would like as diverse a community as 
possible. Diversity encourages contribution, helps avoid the group-think of a 
dominant group, and helps address a wider range of use cases. Therefore, I 
think there is a great opportunity in this charter to dispel this perception 
and, by doing so, help grow the community.
 
With that in mind, I have a few comments on the charter:
 
2. Technical Steering Committee ("TSC")
------------------------------------------------------
 
Processes (not really dealt with by the charter but worth some discussion):
* I think the following would improve transparency, I don't know if this should 
be in the charter, but I think it would be good to address: 
     a. A more open roadmap to avoid duplication, encourage collaboration and 
avoid disappointment when a lot of work has been put into something that 
doesn't get a lot of support from the community. I really liked the way OVN 
started, Ben circulated some development documents which gave everyone a good 
idea of what was going on before code was written and an opportunity to help 
out or comment on. You could take this to the extreme and do something like 
blueprints in Openstack (but this is probably a too heavyweight?)
     b: When the TSC members meet, it would be good that it was documented and 
shared so we can understand the decision making process for the technical 
direction.
 
Voting:
* The charter states that "While it is the goal of OVS to operate as a 
consensus based community, if any TSC decision requires a vote to move forward, 
the Committers shall vote on a one vote per Committer basis."
   Due to b) above, the distribution of the TSC inevitably weighted towards the 
Nicira team which effectively gives veto to one group. I believe this is 
something we should as a community attempt to change. This is obviously not 
going to happen immediately but if we put the right processes in place, it 
should make it easier. One example may be to limit the number of votes 
allocated to one group? Maybe there are other suggestions?
 
* There doesn't seem to be a process to propose a committer unless you are a 
committer. Maybe this could change?
 
1. Mission of Open vSwitch Project ("OVS").
------------------------------------------------------
* I would also like to propose a change to the mission statement. I think this 
is particularly important as we are trying to target OVS for use in NFV use 
cases which is not an use case that was originally envisioned. 
 
" create an open source, production quality, high-performance virtual 
networking platform, including a software switch, control plane, associated 
hardware and software accelerators and related components, that supports 
standard management interfaces and opens the forwarding functions to 
programmatic extension and control;"
 
* Can we call out testing infrastructure explicitly in the second bullet?
 
* Another question that I have is do you expect any changes in the developer 
tool chain? For example, will we be using gerrit, jira, etc?

Thanks

Mark

> -----Original Message-----
> From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of Ben
> Pfaff
> Sent: Sunday, June 19, 2016 5:37 PM
> To: discuss@openvswitch.org
> Subject: [ovs-discuss] Request for comments on Open vSwitch joining the
> Linux Foundation
> 
> Since roughly October, some of the OVS committers have been talking over
> the idea of bringing Open vSwitch into a foundation.  Originally the group
> discussing the idea was Justin, Russell, Thomas, and me, but we later
> expanded it to include all of the OVS committers.
> 
> The kinds of changes we're interested in include transferring ownership of
> the openvswitch.org and ovn.org domain names, hosting and administration
> of the website, mailing lists, and forwarding email addresses for ovn.org,
> formalizing the existing processes for adding and removing committers, and
> obtaining support for organizing the annual Open vSwitch conference.
> Possibly, OVS could benefit from joining a foundation in other ways, such as
> trademark registration, founding a centralized test or performance lab, etc.,
> but those potential benefits have not been our focus.
> 
> We think that Open vSwitch development works quite well as a rule and we
> have no desire to disrupt that, so we also have a list of changes that we do
> *not* want to make.  These include introducing new processes for
> committers such as requiring copyright assignments or CLAs (contributor
> license agreements), significant changes to other policies and processes we
> have that are working, and significant technical changes to our repositories
> on the basis of e.g. legal requirements from a foundation.
> 
> One option is to form our own foundation.  To do this right, it would be a lot
> of work.  We did not seriously pursue this possibility.
> 
> We seriously considered three options:
> 
>     - Apache Software Foundation.  We had a call with members of the
>       Apache board.  Apache would offer OVS all of the services that
>       we want.  (They contract with the Linux Foundation to handle
>       events such as conferences.)  However, they are very "cookie
>       cutter" in that every Apache project is expected to fit into its
>       strictly defined model.  This would be difficult for OVS.  For
>       example, the only acceptable license is the Apache license,
>       which means that the Linux kernel portions of the OVS project
>       would have to be broken out into a separate repository and could
>       not be officially part of the project.  (We asked specifically
>       about this.)  As a second example, Apache requires use of their
>       CLA and all of the committers would be required to sign it and
>       to get their employers to sign it.  We considered these issues
>       to be too disruptive to the project.
> 
>     - Software in the Public Interest (spi-inc.org), aka SPI, the
>       parent of the Debian project.  In many ways it is almost the
>       diametric opposite of the Apache Software Foundation.  Projects
>       have a lot of freedom to operate as they choose, which is a
>       positive, but on the other hand SPI does not provide much in the
>       way of services.  SPI could accept assets such as domain names,
>       and hold donations, but it's questionable whether SPI could
>       relieve us from burdens in hosting and administering even
>       mailing lists, and we could not expect help in running events.
> 
>     - Linux Foundation (LF).  We held calls and meetings with LF
>       executive director Jim Zemlin and vice president Mike Dolan.  LF
>       has all the services we're interested in.  For established
>       projects, like OVS, they aim to avoid disrupting processes and
>       policies that work, so we could retain, unchanged, most of the
>       existing OVS governance.
> 
> We came to consensus among our small group and then among the
> committers in joining the Linux Foundation.  Since then, we've iterated
> through a few versions of a proposed charter for the Open vSwitch project
> within Linux Foundation.  I'm attaching a PDF of the most recent version.  The
> committers have come to informal consensus in favor of this charter.
> VMware, which owns or employs owners of some OVS-related assets, is also
> on board.
> 
> Here's my summary of the document.  Very little is changing.  Under the LF,
> OVS would have a technical steering committee (TSC), whose membership is
> the current OVS committers.  OVS retains its existing documented
> procedures.  The most important of these is the procedure for adding new
> committers, in which existing committers nominate new ones based on their
> contributions to the project.  The details are
> here:
> 
> 
> https://github.com/openvswitch/ovs/blob/master/Documentation/committ
> er-grant-revocation.md
> 
> The OVS committers span a number of organizations and specialties and
> represent the top contributors to the project.  A current list is included in 
> the
> main repo:
> 
>     https://github.com/openvswitch/ovs/blob/master/MAINTAINERS.md
> 
> Inclusion in the group of committers is tied to an individual's contributions,
> not their affiliation.
> 
> LF expects OVS to be a rather small budgetary burden, due to the project's
> simple structure.  The TSC will coordinate with LF for any budgetary needs.
> 
> At this point, I'd like to suggest that people read over the draft and, if you
> have comments, bring them up here for discussion.  After allowing time for
> discussion, the committers will hold a vote on joining the Linux Foundation.  
> I
> believe that that is the final step in the plan.
> 
> Ben Pfaff (on behalf of all the OVS committers)
> 
> P.S. Please ignore the dates in the charter.  We will update them.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to