kicad-developers team mailing list archive

["Stephen Eaton" <seaton@xxxxxxxxxxxxxx>]

G'day one and all,

I see there is a blueprint for the component library and thought I'd expand
on a couple of ideas and put them out on the list for comment.

1) Central Repository or definable multiple repository locations , e.g. you
could also have a central repository at your work location.  These
repositories are synchronised locally by the client, or portions of it.
i.e. only selected components you want and not the entire repository tree,
groups of components (e.g. smd resistors not pth).  This allows the benefits
of the client working offline to the repository if required, but easily
updated to new versions as the need arises, a quick way of mitigating
library errors as they get fixed. 

2) browseable and searchable from within the client, also allowing
components/footprint along with variations to all be viewed, selected and
synced, or via an external www interface directly at the repository.

3) Rating/comment system on each component and footprint, thus giving
indication on the most used or reliable components/footprints by developers
using the repository.  This would more than likely be repository based, so
you can see what other comments are when browsing the repository, but could
also have a view in the client when you go to select the component to use
from you local repository.  This could also be like itunes amount of times
the song is played?

4) Ability to spawn new variations of repository components locally to allow
customisation e.g. changes in solder masks, pad sizes etc, and a then way of
submitting these back for inclusion to the central repository as a variation
of the original, again allows the sharing of the work being done, why
re-invent the wheel?

5) And of course the ability to submit new components created locally for
inclusion in the repository directly from within the client, select
components, click submit, maybe fill out some submission details in the
process.

6) Addition of a simple state field, either as a check box or a dropdown
list, for all components and footprints in the library. e.g. (un)tested,
(un)proven etc.  Yes we can use the existing fields, but you have to
remember to go in and add them, plus it's not consistent as freetext.  This
field is automatically set to an unproven state when the component is first
created and updated at a later point when actually tested/proven.  This
could be expanded so that depending on the state as to whether the component
can be edited or not, i.e. pad/drill changes.

7) Having a central repository requires management and intervention of sorts
by the library management team, but to make things streamlined, the
repository server needs to have a workflow mechanism for submissions and
approvals.  Maybe some form of automation in the approval process, a design
rules bot? then over to the submission workflow if all tests pass, or maybe
no human intervention is required, after a bot checks out the design rules
and passes new components get put in a sandbox/untested/New area and stay
there until there are enough comments/positive ratings or they get approved
by someone from the library management team, where they then get moved into
the general population, same thing could happen for modified and variations
of components, so what ends up happening over time is the general population
only consists of stable/tested components. 

Anyway my 10c worth lol

Regards,

Stephen...

 
 

__________ Information from ESET Smart Security, version of virus signature
database 5048 (20100421) __________

The message was checked by ESET Smart Security.

http://www.eset.com