Would info.yaml be a logical place to record the status and date (in the case of “unmaintained” projects)?
From: [email protected] <[email protected]> On Behalf Of Thomas Kulik Sent: Wednesday, April 7, 2021 2:12 AM To: HANSEN, TONY L <[email protected]>; [email protected]; [email protected]; [email protected]; ZWARICO, AMY <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Onap-seccom] [onap-discuss] SECCOM 5 April update for PTLs >>> Are the repos for these projects marked as readonly in Gerrit? No, not consequently. Unfortunately we have (at least and as far as I know) three areas which hold project lifecycle state related information: * Gerrit repo state (active/read_only) * Wiki project lifecycle state (on project level) * INFO.yaml (more detailed; on repo level!) And they all are NOT in sync. But maybe each field has a different intention? >>> Is there a release name or date available for each of these as to when they >>> were first considered unmaintained? An example might be “beginning with the >>> Honolulu release.” I am not aware of such information but I think it would be worth to have it. Of course you can check which branch is the latest available for a specific repo. >>> It would also be good if the wiki pages that >>> https://wiki.onap.org/display/DW/Unmaintained+State+Projects<https://urldefense.com/v3/__https:/wiki.onap.org/display/DW/Unmaintained*State*Projects__;Kys!!BhdT!wHYl6KXC4aOrTiMASwyzf-flxGGYyjgkk7JhIvJDCA9tfi-FePg7jl9e4hZ5kEVw$> >>> points to were to be modified to indicate clearly that they are indeed >>> unmaintained. I am not sure what you mean with this but there is one important fact (and maybe the OOM team can jump in here): Is far as I understand it, even an “unmaintained” project/repos can be part of the “deployable release” (I call it) (e.g. Guilin) because the OOM team has to add “older” (unmaintained) components of the software in case they still play an important role. And this is also important for the docs team because we have to ensure that all documentation for all __deployed__ components is available – regardless if the deployed component is “maintained” or “unmaintained”. Hope that helps … and comments and corrections are welcome. Best regards, Thomas Von: HANSEN, TONY L <[email protected]<mailto:[email protected]>> Gesendet: Dienstag, 6. April 2021 20:40 An: [email protected]<mailto:[email protected]>; Kulik, Thomas <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; ZWARICO, AMY <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Kenny Paul <[email protected]<mailto:[email protected]>> Betreff: Re: [Onap-seccom] [onap-discuss] SECCOM 5 April update for PTLs Are the repos for these projects marked as readonly in Gerrit? Is there a release name or date available for each of these as to when they were first considered unmaintained? An example might be “beginning with the Honolulu release.” It would also be good if the wiki pages that https://wiki.onap.org/display/DW/Unmaintained+State+Projects<https://urldefense.com/v3/__https:/wiki.onap.org/display/DW/Unmaintained*State*Projects__;Kys!!BhdT!wHYl6KXC4aOrTiMASwyzf-flxGGYyjgkk7JhIvJDCA9tfi-FePg7jl9e4hZ5kEVw$> points to were to be modified to indicate clearly that they are indeed unmaintained. Examples from the CII badging folks on how to clearly mark a project as unmaintained that apply to ONAP are: For example, use “DEPRECATED” as the first heading of its README title, . . . add a no-maintenance-intended badge ( https://unmaintained.tech/<https://urldefense.com/v3/__https:/unmaintained.tech/__;!!BhdT!wHYl6KXC4aOrTiMASwyzf-flxGGYyjgkk7JhIvJDCA9tfi-FePg7jl9e4pOiqK02$> ) in its README, and/or use the code repository's marking system (e.g., . . . Gerrit's "readonly" status, . . .). Additional discussion can be found here: https://medium.com/maintainer-io/how-to-deprecate-a-repository-on-github-8f0ceb9155e<https://urldefense.com/v3/__https:/medium.com/maintainer-io/how-to-deprecate-a-repository-on-github-8f0ceb9155e__;!!BhdT!wHYl6KXC4aOrTiMASwyzf-flxGGYyjgkk7JhIvJDCA9tfi-FePg7jl9e4jRonMQk$> . - Tony From: <[email protected]<mailto:[email protected]>> on behalf of Thomas Kulik <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday, April 6, 2021 at 1:53 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "ZWARICO, AMY" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Onap-seccom] [onap-discuss] SECCOM 5 April update for PTLs Hi Fabian. A general definition can be found here: Project State: Unmaintained https://wiki.onap.org/x/Pw_LBQ<https://urldefense.com/v3/__https:/wiki.onap.org/x/Pw_LBQ__;!!BhdT!1WzY_Vl2G9rM0xKd72qWvmp9FiqA2H7oTSXX35pOEgi0h_xwh_2VihczNA$> The list of unmaintained state projects is here: https://wiki.onap.org/x/GyGLBQ<https://urldefense.com/v3/__https:/wiki.onap.org/x/GyGLBQ__;!!BhdT!1WzY_Vl2G9rM0xKd72qWvmp9FiqA2H7oTSXX35pOEgi0h_xwh_1U9xenqg$> Best regards, Thomas Von: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Gesendet: Dienstag, 6. April 2021 17:21 An: Kulik, Thomas <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; RICHOMME Morgan TGI/OLN <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Betreff: RE: [Onap-seccom] [onap-discuss] SECCOM 5 April update for PTLs Hi Thomas, Do we have a list for the ‘unmaintained project”? Br Fabian De : [email protected]<mailto:[email protected]> [mailto:[email protected]] De la part de [email protected]<mailto:[email protected]> Envoyé : mardi 6 avril 2021 14:53 À : [email protected]<mailto:[email protected]>; RICHOMME Morgan TGI/OLN <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc : [email protected]<mailto:[email protected]> Objet : Re: [Onap-seccom] [onap-discuss] SECCOM 5 April update for PTLs Just a small hint about wording: Please use „unmaintained“ instead of “in maintenance mode”. /Thomas Von: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Im Auftrag von Morgan Richomme via lists.onap.org Gesendet: Dienstag, 6. April 2021 14:07 An: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Betreff: Re: [onap-discuss] SECCOM 5 April update for PTLs last weekly report available here (it includes the RC0): https://logs.onap.org/onap-integration/weekly/onap_weekly_pod4_master/2021-04/03_22-48/security/versions/versions.html<https://urldefense.com/v3/__https:/logs.onap.org/onap-integration/weekly/onap_weekly_pod4_master/2021-04/03_22-48/security/versions/versions.html__;!!BhdT!1WzY_Vl2G9rM0xKd72qWvmp9FiqA2H7oTSXX35pOEgi0h_xwh_0JbJ5kJA$> Java 8: 24+3 (dual java8 and java11) Python 2.7: 13 + 10 (dual python 2.7 and python 3) if we look at the issues java 8 - portal: in maintenance mode since Honolulu - music: in maintenance since Guilin - msb: not sure that it is officially in maintenance but not lots of changes recently - esr: in maintenanc emode since Guilin - appc in maintenance mode since Guilin - ... python 2.7 - appc: in maintenance mode since Guilin - awx: tooling - dcae - robot: tooling - uui - vfx-huawei-vnf-driver -... I raised the question on appc in a gerrit as the HC is also regularly FAIL As far as I can see appc is still mentioned in 2 use cases (vFWDT and scaleout) but should we not - remove appc from the deployment - in the vFWDT and scaleout use case doc, if they are still maintained, indicate how to launch the old appc for the use case but not include appc in teh official honolulu deployment I know that there was a working group on this topic and that the question of dependencies is tricky..music > OOF,, MSB > CNF use cases... /Morgan ________________________________ De : [email protected]<mailto:[email protected]> [[email protected]] de la part de Amy Zwarico [[email protected]] Envoyé : lundi 5 avril 2021 17:45 À : [email protected]<mailto:[email protected]> Cc : [email protected]<mailto:[email protected]> Objet : [onap-discuss] SECCOM 5 April update for PTLs 5 April SECCOM update for the PTLs. * SECCOM is proposing that the TSC promote vulnerable package upgrade (REQ-439<https://urldefense.com/v3/__https:/jira.onap.org/browse/REQ-439__;!!BhdT!1WzY_Vl2G9rM0xKd72qWvmp9FiqA2H7oTSXX35pOEgi0h_xwh_1IbRAjJA$>) and CII Badging (REQ-443<https://urldefense.com/v3/__https:/jira.onap.org/browse/REQ-443__;!!BhdT!1WzY_Vl2G9rM0xKd72qWvmp9FiqA2H7oTSXX35pOEgi0h_xwh_1x12FqTQ$>) to Global Requirements for Istanbul. * Package upgrades will be negotiated with the PTLs based on NexusIQ reports * Package upgrades to be complete at code freeze * SECCOM Istanbul vulnerable package update recommendations will be created after Honolulu RC0/RC1 * CII badging requirements for the Istanbul release: crypto questions plus unanswered questions from prior releases * Please email SECCOM ([email protected]<mailto:[email protected]>) if you are a project with repos that do not write log files stdout. SECCOM needs this input to evaluate whether to request that the TSC promote the Logging POC (REQ-441<https://urldefense.com/v3/__https:/jira.onap.org/browse/REQ-441__;!!BhdT!1WzY_Vl2G9rM0xKd72qWvmp9FiqA2H7oTSXX35pOEgi0h_xwh_2jUkLRQw$>) to a Best Practice * The LF is setting up SonarCloud training sessions and can make those sessions available to PTLs. * Java and Python upgrade status continues to improve * Remaining (March 29) Java 8: 36/104 repos (improvement of 2 from March 4) * Remaining (March 29) Python 2: 24/63 repos (improvement of 16 from March 4) Amy Zwarico, LMTS Chief Security Office / Platform Security AT&T Services (205) 613-1667 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#23125): https://lists.onap.org/g/onap-discuss/message/23125 Mute This Topic: https://lists.onap.org/mt/81896416/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
