kicad-lib-committers team mailing list archive

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

One thing that I failed to mention - having a master repo that references
the sub .pretty repositories allows us to consolidate all the files
together at some future stage without breaking links.

On Wed, Dec 28, 2016 at 10:51 AM, Oliver Walters <
oliver.henry.walters@xxxxxxxxx> wrote:

> 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
>