kicad-lib-committers team mailing list archive

[Carl Poirier <carl.poirier.2@xxxxxxxxx>]

The GITHUB plugin is now part of the default build so the configuration is
supposed to be minimal. As for package maintainers, if they do not like it,
they can make a local libraries package that will need to be updated very
often to stay up to date. Let's recall that the GITHUB plugin has been made
to make library sharing and updating easy. Thus, I expect there will be
lots of modifications and additions in the future.

As for the library policy, I totally agree. I am not really the one to
start it off because I don't know much about the terminology of symbols,
but I think the easiest to begin with would be the parts made of simple
boxes with pins around it. I suggest the default pin length and pin
distance could become the policy. Then, you scale the box depending on how
many pins you need.


On Mon, Jan 13, 2014 at 10:45 AM, Kerusey Karyu <keruseykaryu@xxxxx> wrote:

> W dniu 13.01.2014 10:05, Bernd Wiebus pisze:
>
>> Hello Kerusey Karyu.
>>
>>  I am the most against to move everything stored locally related to
>>> KiCad
>>> to remote repositories. As I remember (and understand), these remote
>>> repositories were to be only an one of ways in entire library system,
>>> but now you want to drop everything else and keep only server based
>>> part.
>>>
>>> Thus, I do not like your idea.
>>>
>>
>> I am completely at your side.
>> I have to add, that even here in Germany with its good infrastructure i
>> am often working with KiCad in remote areas without access to a net.
>>
>> So the dropping of local stored libraries would be cathastrophic.
>>
>>
> And one more thing. The new users. We - as an experienced users - have
> some testing version installed, configured on the fly, etc.
> If a new user want to install KiCad from a scratch and the all the
> library, mesh files will be available only through Git plug-in, this user
> currently will not have anything to start with. He may also feel a bit lost
> in complex configuration.
>
>
>
>  To execute such movement, you must clean up the symbol libraries
>>> first.
>>> As one of worst examples let will serve PIC microcontrollers
>>> libraries.
>>> We have now five files. Ok, three I've added, but we have also
>>> another
>>> two where the symbols are repeated. Want to keep this mess?
>>>
>>>
>> What perhaps about different stiles?
>>
>>
> Just like code developers who have coding policy, lib creators will also
> need policies (Ok. Guidelines may sounds better.) for drawing symbols.
> But this is not that simple like one coherent coding policy. Programming
> languages are very closed in syntax. Drawing schematic I can compare to
> painting. Someone likes Da Vinci for his logic and reality, someone likes
> Picasso for his "skew visions" :D
>
> I prefer smaller symbols with short pins because I want to put as much as
> possible elements on a single A4 or A3 sheet.
>
> Kerusey Karyu
>
>
> --
> Mailing list: https://launchpad.net/~kicad-lib-committers
> Post to     : kicad-lib-committers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-lib-committers
> More help   : https://help.launchpad.net/ListHelp
>