kicad-lib-committers team mailing list archive

[Oliver Walters <oliver.henry.walters@xxxxxxxxx>]

Hi everyone,

Looking for some comment on an issue I raised on the github page a while
ago:

https://github.com/KiCad/kicad-library/issues/824

Having each footprint .pretty lib split into its own repository provides
great separation of files but it does increase workload.

1. Keepling libraries updated

Whilst not all users would interact with the libs in the same fashion,
whenever a .pretty repo is updated, I have to merge the master branch for
that lib. I also have to keep forks for each .pretty repo that I contribute
to.

2. Library Management

Going forward it would be very useful to have some automated CI tools that
(for e.g.) assist users with KLC conformance. As the libraries stand
currently, this would require that such a tool be installed and maintained
for each .pretty repository!

3. Consistency with Schematic Symbols

The schematic symbols currently inhabit a single repository
(kicad-library). The .lib file structure means that there are multiple
symbols per file but this is slated to change when the schematic editor
updates are made.

I would imagine that when the new .sweet directories are introduced, the
kicad-library repository will remain in place, with the individual .sweet
directories introduced as subdirs.

Having all the .pretty directories appear under the same structure would be
good for consistency (in addition to greatly simplifying the large number
of repositories that currently exist)

4. Footprint Table
The current footprint table must be updated each time we add / remove /
rename a .pretty repo.

Thoughts:

As noted on the github issue (
https://github.com/KiCad/kicad-library/issues/824) the current github
plugin implementation for the .pretty repos means that .pretty folders that
are located as subdirectories of a git repo cannot be accessed by the KiCad
library.

This means that simply consolidating all the .pretty repos into a single
master repo will break the current KiCad implementation.

We could update the github plugin code in KiCad to allow this, but such a
large and swift change would cause a lot of grief for users.

Suggestion:

What do people think of the idea of creating a new repo ( kicad-footprints
for e.g. ) which contains all the current .pretty repositores as submodules
(or subtrees)?  Some preliminary reading suggests that we should be able to
link the .pretty repos in such a manner, and at least this would allow devs
to work on the entire footprint library whilst not disturbing the
underlying repositories.

In the future we should consider updating the KiCad code such that it is
compatible with the idea of a single footprint repository. Perhaps for the
v5 release as it is such a grand change?

( As a side note I would also be very much in favour of a v5 release also
including a separate ./3d-models repository )

I am very interested in your opinions on this.

Regards,
Oliver