← Back to team overview

kicad-developers team mailing list archive

Re: Future plans on the KiCad library releases?

 

On 17/01/18 10:03, Carsten Schoenert wrote:
Some more information about the current plans and doings in the library
team would be a good thing! And please not only through the KiCad user
forum. Please use also the KiCad website and/or the new GitHub site for
the libraries you have created.
Not sure what you mean here. The new libs are not yet official. Once they
are we will make a blog post about them.
Well, it was (and is) difficult to follow what is happen on the side of
the libraries, at least this is my impression. Communication is motsly
done by the GitHub issue tracker (which I find horrible to use) and I
guess within the KiCad forum. That's o.k. so far. I just want to mention
it's not easy for new people and also for me as someone who is packaging
all that various stuff to get easy actual information about the work and
plans of the library people.

About 1.5 to 2 years ago there I started to work with KiCad most of the
time I have tried to research around the usage and modification on the
libraries. It's now much better but cut be even better. And that 'even
better' is just a small step in my eyes. Hopefully now it's a bit mor
clear what I've tried to say.

Issues are not ideal but they are the best tool we currently have.
The mailing list would not be the right place to discuss lib specific
topics as they are of no interest to the typical developer.
(They are of interest to users, lib maintainers and maybe packagers)
Getting user input is most easily done via the forum.

In the future we will make a short post on the mailing list if we
think a change does influence packagers. (If i remember correctly
oliver did that in the past as well. With the horrible search
function of the mailing list this is not easy to find out.)

...
Believe me. No matter how long you think about the names you will never
find everything that you want to change at a later date. We discussed the
current new names for over half a year.
I think I know what you say and I don't want to blame anyone here. I
just want to bring the problems on top probably not only I've found.

What me often helps in such situations is to really try to look at
myself and my work like other would do. So, how does this all looks for
someone from outside? What would he expect to see or to find. Is the
work or the goal I try to get really useful for other people?

I know that is difficult but if it would be easy others would already
have done the work.

To get others peoples view they need to know that some feedback is
appropriated. And this brings the circle again to the communication.

We had an issue about this open for half a year.
We made regular inquires over at the info forum
where a lot of experienced users where asked for feedback.

And still some things have been missed.
Also a few manufacturers have already merged/changed name
since we defined our new lib setup.
(Microchip bought Atmel for example.)
This means that our MCU_Atmel* libs already required renaming.
(MCU libs are the only libs that include a manufacturer name.
For footprints it is worse because we allow manufacturer specific
footprints. These then include the manufacturer name in their name.)


...
The libs for version 4 still live in their old repos ;).

As far as i know, no further version 4 release is planned.

We have already archived most of the old repos.
What ever that means in times of git. :-)
But I got that you mean. And I suspect the core library team won't do
any maintenance of the old stuff proactive. But wanted to raise the
question as I know that some users of Debian can't follow the two years
release circle and need to stay on older versions and than ask mostly by
the bugtracker (in Debian) about new updates for their old versions. But
I can't answer such questions without to know what upstream is thinking
about. Maybe the library team want's write a small statement about the
situation of the libraries/symbols for the older version?

Kicad version 4 had one combined repo for symbols and 3d models
(kicad-library) plus one repo per footprint lib. (the 100 *.pretty repos)

Kicad version 5 has four repos:
 - kicad-symbols
 - kicad-footprints
 - kicad-packages3d (plus support repo kicad-packages3d-source)
 - kicad-templates


Another thing to consider:

It is hard to find what symbol/footprint is correct. Even if the contributor
states it worked for their project, a different pcb manufacturer might still
have problems with it. A symbol (or footprint) can be in the library for

years and nobody finds out that it is incorrect. (We found a few footprints

while reworking the libs, that where incorrect for the last 3 years.)

The library can not be compared to software in this regard.
I disagree on that as from the source view there is no difference
between both. But yes, one (or even more) person(s) can't do here any
serious quality testing work due the current and increasing amount of
symbols. This can only be done by automatic testing and as the libraries
internally have always the same structure this will make it mostly
easier to write some autotests.

But let us stop here, further discussing here brings no gain right now.


Some things can not be auto tested.
We can (mostly) test if the contribution complies with the KLC.

But we can not automatically test if the contribution complies with
the datasheet or general manufacturing requirements.
- for symbols: have all pins the correct number, name, electrical type, ...
- for footprints:
   - are all pads at the correct place?
   - have they the correct size?
   - Does the outline on the fab layer reflect the correct size?
   - ...

The reason for this not being able to be auto tested is that one
can not really parse a datasheet automatically.



Follow ups

References