Some of us have been working on how to bring some of the good ideas from the ONF's Forwarding Abstractions Working Group into OpenDaylight in order to make some of the real and enable OpenDaylight to

Also, we would like to put ourselves up for a creation review for the TSC meeting two weeks from today: on 4/17. --Colin

Thanks for the proposal. Assuming you're ready to present next week (10/23), I'd like to review this proposal on the TSC call then. Does that work for you? --Colin

Hi Rex, Ultimately, this will have to be decided by the TSC, so I'm cc'ing the TSC list. --Colin

I'll put a discussion of delaying the deadline for new project proposals on the TSC agenda for next week. Also, just to point out an obvious question which is going to come up during the creation revi

Hi Andrew, I have a quick question and maybe others can chime in so we don't have to spend too much time on it during the TSC call this week. The project name is releng/builder, which, as the proposal

Hi Luis, The best documentation I'm aware of is the project lifecycle document here: http://www.opendaylight.org/project-lifecycle-releases I think the closest example to what Luis might be hinting at

Mohnish, We briefly discussed the controller refactoring as part of the TSC call last week (see bullet 10 in the minutes [0]), but I think the resolution was to have Robert Varga bring back a list of

Thanks for letting us know. I'll take them off the list for discussion. Are you still looking for feedback on the rest of the e-mail (that I've snipped off below) or are you finding that you're produc

Cool! Have you reached out the SNMP4SDN project? You can find their homepage here: (and I've also cc'ed their dev list) https://wiki.opendaylight.org/view/SNMP4SDN:Main It appears as though they are u

That's good to know and a 10 minute browsing through their code seems to imply more or less the same thing. --Colin

George is right. Existing projects should e-mail the release list (release@...) with the George listed. Existing projects DO NOT need to have another creation review to participate.

Looping in the TSC list for discussion. TSC members, depending on the discussion here, we may try to have a creation review for this project on Thursday. If there are issues we'd like to see resolved

I realize this feedback is later than you might like—17 minutes before the TSC meeting—but could you please provide ODL usernames for committers. Thanks! --Colin

My gut reaction is the following: 1.) We've typically been pretty strict about allowing for two weeks or review before projects can have a creation review and I'd like to keep that. 2.) We explicitly

So, I think it makes a lot of sense to move the NETCONF SB plugin to it's own project, but moving RESTCONF out seems... odd to me. It's as critical to the use of the MD-SAL (if not more so) than the D

I understand, but I'm not sure what you said doesn't equally apply to the AsyncDataBroker. Do we intend to also factor that out of the controller? What's left after you do that? I'm honestly curious.

Without taking a stance on any particular committer, it seems to me like it makes sense to have guidelines for how decisions like this are made. There was a lot of discussion about this on the TSC cal

I'm curious how much of this could be done by having logical sub-projects that are well-organized and well-separated within the YANG tools repository. I understand that we'd like to factor apart the v

I had also already assumed that was obvious, but it's good to point it out. --Colin