kicad-lib-committers team mailing list archive

[Vesa Solonen <vesa.solonen@xxxxxxxx>]

23/02/14 15:49, Kerusey Karyu kirjoitti:

> It's simple. The official names are upper case in 95%, for ex.: SOT, TO,
> TQFP, QFN, SOIC followed by a number of pins. Of course there are some
> exclusions like "eSIP-7C" (from Power Intergrations).
> 
> This means, that in libraries we have to use strict forms. So
> "tqfp100" is wrong because this should be "TQFP100" due to widely used
> standards. But "eSIP-7C" is also correct, because this name come from
> manufacturer of a part.

Agreed 100%

> The question which remains: Does "DIP-8" is correct or "DIP8" is correct?

This needs a bit further study. I would be leaning towards "DIP-8". In
general that seems to be the case in all data books (regarding various
packages from DIP to RF-stripline transistor packages) I have. Newer
data sheets online use both conventions. If we name with the hyphen, the
renderer can choose to leave it out... Also that particular wildcard is
not too bad regarding search.

>> My proposal is making a set of strict rules to follow, just like coding
>> style guide. Otherwise stuff is not accepted in the "official"
>> distribution.
>>
> It will be difficult to create and respect these rules by the others. Why?
> 1. Footprint naming convention is the only one of small stones in this
> pyramid. Libraries need some other rules too to create something I
> personally call: KiCad Style.

Yes, again fully agreed. Do you remember how many times this issue has
been discussed in the past? I don't. I still consider this particular
small stone very important for stability.

Please tell more about your style rules, I'm very interested.

Some old stuff of mine: http://users.tkk.fi/~vsolonen/kicad/

Some other excellent stuff:

http://bazaar.launchpad.net/~oyvind-aabling/kicad-newlib/mod/view/head:/modules/oaa.README

> 2. Who have enough time and will play a judge role in evaluating this?

We? Other library maintainers? On best effort basis of course.

Use this list for sending library patches or pull requests, just like
development list. Commit messages providing the source and status of the
data, like drawn/inspected/production, etc.

Say we accept everything that conforms to the style and naming
conventions, but present it with just "drawn" status. It may not be
correct. Then someone else (or we) checks it against data sheets, etc.
and sends a patch changing the status "inspected"

I'm sure as soon as procedures and style details are in written
documentation, the rest follows.

-Vesa