[OpenDaylight TSC] options for dealing with ODL SDNi's not meeting agreed-upon deliverables


Anil Vishnoi <vishnoianil@...>
 



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).​

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.
Also i am not sure this is really a requirement that can be enforced on the project, until and unless, as you said it creates any cross project issues.​

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. 

Cheers,
--Colin


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




--
Thanks
Anil


Thanh Ha <thanh.ha@...>
 

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 


Tai, Hideyuki <hideyuki.tai@...>
 

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 


Colin Dixon <colin@...>
 

For what it's worth the SDNi mailing list is on this thread, so hopefully somebody might respond. Otherwise, I guess one of us can ping the PTL.

--Colin


On Mon, Mar 20, 2017 at 1:33 PM, Tai, Hideyuki <hideyuki.tai@...> wrote:

I agree with Thanh, Luis, and Anil.

 

Regards,

Hideyuki Tai

 

From: tsc-bounces@lists.opendaylight.org [mailto:tsc-bounces@lists.opendaylight.org] On Behalf Of Thanh Ha
Sent: Saturday, March 18, 2017 15:10
To: Anil Vishnoi <vishnoianil@...>
Cc: sdninterfaceapp-dev@lists.opendaylight.org; bgpcep-dev@....org; 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



Gupta, Deepankar (EXT - IN/Noida) <deepankar.gupta.ext@...>
 

Hi

Please refer to mail from Sirisha (PTL)  [1] w.r.t to email chain below:

 

[1] https://lists.opendaylight.org/pipermail/sdninterfaceapp-dev/2017-March/000230.html

 

Thanks & Regards

Deepankar

 

From: sdninterfaceapp-dev-bounces@... [mailto:sdninterfaceapp-dev-bounces@...] On Behalf Of Colin Dixon
Sent: Monday, March 20, 2017 11:59 PM
To: Tai, Hideyuki <hideyuki.tai@...>
Cc: Anil Vishnoi <vishnoianil@...>; tsc@...; Thanh Ha <thanh.ha@...>; sdninterfaceapp-dev@...; bgpcep-dev@...
Subject: Re: [Sdninterfaceapp-dev] [OpenDaylight TSC] options for dealing with ODL SDNi's not meeting agreed-upon deliverables

 

For what it's worth the SDNi mailing list is on this thread, so hopefully somebody might respond. Otherwise, I guess one of us can ping the PTL.

 

--Colin

 

 

On Mon, Mar 20, 2017 at 1:33 PM, Tai, Hideyuki <hideyuki.tai@...> wrote:

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