To ask what specifically would help librarians merge more. Whats your process. What can we automate further?
I notice some authors post an image of the files when they PR, or @SchrodingersGat tends to post an image of the authors work to tell them what to fix. What about a bot that attached a generated image to original pr’s and updates so you didnt have to load up the parts and screenshot?
I also notice it seems like checklib.py is the first step in checking the validity of the part. Why shouldnt a bot run that against all new PRs and comment the results?
I could go on, but maybe Im off base. And yes Im willing to do these things or others, assuming theyre helpful.
@jjrosent great idea starting this - there are similar thoughts here:
but unfortunately little in the way of a response so far.
Automation would certainly be a great approach to take. The schematic symbols (https://github.com/KiCad/kicad-library/pulls) used to be checked against the KLC script as part of a continuous-integration setup. This was super handy (but for some reason it’s not working currently - I’ve been meaning to chase that up).
Each of the .pretty repos should be set up to use the check_kicad_mod script in a similar fashion!
The KLC scripts could themselves do with an update - there are some further requirements that should be added (such as component outlines being added to fab layer, etc) and some of the KLC checks are obtuse or work obscurely.
A graphical diff would be an amazing feature. It’s quite tedious to pull-down a PR, wade through the text changes or pore through them in KiCad. Doubly so for the footprints where the git diff is mostly useless for discerning changes. This would be a most helpful feature.
I’ve been looking into automation with the github API, it’s very powerful. Short of time at the moment.
Having a written process would be really useful step forwards, there are so many PRs hanging and it is not clear who or what is needed to progress them.
There seem to be several “unwritten rules” that are not in the KLC (e.g. aesthetic considerations), and also some obvious ones missing like “pins should match the datasheet”. So I would not insist too closely on parts to automatically follow the KLC only, there are some useful guidelines but it is too incomplete to be definitive.
I also think there should be a rule to never use hidden pins, but some people positively recommend that.
How about improving kicad library editor? Setting editor defaults to library conventions, maybe even integrating checklib scripts to editor. Do you know if there are any plans to work on this?
@Andy_P@bobc@davidsrsb also agreed. On that point, the 74 series logic libraries in particular need a LOT of work. This is a rule that can easily be added to KLC, the hard work comes in fixing the legacy libraries that are in conflict of this rule.
I would suggest tag it ‘deprecated’ but not exclude their use.
KiCads hidden pins are also somewhat less hidden than some other PCB packages, where the pins are never shown on the sheet, and are accessible only via a form.
A hidden pin, that is connected on a sheet, to me is no longer a hidden pin…
There is a more valid usage, for the cooling pads of power smd packages and the tab of a to-220.
Even then there is a case that they should be presented on the schematic.
Some of this would go away if KiCad handled multi-unit parts a bit better and had the concept of NxFunction + 1xPower&Control better built in. At the moment making this sort of part is a bit clunky.
This work - if you are 100% sure to start of this work - should begin after the Eeschema rework and arise of new schematic and library format. In current format there is no real possibility to keep two functionality together (especially in 74xx, 4xxx logic series): sub-parts exchange and different sub-parts per package.
If you think - in worse case - that include visible power pins to each logic gate is a good idea, you’re wrong.
My opinion is that logic gate units should not have power pins at all. A single power and common controls module is more useful and allows a decoupling capacitor to be associated with the part on the schematic as a reminder