← Back to team overview

kicad-developers team mailing list archive

Re: GitHub Plugin (my nemesis)

 

I am no expert, but this question is out of the scope of this thread.. For downloading, gut applies compression anyway. 

I respect the people having slow Internet lines.. However as shown a few posts backwards, the whole footprints and symbol library is like 100 megabytes without the 3d models. If think the benefit of a single repo outways the ability to download only a selection of libraries... By a LOT. 



Am 2. Oktober 2017 10:22:10 MESZ schrieb Andrey Kuznetsov <kandrey89@xxxxxxxxx>:
>Is it possible to keep the 3d models ZIPed or RARed on disk and KiCAD
>unpacks them on the fly as needed/used during the session/etc?
>
>I am seeing 10x reduction in size when I pack the files whether they
>are
>7.5MB or 120KB, both were reduced to 750KB and 10KB respectively.
>That's a lot of space wasted if we're thinking of the poor designers
>with
>limited disk space.
>
>On Mon, Oct 2, 2017 at 1:03 AM, Carsten Schoenert
><c.schoenert@xxxxxxxxxxx>
>wrote:
>
>> Am 02.10.2017 um 06:14 schrieb David Godfrey:
>> > Bernhard hit the nail on the head here.
>> > For normal Users, ALL of the git functionality should be hidden
>behind
>> > basic KiCad GUI features.
>>
>> A "normal" user doesn't need any git functions. He expects to have a
>> working solution if he is using KiCad or $whatever software. The
>tricky
>> part is on the software developers side, they need to take care about
>> full functional additional components for the normal users.
>>
>> > However, for Users and Librarians that want to manage, add, edit at
>> > least a basic knowledge of whatever tooling is used behind the
>scenes is
>> > a HARD REQUIREMENT.
>>
>> Agreed.
>> But such things are additional extras on the current situation. I
>guess
>> the intent of this whole thread was to improve the current situation
>on
>> the library handling inside KiCad. I think this should be focused on
>> first as this increases the usability on the user side significantly.
>>
>> > These days git is probably one of the best documented, and most
>well
>> > supported in the greater community.
>> > That alone makes it a very good choice of backend.
>> >
>> > Handling of submodules can be slightly tricky, but a few simple
>helper
>> > scripts (for LedgerSMB project we use a Makefile with a few targets
>such
>> > as "submodules" which updates all submodules to the current repo
>head's
>> > commit references to them)
>> Mhh, I never have seen that any body is really happy about git
>> submodules as they are always problematic. The reasons for this are
>> already written here in this thread.
>>
>> I always look at the Linux kernel development model which is quite
>> larger and bigger than the KiCad project.
>> All parts in the development there don't use git submoduls for good
>> reasons. All people involved always use the full tree. Sorry, I don't
>> see a real need and gain for using git submoduls. And even if you
>have
>> some scripting on top you need to teach the people how to use this.
>That
>> is *always* overhead I'd avoid.
>>
>> As written here also, a complete git repository about all of the
>> schematics with a stable and development branch and tagged releases
>> would be fine and enough. The l10n and documentation part is already
>> using this model.
>>
>> --
>> Regards
>> Carsten Schoenert
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
>-- 
>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]
>
>kandrey89@xxxxxxxxx
>Live Long and Prosper,
>Andrey

Follow ups

References