What is the reason for keeping both the generated footprint and the .yml used to generate it in the GitLab? Is it for the case where we want to update the KLC rules, and then regenerate ALL the footprints in the library accordingly using the .yml "source files"? Or is it just for others to come and grab existing .yml and modify it for their footprint so they can generate it quicker?
The questions slide (minute 24:12) where he shows that it is important to put the generated 3d model on top of the generated footprint.. shows the 3d model is not good. It shows the pin one in the wrong place regarding to the footprint.
I hope all this gets some day fused natively and easily available inside the KiCad itself so that there are clear GUI's and buttons instead of command line typing and git-stuff between me and creating a 3D model or pushing my creation to the project. I'm no stranger to git etc. but it's still not something i want to do when I'm working with electronics and then there are million others who don't want to start learning git, python, read "ancient runes" etc. but just want to get stuff done. :) But this is very very good thing to have in any professional package, so you're already long way there.
For someone that makes lots of footprints and audits many more made by others I can see why this method filters out the noise of poorly made parts. Nothing worse for design than using a component model of a part that's inaccurate, and the huge cost in money and hours lost rectifying issues that arise from that. If it was capable of doing well from a gui everyone would be doing it, but that's not the case. It's a formal method of component submission, not an easy one.
@@cdyoutoob There area better solutions to this problem. For example Altium doesn't allow you to make new footprint and add it to the library without someone (usually dedicated person) accepting the engineering change notice first. So you make part, send it through Altiums system for the one who must inspect it, accept it and THEN it's added to the library. This also creates a paper trail meaning that the creators name AND the one's who accepted it are in the ledger. If company loses 10k because one or both of them didn't do their jobs... Yeah. So that same flow will work for Kicad. If we're talking about open source library, then we obviously are talking about different scales, but the same idea applies that someone has to write off your work first and THEN it's allowed. If they messed up, heads roll :)
@@cdyoutoob Using git for content submission is creating unnecessary friction. Ideally, the only barrier for footprint submission should be the audit itself. And the audit should be streamlined for the auditor too. The actual problem i have with the way it is now, is that the auditors have to manually check out the changes using git, load the symbol/footprint and can only then have their back-and-forth with the contributers. These extra steps make the process highly inefficient and slow. The submission process should be streamlined through a built-in KiCAD utility with pre-defined fields that you fill out and a 2d/3d preview for your footprint. Submissions should only be possible after registering with a valid email, to avoid spam and to track how many footprints have been successfully submitted by that user already. This allows the auditors to then focus on reliable contributers first.
Hi! Nice video. But the link or slides is not working, it would be super nice if someone fixed it. Thanks :)
What is the reason for keeping both the generated footprint and the .yml used to generate it in the GitLab? Is it for the case where we want to update the KLC rules, and then regenerate ALL the footprints in the library accordingly using the .yml "source files"? Or is it just for others to come and grab existing .yml and modify it for their footprint so they can generate it quicker?
The questions slide (minute 24:12) where he shows that it is important to put the generated 3d model on top of the generated footprint.. shows the 3d model is not good. It shows the pin one in the wrong place regarding to the footprint.
Oh, minute 31, someone just mentioned it. Nice! haha
I hope all this gets some day fused natively and easily available inside the KiCad itself so that there are clear GUI's and buttons instead of command line typing and git-stuff between me and creating a 3D model or pushing my creation to the project.
I'm no stranger to git etc. but it's still not something i want to do when I'm working with electronics and then there are million others who don't want to start learning git, python, read "ancient runes" etc. but just want to get stuff done. :)
But this is very very good thing to have in any professional package, so you're already long way there.
For someone that makes lots of footprints and audits many more made by others I can see why this method filters out the noise of poorly made parts. Nothing worse for design than using a component model of a part that's inaccurate, and the huge cost in money and hours lost rectifying issues that arise from that. If it was capable of doing well from a gui everyone would be doing it, but that's not the case. It's a formal method of component submission, not an easy one.
and who is stupid enough to do all this by clicking like a monkey?
@@cdyoutoob There area better solutions to this problem. For example Altium doesn't allow you to make new footprint and add it to the library without someone (usually dedicated person) accepting the engineering change notice first. So you make part, send it through Altiums system for the one who must inspect it, accept it and THEN it's added to the library. This also creates a paper trail meaning that the creators name AND the one's who accepted it are in the ledger. If company loses 10k because one or both of them didn't do their jobs... Yeah. So that same flow will work for Kicad.
If we're talking about open source library, then we obviously are talking about different scales, but the same idea applies that someone has to write off your work first and THEN it's allowed. If they messed up, heads roll :)
@@cdyoutoob Using git for content submission is creating unnecessary friction. Ideally, the only barrier for footprint submission should be the audit itself. And the audit should be streamlined for the auditor too.
The actual problem i have with the way it is now, is that the auditors have to manually check out the changes using git, load the symbol/footprint and can only then have their back-and-forth with the contributers. These extra steps make the process highly inefficient and slow. The submission process should be streamlined through a built-in KiCAD utility with pre-defined fields that you fill out and a 2d/3d preview for your footprint. Submissions should only be possible after registering with a valid email, to avoid spam and to track how many footprints have been successfully submitted by that user already. This allows the auditors to then focus on reliable contributers first.