Date   

resolving the controller project/code base issues: process going forward

David Meyer <dmm@...>
 

Folks,

As TSC members will recall, I set a date of 05/13/2013 to have
proposals for the single controller project on the table, and Rob
asked a few questions about this on today's TSC call. Now, while
not created as a collaboration between Cisco and BSN, we do have
two proposals on the table: the Dixion-Erickson proposal from the ODP
community (https://wiki.opendaylight.org/view/Dixon-Erickson_OpenDaylight_Merged_Controller_Proposal)
and the Layered API Merged Controller Proposal from BSN
(https://wiki.opendaylight.org/view/Layered_API_Merged_Controller_Proposal).

The process I laid out on 04/29/2013 stated that "If no proposal
can be created by Cisco and BSN" that the TSC would vote for a
controller code base/project on 05/14/2013 in a private ballot
(see that email for details). Again, the goal here is to remove
the uncertainty around code bases that is preventing an ODP
community of developers from forming as well as preventing us from
making timely progress on the artifacts that we want to
deliver.

That said, the current state of affairs is that effectively we
have a proposal from the ODP community (the Dixon-Erickson
proposal) and a proposal from BSN. Consistent with the spirit and
intent of my email of 04/29/2013, unless clear community
consensus forms around one of these proposals before 05/14/2013,
the TSC will conduct a vote to choose one of these proposals as
the ODP controller code base/project going forward. Note that
while it is in the purview of the TSC to take such a vote, we
will vote only as a last resort.

In addition, please raise whatever questions you might have about
either proposal on the discuss list. Finally on this point,
additional information will also be provided by Rob relating to
the BSN proposal to be presented during the Technical Workstream
session on Monday, 05/13/2013, so please be sure to make that
call and have questions (if any) ready so we can make optimal use
of that time slot.

As I know you all understand but is worth reiterating here: the
uncertainty created by the lack of a single code base that
developers can start evolving and developing against is hurting
ODP, and it is our responsibility as a TSC to resolve this issue
in a timely fashion. Resolving this issue is sole intent of this
process.

Thnx,

--dmm


my perspective on where we are with the single controller code base issue

David Meyer <dmm@...>
 

All,

As you know today (05.14.2013) was the day on which I wanted to
have the single controller code base issue resolved. What I had
said is that if we couldn't get the projects to agree on a way
forward that we as a TSC would vote on the issue. In the mean
time we have reached general consensus that the Dixon-Erickson
OpenDaylight Merged Controller Proposal (DE) (see
https://wiki.opendaylight.org/view/Dixon-Erickson_OpenDaylight_Merged_Controller_Proposal).
I want to be very clear here that that plan is distinct from what
is being called Proposed Dixon-Erickson Execution Plan (see
https://wiki.opendaylight.org/view/Proposed_Dixon-Erickson_Execution_Plan). So
from this perspective the community has come together over this
general direction. This functionally obviates the need for a
direct vote.

There have been quite a few concerns raised both publicly and to
me directly in private email. I'd like to review those here and
provide my perspective.

(i). The SAL

It is generally agreed that there is work left to be done on the
SAL, and that there may be instances in which, (in the near term)
we need a mechanism to provide a kind of "SAL bypass". Chris'
IOCTL proposal is one such idea. What I want to point out here is
the the ODP is evolving and as such we expect the architecture to
not not improve technically but converge on the needed
functionality/generality over time. This is a completely natural
state of affairs for any software project. The summary is that we
can provide short term mechanisms that bridge any perceived or
real functionality gaps in the SAL (again, Chris' IOCTL idea
might be one such mechanism). So while the OSCP folks have
argued pretty strongly against the SAL (both publicly and
privately), the DE proposal endorses the SAL concept and the
OpenDaylight Controller folks consider the SAL to be a
fundamental architectural construct. That said, evolution of the
SAL (be it the model driven approach, bypass, etc) is an issue
for folks who are writing SAL applications (committing code) to
resolve.

(ii). New Project/Repository

This issue is really about the fairness of commits to the
controller code base. This was stated explicitly to me privately
and publicly by Glenn Ricart and Guru Parulkar on the discuss
list. On the other hand, a simple majority of TSC members (and
many in the community) have expressed the opinion that they would
prefer moving forward with the plan outlined in the DE-proposal,
namely start with the OpenDaylight controller and evolve that as
needed. I will note here that there is no objective evidence that
there is a fairness issue with commits to any candiate code base
(it would hard for that to be the case in any event as we haven't
had the chance to really get going). Finally, since this is
largely a political issue it is outside of the scope of the TSC
and should be "policed" by the community.

As an aside, I will also note here that several community
members have expressed concern that the new project
approach is quite expensive and has little benefit beyond
the political/perception issue mentioned above.


(iii) Timing

The timing issue, namely that there is (is not) a rush to get the
ODP project up and running is one that has also been raised both
publicly and privately. I have been told (again, both publicly
and privately) by the OSCP (BSN) folks that they have time
pressure to port their applications to the ODP controller. That
is a principle rationale behind the Layered API proposal
(https://wiki.opendaylight.org/view/Layered_API_Merged_Controller_Proposal).
In addition, the same team is also arguing that we are in no rush and
in fact any date for resolving the controller issue is not only
artificial but damaging to the community; this exact sentiment was
contained in a private communication from Rob Sherwood to me dated
Tue, May 14, 2013 at 1:38 AM. In the spirit of transparency I am copying the
relevant text from that email here:

"I know that in your heart you believe what you're doing is the
right thing for the community, and that's why I've held off
making a stink, but as chair, I'm not sure what you're doing is
in terms of pushing hard on this artificial deadline (that you
said originally was not set in stone but now it is) or being
opaque in terms of the actual process is really helping the
community." -- Rob Sherwood to dmm on Tue, May 14, 2013 at 1:38
AM.

(this text of course also contains criticisms of me in my role
as chair to which I will return but I want to focus here on the
timing issue).

The summary here is that it has been argued by the OSCP team that
we accept their proposal
(https://wiki.opendaylight.org/view/File:LayeredAPIProposal.pdf)
because there is time pressure to port applications while at the
same time it is being argued that any time frame is damaging,
artificial, or worse. On the other hand, a simple majority of the
TSC have stated publicly (on the discuss list) that resolving the
controller code base issue of primary importance and they would
like to move forward with an interpretation of DE that starts
with the existing OpenDaylight controller code base.

It is clear from these inconsistencies that the timing issue is
largely a non-issue for the ODP community at large; in addition
there is clear benefit to moving forward with the DE approach now. One
might also note here that we've made very little progress over
the last many weeks and it is time to start, now.

(iv). Finally, if anyone has problems with me personally and/or the
way TSC is being run please air those publicly on the
discuss list. I will not be responding to emails such as the one
quoted above, lobbying by private phone call, or the
like. Again, if you have complaints about the way the TSC
is being run please discuss those on the discuss or tsc lists.

Summary: It is clear that there is additional evolution that is
needed for the SAL. No one is arguing otherwise. The new
project/repository issue is really about concern that commits
won't be fair (again, both Glenn and Guru raised this); however
there is no evidence that this is or will be the case and in any
event is not a technical issue and as such is out of scope for
the TSC. Finally, the timing issue is largely a commercial issue
(the need to port applications) and also has been argued on both
sides by the same people and as such I consider those arguments
largely moot; there is a real need to get the consortium going
(hence the date) but that is a wholly different argument.

--dmm


Re: my perspective on where we are with the single controller code base issue

David Meyer <dmm@...>
 

BTW, it has been pointed out that I mis-attributed the IOCTL idea to
Chris. That was my mistake. That said, the point I was making still
holds, namely, that there exist some ideas (and there will be more) to
deal with the near term deficiencies, perceived or otherwise, with the
SAL.

--dmm

On Tue, May 14, 2013 at 9:09 AM, David Meyer <dmm@...> wrote:
All,

As you know today (05.14.2013) was the day on which I wanted to
have the single controller code base issue resolved. What I had
said is that if we couldn't get the projects to agree on a way
forward that we as a TSC would vote on the issue. In the mean
time we have reached general consensus that the Dixon-Erickson
OpenDaylight Merged Controller Proposal (DE) (see
https://wiki.opendaylight.org/view/Dixon-Erickson_OpenDaylight_Merged_Controller_Proposal).
I want to be very clear here that that plan is distinct from what
is being called Proposed Dixon-Erickson Execution Plan (see
https://wiki.opendaylight.org/view/Proposed_Dixon-Erickson_Execution_Plan). So
from this perspective the community has come together over this
general direction. This functionally obviates the need for a
direct vote.

There have been quite a few concerns raised both publicly and to
me directly in private email. I'd like to review those here and
provide my perspective.

(i). The SAL

It is generally agreed that there is work left to be done on the
SAL, and that there may be instances in which, (in the near term)
we need a mechanism to provide a kind of "SAL bypass". Chris'
IOCTL proposal is one such idea. What I want to point out here is
the the ODP is evolving and as such we expect the architecture to
not not improve technically but converge on the needed
functionality/generality over time. This is a completely natural
state of affairs for any software project. The summary is that we
can provide short term mechanisms that bridge any perceived or
real functionality gaps in the SAL (again, Chris' IOCTL idea
might be one such mechanism). So while the OSCP folks have
argued pretty strongly against the SAL (both publicly and
privately), the DE proposal endorses the SAL concept and the
OpenDaylight Controller folks consider the SAL to be a
fundamental architectural construct. That said, evolution of the
SAL (be it the model driven approach, bypass, etc) is an issue
for folks who are writing SAL applications (committing code) to
resolve.

(ii). New Project/Repository

This issue is really about the fairness of commits to the
controller code base. This was stated explicitly to me privately
and publicly by Glenn Ricart and Guru Parulkar on the discuss
list. On the other hand, a simple majority of TSC members (and
many in the community) have expressed the opinion that they would
prefer moving forward with the plan outlined in the DE-proposal,
namely start with the OpenDaylight controller and evolve that as
needed. I will note here that there is no objective evidence that
there is a fairness issue with commits to any candiate code base
(it would hard for that to be the case in any event as we haven't
had the chance to really get going). Finally, since this is
largely a political issue it is outside of the scope of the TSC
and should be "policed" by the community.

As an aside, I will also note here that several community
members have expressed concern that the new project
approach is quite expensive and has little benefit beyond
the political/perception issue mentioned above.


(iii) Timing

The timing issue, namely that there is (is not) a rush to get the
ODP project up and running is one that has also been raised both
publicly and privately. I have been told (again, both publicly
and privately) by the OSCP (BSN) folks that they have time
pressure to port their applications to the ODP controller. That
is a principle rationale behind the Layered API proposal
(https://wiki.opendaylight.org/view/Layered_API_Merged_Controller_Proposal).
In addition, the same team is also arguing that we are in no rush and
in fact any date for resolving the controller issue is not only
artificial but damaging to the community; this exact sentiment was
contained in a private communication from Rob Sherwood to me dated
Tue, May 14, 2013 at 1:38 AM. In the spirit of transparency I am copying the
relevant text from that email here:

"I know that in your heart you believe what you're doing is the
right thing for the community, and that's why I've held off
making a stink, but as chair, I'm not sure what you're doing is
in terms of pushing hard on this artificial deadline (that you
said originally was not set in stone but now it is) or being
opaque in terms of the actual process is really helping the
community." -- Rob Sherwood to dmm on Tue, May 14, 2013 at 1:38
AM.

(this text of course also contains criticisms of me in my role
as chair to which I will return but I want to focus here on the
timing issue).

The summary here is that it has been argued by the OSCP team that
we accept their proposal
(https://wiki.opendaylight.org/view/File:LayeredAPIProposal.pdf)
because there is time pressure to port applications while at the
same time it is being argued that any time frame is damaging,
artificial, or worse. On the other hand, a simple majority of the
TSC have stated publicly (on the discuss list) that resolving the
controller code base issue of primary importance and they would
like to move forward with an interpretation of DE that starts
with the existing OpenDaylight controller code base.

It is clear from these inconsistencies that the timing issue is
largely a non-issue for the ODP community at large; in addition
there is clear benefit to moving forward with the DE approach now. One
might also note here that we've made very little progress over
the last many weeks and it is time to start, now.

(iv). Finally, if anyone has problems with me personally and/or the
way TSC is being run please air those publicly on the
discuss list. I will not be responding to emails such as the one
quoted above, lobbying by private phone call, or the
like. Again, if you have complaints about the way the TSC
is being run please discuss those on the discuss or tsc lists.

Summary: It is clear that there is additional evolution that is
needed for the SAL. No one is arguing otherwise. The new
project/repository issue is really about concern that commits
won't be fair (again, both Glenn and Guru raised this); however
there is no evidence that this is or will be the case and in any
event is not a technical issue and as such is out of scope for
the TSC. Finally, the timing issue is largely a commercial issue
(the need to port applications) and also has been argued on both
sides by the same people and as such I consider those arguments
largely moot; there is a real need to get the consortium going
(hence the date) but that is a wholly different argument.

--dmm


Changes to the OpenDaylight TSC Meeting Invitation

Phil Robb
 

Hello Everyone:

To provide a clean change to the TSC meeting invitation as we move from 1 hour to 2 hour meetings, I will be canceling the original meeting, and then sending a new invitation for the 2 hour meetings going forward. If you receive a cancellation notice, but do not receive a new invitation, please make sure you are subscribed to the TSC mailing list.

Phil.

OpenDaylight TSC Meeting

OpenDaylight Technical Steering Committee meeting.

Please hold this time for the weekly OpenDaylight TSC meeting.
This invitation will be updated within the next 2 days with WebEx conference information.

When
Thu May 16, 2013 11am – 12pm Mountain Time
Where
TBD (map)
Who
(Guest list is too large to display)


Canceled Event: OpenDaylight TSC Meeting @ Weekly from 11am to 12pm on Thursday from Thu Apr 18 to Thu May 30 (probb@linuxfoundation.org)

Phil Robb
 

This event has been canceled and removed from your calendar.

OpenDaylight TSC Meeting

OpenDaylight Technical Steering Committee meeting.

Please hold this time for the weekly OpenDaylight TSC meeting.
This invitation will be updated within the next 2 days with WebEx conference information.

When
Weekly from 11am to 12pm on Thursday from Thu Apr 18 to Thu May 30 Mountain Time
Where
TBD (map)
Calendar
probb@...
Who
(Guest list is too large to display)

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.


Invitation: OpenDaylight TSC Meeting @ Weekly from 11am to 1pm on Thursday (probb@linuxfoundation.org)

Phil Robb
 

OpenDaylight TSC Meeting

Meeting URL: https://meetings.webex.com/collabs/meetings/join?uuid=MA3SRND964PIX06V2LS3SXX3RE-9VIB

Access Information
Meeting number: 194 548 370
Meeting password: This meeting does not require a password.

Audio Connection
1-855-244-8681 Call-in toll-free number (US/Canada)
1-650-479-3207 Call-in toll number (US/Canada)
Access code: 194 548 370

When
Weekly from 11am to 1pm on Thursday Mountain Time
Where
+1 650-479-3207 - Additional connection information in event description (map)
Calendar
probb@...
Who
Philip Robb - organizer
tsc@...

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.


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
Chris. That was my mistake. That said, the point I was making still
holds, namely, that there exist some ideas (and there will be more) to
deal with the near term deficiencies, perceived or otherwise, with the
SAL.

--dmm


On Tue, May 14, 2013 at 9:09 AM, David Meyer <dmm@...> wrote:
> All,
>
> As you know today (05.14.2013) was the day on which I wanted to
> have the single controller code base issue resolved. What I had
> said is that if we couldn't get the projects to agree on a way
> forward that we as a TSC would vote on the issue. In the mean
> time we have reached general consensus that the Dixon-Erickson
> OpenDaylight Merged Controller Proposal (DE) (see
> https://wiki.opendaylight.org/view/Dixon-Erickson_OpenDaylight_Merged_Controller_Proposal).
> I want to be very clear here that that plan is distinct from what
> is being called Proposed Dixon-Erickson Execution Plan (see
> https://wiki.opendaylight.org/view/Proposed_Dixon-Erickson_Execution_Plan). So
> from this perspective the community has come together over this
> general direction. This functionally obviates the need for a
> direct vote.
>
> There have been quite a few concerns raised both publicly and to
> me directly in private email. I'd like to review those here and
> provide my perspective.
>
> (i). The SAL
>
> It is generally agreed that there is work left to be done on the
> SAL, and that there may be instances in which, (in the near term)
> we need a mechanism to provide a kind of "SAL bypass". Chris'
> IOCTL proposal is one such idea. What I want to point out here is
> the the ODP is evolving and as such we expect the architecture to
> not not improve technically but converge on the needed
> functionality/generality over time. This is a completely natural
> state of affairs for any software project. The summary is that we
> can provide short term mechanisms that bridge any perceived or
> real functionality gaps in the SAL (again, Chris' IOCTL idea
> might be one such mechanism).  So while the OSCP folks have
> argued pretty strongly against the SAL (both publicly and
> privately), the DE proposal endorses the SAL concept and the
> OpenDaylight Controller folks consider the SAL to be a
> fundamental architectural construct. That said, evolution of the
> SAL (be it the model driven approach, bypass, etc) is an issue
> for folks who are writing SAL applications (committing code) to
> resolve.
>
> (ii). New Project/Repository
>
> This issue is really about the fairness of commits to the
> controller code base. This was stated explicitly to me privately
> and publicly by Glenn Ricart and Guru Parulkar on the discuss
> list. On the other hand, a simple majority of TSC members (and
> many in the community) have expressed the opinion that they would
> prefer moving forward with the plan outlined in the DE-proposal,
> namely start with the OpenDaylight controller and evolve that as
> needed. I will note here that there is no objective evidence that
> there is a fairness issue with commits to any candiate code base
> (it would hard for that to be the case in any event as we haven't
> had the chance to really get going). Finally, since this is
> largely a political issue it is outside of the scope of the TSC
> and should be "policed" by the community.
>
> As an aside, I will also note here that several community
> members have expressed concern that the new project
> approach is quite expensive and has little benefit beyond
> the political/perception issue mentioned above.
>
>
> (iii)  Timing
>
> The timing issue, namely that there is (is not) a rush to get the
> ODP project up and running is one that has also been raised both
> publicly and privately. I have been told (again, both publicly
> and privately) by the OSCP (BSN) folks that they have time
> pressure to port their applications to the ODP controller. That
> is a principle rationale behind the Layered API proposal
> (https://wiki.opendaylight.org/view/Layered_API_Merged_Controller_Proposal).
> In addition, the same team is also arguing that  we are in no rush and
> in fact any date for resolving the controller issue is not only
> artificial but damaging to the community; this exact sentiment was
> contained in a private communication from Rob Sherwood to me dated
> Tue, May 14, 2013 at 1:38 AM. In the spirit of transparency I am copying the
> relevant text from that email here:
>
> "I know that in your heart you believe what you're doing is the
>  right thing for the community, and that's why I've held off
>  making a stink, but as chair, I'm not sure what you're doing is
>  in terms of pushing hard on this artificial deadline (that you
>  said originally was not set in stone but now it is) or being
>  opaque in terms of the actual process is really helping the
>  community."  -- Rob Sherwood to dmm on Tue, May 14, 2013 at 1:38
>  AM.
>
>  (this text of course also contains criticisms of me in my role
>  as chair to which I will return but I want to focus here on the
>  timing issue).
>
> The summary here is that it has been argued by the OSCP team that
> we accept their proposal
> (https://wiki.opendaylight.org/view/File:LayeredAPIProposal.pdf)
> because there is time pressure to port applications while at the
> same time it is being argued that any time frame is damaging,
> artificial, or worse. On the other hand, a simple majority of the
> TSC have stated publicly (on the discuss list) that resolving the
> controller code base issue of primary importance and they would
> like to move forward with an interpretation of DE that starts
> with the existing OpenDaylight controller code base.
>
> It is clear from these inconsistencies that the timing issue is
> largely a non-issue for the ODP community at large; in addition
> there is clear benefit to moving forward with the DE approach now. One
> might also note here that we've made very little progress over
> the last many weeks and it is time to start, now.
>
> (iv).  Finally, if anyone has problems with me personally and/or the
> way TSC is being run please air those publicly on the
> discuss list. I will not be responding to emails such as the one
> quoted above, lobbying by private phone call, or the
> like. Again, if you have complaints about the way the TSC
> is being run please discuss those on the discuss or tsc lists.
>
> Summary: It is clear that there is additional evolution that is
> needed for the SAL. No one is arguing otherwise. The new
> project/repository issue is really about concern that commits
> won't be fair (again, both Glenn and Guru raised this); however
> there is no evidence that this is or will be the case and in any
> event is not a technical issue and as such is out of scope for
> the TSC. Finally, the timing issue is largely a commercial issue
> (the need to port applications) and also has been argued on both
> sides by the same people and as such I consider those arguments
> largely moot; there is a real need to get the consortium going
> (hence the date) but that is a wholly different argument.
>
> --dmm
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



--
---------------------------------------------------------
R. Kyle Forster
+1 (415) 990-2670 (m)
kyle.forster@...


on the BSN reset

David Meyer <dmm@...>
 

I'm going to put the new repository question (as outlined by Kyle
Forester in an email of Wed, May 15, 2013 at 7:04 AM) to a voice vote
on the TSC call on Thursday. The options are:

[] Dixion-Erickson proposal with a new repository with initial
committers TBD (BSN proposal)

[] Dixion-Erickson proposal starting with the OpenDaylight controller code base

[] Abstain

This will be the first order of business on Thursday.

--dmm


Re: my perspective on where we are with the single controller code base issue

David Meyer <dmm@...>
 

Kyle/all,

On Wed, May 15, 2013 at 7:04 AM, Kyle Forster
<kyle.forster@...> wrote:
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.
In further considering the below, please find my comments in line.


-------

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 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.
Please provide evidence to support these very serious accusations. IMO
to begin with such an assumption/accusation is very damaging to the
trust relationships that are core to a well functioning open source
project. In fact these assertions/accusations create exactly the
environment you claim to want to prevent.


-------

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.
Again, please provide evidence of any "tyranny". These are serious
accusations that require supporting evidence. The assertion that
"issue is very real in other well known SDN open source projects" is
simply not sufficient.

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.
After thinking about this for a few hours I went back and re-read the
TSC charter for guidance. The following points are relevant to this
thread:

(i). Governance

Section 5 of the TSC charter
(http://www.opendaylight.org/project/tsc/charter) outlines the TSC's
responsibility. In particular, it is not scope for the TSC to dictate
the creation of any project. Specifically, "the TSC is responsible for
simultaneous release dates, release quality standards, technical best
practices (including the Development Process), monitoring technical
progress, mediating technical conflicts between Committers and project
leads, and organizing inter-project collaboration. The TSC will define
ODP’s release vehicles." In summary, it is out of scope for the TSC to
dictate the creation of any ODP project.

(ii). Committers

Section 7 of the TSC charter covers committers. Germain here is that
"Initial projects that form ODP’s base may designate Committers.". In
addition, "Committers select and vote for new Committers, subject to
TSC approval.".

What is clear from this section is that the TSC does not have the
authority under our governance model to appoint committers to any
project. Note that any appointment of committers by the TSC also
violates the "meritocracy principle" that is core to any open source
project.

Summary: As I said in section (ii). below (New Project/Repository) and
reassert here, "this is largely a political issue and as such is
outside of the scope of the TSC". And while I initially thought a vote
on this topic might resolve the problem upon further reflection and
study I see that, as I originally stated, the creation of a New
Project is out of scope for the TSC. Further, the TSC has no
jurisdiction to appoint committers and in any event such an action
would violate core open source principles.

Finally, the ODP community is of course free to start any new project
which will be subject to the ODP lifecycle. However, the creation of a
new project and/or the appointment of committers is out of scope for
the TSC (and in any event would violate core open source values).

--dmm




-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
Chris. That was my mistake. That said, the point I was making still
holds, namely, that there exist some ideas (and there will be more) to
deal with the near term deficiencies, perceived or otherwise, with the
SAL.

--dmm


On Tue, May 14, 2013 at 9:09 AM, David Meyer <dmm@...> wrote:
All,

As you know today (05.14.2013) was the day on which I wanted to
have the single controller code base issue resolved. What I had
said is that if we couldn't get the projects to agree on a way
forward that we as a TSC would vote on the issue. In the mean
time we have reached general consensus that the Dixon-Erickson
OpenDaylight Merged Controller Proposal (DE) (see

https://wiki.opendaylight.org/view/Dixon-Erickson_OpenDaylight_Merged_Controller_Proposal).
I want to be very clear here that that plan is distinct from what
is being called Proposed Dixon-Erickson Execution Plan (see

https://wiki.opendaylight.org/view/Proposed_Dixon-Erickson_Execution_Plan).
So
from this perspective the community has come together over this
general direction. This functionally obviates the need for a
direct vote.

There have been quite a few concerns raised both publicly and to
me directly in private email. I'd like to review those here and
provide my perspective.

(i). The SAL

It is generally agreed that there is work left to be done on the
SAL, and that there may be instances in which, (in the near term)
we need a mechanism to provide a kind of "SAL bypass". Chris'
IOCTL proposal is one such idea. What I want to point out here is
the the ODP is evolving and as such we expect the architecture to
not not improve technically but converge on the needed
functionality/generality over time. This is a completely natural
state of affairs for any software project. The summary is that we
can provide short term mechanisms that bridge any perceived or
real functionality gaps in the SAL (again, Chris' IOCTL idea
might be one such mechanism). So while the OSCP folks have
argued pretty strongly against the SAL (both publicly and
privately), the DE proposal endorses the SAL concept and the
OpenDaylight Controller folks consider the SAL to be a
fundamental architectural construct. That said, evolution of the
SAL (be it the model driven approach, bypass, etc) is an issue
for folks who are writing SAL applications (committing code) to
resolve.

(ii). New Project/Repository

This issue is really about the fairness of commits to the
controller code base. This was stated explicitly to me privately
and publicly by Glenn Ricart and Guru Parulkar on the discuss
list. On the other hand, a simple majority of TSC members (and
many in the community) have expressed the opinion that they would
prefer moving forward with the plan outlined in the DE-proposal,
namely start with the OpenDaylight controller and evolve that as
needed. I will note here that there is no objective evidence that
there is a fairness issue with commits to any candiate code base
(it would hard for that to be the case in any event as we haven't
had the chance to really get going). Finally, since this is
largely a political issue it is outside of the scope of the TSC
and should be "policed" by the community.

As an aside, I will also note here that several community
members have expressed concern that the new project
approach is quite expensive and has little benefit beyond
the political/perception issue mentioned above.


(iii) Timing

The timing issue, namely that there is (is not) a rush to get the
ODP project up and running is one that has also been raised both
publicly and privately. I have been told (again, both publicly
and privately) by the OSCP (BSN) folks that they have time
pressure to port their applications to the ODP controller. That
is a principle rationale behind the Layered API proposal

(https://wiki.opendaylight.org/view/Layered_API_Merged_Controller_Proposal).
In addition, the same team is also arguing that we are in no rush and
in fact any date for resolving the controller issue is not only
artificial but damaging to the community; this exact sentiment was
contained in a private communication from Rob Sherwood to me dated
Tue, May 14, 2013 at 1:38 AM. In the spirit of transparency I am copying
the
relevant text from that email here:

"I know that in your heart you believe what you're doing is the
right thing for the community, and that's why I've held off
making a stink, but as chair, I'm not sure what you're doing is
in terms of pushing hard on this artificial deadline (that you
said originally was not set in stone but now it is) or being
opaque in terms of the actual process is really helping the
community." -- Rob Sherwood to dmm on Tue, May 14, 2013 at 1:38
AM.

(this text of course also contains criticisms of me in my role
as chair to which I will return but I want to focus here on the
timing issue).

The summary here is that it has been argued by the OSCP team that
we accept their proposal
(https://wiki.opendaylight.org/view/File:LayeredAPIProposal.pdf)
because there is time pressure to port applications while at the
same time it is being argued that any time frame is damaging,
artificial, or worse. On the other hand, a simple majority of the
TSC have stated publicly (on the discuss list) that resolving the
controller code base issue of primary importance and they would
like to move forward with an interpretation of DE that starts
with the existing OpenDaylight controller code base.

It is clear from these inconsistencies that the timing issue is
largely a non-issue for the ODP community at large; in addition
there is clear benefit to moving forward with the DE approach now. One
might also note here that we've made very little progress over
the last many weeks and it is time to start, now.

(iv). Finally, if anyone has problems with me personally and/or the
way TSC is being run please air those publicly on the
discuss list. I will not be responding to emails such as the one
quoted above, lobbying by private phone call, or the
like. Again, if you have complaints about the way the TSC
is being run please discuss those on the discuss or tsc lists.

Summary: It is clear that there is additional evolution that is
needed for the SAL. No one is arguing otherwise. The new
project/repository issue is really about concern that commits
won't be fair (again, both Glenn and Guru raised this); however
there is no evidence that this is or will be the case and in any
event is not a technical issue and as such is out of scope for
the TSC. Finally, the timing issue is largely a commercial issue
(the need to port applications) and also has been argued on both
sides by the same people and as such I consider those arguments
largely moot; there is a real need to get the consortium going
(hence the date) but that is a wholly different argument.

--dmm
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



--
---------------------------------------------------------
R. Kyle Forster
+1 (415) 990-2670 (m)
kyle.forster@...


Re: my perspective on where we are with the single controller code base issue

Kyle Forster
 

David / all -

I'd be happy to provide some stats on what a "tyranny of the majority
committers" looks like from outside -- the asymmetric effort required
to add interfaces to one project versus the other -- but let me do
that on a separate thread in order to keep this one moving forward.
I'm still optimistic that we can spot these patterns that we've seen
in other SDN projects and protect against them in Daylight projects.

In terms of next steps, if I read the charter notes you posted
correctly, they would imply that committers and new project proposals
are not TSC decisions but rather project-level decisions. Sounds
healthy.

I'd suggest then (to the community writ large) that David and Colin
propose a new 'merged controller' project with the two of them as the
leads and we follow the design and process route they've advocated on
list for that project.

For developers who need to build on the prod Floodlight components
while we're porting them to the SAL, there is a repo for that. We're
in that boat with the D-E design already.

For developers who need to build on the SAL while it is in flight to
get ready for the prod Floodlight components, there is a repo for
that. We're in that boat with the D-E design already.

For developers who need to build on a controller that starts empty but
most resembles the end design state over the next few months, the new
D-E project repo would fit that purpose. Their pushing will create
natural demand pull for prioritizing the porting of SAL and Floodlight
implementations in to the D-E end state.

I'd argue this puts the power where it should be -- in the hands of
developers writing apps along the D-E design -- and gives all of us
in the controller-oriented projects a *lot* of incentive to serve them
well.

(It also gives David and Colin much deserved independent seats on the
TSC. David was the author of Beacon, the codebase that spawned both
implementations. It feels like the 'right thing' to do that he have a
formal role there as well as in the community at large from his sweat
if not his $$$.)

-K

On May 15, 2013, at 8:33 AM, David Meyer <dmm@...> wrote:

Kyle/all,

On Wed, May 15, 2013 at 7:04 AM, Kyle Forster
<kyle.forster@...> wrote:
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.
In further considering the below, please find my comments in line.


-------

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 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.
Please provide evidence to support these very serious accusations. IMO
to begin with such an assumption/accusation is very damaging to the
trust relationships that are core to a well functioning open source
project. In fact these assertions/accusations create exactly the
environment you claim to want to prevent.


-------

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.
Again, please provide evidence of any "tyranny". These are serious
accusations that require supporting evidence. The assertion that
"issue is very real in other well known SDN open source projects" is
simply not sufficient.

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.
After thinking about this for a few hours I went back and re-read the
TSC charter for guidance. The following points are relevant to this
thread:

(i). Governance

Section 5 of the TSC charter
(http://www.opendaylight.org/project/tsc/charter) outlines the TSC's
responsibility. In particular, it is not scope for the TSC to dictate
the creation of any project. Specifically, "the TSC is responsible for
simultaneous release dates, release quality standards, technical best
practices (including the Development Process), monitoring technical
progress, mediating technical conflicts between Committers and project
leads, and organizing inter-project collaboration. The TSC will define
ODP’s release vehicles." In summary, it is out of scope for the TSC to
dictate the creation of any ODP project.

(ii). Committers

Section 7 of the TSC charter covers committers. Germain here is that
"Initial projects that form ODP’s base may designate Committers.". In
addition, "Committers select and vote for new Committers, subject to
TSC approval.".

What is clear from this section is that the TSC does not have the
authority under our governance model to appoint committers to any
project. Note that any appointment of committers by the TSC also
violates the "meritocracy principle" that is core to any open source
project.

Summary: As I said in section (ii). below (New Project/Repository) and
reassert here, "this is largely a political issue and as such is
outside of the scope of the TSC". And while I initially thought a vote
on this topic might resolve the problem upon further reflection and
study I see that, as I originally stated, the creation of a New
Project is out of scope for the TSC. Further, the TSC has no
jurisdiction to appoint committers and in any event such an action
would violate core open source principles.

Finally, the ODP community is of course free to start any new project
which will be subject to the ODP lifecycle. However, the creation of a
new project and/or the appointment of committers is out of scope for
the TSC (and in any event would violate core open source values).

--dmm




-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
Chris. That was my mistake. That said, the point I was making still
holds, namely, that there exist some ideas (and there will be more) to
deal with the near term deficiencies, perceived or otherwise, with the
SAL.

--dmm


On Tue, May 14, 2013 at 9:09 AM, David Meyer <dmm@...> wrote:
All,

As you know today (05.14.2013) was the day on which I wanted to
have the single controller code base issue resolved. What I had
said is that if we couldn't get the projects to agree on a way
forward that we as a TSC would vote on the issue. In the mean
time we have reached general consensus that the Dixon-Erickson
OpenDaylight Merged Controller Proposal (DE) (see

https://wiki.opendaylight.org/view/Dixon-Erickson_OpenDaylight_Merged_Controller_Proposal).
I want to be very clear here that that plan is distinct from what
is being called Proposed Dixon-Erickson Execution Plan (see

https://wiki.opendaylight.org/view/Proposed_Dixon-Erickson_Execution_Plan).
So
from this perspective the community has come together over this
general direction. This functionally obviates the need for a
direct vote.

There have been quite a few concerns raised both publicly and to
me directly in private email. I'd like to review those here and
provide my perspective.

(i). The SAL

It is generally agreed that there is work left to be done on the
SAL, and that there may be instances in which, (in the near term)
we need a mechanism to provide a kind of "SAL bypass". Chris'
IOCTL proposal is one such idea. What I want to point out here is
the the ODP is evolving and as such we expect the architecture to
not not improve technically but converge on the needed
functionality/generality over time. This is a completely natural
state of affairs for any software project. The summary is that we
can provide short term mechanisms that bridge any perceived or
real functionality gaps in the SAL (again, Chris' IOCTL idea
might be one such mechanism). So while the OSCP folks have
argued pretty strongly against the SAL (both publicly and
privately), the DE proposal endorses the SAL concept and the
OpenDaylight Controller folks consider the SAL to be a
fundamental architectural construct. That said, evolution of the
SAL (be it the model driven approach, bypass, etc) is an issue
for folks who are writing SAL applications (committing code) to
resolve.

(ii). New Project/Repository

This issue is really about the fairness of commits to the
controller code base. This was stated explicitly to me privately
and publicly by Glenn Ricart and Guru Parulkar on the discuss
list. On the other hand, a simple majority of TSC members (and
many in the community) have expressed the opinion that they would
prefer moving forward with the plan outlined in the DE-proposal,
namely start with the OpenDaylight controller and evolve that as
needed. I will note here that there is no objective evidence that
there is a fairness issue with commits to any candiate code base
(it would hard for that to be the case in any event as we haven't
had the chance to really get going). Finally, since this is
largely a political issue it is outside of the scope of the TSC
and should be "policed" by the community.

As an aside, I will also note here that several community
members have expressed concern that the new project
approach is quite expensive and has little benefit beyond
the political/perception issue mentioned above.


(iii) Timing

The timing issue, namely that there is (is not) a rush to get the
ODP project up and running is one that has also been raised both
publicly and privately. I have been told (again, both publicly
and privately) by the OSCP (BSN) folks that they have time
pressure to port their applications to the ODP controller. That
is a principle rationale behind the Layered API proposal

(https://wiki.opendaylight.org/view/Layered_API_Merged_Controller_Proposal).
In addition, the same team is also arguing that we are in no rush and
in fact any date for resolving the controller issue is not only
artificial but damaging to the community; this exact sentiment was
contained in a private communication from Rob Sherwood to me dated
Tue, May 14, 2013 at 1:38 AM. In the spirit of transparency I am copying
the
relevant text from that email here:

"I know that in your heart you believe what you're doing is the
right thing for the community, and that's why I've held off
making a stink, but as chair, I'm not sure what you're doing is
in terms of pushing hard on this artificial deadline (that you
said originally was not set in stone but now it is) or being
opaque in terms of the actual process is really helping the
community." -- Rob Sherwood to dmm on Tue, May 14, 2013 at 1:38
AM.

(this text of course also contains criticisms of me in my role
as chair to which I will return but I want to focus here on the
timing issue).

The summary here is that it has been argued by the OSCP team that
we accept their proposal
(https://wiki.opendaylight.org/view/File:LayeredAPIProposal.pdf)
because there is time pressure to port applications while at the
same time it is being argued that any time frame is damaging,
artificial, or worse. On the other hand, a simple majority of the
TSC have stated publicly (on the discuss list) that resolving the
controller code base issue of primary importance and they would
like to move forward with an interpretation of DE that starts
with the existing OpenDaylight controller code base.

It is clear from these inconsistencies that the timing issue is
largely a non-issue for the ODP community at large; in addition
there is clear benefit to moving forward with the DE approach now. One
might also note here that we've made very little progress over
the last many weeks and it is time to start, now.

(iv). Finally, if anyone has problems with me personally and/or the
way TSC is being run please air those publicly on the
discuss list. I will not be responding to emails such as the one
quoted above, lobbying by private phone call, or the
like. Again, if you have complaints about the way the TSC
is being run please discuss those on the discuss or tsc lists.

Summary: It is clear that there is additional evolution that is
needed for the SAL. No one is arguing otherwise. The new
project/repository issue is really about concern that commits
won't be fair (again, both Glenn and Guru raised this); however
there is no evidence that this is or will be the case and in any
event is not a technical issue and as such is out of scope for
the TSC. Finally, the timing issue is largely a commercial issue
(the need to port applications) and also has been argued on both
sides by the same people and as such I consider those arguments
largely moot; there is a real need to get the consortium going
(hence the date) but that is a wholly different argument.

--dmm
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



--
---------------------------------------------------------
R. Kyle Forster
+1 (415) 990-2670 (m)
kyle.forster@...


Re: on the BSN reset

Christopher Price <christopher.price@...>
 

Hi David & All,

Maybe I missed something but I had understood the idea to begin with a new
repository was proposed by David when the DE proposal was drafted, Colin
was of the opinion to start with the controller code. This vote is to
determine the method of approach based on that I assume.

I didn't see our colleagues from BSN were promoting anything additional
except to raise the question of committers which I don't think is the same
decision. Will this also be a topic for discussion/decision tomorrow?

In any case we will of course discuss internally in prep for Thursday.

/ Chris

On 5/15/13 12:06 AM, "David Meyer" <dmm@...> wrote:

I'm going to put the new repository question (as outlined by Kyle
Forester in an email of Wed, May 15, 2013 at 7:04 AM) to a voice vote
on the TSC call on Thursday. The options are:

[] Dixion-Erickson proposal with a new repository with initial
committers TBD (BSN proposal)

[] Dixion-Erickson proposal starting with the OpenDaylight controller
code base

[] Abstain

This will be the first order of business on Thursday.

--dmm
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


Re: [OpenDaylight Discuss] my perspective on where we are with the single controller code base issue

Chris Wright <chrisw@...>
 

* Kyle Forster (kyle.forster@...) wrote:
-------
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.
This is a community effort. The whole premise of Opendaylight is
founded on that tenant. We have project lifecycle and charter language
to protect this. What you are identifying is a lack of trust.

Communities are _built_ on trust.

-------
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.
Coming up w/ meaningful numbers here is difficult.

--------

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.
The TSC does not own this decision. The community does.


Re: [OpenDaylight Discuss] my perspective on where we are with the single controller code base issue

Chris Wright <chrisw@...>
 

* David Meyer (dmm@...) wrote:
What is clear from this section is that the TSC does not have the
authority under our governance model to appoint committers to any
project. Note that any appointment of committers by the TSC also
violates the "meritocracy principle" that is core to any open source
project.
I absolutely agree here. It is fundamental to the functioning of our
community.

Summary: As I said in section (ii). below (New Project/Repository) and
reassert here, "this is largely a political issue and as such is
outside of the scope of the TSC". And while I initially thought a vote
on this topic might resolve the problem upon further reflection and
study I see that, as I originally stated, the creation of a New
Project is out of scope for the TSC. Further, the TSC has no
jurisdiction to appoint committers and in any event such an action
would violate core open source principles.

Finally, the ODP community is of course free to start any new project
which will be subject to the ODP lifecycle. However, the creation of a
new project and/or the appointment of committers is out of scope for
the TSC (and in any event would violate core open source values).
That's right. The path forward for "DE plan in new repo" is a project
proposal which, assuming it met the criteria, would graduate to an
incubation project.

That is not TSC, that is community driven. The germane question to the
community here is whether that's the right path forward for DE plan.

thanks,
-chris


Re: on the BSN reset

Chris Wright <chrisw@...>
 

* David Meyer (dmm@...) wrote:
I'm going to put the new repository question (as outlined by Kyle
Forester in an email of Wed, May 15, 2013 at 7:04 AM) to a voice vote
on the TSC call on Thursday. The options are:

[] Dixion-Erickson proposal with a new repository with initial
committers TBD (BSN proposal)

[] Dixion-Erickson proposal starting with the OpenDaylight controller code base

[] Abstain
What would we do with the outcome of this? I think it's only
informational.


Re: on the BSN reset

David Meyer <dmm@...>
 

On Wed, May 15, 2013 at 7:03 PM, Chris Wright <chrisw@...> wrote:
* David Meyer (dmm@...) wrote:
I'm going to put the new repository question (as outlined by Kyle
Forester in an email of Wed, May 15, 2013 at 7:04 AM) to a voice vote
on the TSC call on Thursday. The options are:

[] Dixion-Erickson proposal with a new repository with initial
committers TBD (BSN proposal)

[] Dixion-Erickson proposal starting with the OpenDaylight controller code base

[] Abstain
What would we do with the outcome of this? I think it's only
informational.
Yes. This is why I sent the email outlining what the TSC charter
allowed (there's a bit of a ordering problem here; see my next email).
Briefly as I mentioned creation of a new project and/or appointing
committers is out of scope for the TSC.

--dmm


Re: my perspective on where we are with the single controller code base issue

Chris Wright <chrisw@...>
 

* Kyle Forster (kyle.forster@...) wrote:
In terms of next steps, if I read the charter notes you posted
correctly, they would imply that committers and new project proposals
are not TSC decisions but rather project-level decisions. Sounds
healthy.
Indeed, that's the idea! ;)

<snip "we've got a repo for that">

(It also gives David and Colin much deserved independent seats on the
TSC.
Just a formality, but it actually doesn't. This would require:

- project proposal
- creation to incubation
- committers elect a project lead
- promotion to core
- the project lead is now on TSC

On the other hand, we will have a few community representative seats on
the TSC as well. So it's not entirely unreasonable to see both David on
Colin sit on the TSC (recall, that a TSC seat isn't all that magical ;)

David was the author of Beacon, the codebase that spawned both
implementations. It feels like the 'right thing' to do that he have a
formal role there as well as in the community at large from his sweat
if not his $$$.)
David and Colin are fantastic assets to this community, no doubt!

thanks,
-chris


Re: on the BSN reset

Chris Wright <chrisw@...>
 

* David Meyer (dmm@...) wrote:
On Wed, May 15, 2013 at 7:03 PM, Chris Wright <chrisw@...> wrote:
* David Meyer (dmm@...) wrote:
I'm going to put the new repository question (as outlined by Kyle
Forester in an email of Wed, May 15, 2013 at 7:04 AM) to a voice vote
on the TSC call on Thursday. The options are:

[] Dixion-Erickson proposal with a new repository with initial
committers TBD (BSN proposal)

[] Dixion-Erickson proposal starting with the OpenDaylight controller code base

[] Abstain
What would we do with the outcome of this? I think it's only
informational.
Yes. This is why I sent the email outlining what the TSC charter
allowed (there's a bit of a ordering problem here; see my next email).
Briefly as I mentioned creation of a new project and/or appointing
committers is out of scope for the TSC.
Ah, got it...busy morning catching up w/ email ;)


Re: my perspective on where we are with the single controller code base issue

Colin Dixon <ckd@...>
 

I just want to publicly say that I am not in favor of the creation of a third repository to house the merged code. For those of you who have been reading this list, that won't be news, but I wanted to make it as unambiguous as possible.

My suggestion that *if a third repository were to exist for the merge*, then David Erickson and myself should be the only two committers to begin with was intended to point out what I thought was a truly bad idea of assigning committers to companies based on the currently checked in lines of code in the two current repositories. I still do think that's the only logical way that a third repository could exist, but that should not be misconstrued in any way as a statement in support of creating third repository.

--Colin

tsc-bounces@... wrote on 05/15/2013 09:54:50 AM:
> From: Kyle Forster <kyle.forster@...>

> To: David Meyer <dmm@...>
> Cc: "tsc@..." <tsc@...>,
> "discuss@..." <discuss@...>

> Date: 05/15/2013 11:43 AM
> Subject: Re: [OpenDaylight TSC] my perspective on where we are with
> the single controller code base issue

> Sent by: tsc-bounces@...
>
> David / all -
>
> I'd be happy to provide some stats on what a "tyranny of the majority
> committers" looks like from outside -- the asymmetric effort required
> to add interfaces to one project versus the other -- but let me do
> that on a separate thread in order to keep this one moving forward.
> I'm still optimistic that we can spot these patterns that we've seen
> in other SDN projects and protect against them in Daylight projects.
>
> In terms of next steps, if I read the charter notes you posted
> correctly, they would imply that committers and new project proposals
> are not TSC decisions but rather project-level decisions.  Sounds
> healthy.
>
> I'd suggest then (to the community writ large) that David and Colin
> propose a new 'merged controller' project with the two of them as the
> leads and we follow the design and process route they've advocated on
> list for that project.
>
> For developers who need to build on the prod Floodlight components
> while we're porting them to the SAL, there is a repo for that.  We're
> in that boat with the D-E design already.
>
> For developers who need to build on the SAL while it is in flight to
> get ready for the prod Floodlight components, there is a repo for
> that.  We're in that boat with the D-E design already.
>
> For developers who need to build on a controller that starts empty but
> most resembles the end design state over the next few months, the new
> D-E project repo would fit that purpose.  Their pushing will create
> natural demand pull for prioritizing the porting of SAL and Floodlight
> implementations in to the D-E end state.
>
> I'd argue this puts the power where it should be -- in the hands of
> developers writing apps along the D-E design  -- and gives all of us
> in the controller-oriented projects a *lot* of incentive to serve them
> well.
>
> (It also gives David and Colin much deserved independent seats on the
> TSC.  David was the author of Beacon, the codebase that spawned both
> implementations.  It feels like the 'right thing' to do that he have a
> formal role there as well as in the community at large from his sweat
> if not his $$$.)
>
> -K
>
> On May 15, 2013, at 8:33 AM, David Meyer <dmm@...> wrote:
>
> > Kyle/all,
> >
> > On Wed, May 15, 2013 at 7:04 AM, Kyle Forster
> > <kyle.forster@...> wrote:
> >> 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 liketo go to a
> >> few facts and iii) we'd like to chart a productive path forward.
> >
> > In further considering the below, please find my comments in line.
> >
> >>
> >> -------
> >>
> >> 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 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.
> >
> > Please provide evidence to support these very serious accusations. IMO
> > to begin with such an assumption/accusation is very damaging to the
> > trust relationships that are core to a well functioning open source
> > project. In fact these assertions/accusations create exactly the
> > environment you claim to want to prevent.
> >
> >>
> >> -------
> >>
> >> 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 listwith 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-gradeFloodlight
> >> components, and a lot to do on making production-grade Floodlightcomponents
> >> SAL-ready.  We're signed up for a lot there.
> >>
> >> It has the nice property of aligning incentives -- committers arenaturally
> >> 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.
> >
> > Again, please provide evidence of any "tyranny". These are serious
> > accusations that require supporting evidence. The assertion that
> > "issue is very real in other well known SDN open source projects" is
> > simply not sufficient.
> >
> >> 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.
> >
> > After thinking about this for a few hours I went back and re-read the
> > TSC charter for guidance. The following points are relevant to this
> > thread:
> >
> > (i).  Governance
> >
> > Section 5 of the TSC charter
> > (http://www.opendaylight.org/project/tsc/charter) outlines the TSC's
> > responsibility. In particular, it is not scope for the TSC to dictate
> > the creation of any project. Specifically, "the TSC is responsible for
> > simultaneous release dates, release quality standards,  technical best
> > practices (including the Development Process), monitoring technical
> > progress, mediating technical conflicts between Committers and project
> > leads, and organizing inter-project collaboration. The TSC will define
> > ODP’s release vehicles." In summary, it is out of scope for the TSC to
> > dictate the creation of any ODP project.
> >
> > (ii).  Committers
> >
> > Section 7 of the TSC charter covers committers. Germain here is that
> > "Initial projects that form ODP’s base may designate Committers.".  In
> > addition, "Committers select and vote for new Committers, subject to
> > TSC approval.".
> >
> > What is clear from this section is that the TSC does not have the
> > authority under our governance model to appoint committers to any
> > project. Note that any appointment of committers by the TSC also
> > violates the "meritocracy principle" that is core to any open source
> > project.
> >
> > Summary: As I said in section (ii). below (New Project/Repository) and
> > reassert here, "this is largely a political issue and as such is
> > outside of the scope of the TSC". And while I initially thought a vote
> > on this topic might resolve the problem upon further reflection and
> > study I see that, as I originally stated, the creation of a New
> > Project is out of scope for the TSC. Further, the TSC has no
> > jurisdiction to appoint committers and in any event such an action
> > would violate core open source principles.
> >
> > Finally, the ODP community is of course free to start any new project
> > which will be subject to the ODP lifecycle. However, the creation of a
> > new project and/or the appointment of committers is out of scope for
> > the TSC (and in any event would violate core open source values).
> >
> > --dmm
> >
> >
> >
> >>
> >> -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
> >>> Chris. That was my mistake. That said, the point I was making still
> >>> holds, namely, that there exist some ideas (and there will be more) to
> >>> deal with the near term deficiencies, perceived or otherwise, with the
> >>> SAL.
> >>>
> >>> --dmm
> >>>
> >>>
> >>> On Tue, May 14, 2013 at 9:09 AM, David Meyer <dmm@...> wrote:
> >>>> All,
> >>>>
> >>>> As you know today (05.14.2013) was the day on which I wanted to
> >>>> have the single controller code base issue resolved. What I had
> >>>> said is that if we couldn't get the projects to agree on a way
> >>>> forward that we as a TSC would vote on the issue. In the mean
> >>>> time we have reached general consensus that the Dixon-Erickson
> >>>> OpenDaylight Merged Controller Proposal (DE) (see
> >>>>
> >>>> https://wiki.opendaylight.org/view/Dixon-
> Erickson_OpenDaylight_Merged_Controller_Proposal).
> >>>> I want to be very clear here that that plan is distinct from what
> >>>> is being called Proposed Dixon-Erickson Execution Plan (see
> >>>>
> >>>> https://wiki.opendaylight.org/view/Proposed_Dixon-Erickson_Execution_Plan
> ).
> >>>> So
> >>>> from this perspective the community has come together over this
> >>>> general direction. This functionally obviates the need for a
> >>>> direct vote.
> >>>>
> >>>> There have been quite a few concerns raised both publicly and to
> >>>> me directly in private email. I'd like to review those here and
> >>>> provide my perspective.
> >>>>
> >>>> (i). The SAL
> >>>>
> >>>> It is generally agreed that there is work left to be done on the
> >>>> SAL, and that there may be instances in which, (in the near term)
> >>>> we need a mechanism to provide a kind of "SAL bypass". Chris'
> >>>> IOCTL proposal is one such idea. What I want to point out here is
> >>>> the the ODP is evolving and as such we expect the architecture to
> >>>> not not improve technically but converge on the needed
> >>>> functionality/generality over time. This is a completely natural
> >>>> state of affairs for any software project. The summary is that we
> >>>> can provide short term mechanisms that bridge any perceived or
> >>>> real functionality gaps in the SAL (again, Chris' IOCTL idea
> >>>> might be one such mechanism).  So while the OSCP folks have
> >>>> argued pretty strongly against the SAL (both publicly and
> >>>> privately), the DE proposal endorses the SAL concept and the
> >>>> OpenDaylight Controller folks consider the SAL to be a
> >>>> fundamental architectural construct. That said, evolution of the
> >>>> SAL (be it the model driven approach, bypass, etc) is an issue
> >>>> for folks who are writing SAL applications (committing code) to
> >>>> resolve.
> >>>>
> >>>> (ii). New Project/Repository
> >>>>
> >>>> This issue is really about the fairness of commits to the
> >>>> controller code base. This was stated explicitly to me privately
> >>>> and publicly by Glenn Ricart and Guru Parulkar on the discuss
> >>>> list. On the other hand, a simple majority of TSC members (and
> >>>> many in the community) have expressed the opinion that they would
> >>>> prefer moving forward with the plan outlined in the DE-proposal,
> >>>> namely start with the OpenDaylight controller and evolve that as
> >>>> needed. I will note here that there is no objective evidence that
> >>>> there is a fairness issue with commits to any candiate code base
> >>>> (it would hard for that to be the case in any event as we haven't
> >>>> had the chance to really get going). Finally, since this is
> >>>> largely a political issue it is outside of the scope of the TSC
> >>>> and should be "policed" by the community.
> >>>>
> >>>> As an aside, I will also note here that several community
> >>>> members have expressed concern that the new project
> >>>> approach is quite expensive and has little benefit beyond
> >>>> the political/perception issue mentioned above.
> >>>>
> >>>>
> >>>> (iii)  Timing
> >>>>
> >>>> The timing issue, namely that there is (is not) a rush to get the
> >>>> ODP project up and running is one that has also been raised both
> >>>> publicly and privately. I have been told (again, both publicly
> >>>> and privately) by the OSCP (BSN) folks that they have time
> >>>> pressure to port their applications to the ODP controller. That
> >>>> is a principle rationale behind the Layered API proposal
> >>>>
> >>>> (https://wiki.opendaylight.org/view/
> Layered_API_Merged_Controller_Proposal).
> >>>> In addition, the same team is also arguing that  we are in no rush and
> >>>> in fact any date for resolving the controller issue is not only
> >>>> artificial but damaging to the community; this exact sentiment was
> >>>> contained in a private communication from Rob Sherwood to me dated
> >>>> Tue, May 14, 2013 at 1:38 AM. In the spirit of transparency I am copying
> >>>> the
> >>>> relevant text from that email here:
> >>>>
> >>>> "I know that in your heart you believe what you're doing is the
> >>>> right thing for the community, and that's why I've held off
> >>>> making a stink, but as chair, I'm not sure what you're doing is
> >>>> in terms of pushing hard on this artificial deadline (that you
> >>>> said originally was not set in stone but now it is) or being
> >>>> opaque in terms of the actual process is really helping the
> >>>> community."  -- Rob Sherwood to dmm on Tue, May 14, 2013 at 1:38
> >>>> AM.
> >>>>
> >>>> (this text of course also contains criticisms of me in my role
> >>>> as chair to which I will return but I want to focus here on the
> >>>> timing issue).
> >>>>
> >>>> The summary here is that it has been argued by the OSCP team that
> >>>> we accept their proposal
> >>>> (https://wiki.opendaylight.org/view/File:LayeredAPIProposal.pdf)
> >>>> because there is time pressure to port applications while at the
> >>>> same time it is being argued that any time frame is damaging,
> >>>> artificial, or worse. On the other hand, a simple majority of the
> >>>> TSC have stated publicly (on the discuss list) that resolving the
> >>>> controller code base issue of primary importance and they would
> >>>> like to move forward with an interpretation of DE that starts
> >>>> with the existing OpenDaylight controller code base.
> >>>>
> >>>> It is clear from these inconsistencies that the timing issue is
> >>>> largely a non-issue for the ODP community at large; in addition
> >>>> there is clear benefit to moving forward with the DE approach now. One
> >>>> might also note here that we've made very little progress over
> >>>> the last many weeks and it is time to start, now.
> >>>>
> >>>> (iv).  Finally, if anyone has problems with me personally and/or the
> >>>> way TSC is being run please air those publicly on the
> >>>> discuss list. I will not be responding to emails such as the one
> >>>> quoted above, lobbying by private phone call, or the
> >>>> like. Again, if you have complaints about the way the TSC
> >>>> is being run please discuss those on the discuss or tsc lists.
> >>>>
> >>>> Summary: It is clear that there is additional evolution that is
> >>>> needed for the SAL. No one is arguing otherwise. The new
> >>>> project/repository issue is really about concern that commits
> >>>> won't be fair (again, both Glenn and Guru raised this); however
> >>>> there is no evidence that this is or will be the case and in any
> >>>> event is not a technical issue and as such is out of scope for
> >>>> the TSC. Finally, the timing issue is largely a commercial issue
> >>>> (the need to port applications) and also has been argued on both
> >>>> sides by the same people and as such I consider those arguments
> >>>> largely moot; there is a real need to get the consortium going
> >>>> (hence the date) but that is a wholly different argument.
> >>>>
> >>>> --dmm
> >>> _______________________________________________
> >>> TSC mailing list
> >>> TSC@...
> >>> https://lists.opendaylight.org/mailman/listinfo/tsc
> >>
> >>
> >>
> >>
> >> --
> >> ---------------------------------------------------------
> >> R. Kyle Forster
> >> +1 (415) 990-2670 (m)
> >> kyle.forster@...
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
>


project lifecycle

Rajeev Nagar <Rajeev.Nagar@...>
 

I posted a question on the discuss list. However, I have a variant of the question for the TSC and would appreciate some clarification:
 
What in our current/approved project lifecycle describes the current scenario we face wherein the “bootstrap” project is redefined to be an amalgamation of two existing “bootstrap” projects? In this case, “amalgamation” is defined as high likelihood (we are all engineers so I am hand-waving here) that the resultant bootstrap code base will have a minimum of 20% LOC from each constituent bootstrap project?
 
Specific sub-questions include:
 
  1. Does the choice of repo define a bootstrap project?
  2. What defines the initial list of proposed committers for the scenario we are currently facing? Is it derived from the choice of repo?
 
If any of you want my personal opinion on the above, I am glad to directly state it. However, given/despite the passionate discussions amongst many of you, I could not figure out a crisp set of answers to the above. My experience base with open source projects is not as wide as most of you – hence my question and request for discussion amongst the TSC.
 
IF the above questions are not part of the TSC’s mandate, whose purview would they fall under?
 
Thanks and best,
 
  • rajeev


Results of the OpenDaylight board call of 05.15.2013 and its relationship to the issues we've been discussing

David Meyer <dmm@...>
 

All,

During the board call this afternoon I outlined the issues that we
have been facing around repositories, projects and committer lists.
After an hour of thoughtful and spirited discussion the following
items were decided by the ODP Board:

First, two things were stipulated: (a). The Dixon-Erickson
OpenDaylight Merged Controller Proposal ("DE proposal") is the
consensus framework for moving forward, and (b). that the new
project/repository idea in which the two controllers were disassembled
then reassembled to build a new controller will *not* be pursued. As a
result either the OpenDaylight Controller ("controller") or the
OpenDaylight SDN Controller Platform ("net-virt-platform") will be
the starting point.

Given that, the following process was agreed upon:

(i). Disambiguate the starting point for the DE proposal. This
starting point can be either the "controller" or "net-virt-platform"
code base (again, the third project/repository is not a candidate).
Note that the current list of committers for whichever code base will
*not* be carried forward. The point here is to decouple the issue of
committers from the code base.

The TSC will vote on the starting point as the first order of business
during tomorrow's call.

(ii). Using code base selected in (i). find volunteers to flesh out
each functional block of the DE proposal. For each functional block we
will also need a design for integration with the larger system. Note
that those who do this work are likely candidates to become committers
(growing committer lists organically).

(iii). Decide on a timeframe during which this plan can be executed,
noting that we need to have this done in a timely fashion.

Thanks,

--dmm

161 - 180 of 14240