kicad-developers team mailing list archive

[Rene Pöschl <poeschlr@xxxxxxxxx>]

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.