kicad-developers team mailing list archive

[Edwin van den Oetelaar <oetelaar.automatisering@xxxxxxxxx>]

Just for your information, Dick has worked on using Eagle libraries
directly.
The new eagle libraries are in XML and that makes editing easy.
I am going to try to use that function.
I already have some projects and footprints (and a full license for eagle
version 5 but not 6) and do not want to do the work again.

Just my humble view.
Greetings,
Edwin



On Mon, Nov 25, 2013 at 7:01 PM, Povilas Kanapickas <povilas@xxxxxxxx>wrote:

> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>