On Thu, 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.

​Yes, i think we don't have any strong reason here that can be used as a basis for opting for option (1).​

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.

 

​I think TSC should reach out to SDNi project to understand the rationale behind ​it and if they have any issues due to which they were not able to carry out this work, we can probably help them to address these issues. 

I agree with Thanh, Luis, and Anil.

 

Regards,

Hideyuki Tai

 

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Thanh Ha
Sent: Saturday, March 18, 2017 15:10
To: Anil Vishnoi <vishnoianil@...>
Cc: sdninterfaceapp-dev@...; bgpcep-dev@...; tsc@...
Subject: Re: [OpenDaylight TSC] options for dealing with ODL SDNi's not meeting agreed-upon deliverables

 

On Thu, Mar 16, 2017 at 5:32 PM, Anil Vishnoi <vishnoianil@...> wrote:

On Thu, 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.

​Yes, i think we don't have any strong reason here that can be used as a basis for opting for option (1).​

 

Agreed. I also agree with Luis in that we should hear from the project first.

 

Personally I think M5 is kind of late to be suddenly applying stricter rules if we do want to go with option 1. If a decision like that is decided it should be deferred to the next release with a clear message to the project that they will be dropped at the beginning of the next dev cycle (M0) and that they won't be added back until the task is complete.

 

 

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.

 

​I think TSC should reach out to SDNi project to understand the rationale behind ​it and if they have any issues due to which they were not able to carry out this work, we can probably help them to address these issues. 

 

Agreed. Let's hear from the project first.

 

Regards,

Thanh 

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