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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
