Re: [onap-discuss] Removing the committer based on the charter

2017-07-08 Thread denghui (L) 
Hi Steve

Modeling project has already limited the number of each company to 2.

Thanks

DENG Hui

From: Stephen Terrill [mailto:stephen.terr...@ericsson.com]
Sent: Sunday, July 9, 2017 1:18 AM
To: denghui (L) ; onap-...@lists.onap.org; 
onap-discuss@lists.onap.org
Subject: RE: Removing the committer based on the charter

Hi Deng,

I agree that the text could be clearer about how to handle the project 
formation phase, however the interpretation that we could go with was what was 
discussed in the last TSC, the PTL solicits commitment from the committers and 
is that is not forthcoming than the interpretation of “or has been inactive on 
that project for an extended period (e.g. six or more months)” is that the 
contributor is not going to be active in the next six months.  Then there is 
the guidance of the number per company, in such a case the PTL could request 
that the company decides who could volunteerly removes themselves.

Best Regards,

Steve

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of denghui (L)
Sent: 07 July 2017 17:20
To: onap-...@lists.onap.org; 
onap-discuss@lists.onap.org
Subject: [onap-discuss] Removing the committer based on the charter

Hi Mazin and TSC

From our current charter approved:
https://wiki.onap.org/pages/viewpage.action?pageId=4719160&preview=%2F4719160%2F4719377%2FONAP+TSC+Charter+APPROVED+7+1+CLEAN.pdf

3.2.2.3 Removing Committers
A Committer may voluntarily resign from a project by making a public request to 
the PTL to resign (via the project and ONAP-TSC email lists).
A Committer for a project who is disruptive, or has been inactive on that 
project for an extended period (e.g., six or more months) may have his or her 
Committer status revoked by the project‟s Project Technical Leader (PTL) or by 
2/3 super-majority vote of the project’s committers.
The Project Technical Leader is responsible for informing the Technical 
Steering Committee (TSC) of any committers who are removed or resign via the 
ONAP-TSC email list.
Former committers removed for reasons other than being disruptive may be listed 
as „Emeritus Committers‟.  That title expresses gratitude for their service, 
but conveys none of the privileges of being a Committer.

I would like to get advice from our TSC how PTL could handle this, what’s the 
legal process to handle this.

I also think that this issue won’t interfere with moving forward to our 1st 
release before TSC guide us how to handle this

Thanks a lot

DENG Hui
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Removing the committer based on the charter

2017-07-08 Thread Stephen Terrill 
Hi Deng,

I agree that the text could be clearer about how to handle the project 
formation phase, however the interpretation that we could go with was what was 
discussed in the last TSC, the PTL solicits commitment from the committers and 
is that is not forthcoming than the interpretation of “or has been inactive on 
that project for an extended period (e.g. six or more months)” is that the 
contributor is not going to be active in the next six months.  Then there is 
the guidance of the number per company, in such a case the PTL could request 
that the company decides who could volunteerly removes themselves.

Best Regards,

Steve

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of denghui (L)
Sent: 07 July 2017 17:20
To: onap-...@lists.onap.org; onap-discuss@lists.onap.org
Subject: [onap-discuss] Removing the committer based on the charter

Hi Mazin and TSC

From our current charter approved:
https://wiki.onap.org/pages/viewpage.action?pageId=4719160&preview=%2F4719160%2F4719377%2FONAP+TSC+Charter+APPROVED+7+1+CLEAN.pdf

3.2.2.3 Removing Committers
A Committer may voluntarily resign from a project by making a public request to 
the PTL to resign (via the project and ONAP-TSC email lists).
A Committer for a project who is disruptive, or has been inactive on that 
project for an extended period (e.g., six or more months) may have his or her 
Committer status revoked by the project‟s Project Technical Leader (PTL) or by 
2/3 super-majority vote of the project’s committers.
The Project Technical Leader is responsible for informing the Technical 
Steering Committee (TSC) of any committers who are removed or resign via the 
ONAP-TSC email list.
Former committers removed for reasons other than being disruptive may be listed 
as „Emeritus Committers‟.  That title expresses gratitude for their service, 
but conveys none of the privileges of being a Committer.

I would like to get advice from our TSC how PTL could handle this, what’s the 
legal process to handle this.

I also think that this issue won’t interfere with moving forward to our 1st 
release before TSC guide us how to handle this

Thanks a lot

DENG Hui
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] YANG.XML format

2017-07-08 Thread Avi Chapnick 
Hi,

Some of the questions below refers to SDNC managed devices YANG schemas , which 
ODL gets  from the devices once the device is mounted.
Are we planning to allow getting customized version of those schemas from SDC  
for allowing fixing problems on the managed devices yang?

Some of the answers referred  to the yang models which are being used to define 
SDNC NB interfaces (Service RPC+ data model + storage schema)
As Dan explained today these are required in compile time and for that there is 
no sense of getting in runtime via SDC.

In APPC we do allow getting YANG schema from SDC in runtime , we are using 
these to define the structure and  the storage schema of the specific VNF APPC 
Is managing.
Loading NB yang schema dynamically to ODL is tricky , mainly as ODL is not 
providing API for that  and forces you to upload a synthetic  OSGI bundle with 
yang schema embedded.
I have started the engagement with ODL community for adding this support while 
back , if SDNC has the same interest (which makes a lot of sense to me.) maybe 
its good time to revive this discussion.

Avi,



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of TIMONEY, DAN
Sent: Saturday, July 8, 2017 4:03 AM
To: ROZIN, EDEN ; Thomas Nadeau 
; FREEMAN, BRIAN D ; NOSHPITZ, CLAUDE 
; LANDO, MICHAEL ; Kedar Ambekar 

Cc: WRIGHT, STEVEN A ; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] YANG.XML format

All,

The YANG.XML artifact type name is perhaps a bit confusing. The actual artifact 
itself is in XML format. The YANG.XML designation indicates that the structure 
of the file is defined by a Yang model. The Yang model itself isn't distributed 
by SDC.

In the case of SDNC, we need to have the Yang model available to us at compile 
time so that we can use it to generate the code to parse XML files defined by 
that model. So, right now there really wouldn't be much use at least to SDNC in 
distribution of the Yang model itself via SDC. In the longer term, though, we 
are looking into being able to handle Yang models more dynamically. So when we 
get that working, we may very well be very interested in receiving Yang models 
from SDC. But that would not be in scope for release 1.

Hope this helps,
Dan

Sent from MyOwn, an AT&T BYOD solution.


From: "ROZIN, EDEN" mailto:er4...@intl.att.com>>
Date: Thursday, July 6, 2017 at 12:50:05 PM
To: "Thomas Nadeau" 
mailto:thomas.nad...@amdocs.com>>, "FREEMAN, BRIAN D" 
mailto:bf1...@att.com>>, "NOSHPITZ, CLAUDE" 
mailto:cn5...@att.com>>, "LANDO, MICHAEL" 
mailto:ml6...@intl.att.com>>, "Kedar Ambekar" 
mailto:ake...@techmahindra.com>>
Cc: "WRIGHT, STEVEN A" mailto:sw3...@att.com>>, 
"onap-discuss@lists.onap.org" 
mailto:onap-discuss@lists.onap.org>>
Subject: Re: [onap-discuss] YANG.XML format
***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
The artifacts types are configurable, so there is a way to add 'YANG' as 
another type for artifacts upload.
All the artifacts are located inside the distributed CSAR that contain all the 
relevant Service information.
If SDN-C would like to get the artifacts, they can.

Eden

From: Thomas Nadeau [mailto:thomas.nad...@amdocs.com]
Sent: Thursday, July 06, 2017 12:26 AM
To: FREEMAN, BRIAN D mailto:bf1...@att.com>>; NOSHPITZ, CLAUDE 
mailto:cn5...@att.com>>; Lando,Michael 
mailto:ml6...@intl.att.com>>; Kedar Ambekar 
mailto:ake...@techmahindra.com>>; Rozin, Eden 
mailto:er4...@intl.att.com>>
Cc: WRIGHT, STEVEN A mailto:sw3...@att.com>>; 
onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] YANG.XML format

+1

While I'd love for all the new features in 1.1 to be available, the bottom line 
is as Brian said: actual production device support which in my estimation will 
take a bit longer.

--Tom


From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FREEMAN, BRIAN D
Sent: Wednesday, July 5, 2017 4:12 PM
To: NOSHPITZ, CLAUDE mailto:cn5...@att.com>>; LANDO, MICHAEL 
mailto:ml6...@intl.att.com>>; Kedar Ambekar 
mailto:ake...@techmahindra.com>>; ROZIN, EDEN 
mailto:er4...@intl.att.com>>
Cc: WRIGHT, STEVEN A mailto:sw3...@att.com>>; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] YANG.XML format

The industry is still on yang 1.0 so I would focus on that version for now.

Yang 1.1 is emerging and ODL Carbon has limited support for it but its very 
new. I only know of one device that supposedly supports yang 1.1.

Brian


From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of NOSHPITZ, CLAUDE
Sent: Wednesday, July 05, 2017 4:08 PM
To: LANDO, MICHAEL mailto:ml6...@intl.att.com>>; Kedar 
Ambekar