Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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
           There is a Default Sonar Way and a Folio Way
           Rules für Java
              Ethan: describe the location of the code analysis if not Sonar
              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. eine generische Menge von Richtlinien beschreiben für statische Code-Analyse (Propose a generic set of guidlines for static code analysis that is platform agnostic)
  - 3. Make the documentation less sonar cloud specific (Propose edits to our current documentation concerning static code analysis to make it less sonar cloud centric)



  • Make a concrete proposal to the TC to change the Acceptance Criteria.



- 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.

...