etc., ad nauseam.
Librarian seems to be about the most thankless way to help the KiCad project there is.
Iād rather say: the most undervalued jobā¦
I love this comment! Or I did the first 273 times I heard itā¦
Since my point wasnāt clear, Iāll restate it: If you volunteer to manage the libraries, then manage the libraries. If you canāt, then just say so and release control to someone else. Thereās no shame in that.
Iāve been in that situation. I created KiCost and then supported it for a few years until I just got tired of it. Luckily, @hildogjr wanted to take over and heās done a great job supporting and extending it. I think that was a better solution than just ignoring issues and pull requests while the tool rotted. The same is true for the libraries.
And ghosting the libraries has a real cost. Itās a pain in the ass to follow the KLC only to have your submission ignored. That makes a person who put in the effort to support KiCad just a bit less positive towards it. And since KiCad doesnāt have a multimillion-dollar marketing budget, it needs those positive feelings so members of its community will recommend it to others. Thatās less likely if theyāre pissed off.
telling volunteers to volunteer more of their time isnāt likely to win you much sympathy.
Valid point, but isnāt it a numbers game on the librarians ?
Could the waiting be put into a āpendingā library with a proper disclaimer?
IDK, maybe. The point is that the current system isnāt working well. Instead of cranking away and falling further behind, new solutions are needed:
- Include āpre-releaseā libraries in the KiCad distribution.
- Create a search capability to find and load parts stored in repositories on Github/Gitlab.
- Create an enhanced version of KiPart that supports submissions in a simplified format and generates KLC-compliant symbols automatically.
- Or just about anything elseā¦
And who is going to read the disclaimer?
I can envisage a forum full of:
I used this symbol/footprint from the Kicad library and itās broken.
I thought Kicad libraries were supposed to work.
@devbisme
Unfortunately Iād have to include your ideas with Hermits, for the same reason.
I really have trouble understanding the reasons for contributors complaints.
They create a symbol/footprint, they place it in their library, it is theirs to use forever: Great!
They wish to let others use it so: Greater! It will happen, in time. Why all the fuss and dummy-spitting?
I donāt continually read:
I had a great idea for Kicad so I made a feature request and it hasnāt been implemented in twelve months?
OR:
Why isnāt the documentation complete and up to date?
Why all the carry-on with libraries?
I think because of the effort required to meet KLC and then the complete lack of acknowledgement/feedback. (Iām guessing since iāve never submitted to the libraries and am just going from replies to this thread.)
Meeting KLC makes nicer and cleaner looking schematics and PCB designs. And it does not take to much effort.
Asking why people complain is pointless. This would be the same as asking why to contribute to an open source project at all!
KiCad and also its libraries have been (and still are?) an open source project relying on contributions. More on the code side; less on libraries but still both are needed.
And now we have two extremes:
- Too much contribution (which no one can coordinate)
- No contribution at all
Obviously both extremes do not work well.
Having noticed that the number of MRs for the libraries is increasing constantly
I ājustā asked if contributions are still welcome (See #1). Nothing more, nothing less;
no complaint at this time! However this turned into a vivid discussion leading to the
conclusion that the current system is broken. And maybe this discussion leads
to a future change that improves the workflow/process - for maintainers and contributors!?
Getting back to a reason for complaining:
Most of the parts I use are not contained in any official library. And I donāt care too much as suggested.
But if I use official symbols or footprints which need fixes or extensions (e.g. derivations, KLC errors) I always need to be careful to not use the broken one from the official lib - and everytime I install a new version the trouble starts again. Why not fix the broken part instead of creating a fixed clone
and avoid the trouble at all?
Sometimes if I think that a symbol might be useful for others or used regularly I contemplate to contribute itā¦
I was curious about how much is going on in the libraries, so I had a look at the link below, and I count 170 posts for this month (now 17 days, so 10 posts per day on average), and this is only for the footprints.
Moreover, looking at the repository, it looks like they are doing a pretty good job.
Footprint
Symbols
Whats more, youāll only see all this changes if you install the libraries with each release or pull the repository down by yourself.
I agree that the KLC serves a valuable purpose in that it prevents the libraries from becoming wildly inconsistent. And maybe Iām wrong that they are onerous. (They certainly arenāt as bad as stuff like IPC standards.)
I apologize to the maintainers for saying they were not adequately managing the libraries. I was wrong.
Whatever the reason for the backlog in merge requests, itās more complex than I thought.
If I may make a comment as (newish) librarian: a review of an MR takes about 10-20 minutes if there are no comments to make and the contributor provided all of these:
- screenshots of the footprint or symbol:
- footprints: fully dimensioned drawing and a 3D fit-up with the manufacturer 3D model if available
- symbols: screenshot of the part in a representative schematic unless trivial
- datasheet link
- screenshots of relevant datasheet extracts
- explanation of design decisions that you made
- reasons for KLC exceptions (or a green pipeline tick).
If there any comments, any questions, an unexplained KLC pipeline failure, or any uncertainty, then typing out the comments, creating screenshots, that MR will now take at least an hour of keyboard time, but also likely means a round-trip which will delay the whole process by days. In the gap between arriving at home after work and going to bed, even on a day when I can carve out time for reviews on top of other KiCad-ery, let alone my own projects, I can rarely hope to complete a single review.
On Sunday, I spent basically a whole day and started 8 or 9 reviews. None of them could be merged that day. Only one of them could be merged after the first review, all the others needed another go around. Out of the 507 open footprint MRs, I currently know of only two, maybe three, that probably can merge without further comment. Two of those are my reviews from Sunday that I need to double check before pressing the button.
The āone simple trickā you can do to getting something actually reviewed is to convince a reviewer stepping out of the car after 10 hours in the office that your MR can be merged before bedtime. You can do this by adding all the items above, which indicate firstly that youāre willing to make the effort to make the MR easy to review and second that you have actually checked the footprint or symbol is correct and complies with the KLC. Pre-empt every question a reviewer could have. Remember, the reviewer is expected to stand behind every single part they review as if they drew it themselves.
Aim for an MR that needs no comments. These do happen! Honest! Personally, I love it! I donāt like nitpicking MRs, itās boring and I feel bad for asking for changes! Look here (for footprints): Merge requests Ā· KiCad / KiCad Libraries / KiCad Footprints Ā· GitLab - any MR with only one comment merged without further changes (the one comment would be āmerged! thanks!ā).
A small remark on this: looking through the recent merge requests it seems a bit like there are no guidelines on gitlab directly on how the ideal merge request would look like? Gitlab has this great feature where you can set templates for merge requests and I think this would help both sides here greatly. The ones requesting could then easily see what information they have to provide and the reviewers can check if the required information was given and reject all others on this base.
They are templates. However they only appear when you open a MR. Itās basic stuff like a few screen shots and datasheet link. Easy to gather.
John, thanks for the details on what it takes to merge to the library.
A few years ago, I built several symbol libraries for multiple FPGA families across multiple companies. There were hundreds of parts, some having thousands of pins. These were all done with KiPart being driven from pin tables directly from the manufacturers.
If I had submitted these as libraries (I did not), would they ever have been merged? Manually verifying the pins would have taken months! Nobody would want to do that if there were easier parts to merge. Is the backlog caused by passing over more complicated merges, or is there some other factor thatās the main cause?
The disclaimer is in the library name. Not a āsolidā suggestion to start discourse.