I would like to make an alternate proposal that is both simpler and faster: 1) Use the same Condorcet voting tool and algorithm we have used repeatedly before successfully 2) Stand all TSC Members for

And again… if you look at the thread, the vast majority of the community appear to have thought that you emailed the list to add a topic. So the real question is, do we exclude the community topic fro

Chris, My point is that this appears to have been over processed… almost all the community folks I’ve seen propose things have not followed Phil’s process (myself included frankly, all I saw was what

Phil, I think almost *everyone* missed the memo to fill out a form… the vast majority of the submission (as you can see below) came in not in that form… I’m concerned we are going to miss the vast maj

Phil, I may be scanning the spreadsheet to fast, but I think you missed these: https://lists.opendaylight.org/pipermail/tsc/2014-September/001665.html and these: https://lists.opendaylight.org/piperma

Simple Extensible Common Switch/Device Model We have a number of different projects (ovsdb, vtn, l2switch, etc) representing in various ways switch/device like things. It would be very useful to work

Forward Evolution of the Openflowplugin Discussion of future roadmap for the openflowplugin including but not limited to: 1) NB Model improvements (possibly including a model v2) 2) Allowing for alter

I would like to propose as a design summit topic: Models for Application Coexistence Right now many applications in OpenDaylight ‘take over the whole controller’ and cannot coexist with other applicat

TSC, The following should have no bearing on your decision, but is merely a notification of a mechanical fact. D4A is currently using release versions for its artifacts. This breaks autorelease after

Colin, Could we add this to the stack of things you have for Lithium Planning? Ed

TSC, Since the integration project has insufficient infra to take on much new testing, we should really figure out a way for folks to report up the system test happening elsewhere. So far I am aware o

TSC, Defense4All has made clear they are an external application, which runs outside of the OSGI container entirely and interacts only via REST calls with the controller. A such, it does not make any

Phil, One consideration.. that gets to be hugely late for the large segment of our community that is not in North America. Ed

Dave, I like this… it might also be good to talk about good patterns, when to use them, etc. Things like when to use Notifications vs DataChangeListeners etc… Ed

I’d like to through in: * v2 Java Binding Spec for Yang: (some thoughts here: https://wiki.opendaylight.org/view/YANG_Tools:Design:Binding_Specification_v2_Analysis ) * Modeling best practices * Appli

Jan, I was perhaps less clear than I should have been. This is the underlying developer infra (like Jenkins, nexus, etc)… not priorities for the code we are building :) Ed

I would like to nominate myself to run for a committer-at-large seat on the TSC: https://wiki.opendaylight.org/view/TSC:2014_Committer-At-Large_TSC_Election#Ed_Warnicke Ed

Guys, As part of the TSC, there was a request to work out Infra prioritization *hueristics* from here to Helium (longer terms priorities we can discuss after Helium gets out). My first swag would be (

I would also like to join :) Ed

There’s been a lot of confusion around API Freeze. There was a good discussion at the pre-M4 meeting, and Colin recorded the consensus here: https://lists.opendaylight.org/pipermail/release/2014-July/