kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

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