kicad-developers team mailing list archive

[Simon Küppers <simon.kueppers@xxxxxx>]

For what is worth, I strongly support this standpoint! :-)


Am 06.10.2017 um 15:33 schrieb Oliver Walters:
> Wayne,
> 
> Thanks for the clarification - this discussion is getting a bit
> sidetracked I feel.
> 
> We will operate under the assumption that the footprints will be in a
> single repo, without using submodules.
> 
> Any tools that can or will be developed for managing KiCad libraries are
> a secondary requirement at this point.
> 
> Cheers,
> 
> Oliver
> 
> On Sat, Oct 7, 2017 at 12:20 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     On 10/6/2017 5:43 AM, Rene Pöschl wrote:
>     > On 02/10/17 11:37, Simon Küppers wrote:
>     >> I am no expert, but this question is out of the scope of this
>     thread..
>     >> For downloading, gut applies compression anyway.
>     >>
>     >> I respect the people having slow Internet lines.. However as shown a
>     >> few posts backwards, the whole footprints and symbol library is like
>     >> 100 megabytes without the 3d models. If think the benefit of a single
>     >> repo outways the ability to download only a selection of libraries...
>     >> By a LOT.
>     >>
>     > I agree with you here. Lets ignore the 3d model stuff and get back
>     > talking about the footprint libs.
>     > We are planning a massive library reorganization. (for the v5 release)
>     > This will require a lot more footprint libs. If all these new libs are
>     > all in a separate repo then this can not be done!
>     > In addition to the new repos the old once still need to exist (and
>     have
>     > at least one footprint each) because otherwise the github plugin will
>     > stop working for everyone who has this old repo in their fp-lib-table.
>     >
>     > **We library managers require whatever lib distribution is used to
>     > support one repo that holds all footprint libs.** (one repo that
>     has the
>     > pretty folders as subdirectorys)
>     > To be honest i do not care what will be used as long as this
>     requirement
>     > is fulfilled.
>     >
>     > We would really need a decision soon. Are you guys prepared to help us
>     > out here such that we can move on with the lib reorganization? (The
>     > details of how you do it can be discussed later.)
>     >
> 
>     I thought I already addressed this issue but I will reiterate.  I am
>     fine with the footprint library reorganization as long as the existing
>     footprint library repos remain in tact for existing users.  These
>     libraries do not need to be updated but we cannot remove them.  The
>     other thing that will have to happen is that our package devs will have
>     to buy into packaging the new footprint library repo as part of the
>     install packages.  We will have to agree on an install path (
>     ${CMAKE_INSTALL_PREFIX}/share/kicad/footprints seems logical) and make
>     the default fp-lib-table file use the local install path with the KiCad
>     plugin instead of the github plugin fp-lib-table.  I don't think this
>     will be a major issue.  Does anyone have any major objections to this?
>     If not, we will make this part of the stable 5 release.
> 
>     Cheers,
> 
>     Wayne
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
> 
> 
> 
> 
> _______________________________________________
> 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
>