kicad-developers team mailing list archive

["Thomas Kindler" <mail_ubuntu@xxxxxxxxxxxx>]

On Sat, September 23, 2017 21:01, Simon Küppers wrote:
> [..]
>
> Maybe it would be a good way to implement two git repos, one for
> footprints and one for 3D models (and a third one for schematic symbols..).
> That is 3 repos to maintain instead of more than some dozens
> as it is right now. Then I would agree with you, I would personally be ok
> with downloading either all footprints or none and not be able to select
> the libraries to download.

I would prefer an all-or-nothing approach to symbols and footprints. They
take up very little space, and if all users have the same basic set of
libraries, it's great for support.

> And then the user can choose if 3D models
> should be pulled additionally.

Agreed. People with older computers may choose not to use them.

The default should be to clone everything though.


> However that is my opinion only. (What actually about stream compression
> for KiCad Libraries? Of course this would be a big change but could reduce
> just the disk and download size in general)
>

Download size will stay the same as git already uses compression.

.sweet and .pretty should stay uncompressed for easier diffing. But the
generated .step and .wrl files could be compressed (possibly not even
worth it, as it may make git compression worse).

> However, once the repos are pulled they need to be "tracked" somehow.
> Because I strongly disagree with everyone saying "Just do it as you do
> in software development, use the command line periodically to check for
> KiCad footprint repo changes". Just No.

As a user, I would expect the same behaviour as with commercial PCB tools:
Libraries are updated along with new software releases. That way the
libraries are guaranteed to work and are checked for compatibility.

For KiCAD, the 4.0.7 installer should check out the 4.0.7 branch initially.

For library-developers there could be a 4.0-next branch.

Nigthly versions could track master by default.


> A simple first idea I was having in mind for a long time is just a check
> on KiCad startup (by default, can be changed) what the status of the git
> remote is and _notify_ the user if something has changed and if they want
> to pull in the changes _to disk_.

KiCAD could check if the library branch matches the software version. If I
install KiCAD 4.1.0 (or so), it should offer to pull the updates and
checkout the new branch.

Extra care must be taken if the user made local modifications - we don't
want a merge or rebase here.


> Not altering any of the designs of course! This could be improved later
> to provide a more sophisticated GIT integration in KiCad (I get the warm
> fuzzy feeling when I write this :-))

A side-by-side graphical diff viewer would be nice!

-- 
Thomas Kindler