[onap-tsc] ArchCom: Weekly Meeting agenda for Tuesday June 09, 2020 - 14:00 UTC (https://zoom.us/j/608270884)

2020-06-05 Thread Chaker Al-Hakim
June 02, 2020 - 14:00 UTC (https://zoom.us/j/608270884)

Hello Team,

The ArchCom weekly meeting agenda for Tuesday June 09,  2020, 14:00 UTC can be 
found here:   
https://wiki.onap.org/display/DW/2020-06-09+ONAP+Architecture+Meeting

Please review the agenda and the topics carefully and plan to attend the 
reviews if you believe your functional area(s) could be impacted by the topics 
that are being reviewed.

The agenda is over-subscribed and we will try to review as many topics as 
possible starting with the carry-over topic from last week.

Regards,
Chaker


Meeting Logistics (Tuesdays 14:00 UTC: see here for joining): 
https://wiki.onap.org/display/DW/Architecture+Subcommittee+Meeting)


 *   14:00 UTC



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6496): https://lists.onap.org/g/onap-tsc/message/6496
Mute This Topic: https://lists.onap.org/mt/74706668/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

2020-06-05 Thread Kenny Paul
>From my POV, setting it as a TSC policy is the simplest approach. 

Order of operations for this stuff is:

*   LFN Charter <- Legal document over LFN
*   ONAP Charter -< Legal document over ONAP
*   ONAP Community Document <-  Rules for community management
*   TSC Policies <-  Operational best practices to be followed

 

The first 3 all require legal review.

-kenny

 

From: onap-tsc@lists.onap.org  On Behalf Of Jason Hunt
Sent: Friday, June 5, 2020 12:46 PM
To: onap-tsc@lists.onap.org
Cc: az9...@att.com; k.opas...@samsung.com; onap-rele...@lists.onap.org; 
onap-tsc@lists.onap.org; p.paw...@f5.com
Subject: Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

 

 

I don't think we'd want to codify that list of criteria into the technical 
community document, so what we might want to do is amend the document to 
require a Security Subcommittee review prior to a project moving to the mature 
or core phases.  This would need to be voted on by the TSC.  Should we cover it 
in the next TSC meeting?




Regards,
Jason Hunt
Distinguished Engineer, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com  
Twitter: @DJHunt

 

 

- Original message -
From: "Sylvain Desbureaux via lists.onap.org" 
mailto:sylvain.desbureaux=orange@lists.onap.org> >
Sent by: onap-tsc@lists.onap.org  
To: Krzysztof Opasiak mailto:k.opas...@samsung.com> >, 
"onap-tsc@lists.onap.org  " 
mailto:onap-tsc@lists.onap.org> >
Cc: "az9...@att.com  " mailto:az9...@att.com> >, "onap-rele...@lists.onap.org 
 " mailto:onap-rele...@lists.onap.org> >, "p.paw...@f5.com 
 " mailto:p.paw...@f5.com> >
Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle: recommended actions
Date: Fri, Jun 5, 2020 10:08 AM


+1
and one day we may need to be able to add new criterias for the ops
(I'm thinking opentracing compatibility, prometheus endpoints, ...)

De : Krzysztof Opasiak [k.opas...@samsung.com]
Envoyé : vendredi 5 juin 2020 16:53
À : onap-tsc@lists.onap.org  
Cc : az9...@att.com  ; onap-rele...@lists.onap.org 
 ; p.paw...@f5.com  
; DESBUREAUX Sylvain TGI/OLN
Objet : Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

... and correct Pawel Pawlak email;)


On 05.06.2020 16:53, Krzysztof Opasiak wrote:
> Hi Jason,
>
> On 05.06.2020 16:27, Jason Hunt wrote:
>>Krzysztof,
>> Great point.  There are two options to address it:
>> 1. The TSC votes to amend the Technical Community Document to include
>> security in the criteria for the mature state
>> 2.  We modify the template for the maturity reviews to allow for
>> security information to be included under the "mature artifacts"
>> criteria.  The TSC would then include that in its decision whether a
>> project has met the "mature artifacts" portion of the criteria.
>
> I'll deffer this to Pawel & Amy to decide which way to go.
>
>> I would prefer the latter and am happy to make the update.  Please let
>> me know if there is suggested input you would like to see from projects
>> so that we can update the template accordingly.
>
> I'd definitely would like to make sure that before any project is called
> mature it:
>
> 1) Does not hardcode any credentials in the container & OOM helm charts
> 2) Its docker containers are free of any hardcoded certificates
> 3) It doesn't use static TLS certificates but obtains them at runtime
> 4) It has no open OJSI tickets
> 5) It has no known vulnerabilities in its direct dependencies
> 6) It uses base image that is free of license violation and
> vulnerabilities (aka recommended by seccom)
> 7) Does not run as a root
> 8) Does not access any DB as root from the application container (unless
> there is a valid reason for that which has been presented & approved by
> SECCOM)
> 9) Does not access any DB that is owned by other service
> 10) Uses only well-known, open source libraries for handling crypto
> 11) Does not contain its own user store
> 12) Can be access & used via ingress controller
> 13) Has no runtime Internet dependencies
> 14) Use secure communication to access anything that is outside of
> kubernetes cluster
> 15) Has no unprotected APIs/UIs exposed
> 16) Has only a single process per container
> 17) Has properly configured liveness & readiness checks
> 18) Container rootfs is mounted read-only
>
> @Pawel
> @Amy
> Do you have anything more to add?
>
>> By the way, for the "core" state of projects (which comes after
>> "mature"), the criteria in the Technical Community Document include:
>> "Stability, Security, Scalability and Performance levels have reached a
>> high bar."
>
> Right. But it would be great to ensure some "basic" security from
> project which is called mature right?
>
>>
>> 

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

2020-06-05 Thread Eric Debeau via lists.onap.org
Hello

I believe that we need more formal proof of maturity checked by tools to avoid 
any dispute.


›Successful participation in releases: The project demonstrates stable output 
(code base, documents) within its history of releases in accordance with the 
release policy.

=> How to check that a document is stable ?


›Architecture has been reviewed by the Architecture Committee => It do not see 
a proof a maturity. Every project should pass the Architecture Review and can 
claim to become mature. We should state the project passed the Architecture 
Committe


›Project is active and contributes to ONAP: The project demonstrates a stable 
or increasing number of contributions across recent releases. Contributions are 
commits which got merged to a repository of an ONAP project or a related 
upstream project. Commits can for example be patches to update the requirements 
document of a project, code addition to an ONAP or upstream project repository, 
new test cases and so forth.

=> OK. It is easy to check with bitergia


›Mature artifacts produced: The project demonstrates that the artifacts 
produced by the project are deployable (where applicable) and have been 
successfully deployed, configured and used by end users (typically, service 
providers).

=> Any project can claim that if they are in the release !
=> We need more technical proofs : eg code quality, test coverage...

Best Regards

Eric

De : onap-tsc@lists.onap.org [onap-tsc@lists.onap.org] de la part de Jason Hunt 
[djh...@us.ibm.com]
Envoyé : vendredi 5 juin 2020 21:45
À : onap-tsc@lists.onap.org
Cc : az9...@att.com; k.opas...@samsung.com; onap-rele...@lists.onap.org; 
onap-tsc@lists.onap.org; p.paw...@f5.com
Objet : Re: [onap-tsc] ONAP Project Lifecycle: recommended actions


I don't think we'd want to codify that list of criteria into the technical 
community document, so what we might want to do is amend the document to 
require a Security Subcommittee review prior to a project moving to the mature 
or core phases.  This would need to be voted on by the TSC.  Should we cover it 
in the next TSC meeting?


Regards,
Jason Hunt
Distinguished Engineer, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt


- Original message -
From: "Sylvain Desbureaux via lists.onap.org" 

Sent by: onap-tsc@lists.onap.org
To: Krzysztof Opasiak , "onap-tsc@lists.onap.org" 

Cc: "az9...@att.com" , "onap-rele...@lists.onap.org" 
, "p.paw...@f5.com" 
Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle: recommended actions
Date: Fri, Jun 5, 2020 10:08 AM

+1
and one day we may need to be able to add new criterias for the ops
(I'm thinking opentracing compatibility, prometheus endpoints, ...)

De : Krzysztof Opasiak [k.opas...@samsung.com]
Envoyé : vendredi 5 juin 2020 16:53
À : onap-tsc@lists.onap.org
Cc : az9...@att.com; onap-rele...@lists.onap.org; p.paw...@f5.com; DESBUREAUX 
Sylvain TGI/OLN
Objet : Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

... and correct Pawel Pawlak email;)


On 05.06.2020 16:53, Krzysztof Opasiak wrote:
> Hi Jason,
>
> On 05.06.2020 16:27, Jason Hunt wrote:
>>Krzysztof,
>> Great point.  There are two options to address it:
>> 1. The TSC votes to amend the Technical Community Document to include
>> security in the criteria for the mature state
>> 2.  We modify the template for the maturity reviews to allow for
>> security information to be included under the "mature artifacts"
>> criteria.  The TSC would then include that in its decision whether a
>> project has met the "mature artifacts" portion of the criteria.
>
> I'll deffer this to Pawel & Amy to decide which way to go.
>
>> I would prefer the latter and am happy to make the update.  Please let
>> me know if there is suggested input you would like to see from projects
>> so that we can update the template accordingly.
>
> I'd definitely would like to make sure that before any project is called
> mature it:
>
> 1) Does not hardcode any credentials in the container & OOM helm charts
> 2) Its docker containers are free of any hardcoded certificates
> 3) It doesn't use static TLS certificates but obtains them at runtime
> 4) It has no open OJSI tickets
> 5) It has no known vulnerabilities in its direct dependencies
> 6) It uses base image that is free of license violation and
> vulnerabilities (aka recommended by seccom)
> 7) Does not run as a root
> 8) Does not access any DB as root from the application container (unless
> there is a valid reason for that which has been presented & approved by
> SECCOM)
> 9) Does not access any DB that is owned by other service
> 10) Uses only well-known, open source libraries for handling crypto
> 11) Does not contain its own user store
> 12) Can be access & used via ingress controller
> 13) Has no runtime Internet dependencies
> 14) Use secure communication to access anything that is outside of
> kubernetes cluster
> 15) Has no 

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

2020-06-05 Thread David McBride
Hi Jason,

This has been added as an agenda item for Mondays’s PTL meeting.

David

On Thu, Jun 4, 2020 at 3:13 PM Jason Hunt  wrote:

>
> TSC and PTLs,
>
> Per the discussion in today's TSC meeting, we wanted to make everyone
> aware of the ONAP project lifecycle and encourage projects to consider
> their status and any changes.
>
> The current lifecycle is depicted in this diagram:
>
>
>
> The suggestion is that we use this lifecycle to place the ONAP project
> portfolio into three buckets:
>
>
>
> - *Mature projects:* for projects with active release participation &
> solid artifacts; they should submit for a "maturity review"
>
> - *Inactive (Archived) projects*: for projects where there is no longer
> any contributions, they should follow the termination review
>
> - *Other (Incubation) projects*: for those projects that are still active
> but not ready for move to "mature" phase
>
>
>
> For *mature projects*, the TSC encourages qualifying projects to submit
> for a maturity review.  They do this by filling out the template in the
> wiki (https://wiki.onap.org/display/DW/Project+Maturity+Review+Template)
> and send an email to the TSC list.  In order to accelerate reviews (and
> free up time on the TSC calls), we may want to form a working group to do a
> preliminary maturity review for the projects.  The group would submit their
> recommendations to the TSC who would then vote +1/0/-1 for promotion to the
> mature phase.
>
>
> For the *inactive projects*, there is no guidance on who should initiate
> a termination review.  Because there may not be a PTL, perhaps the TSC
> could initiate a termination review for a project.  Again, we may want a
> working group to conduct the steps of the termination review.  This group
> should consist of people who are familiar with the project or at least
> interface with/depend upon the project.  This working group will need to
> walk through the steps of the termination review as outlined here: (scroll
> down)
>
> https://wiki.onap.org/display/DW/ONAP+Project+and+Component+Lifecycle
>
>
>
> All other projects need no action.
>
>
>
> Background slide deck on project lifecycle reviews:
> https://wiki.lfnetworking.org/pages/viewpage.action?pageId=25364127=/25364127/28738708/ONAP%20Proj%20Lifecycle%20and%20Review%2015Jan2020%20v1.pdf
> 
>
>
> Please reply with any questions on the process.
>
>
> Regards,
> Jason Hunt
> Distinguished Engineer, IBM
>
> Phone: +1-314-749-7422
> Email: djh...@us.ibm.com
> Twitter: @DJHunt
>
> 
>
> --
*David McBride*
Release Manager
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
IRC: dmcbride

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6492): https://lists.onap.org/g/onap-tsc/message/6492
Mute This Topic: https://lists.onap.org/mt/74681700/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[onap-tsc] Update on Frankfurt Release Status #frankfurt

2020-06-05 Thread David McBride
Team,

I wanted to update you on the status of the Frankfurt release.

Last week, the TSC agreed to combine the RC2 and Sign-Off milestones. This
week, on Monday and again on Thursday, the TSC reviewed the status of RC2.
The conclusion was that RC2 remains NO GO.  However, we are very close to
meeting RC2 requirements.  Therefore, the TSC will review status again on
Monday, June 8, during the PTL meeting.

Thanks to all of the project teams and integration test leads for your hard
work in getting to this point.  I will update you again after our meeting
on Monday.

Please let me know if you have any questions.

David

-- 
*David McBride*
Release Manager
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
IRC: dmcbride

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6491): https://lists.onap.org/g/onap-tsc/message/6491
Mute This Topic: https://lists.onap.org/mt/74695588/21656
Mute #frankfurt: https://lists.onap.org/mk?hashtag=frankfurt=2743226
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

2020-06-05 Thread Krzysztof Opasiak via lists.onap.org
... and correct Pawel Pawlak email;)


On 05.06.2020 16:53, Krzysztof Opasiak wrote:
> Hi Jason,
> 
> On 05.06.2020 16:27, Jason Hunt wrote:
>>    Krzysztof,
>> Great point.  There are two options to address it:
>> 1. The TSC votes to amend the Technical Community Document to include
>> security in the criteria for the mature state
>> 2.  We modify the template for the maturity reviews to allow for
>> security information to be included under the "mature artifacts"
>> criteria.  The TSC would then include that in its decision whether a
>> project has met the "mature artifacts" portion of the criteria.
> 
> I'll deffer this to Pawel & Amy to decide which way to go.
> 
>> I would prefer the latter and am happy to make the update.  Please let
>> me know if there is suggested input you would like to see from projects
>> so that we can update the template accordingly.
> 
> I'd definitely would like to make sure that before any project is called
> mature it:
> 
> 1) Does not hardcode any credentials in the container & OOM helm charts
> 2) Its docker containers are free of any hardcoded certificates
> 3) It doesn't use static TLS certificates but obtains them at runtime
> 4) It has no open OJSI tickets
> 5) It has no known vulnerabilities in its direct dependencies
> 6) It uses base image that is free of license violation and
> vulnerabilities (aka recommended by seccom)
> 7) Does not run as a root
> 8) Does not access any DB as root from the application container (unless
> there is a valid reason for that which has been presented & approved by
> SECCOM)
> 9) Does not access any DB that is owned by other service
> 10) Uses only well-known, open source libraries for handling crypto
> 11) Does not contain its own user store
> 12) Can be access & used via ingress controller
> 13) Has no runtime Internet dependencies
> 14) Use secure communication to access anything that is outside of
> kubernetes cluster
> 15) Has no unprotected APIs/UIs exposed
> 16) Has only a single process per container
> 17) Has properly configured liveness & readiness checks
> 18) Container rootfs is mounted read-only
> 
> @Pawel
> @Amy
> Do you have anything more to add?
> 
>> By the way, for the "core" state of projects (which comes after
>> "mature"), the criteria in the Technical Community Document include:
>> "Stability, Security, Scalability and Performance levels have reached a
>> high bar."
> 
> Right. But it would be great to ensure some "basic" security from
> project which is called mature right?
> 
>>
>> Regards,
>> Jason Hunt
>> Distinguished Engineer, IBM
>>
>> Phone: +1-314-749-7422
>> Email: djh...@us.ibm.com
>> Twitter: @DJHunt
>>
>>  - Original message -
>>  From: "Krzysztof Opasiak via lists.onap.org"
>>  
>>  Sent by: onap-tsc@lists.onap.org
>>  To: onap-tsc@lists.onap.org, onap-rele...@lists.onap.org, Jason Hunt
>>  
>>  Cc: "pawel.pawl...@orange.com" , "ZWARICO,
>>  AMY" 
>>  Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle:
>>  recommended actions
>>  Date: Fri, Jun 5, 2020 9:05 AM
>>  Hi Jason,
>>
>>  On 05.06.2020 00:13, Jason Hunt wrote:
>>   > TSC and PTLs,
>>   > Per the discussion in today's TSC meeting, we wanted to make everyone
>>   > aware of the ONAP project lifecycle and encourage projects to
>>  consider
>>   > their status and any changes.
>>   > The current lifecycle is depicted in this diagram:
>>   >
>>   > The suggestion is that we use this lifecycle to place the ONAP
>>  project
>>   > portfolio into three buckets:
>>   >
>>   > -*Mature projects:*for projects with active release participation &
>>   > solid artifacts; they should submit for a "maturity review"
>>   >
>>   > - *Inactive (Archived) projects*: for projects where there is no
>>  longer
>>   > any contributions, they should follow the termination review
>>   >
>>   > -*Other (Incubation) projects*: for those projects that are still
>>  active
>>   > but not ready for move to "mature" phase
>>   >
>>   > For *mature projects*, the TSC encourages qualifying projects to
>>  submit
>>   > for a maturity review.  They do this by filling out the template
>>  in the
>>   > wiki
>>  (https://wiki.onap.org/display/DW/Project+Maturity+Review+Template
>>  
>> 
>>
>>   >
>>  
>> >  >)
>>   > and send an email to the TSC list.  In order to accelerate
>>  reviews (and
>>   > free up time on the TSC calls), we may want to form a working
>>  group to
>>   > do a preliminary maturity review for 

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

2020-06-05 Thread Jason Hunt
 Krzysztof,
 
Great point.  There are two options to address it:
 
1. The TSC votes to amend the Technical Community Document to include security in the criteria for the mature state
2.  We modify the template for the maturity reviews to allow for security information to be included under the "mature artifacts" criteria.  The TSC would then include that in its decision whether a project has met the "mature artifacts" portion of the criteria.
 
I would prefer the latter and am happy to make the update.  Please let me know if there is suggested input you would like to see from projects so that we can update the template accordingly.
 
By the way, for the "core" state of projects (which comes after "mature"), the criteria in the Technical Community Document include:
 
"Stability, Security, Scalability and Performance levels have reached a high bar."
 
Regards,Jason HuntDistinguished Engineer, IBMPhone: +1-314-749-7422Email: djh...@us.ibm.comTwitter: @DJHunt
 
 
- Original message -From: "Krzysztof Opasiak via lists.onap.org" Sent by: onap-tsc@lists.onap.orgTo: onap-tsc@lists.onap.org, onap-rele...@lists.onap.org, Jason Hunt Cc: "pawel.pawl...@orange.com" , "ZWARICO, AMY" Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle: recommended actionsDate: Fri, Jun 5, 2020 9:05 AM 
Hi Jason,On 05.06.2020 00:13, Jason Hunt wrote:> TSC and PTLs,> Per the discussion in today's TSC meeting, we wanted to make everyone> aware of the ONAP project lifecycle and encourage projects to consider> their status and any changes.> The current lifecycle is depicted in this diagram:>> The suggestion is that we use this lifecycle to place the ONAP project> portfolio into three buckets:>> -*Mature projects:*for projects with active release participation &> solid artifacts; they should submit for a "maturity review">> - *Inactive (Archived) projects*: for projects where there is no longer> any contributions, they should follow the termination review>> -*Other (Incubation) projects*: for those projects that are still active> but not ready for move to "mature" phase>> For *mature projects*, the TSC encourages qualifying projects to submit> for a maturity review.  They do this by filling out the template in the> wiki (https://wiki.onap.org/display/DW/Project+Maturity+Review+Template  > )> and send an email to the TSC list.  In order to accelerate reviews (and> free up time on the TSC calls), we may want to form a working group to> do a preliminary maturity review for the projects.  The group> would submit their recommendations to the TSC who would then vote> +1/0/-1 for promotion to the mature phase.Shouldn't we have any security review before we move project to themature state? There is no single question regarding security in thistemplate...>> For the*inactive projects*, there is no guidance on who should initiate> a termination review.  Because there may not be a PTL, perhaps the TSC> could initiate a termination review for a project.  Again, we may want a> working group to conduct the steps of the termination review.  This> group should consist of people who are familiar with the project or at> least interface with/depend upon the project.  This working group will> need to walk through the steps of the termination review as outlined> here: (scroll down)>> https://wiki.onap.org/display/DW/ONAP+Project+and+Component+Lifecycle  > >> All other projects need no action.>> Background slide deck on project lifecycle reviews:> https://wiki.lfnetworking.org/pages/viewpage.action?pageId=25364127=/25364127/28738708/ONAP%20Proj%20Lifecycle%20and%20Review%2015Jan2020%20v1.pdf  > >> Please reply with any questions on the process.>> Regards,> Jason Hunt> Distinguished Engineer, IBM>> Phone: +1-314-749-7422> Email: djh...@us.ibm.com> Twitter: @DJHunt>>--Krzysztof OpasiakSamsung R Institute PolandSamsung Electronics 
 


_._,_._,_

Links:


You receive all messages sent to this group.





View/Reply Online (#6487) |


  Reply To Group

| Reply To Sender



|

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

2020-06-05 Thread Krzysztof Opasiak via lists.onap.org
Hi Jason,

On 05.06.2020 00:13, Jason Hunt wrote:
> TSC and PTLs,
> Per the discussion in today's TSC meeting, we wanted to make everyone 
> aware of the ONAP project lifecycle and encourage projects to consider 
> their status and any changes.
> The current lifecycle is depicted in this diagram:
> 
> The suggestion is that we use this lifecycle to place the ONAP project 
> portfolio into three buckets:
> 
> -*Mature projects:*for projects with active release participation & 
> solid artifacts; they should submit for a "maturity review"
> 
> - *Inactive (Archived) projects*: for projects where there is no longer 
> any contributions, they should follow the termination review
> 
> -*Other (Incubation) projects*: for those projects that are still active 
> but not ready for move to "mature" phase
> 
> For *mature projects*, the TSC encourages qualifying projects to submit 
> for a maturity review.  They do this by filling out the template in the 
> wiki (https://wiki.onap.org/display/DW/Project+Maturity+Review+Template 
> )
>  
> and send an email to the TSC list.  In order to accelerate reviews (and 
> free up time on the TSC calls), we may want to form a working group to 
> do a preliminary maturity review for the projects.  The group 
> would submit their recommendations to the TSC who would then vote 
> +1/0/-1 for promotion to the mature phase.

Shouldn't we have any security review before we move project to the 
mature state? There is no single question regarding security in this 
template...

> 
> For the*inactive projects*, there is no guidance on who should initiate 
> a termination review.  Because there may not be a PTL, perhaps the TSC 
> could initiate a termination review for a project.  Again, we may want a 
> working group to conduct the steps of the termination review.  This 
> group should consist of people who are familiar with the project or at 
> least interface with/depend upon the project.  This working group will 
> need to walk through the steps of the termination review as outlined 
> here: (scroll down)
> 
> https://wiki.onap.org/display/DW/ONAP+Project+and+Component+Lifecycle 
> 
> 
> All other projects need no action.
> 
> Background slide deck on project lifecycle reviews: 
> https://wiki.lfnetworking.org/pages/viewpage.action?pageId=25364127=/25364127/28738708/ONAP%20Proj%20Lifecycle%20and%20Review%2015Jan2020%20v1.pdf
>  
> 
> 
> Please reply with any questions on the process.
> 
> Regards,
> Jason Hunt
> Distinguished Engineer, IBM
> 
> Phone: +1-314-749-7422
> Email: djh...@us.ibm.com
> Twitter: @DJHunt
> 
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6486): https://lists.onap.org/g/onap-tsc/message/6486
Mute This Topic: https://lists.onap.org/mt/74681700/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [onap-tsc] Stepping down as VF-C PTL role

2020-06-05 Thread Kenny Paul
Thank you Yan Yang.

Best wishes on your new role.

-kenny

 

 

From: onap-tsc@lists.onap.org  On Behalf Of Yan
Yang
Sent: Thursday, June 4, 2020 11:20 PM
To: onap-tsc@lists.onap.org; onap-disc...@lists.onap.org
Subject: [onap-tsc] Stepping down as VF-C PTL role

 

Dear TSC,

 

Due to a shift in my role and responsibilities within the company, I want to
let you know that I'm stepping down as the PTL of the VF-C project effective
today (June 5, 2020).But I would be delighted to help with any last minute
activity that comes up for the sign off of ONAP Frankfurt release. 

 

Thanks again for giving me the opportunity to serve as the PTL for VF-C
projet in the past six releases and it is really a wonderful journey to work
with everyone in the community.

 

As required by the process, I will follow the official ONAP process for the
next VF-C PTL elections as soon as I can.

 

 

 

Thanks and Regards,

Yan Yang




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6485): https://lists.onap.org/g/onap-tsc/message/6485
Mute This Topic: https://lists.onap.org/mt/74687908/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[onap-tsc] Requirements subcommittee meeting on June 8 will be cancelled due to conflicting TSC meeting scheduled for the same time

2020-06-05 Thread Alla Goldner
The following one will be during the online DDF - once schedule and agenda are 
in place, I will contact the group.

Best regards, Alla
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6484): https://lists.onap.org/g/onap-tsc/message/6484
Mute This Topic: https://lists.onap.org/mt/74692023/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[onap-tsc] Stepping down as VF-C PTL role

2020-06-05 Thread Yan Yang
Dear TSC,

 

Due to a shift in my role and responsibilities within the company, I want to
let you know that I'm stepping down as the PTL of the VF-C project effective
today (June 5, 2020).But I would be delighted to help with any last minute
activity that comes up for the sign off of ONAP Frankfurt release. 

 

Thanks again for giving me the opportunity to serve as the PTL for VF-C
projet in the past six releases and it is really a wonderful journey to work
with everyone in the community.

 

As required by the process, I will follow the official ONAP process for the
next VF-C PTL elections as soon as I can.

 

 

 

Thanks and Regards,

Yan Yang


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6483): https://lists.onap.org/g/onap-tsc/message/6483
Mute This Topic: https://lists.onap.org/mt/74687908/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-