Hi!
In the specific case of many complicated FPGA parts, the best way would likely be to make a generator. We don’t have many of those for symbols, but there are a few. Notably, the large libraries of STM32s are indeed generated, and were merged (in fact any footprint or symbol added in the last many year will have been reviewed and then merged - nothing skips review, no matter who made it). Probably the best way to have approached that would be to submit a handful at first and make sure the general pattern is right in some limited, reviewable-by-mortals sense, then expand to the whole range.
The backlog in any queue is always simply caused by a fundamental result of queueing theory - as the average load factor of a queue’s service agents (i.e. in this case how much of the total review capacity we are using) approaches 1, the latency through the queue (i.e. time from MR submission to merge) tends to infinity. Of course, once a queue is “in the hole”, the load average is pegged to 1.0 while the backlog is handled and latency increases without bound until you either clear the queue somehow or die trying (We are here!)
There can only ever be only three ways to resolve this: increase service agents (add reviewer-hours), reduce requests (e.g. refuse some MRs entirely - not ideal!) or reduce load per request (make MRs quicker to review).
Communicating with contributors in a “nice” way (rather than being terse and dismissive of the effort they made to submit the MR) takes, literally, hours and hours. In order of total time spent: my feeling of where the time usually goes:
- typing the comments, taking screenshots and double checking everything so I don’t give misleading, vague or confusing comments and frustrate the contributor too much
- digging up details e.g. signing up for websites to get 3D models to do my own fit-ups, finding applicable standards like JEDEC ones, opening models in FreeCAD and measuring them, finding application notes to get an idea of what is correct part usage, that kind of thing
- actually checking the “obvious” symbol//footprint content by making my own dimensioned drawings or reading the datasheet pinouts
- switching back and forth between different MR branches and keeping track of returning review comments - every time I do this, it’s a context switch
- checking with other librarians when I’m not sure in edge cases
Anything an MR submitter can do to reduce any of those helps enormously.
It’s likely that the remaining MRs do skew to the more complex, because easy ones often get picked off quickly what a reviewer has 10 minutes to spare and doesn’t want to get involved in a huge review. That said there are quite a few simple ones there that often just look “unappealing” (relative to others, or doing ones own work). Footprints and symbols are very complicated and even the simplest have a large number of things that are often not quite right. The review comments for even the simplest MR needing revisions can contain 5-10 points. A complex review that takes 2 hours to verify but is actually right in the first instance is always easier than a trivial-seeming MR that still somehow requires a two-week-long back-and-forth process to slowly converge on a mergeable result like I’m playing an excruciating game of 20-Questions by post.
A surefire way to make your MR suspected to be of the second type is if the KLC check is not green and just a perfunctory message like this:
Add ABCV4533E
url: https://someco.com/ds/sdfsdfsdfsdf.pdf
Remember, every MR that takes 1 hour (already optimistic for an MR that isn’t one-and-done) blocks 6 requests that each take 10 minutes. Even if we say only 3, look at the difference on that graph if we could have 0.33 load factor rather than 1.0.
Now, as for what you can do: any MR you make - make them a 10 minute one. Check them twice, then check them again. Provide all the materials to show your working. Guess what a reviewer could conceivably ask and answer it first. If the KLC checks fail, do not wait for a reviewer to ask you to deal with it. If the manufacturer 3D model doesn’t seem to fit, fix it first. If the dimensioned drawing doesn’t have the same exact dimensions as the datasheet, fix it now. If GitLab tells your the rebase won’t work - now is the time to deal with it. If you know the MR is not ready and you can’t fix it now, you can mark it as a draft in the meantime.
If you want to help clear the queue, you can do a review of another’s MR on your own, even as a non-librarian (and you can become a librarian this way…I should know!). It’s not rude, it’s very helpful. You can add missing dimensioned drawings, 3D fit-ups and check the KLC pipeline results and other manual checks. If we can clear down the queue, the load factor won’t be 1 any more because we won’t be filling every spare moment with the servicing the backlog and the latency will be far, far lower. The other thing that you personally will learn in that process is what a reviewer is looking for, and then you will be able to pull off the sacred and mystic art of the bullseye MR when it comes to your own submissions!
Another thing you can do is to make (simple, clear, easily-reviewed - see all of above!) MRs to make the library more consistent and KLC-y a small chunk at a time (here’s one I did, for example: Rework Lumberg 1503-07 THT audio jack (!3281) · Merge requests · KiCad / KiCad Libraries / KiCad Footprints · GitLab). This helps because when others, quite reasonably, use existing parts as a basis for new ones, we won’t have to spend scarce review time correcting the KLC issues they inherited from an old library part that predates the KLC rules in question.
Disclaimer: this is all my own opinion - librarians are their own people and I certainly don’t claim to speak for them or for the library team as a whole.
