Sdninterfaceapp-dev Digest, Vol 31, Issue 3


Sirisha Sangam
 

Hi,

We are already working on the bug 6202 to remove the dependency of bgpcep from sdninterfaceapp. Internal testing is going on and we will be submitting the patch by M5 offset 2 date. We had all the resources who are working on sdninterfaceapp being moved to the project assignments with which is the delay in submitting the patch.



Thanks & Regards
Sirisha Sangam
Tata Consultancy Services
Cell:- +91-9912487880
Mailto: sirisha.sangam@...
Website: http://www.tcs.com


-----sdninterfaceapp-dev-bounces@... wrote: -----
To: sdninterfaceapp-dev@...
From: sdninterfaceapp-dev-request@...
Sent by: sdninterfaceapp-dev-bounces@...
Date: 03/17/2017 05:30PM
Subject: Sdninterfaceapp-dev Digest, Vol 31, Issue 3

Send Sdninterfaceapp-dev mailing list submissions to
sdninterfaceapp-dev@...

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.opendaylight.org/mailman/listinfo/sdninterfaceapp-dev
or, via email, send a message with subject or body 'help' to
sdninterfaceapp-dev-request@...

You can reach the person managing the list at
sdninterfaceapp-dev-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sdninterfaceapp-dev digest..."


Today's Topics:

   1. options for dealing with ODL SDNi's not meeting agreed-upon
      deliverables (Colin Dixon)
   2. Re: options for dealing with ODL SDNi's not meeting
      agreed-upon deliverables (Luis Gomez)
   3. Re: [OpenDaylight TSC] options for dealing with ODL SDNi's
      not meeting agreed-upon deliverables (Anil Vishnoi)


----------------------------------------------------------------------

Message: 1
Date: Thu, 16 Mar 2017 15:24:01 -0500
From: Colin Dixon <colin@...>
To: "tsc@..." <tsc@...>,
sdninterfaceapp-dev@...,
"bgpcep-dev@..."
<bgpcep-dev@...>
Subject: [Sdninterfaceapp-dev] options for dealing with ODL SDNi's not
meeting agreed-upon deliverables
Message-ID:
<CANPTM8HexL04ZwdP8FgmbfgA6kps1s+1cCaA17qB5KtKCBvntA@...>
Content-Type: text/plain; charset="utf-8"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sdninterfaceapp-dev/attachments/20170316/2401225d/attachment-0001.html>

------------------------------

Message: 2
Date: Thu, 16 Mar 2017 14:03:44 -0700
From: Luis Gomez <ecelgp@...>
To: Colin Dixon <colin@...>
Cc: "tsc@..." <tsc@...>,
sdninterfaceapp-dev@...,
"bgpcep-dev@..."
<bgpcep-dev@...>
Subject: Re: [Sdninterfaceapp-dev] options for dealing with ODL SDNi's
not meeting agreed-upon deliverables
Message-ID: <27FCA60E-AA6E-4280-AE3E-CC0D31A5006C@...>
Content-Type: text/plain; charset=us-ascii

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



------------------------------

Message: 3
Date: Thu, 16 Mar 2017 14:32:43 -0700
From: Anil Vishnoi <vishnoianil@...>
To: Colin Dixon <colin@...>
Cc: "tsc@..." <tsc@...>,
sdninterfaceapp-dev@...,
"bgpcep-dev@..."
<bgpcep-dev@...>
Subject: Re: [Sdninterfaceapp-dev] [OpenDaylight TSC] options for
dealing with ODL SDNi's not meeting agreed-upon deliverables
Message-ID:
<CAN-WPTsnK8J_vApi8p9p5Tkk-tNNkNDRXNYqHGdzCt+kh=K-Mg@...>
Content-Type: text/plain; charset="utf-8"


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sdninterfaceapp-dev/attachments/20170316/b50c5e0e/attachment-0001.html>

------------------------------

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


End of Sdninterfaceapp-dev Digest, Vol 31, Issue 3
**************************************************

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you