Date   

Re: TSC Comments to the Board on TSC_Policy.doc

David Meyer <dmm@...>
 



On Thu, Apr 25, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Please find enumerated below the comments of the TSC on the Boards TSC-policies doc.  In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"•      Simultaneous Release:  The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an  adjustment of scope for the OpenDaylight project to the  Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding  elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller  communication”

Thanks Ed. This looks to accurately capture what we decided. Others: If you have corrections/discussion points/etc please get those to the list by COB and I will synthesize a package for the Board (hopefully by tomorrow if we can close on this list).

Thnx,

--dmm



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



Re: TSC Comments to the Board on TSC_Policy.doc

Rob Sherwood
 

The list definitely looks accurate - thanks Ed.

One thing: I'm sure that Dave, Benson, Chris and others will provide the necessary context around these changes, but I can imagine if you see these proposed changes without that context, one could jump to some incorrect conclusions.  Do the TSC members who are also on the board feel comfortable representing _why_ the changes were made?

Thanks,

- Rob


On Thu, Apr 25, 2013 at 12:10 PM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Please find enumerated below the comments of the TSC on the Boards TSC-policies doc.  In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"•      Simultaneous Release:  The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an  adjustment of scope for the OpenDaylight project to the  Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding  elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller  communication”

Thanks Ed. This looks to accurately capture what we decided. Others: If you have corrections/discussion points/etc please get those to the list by COB and I will synthesize a package for the Board (hopefully by tomorrow if we can close on this list).

Thnx,

--dmm



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



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



Re: TSC Comments to the Board on TSC_Policy.doc

Phil Robb
 

For clarity, you might also want to add that comments 4 through 6 are in reference to the "Scope" portion of the document.

Phil.


On Thu, Apr 25, 2013 at 2:21 PM, Rob Sherwood <rob.sherwood@...> wrote:

The list definitely looks accurate - thanks Ed.

One thing: I'm sure that Dave, Benson, Chris and others will provide the necessary context around these changes, but I can imagine if you see these proposed changes without that context, one could jump to some incorrect conclusions.  Do the TSC members who are also on the board feel comfortable representing _why_ the changes were made?

Thanks,

- Rob


On Thu, Apr 25, 2013 at 12:10 PM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Please find enumerated below the comments of the TSC on the Boards TSC-policies doc.  In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"•      Simultaneous Release:  The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an  adjustment of scope for the OpenDaylight project to the  Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding  elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller  communication”

Thanks Ed. This looks to accurately capture what we decided. Others: If you have corrections/discussion points/etc please get those to the list by COB and I will synthesize a package for the Board (hopefully by tomorrow if we can close on this list).

Thnx,

--dmm



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



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



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




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: TSC Comments to the Board on TSC_Policy.doc

David Meyer <dmm@...>
 



On Thu, Apr 25, 2013 at 1:21 PM, Rob Sherwood <rob.sherwood@...> wrote:
The list definitely looks accurate - thanks Ed.

One thing: I'm sure that Dave, Benson, Chris and others will provide the necessary context around these changes, but I can imagine if you see these proposed changes without that context, one could jump to some incorrect conclusions.  Do the TSC members who are also on the board feel comfortable representing _why_ the changes were made?

Not a problem. --dmm
 

Thanks,

- Rob


On Thu, Apr 25, 2013 at 12:10 PM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Please find enumerated below the comments of the TSC on the Boards TSC-policies doc.  In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"•      Simultaneous Release:  The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an  adjustment of scope for the OpenDaylight project to the  Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding  elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller  communication”

Thanks Ed. This looks to accurately capture what we decided. Others: If you have corrections/discussion points/etc please get those to the list by COB and I will synthesize a package for the Board (hopefully by tomorrow if we can close on this list).

Thnx,

--dmm



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



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




Re: TSC Comments to the Board on TSC_Policy.doc

Chris Wright <chrisw@...>
 

* Rob Sherwood (rob.sherwood@...) wrote:
The list definitely looks accurate - thanks Ed.

One thing: I'm sure that Dave, Benson, Chris and others will provide the
necessary context around these changes, but I can imagine if you see these
proposed changes without that context, one could jump to some incorrect
conclusions. Do the TSC members who are also on the board feel comfortable
representing _why_ the changes were made?
Yes


Re: Asynchronous voting mechanisms for TSC

Chris Wright <chrisw@...>
 

* David Meyer (dmm@...) wrote:
<snip>
Finally, we aren't
really making as much progress as I would like (you'll see an update from
Phil on this) and as such using "quorum authority" helps us execute.
Here are a couple concrete steps we could follow to encourage more
email use:

1) require that all agenda items are added to the wiki w/in Xhrs/days
of the next call, and include a cc to the list (alternatively, we place
a watch on the agenda wiki such that updates are sent to the list)

2) use email to put forth motions allowing for time before meeting to
actually vote.

The goal of both of those is to push the bulk of the conversation
surrounding the topic to the list before a tsc meeting to streamline
the realtime part of the conversation.

thanks,
-chris


Re: Asynchronous voting mechanisms for TSC

David Meyer <dmm@...>
 

Great suggestions. --dmm


On Thu, Apr 25, 2013 at 2:58 PM, Chris Wright <chrisw@...> wrote:
* David Meyer (dmm@...) wrote:
<snip>
> Finally, we aren't
> really making as much progress as I would like (you'll see an update from
> Phil on this) and as such using "quorum authority" helps us execute.

Here are a couple concrete steps we could follow to encourage more
email use:

1) require that all agenda items are added to the wiki w/in Xhrs/days
of the next call, and include a cc to the list (alternatively, we place
a watch on the agenda wiki such that updates are sent to the list)

2) use email to put forth motions allowing for time before meeting to
actually vote.

The goal of both of those is to push the bulk of the conversation
surrounding the topic to the list before a tsc meeting to streamline
the realtime part of the conversation.

thanks,
-chris


Re: Asynchronous voting mechanisms for TSC

Thomas Nadeau <tnadeau@...>
 

I guess any motions that are raised during the call, in cases where %100
of members are not there, must then also be sent out via email (with an
expiration date to absentee votes). Although we should count attendees at
the time its called.

--Tom

* David Meyer (dmm@...) wrote:
<snip>
Finally, we aren't
really making as much progress as I would like (you'll see an update
from
Phil on this) and as such using "quorum authority" helps us execute.
Here are a couple concrete steps we could follow to encourage more
email use:

1) require that all agenda items are added to the wiki w/in Xhrs/days
of the next call, and include a cc to the list (alternatively, we place
a watch on the agenda wiki such that updates are sent to the list)

2) use email to put forth motions allowing for time before meeting to
actually vote.

The goal of both of those is to push the bulk of the conversation
surrounding the topic to the list before a tsc meeting to streamline
the realtime part of the conversation.

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


Increasing TSC meetings to twice per week

Phil Robb
 

Hello OpenDaylight TSC Members:

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

Alternatively we could expand the meeting on Thursdays to 2 hours.

Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: Increasing TSC meetings to twice per week

Thomas Nadeau <tnadeau@...>
 



From: Phil Robb <probb@...>
Date: Thursday, April 25, 2013 10:15 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Increasing TSC meetings to twice per week

Hello OpenDaylight TSC Members:

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

Can we make it at 1:30?

Alternatively we could expand the meeting on Thursdays to 2 hours.

If we keep it on the same day, I'd like it expanded in the backward direction. I have a meeting that overlaps with the existing time that I just moved forward an hour that has 10 people on it, so it was quite a bear to move. 

The other approach is to have a "virtual meeting" the rest of the week where we discuss via the mailing list (and vote there as well).

--Tom


Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: Increasing TSC meetings to twice per week

Phil Robb
 

Hi Tom:

Thanks for your quick response.

Some of the attendees have a conflict at 1:30pm PDT on Tuesdays.  Would 2pm PDT on Tuesdays work?

We will start after next week  (on May 7th).  Does 2:00pm PDT on Tuesdays work for all TSC members?  Please let me know and I'll get this scheduled.

Thanks,

Phil.


On Fri, Apr 26, 2013 at 6:21 AM, Thomas Nadeau <tnadeau@...> wrote:


From: Phil Robb <probb@...>
Date: Thursday, April 25, 2013 10:15 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Increasing TSC meetings to twice per week

Hello OpenDaylight TSC Members:

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

Can we make it at 1:30?

Alternatively we could expand the meeting on Thursdays to 2 hours.

If we keep it on the same day, I'd like it expanded in the backward direction. I have a meeting that overlaps with the existing time that I just moved forward an hour that has 10 people on it, so it was quite a bear to move. 

The other approach is to have a "virtual meeting" the rest of the week where we discuss via the mailing list (and vote there as well).

--Tom


Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb



--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: Increasing TSC meetings to twice per week

Abhishek Chauhan
 

2:00pm PDT on Tuesdays works for me generally, but I have a conflict on 5/7 till 2:30p.

 

Best,

abhishek

 

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Phil Robb
Sent: Friday, April 26, 2013 8:29 AM
To: Thomas Nadeau
Cc: tsc@...
Subject: Re: [OpenDaylight TSC] Increasing TSC meetings to twice per week

 

Hi Tom:

 

Thanks for your quick response.

 

Some of the attendees have a conflict at 1:30pm PDT on Tuesdays.  Would 2pm PDT on Tuesdays work?

 

We will start after next week  (on May 7th).  Does 2:00pm PDT on Tuesdays work for all TSC members?  Please let me know and I'll get this scheduled.

 

Thanks,

 

Phil.

 

On Fri, Apr 26, 2013 at 6:21 AM, Thomas Nadeau <tnadeau@...> wrote:

 

 

From: Phil Robb <probb@...>
Date: Thursday, April 25, 2013 10:15 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Increasing TSC meetings to twice per week

 

Hello OpenDaylight TSC Members:

 

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

 

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

 

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

 

Can we make it at 1:30?

 

Alternatively we could expand the meeting on Thursdays to 2 hours.

 

If we keep it on the same day, I'd like it expanded in the backward direction. I have a meeting that overlaps with the existing time that I just moved forward an hour that has 10 people on it, so it was quite a bear to move. 

 

The other approach is to have a "virtual meeting" the rest of the week where we discuss via the mailing list (and vote there as well).

 

--Tom

 

 

Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

 

Phil.
--

Phil Robb

Director - Networking Solutions

The Linux Foundation

Skype: Phil.Robb



 

--

Phil Robb

Director - Networking Solutions

The Linux Foundation

(O) 970-229-5949

(M) 970-420-4292

Skype: Phil.Robb


Re: Increasing TSC meetings to twice per week

Thomas Nadeau <tnadeau@...>
 


5-6 EST is getting a bit late for east coast folks. 

--Tom



From: Phil Robb <probb@...>
Date: Friday, April 26, 2013 11:28 AM
To: Thomas Nadeau <tnadeau@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [OpenDaylight TSC] Increasing TSC meetings to twice per week

Hi Tom:

Thanks for your quick response.

Some of the attendees have a conflict at 1:30pm PDT on Tuesdays.  Would 2pm PDT on Tuesdays work?

We will start after next week  (on May 7th).  Does 2:00pm PDT on Tuesdays work for all TSC members?  Please let me know and I'll get this scheduled.

Thanks,

Phil.


On Fri, Apr 26, 2013 at 6:21 AM, Thomas Nadeau <tnadeau@...> wrote:


From: Phil Robb <probb@...>
Date: Thursday, April 25, 2013 10:15 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Increasing TSC meetings to twice per week

Hello OpenDaylight TSC Members:

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

Can we make it at 1:30?

Alternatively we could expand the meeting on Thursdays to 2 hours.

If we keep it on the same day, I'd like it expanded in the backward direction. I have a meeting that overlaps with the existing time that I just moved forward an hour that has 10 people on it, so it was quite a bear to move. 

The other approach is to have a "virtual meeting" the rest of the week where we discuss via the mailing list (and vote there as well).

--Tom


Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb



--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: Increasing TSC meetings to twice per week

Christopher Price <christopher.price@...>
 

Hi Phil,

In general Tuesdays work for me I don't have anything recurring that cannot be shuffled.

/ Chris

From: Phil Robb <probb@...>
Date: Thursday, April 25, 2013 7:15 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Increasing TSC meetings to twice per week

Hello OpenDaylight TSC Members:

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

Alternatively we could expand the meeting on Thursdays to 2 hours.

Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


TSC comments on TSC_policy.doc

David Meyer <dmm@...>
 


As discussed during the TSC meeting of 2013-04-25, the TSC has the following comments on TSC_policy.doc:  
 
(i).    Comment to the Board: The TSC recommends replacing the 
        word 'mature' in the 'Singularity' bullet with the word 
        'core'.  
 
(ii).   Comment to the Board: The TSC recommends striking the 
        'Effectiveness' bullet all together on the grounds that 
        resources and priority are driven bottom up, not top 
        down from the TSC.  
 
(iii).  Comment to the Board: The TSC recommends striking the 
        'Productivity' bullet and replacing it with the following 
        bullet:  
 
        Simultaneous Release:  The TSC is responsible for 
        organizing a simultaneous release of appropriate 
        OpenDaylight Projects at regular intervals.  
 
Regarding the Scope portion of TSC_policy.doc: 
 
(iv).   Comment to the Board: The TSC requests that the Board
        institute a lightweight mechanism to for the TSC to request
        adjustments to the scope of the OpenDaylight project (as needed).  
 
(v).    Comment to the Board: With regard to the "Reference 
        forwarding elements" in the OpenDaylight scope, the TSC 
        recommends replacing with the following text: "Software 
        for forwarding elements" 
 
(vi).   Comment to the Board: The TSC recommends adding the
        following item to the scope: "Plugins for inter-controller  
        communication" 
 
 
A highlighted copy of TSC_policy.doc is also attached. 

Please let us know if you have questions or comments.
 
Thanks, 
 
--dmm 
 
[for the TSC] 


Resolving the multiple controller code bases issue

David Meyer <dmm@...>
 

 
[04/29/2013] 
 
As you may know, there have been several proposals floated to 
deal with the problems created by the fact that we have two 
controller code bases. These include but not limited to:  
 
(i).    Work on portability between code bases and maintain two 
        controllers going forward. This would obviously create 
        enormous challenges and inefficiencies over time. In 
        addition, it will continue the lack of clarity over 
        the ODP controller code base. 
 
(ii).   Create a new controller project that would incorporate 
        the desirable components of both controllers (the 
        so-called "merged controller"). Note that the creation of 
        such a third controller project would require extensive 
        resources for design and integration, versus expanding on 
        what we already have. Again, such an approach will also 
        continue the lack of clarity over the ODP controller code 
        base and push our deliverables out an for an undefined 
        period of time.  
 
(iii).  Have the TSC vote for either the Cisco or BSN code base 
        as the ODP controller code base. The TSC could also vote 
        to keep the other code base available in case it ever 
        wanted to pull parts of the other code base in.   
 
(iv).   Others that I might have missed? 
 
Clearly neither option (i). nor option (ii). reach the objective 
of providing a clear understanding for the community of which 
code base ODP is building on (nor would they do so in a timely  
fashion). On the other hand, jumping directly to option (iii). is 
not optimal as we might miss out on compromises that could be 
beneficial to our community (as well as being more "top-down" 
than we would like). 
 
Since our clear goal (and responsibility) is to make ODP into the 
standard open source infrastructure for SDN, it is incumbent upon 
us as the ODP TSC to take affirmative action to clear this 
problem and get ODP moving. To that end and in consultation with 
the Linux Foundation and others, I am formally putting the 
following resolution process in place:  
 
(a).    I will ask Cisco and BSN to create a proposal for one 
        controller code base that comprise the ODP controller 
        code base. This "one code base" could be either code 
        bases or a mashup of the two that Cisco and BSN feel, 
        from a technical point of view, will best serve the ODP 
        community. In addition, the proposal may include 
        proposals to start other ODP projects or sub-projects to 
        address any gaps or future work.  And of course,
        community members are encouraged to participate in 
        this process.
 
(b).   The proposal should be available for TSC review no later 
        than Monday, 13 May 2013. Of course, we should provide 
        for flexibility in the event substantive progress is 
        being made. That said, 13 May 2013 should be our target 
        date.  
 
(c).    If no proposal can be created by Cisco and BSN (possibly 
        working with other community members), the TSC will take 
        an up or down vote on which controller code base ODP will 
        be using going forward. The vote should be taken on 
        Tuesday, 14 May 2013 by email in a private ballot to 
        preclude the appearance of a "deciding vote" being cast 
        by any TSC member. I propose that the Linux Foundation 
        receive, tally, and make public all the votes and the 
        result at the same time.    
 
 
Note that it is not uncommon for an open source project such as 
ODP to have competing code bases, nor is it uncommon for a 
resolution such as described above to be used in these cases. In 
particular, this process is designed to both be as true as 
possible to the open source community and its governance model 
while at the same time providing a forcing function to drive 
resolution of our controller code base problem. 
 
Finally, I have asked Collin Dixon and David Erickson to start a 
discussion of architectural and technical aspects of the two code 
bases on discuss@.... Thanks Colin and David!  
Please join in on that discussion to the extent you have 
time/inclination. This discussion is a crucial part of building 
our community, and we will need such an analysis in the event 
that vote. In particular, this work will give us a technical 
basis on which to base our votes. 
 
Thnx, 
 
--dmm 
 


Re: Resolving the multiple controller code bases issue

Chris Wright <chrisw@...>
 

* David Meyer (dmm@...) wrote:
As you may know, there have been several proposals floated to
deal with the problems created by the fact that we have two
controller code bases. These include but not limited to:

(i). Work on portability between code bases and maintain two
controllers going forward. This would obviously create
enormous challenges and inefficiencies over time. In
addition, it will continue the lack of clarity over
the ODP controller code base.
Agreed, non-starter.

(ii). Create a new controller project that would incorporate
the desirable components of both controllers (the
so-called "merged controller"). Note that the creation of
such a third controller project would require extensive
resources for design and integration, versus expanding on
what we already have. Again, such an approach will also
continue the lack of clarity over the ODP controller code
base and push our deliverables out an for an undefined
period of time.
I actually think this is quite similar to or at least a variant of what
you've outlined in your proposal below.

(iii). Have the TSC vote for either the Cisco or BSN code base
as the ODP controller code base. The TSC could also vote
to keep the other code base available in case it ever
wanted to pull parts of the other code base in.
BTW, let's keep this to the projects and their developers.
So, that is the "controller" project and the "net-virt-platform"
project.

(iv). Others that I might have missed?

Clearly neither option (i). nor option (ii). reach the objective
of providing a clear understanding for the community of which
code base ODP is building on (nor would they do so in a timely
fashion). On the other hand, jumping directly to option (iii). is
not optimal as we might miss out on compromises that could be
beneficial to our community (as well as being more "top-down"
than we would like).

Since our clear goal (and responsibility) is to make ODP into the
standard open source infrastructure for SDN, it is incumbent upon
us as the ODP TSC to take affirmative action to clear this
problem and get ODP moving. To that end and in consultation with
the Linux Foundation and others, I am formally putting the
following resolution process in place:

(a). I will ask Cisco and BSN to create a proposal for one
controller code base that comprise the ODP controller
code base. This "one code base" could be either code
bases or a mashup of the two that Cisco and BSN feel,
from a technical point of view, will best serve the ODP
community. In addition, the proposal may include
proposals to start other ODP projects or sub-projects to
address any gaps or future work. And of course,
community members are encouraged to participate in
this process.
I agree. Pushing back on the developers that own each proposal and making
the path forward "their problem" is a tried and true way to try to positively
engage each of the teams. A critical component of the success of
OpenDaylight is building community and collaboration.

(b). The proposal should be available for TSC review no later
than Monday, 13 May 2013. Of course, we should provide
for flexibility in the event substantive progress is
being made. That said, 13 May 2013 should be our target
date.

(c). If no proposal can be created by Cisco and BSN (possibly
working with other community members), the TSC will take
an up or down vote on which controller code base ODP will
be using going forward. The vote should be taken on
Tuesday, 14 May 2013 by email in a private ballot to
preclude the appearance of a "deciding vote" being cast
by any TSC member. I propose that the Linux Foundation
receive, tally, and make public all the votes and the
result at the same time.
I believe we'd need to have some metrics that we (the TSC) would be
using to evaluate the code bases and make a vote that's not completely
arbitrary or a popularity contest. Some examples are (just throwing
things out to be concrete):

1) controller extensibility and modularity
2) model driven API abstraction
3) ability to support eventual consistency model
4) ability to support multiple southbound plugins
5) ability to support virtual networking requirements

And I see this as an absolute last resort. Basically, if we get here
it's because the controller and net-virt-platform teams have reached
some fundamental impasse.

Note that it is not uncommon for an open source project such as
ODP to have competing code bases, nor is it uncommon for a
resolution such as described above to be used in these cases. In
particular, this process is designed to both be as true as
possible to the open source community and its governance model
while at the same time providing a forcing function to drive
resolution of our controller code base problem.

Finally, I have asked Collin Dixon and David Erickson to start a
discussion of architectural and technical aspects of the two code
bases on discuss@.... Thanks Colin and David!
Please join in on that discussion to the extent you have
time/inclination. This discussion is a crucial part of building
our community, and we will need such an analysis in the event
that vote. In particular, this work will give us a technical
basis on which to base our votes.
Yes, OK. Let's use that to build the list I mentioned above.

thanks,
-chris


Re: Resolving the multiple controller code bases issue

David Meyer <dmm@...>
 



On Mon, Apr 29, 2013 at 12:49 PM, Chris Wright <chrisw@...> wrote:
* David Meyer (dmm@...) wrote:
> As you may know, there have been several proposals floated to
> deal with the problems created by the fact that we have two
> controller code bases. These include but not limited to:
>
> (i).    Work on portability between code bases and maintain two
>         controllers going forward. This would obviously create
>         enormous challenges and inefficiencies over time. In
>         addition, it will continue the lack of clarity over
>         the ODP controller code base.

Agreed, non-starter.

> (ii).   Create a new controller project that would incorporate
>         the desirable components of both controllers (the
>         so-called "merged controller"). Note that the creation of
>         such a third controller project would require extensive
>         resources for design and integration, versus expanding on
>         what we already have. Again, such an approach will also
>         continue the lack of clarity over the ODP controller code
>         base and push our deliverables out an for an undefined
>         period of time.

I actually think this is quite similar to or at least a variant of what
you've outlined in your proposal below.

Yes, again an issue of degrees.
 

> (iii).  Have the TSC vote for either the Cisco or BSN code base
>         as the ODP controller code base. The TSC could also vote
>         to keep the other code base available in case it ever
>         wanted to pull parts of the other code base in.

BTW, let's keep this to the projects and their developers.
So, that is the "controller" project and the "net-virt-platform"
project.

Makes sense.
 

> (iv).   Others that I might have missed?
>
> Clearly neither option (i). nor option (ii). reach the objective
> of providing a clear understanding for the community of which
> code base ODP is building on (nor would they do so in a timely
> fashion). On the other hand, jumping directly to option (iii). is
> not optimal as we might miss out on compromises that could be
> beneficial to our community (as well as being more "top-down"
> than we would like).
>
> Since our clear goal (and responsibility) is to make ODP into the
> standard open source infrastructure for SDN, it is incumbent upon
> us as the ODP TSC to take affirmative action to clear this
> problem and get ODP moving. To that end and in consultation with
> the Linux Foundation and others, I am formally putting the
> following resolution process in place:
>
> (a).    I will ask Cisco and BSN to create a proposal for one
>         controller code base that comprise the ODP controller
>         code base. This "one code base" could be either code
>         bases or a mashup of the two that Cisco and BSN feel,
>         from a technical point of view, will best serve the ODP
>         community. In addition, the proposal may include
>         proposals to start other ODP projects or sub-projects to
>         address any gaps or future work.  And of course,
>         community members are encouraged to participate in
>         this process.

I agree.  Pushing back on the developers that own each proposal and making
the path forward "their problem" is a tried and true way to try to positively
engage each of the teams.  A critical component of the success of
OpenDaylight is building community and collaboration.

> (b).   The proposal should be available for TSC review no later
>         than Monday, 13 May 2013. Of course, we should provide
>         for flexibility in the event substantive progress is
>         being made. That said, 13 May 2013 should be our target
>         date.

BTW, it might not have come across in (b). but of course making progress is more important than any exact dates. That said I would like to resolve this in the most timely fashion possible. 
 
>
> (c).    If no proposal can be created by Cisco and BSN (possibly
>         working with other community members), the TSC will take
>         an up or down vote on which controller code base ODP will
>         be using going forward. The vote should be taken on
>         Tuesday, 14 May 2013 by email in a private ballot to
>         preclude the appearance of a "deciding vote" being cast
>         by any TSC member. I propose that the Linux Foundation
>         receive, tally, and make public all the votes and the
>         result at the same time.

I believe we'd need to have some metrics that we (the TSC) would be
using to evaluate the code bases and make a vote that's not completely
arbitrary or a popularity contest.  Some examples are (just throwing
things out to be concrete):

1) controller extensibility and modularity
2) model driven API abstraction
3) ability to support eventual consistency model
4) ability to support multiple southbound plugins
5) ability to support virtual networking requirements

And I see this as an absolute last resort.  Basically, if we get here
it's because the controller and net-virt-platform teams have reached
some fundamental impasse.

Agreed. Hopefully some of this will fall out of the discussion that I'm hoping will take place at discuss@...

 

> Note that it is not uncommon for an open source project such as
> ODP to have competing code bases, nor is it uncommon for a
> resolution such as described above to be used in these cases. In
> particular, this process is designed to both be as true as
> possible to the open source community and its governance model
> while at the same time providing a forcing function to drive
> resolution of our controller code base problem.
>
> Finally, I have asked Collin Dixon and David Erickson to start a
> discussion of architectural and technical aspects of the two code
> bases on discuss@.... Thanks Colin and David!
> Please join in on that discussion to the extent you have
> time/inclination. This discussion is a crucial part of building
> our community, and we will need such an analysis in the event
> that vote. In particular, this work will give us a technical
> basis on which to base our votes.

Yes, OK.  Let's use that to build the list I mentioned above.

Yep. And s/Collin/Colin/  (sorry about that Colin).

--dmm
 

thanks,
-chris


Re: Resolving the multiple controller code bases issue

Colin Dixon <ckd@...>
 

The list of desirable features which you're asking for are at least partially documented here:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Architectural_Principles

Presumably we should move that out to a project-neutral space on the wiki and attach it to any discussions as we go forward.

--Colin

tsc-bounces@... wrote on 04/29/2013 02:49:19 PM:
> From: Chris Wright <chrisw@...>

> To: David Meyer <dmm@...>
> Cc: tsc@...
> Date: 04/29/2013 02:49 PM
> Subject: Re: [OpenDaylight TSC] Resolving the multiple controller
> code bases issue

> Sent by: tsc-bounces@...
>
> * David Meyer (dmm@...) wrote:
> > As you may know, there have been several proposals floated to
> > deal with the problems created by the fact that we have two
> > controller code bases. These include but not limited to:
> >
> > (i).    Work on portability between code bases and maintain two
> >         controllers going forward. This would obviously create
> >         enormous challenges and inefficiencies over time. In
> >         addition, it will continue the lack of clarity over
> >         the ODP controller code base.
>
> Agreed, non-starter.
>
> > (ii).   Create a new controller project that would incorporate
> >         the desirable components of both controllers (the
> >         so-called "merged controller"). Note that the creation of
> >         such a third controller project would require extensive
> >         resources for design and integration, versus expanding on
> >         what we already have. Again, such an approach will also
> >         continue the lack of clarity over the ODP controller code
> >         base and push our deliverables out an for an undefined
> >         period of time.
>
> I actually think this is quite similar to or at least a variant of what
> you've outlined in your proposal below.
>
> > (iii).  Have the TSC vote for either the Cisco or BSN code base
> >         as the ODP controller code base. The TSC could also vote
> >         to keep the other code base available in case it ever
> >         wanted to pull parts of the other code base in.
>
> BTW, let's keep this to the projects and their developers.
> So, that is the "controller" project and the "net-virt-platform"
> project.
>
> > (iv).   Others that I might have missed?
> >
> > Clearly neither option (i). nor option (ii). reach the objective
> > of providing a clear understanding for the community of which
> > code base ODP is building on (nor would they do so in a timely
> > fashion). On the other hand, jumping directly to option (iii). is
> > not optimal as we might miss out on compromises that could be
> > beneficial to our community (as well as being more "top-down"
> > than we would like).
> >
> > Since our clear goal (and responsibility) is to make ODP into the
> > standard open source infrastructure for SDN, it is incumbent upon
> > us as the ODP TSC to take affirmative action to clear this
> > problem and get ODP moving. To that end and in consultation with
> > the Linux Foundation and others, I am formally putting the
> > following resolution process in place:
> >
> > (a).    I will ask Cisco and BSN to create a proposal for one
> >         controller code base that comprise the ODP controller
> >         code base. This "one code base" could be either code
> >         bases or a mashup of the two that Cisco and BSN feel,
> >         from a technical point of view, will best serve the ODP
> >         community. In addition, the proposal may include
> >         proposals to start other ODP projects or sub-projects to
> >         address any gaps or future work.  And of course,
> >         community members are encouraged to participate in
> >         this process.
>
> I agree.  Pushing back on the developers that own each proposal and making
> the path forward "their problem" is a tried and true way to try to positively
> engage each of the teams.  A critical component of the success of
> OpenDaylight is building community and collaboration.
>
> > (b).   The proposal should be available for TSC review no later
> >         than Monday, 13 May 2013. Of course, we should provide
> >         for flexibility in the event substantive progress is
> >         being made. That said, 13 May 2013 should be our target
> >         date.
> >
> > (c).    If no proposal can be created by Cisco and BSN (possibly
> >         working with other community members), the TSC will take
> >         an up or down vote on which controller code base ODP will
> >         be using going forward. The vote should be taken on
> >         Tuesday, 14 May 2013 by email in a private ballot to
> >         preclude the appearance of a "deciding vote" being cast
> >         by any TSC member. I propose that the Linux Foundation
> >         receive, tally, and make public all the votes and the
> >         result at the same time.
>
> I believe we'd need to have some metrics that we (the TSC) would be
> using to evaluate the code bases and make a vote that's not completely
> arbitrary or a popularity contest.  Some examples are (just throwing
> things out to be concrete):
>
> 1) controller extensibility and modularity
> 2) model driven API abstraction
> 3) ability to support eventual consistency model
> 4) ability to support multiple southbound plugins
> 5) ability to support virtual networking requirements
>
> And I see this as an absolute last resort.  Basically, if we get here
> it's because the controller and net-virt-platform teams have reached
> some fundamental impasse.
>
> > Note that it is not uncommon for an open source project such as
> > ODP to have competing code bases, nor is it uncommon for a
> > resolution such as described above to be used in these cases. In
> > particular, this process is designed to both be as true as
> > possible to the open source community and its governance model
> > while at the same time providing a forcing function to drive
> > resolution of our controller code base problem.
> >
> > Finally, I have asked Collin Dixon and David Erickson to start a
> > discussion of architectural and technical aspects of the two code
> > bases on discuss@.... Thanks Colin and David!
> > Please join in on that discussion to the extent you have
> > time/inclination. This discussion is a crucial part of building
> > our community, and we will need such an analysis in the event
> > that vote. In particular, this work will give us a technical
> > basis on which to base our votes.
>
> Yes, OK.  Let's use that to build the list I mentioned above.
>
> thanks,
> -chris
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
>


Re: Resolving the multiple controller code bases issue

David Meyer <dmm@...>
 



On Mon, Apr 29, 2013 at 1:03 PM, Colin Dixon <ckd@...> wrote:

The list of desirable features which you're asking for are at least partially documented here:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Architectural_Principles

Presumably we should move that out to a project-neutral space on the wiki and attach it to any discussions as we go forward.


Thanks for pointing this out. For those who haven't taken a look at this page, it has some reasonable principles. Also agree with Colin that these are general principles, not project specific.

--dmm
 



--Colin

tsc-bounces@... wrote on 04/29/2013 02:49:19 PM:
> From: Chris Wright <chrisw@...>

> To: David Meyer <dmm@...>
> Cc: tsc@...
> Date: 04/29/2013 02:49 PM
> Subject: Re: [OpenDaylight TSC] Resolving the multiple controller
> code bases issue

> Sent by: tsc-bounces@...

>
> * David Meyer (dmm@...) wrote:
> > As you may know, there have been several proposals floated to
> > deal with the problems created by the fact that we have two
> > controller code bases. These include but not limited to:
> >
> > (i).    Work on portability between code bases and maintain two
> >         controllers going forward. This would obviously create
> >         enormous challenges and inefficiencies over time. In
> >         addition, it will continue the lack of clarity over
> >         the ODP controller code base.
>
> Agreed, non-starter.
>
> > (ii).   Create a new controller project that would incorporate
> >         the desirable components of both controllers (the
> >         so-called "merged controller"). Note that the creation of
> >         such a third controller project would require extensive
> >         resources for design and integration, versus expanding on
> >         what we already have. Again, such an approach will also
> >         continue the lack of clarity over the ODP controller code
> >         base and push our deliverables out an for an undefined
> >         period of time.
>
> I actually think this is quite similar to or at least a variant of what
> you've outlined in your proposal below.
>
> > (iii).  Have the TSC vote for either the Cisco or BSN code base
> >         as the ODP controller code base. The TSC could also vote
> >         to keep the other code base available in case it ever
> >         wanted to pull parts of the other code base in.
>
> BTW, let's keep this to the projects and their developers.
> So, that is the "controller" project and the "net-virt-platform"
> project.
>
> > (iv).   Others that I might have missed?
> >
> > Clearly neither option (i). nor option (ii). reach the objective
> > of providing a clear understanding for the community of which
> > code base ODP is building on (nor would they do so in a timely
> > fashion). On the other hand, jumping directly to option (iii). is
> > not optimal as we might miss out on compromises that could be
> > beneficial to our community (as well as being more "top-down"
> > than we would like).
> >
> > Since our clear goal (and responsibility) is to make ODP into the
> > standard open source infrastructure for SDN, it is incumbent upon
> > us as the ODP TSC to take affirmative action to clear this
> > problem and get ODP moving. To that end and in consultation with
> > the Linux Foundation and others, I am formally putting the
> > following resolution process in place:
> >
> > (a).    I will ask Cisco and BSN to create a proposal for one
> >         controller code base that comprise the ODP controller
> >         code base. This "one code base" could be either code
> >         bases or a mashup of the two that Cisco and BSN feel,
> >         from a technical point of view, will best serve the ODP
> >         community. In addition, the proposal may include
> >         proposals to start other ODP projects or sub-projects to
> >         address any gaps or future work.  And of course,
> >         community members are encouraged to participate in
> >         this process.
>
> I agree.  Pushing back on the developers that own each proposal and making
> the path forward "their problem" is a tried and true way to try to positively
> engage each of the teams.  A critical component of the success of
> OpenDaylight is building community and collaboration.
>
> > (b).   The proposal should be available for TSC review no later
> >         than Monday, 13 May 2013. Of course, we should provide
> >         for flexibility in the event substantive progress is
> >         being made. That said, 13 May 2013 should be our target
> >         date.
> >
> > (c).    If no proposal can be created by Cisco and BSN (possibly
> >         working with other community members), the TSC will take
> >         an up or down vote on which controller code base ODP will
> >         be using going forward. The vote should be taken on
> >         Tuesday, 14 May 2013 by email in a private ballot to
> >         preclude the appearance of a "deciding vote" being cast
> >         by any TSC member. I propose that the Linux Foundation
> >         receive, tally, and make public all the votes and the
> >         result at the same time.
>
> I believe we'd need to have some metrics that we (the TSC) would be
> using to evaluate the code bases and make a vote that's not completely
> arbitrary or a popularity contest.  Some examples are (just throwing
> things out to be concrete):
>
> 1) controller extensibility and modularity
> 2) model driven API abstraction
> 3) ability to support eventual consistency model
> 4) ability to support multiple southbound plugins
> 5) ability to support virtual networking requirements
>
> And I see this as an absolute last resort.  Basically, if we get here
> it's because the controller and net-virt-platform teams have reached
> some fundamental impasse.
>
> > Note that it is not uncommon for an open source project such as
> > ODP to have competing code bases, nor is it uncommon for a
> > resolution such as described above to be used in these cases. In
> > particular, this process is designed to both be as true as
> > possible to the open source community and its governance model
> > while at the same time providing a forcing function to drive
> > resolution of our controller code base problem.
> >
> > Finally, I have asked Collin Dixon and David Erickson to start a
> > discussion of architectural and technical aspects of the two code
> > bases on discuss@.... Thanks Colin and David!
> > Please join in on that discussion to the extent you have
> > time/inclination. This discussion is a crucial part of building
> > our community, and we will need such an analysis in the event
> > that vote. In particular, this work will give us a technical
> > basis on which to base our votes.
>
> Yes, OK.  Let's use that to build the list I mentioned above.
>
> thanks,
> -chris
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
>


61 - 80 of 14350