Re: my perspective on where we are with the single controller code base issue
|
Kyle Forster
Dave (and other members of the community) - The folks that work here at BSN are here to make Daylight as successful as we can, but i) we owe transparency about our over-arching concern (that we think is valid for a large swath of the community), ii) we'd like to go to a few facts and iii) we'd like to chart a productive path forward. ------- Transparency -- The over-arching concern that we (BSN folk) have tried to mitigate with design and process proposals is a "tyranny of the committer majority" problem in the controller project, a situation where a highly concentrated group of committers blocks well intentioned progress by teams around them whose applications call for different design trade-offs and timing priorities. This issue is very real in other well known SDN open source projects where competing companies are regularly locked out from material commits. The result is an awkward amalgamation of open and closed source components across a handful of companies now, a trail of open source that isn't broadly used in production and a lot of confusion. The problem isn't because the concentrated group of committers in these projects have been evil, or dumb, or mean. They simply prioritize designs for the needs they see and add friction for the needs they don't until those needs go away. While subjective, I submit to the list that the same patterns are emerging in Daylight already, and it will take extraordinary effort by motivated individuals in the months ahead to avoid this path. ------- Let's go to facts -- First, the D-E plan you linked to above does *not* specify a starting repo in writing, but rather states explicitly on the page that the authors disagree on this point, a point that has been re-emphasized in the public threads. D-E plan, full steam ahead! Which D-E plan starting repo? Second, on community support, by my count of emails on list, I came up with 10 organizations voicing support for a fresh repo / committer list and 3 against. Have we asked for on-list support from others who share our concerns privately? Yes! But even if we filter by TSC organizations (community+$$$), we came up with 3 in favor, 3 against, 3 no explicit vote. -------- How to move forward? -- We are in strong favor of the fresh repo and blank committer list with Dave and Colin as the first two committers. Let them invite other committers to the "merged controller repo" along with their code as it flows to their design. This is the suggestion I believe that both Dave and Colin have supported as their own compromise as the authors of the D-E plan. It has the nice property of parallelizing work -- as we've drilled down, there is a lot to do on SAL to make it ready for production-grade Floodlight components, and a lot to do on making production-grade Floodlight components SAL-ready. We're signed up for a lot there. It has the nice property of aligning incentives -- committers are naturally balanced across those who get implementations, not ppt, in shape for Colin/Dave acceptance as quickly possible. We see this as healthy. It has the nice property of reducing the "tyranny of the committer majority" risk -- no community process or design is perfect, but we're optimistic this approach will yield a positive outcome. We're in support of the D-E 'fresh repo' suggestion for kick-starting the D-E plan, we're quite motivated to make the controller project a balanced committer repo and we're quite motivated to see this move forward. If there is community consensus on this approach, great! If not, we look to you (Dave) to figure out a decision protocol at the next TSC call. -Kyle On Tue, May 14, 2013 at 7:37 AM, David Meyer <dmm@...> wrote: BTW, it has been pointed out that I mis-attributed the IOCTL idea to --------------------------------------------------------- R. Kyle Forster +1 (415) 990-2670 (m) kyle.forster@... |
|
|