kicad-developers team mailing list archive

[Povilas Kanapickas <povilas@xxxxxxxx>]

Hello,

One of the things that I noticed working with KiCad is that its cental
symbol/footprint library collection could be improved immensely. I'd
like to share several ideas that may (or may not) be useful. I'm also
willing to spend time implementing them, so hopefully the ideas that
will be deemed useful (if any) won't end up being forgotten due to lack
of time.

Before I begin, please excuse me for being unfamiliar with any recent
developments, plans and decisions in this area. Even though I've read
the recent posts in the mailing list, there must be some things that I
misunderstood.

Some of my ideas unfortunately conflict with the current direction of
the library sub-project. Please do not take any of them as a suggestion
that the current work should be dropped -- I only want to share my
optimistic and thus necessarily naive view of how the central library
collection could look like in the ideal world :-)


I think a central, official collection with huge collection of symbols
and footprints is necessary for KiCad. The reasons are as follows:

 * It's possible to provide at least some guarantees for the quality of
content. The user does not need to spend time verifying the data.
 * It becomes the go-to place for symbols and footprints. Users spend
less time searching for them.
 * The chance of duplication of work is reduced.
 * (see the second point below for a specific model and more reasons)

The main issue with the current approach is that the central library
repository is not 'accessible' enough to outside contributions. By
'accessible', I mean plenty of things that hinder movement of symbols,
footprints and their improvements from third party repositories to the
central repository. If we want the central repository to succeed, this
issue is critical.

Below comes an unsorted list of what I think could be improved in order
to solve the above problem.

---

1) Make the central footprint repository discoverable

Currently is pretty impossible to find the central repository.
Unfortunately it's not described as 'official' anywhere, thus even if an
user finds it, he probably doesn't think this is the place to merge your
new footprints or symbols.

The current situation could be improved by the following changes:

 * Add a link to the central library repository to
https://launchpad.net/kicad. Describe that repository as 'official KiCad
footprint and symbol repository' and say that contributions are welcome.

 * Do the above at kicad-pcb.org

 * Improve the currently inexistent description of the central
repository. Say that it's 'official KiCad footprint and symbol
repository' and say that contributions are welcome.

---

2) Make the VCS workflow intuitive and familiar to as many users and
developers as possible.

I think the Launchpad workflow is quite unintuitive to the majority of
potential committers. For example,
https://code.launchpad.net/~kicad-lib-committers/kicad/library shows
only how to checkout the library locally. If you want to make your first
public repo you need to do some Googling on how to set up SSH keys, etc.
as no documentation is provided when you need it, e.g. whet you do bzr push.

On the other hand, for example on Github once you register you can push
almost immediately -- it's a bit inconvenient as it asks for your
password each time (until you configure password caching), but it works.

Also, I think moving to git might be a good idea as many more people are
familiar to git than to bzr.

Git also has a huge advantage in that allows single person to manage
huge repositories (see the Linux kernel for example). The
responsibilities can be offloaded to secondary maintainers with their
own trees, so the main maintainer does not need to bother at all when a
minor fix needs to be merged.

This also means that it's sensible to collect even small libraries to
the central repository. The library maintainers could then fork the
central repository to their own trees, maintain their libraries there
and issue pull requests when they think their work is ready.

Furthermore, this approach makes updating symbols and footprints an easy
task. One only needs to pull a single git repository instead of many.

Finally, a single repository allows to enforce some kind of consistency.
I guess none of us want to work with similar components that are marked
differently :-)

---

3) Make merging easier and less complex.

Currently a library corresponds a file. This is a bit inconvenient as
one can't immediately see what components are within that library. Also,
merging becomes more complex as one needs to use external tools to make
sure no duplicates are introduced.

I think this situation could be improved if we introduced (I'm willing
to work on this) a library format that makes a library to correspond to
a directory (plus an index file) and each of the components to a file
within that directory. This would allow to immediately see what
components does a library include without any external tools. This would
also make merging easier -- the chance of conflicts and inadvertent
duplications would be reduced to a minimum.

---

This is all I have to say for now. It would be get some feedback even if
my ideas seem silly or conflicting with the current goals -- I'm willing
to work on improving KiCad, so it would be great reconcile the
difference of opinions from the start :-)

Regards,
Povilas Kanapickas