Closed drid closed 4 years ago
This seems usefull for LOGOs, but I think it is better to live with the false positives. For some virtual components these checks do make sense. For example:
Connector_PCBEdge.pretty/Samtec_MECF-40-0_-L-DV_2x40_P1.27mm_Polarized_Edge.kicad_mod
TestPoint.pretty/TestPoint_Pad_D4.0mm.kicad_mod
I see yout point but we are using utils for CI in our libraries so false positives cause CI to fail. What if the rules are relaxed if no copper layers are used? Maybe detect the word LOGO in name or keywords?
This repo is meant to be used for the official lib. We use Travis as a helper but not as the final decision maker. Which means we can live with the occasional false positive. (We librarians can merge even with a CI error) Especially if the alternative would be that Travis would miss real errors. In this case i prefer the false positives on the rare symbol footprints as this test finds errors in footprints like edge connectors which are much more common.
I think an option would be to add some sort of attribute to libraries that controls which rules are checked. A text file (example a json or yaml file) inside the .pretty directory might be an option. I would however suggest aligning with the developers as they might have similar ideas, and we really do not want to hinder their development efforts.
I will close this for now as the presented solution goes too far as explained above. Feel free to open an issue for discussing possible ways forward.
Virtual components like LOGOs etc should be allowed to have hidden fields
This patch relaxes rules F5.1 F5.2 F5.3 regarding field visibility for virtual components