Skip to end of banner
Go to start of banner

2024-08-20 Meeting notes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Date

Attendees

Goals


Discussion items

TimeItemWhoNotes



  TC agreed to split off the test coverage and testing topic into a separate subgroup.
   Goals of the Subgroup:
  - 1. Review the current sonar cloud settings
           Rules für Java
           The Default Sonar Way contains 700 Rules.(157 of those are currently inactive by default).
           Only 20 of those Rules have been modified by FOLIO Administrators.
           The Changes are minor, e.g.
  • Change in the Level of Criticality if Rule fails
  • Change in a threshold level

             These changes have been made by development teams in order to get a test result which is more appropriate to the type of project

              These changes are not overall applicable to each project (a module or a set of modules), but each development teams has their own set of rule modiications.

            
              if reactive programming comes up, the guidelines will have to change
              it's down to that module what guidlines are acceptabel. Descisions need to be made by the development team
                   a pitch and agreement . A challenge of saying "we don't think it's stringent enought"
                   no immediate failure
               - settings up a new language requires setting up a set of sonar rules or whatever rules
               - Java looks different now than 20 years ago. Not allowing changes is not a good strategy.
                    - 20 Regeln sind unterschiedlich
                         nur kleine Änderungen; wahrscheinlich haben sie zu viele Warnungen bekommen
                         es repräsentiert Hürden / wir aus dem Weg geschafft
                            whether a pitch or a challenge   
                  Ingolf: TC reviews the changes to the rules / there is a TC admin for each code scanner
                           If a new language or a new code scanner, we first start from "Default" setting
                            Protect from bad actors
                    Ethan: I would accept that. Although it causes a blocker, more administrative overhead, friction
                        Not any failure is inaccaptable
              Ein anderes Modul könnte 20 andere Unterscheide haben
             Andere Code Scanner arbeiten vielleicht anders als SonarCloud
                - Default-Rules for each code scanner per language are the standard
                - the Team is free to change the rules according to their development needs, they are admins to the code scanner repository (e.g. https://sonarcloud.io/organizations/folio-org/)
                  - the changes need to be made explicit to the Reviewer and reasonably justified
                - the Reviewer is someone from the TC who does the code review
            -- if the biggest problem is to set up the static code analysis, that's a good thing
           example : a micronautic language; it might be java based, but SonarCloud is not the best scanner
           Muss man SonarCloud verwenden, wenn es ein Java-Projekt ist ?
              - modules could have multiple language
          Wenn es ein SpringWay oder Vertex-Modul ist, muss man SonarCloud verwenden: TC to vote on this ?
                we recommend springWay and vertex to use SonarCloud. If something new comes out , the module should be free to use it. It will be made explicit and reviewed by the TC. 
             Julian disagrees.
 
 



- 2. Propose a generic set of guidlines for static code analysis that is platform agnostic

The group proposes the following set of guidelines:

  • Default rules for each code scanner per language are the standard.
  • The team is free to change the rules according to their development needs.
  • The team is free to set up a new code scanner without explicit TC approval
  • The changes need to be made explicit to the reviewer and reasonably justified.
  • The reviewer is a member of the TC who does the code review
Explanations:

 The team should describe the location of the code analysis if not Sonar.




- 3. Propose edits to our current documentation concerning static code analysis to make it less sonar cloud centric

Action items

  •  
  • No labels