1. Topics
  2. options for dealing with ODL SDNi's not meeting agreed-upon deliverables

options for dealing with ODL SDNi's not meeting agreed-upon deliverables

Colin Dixon <colin@...>
 

First, the background. During the Boron Release Review for ODL SDNi (sdninterfaceapp) and again during Carbon release planning the ODL SDNi project agreed to try to move off of a fork of the bgpcep project, which they've had internally since Lithium. Despite that, it seems as though the work isn't going to happen in Carbon.

Because of that, Robert raised this issue on behalf of the bgpcep project since they would really like to see ODL SDNi move to consuming their code in a more traditional way. I brought up that the TSC really only has 3 options:
1.) drop the ODL SDNi project from Carbon if they don't do this
2.) mark the ODL SDNi project as experimental in Carbon if they don't do this
3.) take no action

My personal take is that as long as ODL SDNi doesn't break the release for other projects (which they currently don't) it would be out of character for the TSC to drop them from the release. We certainly have the power to do it, but historically haven't done that unless a project is either totally unresponsive and/or technically cannot be included.

That being said, we have been more aggressive about marking projects that don't meet requirements (and this would seem to fit that bill) as experimental. That seems pretty reasonable to me.

It does seem, based on discussions over the past few weeks, that there is a stronger appetite to have stricter requirements for participation in future releases (starting with Nitrogen) and so this might (or might not) fit in that bin.

If people have thoughts, please chime in here.

Cheers,
--Colin
Luis Gomez <ecelgp@...>
 

I personally would like to hear from PTL or committers of sdni project before deciding the action, so if any of these are listening in their mail list please speak up.

On Mar 16, 2017, at 1:24 PM, Colin Dixon <colin@...> wrote:

First, the background. During the Boron Release Review for ODL SDNi (sdninterfaceapp) and again during Carbon release planning the ODL SDNi project agreed to try to move off of a fork of the bgpcep project, which they've had internally since Lithium. Despite that, it seems as though the work isn't going to happen in Carbon.

Because of that, Robert raised this issue on behalf of the bgpcep project since they would really like to see ODL SDNi move to consuming their code in a more traditional way. I brought up that the TSC really only has 3 options:
1.) drop the ODL SDNi project from Carbon if they don't do this
2.) mark the ODL SDNi project as experimental in Carbon if they don't do this
3.) take no action

My personal take is that as long as ODL SDNi doesn't break the release for other projects (which they currently don't) it would be out of character for the TSC to drop them from the release. We certainly have the power to do it, but historically haven't done that unless a project is either totally unresponsive and/or technically cannot be included.

That being said, we have been more aggressive about marking projects that don't meet requirements (and this would seem to fit that bill) as experimental. That seems pretty reasonable to me.

It does seem, based on discussions over the past few weeks, that there is a stronger appetite to have stricter requirements for participation in future releases (starting with Nitrogen) and so this might (or might not) fit in that bin.

If people have thoughts, please chime in here.

Cheers,
--Colin

_______________________________________________
Sdninterfaceapp-dev mailing list
Sdninterfaceapp-dev@...
https://lists.opendaylight.org/mailman/listinfo/sdninterfaceapp-dev
1 - 2 of 2