kicad-lib-committers team mailing list archive

[Jan Krieger <jan@xxxxxxxxxxx>]

Hi!

sorry for the late answer ... and just a few thoughts on the stuff:

ad 1) I think a major advantage would be to be able to have 
symbol+footprint+3D package in a single PR (not 2-3 separate PRs that 
have to be reviewed separately and linked so they are seen as one thing) 
... but that would also mean we have ONE repo for symbols+footprints+3D 
... Also this may help in seeing new PRs ... as I have the feeling that 
often PRs to the .pretty-repos tend to get no attention, possibly 
because there are so many repos that they simply get lost.

ad 2) YES PLEASE!!! I think it would also be great to provide users with 
a sinmple button/menu entry in KiCAD that allows to submit a 
symbol/footprint/3D package (or parts thereof) ... I know that e.g. 
Target!3001 has such an option ...

ad 3) maybe a structure like this:
  MAINREPO "kicad-library"
     |
     +--- symbols -> contains all the symbol libraries as subdirs (in 
future)
     |
     +--- footprints -> contains all the footprint libraries as subdirs
     |
     +--- packages3d -> contains all the 3D packages, grouped into subdirs

Then in addition KiCAD should allow to select three different pathes (or 
several for each category):
  - symbols: http://REPO/DIR/symbols
  - footprints: http://REPO/DIR/footprints
  - packages3d: http://REPO/DIR/packages3d
This way, a user can e.g. use the standard symbols, but his own flavour 
of footprints and 3D packages ... and so on ...


About the GIT submodules: I'm not sure whether this solves the points 
above: With submodules (as far as I understand them and used them until 
now) you still have separate repos for everything, you just (kind of) 
reference a certain commit/tag/master of another repo. What you e.g. 
don't get are consolidated commits ... i.e. you cannot do a comit that 
pushes something to more than one submodule ... you will always have to 
push in the submosules separately. So in the end it will be more or less 
just a directory that has all repos checked out with one command ... or 
am I mistakenß

Best,
JAN




Am 28.12.2016 um 00:55 schrieb Oliver Walters:
> 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 <mailto: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
>     <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
>     <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


--
+---------------------------------
|   Jan Krieger
|   Schwetzinger Straße 60
|   69124 Heidelberg
|
|   jan@xxxxxxxxxxx
|   www.jkrieger.de
+---------------------------------