Re: [Kicad-developers] KiCad Libraries (again)

[Diego Herranz]

Hi,

I've just submitted a pull request (
https://github.com/KiCad/kicad-website/pull/236) trying to make a bit more
clear when/why you need to update the libraries. Also adding links to
github lib repos. Comments welcome :)

Thanks,
Diego

On Sun, Nov 5, 2017 at 10:33 PM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:

> Thanks, Rene
>
> On 4 Nov 2017 4:06 pm, "Rene Pöschl"  wrote:
>
> On 03/11/17 21:34, Diego Herranz wrote:
>
>> First of all, I think all the recent work around the libraries is great!
>> Thanks to everyone involved. I think sometimes libraries are underestimated
>> (not just in KiCad). If KiCad manages to have extensive, high-quality and
>> clearly arranged libraries, many more users will end up using it.
>>
>> Having said that, I've used Kicad for some time and even contributed some
>> code but still can't fully understand how all the library stuff works. It
>> is the most common complaint I read about KiCad by newbies and somehow I
>> feel myself in a similar situation.
>>
>> So, I've reviewed http://kicad-pcb.org/libraries/download/ <
>> http://kicad-pcb.org/libraries/download/> with my lack of library
>> understanding and will try to provide some feedback from that view:
>>
>>
>> - It seems to imply that the user needs to download the libraries from
>> there. However they come with the installer, don't they?
>>
> A user might want do download an older or newer version of the lib than is
> offered with their software version. (Maybe because they want to open a
> project designed with this version of the lib.)
>
> And there is talk about giving users the option to get a small installer
> without libs. (Some users have data constrains. The installer is now nearly
> 1GB including all the 3d model libs.)
> It might also be a good idea to decouple the library release cycle from
> the software release cycle.
>
> I understand. We may want to explain that not to make users think they
> *need* to download them. I may submit a patch.
>
>
>
>
> - It says "Users who wish to keep their libraries up to date with the
>> latest additions should clone the library repositories using Git.". But,
>> does that apply to footprint libraries? I think my installs have always
>> gone to github for those. Is that true? Do they grab the latest or a
>> specific tag?
>>
> The github plugin in general is a bad idea. It grabs the current master
> head and downloads everything in every session. (At least everytime it
> needs information about footprints for the first time in this session.) It
> does not even use git but pulls a zip archive.
>
> Another problem of having the github plugin is that the libs of the user
> get out of sync. So the symbol libs and 3d model libs stay at the version
> they where at the release of the installed software version. But the
> footprint libs get every change we make in the repos. (This means that if
> we rename a footprint, the footprint filters defined in the symbol might no
> longer work. Or if we change the scaling of the 3d model this will produce
> wrongly scaled results in the 3d viewer until the user manually downloads
> newer 3d models.)
>
> Because we decided to kill the one repo per footprint lib nonsense for the
> v5 release the current github plugin will no longer work there. (So you
> could say the download page is already prepared for the v5 release.)
> Unless of course someone fixes the github plugin such that it supports one
> large repo that holds all footprint libs. (But i would not suggest to use
> it as the default option, because it has the major drawbacks mentioned
> above.)
>
> Thanks, I understand it a bit better now.
>
>
>
>
>
> - I would explain the differences between schematic (old style,
>> per project) and layout libraries (new table style, per project or global).
>> Also in "Future of the Libraries" explain the new symbol table, etc.
>>
> If i read the conversations on the mailing list correctly then kicad 5
> will include a symbol table for managing symbols.
> We could of course add a pointer to the documentation of this stuff. But i
> don't really know where it would fit.
>
>
> - I would maybe mention kicad-packages3d-source (maybe in brackets)
>>
> good idea
>
> Again, I may submit a patch.
>
>
>
> - I would add links to the repos in "Future of the Libraries"
>>
> I think oliver is already designing a better version of the download page.
> Have a look at the other library related conversation here on the mailing
> list.
> https://lists.launchpad.net/kicad-developers/msg31312.html
>
> I think that's different from the landing download page, but not sure how
> both would interact.
>
>
>
> - If anything of what I said doesn't make sense or it's wrong, please let
>> me know. I'd love to understand it better.
>>
> done
>
> mfg Rene Pöschl
>
>
> Many thanks for your help, Rene.
> Diego
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubs

Re: [Kicad-developers] KiCad Libraries (again)

[Diego Herranz]

Thanks, Rene

On 4 Nov 2017 4:06 pm, "Rene Pöschl"  wrote:

On 03/11/17 21:34, Diego Herranz wrote:

> First of all, I think all the recent work around the libraries is great!
> Thanks to everyone involved. I think sometimes libraries are underestimated
> (not just in KiCad). If KiCad manages to have extensive, high-quality and
> clearly arranged libraries, many more users will end up using it.
>
> Having said that, I've used Kicad for some time and even contributed some
> code but still can't fully understand how all the library stuff works. It
> is the most common complaint I read about KiCad by newbies and somehow I
> feel myself in a similar situation.
>
> So, I've reviewed http://kicad-pcb.org/libraries/download/ <
> http://kicad-pcb.org/libraries/download/> with my lack of library
> understanding and will try to provide some feedback from that view:
>
>
> - It seems to imply that the user needs to download the libraries from
> there. However they come with the installer, don't they?
>
A user might want do download an older or newer version of the lib than is
offered with their software version. (Maybe because they want to open a
project designed with this version of the lib.)

And there is talk about giving users the option to get a small installer
without libs. (Some users have data constrains. The installer is now nearly
1GB including all the 3d model libs.)
It might also be a good idea to decouple the library release cycle from the
software release cycle.

I understand. We may want to explain that not to make users think they
*need* to download them. I may submit a patch.




- It says "Users who wish to keep their libraries up to date with the
> latest additions should clone the library repositories using Git.". But,
> does that apply to footprint libraries? I think my installs have always
> gone to github for those. Is that true? Do they grab the latest or a
> specific tag?
>
The github plugin in general is a bad idea. It grabs the current master
head and downloads everything in every session. (At least everytime it
needs information about footprints for the first time in this session.) It
does not even use git but pulls a zip archive.

Another problem of having the github plugin is that the libs of the user
get out of sync. So the symbol libs and 3d model libs stay at the version
they where at the release of the installed software version. But the
footprint libs get every change we make in the repos. (This means that if
we rename a footprint, the footprint filters defined in the symbol might no
longer work. Or if we change the scaling of the 3d model this will produce
wrongly scaled results in the 3d viewer until the user manually downloads
newer 3d models.)

Because we decided to kill the one repo per footprint lib nonsense for the
v5 release the current github plugin will no longer work there. (So you
could say the download page is already prepared for the v5 release.)
Unless of course someone fixes the github plugin such that it supports one
large repo that holds all footprint libs. (But i would not suggest to use
it as the default option, because it has the major drawbacks mentioned
above.)

Thanks, I understand it a bit better now.





- I would explain the differences between schematic (old style,
> per project) and layout libraries (new table style, per project or global).
> Also in "Future of the Libraries" explain the new symbol table, etc.
>
If i read the conversations on the mailing list correctly then kicad 5 will
include a symbol table for managing symbols.
We could of course add a pointer to the documentation of this stuff. But i
don't really know where it would fit.


- I would maybe mention kicad-packages3d-source (maybe in brackets)
>
good idea

Again, I may submit a patch.



- I would add links to the repos in "Future of the Libraries"
>
I think oliver is already designing a better version of the download page.
Have a look at the other library related conversation here on the mailing
list.
https://lists.launchpad.net/kicad-developers/msg31312.html

I think that's different from the landing download page, but not sure how
both would interact.



- If anything of what I said doesn't make sense or it's wrong, please let
> me know. I'd love to understand it better.
>
done

mfg Rene Pöschl


Many thanks for your help, Rene.
Diego
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Diego Herranz]

First of all, I think all the recent work around the libraries is great!
Thanks to everyone involved. I think sometimes libraries are underestimated
(not just in KiCad). If KiCad manages to have extensive, high-quality and
clearly arranged libraries, many more users will end up using it.

Having said that, I've used Kicad for some time and even contributed some
code but still can't fully understand how all the library stuff works. It
is the most common complaint I read about KiCad by newbies and somehow I
feel myself in a similar situation.

So, I've reviewed http://kicad-pcb.org/libraries/download/ with my lack of
library understanding and will try to provide some feedback from that view:

- It seems to imply that the user needs to download the libraries from
there. However they come with the installer, don't they?
- It says "Users who wish to keep their libraries up to date with the
latest additions should clone the library repositories using Git.". But,
does that apply to footprint libraries? I think my installs have always
gone to github for those. Is that true? Do they grab the latest or a
specific tag?
- I would explain the differences between schematic (old style,
per project) and layout libraries (new table style, per project or global).
Also in "Future of the Libraries" explain the new symbol table, etc.
- I would maybe mention kicad-packages3d-source (maybe in brackets)
- I would add links to the repos in "Future of the Libraries"
- If anything of what I said doesn't make sense or it's wrong, please let
me know. I'd love to understand it better.

Many thanks,
Diego


On Wed, Nov 1, 2017 at 9:32 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Thanks Nick! Really happy to have this running on the website! I think a
> blog post would be a good idea, I'll see if I can make some words
>
> On Thu, Nov 2, 2017 at 8:14 AM, Nick Østergaard  wrote:
>
>> Hello
>>
>> I will just announce that I merged the pull request. I hope this will aid
>> in getting the librarians to feel more part of the "official" KiCad, if
>> they didn't before. I am glad that we have motivated librarians around.
>>
>> I will encourage Oliver and Co. to write an article to the "blog" section
>> if they see fit. http://kicad-pcb.org/post/
>>
>> Nick
>>
>> 2017-10-18 17:04 GMT+02:00 Oliver Walters > >:
>>
>>> I have been working on this for a while, and have submitted the first
>>> version here - https://github.com/KiCad/kicad-website/pull/219
>>>
>>> On Thu, Sep 14, 2017 at 10:01 PM, Oliver Walters <
>>> oliver.henry.walt...@gmail.com> wrote:
>>>
 Hi everyone,

 The conversation of how best to manage and distribute KiCad libraries
 has been raging for a while now.

 Users looking to download or contribute to the libraries are currently
 presented with a github landing page and some bland wiki pages (e.g. for
 the KLC information).

 I have been working on a new-and-improved website system for the
 following:

 * Clear information about the libraries
 * A place to download the latest libraries
 * Information on what is *in* the libraries
 * Instructions on how to contribute to the libs
 * Better presentation of the KLC

 This website will need to be updated periodically to present the latest
 version of the libraries to the users. Also, if users are going to be
 downloading library files then it could potentially use a lot of bandwidth.
 Thirdly, the generated content should be scripted but statically hosted.

 The solution? GitHub pages! - https://pages.github.com/ -

 These are hosted from your github repository, and for e.g. ours would
 have the URL kicad.github.io - this could be easily redirected from
 kicad-lib.org/library (for example).

 GitHub pages use the jekyll toolset to generate static content.

 With a small amount of additional Python scripting I have created a
 bare-bones example of what this might look like (locally hosted on my
 laptop for now):

 Here are some screenshots! Ignore the colors and simple layout scheme,
 this is currently just a framework.

 https://imgur.com/a/0GELG

 The main objectives of this project are:

 a) Present a more professional landing page for the libraries
 b) Leverage GitHub Pages functionality
 c) Improve KLC

 And, eventually:

 Provide a standardised way to separate the KiCad libraries from the
 KiCad installer!

 Thoughts and comments appreciated!

 Cheers,

 Oliver

>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
> ___
> Mailing list: https://launchpad.net

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Thanks Nick! Really happy to have this running on the website! I think a
blog post would be a good idea, I'll see if I can make some words

On Thu, Nov 2, 2017 at 8:14 AM, Nick Østergaard  wrote:

> Hello
>
> I will just announce that I merged the pull request. I hope this will aid
> in getting the librarians to feel more part of the "official" KiCad, if
> they didn't before. I am glad that we have motivated librarians around.
>
> I will encourage Oliver and Co. to write an article to the "blog" section
> if they see fit. http://kicad-pcb.org/post/
>
> Nick
>
> 2017-10-18 17:04 GMT+02:00 Oliver Walters 
> :
>
>> I have been working on this for a while, and have submitted the first
>> version here - https://github.com/KiCad/kicad-website/pull/219
>>
>> On Thu, Sep 14, 2017 at 10:01 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> Hi everyone,
>>>
>>> The conversation of how best to manage and distribute KiCad libraries
>>> has been raging for a while now.
>>>
>>> Users looking to download or contribute to the libraries are currently
>>> presented with a github landing page and some bland wiki pages (e.g. for
>>> the KLC information).
>>>
>>> I have been working on a new-and-improved website system for the
>>> following:
>>>
>>> * Clear information about the libraries
>>> * A place to download the latest libraries
>>> * Information on what is *in* the libraries
>>> * Instructions on how to contribute to the libs
>>> * Better presentation of the KLC
>>>
>>> This website will need to be updated periodically to present the latest
>>> version of the libraries to the users. Also, if users are going to be
>>> downloading library files then it could potentially use a lot of bandwidth.
>>> Thirdly, the generated content should be scripted but statically hosted.
>>>
>>> The solution? GitHub pages! - https://pages.github.com/ -
>>>
>>> These are hosted from your github repository, and for e.g. ours would
>>> have the URL kicad.github.io - this could be easily redirected from
>>> kicad-lib.org/library (for example).
>>>
>>> GitHub pages use the jekyll toolset to generate static content.
>>>
>>> With a small amount of additional Python scripting I have created a
>>> bare-bones example of what this might look like (locally hosted on my
>>> laptop for now):
>>>
>>> Here are some screenshots! Ignore the colors and simple layout scheme,
>>> this is currently just a framework.
>>>
>>> https://imgur.com/a/0GELG
>>>
>>> The main objectives of this project are:
>>>
>>> a) Present a more professional landing page for the libraries
>>> b) Leverage GitHub Pages functionality
>>> c) Improve KLC
>>>
>>> And, eventually:
>>>
>>> Provide a standardised way to separate the KiCad libraries from the
>>> KiCad installer!
>>>
>>> Thoughts and comments appreciated!
>>>
>>> Cheers,
>>>
>>> Oliver
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Nick Østergaard]

Hello

I will just announce that I merged the pull request. I hope this will aid
in getting the librarians to feel more part of the "official" KiCad, if
they didn't before. I am glad that we have motivated librarians around.

I will encourage Oliver and Co. to write an article to the "blog" section
if they see fit. http://kicad-pcb.org/post/

Nick

2017-10-18 17:04 GMT+02:00 Oliver Walters :

> I have been working on this for a while, and have submitted the first
> version here - https://github.com/KiCad/kicad-website/pull/219
>
> On Thu, Sep 14, 2017 at 10:01 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> The conversation of how best to manage and distribute KiCad libraries has
>> been raging for a while now.
>>
>> Users looking to download or contribute to the libraries are currently
>> presented with a github landing page and some bland wiki pages (e.g. for
>> the KLC information).
>>
>> I have been working on a new-and-improved website system for the
>> following:
>>
>> * Clear information about the libraries
>> * A place to download the latest libraries
>> * Information on what is *in* the libraries
>> * Instructions on how to contribute to the libs
>> * Better presentation of the KLC
>>
>> This website will need to be updated periodically to present the latest
>> version of the libraries to the users. Also, if users are going to be
>> downloading library files then it could potentially use a lot of bandwidth.
>> Thirdly, the generated content should be scripted but statically hosted.
>>
>> The solution? GitHub pages! - https://pages.github.com/ -
>>
>> These are hosted from your github repository, and for e.g. ours would
>> have the URL kicad.github.io - this could be easily redirected from
>> kicad-lib.org/library (for example).
>>
>> GitHub pages use the jekyll toolset to generate static content.
>>
>> With a small amount of additional Python scripting I have created a
>> bare-bones example of what this might look like (locally hosted on my
>> laptop for now):
>>
>> Here are some screenshots! Ignore the colors and simple layout scheme,
>> this is currently just a framework.
>>
>> https://imgur.com/a/0GELG
>>
>> The main objectives of this project are:
>>
>> a) Present a more professional landing page for the libraries
>> b) Leverage GitHub Pages functionality
>> c) Improve KLC
>>
>> And, eventually:
>>
>> Provide a standardised way to separate the KiCad libraries from the KiCad
>> installer!
>>
>> Thoughts and comments appreciated!
>>
>> Cheers,
>>
>> Oliver
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

I have been working on this for a while, and have submitted the first
version here - https://github.com/KiCad/kicad-website/pull/219

On Thu, Sep 14, 2017 at 10:01 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Hi everyone,
>
> The conversation of how best to manage and distribute KiCad libraries has
> been raging for a while now.
>
> Users looking to download or contribute to the libraries are currently
> presented with a github landing page and some bland wiki pages (e.g. for
> the KLC information).
>
> I have been working on a new-and-improved website system for the following:
>
> * Clear information about the libraries
> * A place to download the latest libraries
> * Information on what is *in* the libraries
> * Instructions on how to contribute to the libs
> * Better presentation of the KLC
>
> This website will need to be updated periodically to present the latest
> version of the libraries to the users. Also, if users are going to be
> downloading library files then it could potentially use a lot of bandwidth.
> Thirdly, the generated content should be scripted but statically hosted.
>
> The solution? GitHub pages! - https://pages.github.com/ -
>
> These are hosted from your github repository, and for e.g. ours would have
> the URL kicad.github.io - this could be easily redirected from
> kicad-lib.org/library (for example).
>
> GitHub pages use the jekyll toolset to generate static content.
>
> With a small amount of additional Python scripting I have created a
> bare-bones example of what this might look like (locally hosted on my
> laptop for now):
>
> Here are some screenshots! Ignore the colors and simple layout scheme,
> this is currently just a framework.
>
> https://imgur.com/a/0GELG
>
> The main objectives of this project are:
>
> a) Present a more professional landing page for the libraries
> b) Leverage GitHub Pages functionality
> c) Improve KLC
>
> And, eventually:
>
> Provide a standardised way to separate the KiCad libraries from the KiCad
> installer!
>
> Thoughts and comments appreciated!
>
> Cheers,
>
> Oliver
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Wayne Stambaugh]

On 9/19/2017 10:35 AM, José Ignacio wrote:
> 
> 
> On Mon, Sep 18, 2017 at 7:52 PM, Rene Pöschl  > wrote:
> 
> 
> 
> On 19 Sep 2017 2:05 am, "José Ignacio"  > wrote:
> 
> Probably, contributors would need to agree to be attributed as a
> group when the work is embedded in a design (When the library is
> distributed in whole or part they should get attributed
> individually as the GPL requires). Ownership transfer shouldn't
> be necessary. a CLA is a good idea anyway to ensure all
> contributions are licensed with all the terms you think they
> are, and everyone is given proper attribution.
> 
> 
> I think ownership transfer happens automatically when opening a pull
> request. But having contributers sign an explicit agreement can't hurt. 
> 
> 
> A pull request is not sufficient to transfer ownership of a copyrighted
> work, unless that was specified in an agreement you signed beforehand,
> all contributions are owned by the respective contributors, but the
> project is granted a GPL license to use the contributed work, which
> can't be revoked (unless the project messes up in version 2). But since
> the GPL does not allow relicensing, the contributors must all agree to
> any licensing change.

Contributors to KiCad keep ownership of their contributions.  There is
no transfer of ownership to the project for source code, libraries,
documentation, translations, etc. that I am aware of.  It's been this
way since I joined the project so I'm not sure why you are concerned
with transfer of ownership.  The only concern is we now have an official
license for libraries where before that was not very well defined and if
you find the terms of this license acceptable as a contributor.

>  
> 
> 
> The attribution requirement for case #2 ideally would be a
> simple "Using symbols/footprints/models for the Kicad project's
> library, version X" plus some permalink where the GPL versions
> of the libraries can be obtained, together with the attribution
> information (embedded in the GIT history, or preferably an
> AUTHORS file). If that's not agreeable, perhaps an AUTHORS file
> that can be downloaded and bundled with a non-gpl design should
> comply with the attribution requirement.
> 
> 
> for #2 we used the font exception. We also have a credits file that
> has a dual purpose of documenting where the models come from (script
> or mcad software example freecad) and who made them. I don't think
> this would be practical for other libs though. (it already creates
> merge conflicts in the 3d repo.)
> 
> 
> That would need to be fixed somehow. It would be nice if GPL+FE
> compliance was just a few clicks away rather than having to hunt down
> lists of contributors.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[José Ignacio]

On Mon, Sep 18, 2017 at 7:52 PM, Rene Pöschl  wrote:

>
>
> On 19 Sep 2017 2:05 am, "José Ignacio"  wrote:
>
> Probably, contributors would need to agree to be attributed as a group
> when the work is embedded in a design (When the library is distributed in
> whole or part they should get attributed individually as the GPL requires).
> Ownership transfer shouldn't be necessary. a CLA is a good idea anyway to
> ensure all contributions are licensed with all the terms you think they
> are, and everyone is given proper attribution.
>
>
> I think ownership transfer happens automatically when opening a pull
> request. But having contributers sign an explicit agreement can't hurt.
>

A pull request is not sufficient to transfer ownership of a copyrighted
work, unless that was specified in an agreement you signed beforehand, all
contributions are owned by the respective contributors, but the project is
granted a GPL license to use the contributed work, which can't be revoked
(unless the project messes up in version 2). But since the GPL does not
allow relicensing, the contributors must all agree to any licensing change.


>
> The attribution requirement for case #2 ideally would be a simple "Using
> symbols/footprints/models for the Kicad project's library, version X" plus
> some permalink where the GPL versions of the libraries can be obtained,
> together with the attribution information (embedded in the GIT history, or
> preferably an AUTHORS file). If that's not agreeable, perhaps an AUTHORS
> file that can be downloaded and bundled with a non-gpl design should comply
> with the attribution requirement.
>
>
> for #2 we used the font exception. We also have a credits file that has a
> dual purpose of documenting where the models come from (script or mcad
> software example freecad) and who made them. I don't think this would be
> practical for other libs though. (it already creates merge conflicts in the
> 3d repo.)
>

That would need to be fixed somehow. It would be nice if GPL+FE compliance
was just a few clicks away rather than having to hunt down lists of
contributors.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Carsten Schoenert]

Hi,

Am 19.09.2017 um 01:44 schrieb Oliver Walters:
> Thanks for the links Rene.
> 
> Rene also found an older reference to a discussion between Wayne and
> Torsten
> - 
> https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg16268.html
> 
> This strongly suggests that the gEDA license is the way to go.

this wording is potential ambiguous!
There is no gEDA license, we just can talk about a analogous gEDA
licensing model.

http://wiki.geda-project.org/geda:license

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Ingo Kletti]

IMO (engineer's point of view), the licensing for the 3D models is a 
good template for the schematic and footprint libraries.


Regards,

Ingo

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Rene Pöschl]

On 19 Sep 2017 2:05 am, "José Ignacio"  wrote:

Probably, contributors would need to agree to be attributed as a group when
the work is embedded in a design (When the library is distributed in whole
or part they should get attributed individually as the GPL requires).
Ownership transfer shouldn't be necessary. a CLA is a good idea anyway to
ensure all contributions are licensed with all the terms you think they
are, and everyone is given proper attribution.


I think ownership transfer happens automatically when opening a pull
request. But having contributers sign an explicit agreement can't hurt.


IANAL but i think something that would make everyone happy is to have these
conditions apply:

1) When distributing the libraries in whole or in part the whole GPL
applies, with it's requirements on disclosure of source, copyleft, and
attribution.
2) In the special case of someone embedding the symbols in their design, a
simpler license would apply, where they can use a simplified attribution
requirement, people are forbidden from separating the symbols from the
design for their own use in other designs.


Did you read what we did for the 3d models repo? If I read your comment
correctly it means the same as we wrote there. If you think your suggestion
is not satisfied with this license could you give a specific list of
differences?

Here again the link to the 3d model licence page
https://github.com/KiCad/kicad-packages3D/wiki/Model-Licencing


The attribution requirement for case #2 ideally would be a simple "Using
symbols/footprints/models for the Kicad project's library, version X" plus
some permalink where the GPL versions of the libraries can be obtained,
together with the attribution information (embedded in the GIT history, or
preferably an AUTHORS file). If that's not agreeable, perhaps an AUTHORS
file that can be downloaded and bundled with a non-gpl design should comply
with the attribution requirement.


for #2 we used the font exception. We also have a credits file that has a
dual purpose of documenting where the models come from (script or mcad
software example freecad) and who made them. I don't think this would be
practical for other libs though. (it already creates merge conflicts in the
3d repo.)
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[José Ignacio]

Probably, contributors would need to agree to be attributed as a group when
the work is embedded in a design (When the library is distributed in whole
or part they should get attributed individually as the GPL requires).
Ownership transfer shouldn't be necessary. a CLA is a good idea anyway to
ensure all contributions are licensed with all the terms you think they
are, and everyone is given proper attribution.

IANAL but i think something that would make everyone happy is to have these
conditions apply:

1) When distributing the libraries in whole or in part the whole GPL
applies, with it's requirements on disclosure of source, copyleft, and
attribution.
2) In the special case of someone embedding the symbols in their design, a
simpler license would apply, where they can use a simplified attribution
requirement, people are forbidden from separating the symbols from the
design for their own use in other designs.

The attribution requirement for case #2 ideally would be a simple "Using
symbols/footprints/models for the Kicad project's library, version X" plus
some permalink where the GPL versions of the libraries can be obtained,
together with the attribution information (embedded in the GIT history, or
preferably an AUTHORS file). If that's not agreeable, perhaps an AUTHORS
file that can be downloaded and bundled with a non-gpl design should comply
with the attribution requirement.


On Mon, Sep 18, 2017 at 6:46 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> PS: It would be nice to provide a simplified way for non-GPL users to
>> provide attribution for the libraries without having to name every single
>> john doe that made a symbol or footprint. If it's made simple people will
>> probably be more inclined to comply.
>
>
> What would such a thing look like? Something like a CLA -
> https://en.wikipedia.org/wiki/Contributor_License_Agreement ?
>
> On Tue, Sep 19, 2017 at 9:02 AM, José Ignacio 
> wrote:
>
>> PS: It would be nice to provide a simplified way for non-GPL users to
>> provide attribution for the libraries without having to name every single
>> john doe that made a symbol or footprint. If it's made simple people will
>> probably be more inclined to comply.
>>
>> On Mon, Sep 18, 2017 at 5:59 PM, José Ignacio 
>> wrote:
>>
>>> The GPL with font exception is probably the better of the two, as it is
>>> the least restrictive one contributors seem to agree on.
>>>
>>> On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
>>> oliver.henry.walt...@gmail.com> wrote:
>>>
 A further issue that has cropped up twice in the last hour: Library
 licensing

 https://github.com/KiCad/kicad-library/issues/1259#issuecomm
 ent-330374095

 https://forum.kicad.info/t/default-libraries-gpl-licencing-v
 s-proprietary-designs/140/8


 We have been discussing this for a while in this thread -
 https://lists.launchpad.net/kicad-developers/msg28181.html

 It initially looked like we had a consensus but then it quickly
 devolved and never reached a conclusion.

 *Without entering into the same back-and-forth again, *and with the
 following stipulations:

 a) All libraries will have the same license agreeement
 b) A single LICENSE.md file will suffice

 What license should we be using?

 1. CC-BY-SA - This is what Wayne originally suggested IIRC
 2. modified GPL similar to gEDA license?


 I need a consensus on this so I can add the license files to the
 repositories and add the information to the website.

 Cheers,
 Oliver


 On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh >>> > wrote:

> Oliver,
>
> Great work!  This is really shaping up nicely.
>
> Cheers,
>
> Wayne
>
> On 9/17/2017 12:13 AM, Oliver Walters wrote:
> > Hugo can use external JSON data during the build step, so I've worked
> > out how to list the GitHub library releases directly onto the
> downloads
> > page!
> >
> > Some progress images here:
> >
> > https://imgur.com/a/2V6E3
> >
> > Most of the framework is in place now. I need some assistance with
> > wording for /discover/libraries but other than that, almost ready to
> go :)
> >
> > Oliver
> >
> > On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
> > mailto:oliver.henry.walters@g
> mail.com>>
> > wrote:
> >
> > Some more
> > progress: https://github.com/KiCad/kicad-library/issues/1622
> > 
> >
> > On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
> >  > > wrote:
> >
> > I have worked out how to transfer the KLC page to the Hugo
> > templating system (it is SO much harder to use than Jenkins
> :p)
> >
> > Example:
> >
> > https://i.im

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Huh, this looks pretty cool - https://github.com/cla-assistant/cla-assistant

On Tue, Sep 19, 2017 at 9:46 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> PS: It would be nice to provide a simplified way for non-GPL users to
>> provide attribution for the libraries without having to name every single
>> john doe that made a symbol or footprint. If it's made simple people will
>> probably be more inclined to comply.
>
>
> What would such a thing look like? Something like a CLA -
> https://en.wikipedia.org/wiki/Contributor_License_Agreement ?
>
> On Tue, Sep 19, 2017 at 9:02 AM, José Ignacio 
> wrote:
>
>> PS: It would be nice to provide a simplified way for non-GPL users to
>> provide attribution for the libraries without having to name every single
>> john doe that made a symbol or footprint. If it's made simple people will
>> probably be more inclined to comply.
>>
>> On Mon, Sep 18, 2017 at 5:59 PM, José Ignacio 
>> wrote:
>>
>>> The GPL with font exception is probably the better of the two, as it is
>>> the least restrictive one contributors seem to agree on.
>>>
>>> On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
>>> oliver.henry.walt...@gmail.com> wrote:
>>>
 A further issue that has cropped up twice in the last hour: Library
 licensing

 https://github.com/KiCad/kicad-library/issues/1259#issuecomm
 ent-330374095

 https://forum.kicad.info/t/default-libraries-gpl-licencing-v
 s-proprietary-designs/140/8


 We have been discussing this for a while in this thread -
 https://lists.launchpad.net/kicad-developers/msg28181.html

 It initially looked like we had a consensus but then it quickly
 devolved and never reached a conclusion.

 *Without entering into the same back-and-forth again, *and with the
 following stipulations:

 a) All libraries will have the same license agreeement
 b) A single LICENSE.md file will suffice

 What license should we be using?

 1. CC-BY-SA - This is what Wayne originally suggested IIRC
 2. modified GPL similar to gEDA license?


 I need a consensus on this so I can add the license files to the
 repositories and add the information to the website.

 Cheers,
 Oliver


 On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh >>> > wrote:

> Oliver,
>
> Great work!  This is really shaping up nicely.
>
> Cheers,
>
> Wayne
>
> On 9/17/2017 12:13 AM, Oliver Walters wrote:
> > Hugo can use external JSON data during the build step, so I've worked
> > out how to list the GitHub library releases directly onto the
> downloads
> > page!
> >
> > Some progress images here:
> >
> > https://imgur.com/a/2V6E3
> >
> > Most of the framework is in place now. I need some assistance with
> > wording for /discover/libraries but other than that, almost ready to
> go :)
> >
> > Oliver
> >
> > On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
> > mailto:oliver.henry.walters@g
> mail.com>>
> > wrote:
> >
> > Some more
> > progress: https://github.com/KiCad/kicad-library/issues/1622
> > 
> >
> > On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
> >  > > wrote:
> >
> > I have worked out how to transfer the KLC page to the Hugo
> > templating system (it is SO much harder to use than Jenkins
> :p)
> >
> > Example:
> >
> > https://i.imgur.com/4kZnvOA.png <
> https://i.imgur.com/4kZnvOA.png>
> >
> > The libraries information is also moved across, but that's
> just
> > static content so it's much simpler.
> >
> > I'll keep you posted.
> >
> > On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> >
> > On 9/14/2017 8:54 PM, Oliver Walters wrote:
> > > Ben,
> > >
> > > That's also an option, I hadn't considered that!
> Perhaps I was focused
> > > on the GitHub-side solution too closely.
> > >
> > > Wayne, do you want to weigh in here before I spend too
> much further
> > > effort developing this? Could the libraries page be
> developed on the
> > > KiCad website itself?
> >
> > The libraries page could be developed on KiCad website
> > although I'm not
> > sure how that would work.  I am comfortable with either
> > solution.  Pick
> > which ever solution is the most comfortable for you.
> Since
> > you are
> > doing the work, you should choose the im

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

>
> PS: It would be nice to provide a simplified way for non-GPL users to
> provide attribution for the libraries without having to name every single
> john doe that made a symbol or footprint. If it's made simple people will
> probably be more inclined to comply.


What would such a thing look like? Something like a CLA -
https://en.wikipedia.org/wiki/Contributor_License_Agreement ?

On Tue, Sep 19, 2017 at 9:02 AM, José Ignacio  wrote:

> PS: It would be nice to provide a simplified way for non-GPL users to
> provide attribution for the libraries without having to name every single
> john doe that made a symbol or footprint. If it's made simple people will
> probably be more inclined to comply.
>
> On Mon, Sep 18, 2017 at 5:59 PM, José Ignacio 
> wrote:
>
>> The GPL with font exception is probably the better of the two, as it is
>> the least restrictive one contributors seem to agree on.
>>
>> On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> A further issue that has cropped up twice in the last hour: Library
>>> licensing
>>>
>>> https://github.com/KiCad/kicad-library/issues/1259#issuecomm
>>> ent-330374095
>>>
>>> https://forum.kicad.info/t/default-libraries-gpl-licencing-v
>>> s-proprietary-designs/140/8
>>>
>>>
>>> We have been discussing this for a while in this thread -
>>> https://lists.launchpad.net/kicad-developers/msg28181.html
>>>
>>> It initially looked like we had a consensus but then it quickly devolved
>>> and never reached a conclusion.
>>>
>>> *Without entering into the same back-and-forth again, *and with the
>>> following stipulations:
>>>
>>> a) All libraries will have the same license agreeement
>>> b) A single LICENSE.md file will suffice
>>>
>>> What license should we be using?
>>>
>>> 1. CC-BY-SA - This is what Wayne originally suggested IIRC
>>> 2. modified GPL similar to gEDA license?
>>>
>>>
>>> I need a consensus on this so I can add the license files to the
>>> repositories and add the information to the website.
>>>
>>> Cheers,
>>> Oliver
>>>
>>>
>>> On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh 
>>> wrote:
>>>
 Oliver,

 Great work!  This is really shaping up nicely.

 Cheers,

 Wayne

 On 9/17/2017 12:13 AM, Oliver Walters wrote:
 > Hugo can use external JSON data during the build step, so I've worked
 > out how to list the GitHub library releases directly onto the
 downloads
 > page!
 >
 > Some progress images here:
 >
 > https://imgur.com/a/2V6E3
 >
 > Most of the framework is in place now. I need some assistance with
 > wording for /discover/libraries but other than that, almost ready to
 go :)
 >
 > Oliver
 >
 > On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
 > mailto:oliver.henry.walters@g
 mail.com>>
 > wrote:
 >
 > Some more
 > progress: https://github.com/KiCad/kicad-library/issues/1622
 > 
 >
 > On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
 > >>> > > wrote:
 >
 > I have worked out how to transfer the KLC page to the Hugo
 > templating system (it is SO much harder to use than Jenkins
 :p)
 >
 > Example:
 >
 > https://i.imgur.com/4kZnvOA.png <
 https://i.imgur.com/4kZnvOA.png>
 >
 > The libraries information is also moved across, but that's
 just
 > static content so it's much simpler.
 >
 > I'll keep you posted.
 >
 > On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh
 > mailto:stambau...@gmail.com>> wrote:
 >
 > On 9/14/2017 8:54 PM, Oliver Walters wrote:
 > > Ben,
 > >
 > > That's also an option, I hadn't considered that!
 Perhaps I was focused
 > > on the GitHub-side solution too closely.
 > >
 > > Wayne, do you want to weigh in here before I spend too
 much further
 > > effort developing this? Could the libraries page be
 developed on the
 > > KiCad website itself?
 >
 > The libraries page could be developed on KiCad website
 > although I'm not
 > sure how that would work.  I am comfortable with either
 > solution.  Pick
 > which ever solution is the most comfortable for you.
 Since
 > you are
 > doing the work, you should choose the implementation
 unless
 > someone else
 > is willing step up and help out.  Even the basic overview
 > that you
 > presented is far better than anything we have at the
 > moment.  We can
 > always add more featu

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Thanks for the links Rene.

Rene also found an older reference to a discussion between Wayne and
Torsten -
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg16268.html

This strongly suggests that the gEDA license is the way to go.

Unless I hear any very strong objections I shall go ahead and implement a
license message like this (as we have done for the 3D models).

Oliver


On Tue, Sep 19, 2017 at 9:17 AM, Rene Pöschl  wrote:

> On 19/09/17 00:59, José Ignacio wrote:
>
>> The GPL with font exception is probably the better of the two, as it is
>> the least restrictive one contributors seem to agree on
>>
>
>
> Well we use this already for the 3d model lib.
> https://github.com/KiCad/kicad-packages3D/wiki/Model-Licencing
>
> So it would actually suite us as well.
>
> And back in 2015 Wayne also suggested the gEDA route in this message:
> https://lists.launchpad.net/kicad-developers/msg21732.html <
> https://lists.launchpad.net/kicad-developers/msg28181.html>
>
> This is the reason we went down that route for the 3d models.
>
>
> On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com >
>> wrote:
>>
>> A further issue that has cropped up twice in the last hour:
>> Library licensing
>>
>> https://github.com/KiCad/kicad-library/issues/1259#issuecomm
>> ent-330374095
>> > ment-330374095>
>>
>> https://forum.kicad.info/t/default-libraries-gpl-licencing-
>> vs-proprietary-designs/140/8
>> > vs-proprietary-designs/140/8>
>>
>>
>> We have been discussing this for a while in this thread -
>> https://lists.launchpad.net/kicad-developers/msg28181.html
>> 
>>
>> It initially looked like we had a consensus but then it quickly
>> devolved and never reached a conclusion.
>>
>> *Without entering into the same back-and-forth again, *and with
>> the following stipulations:
>>
>> a) All libraries will have the same license agreeement
>> b) A single LICENSE.md file will suffice
>>
>> What license should we be using?
>>
>> 1. CC-BY-SA - This is what Wayne originally suggested IIRC
>> 2. modified GPL similar to gEDA license?
>>
>>
>> I need a consensus on this so I can add the license files to the
>> repositories and add the information to the website.
>>
>> Cheers,
>> Oliver
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Rene Pöschl]

On 19/09/17 00:59, José Ignacio wrote:
The GPL with font exception is probably the better of the two, as it 
is the least restrictive one contributors seem to agree on



Well we use this already for the 3d model lib.
https://github.com/KiCad/kicad-packages3D/wiki/Model-Licencing

So it would actually suite us as well.

And back in 2015 Wayne also suggested the gEDA route in this message:
https://lists.launchpad.net/kicad-developers/msg21732.html 



This is the reason we went down that route for the 3d models.


On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters 
> wrote:


A further issue that has cropped up twice in the last hour:
Library licensing

https://github.com/KiCad/kicad-library/issues/1259#issuecomment-330374095



https://forum.kicad.info/t/default-libraries-gpl-licencing-vs-proprietary-designs/140/8




We have been discussing this for a while in this thread -
https://lists.launchpad.net/kicad-developers/msg28181.html


It initially looked like we had a consensus but then it quickly
devolved and never reached a conclusion.

*Without entering into the same back-and-forth again, *and with
the following stipulations:

a) All libraries will have the same license agreeement
b) A single LICENSE.md file will suffice

What license should we be using?

1. CC-BY-SA - This is what Wayne originally suggested IIRC
2. modified GPL similar to gEDA license?


I need a consensus on this so I can add the license files to the
repositories and add the information to the website.

Cheers,
Oliver




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[José Ignacio]

PS: It would be nice to provide a simplified way for non-GPL users to
provide attribution for the libraries without having to name every single
john doe that made a symbol or footprint. If it's made simple people will
probably be more inclined to comply.

On Mon, Sep 18, 2017 at 5:59 PM, José Ignacio  wrote:

> The GPL with font exception is probably the better of the two, as it is
> the least restrictive one contributors seem to agree on.
>
> On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> A further issue that has cropped up twice in the last hour: Library
>> licensing
>>
>> https://github.com/KiCad/kicad-library/issues/1259#issuecomment-330374095
>>
>> https://forum.kicad.info/t/default-libraries-gpl-licencing-v
>> s-proprietary-designs/140/8
>>
>>
>> We have been discussing this for a while in this thread -
>> https://lists.launchpad.net/kicad-developers/msg28181.html
>>
>> It initially looked like we had a consensus but then it quickly devolved
>> and never reached a conclusion.
>>
>> *Without entering into the same back-and-forth again, *and with the
>> following stipulations:
>>
>> a) All libraries will have the same license agreeement
>> b) A single LICENSE.md file will suffice
>>
>> What license should we be using?
>>
>> 1. CC-BY-SA - This is what Wayne originally suggested IIRC
>> 2. modified GPL similar to gEDA license?
>>
>>
>> I need a consensus on this so I can add the license files to the
>> repositories and add the information to the website.
>>
>> Cheers,
>> Oliver
>>
>>
>> On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh 
>> wrote:
>>
>>> Oliver,
>>>
>>> Great work!  This is really shaping up nicely.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 9/17/2017 12:13 AM, Oliver Walters wrote:
>>> > Hugo can use external JSON data during the build step, so I've worked
>>> > out how to list the GitHub library releases directly onto the downloads
>>> > page!
>>> >
>>> > Some progress images here:
>>> >
>>> > https://imgur.com/a/2V6E3
>>> >
>>> > Most of the framework is in place now. I need some assistance with
>>> > wording for /discover/libraries but other than that, almost ready to
>>> go :)
>>> >
>>> > Oliver
>>> >
>>> > On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
>>> > mailto:oliver.henry.walt...@gmail.com
>>> >>
>>> > wrote:
>>> >
>>> > Some more
>>> > progress: https://github.com/KiCad/kicad-library/issues/1622
>>> > 
>>> >
>>> > On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
>>> > >> > > wrote:
>>> >
>>> > I have worked out how to transfer the KLC page to the Hugo
>>> > templating system (it is SO much harder to use than Jenkins
>>> :p)
>>> >
>>> > Example:
>>> >
>>> > https://i.imgur.com/4kZnvOA.png >> ng>
>>> >
>>> > The libraries information is also moved across, but that's just
>>> > static content so it's much simpler.
>>> >
>>> > I'll keep you posted.
>>> >
>>> > On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh
>>> > mailto:stambau...@gmail.com>> wrote:
>>> >
>>> > On 9/14/2017 8:54 PM, Oliver Walters wrote:
>>> > > Ben,
>>> > >
>>> > > That's also an option, I hadn't considered that! Perhaps
>>> I was focused
>>> > > on the GitHub-side solution too closely.
>>> > >
>>> > > Wayne, do you want to weigh in here before I spend too
>>> much further
>>> > > effort developing this? Could the libraries page be
>>> developed on the
>>> > > KiCad website itself?
>>> >
>>> > The libraries page could be developed on KiCad website
>>> > although I'm not
>>> > sure how that would work.  I am comfortable with either
>>> > solution.  Pick
>>> > which ever solution is the most comfortable for you.  Since
>>> > you are
>>> > doing the work, you should choose the implementation unless
>>> > someone else
>>> > is willing step up and help out.  Even the basic overview
>>> > that you
>>> > presented is far better than anything we have at the
>>> > moment.  We can
>>> > always add more features later.
>>> >
>>> > >
>>> > > The structure could remain largely the same but the
>>> formatting would
>>> > > need to change from Jekyll to Hugo.
>>> > >
>>> > > Cheers,
>>> > > Oliver
>>> > >
>>> > > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest <
>>> bombledm...@gmail.com 
>>> > > > bombledm...@gmail.com>>> wrote:
>>> > >
>>> > > Does this method provide an advantage over doing a
>>> similar thing
>>>

Re: [Kicad-developers] KiCad Libraries (again)

[José Ignacio]

The GPL with font exception is probably the better of the two, as it is the
least restrictive one contributors seem to agree on.

On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> A further issue that has cropped up twice in the last hour: Library
> licensing
>
> https://github.com/KiCad/kicad-library/issues/1259#issuecomment-330374095
>
> https://forum.kicad.info/t/default-libraries-gpl-licencing-
> vs-proprietary-designs/140/8
>
>
> We have been discussing this for a while in this thread -
> https://lists.launchpad.net/kicad-developers/msg28181.html
>
> It initially looked like we had a consensus but then it quickly devolved
> and never reached a conclusion.
>
> *Without entering into the same back-and-forth again, *and with the
> following stipulations:
>
> a) All libraries will have the same license agreeement
> b) A single LICENSE.md file will suffice
>
> What license should we be using?
>
> 1. CC-BY-SA - This is what Wayne originally suggested IIRC
> 2. modified GPL similar to gEDA license?
>
>
> I need a consensus on this so I can add the license files to the
> repositories and add the information to the website.
>
> Cheers,
> Oliver
>
>
> On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh 
> wrote:
>
>> Oliver,
>>
>> Great work!  This is really shaping up nicely.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 9/17/2017 12:13 AM, Oliver Walters wrote:
>> > Hugo can use external JSON data during the build step, so I've worked
>> > out how to list the GitHub library releases directly onto the downloads
>> > page!
>> >
>> > Some progress images here:
>> >
>> > https://imgur.com/a/2V6E3
>> >
>> > Most of the framework is in place now. I need some assistance with
>> > wording for /discover/libraries but other than that, almost ready to go
>> :)
>> >
>> > Oliver
>> >
>> > On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
>> > mailto:oliver.henry.walt...@gmail.com
>> >>
>> > wrote:
>> >
>> > Some more
>> > progress: https://github.com/KiCad/kicad-library/issues/1622
>> > 
>> >
>> > On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
>> > > > > wrote:
>> >
>> > I have worked out how to transfer the KLC page to the Hugo
>> > templating system (it is SO much harder to use than Jenkins :p)
>> >
>> > Example:
>> >
>> > https://i.imgur.com/4kZnvOA.png > ng>
>> >
>> > The libraries information is also moved across, but that's just
>> > static content so it's much simpler.
>> >
>> > I'll keep you posted.
>> >
>> > On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh
>> > mailto:stambau...@gmail.com>> wrote:
>> >
>> > On 9/14/2017 8:54 PM, Oliver Walters wrote:
>> > > Ben,
>> > >
>> > > That's also an option, I hadn't considered that! Perhaps
>> I was focused
>> > > on the GitHub-side solution too closely.
>> > >
>> > > Wayne, do you want to weigh in here before I spend too
>> much further
>> > > effort developing this? Could the libraries page be
>> developed on the
>> > > KiCad website itself?
>> >
>> > The libraries page could be developed on KiCad website
>> > although I'm not
>> > sure how that would work.  I am comfortable with either
>> > solution.  Pick
>> > which ever solution is the most comfortable for you.  Since
>> > you are
>> > doing the work, you should choose the implementation unless
>> > someone else
>> > is willing step up and help out.  Even the basic overview
>> > that you
>> > presented is far better than anything we have at the
>> > moment.  We can
>> > always add more features later.
>> >
>> > >
>> > > The structure could remain largely the same but the
>> formatting would
>> > > need to change from Jekyll to Hugo.
>> > >
>> > > Cheers,
>> > > Oliver
>> > >
>> > > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest <
>> bombledm...@gmail.com 
>> > >  bombledm...@gmail.com>>> wrote:
>> > >
>> > > Does this method provide an advantage over doing a
>> similar thing
>> > > using Hugo and putting the docs on the kicad-pcb.org
>> 
>> > > 
>> > > website? https://github.com/KiCad/kicad-website
>> > 
>> > > > > >
>> > >
>> > >
>> > >

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

A further issue that has cropped up twice in the last hour: Library
licensing

https://github.com/KiCad/kicad-library/issues/1259#issuecomment-330374095

https://forum.kicad.info/t/default-libraries-gpl-licencing-vs-proprietary-
designs/140/8


We have been discussing this for a while in this thread -
https://lists.launchpad.net/kicad-developers/msg28181.html

It initially looked like we had a consensus but then it quickly devolved
and never reached a conclusion.

*Without entering into the same back-and-forth again, *and with the
following stipulations:

a) All libraries will have the same license agreeement
b) A single LICENSE.md file will suffice

What license should we be using?

1. CC-BY-SA - This is what Wayne originally suggested IIRC
2. modified GPL similar to gEDA license?


I need a consensus on this so I can add the license files to the
repositories and add the information to the website.

Cheers,
Oliver


On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh 
wrote:

> Oliver,
>
> Great work!  This is really shaping up nicely.
>
> Cheers,
>
> Wayne
>
> On 9/17/2017 12:13 AM, Oliver Walters wrote:
> > Hugo can use external JSON data during the build step, so I've worked
> > out how to list the GitHub library releases directly onto the downloads
> > page!
> >
> > Some progress images here:
> >
> > https://imgur.com/a/2V6E3
> >
> > Most of the framework is in place now. I need some assistance with
> > wording for /discover/libraries but other than that, almost ready to go
> :)
> >
> > Oliver
> >
> > On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
> > mailto:oliver.henry.walt...@gmail.com>>
> > wrote:
> >
> > Some more
> > progress: https://github.com/KiCad/kicad-library/issues/1622
> > 
> >
> > On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
> >  > > wrote:
> >
> > I have worked out how to transfer the KLC page to the Hugo
> > templating system (it is SO much harder to use than Jenkins :p)
> >
> > Example:
> >
> > https://i.imgur.com/4kZnvOA.png  >
> >
> > The libraries information is also moved across, but that's just
> > static content so it's much simpler.
> >
> > I'll keep you posted.
> >
> > On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> >
> > On 9/14/2017 8:54 PM, Oliver Walters wrote:
> > > Ben,
> > >
> > > That's also an option, I hadn't considered that! Perhaps I
> was focused
> > > on the GitHub-side solution too closely.
> > >
> > > Wayne, do you want to weigh in here before I spend too
> much further
> > > effort developing this? Could the libraries page be
> developed on the
> > > KiCad website itself?
> >
> > The libraries page could be developed on KiCad website
> > although I'm not
> > sure how that would work.  I am comfortable with either
> > solution.  Pick
> > which ever solution is the most comfortable for you.  Since
> > you are
> > doing the work, you should choose the implementation unless
> > someone else
> > is willing step up and help out.  Even the basic overview
> > that you
> > presented is far better than anything we have at the
> > moment.  We can
> > always add more features later.
> >
> > >
> > > The structure could remain largely the same but the
> formatting would
> > > need to change from Jekyll to Hugo.
> > >
> > > Cheers,
> > > Oliver
> > >
> > > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest <
> bombledm...@gmail.com 
> > > >> wrote:
> > >
> > > Does this method provide an advantage over doing a
> similar thing
> > > using Hugo and putting the docs on the kicad-pcb.org <
> http://kicad-pcb.org>
> > > 
> > > website? https://github.com/KiCad/kicad-website
> > 
> > >  > >
> > >
> > >
> > > - Ben
> > >
> > > On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
> > >  > 
> > >  > >> wrote:
> > >
> > > Hi everyone,
> > >
> > 

Re: [Kicad-developers] KiCad Libraries (again)

[Wayne Stambaugh]

Oliver,

Great work!  This is really shaping up nicely.

Cheers,

Wayne

On 9/17/2017 12:13 AM, Oliver Walters wrote:
> Hugo can use external JSON data during the build step, so I've worked
> out how to list the GitHub library releases directly onto the downloads
> page!
> 
> Some progress images here:
> 
> https://imgur.com/a/2V6E3
> 
> Most of the framework is in place now. I need some assistance with
> wording for /discover/libraries but other than that, almost ready to go :)
> 
> Oliver
> 
> On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
> mailto:oliver.henry.walt...@gmail.com>>
> wrote:
> 
> Some more
> progress: https://github.com/KiCad/kicad-library/issues/1622
> 
> 
> On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
>  > wrote:
> 
> I have worked out how to transfer the KLC page to the Hugo
> templating system (it is SO much harder to use than Jenkins :p) 
> 
> Example:
> 
> https://i.imgur.com/4kZnvOA.png 
> 
> The libraries information is also moved across, but that's just
> static content so it's much simpler.
> 
> I'll keep you posted.
> 
> On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> 
> On 9/14/2017 8:54 PM, Oliver Walters wrote:
> > Ben,
> >
> > That's also an option, I hadn't considered that! Perhaps I was 
> focused
> > on the GitHub-side solution too closely.
> >
> > Wayne, do you want to weigh in here before I spend too much 
> further
> > effort developing this? Could the libraries page be developed 
> on the
> > KiCad website itself?
> 
> The libraries page could be developed on KiCad website
> although I'm not
> sure how that would work.  I am comfortable with either
> solution.  Pick
> which ever solution is the most comfortable for you.  Since
> you are
> doing the work, you should choose the implementation unless
> someone else
> is willing step up and help out.  Even the basic overview
> that you
> presented is far better than anything we have at the
> moment.  We can
> always add more features later.
> 
> >
> > The structure could remain largely the same but the formatting 
> would
> > need to change from Jekyll to Hugo.
> >
> > Cheers,
> > Oliver
> >
> > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest 
> mailto:bombledm...@gmail.com>
> > >> 
> wrote:
> >
> >     Does this method provide an advantage over doing a similar 
> thing
> >     using Hugo and putting the docs on the kicad-pcb.org 
> 
> >     
> >     website? https://github.com/KiCad/kicad-website
> 
> >      >
> >
> >
> >     - Ben
> >
> >     On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
> >      
> >      >> wrote:
> >
> >         Hi everyone,
> >
> >         The conversation of how best to manage and distribute 
> KiCad
> >         libraries has been raging for a while now.
> >
> >         Users looking to download or contribute to the 
> libraries are
> >         currently presented with a github landing page and some 
> bland
> >         wiki pages (e.g. for the KLC information).
> >
> >         I have been working on a new-and-improved website 
> system for the
> >         following:
> >
> >         * Clear information about the libraries
> >         * A place to download the latest libraries
> >         * Information on what is *in* the libraries
> >         * Instructions on how to contribute to the libs
> >         * Better presentation of the KLC
> >
> >         This website will need to be updated periodically to 
> present the
> >         latest version of the libraries to the users. Also, if 
> users are
> >         going to be downloading library files then it could 
> potentially
>  

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Diego,

This has already been done :)

On Sun, Sep 17, 2017 at 6:51 PM, Diego Herranz 
wrote:

> Hi, Oliver.
>
> Thanks a lot for your work on this. I think it's gonna be really useful,
> especially for newbies, but also for experienced users.
>
> Regarding the new repo to hold every footprint, I think it's the way to
> go, it's impossible to follow the progress and updates on a thousand repos.
> Should we call it kicad-footprints? To follow the same format as
> kicad-symbols.
>
> On another thread I said
> "Thinking of naming, should we use "kicad-packages3d" to keep the same
> format (kicad-symbols)"
> Which I think still applies?
>
> If you agree, can we rename both packages3d and footprints to
> kicad-packages3d and kicad-footprints before it's too late? Or
> kicad-symbols to symbols but I guess that's more difficult now?
>
> Thanks!
>
>
> On 17 Sep 2017 6:00 am, "Oliver Walters" 
> wrote:
>
>> I have also created a FOOTPRINTS repository at -
>> https://github.com/KiCad/footprints
>>
>> The intent is to have ALL the .pretty repos merged here, to combat the
>> ever decreasing maintainability of the libraries.
>>
>> For now, it contains each .pretty repository as an individual submodule.
>>
>> On Sun, Sep 17, 2017 at 2:13 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> Hugo can use external JSON data during the build step, so I've worked
>>> out how to list the GitHub library releases directly onto the downloads
>>> page!
>>>
>>> Some progress images here:
>>>
>>> https://imgur.com/a/2V6E3
>>>
>>> Most of the framework is in place now. I need some assistance with
>>> wording for /discover/libraries but other than that, almost ready to go :)
>>>
>>> Oliver
>>>
>>> On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters <
>>> oliver.henry.walt...@gmail.com> wrote:
>>>
 Some more progress: https://github.com/KiCad/kicad-library/issues/1622

 On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters <
 oliver.henry.walt...@gmail.com> wrote:

> I have worked out how to transfer the KLC page to the Hugo templating
> system (it is SO much harder to use than Jenkins :p)
>
> Example:
>
> https://i.imgur.com/4kZnvOA.png
>
> The libraries information is also moved across, but that's just static
> content so it's much simpler.
>
> I'll keep you posted.
>
> On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh <
> stambau...@gmail.com> wrote:
>
>> On 9/14/2017 8:54 PM, Oliver Walters wrote:
>> > Ben,
>> >
>> > That's also an option, I hadn't considered that! Perhaps I was
>> focused
>> > on the GitHub-side solution too closely.
>> >
>> > Wayne, do you want to weigh in here before I spend too much further
>> > effort developing this? Could the libraries page be developed on the
>> > KiCad website itself?
>>
>> The libraries page could be developed on KiCad website although I'm
>> not
>> sure how that would work.  I am comfortable with either solution.
>> Pick
>> which ever solution is the most comfortable for you.  Since you are
>> doing the work, you should choose the implementation unless someone
>> else
>> is willing step up and help out.  Even the basic overview that you
>> presented is far better than anything we have at the moment.  We can
>> always add more features later.
>>
>> >
>> > The structure could remain largely the same but the formatting would
>> > need to change from Jekyll to Hugo.
>> >
>> > Cheers,
>> > Oliver
>> >
>> > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest > > > wrote:
>> >
>> > Does this method provide an advantage over doing a similar thing
>> > using Hugo and putting the docs on the kicad-pcb.org
>> > 
>> > website? https://github.com/KiCad/kicad-website
>> > 
>> >
>> >
>> > - Ben
>> >
>> > On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
>> > > > > wrote:
>> >
>> > Hi everyone,
>> >
>> > The conversation of how best to manage and distribute KiCad
>> > libraries has been raging for a while now.
>> >
>> > Users looking to download or contribute to the libraries are
>> > currently presented with a github landing page and some
>> bland
>> > wiki pages (e.g. for the KLC information).
>> >
>> > I have been working on a new-and-improved website system
>> for the
>> > following:
>> >
>> > * Clear information about the libraries
>> > * A place to download the latest libraries
>> > * Information on what is *in* the libraries
>> > * Instructions on how to contribute to the libs
>> > * Better presentation 

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

I have also created a FOOTPRINTS repository at -
https://github.com/KiCad/footprints

The intent is to have ALL the .pretty repos merged here, to combat the ever
decreasing maintainability of the libraries.

For now, it contains each .pretty repository as an individual submodule.

On Sun, Sep 17, 2017 at 2:13 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Hugo can use external JSON data during the build step, so I've worked out
> how to list the GitHub library releases directly onto the downloads page!
>
> Some progress images here:
>
> https://imgur.com/a/2V6E3
>
> Most of the framework is in place now. I need some assistance with wording
> for /discover/libraries but other than that, almost ready to go :)
>
> Oliver
>
> On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Some more progress: https://github.com/KiCad/kicad-library/issues/1622
>>
>> On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> I have worked out how to transfer the KLC page to the Hugo templating
>>> system (it is SO much harder to use than Jenkins :p)
>>>
>>> Example:
>>>
>>> https://i.imgur.com/4kZnvOA.png
>>>
>>> The libraries information is also moved across, but that's just static
>>> content so it's much simpler.
>>>
>>> I'll keep you posted.
>>>
>>> On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh 
>>> wrote:
>>>
 On 9/14/2017 8:54 PM, Oliver Walters wrote:
 > Ben,
 >
 > That's also an option, I hadn't considered that! Perhaps I was focused
 > on the GitHub-side solution too closely.
 >
 > Wayne, do you want to weigh in here before I spend too much further
 > effort developing this? Could the libraries page be developed on the
 > KiCad website itself?

 The libraries page could be developed on KiCad website although I'm not
 sure how that would work.  I am comfortable with either solution.  Pick
 which ever solution is the most comfortable for you.  Since you are
 doing the work, you should choose the implementation unless someone else
 is willing step up and help out.  Even the basic overview that you
 presented is far better than anything we have at the moment.  We can
 always add more features later.

 >
 > The structure could remain largely the same but the formatting would
 > need to change from Jekyll to Hugo.
 >
 > Cheers,
 > Oliver
 >
 > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest >>> > > wrote:
 >
 > Does this method provide an advantage over doing a similar thing
 > using Hugo and putting the docs on the kicad-pcb.org
 > 
 > website? https://github.com/KiCad/kicad-website
 > 
 >
 >
 > - Ben
 >
 > On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
 > >>> > > wrote:
 >
 > Hi everyone,
 >
 > The conversation of how best to manage and distribute KiCad
 > libraries has been raging for a while now.
 >
 > Users looking to download or contribute to the libraries are
 > currently presented with a github landing page and some bland
 > wiki pages (e.g. for the KLC information).
 >
 > I have been working on a new-and-improved website system for
 the
 > following:
 >
 > * Clear information about the libraries
 > * A place to download the latest libraries
 > * Information on what is *in* the libraries
 > * Instructions on how to contribute to the libs
 > * Better presentation of the KLC
 >
 > This website will need to be updated periodically to present
 the
 > latest version of the libraries to the users. Also, if users
 are
 > going to be downloading library files then it could
 potentially
 > use a lot of bandwidth. Thirdly, the generated content should
 be
 > scripted but statically hosted.
 >
 > The solution? GitHub pages! - https://pages.github.com/ -
 >
 > These are hosted from your github repository, and for e.g.
 ours
 > would have the URL kicad.github.io  -
 > this could be easily redirected from kicad-lib.org/library
 >  (for example).
 >
 > GitHub pages use the jekyll toolset to generate static
 content.
 >
 > With a small amount of additional Python scripting I have
 > created a bare-bones example of what this might look like
 > (locally hosted on my laptop for now):
 >
 > Here are some screenshots! Ignore the colors and simple layout
 > sc

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Hugo can use external JSON data during the build step, so I've worked out
how to list the GitHub library releases directly onto the downloads page!

Some progress images here:

https://imgur.com/a/2V6E3

Most of the framework is in place now. I need some assistance with wording
for /discover/libraries but other than that, almost ready to go :)

Oliver

On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Some more progress: https://github.com/KiCad/kicad-library/issues/1622
>
> On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> I have worked out how to transfer the KLC page to the Hugo templating
>> system (it is SO much harder to use than Jenkins :p)
>>
>> Example:
>>
>> https://i.imgur.com/4kZnvOA.png
>>
>> The libraries information is also moved across, but that's just static
>> content so it's much simpler.
>>
>> I'll keep you posted.
>>
>> On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh 
>> wrote:
>>
>>> On 9/14/2017 8:54 PM, Oliver Walters wrote:
>>> > Ben,
>>> >
>>> > That's also an option, I hadn't considered that! Perhaps I was focused
>>> > on the GitHub-side solution too closely.
>>> >
>>> > Wayne, do you want to weigh in here before I spend too much further
>>> > effort developing this? Could the libraries page be developed on the
>>> > KiCad website itself?
>>>
>>> The libraries page could be developed on KiCad website although I'm not
>>> sure how that would work.  I am comfortable with either solution.  Pick
>>> which ever solution is the most comfortable for you.  Since you are
>>> doing the work, you should choose the implementation unless someone else
>>> is willing step up and help out.  Even the basic overview that you
>>> presented is far better than anything we have at the moment.  We can
>>> always add more features later.
>>>
>>> >
>>> > The structure could remain largely the same but the formatting would
>>> > need to change from Jekyll to Hugo.
>>> >
>>> > Cheers,
>>> > Oliver
>>> >
>>> > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest >> > > wrote:
>>> >
>>> > Does this method provide an advantage over doing a similar thing
>>> > using Hugo and putting the docs on the kicad-pcb.org
>>> > 
>>> > website? https://github.com/KiCad/kicad-website
>>> > 
>>> >
>>> >
>>> > - Ben
>>> >
>>> > On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
>>> > >> > > wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > The conversation of how best to manage and distribute KiCad
>>> > libraries has been raging for a while now.
>>> >
>>> > Users looking to download or contribute to the libraries are
>>> > currently presented with a github landing page and some bland
>>> > wiki pages (e.g. for the KLC information).
>>> >
>>> > I have been working on a new-and-improved website system for
>>> the
>>> > following:
>>> >
>>> > * Clear information about the libraries
>>> > * A place to download the latest libraries
>>> > * Information on what is *in* the libraries
>>> > * Instructions on how to contribute to the libs
>>> > * Better presentation of the KLC
>>> >
>>> > This website will need to be updated periodically to present
>>> the
>>> > latest version of the libraries to the users. Also, if users
>>> are
>>> > going to be downloading library files then it could potentially
>>> > use a lot of bandwidth. Thirdly, the generated content should
>>> be
>>> > scripted but statically hosted.
>>> >
>>> > The solution? GitHub pages! - https://pages.github.com/ -
>>> >
>>> > These are hosted from your github repository, and for e.g. ours
>>> > would have the URL kicad.github.io  -
>>> > this could be easily redirected from kicad-lib.org/library
>>> >  (for example).
>>> >
>>> > GitHub pages use the jekyll toolset to generate static content.
>>> >
>>> > With a small amount of additional Python scripting I have
>>> > created a bare-bones example of what this might look like
>>> > (locally hosted on my laptop for now):
>>> >
>>> > Here are some screenshots! Ignore the colors and simple layout
>>> > scheme, this is currently just a framework.
>>> >
>>> > https://imgur.com/a/0GELG
>>> >
>>> > The main objectives of this project are:
>>> >
>>> > a) Present a more professional landing page for the libraries
>>> > b) Leverage GitHub Pages functionality
>>> > c) Improve KLC
>>> >
>>> > And, eventually:
>>> >
>>> > Provide a standardised way to separate the KiCad libraries from
>>> > the KiCad installer!
>>> >
>>> > Thoughts and comments appr

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Some more progress: https://github.com/KiCad/kicad-library/issues/1622

On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> I have worked out how to transfer the KLC page to the Hugo templating
> system (it is SO much harder to use than Jenkins :p)
>
> Example:
>
> https://i.imgur.com/4kZnvOA.png
>
> The libraries information is also moved across, but that's just static
> content so it's much simpler.
>
> I'll keep you posted.
>
> On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh 
> wrote:
>
>> On 9/14/2017 8:54 PM, Oliver Walters wrote:
>> > Ben,
>> >
>> > That's also an option, I hadn't considered that! Perhaps I was focused
>> > on the GitHub-side solution too closely.
>> >
>> > Wayne, do you want to weigh in here before I spend too much further
>> > effort developing this? Could the libraries page be developed on the
>> > KiCad website itself?
>>
>> The libraries page could be developed on KiCad website although I'm not
>> sure how that would work.  I am comfortable with either solution.  Pick
>> which ever solution is the most comfortable for you.  Since you are
>> doing the work, you should choose the implementation unless someone else
>> is willing step up and help out.  Even the basic overview that you
>> presented is far better than anything we have at the moment.  We can
>> always add more features later.
>>
>> >
>> > The structure could remain largely the same but the formatting would
>> > need to change from Jekyll to Hugo.
>> >
>> > Cheers,
>> > Oliver
>> >
>> > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest > > > wrote:
>> >
>> > Does this method provide an advantage over doing a similar thing
>> > using Hugo and putting the docs on the kicad-pcb.org
>> > 
>> > website? https://github.com/KiCad/kicad-website
>> > 
>> >
>> >
>> > - Ben
>> >
>> > On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
>> > > > > wrote:
>> >
>> > Hi everyone,
>> >
>> > The conversation of how best to manage and distribute KiCad
>> > libraries has been raging for a while now.
>> >
>> > Users looking to download or contribute to the libraries are
>> > currently presented with a github landing page and some bland
>> > wiki pages (e.g. for the KLC information).
>> >
>> > I have been working on a new-and-improved website system for the
>> > following:
>> >
>> > * Clear information about the libraries
>> > * A place to download the latest libraries
>> > * Information on what is *in* the libraries
>> > * Instructions on how to contribute to the libs
>> > * Better presentation of the KLC
>> >
>> > This website will need to be updated periodically to present the
>> > latest version of the libraries to the users. Also, if users are
>> > going to be downloading library files then it could potentially
>> > use a lot of bandwidth. Thirdly, the generated content should be
>> > scripted but statically hosted.
>> >
>> > The solution? GitHub pages! - https://pages.github.com/ -
>> >
>> > These are hosted from your github repository, and for e.g. ours
>> > would have the URL kicad.github.io  -
>> > this could be easily redirected from kicad-lib.org/library
>> >  (for example).
>> >
>> > GitHub pages use the jekyll toolset to generate static content.
>> >
>> > With a small amount of additional Python scripting I have
>> > created a bare-bones example of what this might look like
>> > (locally hosted on my laptop for now):
>> >
>> > Here are some screenshots! Ignore the colors and simple layout
>> > scheme, this is currently just a framework.
>> >
>> > https://imgur.com/a/0GELG
>> >
>> > The main objectives of this project are:
>> >
>> > a) Present a more professional landing page for the libraries
>> > b) Leverage GitHub Pages functionality
>> > c) Improve KLC
>> >
>> > And, eventually:
>> >
>> > Provide a standardised way to separate the KiCad libraries from
>> > the KiCad installer!
>> >
>> > Thoughts and comments appreciated!
>> >
>> > Cheers,
>> >
>> > Oliver
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > 
>> > Post to : kicad-developers@lists.launchpad.net
>> > 
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > 
>> > More help   : https://help.launchpad.net/ListHelp
>> > 

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

I have worked out how to transfer the KLC page to the Hugo templating
system (it is SO much harder to use than Jenkins :p)

Example:

https://i.imgur.com/4kZnvOA.png

The libraries information is also moved across, but that's just static
content so it's much simpler.

I'll keep you posted.

On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh 
wrote:

> On 9/14/2017 8:54 PM, Oliver Walters wrote:
> > Ben,
> >
> > That's also an option, I hadn't considered that! Perhaps I was focused
> > on the GitHub-side solution too closely.
> >
> > Wayne, do you want to weigh in here before I spend too much further
> > effort developing this? Could the libraries page be developed on the
> > KiCad website itself?
>
> The libraries page could be developed on KiCad website although I'm not
> sure how that would work.  I am comfortable with either solution.  Pick
> which ever solution is the most comfortable for you.  Since you are
> doing the work, you should choose the implementation unless someone else
> is willing step up and help out.  Even the basic overview that you
> presented is far better than anything we have at the moment.  We can
> always add more features later.
>
> >
> > The structure could remain largely the same but the formatting would
> > need to change from Jekyll to Hugo.
> >
> > Cheers,
> > Oliver
> >
> > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest  > > wrote:
> >
> > Does this method provide an advantage over doing a similar thing
> > using Hugo and putting the docs on the kicad-pcb.org
> > 
> > website? https://github.com/KiCad/kicad-website
> > 
> >
> >
> > - Ben
> >
> > On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
> >  > > wrote:
> >
> > Hi everyone,
> >
> > The conversation of how best to manage and distribute KiCad
> > libraries has been raging for a while now.
> >
> > Users looking to download or contribute to the libraries are
> > currently presented with a github landing page and some bland
> > wiki pages (e.g. for the KLC information).
> >
> > I have been working on a new-and-improved website system for the
> > following:
> >
> > * Clear information about the libraries
> > * A place to download the latest libraries
> > * Information on what is *in* the libraries
> > * Instructions on how to contribute to the libs
> > * Better presentation of the KLC
> >
> > This website will need to be updated periodically to present the
> > latest version of the libraries to the users. Also, if users are
> > going to be downloading library files then it could potentially
> > use a lot of bandwidth. Thirdly, the generated content should be
> > scripted but statically hosted.
> >
> > The solution? GitHub pages! - https://pages.github.com/ -
> >
> > These are hosted from your github repository, and for e.g. ours
> > would have the URL kicad.github.io  -
> > this could be easily redirected from kicad-lib.org/library
> >  (for example).
> >
> > GitHub pages use the jekyll toolset to generate static content.
> >
> > With a small amount of additional Python scripting I have
> > created a bare-bones example of what this might look like
> > (locally hosted on my laptop for now):
> >
> > Here are some screenshots! Ignore the colors and simple layout
> > scheme, this is currently just a framework.
> >
> > https://imgur.com/a/0GELG
> >
> > The main objectives of this project are:
> >
> > a) Present a more professional landing page for the libraries
> > b) Leverage GitHub Pages functionality
> > c) Improve KLC
> >
> > And, eventually:
> >
> > Provide a standardised way to separate the KiCad libraries from
> > the KiCad installer!
> >
> > Thoughts and comments appreciated!
> >
> > Cheers,
> >
> > Oliver
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
> >
> >
> > --
> >
> > -Ben
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~ki

Re: [Kicad-developers] KiCad Libraries (again)

[Simon Richter]

Hi,

On 15.09.2017 04:14, Oliver Walters wrote:

> Full description of library elements, including image previews /
> metadata / etc. This will be searchable.

I'd like to also get a culture going where the library is a huge
commons, and it is acceptable and encouraged to improve existing parts:

 - I have a lot of parts in "works for me" state, where I have made a
board that works, but where the part does not fully fulfill the KLC, so
is unsuitable for upload into the library as it is.

 - I'm planning a few changes to kicad for better support of large ICs
and ICs with multifunction pins, where we might want to add information
to a part we cannot currently encode (e.g. complex pin swapping rules
for large FPGAs).

Both nonconforming but working, and outdated elements still have some
value, so I'd like to keep them in the library but mark them in listings
so users can decide whether they want to use these as-is, improve them
or replace them with a new version.

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Ruth Ivimey-Cook]

Oliver, thanks for your efforts on this.

I have been thinking for a while that the current way libraries are 
located and downloaded could benefit from improvement:


- At present the symbol, footprint and 3d libs are/can be installed 
site-wide (e.g. Mac /Library/Application Support/kicad/ folder), and I 
believe for novice and intermediate users it is not obvious that this is 
the case or how to change it. I know the 'Configure paths dialog and the 
various library update actions exist, but I don't think it is a very 
good solution.


- It can be hard to find appropriate parts, especially if you want to 
include more than the official repo in your scope.


Would it be useful to have a library manager tool that could not only 
edit entries but also set up per-project library folders and manage 
which versions of which remote libraries are downloaded -- a bit like 
'apt' and 'synaptic' do for linux packages, but with more control over 
where the packages were installed (e.g. per project, per user login, on 
a network share) and which versions were used, as for python's 'virtualenv'.


It might even be useful for the tool to be able to list which components 
came from which library and check whether the cached copy matches it.


Is this a direction the community would benefit from? If it were taken 
would it impact on the website work you are looking at?


Regards,

Ruth


On 14/09/2017 13:01, Oliver Walters wrote:

Hi everyone,

The conversation of how best to manage and distribute KiCad libraries 
has been raging for a while now.


Users looking to download or contribute to the libraries are currently 
presented with a github landing page and some bland wiki pages (e.g. 
for the KLC information).


I have been working on a new-and-improved website system for the 
following:


* Clear information about the libraries
* A place to download the latest libraries
* Information on what is *in* the libraries
* Instructions on how to contribute to the libs
* Better presentation of the KLC

This website will need to be updated periodically to present the 
latest version of the libraries to the users. Also, if users are going 
to be downloading library files then it could potentially use a lot of 
bandwidth. Thirdly, the generated content should be scripted but 
statically hosted.


The solution? GitHub pages! - https://pages.github.com/ -

These are hosted from your github repository, and for e.g. ours would 
have the URL kicad.github.io  - this could be 
easily redirected from kicad-lib.org/library 
 (for example).


GitHub pages use the jekyll toolset to generate static content.

With a small amount of additional Python scripting I have created a 
bare-bones example of what this might look like (locally hosted on my 
laptop for now):


Here are some screenshots! Ignore the colors and simple layout scheme, 
this is currently just a framework.


https://imgur.com/a/0GELG

The main objectives of this project are:

a) Present a more professional landing page for the libraries
b) Leverage GitHub Pages functionality
c) Improve KLC

And, eventually:

Provide a standardised way to separate the KiCad libraries from the 
KiCad installer!


Thoughts and comments appreciated!

Cheers,

Oliver


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Ingo Kletti]

Oliver,

Am 15.09.2017 um 00:27 schrieb Oliver Walters:



A minor nitpick from personal preference: An always visible table of
contents for easy jumping between pages and/or breadcrumb navigation
would be great.



Can you provide an example of what you mean?


From the screenshots, I derive the following basic website structure 
(caution: ASCII art)



KiCad Libraries
!
+- Contribute
!
+- KLC front matter
!  !
!  +- KLC requirements - General
!  !
!  +- KLC requirements - Symbols
!  !
!  +- ...
!
+- Libraries information page
   !
   +- Symbol libraries
   !
   +- Footprint libraries
   !
   +- ...


I'll take the last two of your screenshots as an example:

Following the link for "Symbols" on the "Library information page" takes 
you down one level to the "Symbol libraries".


On that page there's no reference how I got there and no navigation aid. 
To get back one level to the "Library information page" you'd have to 
use the "Back" function of your browser. Or you could follow the 
"Library" link in the upper right corner.


ATM this is no big deal, but if the content should some day be expanded 
to library/symbol previews, etc., this will propably add a third layer 
of content below the "Symbol libraries".


The KiCad website already has breadcrumb navigation (the grey horizontal 
bar below the header images) at and a TOC on the right side as 
navigation aids (except on the "Blog" subsection).


This makes arbitrary jumps between subcontent much easier than going 
back and following another link.



Regards,

Ingo

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Wayne Stambaugh]

On 9/14/2017 8:54 PM, Oliver Walters wrote:
> Ben,
> 
> That's also an option, I hadn't considered that! Perhaps I was focused
> on the GitHub-side solution too closely.
> 
> Wayne, do you want to weigh in here before I spend too much further
> effort developing this? Could the libraries page be developed on the
> KiCad website itself?

The libraries page could be developed on KiCad website although I'm not
sure how that would work.  I am comfortable with either solution.  Pick
which ever solution is the most comfortable for you.  Since you are
doing the work, you should choose the implementation unless someone else
is willing step up and help out.  Even the basic overview that you
presented is far better than anything we have at the moment.  We can
always add more features later.

> 
> The structure could remain largely the same but the formatting would
> need to change from Jekyll to Hugo.
> 
> Cheers,
> Oliver
> 
> On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest  > wrote:
> 
> Does this method provide an advantage over doing a similar thing
> using Hugo and putting the docs on the kicad-pcb.org
> 
> website? https://github.com/KiCad/kicad-website
> 
> 
> 
> - Ben
> 
> On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
>  > wrote:
> 
> Hi everyone,
> 
> The conversation of how best to manage and distribute KiCad
> libraries has been raging for a while now.
> 
> Users looking to download or contribute to the libraries are
> currently presented with a github landing page and some bland
> wiki pages (e.g. for the KLC information).
> 
> I have been working on a new-and-improved website system for the
> following:
> 
> * Clear information about the libraries
> * A place to download the latest libraries
> * Information on what is *in* the libraries
> * Instructions on how to contribute to the libs
> * Better presentation of the KLC
> 
> This website will need to be updated periodically to present the
> latest version of the libraries to the users. Also, if users are
> going to be downloading library files then it could potentially
> use a lot of bandwidth. Thirdly, the generated content should be
> scripted but statically hosted.
> 
> The solution? GitHub pages! - https://pages.github.com/ -
> 
> These are hosted from your github repository, and for e.g. ours
> would have the URL kicad.github.io  -
> this could be easily redirected from kicad-lib.org/library
>  (for example).
> 
> GitHub pages use the jekyll toolset to generate static content.
> 
> With a small amount of additional Python scripting I have
> created a bare-bones example of what this might look like
> (locally hosted on my laptop for now):
> 
> Here are some screenshots! Ignore the colors and simple layout
> scheme, this is currently just a framework.
> 
> https://imgur.com/a/0GELG
> 
> The main objectives of this project are:
> 
> a) Present a more professional landing page for the libraries
> b) Leverage GitHub Pages functionality
> c) Improve KLC
> 
> And, eventually:
> 
> Provide a standardised way to separate the KiCad libraries from
> the KiCad installer! 
> 
> Thoughts and comments appreciated!
> 
> Cheers,
> 
> Oliver
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> -- 
> 
> -Ben
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Carsten Schoenert]

Hi,

TL;DR
yes, please place information about new libraries, their changes and
plans on this to the KiCad website! But also keep information about
changed documentation or localizations here.

Am 15.09.2017 um 04:01 schrieb Adam Wolf:
> I really, really like the idea of having the libraries page on the
> KiCad website itself.
> 
> I have run into numerous people who do not understand that the github
> libraries are "official".  Plus, this means that *for whatever reason*
> if the libraries move from github, the pages explaining the libraries
> stay in the same space.

And here the long version.
I guess the KiCad project can improving themselves here still a lot.
Even for me who is working with KiCad for now over two years it's
sometimes not really clear where to find something or what has changed.

It's fine to read a compact summarize of changes inside the binaries
that are the core of KiCad. But from a view of a packager KiCad for
Debian I need to invest a lot of time to collect all the various
information that I need to do a good packaging of all the KiCad stuff!
And this time is lost or not usable to do other things like testing
before going live with a new set of packages.

So, while Wayne is giving a overview of the bugfixes and modifications
for new stable release I totally miss such a overview for the libraries,
documentation and the internationalizing. This gives me the feeling
KiCad isn't *one* project, but more a project with a individual subsets
of projects that do not communicate as I expected this from a well
working project.
The Social Contract and the DFSG (Debian Free Software Guidelines) [1]
are really short, but especially point 4 of the Social Contract helps me
often to decide what to do if I'm unsure.

> Our priorities are our users and free software

The point is really small but holds all the sense of not only my doing,
so I'd wished KiCad has a more global thinking about the project. KiCad
aren't the applications only!

And one more point on the libraries and GitHub, please keep in mind that
probably a lot users don't may have direct access or only restricted
access to GitHub or the Internet at all! Even in the middle of Europe or
America there are places there is no fast Internet is available or
people are sitting simply behind a firewall that is not allowing free
access to GitHub or whatever website. All those user are depending on
off line downloads and on new released versions.
>From a users POV it's than hard to understand that libraries and there
structure of them have changed a lot between two micro versions!

[1] https://www.debian.org/social_contract

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Adam Wolf]

This sounds awesome to me, and helps keep KiCad cohesive.  I remember
when basically every KiCad site was a fan site and it was pretty hard
to find anything, and we have done a great job lately and this is
going to help make it even better I think!

I do not think that this even technically requires to change the
static site engine, if you already have a lot of work or a reason to
stick with whatever you have already used.  It is pretty easy for the
site folks to host the static site out of a different directory, for
example.  (It's a bummer when you show something cool to a mailing
list and everyone is enthusiastic but then asks you do to more work or
to redo what you already did :) )

On Thu, Sep 14, 2017 at 9:14 PM, Oliver Walters
 wrote:
> Adam,
>
> Both are really good points.
>
> Here's what I propose:
>
> Short Term:
>
> Move the library information / license / KLC / contributing information to
> the website. This will also include links to download library releases (from
> github)
>
> Medium Term:
>
> Provide downloads of individual libraries, which will be hosted (??
> somewhere ?? )
>
> Long Term:
>
> Full description of library elements, including image previews / metadata /
> etc. This will be searchable.
>
> Actual library data remains on GitHub, obviously.
>
> On Fri, Sep 15, 2017 at 12:01 PM, Adam Wolf 
> wrote:
>>
>> I really, really like the idea of having the libraries page on the
>> KiCad website itself.
>>
>> I have run into numerous people who do not understand that the github
>> libraries are "official".  Plus, this means that *for whatever reason*
>> if the libraries move from github, the pages explaining the libraries
>> stay in the same space.
>>
>> Adam Wolf
>>
>> On Thu, Sep 14, 2017 at 7:54 PM, Oliver Walters
>>  wrote:
>> > Ben,
>> >
>> > That's also an option, I hadn't considered that! Perhaps I was focused
>> > on
>> > the GitHub-side solution too closely.
>> >
>> > Wayne, do you want to weigh in here before I spend too much further
>> > effort
>> > developing this? Could the libraries page be developed on the KiCad
>> > website
>> > itself?
>> >
>> > The structure could remain largely the same but the formatting would
>> > need to
>> > change from Jekyll to Hugo.
>> >
>> > Cheers,
>> > Oliver
>> >
>> > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest  wrote:
>> >>
>> >> Does this method provide an advantage over doing a similar thing using
>> >> Hugo and putting the docs on the kicad-pcb.org website?
>> >> https://github.com/KiCad/kicad-website
>> >>
>> >>
>> >> - Ben
>> >>
>> >> On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
>> >>  wrote:
>> >>>
>> >>> Hi everyone,
>> >>>
>> >>> The conversation of how best to manage and distribute KiCad libraries
>> >>> has
>> >>> been raging for a while now.
>> >>>
>> >>> Users looking to download or contribute to the libraries are currently
>> >>> presented with a github landing page and some bland wiki pages (e.g.
>> >>> for the
>> >>> KLC information).
>> >>>
>> >>> I have been working on a new-and-improved website system for the
>> >>> following:
>> >>>
>> >>> * Clear information about the libraries
>> >>> * A place to download the latest libraries
>> >>> * Information on what is *in* the libraries
>> >>> * Instructions on how to contribute to the libs
>> >>> * Better presentation of the KLC
>> >>>
>> >>> This website will need to be updated periodically to present the
>> >>> latest
>> >>> version of the libraries to the users. Also, if users are going to be
>> >>> downloading library files then it could potentially use a lot of
>> >>> bandwidth.
>> >>> Thirdly, the generated content should be scripted but statically
>> >>> hosted.
>> >>>
>> >>> The solution? GitHub pages! - https://pages.github.com/ -
>> >>>
>> >>> These are hosted from your github repository, and for e.g. ours would
>> >>> have the URL kicad.github.io - this could be easily redirected from
>> >>> kicad-lib.org/library (for example).
>> >>>
>> >>> GitHub pages use the jekyll toolset to generate static content.
>> >>>
>> >>> With a small amount of additional Python scripting I have created a
>> >>> bare-bones example of what this might look like (locally hosted on my
>> >>> laptop
>> >>> for now):
>> >>>
>> >>> Here are some screenshots! Ignore the colors and simple layout scheme,
>> >>> this is currently just a framework.
>> >>>
>> >>> https://imgur.com/a/0GELG
>> >>>
>> >>> The main objectives of this project are:
>> >>>
>> >>> a) Present a more professional landing page for the libraries
>> >>> b) Leverage GitHub Pages functionality
>> >>> c) Improve KLC
>> >>>
>> >>> And, eventually:
>> >>>
>> >>> Provide a standardised way to separate the KiCad libraries from the
>> >>> KiCad
>> >>> installer!
>> >>>
>> >>> Thoughts and comments appreciated!
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Oliver
>> >>>
>> >>> ___
>> >>> Mailing list: https://launchpad.net/~kicad-developers
>> >>> Post to : kicad-developers@lists.launchpad.net
>> >>> 

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Adam,

Both are really good points.

Here's what I propose:

*Short Term:*

Move the library information / license / KLC / contributing information to
the website. This will also include links to download library releases
(from github)

*Medium Term:*

Provide downloads of individual libraries, which will be hosted (??
somewhere ?? )

*Long Term:*

Full description of library elements, including image previews / metadata /
etc. This will be searchable.

Actual library data remains on GitHub, obviously.

On Fri, Sep 15, 2017 at 12:01 PM, Adam Wolf 
wrote:

> I really, really like the idea of having the libraries page on the
> KiCad website itself.
>
> I have run into numerous people who do not understand that the github
> libraries are "official".  Plus, this means that *for whatever reason*
> if the libraries move from github, the pages explaining the libraries
> stay in the same space.
>
> Adam Wolf
>
> On Thu, Sep 14, 2017 at 7:54 PM, Oliver Walters
>  wrote:
> > Ben,
> >
> > That's also an option, I hadn't considered that! Perhaps I was focused on
> > the GitHub-side solution too closely.
> >
> > Wayne, do you want to weigh in here before I spend too much further
> effort
> > developing this? Could the libraries page be developed on the KiCad
> website
> > itself?
> >
> > The structure could remain largely the same but the formatting would
> need to
> > change from Jekyll to Hugo.
> >
> > Cheers,
> > Oliver
> >
> > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest  wrote:
> >>
> >> Does this method provide an advantage over doing a similar thing using
> >> Hugo and putting the docs on the kicad-pcb.org website?
> >> https://github.com/KiCad/kicad-website
> >>
> >>
> >> - Ben
> >>
> >> On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
> >>  wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> The conversation of how best to manage and distribute KiCad libraries
> has
> >>> been raging for a while now.
> >>>
> >>> Users looking to download or contribute to the libraries are currently
> >>> presented with a github landing page and some bland wiki pages (e.g.
> for the
> >>> KLC information).
> >>>
> >>> I have been working on a new-and-improved website system for the
> >>> following:
> >>>
> >>> * Clear information about the libraries
> >>> * A place to download the latest libraries
> >>> * Information on what is *in* the libraries
> >>> * Instructions on how to contribute to the libs
> >>> * Better presentation of the KLC
> >>>
> >>> This website will need to be updated periodically to present the latest
> >>> version of the libraries to the users. Also, if users are going to be
> >>> downloading library files then it could potentially use a lot of
> bandwidth.
> >>> Thirdly, the generated content should be scripted but statically
> hosted.
> >>>
> >>> The solution? GitHub pages! - https://pages.github.com/ -
> >>>
> >>> These are hosted from your github repository, and for e.g. ours would
> >>> have the URL kicad.github.io - this could be easily redirected from
> >>> kicad-lib.org/library (for example).
> >>>
> >>> GitHub pages use the jekyll toolset to generate static content.
> >>>
> >>> With a small amount of additional Python scripting I have created a
> >>> bare-bones example of what this might look like (locally hosted on my
> laptop
> >>> for now):
> >>>
> >>> Here are some screenshots! Ignore the colors and simple layout scheme,
> >>> this is currently just a framework.
> >>>
> >>> https://imgur.com/a/0GELG
> >>>
> >>> The main objectives of this project are:
> >>>
> >>> a) Present a more professional landing page for the libraries
> >>> b) Leverage GitHub Pages functionality
> >>> c) Improve KLC
> >>>
> >>> And, eventually:
> >>>
> >>> Provide a standardised way to separate the KiCad libraries from the
> KiCad
> >>> installer!
> >>>
> >>> Thoughts and comments appreciated!
> >>>
> >>> Cheers,
> >>>
> >>> Oliver
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>
> >>
> >> --
> >>
> >> -Ben
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Adam Wolf]

I really, really like the idea of having the libraries page on the
KiCad website itself.

I have run into numerous people who do not understand that the github
libraries are "official".  Plus, this means that *for whatever reason*
if the libraries move from github, the pages explaining the libraries
stay in the same space.

Adam Wolf

On Thu, Sep 14, 2017 at 7:54 PM, Oliver Walters
 wrote:
> Ben,
>
> That's also an option, I hadn't considered that! Perhaps I was focused on
> the GitHub-side solution too closely.
>
> Wayne, do you want to weigh in here before I spend too much further effort
> developing this? Could the libraries page be developed on the KiCad website
> itself?
>
> The structure could remain largely the same but the formatting would need to
> change from Jekyll to Hugo.
>
> Cheers,
> Oliver
>
> On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest  wrote:
>>
>> Does this method provide an advantage over doing a similar thing using
>> Hugo and putting the docs on the kicad-pcb.org website?
>> https://github.com/KiCad/kicad-website
>>
>>
>> - Ben
>>
>> On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters
>>  wrote:
>>>
>>> Hi everyone,
>>>
>>> The conversation of how best to manage and distribute KiCad libraries has
>>> been raging for a while now.
>>>
>>> Users looking to download or contribute to the libraries are currently
>>> presented with a github landing page and some bland wiki pages (e.g. for the
>>> KLC information).
>>>
>>> I have been working on a new-and-improved website system for the
>>> following:
>>>
>>> * Clear information about the libraries
>>> * A place to download the latest libraries
>>> * Information on what is *in* the libraries
>>> * Instructions on how to contribute to the libs
>>> * Better presentation of the KLC
>>>
>>> This website will need to be updated periodically to present the latest
>>> version of the libraries to the users. Also, if users are going to be
>>> downloading library files then it could potentially use a lot of bandwidth.
>>> Thirdly, the generated content should be scripted but statically hosted.
>>>
>>> The solution? GitHub pages! - https://pages.github.com/ -
>>>
>>> These are hosted from your github repository, and for e.g. ours would
>>> have the URL kicad.github.io - this could be easily redirected from
>>> kicad-lib.org/library (for example).
>>>
>>> GitHub pages use the jekyll toolset to generate static content.
>>>
>>> With a small amount of additional Python scripting I have created a
>>> bare-bones example of what this might look like (locally hosted on my laptop
>>> for now):
>>>
>>> Here are some screenshots! Ignore the colors and simple layout scheme,
>>> this is currently just a framework.
>>>
>>> https://imgur.com/a/0GELG
>>>
>>> The main objectives of this project are:
>>>
>>> a) Present a more professional landing page for the libraries
>>> b) Leverage GitHub Pages functionality
>>> c) Improve KLC
>>>
>>> And, eventually:
>>>
>>> Provide a standardised way to separate the KiCad libraries from the KiCad
>>> installer!
>>>
>>> Thoughts and comments appreciated!
>>>
>>> Cheers,
>>>
>>> Oliver
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> --
>>
>> -Ben
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Ben,

That's also an option, I hadn't considered that! Perhaps I was focused on
the GitHub-side solution too closely.

Wayne, do you want to weigh in here before I spend too much further effort
developing this? Could the libraries page be developed on the KiCad website
itself?

The structure could remain largely the same but the formatting would need
to change from Jekyll to Hugo.

Cheers,
Oliver

On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest  wrote:

> Does this method provide an advantage over doing a similar thing using
> Hugo and putting the docs on the kicad-pcb.org website?
> https://github.com/KiCad/kicad-website
>
>
> - Ben
>
> On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> The conversation of how best to manage and distribute KiCad libraries has
>> been raging for a while now.
>>
>> Users looking to download or contribute to the libraries are currently
>> presented with a github landing page and some bland wiki pages (e.g. for
>> the KLC information).
>>
>> I have been working on a new-and-improved website system for the
>> following:
>>
>> * Clear information about the libraries
>> * A place to download the latest libraries
>> * Information on what is *in* the libraries
>> * Instructions on how to contribute to the libs
>> * Better presentation of the KLC
>>
>> This website will need to be updated periodically to present the latest
>> version of the libraries to the users. Also, if users are going to be
>> downloading library files then it could potentially use a lot of bandwidth.
>> Thirdly, the generated content should be scripted but statically hosted.
>>
>> The solution? GitHub pages! - https://pages.github.com/ -
>>
>> These are hosted from your github repository, and for e.g. ours would
>> have the URL kicad.github.io - this could be easily redirected from
>> kicad-lib.org/library (for example).
>>
>> GitHub pages use the jekyll toolset to generate static content.
>>
>> With a small amount of additional Python scripting I have created a
>> bare-bones example of what this might look like (locally hosted on my
>> laptop for now):
>>
>> Here are some screenshots! Ignore the colors and simple layout scheme,
>> this is currently just a framework.
>>
>> https://imgur.com/a/0GELG
>>
>> The main objectives of this project are:
>>
>> a) Present a more professional landing page for the libraries
>> b) Leverage GitHub Pages functionality
>> c) Improve KLC
>>
>> And, eventually:
>>
>> Provide a standardised way to separate the KiCad libraries from the KiCad
>> installer!
>>
>> Thoughts and comments appreciated!
>>
>> Cheers,
>>
>> Oliver
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
>
> -Ben
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

On 15 Sep 2017 01:29, "Andrey Kuznetsov"  wrote:

If possible, would be good to have a single full KLC page with all the
rules combined in addition to the individual chapter pages, hopefully using
the same KLC source without having to maintain 2 version.
This is useful when you want to use the browser find functionality instead
of clicking on chapters or when you want to print out the KLC, which
reminds me there should be a revision and last update date time stamp to
the ruleset somewhere at the top of the page of the full KLC ruleset.


The KLC page currently auto-generates revision number and date :)

I'll have a think about the all-on-one-page idea.

Thanks


--
Andrey


On Thu, Sep 14, 2017 at 5:01 AM Oliver Walters  wrote:

> Hi everyone,
>
> The conversation of how best to manage and distribute KiCad libraries has
> been raging for a while now.
>
> Users looking to download or contribute to the libraries are currently
> presented with a github landing page and some bland wiki pages (e.g. for
> the KLC information).
>
> I have been working on a new-and-improved website system for the following:
>
> * Clear information about the libraries
> * A place to download the latest libraries
> * Information on what is *in* the libraries
> * Instructions on how to contribute to the libs
> * Better presentation of the KLC
>
> This website will need to be updated periodically to present the latest
> version of the libraries to the users. Also, if users are going to be
> downloading library files then it could potentially use a lot of bandwidth.
> Thirdly, the generated content should be scripted but statically hosted.
>
> The solution? GitHub pages! - https://pages.github.com/ -
>
> These are hosted from your github repository, and for e.g. ours would have
> the URL kicad.github.io - this could be easily redirected from
> kicad-lib.org/library (for example).
>
> GitHub pages use the jekyll toolset to generate static content.
>
> With a small amount of additional Python scripting I have created a
> bare-bones example of what this might look like (locally hosted on my
> laptop for now):
>
> Here are some screenshots! Ignore the colors and simple layout scheme,
> this is currently just a framework.
>
> https://imgur.com/a/0GELG
>
> The main objectives of this project are:
>
> a) Present a more professional landing page for the libraries
> b) Leverage GitHub Pages functionality
> c) Improve KLC
>
> And, eventually:
>
> Provide a standardised way to separate the KiCad libraries from the KiCad
> installer!
>
> Thoughts and comments appreciated!
>
> Cheers,
>
> Oliver
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Oliver Walters]

Ingo,


On 15 Sep 2017 03:51, "Ingo Kletti"  wrote:

Hi,

will the framework allow to generate and present previews/artwork for the
schematic symbols and footprints contained in the different libraries?

This might be useful if in the future the libraries become really big (e.g.
if there should be official atomic libraries). Think of a user that tries
to find a specific component so he only needs to pull that one library
instead of the complete libraries.


Yes indeed. In the fullness of time I envision that a preview image can be
generated for each symbol / footprint as well as listing information about
each element. Additionally, providing a search feature across these data
would be key.

A minor nitpick from personal preference: An always visible table of
contents for easy jumping between pages and/or breadcrumb navigation would
be great.


Can you provide an example of what you mean?


Regards,

Ingo


-- 
---

HTWG Konstanz
Hochschule Technik, Wirtschaft und Gestaltung

Fakultät Elektrotechnik und Informationstechnik
Dipl.-Ing. (FH) Ingo Kletti

Alfred-Wachtel-Strasse 8
78462 Konstanz
Germany

Telefon: +49 (0)7531/206-263
Fax: +49 (0)7531/206-87263
E-Mail:  ikle...@htwg-konstanz.de
URL: http://www.htwg-konstanz.de



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Ingo Kletti]

Hi,

will the framework allow to generate and present previews/artwork for 
the schematic symbols and footprints contained in the different libraries?


This might be useful if in the future the libraries become really big 
(e.g. if there should be official atomic libraries). Think of a user 
that tries to find a specific component so he only needs to pull that 
one library instead of the complete libraries.


A minor nitpick from personal preference: An always visible table of 
contents for easy jumping between pages and/or breadcrumb navigation 
would be great.


Regards,

Ingo


--
---

HTWG Konstanz
Hochschule Technik, Wirtschaft und Gestaltung

Fakultät Elektrotechnik und Informationstechnik
Dipl.-Ing. (FH) Ingo Kletti

Alfred-Wachtel-Strasse 8
78462 Konstanz
Germany

Telefon: +49 (0)7531/206-263
Fax: +49 (0)7531/206-87263
E-Mail:  ikle...@htwg-konstanz.de
URL: http://www.htwg-konstanz.de


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Wayne Stambaugh]

Hey Oliver,

Nice work!  Once this is ready to go, it is definitely something that
should be added or linked to the KiCad website.  Currently our users
really don't have friendly resource for discovering what libraries are
available for KiCad and how to get them.  I consider this a big plus for
our users and the project.  It is one of the more common complaints I
hear about KiCad.  Thank you for taking the lead on this.

Cheers,

Wayne

On 9/14/2017 8:01 AM, Oliver Walters wrote:
> Hi everyone,
> 
> The conversation of how best to manage and distribute KiCad libraries
> has been raging for a while now.
> 
> Users looking to download or contribute to the libraries are currently
> presented with a github landing page and some bland wiki pages (e.g. for
> the KLC information).
> 
> I have been working on a new-and-improved website system for the following:
> 
> * Clear information about the libraries
> * A place to download the latest libraries
> * Information on what is *in* the libraries
> * Instructions on how to contribute to the libs
> * Better presentation of the KLC
> 
> This website will need to be updated periodically to present the latest
> version of the libraries to the users. Also, if users are going to be
> downloading library files then it could potentially use a lot of
> bandwidth. Thirdly, the generated content should be scripted but
> statically hosted.
> 
> The solution? GitHub pages! - https://pages.github.com/ -
> 
> These are hosted from your github repository, and for e.g. ours would
> have the URL kicad.github.io  - this could be
> easily redirected from kicad-lib.org/library
>  (for example).
> 
> GitHub pages use the jekyll toolset to generate static content.
> 
> With a small amount of additional Python scripting I have created a
> bare-bones example of what this might look like (locally hosted on my
> laptop for now):
> 
> Here are some screenshots! Ignore the colors and simple layout scheme,
> this is currently just a framework.
> 
> https://imgur.com/a/0GELG
> 
> The main objectives of this project are:
> 
> a) Present a more professional landing page for the libraries
> b) Leverage GitHub Pages functionality
> c) Improve KLC
> 
> And, eventually:
> 
> Provide a standardised way to separate the KiCad libraries from the
> KiCad installer! 
> 
> Thoughts and comments appreciated!
> 
> Cheers,
> 
> Oliver
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Andrey Kuznetsov]

If possible, would be good to have a single full KLC page with all the
rules combined in addition to the individual chapter pages, hopefully using
the same KLC source without having to maintain 2 version.
This is useful when you want to use the browser find functionality instead
of clicking on chapters or when you want to print out the KLC, which
reminds me there should be a revision and last update date time stamp to
the ruleset somewhere at the top of the page of the full KLC ruleset.

--
Andrey


On Thu, Sep 14, 2017 at 5:01 AM Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Hi everyone,
>
> The conversation of how best to manage and distribute KiCad libraries has
> been raging for a while now.
>
> Users looking to download or contribute to the libraries are currently
> presented with a github landing page and some bland wiki pages (e.g. for
> the KLC information).
>
> I have been working on a new-and-improved website system for the following:
>
> * Clear information about the libraries
> * A place to download the latest libraries
> * Information on what is *in* the libraries
> * Instructions on how to contribute to the libs
> * Better presentation of the KLC
>
> This website will need to be updated periodically to present the latest
> version of the libraries to the users. Also, if users are going to be
> downloading library files then it could potentially use a lot of bandwidth.
> Thirdly, the generated content should be scripted but statically hosted.
>
> The solution? GitHub pages! - https://pages.github.com/ -
>
> These are hosted from your github repository, and for e.g. ours would have
> the URL kicad.github.io - this could be easily redirected from
> kicad-lib.org/library (for example).
>
> GitHub pages use the jekyll toolset to generate static content.
>
> With a small amount of additional Python scripting I have created a
> bare-bones example of what this might look like (locally hosted on my
> laptop for now):
>
> Here are some screenshots! Ignore the colors and simple layout scheme,
> this is currently just a framework.
>
> https://imgur.com/a/0GELG
>
> The main objectives of this project are:
>
> a) Present a more professional landing page for the libraries
> b) Leverage GitHub Pages functionality
> c) Improve KLC
>
> And, eventually:
>
> Provide a standardised way to separate the KiCad libraries from the KiCad
> installer!
>
> Thoughts and comments appreciated!
>
> Cheers,
>
> Oliver
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Ben Hest]

Does this method provide an advantage over doing a similar thing using Hugo
and putting the docs on the kicad-pcb.org website?
https://github.com/KiCad/kicad-website


- Ben

On Thu, Sep 14, 2017 at 7:01 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Hi everyone,
>
> The conversation of how best to manage and distribute KiCad libraries has
> been raging for a while now.
>
> Users looking to download or contribute to the libraries are currently
> presented with a github landing page and some bland wiki pages (e.g. for
> the KLC information).
>
> I have been working on a new-and-improved website system for the following:
>
> * Clear information about the libraries
> * A place to download the latest libraries
> * Information on what is *in* the libraries
> * Instructions on how to contribute to the libs
> * Better presentation of the KLC
>
> This website will need to be updated periodically to present the latest
> version of the libraries to the users. Also, if users are going to be
> downloading library files then it could potentially use a lot of bandwidth.
> Thirdly, the generated content should be scripted but statically hosted.
>
> The solution? GitHub pages! - https://pages.github.com/ -
>
> These are hosted from your github repository, and for e.g. ours would have
> the URL kicad.github.io - this could be easily redirected from
> kicad-lib.org/library (for example).
>
> GitHub pages use the jekyll toolset to generate static content.
>
> With a small amount of additional Python scripting I have created a
> bare-bones example of what this might look like (locally hosted on my
> laptop for now):
>
> Here are some screenshots! Ignore the colors and simple layout scheme,
> this is currently just a framework.
>
> https://imgur.com/a/0GELG
>
> The main objectives of this project are:
>
> a) Present a more professional landing page for the libraries
> b) Leverage GitHub Pages functionality
> c) Improve KLC
>
> And, eventually:
>
> Provide a standardised way to separate the KiCad libraries from the KiCad
> installer!
>
> Thoughts and comments appreciated!
>
> Cheers,
>
> Oliver
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 

-Ben
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp