[Ground-station] How are we set for layout tools?

[John Ackermann N8UR]

KiCad does have the concept of a project, and I am pretty sure it 
maintains a local cache of all the footprints used.

What I was suggesting was a little more than that -- collect up and 
share all the symbols and footprints used across all group projects in a 
set of (moderately) organized libraries that become *the* source 
libraries for future work.

That way you avoid recreating the wheel, and also get consistency -- if 
you have make available one tested footprint for an 0805 passive, you 
don't end up with people using all the slight variants that are 
available in the universe of libraries.

(And to be clear -- I'm not being KiCad specific about this; I think 
it's a good time investment no matter what tools you use.)

73,
John
----

On 7/28/20 1:39 PM, Keith Wheeler via Ground-Station wrote:
> Paul,
> 
> Honestly I personally wouldn't have separate repos for the outputs and 
> source. I'd tend towards a single repo, with outputs being generated for 
> each tagged release. I mentioned separate repos because many prefer to 
> model hardware repos on software ones where build artifacts are pushed 
> to a different channel. The complaint, as I understand it, is that at 
> any point in development other than tagging a release, there is likely 
> to be a mismatch between the source schematic document output documents. 
> Seems to me the best way to resolve this is a well written readme; I 
> think CI/CD is still a radical concept for board design, at least once 
> you get away from multik$ tools which have scripting support for 
> automated output generation.
> 
> One thing I'd change in the trans-ionospheric repo is the "outputs" 
> directory. The gerbers, drc, BOM, etc are all there. Perhaps a directory 
> structure for these would be in order, and one would be the pdf's of the 
> source docs. Netlists would be a useful output.
> 
> John,
> 
> I completely agree with your comment about creating a project library. 
> Some tools make that easy; the top tier Altium does, I don't know about 
> the "Circuit Studio" I use or Kicad. While "source" a project library 
> should be at a minimum updated with every tagged release. Other than the 
> tool the project space should contain every source file someone would 
> need to recreate and modify the gerbers, BOM, etc, with no surprise 
> library dependencies. It also prevents issues with name collisions -- 
> I've seen tools just default to using the first "SOT23" footprint it 
> finds, and if there are different footprints that differ in pin 
> ordering, bad things happen.
> 
> On Tue, Jul 28, 2020 at 9:36 AM Paul Williamson via Ground-Station 
> <ground-station at lists.openresearch.institute> wrote:
> 
>>     On Jul 28, 2020, at 7:53 AM, Keith Wheeler wrote:
>>     This also opens the question of do we have a repo for source and
>>     another for tagged released outputs.
> 
>     I’m curious as to why it might be a good idea to have separate repos
>     for work and outputs. At first glance it would seem to me that this
>     is just asking for version skew confusion and extra work.
>>
>>     1.
>>
>>         Not all parties interested in the schematic and layout source
>>         files will desire access to the tool. We should publish these
>>         in a more common format (pdf?), perhaps at every tagged release.
>>
>     Yes, we absolutely should. Even people who do have access to the
>     tools may find it quicker and easier to open a PDF for reference.
>     The semantics of the special source file formats can have
>     dependencies on library files that could become separated (or
>     version skewed) from the design, or on features of specific tool
>     versions. A stable, widely recognized, print-oriented format like
>     PDF gives a valuable point of reference for what the thing is
>     supposed to look like. Ancillary text-based outputs like netlists
>     can also be helpful for people working with the hardware.
> 
>        -Paul KB5MU
>